10 noviembre 2010

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.

1 comments :

Gonzalo Asensio dijo...

Interesante Lorenzo!

Ya que generalmente el problema es o bien que no se sabe/conoce que es importante "loggear" o bien se "pilla" todo y se vuelve inmanejable.

Yo matizaría algunos puntos sobre los eventos en general:

a) Lo primero que hay que tener es un buen inventario de activos, con su BIA y en función de la criticidad de cada uno, definir que tipos de logs en las categorías tradicionales de seguridad (CIA), entra cada evento, porque y para que.
b) Esto nos ayudará a centrar el tiro en lo importante, ya que lo segundo que debemos hacer es filtrar en origen los logs (el medio cada uno que valore el mejor o el que se pueda) esto nos ayudará a tener sólo lo que queremos analizar.

A esos informes yo añadiría algunos puntos básicos que ayudan a afinar:
* Login incorrectos sólo de cuentas privilegiadas y conocidas de activos críticos.
* Login de cuentas privilegiadas desde ip's distintas a los administradores de dichos activos.
* Disponibilidad de los orígenes (para saber si no están llegando eventos)
* Control de borrado o modificación de los logs de los activos.
* Dispositivos I/O "pinchados y despinchados"
* Y en BBDD algo más específicos para auditar objetos que son críticos para el negocio

c) Como todo en seguridad intentar llevar este tema como un proceso más dentro de la organización, en el que este definido por cada evento y activo, la criticidad del mismo, tiempos de respuesta y resolución.

...si esto se consigue dentro de una organización y el proceso arranca y funciona, entones ya se podrá "empezar" a "intentar" hacer magia de correlación "seudocientifica" (evento de ataque de la IPS, junto a creación de cuenta, escalada de privilegios, más modificación de la BBDD, intentos de login dentro del mismo segmento, además el nessus dice que ese activo es vulnerable, el AV canta un bicho y encima vemos tráfico raro saliente .... "y la luna");P

Un saludo,