Seleccionando informes de seguridad

Hace poco hablábamos [Sistemas de notificación de eventos ¿renovarse o morir?] de las posibilidades de notificación de eventos que nos permitían conocer las alertas ocurridas en nuestros sistemas por diferentes canales y medios. Sin embargo uno de los puntos más importantes a los que hacíamos referencia en dicho post, es que si notificamos sobre absolutamente todo lo que ocurre en un sistema, sin priorizar lo que realmente es importante, lograremos que los receptores terminen perdiendo el foco y no reaccionando como corresponda.

Curiosamente, navegando por una de las fuentes de sabiduría del mundo de la seguridad informática, la página web del Instituto SANS, dí con un documento [Top 5 Log Reports] sobre los tipos de Informes de seguridad más recomendables a tener en cuenta sobre nuestros sistemas. Me pareció muy interesante no sólo por los eventos elegidos, sino por el desarrollo argumentado de cada uno, a quién notificar, etc,…

No pretendo hacer un copy/translate/paste de dicho documento, pero sí que me gustaría resumirlos y añadir otras recomendaciones a tener en cuenta.

Lógicamente para poder hacer un informe, hay que contar con la información fuente necesaria. Para los más importantes del SANS, habrá que loggear:

• Accesos fallidos mediante cuentas válidas: ¿Quién no ha recibido ataques de fuerza bruta ante servicios expuestos a Internet? SSH, SMTP, POP3, FTP, etc,… Si os configuráis en cada servicio que guarde registro de los intentos de acceso inválidos, veréis como os aparecen más intentos de los que contabais. Para evitarlo, en SSH podemos contar con mecanismos de prevención del tipo port knocking o reactivos como fail2ban; para el servicio SMTP se puede exigir autenticación o POP-Before-SMTP, se puede acotar un rango de IPs internas para enviar correo, mediante acceso previo por VPN y, si no se puede, solicitar a los usuarios ejecutar una política robusta de contraseñas. Por supuesto se pueden desarrollar scripts a medida que lean archivos de log y que correlen dichos eventos generando bloqueos en el cortafuegos del sistema (Si algún lector está muy interesado en esta parte que contacte con nosotros y estaré encantado de darle más detalles)

• Recursos buscados no encontrados: Dada la cantidad de botnets, PCs infectados con malware, que están todo el tiempo barriendo direccionamientos IP en la búsqueda de servidores vulnerables, fuerza bruta como en el punto anterior, para después reportar sus logros al "dueño", los logs de los servidores muestran de todo [El extraño caso de Woot.woot.at.,ISC.SANS.Dfind]. Sí que es verdad es que como indicio de un escaneo de vulnerabilidades o saber que alguien se está molestando en mirar qué tienes y ver por dónde golpearte, es interesante saberlo. Partiendo de la base que, por ejemplo, a partir de la web, todo aquello a lo que quiero dar acceso, es accesible mediante enlaces en la misma, cualquier otra cosa que pidas y no exista, será actividad no deseada: por ello, al menos, regístralo… aunque quizá notificarlo directamente pueda ser demasiado saturante por la cantidad de avisos que se recibirían. La recomendación es fundamentalmente, tener los servicios actualizados, para que los escaneos basados en versiones vulnerables no den positivo a los atacantes.

• Cambios no autorizados a usuarios, grupos y servicios: Tienen que estar muy bien definidos y acotados los usuarios con capacidad de dar y quitar permisos a otros. Serán sospechosas las actividades que se hagan fuera de horarios habituales, usuarios que súbitamente ahora tengan otros roles, temporales, etc,… pero también deben registrarse los cambios que se hagan desde cuentas autorizadas. No sabes si ese power user ha sido sobornado para subir los permisos de otros o si su cuenta ha sido comprometida. Lo mismo cuando ocurre un reinicio/parada/arranque de un servicio. Si observamos que, de forma no controlada, un servicio cambia de estado "el solo", algo raro puede estar pasando.

• Sistemas más vulnerables a ataques: En este caso, más que loggear, habrá que auditar, nuestros sistemas en busca de vulnerabilidades, recibiendo una ponderación según estén más expuestos, gestionen información más o menos crítica, tenga un mayor o menos impacto una posible indisponibilidad del servicio o robo de la información, etc… Pasar auditorías periódicas, proteger los sistemas con dispositivos especializados y por supuesto primar una configuración segura y basada en permitir únicamente lo necesario en cada máquina y deshabilitar o borrar el resto, deberían ser los leitmotivs para que el riesgo se minimice lo máximo posible.

• Patrones de tráfico de red sospechosos o no autorizados: En general, aquello que no conocemos, o que no puede clasificarse según criterios especificados, supone una gran amenaza puesto que no podemos saber si es o no un ataque. En base a esto, el informe que propone el SANS, basado en tráfico de red sospechoso, yo indicaría como algo importante a guardar, información correlada entre diferentes fuentes que generan un único evento que pueda presagiar actividad maliciosa. Ejemplos de este tipo pueden ser actividad por el puerto TCP/25 por máquinas que no gestionan correo electrónico, tráfico por puertos de aplicaciones que no deberían estar permitidas (IRC, P2P,...), etc,… Para protegernos ante este tipo de amenaza, la configuración de los dispositivos de seguridad perimetral deberían estar pensada conociendo palmo a palmo la funcionalidad y necesidades de cada máquina objetivo y permitir estrictamente lo necesario, prohibiendo lo demás. Asimismo, contar con soluciones configuradas en modo anomaly detection puede ayudar a generar informes en los que lo que se observa son patrones que van más allá de lo normal.

Etiquetas: informes , notificación