Guía para la administración y generación de directivas y datasheets de OSSIM.
manuales-ejemplos-alienvault-usm
OTX
Descripción completa
manual calderos cleaver brooks package . resumen de diferentes calderos pirotubularesDescripción completa
Descripción completa
Descrição completa
Manual for applying on Universiy of TIlburg, research master in philosophyFull description
guitarra
manual
Descripción completa
1.-OSSIM. Monitorización de eventos de seguridad. Antes de llover chispea !!!
El uso de herramientas para la gestión SIEM (Security Information and Event Management) es algo necesario para controlar la buena salud de nuestros sistemas y podemos darle el enfoque que necesitemos, no solo manejando datos de seguridad sino cualquier log de cualquier sistema.
Según la Wikipedia, un sistema SIEM nos permite agregar datos de varias fuentes, correlación de logs ( un intento de autenticación fallido es una linea de log, varios es un ataque de fuerza bruta) alertas, cuadros de mando con gráficos preciosos, análisis forense y retención en el tiempo de eventos pasados.
No conozco a ningún administrador de sistemas que se pase una mañana entera navegando por el visor de eventos de sus 100 servidores Windows en busca de códigos de error sospechosos. Siempre recurrimos a los logs en caso de errores, caidas, deterioro en el rendimiento etc. En mi "pueblo" se emplea una frase muy graciosa para algo mucho menos gracioso, pero que creo viene como anillo al dedo: ANTES DE LLOVER CHISPEA !!!! Los amigos de Security By Default escribieron un buen post con algunas impresiones sobre el funcionamiento que creo complementan este post y que debes leer. La aventura con OSSIM comienza con la descarga de la ISO. Vamos a usar la versión Open Source que en este momento anda por 4.3. El fabricante nos ofrece todo tipo de enlaces para probar su versión de pago por lo que tenemos que buscar en las fichas de producto, en la comparativa para encontrar la versión Free.
Para este laboratorio voy a usar una máquina virtual sobre mi infraestructura Vmware por lo que me creo una VM, engancho la ISO y siguiente siguiente siguiente...
Ahora ya tenemos instalado nuestro OSSIM. Como indica el banner, para traer la paz y la seguridad...Configuramos el usuario y entramos al portal.
Curioso que nada más instalado tengamos eventos de seguridad. Vamos a darle alguna vuelta para ver que tenemos.
Como se puede apreciar, el sensor OSSEC ha detectado una escritura en un fichero propiedad de ROOT lo cual es un indicio de actividad peligrosa. Esto se ha realizado en la propia instalación/configuración de OSSIM. Recordar que OSSEC es un IDS a nivel de HOST (HIDS) es decir, es como un "Snort" pero en vez de escuchar en modo promiscuo todo el tráfico, atiende solo a los cambios o incidentes que se originan en el host que lo tiene instalado. El problema de estas instalaciones sencillas es que uno pierde la sensación de control sobre los elementos, por lo que me gusta dejarla un poco "pelada". Nos ubicamos en Configuration->Deployment. Ubicamos el sensor por defecto que se crea en la propia instalación de OSSIM y vamos a ver que componentes están a la escucha.
Pinchando sobre el sensor que he tachado abajo a la izquierda podemos ver alguna información.
Pinchamos en Sensor Configuration.
Para
este
sensor
voy
a
descriptivos. Prads, Suricata,
deshabilitar etc.
Voy
a
todos dejar
el
los
servicios
sistema
como
que
creo
son
un
mero
syslog
bastante bonito.
También voy a borrar todos los logs generados, por empezar desde cero...
Ahora es el turno de desplegar un agente en algún servidor Windows para ver los logs, que es por donde iba esto...
Ya tenemos nuestro agente !!! Ahora unos clicks en el servidor y listo.
Con esto ya podéis jugar un poco con la instalación de OSSIM.
2.-OSSIM. Pentesting continuo como si estuvieses en primero En el último capítulo hablamos de la instalación de esta suite y de una pequeña configuración básica de agentes Windows mediante el HIDS OSSEC para monitorización de logs...Ahora vamos con la parte que más os gusta de la seguridad, el pentesting, el NMAP, el Open-vas y los gráficos a todo color !!! Recuerdo una frase de mi amigo y organizador de Navaja Negra @ggdaniel , no recuerdo muy bien porque lo decía, pero era algo así como "es más difícil de instalar que Open-vas" me partí el pecho !!! Parece mentira "tan" informáticos que somos, tantas tools que usamos, e instalar desde cero Open Vas en una debian tiene su chicha...
Cuando instalamos OSSIM instalamos por defecto el scanner de seguridad Open Vas y Nessus que podemos integrar en nuestra colección de dispositivos monitorizados para realizar un pentesting programado e integrado dentro del motor de informes de OSSIM. En su día en Inseguros hablamos de esto, del pentesting contínuo mediente la programación de Nessus y comparando sus resultados. Lo primero que tenemos que hacer es indicar a OSSIM qué es nuestra red, o cuales son nuestros equipos, y posteriormente preparar el asunto de las políticas de scaneo, a qué equipos y demás menesteres de los scanners de vulnerabilidades. Vamos a realizar un inventario de red de nuestra organización, lo que en OSSIM denominan ASSETS. Por debajo OSSIM realiza un NMAP con la posibilidad de elegir entre varios parámetros básicos. Con el resultado de este escaneo incorporaremos los dispositivos a nuestro inventario OSSIM. Podríamos importar un csv con esta información, habilitar Nagios, pero sinceramente prefiero tener Nagios por un lado, y OSSIM por otro.
Podemos configurar los Time´s de Nmap. Recuerdas el post donde hablamos de esto?
Ya tenemos nuestros equipos medianamente controlados en OSSIM. No vamos a tener Log´s de ellos, pero aglutinamos el conocimiento que generamos bajo el framework.
Ahora es el turno del pentesting. Vamos a seleccionar algún dispositivo y vamos a programar un test de vulnerabilidades para que se efectue los domingos por la tarde.
Bajo este punto vamos a configurar una política a nuestro gusto, simplemente porque sabemos y podemos !!
Ahora esperamos una semanita a que se ejecute el test para ver los resultados...O lo programamos para ejecución inmediata.
En el cuadro de mando inicial podemos ver un resumen por equipos, redes y los gráficos que tanto nos gustan. Ahora seguro que si eres una mente inquieta pensarás, bien, y dentro de un mes? los plugins de Openvas los actualizas tu kino? Noooo, puedes y deber actualizarlos tu manualmente o con un cron. El comando es sencillo.
Otra de las gestiones que podemos hacer rápidamente para mejorar nuestro testing es modificar el catálogo
de
puertos
que
Open-vas
escaneará.
Podemos
modificar
la
lista
en : /usr/share/openvas/openvas-services Otras de las configuraciones que solemos setear para los test de intrusión o de vulnerabilidades son las credenciales para los equipos. Desde vulnerabilidades accedemos a profiles y editamos los parámetros. En esa misma parte podemos configurar granularmente los plugins exactos que queremos aplicar en nuestra política, como hacíamos un poco más arriba, pero en vez de por familia, por plugin.
Si habéis utilizado OpenVas os sonará este apartado de configuraciones. Se agradece la configuración de los scripts NSE para Nmap. Si tus contraseñas son complejas, complejas de verdad de corazón :-) tal vez debas editar el fichero /usr/share/ossim/includes/classes/Security.inc. para añadir los caracteres válidos.
3.-OSSIM. Políticas y acciones personalizadas. ¿Qué hago como mis logs? Cuando hablamos de la gestión de la información nos referimos no solo a la detección y almacenamiento, sino a todas las posibles acciones que debemos llevar a cabo ante esas situaciones. Vivimos en un mundo conectado a la red las 24 horas del día, y la pregunta no es ¿Tendré algún incidente de seguridad? sino ¿Cuando tendré algún incidente de seguridad?. Podríamos debatir largo y tendido sobre este concepto, sobre todo con directores financieros pero asumimos que estamos en esa corriente, en la de ser todo lo proactivos que podamos.
Vamos a poner un ejemplo sencillo. Has seguido la serie de artículos uno y dos, has montado tu sistema y recibes al día 1200 logs, o 12000. Aún no has conectado tus sistemas de producción, salvo el ejemplo que hicimos de instalar OSSEC en un servidor Windows. Solo con los propios logs de
OSSIM del demonio ssh ya tenemos entretenimiento para rato. Podemos desactivar la monitorización del demonio ssh o podemos desactivar toda la monitorización del demonio en ese servidor, salgo los intentos de login con una clave incorrecta. Viendo el proceso descubriréis lo fácil e intuitivo que es.
Podemos trabajar con una política por defecto para todo el sistema, o para un política concreta para un servidor. En esta prueba realizaremos la política por defecto.
Podemos movernos por las distintas opciones pinchando en los bloques de color o en los menús laterales. Configuramos las opciones relativas al origen, destino, puertos.
Ahora configuramos los eventos. Podemos seleccionar eventos por su taxonomía, por la categorización que tienen, o bien por fuentes de datos o DS (data sources). Vamos a crearnos una fuente de datos específica para el componente SSHD.
Podríamos configurar de golpe todos los eventos generados por el sensor SSHD y creando una segunda política para incluir solo el evento de SSH password failure como notificación. Usamos la ordenación de políticas, como hacemos con los firewalls, para procesar primero la regla de "aceptar", en nuestro caso, la segunda regla.
O podemos hacerlo al revés. Seleccionando evento por evento dentro del sensor SSHD y dejando sin marcar el que queremos que SI notifique.
Dentro de las opciones relativas a las consecuencias nos vamos a centrar en la parte de SIEM. Solo queremos
limpiar
eventos
innecesarios
pero
que
pueden
aportar
valor.
En el próximo artículo haremos varias pruebas de acciones. La parte de Logger y fordwarding no está operativa en la versión OSSIM que estamos usando ( Alienvault=pago). Logger básicamente lo que hace es guardar los logs que recibimos de nuestras fuentes en formato RAW. OSSIM almacena las alertas generadas durante el tiempo que indiquemos, pero no conserva el log completo. Si hay campos que no se parsean por OSSIM se pierden. Por supuesto al alcanzar el ciclo de retención también se pierden. Podría ser necesario almacenar el log en raw para temas forenses, judiciales, etc. Fordwarding básicamente hace lo mismo con las alertas hacia otro servidor syslog. Por defecto se retienen los eventos durante 5 días. Podemos configurarlo..
Para este ejemplo de "limpiar" los eventos SSH del propio servidor salvo las contraseñas incorrectas simplemente activaremos NO en Sql Storage. .
Set Event Priority: Risk Assessment. Logical Correlation. Cross Correlation. Sql Storage. **Introducción.En próximos capítulos ampliaremos estos conceptos** Risk Assessment. Establece niveles de alerta para eventos. Cross Correlation. Referencias que se hacen entre eventos que contienen una ip de destino común. Por ejemplo, podríamos no almacenar un evento de fallo de inicio de sesión pero usar Cross Correlation. Varios intentos de inicio de sesión nos proporcionarían una correlación que llamamos "ataque de fuerza bruta" igual que las alertas de Snort y similares. Por supuesto podemos crear nuestras propias correlaciones... Logical Correlation: Referencias entre eventos que no tienen por qué tener como denominador común la ip de destino. Pongamos un ejemplo, tenemos una regla que no alerta de los login correctos en un ssh. Tenemos una regla para los ataques de fuerza bruta, con 3 intentos en n tiempo. Imaginar que un atacante intenta una password, no la encuentra, intenta otra password y acierta. No tendríamos ningún evento de la intrusión. Podríamos haber creado esa referencia o directiva. *** Ya tenemos configurada la gestión de los eventos del demonio ssh para que no nos inunde de información, pero conseguimos toda la potencia que nos ofrece un sistema de correlación de logs como OSSIM.
4.-Agente OSSEC en sistemas Debian Based Vamos a realizar un procedimiento similar al empleado en el despliegue de agentes OSSEC en Windows salvo que lo vamos a hacer sobre un sistema basado en Debian como es Kali Linux.
Para retomar un poco el hilo, hablamos de OSSEC como un sistema de detección de intrusos a nivel de host (HIDS). Podemos configurar que tipo de logs del sistema queremos monitorizar, así como establecer niveles de integridad en los ficheros para detectar cambios. También se implementa una tecnología para la detección de Rootkits. Monitoriza claves de registro en sistemas Windows. Todo ello lo enviaremos a nuestro servidor OSSIM para realizar nuestro análisis de eventos. El primer paso es configurar en OSSIM que vamos a usar un nuevo agente OSSEC ( que instalaremos en nuestro sistema debian) con un nombre y una dirección IP. Es recomendable realizar la anotación CIDR (P.E. 192.168.1.1/24). Generamos la clave para autenticar a nuestro cliente.
En nuestro equipo Debian descargamos el agente. wget http://www.ossec.net/files/ossec-hids-2.7.1.tar.gz tar -zxvf ossec-hids-2.7.1.tar.gz Ejecutamos el instalador que nos presenta un menú muy sencillo en donde seleccionamos el tipo de OSSEC que vamos a instalar, servidor o agente. La dirección ip del servidor y alguna cosita mas.
Una vez instalado configuramos el agente con la clave que hemos exportado desde OSSIM.
Una vez completado el proceso iniciamos el agente.
Podemos comprobar en OSSIM que ya tenemos conexión con el agente desplegado.
5.-OTX .Open Threat Exchange. OSSIM En el capítulo de hoy vamos a hablar de un servicio denominado OTX. Dicho servicio es una base de datos de conocimiento, mantenida por AlienVault, y puesta a la comunidad para su uso. Podemos navegar por la información de amenazas existentes mediante un browser o integrarlo en nuestra suite OSSIM para recibir alertas en el caso de estar siendo atacados por alguna dirección o evento catalogado en la base de datos.
Lo primero que hacemos es acceder desde OSSIM a Configuration-Administration-Main-OTX.
Nos creamos un usuario, o vinculamos el login con alguna de las plataformas. Una vez creado generamos el token y lo pegamos en la casilla correspondiente.
Podemos pinchar sobre contribuir. En el caso de tener amenazas en nuestro SIEM, nos propondrá un resumen con las direcciones IP. De esta manera se mantiene una base de datos de reputación IP que nos ayude a la hora de procesar la información de los eventos que nos llegan.
6.-Cambios look & feel en interface OSSIM En el episodio de hoy vamos a cambiar un poco la visión del panel de control de OSSIM. Ya sabes, los gráficos, los indicadores, nuestro cuadro de mando personalizado. Suelo aglutinar todos los indicadores bajo una pestaña por mi comodidad, aunque puedes entrar en cualquiera de la subsecciones para investigar los detalles. Otro punto a favor para realizar estos pequeños cambios es nuestro jefe !!! queda más elegante hacer una presentación mostrando información que conocemos y nos es útil, que no mostrar un montón de indicadores por defecto que quedan muy bonitos pero no son efectivos. Por último vamos a añadir una pestaña RSS. Esto es un Widget que agregamos con una fuente RSS. El propósito para mi es aglutinar en un solo sitio todas las fuentes de todos los sistemas que tengo instalados, y que me interesa estar al día en cuestiones de avisos de seguridad. Para ello creo que te será útil el post Crear fuente RSS personalizada. Comenzamos el proceso desde el DashBoard-Overview y habilitamos el modo de edición.
Podemos ocultar las pestañas generadas por defecto.
En la parte de la izquierda creamos una nueva pestaña, configuramos el número de columnas que vamos a mostrar y empezamos a añadir complementos o Widgets.
Podemos elegir entre varios tipos. Vamos a por las barritas !!!
Os dejo algunos ejemplos de complementos que me gustan.
Para añadir las fuentes RSS simplemente creamos una pestaña nueva y añadimos Widget de RSS y la fuente. Me gusta tener toda esta información asequible de un vistazo.
7.-OSSIM Análisis de vulnerabilidades y configuración de PLUGINS. Una de las opciones que hemos configurado en anteriores capítulos es un análisis de vulnerabilidades de nuestros equipos o infraestructura. Como en la mayoría de herramientas de este tipo, el proceso consiste en realizar la auditoría, comprobar manualmente el impacto de los hallazgos, identificar falsos positivos y falsos negativos. Una vez realizada la comprobación manual, debemos elegir entre abrir un ticket de trabajo, o simplemente deshabilitar el plugin que nos está dando falsos positivos para no incluirlo en nuestra auditoría. Vamos a realizar el segundo paso, deshabilitar el plugin que arroja información errónea. Como hacíamos con las políticas para la correlación de eventos, limpiar la información. Empezamos desde un informe de análisis. Identificamos la familia del plugin, y el id que queremos deshabilitar.
Una vez identificados, nos vamos a la configuración del Profile que usamos para el scaneo, y deshabilitamos el plugin.
De esta manera vamos configurando la visión de la información que arrojan los componentes de OSSIM.
8.-OSSIM Completando datos de nuestros activos. En el artículo de hoy vamos a completar la información que obtuvimos del proceso de descubrimiento de activos o Assets Discovery. Vamos a completar información para nuestros activos. Iré comentando su uso.
Elegimos editar un assets o activo.
Podemos editar manualmente cualquiera de estos atributos, o realizar un scaneo para ver que obtenemos.
Como podéis comprobar, podemos elegir entre varios tipos de scaneo. Realmente esto lanza un comando nmap. Podemos modificar cualquiera de ellos, aunque lo aconsejable es cambiar el Custom (por eso de los updates xD). la ruta mágica para cambiar la configuración de los scans la tenemos en: •
/usr/share/ossim/include/classes/Scan.inc Una vez terminado el scaneo, debemos actualizar la información en la base de datos, o borrar la información.
Ahora viene la parte que realmente nos interesa a la hora de configurar la información de los assets o activos. Aunque vamos a tratar todos estos aspectos en el próximo post, adelantar que hay que configurar varios valores para categorizar nuestros activos mediante unas métricas concretas.
Lo más importante es el valor que le queremos dar al activo. Es un valor entre el 0 y el 5 que debemos establecer en base a la importancia de nuestro activo. Ahora informamos el plugin que usamos para este activo, en este caso, un agente ossec.
Ahora es el turno de cambiar el nombre, la ubicación del activo dentro de un mapa...
Con esta parte tenemos suficiente. Configuramos nuestros activos con información que nos pueda ser útil a la hora de correlacionar eventos ( por ejemplo, una alerta para timeouts en un servicio que corre en un server con poca ram...) Lo más importante es que indiquéis el grado de importancia que tienen para vuestra organización el activo entre 0 y 5.
9.- OSSIM Solucionando problemas con Nikto Web Scanner En el artículo de hoy vamos a solucionar un problema que se presenta, al menos desde 4.6 ( actual 4.7.1) en OSSIM con el scanner Nikto.
Si has realizado un test de vulnerabilidades como indicamos en el capítulo 2 y has usado los plugins para abusos web, habrás comprobado como OSSIM nos revela un problema en el scanner NIKTO tal que así.
Como puedes apreciar, existe un problema con Nikto y el parámetro ASK. Vamos al fichero de configuración /var/lib/openvas/plugins/nikto.nasl
Comentamos los dos argumentos y ya podemos disfrutar de las opciones del Plugin para Nikto.
10.- OSSIM Un poco de teoría. Este artículo quizás podría ser el número uno. En este capítulo voy a hablar de la gestión de riesgos con OSSIM, que realmente es el propósito de esta suite. También voy a intentar explicar el funcionamiento interno del sistema de eventos, alarmas, correlación. OSSIM no es un gestor de log centralizado, como pueda ser cualquier servicio RSYSLOG. OSSIM es mucho más. Con OSSIM identificamos nuestros activos, establecemos prioridades en los eventos, creamos reglas que nos permiten gestionar el comportamiento de nuestros eventos, correlaciona eventos para detectar alertas,etc.
Empezamos el recorrido por nuestro sistema a monitorizar, las fuentes de logs. Podemos usar un servidor Windows o Linux instalando el agente OSSEC. Con este agente recopilamos información mediante los logs del sistema. OSSEC no es OSSIM. OSSEC es un HIDS (Host Intrusion Detection System) o mejor dicho LIDS ( Logs Intrusion Detection System). En comparación con un IDS de red como Snort, OSSEC no va a monitorizar los eventos de red para detectar un ataque, sino que "depende" de logs de Apache, Mod_security, firewall de Windows o cualquier aplicación que añadamos a la configuración de OSSEC para monitorizar. Como hemos mencionado, podemos configurar cualquier LOG en OSSEC para ser monitorizado y enviado a OSSIM. Si tenemos un sistema Snort instalado previamente, podemos monitorizar sus ficheros de logs mediante el agente. Si por cualquier motivo no podemos instalar el agente OSSEC en el servidor/sistema Snort, podemos configurar Snort para que envíe log al servidor rsyslog de OSSIM. Esto no es exclusivo para Snort, sino para CUALQUIER LOG.
Una de las herramientas que incorpora el propio OSSIM es SNORT. Esto quiere decir que podemos usar un Snort propio bajo un sensor, y que internamente envie información a OSSIM. Depende de tu infraestructura y necesidades el usar un Snort externo o usar el implementado con OSSIM.
He comentado arriba que podemos configurar OSSEC para que lea cualquier fichero de logs de nuestras aplicaciones pero... OSSIM en concreto lis plugins del sensor deben conocer la configuración de ese fichero. Cuando habilitamos plugins en el sensor debemos elegir los sistemas que vamos a parsear. Por ejemplo. Imagina que tienes un firewall Cisco, Fortigate o cualquiera de los populares. Si "conectamos" esa fuente de logs a nuestro sistema OSSIM, este entenderá perfectamente el formato del log.
Por supuesto que podemos crear nuestros plugins personalizados Ya hemos obtenido logs y los hemos "parseado" con los plugins del sensor.
para
nuestros
sistemas.
Este sensor es un componente de OSSIM. Podemos tener tantos sensores como nos apetezca. Al igual que hacemos con una instalación distribuida de Snort en la que tenemos un servidor central y varios sensores. La instalación del sensor OSSIM ( no confundir con OSSEC) debe realizarse con el fichero ISO proporcionado por AlienVault, por lo que no se puede instalar en un servidor Linux en ejecución. Quizás tu si puedas, pero he repasado la documentación y foros y al parecer es mucho más que complejo. Si tenemos un VPS externo a la organización, si tenemos una DMZ fuertemente protegida, o simplemente por cuestiones de rendimiento queremos usar otro sensor OSSIM, la opción más elegante es instalarlo como una VM dentro del segmento de red que queramos. Cuando el plugin OSSIM parsea el log, identifica unos campos básicos y los normaliza en su base de datos. Uno de los campos principales es el identificador de seguridad o SID. Esto qué significa?. Imaginamos que tenemos un servidor Windows con un agente OSSEC instalado. Configuramos que se reenvíen todos los logs del sistema ( visor de eventos) al sistema OSSIM. OSSIM normaliza la información pero no va a mostrar un evento por cada registro. Como decía al principio, OSSIM es una consola para administrar eventos de seguridad. El plugin OSSEC dentro de OSSIM conoce los identificadores de eventos de Windows, y en ese proceso de normalización, asignará un SID concreto para ese evento. Mediante las políticas decidimos qué eventos queremos que se nos muestren. Los campos "Destino" o que OSSIM normalizará son estos:
Una vez normalizado el log se convierte en un evento en OSSIM ( o quizás por nuestra configuración, desechamos ese evento. Como hicimos en la práctica de políticas personalizadas). A este evento le asignamos unos valores para conseguir mediante la métrica de OSSIM un valor definido como RIESGO. Por cada SID de nuestro plugin podemos atribuir un valor para estos dos conceptos: Priority: Prioridad. La urgencia para investigar el evento. Reliability: "Confiabilidad". La probabilidad de que el evento sea un falso positivo. Por defecto os muestro algunos valores para el plugin OSSEC con sistemas Windows.
Ahora tenemos un evento normalizado y valorado según estos dos criterios. Ahora nos referimos al artículo de personalización de activos, en donde veíamos como a cada activo o Asset se le asignaba un valor entre 0 y 5 según la importancia de este activo. Con estos 3 parámetros se define el Riesgo como: (ASSET
VALUE
*
PRIORITY
*
Por cada fabricante, metodología o Por ejemplo aquí teneís dos formulas. 1 y 2.
RELIABILITY) normativa
existe
/
25 una
=
RISK
formula
para
OF
THE
calcular
EVENT el
riesgo.
Si quieres leer un poco más sobre este asunto, te recomiendo MAGERIT ( Metodología y gestión de riesgos de los sistemas de información. Tenemos que tener en cuenta que por eventos que produzcan un Riesgo mayor a 1 se creará una alarma en OSSIM. Una vez asignado el riesgo, OSSIM lo agrupa por una Taxonomia que nos será útil a la hora de filtrar la información en nuestros cuadros de mando e informes.
Si realizaste la inscripción en el servicio OTX como vimos anteriormente, ahora es el turno de comparar la ip de origen del evento con la base de datos pública de OTX para identificar ese equipo. Si el equipo es externo (IP publica) se enviará esa información al servicio OTX dado su carácter colaborativo o comunitario como quieras llamarlo. El evento sigue de viaje !!! empezó siendo un log en un fichero, y ahora se ha hecho mayor !!! Es el turno para el motor de correlación, la verdadera punta de flecha de OSSIM. Cuando hablamos de correlación hablamos de identificar patrones de comportamiento entre elementos, que puedan ser de distinta fuente. Por ejemplo, un brute force sobre un servidor o servicio es fácil de detectar, pero imaginar un escenario distinto en el que un atacante tiene un usuario y clave SSH y lo que está haciendo es probar contra TODOS los equipos que corren un servidor SSH. No vamos a tener X intentos de conexión a un servidor, sino a varios servidores. Podemos crear nuestras propias correlaciones con nuestras "paranoyas" de seguridad más complicadas. Una de las que he leído y por supuesto nunca he implementado es una correlación de autenticación wifi y lectores de presencia: Si tenemos un sistema de control de presencia para empleados, el típico lector de tarjetas, conectado a nuestro servidor OSSIM sabemos que usuarios están dentro del edificio. Si tenemos un sistema de Wi-fi autenticado conectado a OSSIM sabemos cuando un usuario se conecta: La magia se produce en forma de alerta o evento de seguridad a investigar cuando un empleado que NO ha pasado por el detector de tarjeta está conectado al sistema Wi-fi... La imaginación y las regular expressión al poder!!! :-) Para ver algunos ejemplos que out-of-box de OSSIM:
Creo que no se me ha pasado ningún paso en el proceso de "gestión" de logs de OSSIM. Espero que os haya servido de ayuda para comprender un poco más el mundo SIEM, y como OSSIM gestiona la entrada de información y como la procesa.
11.- OSSIM Reenviando logs de Vmware Esxi. Agentless En anteriores artículos hemos visto como agregar fuentes de información a OSSIM para analizar. Hemos configurado esas fuentes de información desde un sensor OSSEC instalado bajo Windows y otro sensor OSSEC instalado bajo Debian. Ahora es el turno de agregar otra fuente de información de un sistema sobre el cual no podemos instalar software adicional, como pueda ser un Access Point. Para esta prueba vamos a "ligar" OSSIM con un hypervisor Vmware Esxi. Creo que existe un procedimiento para compilar el agente OSSEC en Esxi, pero no veo recomendable instalar herramientas C y un montón de librerías sobre nuestro Hypervisor. La única diferencia entre usar un cliente OSSEC y aprovechar las funciones syslog es la monitorización de integridad de ficheros. Si podemos prescindir de esta medida de seguridad en nuestro Host Esxi, perfecto !! El primer paso es configurar en nuestro Esxi que queremos reenviar los logs del sistema a un servidor syslog, que será la ip de nuestro sensor OSSIM por el puerto UDP 514. esxcli system syslog config set --loghost='udp://OSSIM:514' esxcli system syslog reload En la interface gráfica de OSSIM debemos habilitar el plugin para ESXI, ya sabes, para que sepa interpretar y normalizar los logs que le lleguen.
En la consola OSSIM: Creamos el fichero /var/log/vmware-esxi.log para almacenar los logs antes de parsearlos con OSSIM. Creamos el fichero /etc/rsyslog.d/vmware-esxi.conf y editamos if $fromhost-ip == 'ip_ossim' and $syslogseverity <= '6' then -/var/log/vmware-esxi.log
Añadimos /var/log/vmware-esxi.log al fichero de configuración de rotación de logs. En cuanto se produzca un evento que coincida con la condición que le hemos aplicado, podremos visualizarlo en la consola SIEM. Dentro de la necesidad de obtener información de sistemas a los cuales no podemos agregar software adicional (instalar un cliente OSSEC) existen dos peculiaridades... que pueda acceder por ssh o no. En el segundo caso el procedimiento termina aquí.
Para el caso del Esxi, podemos acceder por SSH al sistema, y monitorizar integridad de ficheros periodicamente con lo que se denomina OSSEC Agentless... El proceso de configuración es tan sencillo como siempre.
Indicamos los campos básicos.
Podemos elegir entre las comprobaciones habituales de OSSEC para cada tipo de sistema. Si seleccionamos SSH_DIFF podemos incluir una serie de comandos, y ossec simplemente los ejecutará y nos reportará eventos en caso de diferencias...
OSSIM 12. Como monitorizar webserver > 1mill. files. TCP tunning, Inotify, OSSEC performance y demás. Para esta entrada del verano voy a comentar algunos consejos que ido recopilando y usando en un despliegue empresarial que seguro os servirá de ayuda.
El escenario es un web server con distintos dominios y una larga seria de ficheros, mas o menos 1.000.000 de ficheros. La idea es monitorizar la integridad de dichos ficheros, mediante el agente OSSEC, el cual indexará varios datos como el tamaño, el hash md5 y el sha-1. Si has seguido la serie de artículos dedicados a Ossim, habrás configurado algún agente. Vamos a usar su capacidad de realizar File Integrity Monitoring editando el fichero ossec.conf ( /var/ossec/etc/). En el incluimos la ruta de ficheros que queremos monitorizar. Ignoramos algún directorio, extensión de ficheros y poco más respecto al Syscheck. 79200
Es muy sencillo y lo recomendables pasarse por la documentación oficial y leer todos los parámetros disponibles.
Hasta este punto es muy sencillo. Ahora debemos añadir una regla en nuestro decoder en OSSIM para que emita una alerta cuando un fichero nuevo se cree. Si no hacemos este paso podríamos verlo en la parte servido de OSSEC en el servidor OSSIM, pero queremos verlo graficamente. Editamos local_rules.xml en nuestro servidor OSSIM /var/ossec/rules/ y añadimos: ossecsyscheck_new_entryFile added to the system.syscheck,1 Recuerda que estas reglas son las únicas que no se "machacaran" con los updates...
En el supuesto de establecer que cada 8 horas compruebe el millón de archivos que existe en este caso la lectura/escritura se vería considerablemente mermada, y todos sabemos que el Performance de los servidores reside en el almacenamiento ( Ram y persistente). Ossec emplea la función Inotify del Kernel de Linux ( > 2.6.13) que nos permite el Real Monitoring es decir, en tiempo real, detecta los cambios... Justo lo que necesitamos. Esta función es empleada para muchos desarrollos debido a la agilidad que proporciona.
Inotify almacena en Kernel Space una estructura de datos en la que almacena los ficheros a revisar y las acciones asociadas. De esta manera, tendremos agilidad respecto al acceso a disco. Para poder ver el el número máximo de ficheros "controlados" podemos ejecutar: cat /proc/sys/fs/inotify/max_user_watches En mi caso he tenido que aumentar el tamaño para que no desborde el sistema. Realmente entran en cola, pero con la cantidad de ficheros se congestiona entra cada revision de SYSCHECK y no da los resultados correctamente. Cuanto lo subo? Lo primero que debemos saber es que en sistemas 64 bits, cada watch, cada objeto suervisado ocupa en memoria 1 kb. Para el millón de ficheros empleo 1 GB ( 1mill. kb)Al usar Kernel Space no entra en Swap, por lo que si te mueves en entornos de poca memoria ojo !!!. Para modificar el valor: echo fs.inotify.max_user_watches=1000000 >> /etc/sysctl.conf Si queremos ver los procesos que están consumiendo recursos de Inotify podemos ejecutar: ps -p `find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print | sed s/'^\/proc\/'/''/ | sed s/'\/fd.*$'/''/`
Otra de las configuraciones que he revisado el tamaño del buffer TCP. En una conexión TCP existe un mecanismo de control de flujo en el que ambos extremos de la conexión conocen el espacio disponible para procesar los paquetes. Aumentando este tamaño a las capacidades actuales de velocidad y memoria, podemos obtener rendimiento entra la comunicación de nuestro agente OSSEC y el servidor OSSEC instalado en OSSIM. En el caso de necesitar performance para copiar ficheros grandes por la red y similares, este TCP TUNNING nos ayudará. Para comprobar los tamaños del buffer TCP podemos ejecutar: cat /proc/sys/net/ipv4/tcp_mem Ajustamos a 12 MB como se recomienda para servidores de más de 4gb y líneas ADSL. alienvault:~# echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf alienvault:~# echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf sysctl -p Ejecutamos estas modificaciones en ambos extremos, OSSEC agente y servidor. De esta manera he conseguido tener el millón de ficheros controlado ante modificaciones deseada o no, subida de ficheros y en general medidas anti-defacement, RFI y demás amenazas WEB.
OSSIM 13. Conectando un sensor Snort externo y jugando con scripts. Por cierto, has visto el cuadrante mágico de Gartner para el mundo SIEM de 2014?
En esta entrega vamos a conectar nuestro sistema Snort externo a OSSIM. Aunque la distribución OSSIM trae por defecto snort y suricata para la recolección de eventos, por motivos de infraestructura puede que queramos conectar los logs de un sistema snort externo, como pueda ser un VPS, una delegación remota, un segmento de red aislado, etc. El procedimiento es sencillo, aunque deberíamos mejorarlo por tema de perfomance, ahora os cuento. Basícamente lo que hacemos es que configuamos Snort con una salida syslog. Configuramos rsyslog en el servidor snort para que envie al rsyslog de OSSIM. Configuramos el plugin en OSSIM para Snort-Syslog, para que sepa decodificar los eventos. Adicionalmente vamos a crear una política que ejecute un script por cada detección de evento. El script realizará un baneo de la ip que origina el evento, en varios servidores. La configuración de snort para la salida hacia SYSLOG es: alert_syslog output: host = IP: PUERTO, LOG_AUTH LOG_ALERT He detectado que de esta manera añade al syslog local del servidor Snort los logs, en la rama /var/log/messages. En el fichero /etc/rsyslog.conf añadimos el servidor remoto, en nuestro caso, OSSIM, que previamente tiene hechos el nat y la reglas del firewall ya que son dos elementos conectados mediante la red de redes (Internet? ) auth.alert @ip:puerto En esta sección podrás encontrar si cotejas este procedimiento con otros, que la gente hace *.* @. Con esto estaríamos enviando todos los logs del syslog del servidor snort hacia OSSIM, los logs de Snort, y todos los del sistema. De la manera que indico se filtran gran parte de eventos, aunque se puede jugar más con rsyslog para crear un filtro por la palabra Snort. Tampoco es muy preocupante, pero el Performance disminuye ya que tiene que enviar más log. No muy grave.
Esto va a hacer que como mediante el agente OSSEC TAMBIEN INSTALADO EN EL SERVIDOR SNORT, para File Integrity Monitor como vimos en el anterior capítulo, está recolectando y enviando logs a OSSIM de sur /var/log/messages, en OSSIM tendremos duplicado el evento IDS Snort, uno que le viene por OSSEC y otro que enviamos por Rsyslog. Crearemos una regla para excluir esto... Ahora toca el turno de la parte receptora, el servidor OSSIM. En la linea del rsyslog autorizamos la recepción de logs del servidor Snort. *.* @ip snort. Ahora configuramos una regla para que los logs que vengan de Snort, los almacene en un fichero exclusivo. Este fichero será el que indiquemos en el plugin snort-syslog ( el que conoce la estructura del log) para poder leer. vim /etc/rsyslog.d/snortovh.conf : if $ fromhost == '***********' then /var/log/snortovh2.log &~ vim /etc/ossim/agent/plugins/snort_syslog.cfg source=log location=/var/log/snortovh2.log Reiniciamos en ambos servers rsyslog. En Ossim>configuration>deployment>sensor config.>collection añadimos el plugin snort-syslog.
Ya tenemos los eventos en el SIEM.
Has visto las ip que aparecen con un circulo amarillo? recuerdas el post de OTX? eso es una ip maliciosa. Ahora retomamos el post para creación de políticas para nuestros logs, y metemos el evento genérico IDS EVENT que nos viene de /var/log/messages y que no se parsea bien, y lo metemos en una política que me gusta usar llamada "errores_habituales" en la que añado los id de evento que me aparecen, pero no quiero ver en el SIEM. Recuerda que a OSSIM le van a llegar los eventos de Snort por dos vías, por rsyslog y por ossec. Como hemos configurado el plugin que lee snort_syslog para que lea los log del rsyslog, los de ossec aparecen genéricos, por eso los omitimos. Y ahora? Ya tenemos información de lo que pasa en nuestro servidor. Ahora vamos a pasarle la IP a un script por cada evento, para que banee en varios firewalls. No es la mejor opción, pero dada la infraestructura y necesidades del servidor Snort ( es un vps externo) no podemos poner Snort en modo inline, en modo IPS, es decir, que Snort no para los ataques. Las reglas DROP no funcionan, por ejemplo, si está puesto en modo pasivo mediante un port mirroring o span port en un switch. Si un atacante ejecuta un exploit, este se ejecuta, pero lo detecta Snort y banea la ip. Esto es útil para escaneos y herramientas de juacker, ya que si el primer exploit o ataque no es satisfactorio, esa ip se banea. En el caso de usar un ataque mediante la red Tor, la cosa se complica ya que la IP del atacante no será la misma. Para estos casos yo recomiendo unos scripts que se bajan todos los días y se incluyen en iptables con las ip´s de Tor que tienen acceso a tu servidor. En otro capítulo lo hablamos o me lo preguntáis directamente.
Las posibilidades de ejecutar comando por cada detección es increíble, la imaginación al poder. Simplemente tenemos que crear un script en el servidor OSSIM, con la identificación de la shell o lenguaje al principio, como indican las buenas prácticas de scripting, y darle permisos de ejecución. En OSSIM, creamos una política e indicamos que es para todos los eventos de Snort Signature.
Más abajo en Policy Consequences creamos una acción de ejecución de script, y la vinculamos a la política. Debemos hacer un Reload Policies para que quede activa.
Puedes crear un script sencillo que te escriba en un log para probar que funciona. Por ejemplo. #!/bin/sh /bin/echo `/bin/date`: La IP $1 Está atacado >> /tmp/prueba-script.log chmod 755 script.sh También puedes probar a pasarle más argumentos al script, como hacemos cuando la acción es enviar un correo informativo.
OSSIM 14. Rutas de configuración y logs para el trabajo con OSSEC/OSSIM. En el mundo OSSIM- OSSEC no he conseguido encontrar "la biblia" o documento perfecto. Para realizar los procedimientos básicos es mas o menos sencillo encontrar buenas referencias de información, como este humilde blog :-) pero para el trabajo diario es necesario conocer muchos ficheros de configuración y registros para ver que está ocurriendo y poder segmentar. El típico "no me llega los logs" hay que delimitarlo en que parte falla el proceso. He decidido crear este mini post recopilando las rutas y ficheros que para mi son de ayuda en mi día a día. Espero que os guste. Como
comprobar
que
están
llegando
paquetes
de
una
ip
concreta
a
tcpdump -i eth0 -v -w /dev/null 'src ip' OSSEC-Cliente. Configuración general del cliente: /var/ossec/etc/ossec.conf Log del cliente OSSEC: /var/ossec/log/ossec.log Comprobar conectividad con el servidor OSSEC: ncat -u ip-servidor-ossec 1514 OSSEC-Servidor. Comprobación de actividad recibida por un agente concreto. /var/ossec/bin/agent_control -lc * lista los agentes. /var/ossec/bin/agent_control -i 002 * muestra la información.
Controlar los últimos cambios en ficheros detectados por Syscheckd (útil para el FIM) /var/ossec/bin/syscheck_control -i agente Ampliar detalles de cambios sobre un fichero concreto /var/ossec/bin/syscheck_control -i agente -f /ruta/fichero_modificado
un
servidor:
Comando de servicio para el servidor OSSEC. /var/ossec/bin/ossec-control {start|stop|restart|status|enable|disable} Logs para ver la estadística de eventos por un día. El formato es por cada dia un fichero, dentro: Hora, SID, LEVEL, y las veces que se ha producido. Al final del fichero tenemos el resumen: /var/ossec/stats/totals/2014/Sep/ossec-totals-01.log
Comprobar si recibes datos desde clientes ossec al puerto 1514. tcpdump -i eth0 port 1514
OSSIM-Servidor. Actividad de los agentes hacia OSSIM: /var/log/agent.log Actualizar la versión de OSSIM desde consola, no desde el GUI: alienvault-update -c -v -d Reinicio de servicios.
OSSIM 16. Update Openvas y conexión con servidor externo vía OMP. En el episodio de OSSIM de hoy vamos a realizar algunas operaciones cotidianas en el mantenimiento de OPENVAS y resolución de problemas básicos, pero solo aspectos relativos a OSSIM. También vamos a conectar un OPENVAS existente en otro servidor a nuestra consola OSSIM. Lo primero que vamos a hacer es actualizar la base de datos de firmas o plugins por el interfaz gráfico. Recuerda tener siempre actualizado tu "hacker-kmow-how" para las amenazas recientes.
Otra manera de realizar la actualización de firmas de Openvas es mediante la consola, siguiendo estas sencillas instrucciones.
Si estás acostumbrado a usar OPENVAS en cualquiera otra distribución sabrás que la base de datos de firmas se suele corromper, sobre todo tras actualizaciones ( de Openvas o el propio OSSIM). La solución es sencilla, regenerarla. openvasmd --rebuild /etc/init.d/openvas-scanner restart /etc/init.d/openvas-manager restart /etc/init.d/openvas-administrator restart Como es lógico, en este punto del artículo estás pensando ¿ via Cron? por supuesto caballero/Señora !!! openvas-nvt-sync --wget /etc/init.d/openvas-scanner restart perl /usr/share/ossim/scripts/vulnmeter/updateplugins.pl update Lo hagas de la manera que lo hagas, dedícale un buen rato a la tarea, quizás por encima de los 30 minutos. Una de las cuestiones que se presentan con Openvas OSSIM es la configuración y personalización. Puede que en tu despliegue tengas un servidor OPENVAS previamente configurado con usuarios y políticas y quieras integrarlo en OSSIM, simplemente para tener la información de seguridad centralizada, SIEM !!!! Lo primero que haremos es desde OSSIM comprobar que tenemos conectividad con nuestro servidor OPENVAS mediante el comando OMP. omp -h servidor -p 9390 ( puedes omitir puerto) -u usuario -w clave -g ( man omp da una lista completa de comandos. con g listamos los tipos de scans configurados). Una vez detectado el problema de firewall/nat/unicornios en OSSIM agregamos un nuevo sensor. Sería el mismo procedimiento que efectuaríamos en el caso de instalar un sensor remoto OSSIM ( segunda opción en el menú de instalación del fichero .ISO).
Es curioso que lo creamos por defecto, pero tenemos que modificarlo para indicarle que va a ser VulnScan. De esta manera podemos manejar nuestro Openvas Remoto sin tener que recrear toda la configuración existente en OSSIM.
OSSIM 17. PCI DDS
En esta ocasión vamos a hablar de una de esas normas relacionadas con la seguridad, y que sospecho que no todo el mundo es conocedor de ella.
PCI
DDS:
Payment
Card
Industry
Data
Security
Standard. Norma
en
castellano.
A resumidas cuentas se trata de una norma internacional para aplicar a TODOS los agentes que intervienen en transacciones comerciales via internet mediante tarjetas de crédito/débito. Resalto
TODOS ya que existe la falsa sensación entre la comunidad de que esta norma solo es aplicable si almacenas datos bancarios de clientes (e-commerce) y si usas la típica pasarela de pago de tu banco (tpv virtual) estás exento de aplicarla. Nada mas lejos de la realidad. Lo que si es cierto es que existen varias niveles o modalidades a aplicar según la categoría de uso en la que te encuentres: no son las mismas medidas de seguridad a aplicar las que debe cumplir un banco, que una tienda online de barrio, pero en ambos casos existe normativa. Algo parecido a los niveles de seguridad de la española LOPD ( Ley Orgánica de protección de datos). El objetivo de este artículo no es destripar la norma, sino darle un enfoque práctico. Suelo leer varios blogs de seguridad "organizativa" o "none-tech" que dedican sendos posts a la "seguridad". Suelo ser de los que piensa que un buen responsable de seguridad o CISO debe tener tanto el aspecto técnico como el aspecto organizativo. No deberías ser consultor en seguridad si no sabes lanzar un NMAP, al igual que no deberías ser un CISO si no conces la legislación y normas que nos rodean. Prefiero el segundo caso dado mi pasión por la tecnología. Tengo que decir sobre esta norma y su respectiva certificación algo que suelo decir para el resto de certificaciones, ya sean tipo ISO o tipo producto ( MCSE, VMWARE, CISCO, etc). Tener la certificación PCI-DDS no te proporciona seguridad, pero tener seguridad si que te proporciona poder optar a la certificación. Quiero decir con esto que lo importante no es la certificación en si, sino el trabajo que subyace para obtenerla. Si el trabajo ha sido pagar a una consultora, osea nulo, no tiene ningún sentido, mas el puro tramite de cumplir unas exigencias de cara a clientes/proveedores.
Entonces por qué habla de esta norma, cuando lo que realmente importa es la seguridad subyacente? Sencillo. Vamos a comentar los 12 aspectos principales que ocupan la PCI -DSS.( via wikipedia) •
Desarrollar y Mantener una Red Segura
• Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los propietarios de tarjetas.
• Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad predeterminados provistos por los proveedores.
•
Proteger los Datos de los propietarios de tarjetas.
•
Requisito 3: Proteger los datos almacenados de los propietarios de tarjetas.
•
Requisito 4: Cifrar los datos de los propietarios de tarjetas e información confidencial transmitida a través de redes públicas abiertas.
• Mantener un Programa de Gestión de Vulnerabilidades • Requisito 5: Usar y actualizar regularmente un software antivirus. •
Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguras.
•
Implementar Medidas sólidas de control de acceso
•
Requisito 7: Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información.
•
Requisito 8: Asignar una identificación única a cada persona que tenga acceso a un computador.
•
Requisito 9: Restringir el acceso físico a los datos de los propietarios de tarjetas.
•
Monitorizar y probar regularmente las redes
•
Requisito 10: Rastrear y monitorizar todo el acceso a los recursos de la red y datos de los propietarios de tarjetas.
•
Requisito 11: Probar regularmente los sistemas y procesos de seguridad.
• Mantener una Política de Seguridad de la Información •
Requisito 12: Mantener una política que contemple la seguridad de la información Aunque suelen sonar a las típicas medidas de seguridad de la gente que "speak security" pero no las practican, nada mas lejos de la realidad te pregunto ¿ En tu organización, use tarjetas de crédito o no, implementa TODAS estas medidas?. Este informe de Forbes con las 6 causas de fallo en las implementaciones de PCI te puede servir de ayuda para aclarar los conceptos mentales que empiezas a barajar :-) Puede ser una buena ayuda para el departamento IT estas norma para impulsar la compra de material o servicios relacionados con la seguridad. Que tu jefe no piense que quieres un firewall para jugar o para llevarte una comisión. Bueno, después de esta mini introducción vamos a ver que relación guarda con OSSIM. La consola SIEM de OSSIM nos permite realizar varias de las acciones requeridas en la norma PCI DDS pero de momento, solo en versión 2.0. La actual norma versiona 3.0. Sospecho que la versión de pago AlienVault USM si adapta los requisitos a la norma 3.
También podríamos validar ciertos aspectos de la ISO 27001 pero le tengo manía. Por varias razones, pero principalmente por dos: por cobrar por descargar la norma y por la cantidad de empresas que venden seguridad cuando venden papeles. Principalmente OSSIM lo que hace es comprobar el manejo de cada una de las áreas en base a los eventos que tiene. Por ejemplo, si tiene eventos de nuevo host descubierto porque tenemos Nagios activado y buscando cada cierto tiempo, entiende que cumplimos esa norma. En el caso de que nos aparezca un campo sin comprobar, podemos vincularle un evento concreto para que sepa que cumplimos con esa parte de la norma gracias a esos eventos que añadimos. Recuerda que esto es una guia orientativa del estado de tu cumplimiento PCI DDS, no es una herramienta completa que te "regale" la norma. Lo que si es cierto es que contamos con alugnos Reports preconfigurados válidos para apoyar la norma.
Podemos aglutinar las 12 grandes normas PCI en 6 respecto a OSSIM:
• Gestión de activos. Mediante las opciones de ASSETS e INVENTORY de OSSIM podemos descubrir, identificar y monitorizar nuestros activos, algo básico en todo esto. Debemos saber que tenemos que asegurar, pero de manera dinámica, no basta con un inventario "estático" de hace un año, sin actualizar.
• Análisis de vulnerabilidades. Mediante la integración de Openvas en OSSIM podemos programar auditorias de vulnarabilidades tal y como indica la norma. Hago ENFASIS en que no es lo mismo un Vuln Scan. que un Pen Test que luego me critcaís por ahí xD. Lo vimos aquí y aquí.
• Detección de amenazas. Mediante el uso de sistemas HIDS/IDS y la monitorización de ficheros podemos realizar este punto perfectamente con OSSIM, como hemos visto en los artículos de Snort y OSSEC File Integrity.
• Monitorización. La base de OSSIM es la monitorización de logs, mediante plugins OSSIM o mediante OSSEC. PCI DDS tmbien hace hincapié en la monitorización de servicios/aplicaciones y flujo de red. •
Inteligencia. El motor de inteligencia OSSIM proporciona correlación de eventos de distintas fuentes para proporcionar algo más que visionado de logs, inteligencia. El típico ejemplo: si detectas intentos de login a un servidor SSH ( log ssh) y se produce una ejecución de comandos elevada desde la misma ip ( log kernel) y se abre un puerto ( log de servicios ) vistos en conjunto es una alarma, visto por separado son simples logs de actividad.
•
Revisión. La consola de OSSIM nos permite revisar todos los puntos anteriores e implementar medidas para la solución. No todo es oro lo que reduce, y debemos ser conocedores de la norma en profundidad para poder realizar o aprovechar sus beneficios. Un ejemplo claro de la norma: 10.7 Conserve el historial de pistas de auditorías durante, al menos, un año,con un mínimo de disponibilidad para análisis de tres meses (por ejemplo, en línea, archivados o recuperables para la realización de copias de seguridad).
La versión gratuita de AlienVault, OSSIM solo permite guardar XXX registros, por lo que debemos jugar con una estrategia de consolidación de logs mediante el reenvio de información hacia un syslog pasivo. En otro post os explicaré como podéis realizarlo mediante Tablas Sql y mediante ejecución de scripts. Un informe cualquiera de fugas de información, como pueda ser este de Verizon indica que:
1. 79% de las víctimas fue por razones oportunistas. Esto quiere decir que no es lo mismo hacer un google hack y buscar servidores "facilones" que buscar la manera de entrar en un sistema concreto. Esta parte tiene mucho de concienciación. 2. 96% de los ataques no fueron de alto valor técnico. Es decir, buscar una sql inyection en un portal para sacar la información no tiene mucho componente técnico, por lo que lo puede llevar a cabo mucha más gente. Ese 4% es el que preocupa :-). 3. 94% de los datos provenía de servidores, y no de malas prácticas por parte de usuarios ( client side). 4. 85% de los incidentes fueron detectados pasadas semanas, es decir, cuando el daño ya está hecho y tenemos menos medidas para mitigarlo. 5. 92% de los incidentes fue descubierto por terceras partes, es decir cuando aparecen en un foro, en un defacement o un servicio de monitorización externo. Este punto hace evidente la necesidad de saber el estado de tus sistemas, y no confiar en el appliance de 1000$ o 10000$ sino en una estrategia global que contemple todos los vectores de ataque. 6. 97% de los incidentes podrían ser evitados con medidas sencillas. Tirón de orejas para el CISO !!! 7. 96% de las víctimas de incidentes NO tenían una política real de cumplimiento PCI. Insisto en el comienzo, tenerla no garantiza nada, pero este dato es muy revelador.
OSSIM 18. Capturas de red.
Usar una tool en linea como tcpdump o gráfica como wireshark es tu decisión, pero debes estar familiarizado con los ficheros pcap de capturas y saber leer entre líneas lo que ocurre en tu red. Una de las comodidades que nos ofrece OSSIM es poder capturar, visualizar o descargar capturas de red entre dispositivos. Muy útil para la parte de configuración de OSSIM, pero realmente útil a la hora de detectar un incidente de seguridad, mediante los eventos, y poder ampliar la información mediante la captura de datos y posterior análisis. Desde la versión Free ( no el USM de Alient Vault) no he podido vincular la captura de red teniendo como desencadenante un evento. Solo he podido capturar manualmente, pero no está nada mal. Las teclas del piano son tan sencillas como click, click, click.
Es muy cómodo poder filtrar la captura desde origen y destino.
Podemos descargar el fichero o visualizarlo in situ.
OSSIM 19. El poder de la correlación. ejemplo iptables denial of services Hemos visto muchos usos de OSSIM relacionados con la seguridad, pero momento no deja de ser un Syslog centralizado, con una interface gráfica, y una serie de herramientas integradas en una distribución. El mundo SIEM ( Gestión de eventos de la seguridad de la información) es toda una disciplina dentro de la seguridad, al igual que el pentesting, reversing, forensic etc. Esta es la opinión de la gente de Gartner sobre el software SIEM para 2014.
Cuando alguien se inicia en este mundo suele empezar con la instalación de una herramienta de logs centralizada en la que observar lo que pasa en su entorno. El principal reto es discriminar los logs de información, identificando cuales son relativos a la seguridad, o la seguridad que yo necesito. Vamos a poner un ejemplo gráfico.
Hay eventos de seguridad, hay logs, es gráfico, pero es un logs de 3 minutos, filtrado por las opciones que me deja el front-end (log-analyzer). Como encontrar un incidente de seguridad más o menos complejo, en un log de 300.000 líneas, para un solo día? Ahí es donde podemos usar el motor de inteligencia de OSSIM. Vamos a trabajar con un supuesto de iptables. Cuando ejecutamos una regla en iptables tenemos la opción de indicar que haga log, creamos dos líneas una para el drop y otra para el log, en orden inverso xD ( si primero bloqueas, no llega al log). Yo tengo activado en OSSIM el PLUGIN que parsea los logs de iptables, que los "entiende", sin tener que hacer uno a medida con regular expressións. Cada vez que iptables bloquea un paquete de una ip por la coincidencia de una regla, crea un log que visualizo en OSSIM.
Esto es mucha información, en unos segundos se nos va a llenar la lista de este evento. El ser humano tiene la capacidad de adaptación, por lo que el segundo día, no haces NADA con los logs, los borras, buscando el log mágico que te de toda la información a un click... Igual que con las alertas de Nagios mal configuradas, el servicio de correo al final es un simple "heart beat" del sistema, si llevas una tarde sin alertas de Nagios es que Nagios está roto, no que todo va bien :-). En el tercer artículo la serie hablábamos de crear una política para incluir los eventos que no nos interesan, o que nos proporcionan poca información, para ocultarlos en el sistema. Una de las opciones que indicamos fue la de no mostrar los eventos en el panel SIEM, pero usarlos en la correlación.
Podemos hacer esto con el evento de arriba de Iptables, que no lo muestre, pero lo use con la inteligencia. Podría haber usado el típico ejemplo de la fuerza bruta: no muestres un login_failed, pero en tres intentos muestra un evento de fuerza bruta. Pero quizás este también os interese. El propósito de mi correlación es detectar amenazas persistentes o ataques de denegación de servicios distribuidos. Si tenemos unas reglas de iptables para cortar ataques, como sabemos que seguimos siendo atacados? Con este log de iptables. Recuerda que son ip´s que están baneadas y aún siguen intentando conectar. Mi correlación va a ser simple, cuando encuentre 50 ocurrencias del log, muestra un evento que diga: Posible DDOS 50 intentos. ** La idea completa es anidar esta correlación con otra correlación. Tener este evento, y que ocurra en más de 50 ip de origen, es un claro síntoma de un ataque DDOS. Para una ip o dos puede ser un bot tonto o un mal hacker. La idea es asociar una serie de medidas de contención automáticas contra un ataques DDOS. ** Entramos en la sección de inteligencia y a continuación Directives.
Podemos ver las directivas que vienen con OSSIM, incluso clonarlas para editarlas a nuestro gusto. Nosotros vamos a por todas y creamos una nueva.
Si leíste la teoría del artículo 10 sobre el cálculo del riesgo, esta parte es obvia.
Elegimos el Data Source del evento, en este caso indicamos que es un evento IPTABLES. A continuación indicamos el evento que queremos que dispare nuestra correlación. Si no indicamos nada la correlación se iniciaría con cualquier evento de esa fuente.
Ahora podemos granular, afinar los orígenes y destinos del evento. Podemos trabajar como siempre en OSSIM con la información de Assets, o incluso con la variables Home_Net.
Podríamos indicar más opciones como tipo de puerto, usar los campos específicos del evento, usuario y contraseña si el evento manejase esta información, etc. Para esta regla no es necesario. Ahora añadimos una acción, que será la ejecución de otra regla. En este caso, crearemos la misma regla que anteriormente, pero modificaremos el número de ocurrencias a 50.
Es importante indicar que la Reliability o la posibilidad de que este evento no sea un falso positivo, un valor que al ejecutar la regla del cálculo del riesgo de un valor por encima de 1, o no nos mostrará la información en el SIEM. Seguro que te has leído la teoría :-) La directiva queda de la siguiente forma:
De esta manera, no tenemos los molestos logs por cada intento de conexión, pero cuando una ip intente 50 veces conectar, nos aparecerá el evento de posible DOS.
/etc/ossim/server/**********************# vim user.xml En otra entrada realizaremos una directiva o correlación que anide otra correlación, y haremos alguna un poco más compleja usando diferentes data sources e incluso ntop. ** por ejemplo podríamos crear una directiva que sea: si encuentra más de un evento snort ( dos por ejemplo) y luego encuentra un login_ok desde la misma ip, alertar de un posible ataque fructuoso. si encuentra un brute force y luego un login de ese mismo usuario, aunque sea de una ip origen distinta... **
OSSIM 20. Wireless IDS Kismet y prueba de concepto de ataque.Parte 1.
Kismet es un sistema de detección de intrusos wireless. No me refiero a monitorizar la red wifi con snort, y detectar los ataques de la red cableada ( brute force, exploit,etc), sino detectar específicamente los ataques que se producen sobre la infraestructura wifi. Para ponernos en situación, mejor leer el manual oficial de Kismet para saber que tipos de ataques detecta, lo que serían las "reglas" de snort/modsec/etc.
NOPROBERESP Fingerprint Probe response packet with 0-length SSID tagged parameter
WVE: Alert name: Alert type: Alert on:
WVE-2006-0064 BSSTIMESTAMP Trend Invalid BSS timestamps indicative of an access point being spoofed.
WVE: Alert name: Alert type: Alert on:
WVE-2005-0019 MSFBCOMSSID Signature MAC src address used as CPU instructions by MSF when
exploiting the Broadcom SSID overflow WVE: Alert name: Alert type: Alert on: Alert name: Alert type: Alert on:
WVE-2006-0071 LONGSSID Signature SSID advertised as greater than IEEE spec of 32 bytes MSFDLINKRATE Signature Beacon frame with over-long 802.11 rates tag containing exploit opcodes
WVE: Alert name: Alert type: Alert on: Alert name: Alert type: Alert on:
WVE-2006-0072 MSFNETGEARBEACON Signature Large beacon frame containing exploit opcodes DISCONCODEINVALID | DEAUTHCODEINVALID Signature Unknown / reserved / invalid reason codes in deauth and disassoc packets
Como puedes observar, son los clásicos ataques Wifi. Para realizar este despliegue he optado por instalar el sniffer wifi, Kismet, en una máquina independiente. El motivo es que OSSIM está instalado sobre Vmware y como todos sabemos, Vmware no es buen amigo de los interfaces Wifi. Es un Kali con una tarjeta de red wifi. La típica máquina P4 2,4ghz 512 Mb. Pero que funciona de lujo. Lo que vamos a hacer es integrar dos "opciones" de Kismet con OSSIM. Una serán las alertas cuando se produzcan los ataques. Otra opción será documentar nuestra infraestructura Wifi obtenida con Kismet, para el inventario de áctivos. Un requisito de la famosa PCI- DSS es monitorizar la red wifi, algo que me parece perfecto. Lo primero que hacemos en el servidor OSSIM es habilitar el tráfico de logs desde el sensor e indicarle la ubicación de los mismos en local:
if $fromhost == 'ip_wids' then /var/log/kismet.log &~
Ahora habilitamos el envio desde el WIDS hacia Ossim:
Service rsyslog restart en ambos extremos. Con esto ya podemos ver los logs del sistema WIDS en ossim mediante un tail a la ruta indicada. El siguiente paso es ejecutar Kismet en el Wids y comprobar que tenemos actividad. /usr/bin/kismet_server -t kismet -f /etc/kismet/kismet.conf 2>&1 | logger -t kismet -p local7.1 Si nos devuelve a bash, no ha funcionado. Vamos a configurar alguna cosa más en el kismet.conf, como: Descomentamos ncsource=wlan0 o cualquiera que sea el nombre de tu adaptador wifi. gps=false. Cambiamos el prefíjo de los logs: logtemplate=/var/log/kismet/%n_%D-%i.%l
Aprovechamos este momento para editar la regla apspoof=Foo... en donde cambiamos el nombre y cambiamos el ssid "Foobar" por el nombre de un ap que esté en nuestro alcance. De esta manera vamos a comprobar que como no hemos cambiado la mac que aparece, al detectar el AP y no coincidir con la mac proporcionada, nos generará una alarma. En el proceso normal de uso debemos añadir una regla por cada AP que tenga un nombre SSID distinto. Si es el mismo, basta con añadir mas direcciones mac mediante una coma.
La alerta generada sería así: Oct 1 08:34:06 localhost kismet: ALERT: APSPOOF Unauthorized device (C8:D7:19:FB:67:01) advertising for SSID 'MySSID', matching APSPOOF rule Foo2 with SSID which may indicate spoofing or impersonation. Lanzamos un ataque DOS Deauth. Comprobamos que Kismet detecta el ataque. airodump-ng wlan0 -> anotamos un bssid y su channel. iwconfig wlan0 channel x > ponemos nuestra tarjeta en el mismo canal. aireplay-ng --deauth 0 -a bssid wlan0
OSSIM 21. Varios usos de la Reputation Data. Firewall, detección de tráfico e inclusión. Hace unos capítulos hablamos aquí sobre OTX, la base de datos de reputación de AlienVault, El resumen es que podemos usar nuestra información de atacantes de la consola OSSIM para contribuir con una base de datos de reputación global, la que podemos usar para nuestras medidas defensivas.
En este capítulo vamos a darle ese uso, el defensivo, y no el meramente documental. El primer uso, el más sencillo, podría ser integrar en nuestro sistema firewall, si lo permite, la lista de direcciones "maliciosas" para que sean baneadas. Este post no trata de eso, ya que cada sistema lo realiza de manera distinta, pero comentar que el fichero está disponible en un formato muy amigable ( tan sencillo como copiar en CSF blocklist, por ejemplo).
La ruta alienvault:/etc/ossim/server/reputation.data El segundo uso que vamos a comentar es la monitorización de nuestros servicios IP en la base de datos. Esto quiere decir que añadimos nuestros equipos públicos, y configuramos una alerta para que en el caso de ser introducidos, por ejemplo por la presencia de malware en algún equipo que
está "trabajando internet", el servicio nos envíe una alerta para poder gestionar la inclusión. Esta configuración la hacemos directamente desde la url de Alienvault, con nuestro usuario.
OSSIM 22. Integración de cuentas Ossim-Active Directory. En el capítulo de hoy de Inseguros dedicado a Ossim, el software libre de Alien Vault para SIEM, vamos a integrar la autenticación de cuentas del portal con nuestro servicio de directorio, en este caso, Active Directory.
La idea es sencilla, creamos un usuario local en Ossim, con el mismo nombre de usuario que la cuenta en Active Directory, e integramos la gestión de contraseñas con AD. En primer lugar vamos a crear nuestro usuario local en Ossim.
También vamos a crear un usuario en nuestro Active Directory con permisos para poder ofrecer este usuario a OSSIM para tener un contexto de seguridad válido para "preguntar" al servicio de directorio sobre las cuentas.
Una vez creado, procedemos a configurar la integración.
Para hacer más fácil la configuración, nos vamos a apoyar de la herramienta Active Directory Explorer de Sys Internals para identificar los nombres de objeto correctamente. Los datos de conexión serán la IP de nuestro Domain Controller, el usuario y password? el que hemos creado en Active Directory para poder consultar el directorio.
Si nos aparece el árbol de AD, es que todo va bien. XD.
Mediante estos pasos hemos localizado el DN (Distinguished name) de la cuenta creada. Copiamos hasta los datos de dominio. "CN=OSSIMservices,CN=Users," Con estos datos, la configuración en OSSIM para la integración quedaría tal que así.
Ahora solo nos queda hacer un log-out e iniciar la sesión en OSSIM con nuestras credenciales de Active Directory.
OSSIM 23. Conectar un OSSIM sensor externo a nuestro servidor por VPN Estimados amigos de Inseguros. Vamos a configurar una sencilla operación. Instalar un sensor OSSIM en un VPS externo a nuestra red, y conectarlo con nuestro actual despliegue de OSSIM de manera segura por VPN. De esta manera podemos usar los plugins de los sistemas que tengamos en esa ubicación, y enviar los eventos al servidor central. Tenemos que descargar una imagen ISO, que nos sirve tanto para instalar el servidor como el sensor. Si tu VPS no trabaja con virtualización, tu me contarás como vas a instalar la ISO :-). Una vez solventado este concepto, procedemos con las pantallas de instalación.
Una vez configurados los datos de red, hemos terminado !!
Ahora viene el proceso. El resumen es que en el servidor Ossim tenemos que acceder por ssh puerto 22 al sensor. En mi caso estaba en un vps, detrás de un firewall, por lo que he tenido que natear en el sensor el puerto 22. El servidor se conecta al sensor, configura el cliente vpn copiando la configuración en /etc/openvpn/ip.conf. El problema es que cuando Ossim copia los datos al cliente, en ese fichero .conf indica la dirección ip de OSSIM server, la interna, por lo que el cliente vpn del sensor intenta conectar a una ip privada... Yo he tenido que cambiar el fichero citado y poner la dirección ip publica de mi server OSSIM, y hacer un nat en el firewall hacia el puerto TCP 33800. Vamos a ello !!! En el servidor principal Ossim, en la consola de administración ejecutamos:
Esta es la red virtual del servidor vpn. el equpo será .1
Ahora seguimos desde el servidor OSSIM y configuramos el VPN client.
Esta ip es la local del sensor OSSIM
Ahora nos conectamos con el sensor Ossim que acabamos de instalar, y seleccionamos:
Esta IP es la del extremo virtual de la vpn del servidor OSSIM. Coincide con la red vpn que hemos configurado unos pasos atrás. Hacemos lo mismo con framework IP. Ahora aplicamos los cambios.
Por último, desde el gui de Ossim añadimos un sensor nuevo, bajo la rama despliegue, e indicamos los datos de ip, que será la interface de túnel del equipo sensor.
El resumen es: SEDE PRINCIPAL: ip publica--->fw/nat 33800-->ossim server. SEDE REMOTA: ip publica-->fw/nat 22 ->> ossim sensor. EN OSSIM SERVER: configurar la opcion vpn server y cliente. ( por defecto 10.67.68) EN OSSIM SENSOR: configurar las direcciones de server y framework con la ip del tunel. (por defecto 10.67.68.1) Editar el fichero /etc/openvpn/ip.conf con la dirección ip pública del servidor OSSIM. /etc/init.d/openvpn restart. EN OSSIM SERVER GUI: añadir el sensor con la ip del túnel, del extremo del sensor. ( por defecto 10.67.68.12)
OSSIM 24. AlienVault OTX 2 beta. La red social de moda entre los analistas Hoy os voy a contar una iniciativa muy interesante organizada por Alien Vault denominada OTX 2. En este mismo artículo o en este hemos hablado del uso de la base de datos de reputación que nos proporciona Alien Vault con el servicio OTX.
Hace unos meses me inscribí en un programa para participar en la beta de la versión 2 y hoy mismo he recibido el login y me gustaría contar que he visto :-)
La idea es una "red social" porque hay usuarios y se puede tener un avatar :-) en la que la gente comparte su información de amenazas detectadas en formato abierto, en concreto para mi uso OpenIOC 1.1. Podemos apuntarnos en la beta aquí. Una vez proporcionados los datos de acceso, la pantalla inicial muestra este aspecto:
Como podéis ver, hay un "muro" con toda la actividad publicada, y podemos visualizar solo la de nuestros sindicados, nuestros "gurus" en los que confiamos. Este punto es muy importante, ya que no hay un sistema que impida que yo publique una ip como maliciosa y todo el mundo incorpore a sus sistemas un bloqueo o alerta. Debemos ser nosotros los que seleccionamos aquellos analistas o fuentes de información en las que confiamos.
Crear un nuevo Pulse como ellos lo denominan es muy sencillo. Podéis observar los datos necesarios.
La opción más interesante sin duda para mi es la de poder descargar los registros en distintos formatos, como OpenIoc.
-Malvertising from Google advertisementsMalvertising from Google advertisementsAlienVault - Alienvault OTX2015-07-20T10:58:50 - http://blog.fox-it.com/2015/04/07/liveblog-malvertising-fromgoogle-advertisements-via-possibly-compromised-reseller/ https://otx.alienvault.com/pulse/ 5524271d13432a714ff499f1 -
- -banking.techpool.org -alfiantoys.com/wp-news.php -foley.go2lightuniversity.com -soaring.betsystemreviews.com -supervision.sactown.us -banking.techpool.org -85.143.217.196 -174.36.217.82 Disponemos de una API en Java y en Python para automatizar la lectura-descarga-publicación de contenidos. Poco más que decir de otra buena iniciativa de la gente de Alien Vault que pone a disposición gratuitamente para la comunidad.
OSSIM 25. OTX2 Subscribe o Follow. Como vimos en el último capítulo de Ossim 24, OTX2, seguimos trabajando con esta estupenda iniciativa de la gente de Alien Vault.
En la pestaña de configuración de nuestro AlienVault/Ossim podemos activar la api-key de nuestro usuario de OTX2.
Bajo este punto añadir la diferencia que existe entre subscripción a un usuario o seguirlo. En el primer caso, toda la información publicada por el usuario en la red OTX2 se incorporará a nuestros sistemas de seguridad USM/OSSIM, mientras que si seguimos al usuario simplemente tendremos organizados nuestros usuarios "favoritos". Podemos subscribir tanto a un usuario como SOLO a un "pulse" o registro. Esto es recomendable ya que aunque confiemos en una fuente, no siempre nos interesa la información que publica.
Cada 15 minutos podemos ver en nuestro USM/OSSIM como los datos publicados en OTX2 se incorporan a nuestro SIEM.
Tip&Tricks: Instalar Ossim sobre Xen Server Si por cualquiera de las razones, has decidido instalar Ossim sobre un servidor Xen, piensalo dos veces !! :-) Aún estás a tiempo de instalarlo en un Hypervisor bueno, pero...si lo haces... recuerda marcar la máquina virtual como Template Windows 7 o tendrás problemas con la instalación de Grub. Más bien no se instalará.
Al parecer es debido a un problema en la nomenclatura del disco, pero con este pequeño bricoconsejo- te ahorras la búsqueda en Google. O... quizás ya has buscado en google Como instalar Ossim en Xen Server?
OSSIM 26. Análisis de boletines Microsoft en sistemas Openvas-Ossim. Credenciales !!! Estimados amigos de Inseguros !!! Vamos a dar otro pequeño artículo de la serie OSSIM En esta ocasión vamos a dar a los lectores un pequeño truco para realizar un tipo de análisis bastante útil en algunos procesos de auditoria, generalmente del tipo Compliance, o simplemente para control interno del departamento. Como todos sabéis, mantener los sistemas operativos actualizados es un MUST en la seguridad.
En esta blog hemos hablado largo y tendido sobre ello, incluso de herramientas para comprobar las actualizaciones, como MBSA. En esta ocasión vamos a aprovechar una de las funciones que nos ofrece OSSIM para el análisis de Vulnerabilidades mediante OpenVas. La idea es crear un perfil de análisis, pero en vez de usar los plugins típicos, vamos a seleccionar los plugins de comprobación de actualizaciones de Microsoft, vamos a configurar un usuario y contraseña válido en el dominio, y vamos a comprobar los resultados. Comenzamos con la configuración del Profile o perfil del escaneo.
Como se aprecia en las capturas, creamos un perfil habilitando solo la familia de plugins relativa a los boletines de seguridad de Microsoft. Ahora iniciamos el proceso de configuración de credenciales.
Como puedes ver, se pueden proporcionar credenciales para SSH y SMB. Si necesitas credenciales para otro tipo de análisis, como pueda ser un usuario FTP o un usuario POP3 deberías configurarlo en la parte del plugin concreto. No es el caso.
Una vez configurada la autenticación podemos comprobarla si elegimos un equipo.
Una vez configuradas las credenciales, podemos crear un nuevo trabajo de escaneo normal.
Elegimos el perfil que hemos creado, y pinchamos avanzadas para proporcionarle un juego de usuario/password
Una vez terminado el análisis, vamos a comprobar alguna de las "vulnerabilidades" que nos presenta el sistema.
El color púrpura, lila, violeta, o como diga mi mujer que se llama... no es decisión mia, es debido a la criticidad de la "vulnerabilidad". Si programamos un análisis completo de la red, digamos... dos días después del ciclo de
actualizaciones clásico de los servidores Windows (segundo martes de cada mes) podemos tener un buen punto de vista del estado de las actualizaciones.
En entornos empresariales se suele usar un sistema WSUS que contiene sus propios reports, pero no todo el mundo instala el complemento en el servidor, y tener otra perspectiva, digamos "aparte" del área de sistemas, y mas focalizada para el SOC o el departamento/responsable de seguridad, nunca está de mal.
OSSIM 27. Mamá, he roto OSSIM... Backups En esta ocasión vamos a trabajar un poco con las opciones de configuración y backups. El producto OSSIM en la versión de software libre, no se en la de pago, suele ser algo "inestable" por no decir otra cosa con algunas situaciones. Bien sea porque nos quedamos sin disco, o por un corte de corriente, mala actualización, y demás situaciones no-friendly para el sysdamin, la base de datos se suele corromper, o se puede corromper, tampoco voy a criticar este producto GRATUITO. Lo que si sabéis todos los que lo estáis usando, es que antes de hacer algún cambio importante o update, mejor hacer un snapshot o copia de seguridad potente. El sistema hasta la versión 5.2.4 realizaba una copia de seguridad automática de la configuración del sistema, desde las políticas, assets, configuración de openvas, usuarios, TODO. La ubicación de las copias de seguridad se solía hacer en /var/alienvault/backup/ Si actualizaste a la versión 5.2.5, sin leer, como suele ser el caso :-) habrás notado que ya no se están realizando backups automáticos y el sistema nos invita amablemente a introducir una clave de seguridad para los backups, un punto más de seguridad en nuestros despliegues.
El procedimiento es tan sencillo como este.
Si alguna vez se nos va la base de datos, tenemos que tener en cuenta una cuestión. Si actualizamos el servidor OSSIM no podemos restaurar la configuración de una versión previa. El otro día me paso eso, que me petó la BBDD, pensé que actualizando se arreglaría, y me vi en la situación de no poder restaurar la configuración por ser de una versión anterior. Todo el OSSIM de años perdido...
Me puse a pensar como loco, porque ya no fumo :-) y pensé: si en en /etc/ossim/ossim_setup.conf tengo la clave de la BBDD mysql de OSSIM y tengo los ficheros .sql, por qué no los lanzó a ver si la actualización no ha tocado mucha definición de tablas, y salgo del paso? Correcto, ejecute el dump de mysql de todos los ficheros .sql y volví a respirar. Si vas a hacerlo uno a uno (son muchos) me parece bien, yo pensé en hacer un cat *.sql | mysql -u adasd..... y funcionó. Aprovecha también para introducir estos ficheros en tu sistema de backups de disco general. Si exportas la configuración a otro servidor salvarás los "muebles" en caso de que se rompa el disco y no puedas acceder localmente a la copia de seguridad... Espero que sea estable la solución, aunque imagino que en la próxima actualización me tocará lidiar con las tablas del mysql... De momento tengo SIEM. Realmente tengo copias de seguridad de la máquina, pero quería probar estas pequeñas historias para cuando todo falla.
