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.

Leer más...

Sistemas de notificación de eventos ¿Renovarse o morir?

La semana pasada tuve que hacer una presentación en un gran cliente, que en el turno de preguntas, me cuestionaba, como muchos otros clientes, sobre las capacidades de integración y el tipo de mecanismos de notificación que permiten los productos de la empresa en que trabajo, lo cuál demuestra una vez más que, en el momento de adquirir una solución de seguridad, los requisitos de integración de los logs y alertas con las plataformas existentes en la casa, son muy importantes.

Las grandes organizaciones requieren que todos los dispositivos que tengan una IP, desde servidores, electrónica de red, equipos de seguridad y comunicaciones, hasta PCs, impresoras, tostadoras y cafeteras, envíen datos sobre lo que pueden considerar un "evento" a un sitio centralizado. Allí dicha información podrá ser tratada y gestionada convenientemente para priorizarla y comunicarla a quien corresponda según esté definido en la política de responsabilidades de la organización.

Muy de moda están por ello los sistemas de centralización de eventos de seguridad (o SIEM), de los cuáles ya hemos hablado alguna que otra vez en SbD a fin de poder obtener algo útil partiendo de un montón de fuentes que, si tuviéramos que leer todo lo que envían, el resultado sería inútil o nos sobrepasaría por la cantidad de recursos humanos necesarios para procesar tanta información.

Una vez decidimos si el mejor es OSSIM, NetIQ o ARC Sight (comprada por HP hace poco), lo que está claro es que un proyecto de esta envergadura, requiere definir muy claramente quién recibirá los "diamantes" pulidos en forma de notificación, cómo, cuándo y en qué canal. No es práctico, que por una caída puntual de una máquina se notifique a toda la jerarquía de una organización. Es vital tener en cuenta la criticidad de un evento para priorizar avisando a unos u otros, según corresponda. El mismo principio es aplicable a sistemas puros de monitorización de sistemas como Nagios o Cacti por ejemplo.

Tradicionalmente, los mecanismos de aviso estándar a los centralizadores/correladores de eventos, que suelen implementar los dispositivos son los siguientes:

• Syslog: Cifrado o no. Es, posiblemente, el más estándar sistema de envío de eventos que cualquier centralizador es capaz de entender. Indica además el "recurso" (facility) origen que genera el evento y la "severidad" (severity) del mismo, indicando por supuesto una descripción del mismo.

• SNMP: Protocolo utilizado desde los orígenes para leer/escribir en dispositivos basándose en la comunidad utilizada. Permitía configurar o preguntar a un dispositivo por su estado de forma síncrona o asíncrona. En el caso de las notificaciones, los "traps" SNMP permiten hacer llegar un mensaje a un servidor SNMP por parte de casi cualquier dispositivo de hoy en día. A lo largo del tiempo ha evolucionado en diferentes versiones que implementan mayores detalles de seguridad/autenticación para dar su funcionalidad.

• Email: No puede considerarse un mecanismo de notificación tan sencillo de integrar en un sistema de centralización de eventos, pero sin embargo, resulta mucho más humano para notificar a personas (en cualquier nivel jerárquico) sobre diversos problemas. Es el mecanismo preferido por las empresas para alertar al personal de que algo pasa. Y puedo decir que he visto en más de un cliente la carpeta "Nagios" en el Outlook con cientos de correos sin leer.

• SMS: Gracias a que las empresas se empeñan en regalar un teléfono a todo aquel empleado que compense pagarle la factura telefónica mientras lo puedan tener disponible 24 horas, muchos padres y madres de familia, reciben notificaciones a horas ajenas al horario laboral, que lógicamente han de subsanar. A veces no es tan sencillo justificar que le diste al "mute", que se te quedó en el coche, que se acabó la batería o que se lo comió el perro.

• Pager/Busca: Aunque este mecanismo está completamente en desuso, siempre vemos en películas o series cómo al inspector, policía, médico o el bombero de turno, le suena el busca y tiene que salir corriendo. Me imagino que no será un "Máquina Urano está caida; Máquina Saturno entra en el Fail-over", pero es efectivo, porque lo ve y va a atender la emergencia.

Pero,… ¿dónde pasamos el resto del día?

Contando con que el busca lo usamos poco, y el uso del SMS suena exagerado para notificaciones de una prioridad que no sea muy elevada, en según qué momentos, así como por asegurarnos que nos llega la notificación aunque lo que falle sea el servidor de correo o el servidor SNMP, puede ser interesante recibir aviso de dichos eventos por diferentes canales como:

• Mensajería instantánea: SbD cuenta con bots para las redes de MSN Messenger, Gtalk y Facebook que avisan, siempre y cuando estés en estado "Disponible" que se ha escrito un nuevo post, entre otras cosas. Diseñar un bot para la mensajería instantánea que se desee, que alerte a los destinatarios correctos ante determinados eventos abriéndoles una ventana puede resultar más que útil en aquellas organizaciones en las que la mensajería instantánea no está prohibida.

• Twitter: De esto hemos hablado varias veces en SbD. Yago convirtió tiempo atrás los mensajes de Syslog en envíos a un timeline de un usuario Twitter directamente. Más tarde implementó mecanismos de cifrado en mensajes Twitter, de manera que sólo los conocedores de una contraseña podrían descifrar el mensaje. Más adelante presentamos una herramienta que permite enviar mensajes o la salida de un comando de una máquina concreta, vía Direct Message para que no lo pueda leer más que el receptor del mismo y no todos sus followers.

• Prowl: En iPhone, las notificaciones automáticas, además de acortar la vida de la batería del mismo (efecto colateral), permiten tener un mecanismo bastante potente para recibir mensajes mediante la tarifa de datos. Prowl es una aplicación que se instala en nuestro teléfono y recibe, los mensajes. Para enviar los avisos, Prowl dispone de aplicaciones por línea de comandos que le otorgan grandes dosis de flexibilidad y potencia para mentes creativas.

Como conclusiones me gustaría destacar que:

• En todos los mecanismos de notificación comentados, hemos de tener muy en cuenta que el abusar del número de avisos, puede dar lugar a problemas de saturación, tanto de las infraestructuras, como de los receptores humanos de los mismos, lo que hará que al principio se preste atención a eventos que no valgan para nada y que, con el paso del tiempo, se descarten notificaciones que deberían tener unas acciones más inmediatas.

• Muchos de vosotros pensaréis que es una aberración enviar eventos cuyo contenido va en claro (sin cifrar) a Twitter, Facebook o Messenger. Sin embargo, los elementos que envían notificaciones tampoco suelen incorporar mecanismos de cifrado de correo de basado en PKI como PGP, ni siquiera cifrados con una clave conocida por ambas partes. Lo más normal es que la información a recibir es saber que un backup ha terminado correctamente, que un servicio no funciona, que una partición se está llenando, etc,… En general, y dada la nomenclatura utilizada para las máquinas, poco importa que otra persona sepa lo que le ha pasado a "Mortadelo", "Filemón", "Zipi" o "Zape"… En definitiva, se trata de recibir un aviso urgente, lo más rápidamente posible. Para comunicar secretos de Estado confidenciales, mejor usar otros canales, o cifrar la información, si no queremos que aparezcan en Wikileaks.

• Por defecto, los dispositivos normales, siguen incorporando mecanismos de notificación clásicos (SNMP, Email, Syslog remoto); si queremos algo más sofisticado hay que utilizar una pasarela, que bien puede ser el consolidador/correlador de eventos, que permita enviar a diferentes roles, mediante diferentes canales, las notificaciones definidas. Es decir, que no incorporan de forma nativa el envío mediante canales más modernos de notificación o ejecutar un script personalizado que permita construir la notificación por el medio de nuestra elección.

• ¿Qué hay de malo en redundar la notificación por varios canales? En caso de eventos críticos, de lo que se trata es de que me entere cuanto antes, ¿no? Además así, dotamos de alta disponibilidad el sistema de envío/recepción de mensajes. Si no tengo el correo abierto, pero sí Twitter o Messenger, me enteraré de que algo de lo que debería estar alertado ha sucedido, y lo haré cuanto antes, para poder reaccionar y minimizar el impacto en el tiempo.

Leer más...

Notificación privada mediante TweetMe!

Históricamente, el protocolo de notificación de los diferentes dispositivos que conforman las estructuras de red en las grandes empresas, ha sido SNMP. También son canales válidos, el correo electrónico o syslog como mecanismo de centralización de eventos.

Sin embargo, el mundo 2.0 ha ido haciendo que los que vivimos en él tengamos que evolucionar al mismo tiempo, al menos intentarlo, adaptándonos a los mecanismos de notificación y sociabilidad que el dospuntocerismo trae consigo, en vez de quedarnos anclados a como se hacían las cosas en el pasado.

Hace casi dos años ya, que Yago publicó una revolucionaria herramienta que permitía publicar en el timeline un usuario twitter el syslog de una máquina mediante Sys2Twit. La utilidad es patente, aunque en el caso de que ese timeline sea público, podría considerarse como un problema de seguridad. Sin embargo esto mismo, enviado mediante Direct Messages podría ser una posible solución.

Para otras herramientas publicadas en este blog como amISpammer y Brute12UNX, tuve la tentación de añadir opciones de notificación mediante twitter, cuando una IP ha sido incluida en alguna lista negra o cuando se ha obtenido la contraseña de un #PKCS12. Actualmente, en ambas herramientas, se permite notificar mediante un correo electrónico. Aunque no descarto implementar la notificación a Twitter en un futuro cercano, he preferido crear una herramienta global que permita notificar a un usuario Twitter mediante Direct Messages.

El "original" nombre de la herramienta, TweetMe!, es una implementación por línea de comandos que permite enviar un mensaje, ya sea por parámetros de entrada como el resultado de la salida de otro comando.

Para ello, y aprovechando que los Direct Messages en Twitter soportan una longitud de hasta 920 caracteres, TweetMe! enviará de esa longitud, y si el mensaje a enviar es mayor, lo troceará cuanto sea necesario y lo enviará reordenado al usuario elegido.

Una aplicación muy interesante de esta herramienta es la creación de un nuevo mecanismo de notificación de eventos para plataformas de Nagios.

Las dos formas de ejecutarlo son:

• tweetme.pl <usuariotwitter> <"El mensaje que queramos">

• comando | tweetme.pl <usuariotwitter> -> envía la salida de al usuariotwitter por DMs
  

Para incorporar la mencionada funcionalidad en Nagios, hay que añadir lo siguiente al fichero /etc/nagios/misccommands.cfg:

define command

{


command_name notify-by-twitter

command_line /bin/printf "$SERVICESTATE$ alert for $HOSTALIAS$/$SERVICEDESC$ $OUTPUT$" | /usr/local/bin/tweetme.pl <usuariotwitter>


}

y luego en el fichero /etc/nagios/contacts.cfg indicar para qué usuario(s) queremos añadir notificación por twitter mediante: "service_notification_commands notify-by-twitter"

En mi caso, por ejemplo lo utilizo encadenado con amispammer en el cron para comprobarlo diariamente:

29 5 * * * /usr/local/bin/amispammer | /usr/local/bin/tweetme.pl <usuariotwitter>

A vuestra disposición queda el script para que lo descarguéis desde aquí o aquí

Leer más...

¿Les importa a las empresas las vulnerabilidades reportadas?

En este último año y sobre todo últimamente, desde Security By Default (y algún colaborador nuestro), hemos reportado diferentes vulnerabilidades a diferentes entidades: Menéame, Digg, Movistar, Sun (gracias Slai One), Popular.es, etc,...

En general, lo éticamente correcto cuando se encuentra una vulnerabilidad en un sistema, una vez analizado el impacto de la misma, es notificarla al fabricante o en caso de una página web, al contacto designado por la entidad propietaria. Un correo de contacto que debería ser válido es el proporcionado por la organización cuando efectúa el registro del dominio. Para ello lo que hacemos es buscar los registros whois del dominio o en caso de que falle (o hayan hecho caso a Yago) podemos intentarlo haciendo el Whois a la dirección IP directamente.

Una vez encontrado el contacto, se envía un correo, detallando lo mejor posible, la naturaleza del bug y cómo se ha encontrado (por casualidad o por intuición).

En nuestro caso además solemos indicar que nos gustaría saber cuándo ha sido parcheado el bug para poder publicar un artículo en el que hacemos pública una vulnerabilidad que ya ha sido solucionada, así como los detalles de explotabilidad de la misma.

A partir de aquí, lo lógico es esperar una contestación del tipo que sea en un tiempo prudencial.

Las respuestas han sido hasta ahora bastante diferentes:

• Un mensaje automatizado que nos daba bastante pocas esperanzas de que la vulnerabilidad fuese a ser tratada en condiciones, como nos pasó con Digg.
• Una comunicación bastante fluida y amable en la que se agradecía haber reportado el fallo y que en un breve espacio de tiempo sería solucionado: el caso de popular.es o Menéame,
  
• Ningún tipo de respuesta, como hasta ahora ha sido el caso en Movistar y Sun (esta vulnerabilidad no ha sido ni descubierta ni notificada por nosotros, pero estamos al tanto de que la comunicación ha sido completamente unidireccional desde "Slai One" hacia Sun) no hemos obtenido respuesta de ningún tipo.
  

Si bien parece que las empresas de mayor volumen hacen caso omiso de las notificaciones de vulnerabilidades, hemos de encontrar la justificación de dicha latencia en la jerarquización y estratificación de las mismas. Conocemos que desde que llega un correo con la notificación (si es que llega y no lo filtra el antispam), se procesa por diferentes operadores, se reenvía al departamento correspondiente, se analiza, se comprueba su impacto, se piden los permisos para el cambio y se pasa a producción... pueden pasar varios días. Por eso en organizaciones más sencillas en cuanto a estructura, este tipo de problemas tiene menor tiempo de exposición.

No obstante parece mentira como organizaciones con gran cantidad de medios invertidos en seguridad (infraestructuras de IDS/IPS, servicios de auditoría de aplicaciones, criterios de programación segura, técnicos extremadamente competentes,...) no tengan en cuenta el facilitar de una forma más fácilmente alcanzable una dirección de correo en la que poder reportar los remotos fallos encontrados por terceros. Esta dirección obviamente debería ser monitorizada de manera continua por alguien del equipo de seguridad que pueda escalar el fallo al departamento correspondiente a la brevedad.

Leer más...