SYSLOG CENTRALIZADO CON DETECCION DE EVENTOS

Transcripción

1 SYSLOG CENTRALIZADO CON DETECCION DE EVENTOS Norberto Altalef RedKlee Argentina Alcances Se describirá en el presente documento la implementación de un sistema de syslog centralizado con detección de eventos y generación de distintos tipos de alarmas. Todo el sistema está basado en herramientas Open Source. Se detallarán las herramientas utilizadas, así como detalles de su configuración y ejemplos reales de aplicación. Generalidades de un sistema de log. Log es el registro de acciones y eventos que tienen lugar en un sistema. Los logs son el primer registro de la actividad en los sistemas y redes. Los logs de un sistema son una parte primaria de la seguridad y pueden ser usados en la detección de ataques e intrusiones, así como en el análisis de fallas de hardware y software. El programa syslog, es una interface que provee un framework standard para que tanto programas como el mismo sistema operativo puedan generar mensajes que peuden ser almacenados localmente o ser enviados a un host remoto. Originalmente escrito para Unix, se convirtió en un standard que se usa en muchos sistemas operativos y dispositivos de red. Cual es la utilidad de un sistema de syslog centralizado? En un sistema de syslog centralizado, un server común recibe todos los mensajes de syslog de todos los sistemas de la red. Esto incluye logs de los servers Unix/linux/Windows etc, firewalls, y dispositivos de red (routers, switches, etc) Hay varias ventajas de un sistema de syslog centralizado El syslog puede ser conectado en un segmento de red diferente protegido por un firewall para mantener más segura la información Teniendo los mensajes de todos los equipos, puede hacerse una correlación de ataques o fallas en distintos puntos de una manera mucho más sencilla. Por ejemplo si en el syslog aparece un mensaje de desconexión de la interface de red de varios servers en el mismo Syslog Centralizado Página 1 de 16

2 momento, es lógico suponer una falla en el switch donde estos servers estan conectados. Un usuario no deseado que haya ingresado en un server, no podrá alterar los mensajes que se hayan almacenado en el server central. Se pueden generar alertas usando sistemas de monitoreo de logs. Sistema de monitoreo de logs El análisis de logs es una herramienta muy importante para mantener el control de servers y dispositivos de red. Sin embargo esta es una de las tareas que más tiempo consume y por consiguiente que menos se hace. Con la cantidad de mensajes informativos que se generan en un sistema de log, detectar en forma manual los mensajes de problemas es muy dificultoso y con mucha probabilidad de error. Esto se vé aumentado cuando se usa un sistema de syslog centralizado, donde la información proviene de varias fuentes distintas. Muchas soluciones de monitoreo se basan en sumarizar la información de archivos de log de dias previos. Esto es muy útil para la generación de estadísticas y análisis posterior a una falla o intrusión, pero no tanto para la resolución de problemas. Un administrador no puede actuar en forma proactiva, previamente a que el error ocurra. Muchas fallas o accesos no autorizados se ven precedidos por mensajes que de haber sido detectados, podrían haber permitido tomar acciones preventivas. Por ejemplo, un acceso no autorizado via ssh, puede haber estado precedido por una gran cantidad de intentos fallidos de acceso. Disponer una solución on line de monitoreo, permite disponer de herramientas que pueden ayudar a prevenir problemas graves antes que ocurran. Detectar eventos en el momento que ocurren permite generar acciones en ese mismo instante y no luego de las consecuencias. Siguiendo con el ejemplo del acceso ssh, podría bloquearse el acceso ssh desde determinada Syslog Centralizado Página 2 de 16

3 dirección IP despues de un número de intentos fallidos de acceso. Un concepto que aparece aquí es el de correlación de eventos. Un sistema automatizado de análisis de logs que pueda hacer una correlación de varios eventos simplifica y acelera el monitoreo de eventos consolidando alertas y mensajes de error en un mensaje más corto y fácil de entender. Una serie de operaciones están relacionadas con la correlación de eventos. Compresión toma varias apariciones del mismo evento y se examina la duplicación de información, se remueve las redundacias y se reporta como un único evento. De esta manera 1000 mensajes "route failed" se convierte en un único alerta que dice "route failed 1000 times" Recuento reporta un número específico de eventos similares como uno solo. Esto se diferencia de la compresión en que no solo cuenta en que sea el mismo evento, sino que se supere un determinado umbral para generar un reporte. Supresión asocia prioridades con alarmas y permite que el sistema suprima un alarma de prioridad más baja si ha ocurrido un evento de prioridad mayor. Generalización asocia alarmas con eventos de más alto nivel que son los que son reportados. Esto puede ser útil para por ejemplo para correlacionar eventos de múltiples discos de un array. No se necesita ver cada mensaje específico si se puede determinar que el array completo tiene problemas. Correlación basada en tiempo puede ser útil estableciendo causalidad. A menudo una información puede ser obtenida relacionando eventos que tienen una relación temporal específica. Ejemplos genéricos: El Evento A está seguido del Evento B. Este es el primer Evento A desde el Evento B reciente. El Evento A sigue al Evento B dentro de los dos minutos. El Evento A no fue observado dentro del Intervalo I. Implementación Se detallará a continuación la implementación real de un sistema de syslog centralizado junto con un sistema de monitoreo on line de los logs. La instalación tuvo los siguientes requisitos: Concentrar los logs de un server que corre HPUX, un firewall que corre Linux y un sistema de Syslog Centralizado Página 3 de 16

4 detección de intrusos (IDS) usando snort que corre en Linux. Los mensajes del sistema que corre HPUX eran provenientes del sistema operativo y de una aplicación específica. Debian generarse alarmas para determinados eventos. Se debía disponer de una manera de consultar los logs y realizar búsquedas en ellos. Para armar este sistema se tomaron en cuenta los siguientes aspectos: Sistema operativo: se utilizó Debian GNU/Linux. La decisión estuvo basada en el conocimiento y experiencia con esta distribución, así como la reconocida estabilidad y facilidad de actualización. Sin embargo, la solución podría perfectamente adaptarse a otra distribución. Syslog: si bien el daemon de syslog standard de Linux (syslogd) es adecuado para concentrar información de otros syslog, se decidió utilizar syslog ng (syslog new generation) que es un reempazo directo de syslog. El syslog original permite que los mensajes sean organizados basandose en los pares priority/facility; syslog ng agrega la posibilidad de filtrar basandose en el contenido de los mensajes usando expresiones regulares. syslog ng permite guardar los mensajes en un base de datos y tambien usar TCP en lugar de UDP para enviar los mensajes a otro server. Base de datos: para facilitar las posteriores consultas se decidió almacenar los mensajes en una base de datos MySQL. Consulta de logs: se usó como base un producto denominado php syslog ng, que se modificó para tener más opciones de consulta.. Monitoreo de logs: se utilizó un producto llamado SEC (Simple Event Correlator). En el siguiente observan los componentes del sistema. Syslog Centralizado Página 4 de 16

5 Algunos detalles de este esquema: Los hosts envian sus mensajes al server de syslog, a través del protocolo UDP. No se usó TCP, porque se decidió no instalar syslog ng en los servers HPUX. Se guarda la información de cada server en distintos archivos, para facilitar las reglas de SEC posteriores. En syslog ng no se hace ningún filtrado y se guardan todos los mensajes. El proceso SEC está monitoreando en forma continua estos archivos generados por syslog ng. Existen dos bases de datos a las que SEC tiene acceso. Una base de datos de alarmas y una base de datos de logs. Estas bases de datos pueden ser consultadas desde formularios en forma interactiva o generando reportes estadísticos. En base a distintas reglas de SEC se toman distinto tipo de decisiones, con respecto a los mensajes que se leen de los archivos. Estas decisiones son: 1. Mensaje descartado. Los mensajes que son solo informativos, se descartan y no se almacenan en la base de datos. 2. Mensaje almacenado. Los mensajes que se consideran importantes se almacenan Syslog Centralizado Página 5 de 16

6 en la base de datos de log 3. Alarma. Si hay un evento que genera alguna alarma, se guarda en la base de datos de alarmas. Además de esto, pueden generarse acciones adicionales, tales como enviar un mail o mostrar un mensaje en la consola de monitoreo. Se define una consola de monitoreo, que originalmente se basó en la incluída en phpsyslog ng. En esta consola accesible desde un browser puede elegirse los mensajes de que server se muestran, así como las alarmas que se generan. Detalles de la implementación I syslog ng El paquete syslog ng, puede instalarse usando apt get desde los repositorios de Debian. En otras distribuciones está tambien disponible, sino puede bajarse el códifo fuente desde Toda la configuración se hace en el archivo /etc/syslog ng/syslog ng.conf La ruta que seguirá un mensaje se define con tres posibles secciones, que son source, destination y filtering rules. source: se define el origen de los mensajes (palabra clave: source) El formato es: source <sourcename> { sourcedriver params; sourcedriver params;... }; donde sourcename es un identificador y sourcedriver es el método usado para recibir estos mensajes. Ejemplos: source kernel file("/proc/kmsg" log_prefix("kernel: ")); source net udp; El primer ejemplo indica que los mensajes del kernel se leen desde /proc/kmsg y que se les agrega un prefijo kernel: El segundo ejemplo indica que se habilita la recepción de mensajes a través de conexiones udp. destination: se define el destino de los mensajes (palabra clave: destination) El formato es: Syslog Centralizado Página 6 de 16

7 destination <destname> { destdriver params; destdriver params;... ; }; donde destname es un identificador y destdriver es el método usado para guardar los mensajes. Ejemplos: destination df_mail { file("/var/log/mail.log"); }; destination du_root { usertty("root"); }; El primer ejemplo se define para enviar los mensajes del sistema de mail al archivo /var/log/mail.log El segundo ejemplo se define para enviar mensajes a la tty donde esté conectado root. Estos son solo ejemplos. En ambos casos hay varias opciones adicionales. Consultar man (5) syslog ng.conf, para ver las opciones completas. filtering rules: reglas de filtrado (palabra clave: filter) El formato es: filter <filtername> { expression; }; Donde filtername es el nombre del filtro y expression es una expersión booleana simple. Se puede usar "and", "or" y "not" para conectar las funciones incorporadas. Las funciones pueden ser: facility (una lista separada por comas de nombres de facilities) level (una lista separada por comas o un rango separado por ".." de nombres de priority) program (una expresión regular para buscar coincidencias con nombres de programas) host (una expresión regular para buscar coincidencias con nombres de host match (una expresión regular que busca coincidencias en el mensaje de syuslog en si. Syslog Centralizado Página 7 de 16

8 Sentencias log. Se pueden conectar origenes y destinos, usando sentencias log. El formato es: log { source S1; source S2;... filter F1; filter F2;... destination D1; destination D2;... }; Donde Sx se refiere a uno de los orígenes de log declarados, Fx a uno de los filtros y Dx a uno de los destinos. Veamos un ejemplo: Para loguear los mensajes que se reciben de un server que tiene como nombre amadeus y tiene un IDS (snort). 1 Definimos como origen los mensajes recibidos por udp source s_net { udp(); }; 2 Definimos como destino un archivo llamado /var/log/amadeus.ids.log Adicionalmente se cambia el formato standard de los mensajes, incluyendo el año destination d_amadeus.ids { file("/var/log/amadeus.ids.log" template("$year-$month-$day $WEEKDAY $HOUR:$MIN:$SEC $HOST $FACILITY $PRIORITY $MSG\n") template_escape(no) ); }; 3 Creamos un filtro que seleccione los mensajes recibidos de este server. En este caso snort se configuró para enviar sus mensajes al facility local6. filter f_amadeus.ids { host(amadeus) and facility(local6); }; 3 Por último generamos los mensajes de log log { source(s_net); filter(f_amadeus.ids); Syslog Centralizado Página 8 de 16

9 destination(d_amadeus.ids); }; 2 SEC SEC (Simple Event Corrrelator) es un script en Perl. Está escrito por Risto Vaarandi y su home están en Está pensado para hacer un monitoreo de archivos de log en tiempo real y elegir eventos que se quieran reportar. En SEC se pueden definir y almacenar contextos, que son un juego arbitrario de hechos que describen un evento. Empecemos por un ejemplo básico, para entender el funcionamiento de SEC. Supongamos que queremos controlar los login de root. Cada vez que hay un login de root en un equipo el mensaje de syslog tiene el siguiente formato: Feb 1 11:54: sshd[20994]: [ID auth.info] Accepted publickey for root from port ssh2 Creamos un archivo de configuración (que se llame root.conf) con el siguiente contenido: type=single ptype=regexp pattern=(^.+\d+ \d+:\d+:\d+) (\d+\.\d+\.\d+\.\d+) sshd\[\d+\]: \[.+\] Accepted (.+) for root from (\d+\.\d+\.\d+\.\d+) desc=direct ssh root login on $2 from $4 (via $1 action=add root ssh_$2 $0; report root ssh_$2 /usr/bin/mail s "Login de root en $2 desde $4" admin@ejemplo.com Esto es un ejemplo de una regla de SEC. La primer línea, type, define el tipo de regla, que en este caso es "Single", que le indica que queremos analizar ocurrencias únicas de un evento. La segunda línea, ptype, define como haremos la búsqueda de patrones. En este caso "RegExp" indica que se usarán expresiones regulares de Perl. La próxima linea, pattern, es una expresión regular que va a coincidir con los mensajes de log cuando hay un login de root. Se agrupan la fecha y hora, la IP de origen y la IP de destino. La siguiente linea, desc, es una descripción. Esta descripción identifica explicitamente cada ocurrencia (ver Reglas y operaciones de correlación de eventos) Syslog Centralizado Página 9 de 16

10 La última línea, action, es la acción que se tomará. En este caso se agrega el mensaje completo (identificado como $0) a un contexto denominado root ssh_$2, donde $2 será la IP de origen. Finalmente, se envía un mail con el contenido del contexto. Para ejecutar SEC: sec detach conf=root.conf input=/var/log/messages detach, hace que SEC corra en background conf, indica el archivo de configuración que debe usarse input, especifica el archivo de donde deben leerse los mensajes. Ahora bien, supongamos que hay una tarea de cron que todos los días hace una conexión como root, para ejecutar un proceso y no queremos recibir un mail cada vez que se realiza esta conexión conocida. Lo que se necesita es agregar en el archivo de configuración la regla siguiente antes de la regla anterior. type=suppress ptype=regexp pattern=^.+\d+ \d+:\d+:\d+ \d+\.\d+\.\d+\.\d+ sshd\[\d+\]: \[.+\] Accepted.+ for root from Enviando la señal SIGABRT al proceso SEC se le indica que relea el archivo de configuración y continue. Ahora las conexiones desde , no generarán mensajes de alerta. Siguiendo con ejemplos veamos, una regla de SEC para detectar posibles ataques por fuerza bruta en conexiones ssh. # # crear el contexto en la primera ocurrencia # type=singlewiththreshold ptype=regexp pattern=(^.+\d+ \d+:\d+:\d+) (\d+\.\d+\.\d+\.\d+) sshd\[\d+\]: \[.+\] Failed (.+) for (.*?) from (\d+\.\d+\.\d+\.\d+) desc=posible ataque por fuerza bruta (ssh) usuario $4 en $2 desde $5 window=60 thresh=5 context=!ssh_brute_from_$5 action=create SSH_BRUTE_FROM_$5 60 (report SSH_BRUTE_FROM_$5 /usr/bin/mail s "ataque por fuerza bruta ssh en $2 desde $5" admin@ejemplo.com); add SSH_BRUTE_FROM_$5 Detectados 5 intentos fallidos de ssh en 60 seg; Syslog Centralizado Página 10 de 16

11 add SSH_BRUTE_FROM_$5 $0 # # agregar eventos siguientes al contexto # type=single ptype=regexp pattern=(^.+\d+ \d+:\d+:\d+) (\d+\.\d+\.\d+\.\d+) sshd\[\d+\]: \[.+\] Failed (.+) for (.*?) from (\d+\.\d+\.\d+\.\d+) desc=posible ataque por fuera bruta (ssh) usuario $4 en $2 desde $5 context=ssh_brute_from_$5 action=add SSH_BRUTE_FROM_$5 "Evento adicional: $0"; set SSH_BRUTE_FROM_$5 30 Esto son en realidad dos reglas. La primera regla es otro de los tipos disponibles en SEC: SingleWithThershold. Se agregan dos opciones más a las que tenía Single, que son window y thresh. window es el lapso durante el que esta regla debe estar monitoreando y thresh es el umbral para el número de eventos que es necesario que aparezcan dentro del lapso anterior para disparar la action de esta regla. En este caso la regla ejecutará la acción si hay 5 eventos de login fallido dentro de 60 seg. Se usa tambien la opción de contexto, que indica que la regla se dispara solo si el contexto no existe. La línea de action, crea el contexto ($5 representa la IP de origen) que expira en 60 seg. Una vez que expiró el contexto se envía un mail con una descripción y las lineas de log que fueron detectadas. La segunda regla agrega eventos adicionales al contexto y extiende su tiempo de vida por 30 seg, siempre que este exista. Si no existe no hace nada. La creación de estos contextos que son creados en forma dinámica, es una de las principales caracteristicas de SEC. Por ejemplo una impresora con un papel trabado, puede emitir una gran cantidad de mensajes de log y sería una molestia si se genera un mail por cada mensaje de log. En SEC podría crearse un contexto tal que "se ha visto un evento de papel trabado y ya se ha enviado un mail" de manera que la regla podría en el futuro suprimir el envío de los mails si el contexto existe. SEC incluye otros tipos de reglas. La descripción obtenida directamente del manual es: SingleWithScript buscar coincidencias en los eventos de entrada y ejecutar una acción dependiendo del status de un script externo SingleWithSuppress buscar coincidencias en los eventos de entrada y ejecutar una acción inmediatamente, pero ignorar las siguientes coincidencias durante los próximos t seg. Syslog Centralizado Página 11 de 16

12 Pair buscar coincidencias en los eventos de entrada, ejecutar una acción inmediatamente e ignorar las siguientes coincidiencias, hasta que haya una coincidencia con otro evento distinto. En la coincidencia del segundo evento ejecutar otra acción. PairWithWindow buscar coincidencias en los eventos de entrada y esperar t seg para que aparezca otro evento. Si este evento no se observa dentro de un determinado intervalo se ejecuta una acción y si el evento aparece se ejecuta otra acción. SingleWith2Thresholds buscar coincidencias en los eventos de entrada durante t1 seg y si se supera un dado umbral, ejecutar una acción. Entonces empezar a contar las coincidencias de nuevo y si su número durante t2 seg es menor que un segundo umbral, ejecutar otra acción. Calendar ejecuta una acción en momentos específicos. Reglas y operaciones de correlación de eventos (extraído del manual de SEC) Pese a que cada operación de correlación de eventos se inicia por una regla de SEC, no hay una relación uno a uno entre reglas y operaciones de correlación de eventos, ya que una regla podría iniciar varias operaciones de correlación de eventos que corren simultaneamente. Para distinguir una operación de otra, SEC asigna una clave a cada operación que está compuesta por el nombre de archivo de configuración, el ID de la regla y la descripción del evento derivado del parámetro desc de cada regla, reemplazando cada variable con su valor. Uso de SEC en la implementación. Como se vió antes, en la implementación descripta guarda tanto los mensajes de syslog, como las alarmas en una base de datos MySQL. La interacción entre SEC y MySQL, se hace a través de un archivo de tipo FIFO (pipe). SEC puede escribir a un pipe y luego un proceso que está leyendo este pipe hace los insert correspondientes en la base de datos. Dentro de la base de datos se definieron las siguientes tablas: alarms: alarmas cod_alarms: códigos de alarmas. Se usan para los reportes logs: mensajes de syslog Estructura de la tabla alarms: Syslog Centralizado Página 12 de 16

13 newmsg: se usa para saber si un mensaje ha sido leído o no en la consola de monitoreo screen_dest: define en cual de las zonas de la consola de monitoreo debe mostrarse el mensaje host: server que generó la alarma level: es un código que define la importancia de la alarma date y time: fecha y hora msg: texto del mensaje de alarma seq: indice Estructura de la tabla cod_alarms: cod: código de la alarma rep: indica si el tiop de alarma debe incluirse o no en los reportes des: descripción Estructura de la tabla logs: newmsg: se usa para saber si un mensaje ha sido leído o no en la consola de monitoreo screen_dest: define en cual de las zonas de la consola de monitoreo debe mostrarse el mensaje host: server que generó el mensaje facility: sistema que generó el mensaje (ver syslog) priority: nivel del mensaje (ver syslog) date y time: fecha y hora program: programa que generó el mensaje msg: texto del mensaje seq: indice Estas estructuras se respetan tanto cuando SEC escribe al pipe, como cuando el proceso que lee del pipe hace los insert en la base de datos. El proceso que lee del pipe es una modificación de dbinsert.pl, que es un script usado en Syslog Centralizado Página 13 de 16

14 "Working with SEC The Simple Event Correlator" ( Veamos un ejemplo de una regla que hace un insert en una tabla: # Asignación de variables # Pipe # type=single ptype=regexp pattern=(sec_startup SEC_RESTART SEC_SOFTRESTART) desc=sec Initialization_Pipe context=sec_internal_event action=assign %secdb_pipe /etc/sec/db/secdb.pipe # Generar alarma cuando se presentaron más de 100 mensajes # de cualquier tipo en 1 hora # IDS # type=singlewiththreshold ptype=regexp continue=takenext pattern=(.*) desc=xx eventos en yy minutos IDS window=3600 thresh=100 action=write %secdb_pipe ALR 1 5 amadeus %f %h Más de 100 mensajes en 1 hora IDS Poniendo detalle en la linea action, se observa que SEC vá a escribir al pipe definido en la variable %secdb_pipe, una serie de campos separados por " " El primer campo, no pertenece en realidad a ninguna tabla y es el que le indica al script dbinsert.pl, en que tabla debe hacer el insert. En este caso es ALR indicando que el insert debe hacerse en la tabla alarms. El resto son los campos de la tabla correspondiente. De la misma manera, para guardar un mensaje de syslog (generado en este caso por un programa de usuario): # Fallo al validar la clave # Mensaje en el log # # Fri 10:10:41 gsahp local6 notice gam(ascprec.exe)[28045]: Fallo al validar clave;\ # login= uid=740 euid=740 tty=/dev/pts/tbjrhost=pctuc12 user=tuc00g # Regla type=single Syslog Centralizado Página 14 de 16

15 ptype=regexp pattern=(\s+)\s+\s+\s+(\s+)\s+gsahp\s+local6\s+(\s+)\s+gam\((\s+)\)\[\d+\]\:\s+fallo al validar clave\;\s+(.*) desc=falla de clave sistema comercial action=write %secdb_pipe LOG 1 0 gsahp local6 $3 $1 $2 $4 Fallo al validar clave $5 En este caso el primer campo es LOG, indicando que el insert debe hacerse en la tabla log. Con este esquema, aprovechando la gran potencia de SEC, puede armarse un sistema de monitoreo y alarmas tan complejo y sofisticado como se necesite. No se dispone de una interface gráfica de configuración, por lo que hay que dedicarle un poco de trabajo a armar las reglas. Sin embargo, las potencialidades son muchas. Para ver más ejemplos se recomienda ver la información de SEC, tanto las páginas del manual, como la FAQ y los ejemplos. Hay una colección de reglas en Tambien hay un execelente tutorial en 3 Interface de usuario Una vez que los datos están almacenados en la base de datos es más sencillo, realizar consultas y reportes. Para la aplicación se partió de php syslog ng ( syslog ng) pensado para hacer consultas en una base de datos creada directamente por syslog ng y se adaptó al esquema descripto anteriormente. Un ejemplo de un pantalla de consulta es: En php syslog ng tambien hay una opción para mostrar en tiempo real los mensajes que se ván generando: Syslog Centralizado Página 15 de 16

16 Se muestra acá el resultado de una versión modificada donde dos ventanas con mensajes de syslog de hosts y una tercera con alarmas. En el momento de escribir este documento se está realizando una migración de esta interface a una desarrollada en AJAX. Este conjunto de programas, la mayoría usados sin modificación y puestos juntos a trabajar muestran una de las grandes posibilidades del software libre, que es la de lograr una solución completa a un problema, con muchisimas posiblidades de operación. Valga aclarar que este sistema está funcionando desde mediados del 2005, en una empresa de envergadura, monitoreando varios servers y firewall y se le están continuamente agregando funcionalidades y ha demostrado en más de una vez su utilidad. Norberto Altalef RedKlee Soluciones basadas en Software Libre naltalef@redklee.com.ar Sanchez de Bustamante 635 Buenos Aires Argentina Tel: / Cel: Syslog Centralizado Página 16 de 16