Este artículo presenta la segunda parte del estudio del compromiso de un servidor perteneciente a una determinada compañía. Se expondrán algunas lecciones sobre el diseño e implementación de la seguridad basadas en este caso. Se llevó a cabo una investigación forense, de la cual se presentan los resultados. El artículo ofrece la oportunidad de seguir la pista a la respuesta ante un incidente real. Organizaremos el estudio del caso basándonos en la metáfora de prevención-detección-respuesta. Por jemplo, ¿cómo prevenir futuros incidentes de este tipo? ¿Qué tecnologías necesitamos para detectarlo? ¿Cómo podemos responder de forma efectiva?
¿Qué debe hacer la compañía para prevenir esto? Su arquitecura DMZ era robusta (vea la descripción en el anterior texto), y evitó la extensión del daño provocado. Como descubrimos por las trazas de red del programa netForensics, el intruso intentó conectarse a diferentes máquinas internas, todas sin éxito.
Además, una configuración efectiva de la DMZ frustró los intentos de conexión del intruso a su sitio web y a otros sitios. En general, nos muestra que el deshabilitar el acceso de las máquinas de la DMZ hacia el exterior es muy importante. Sirve para prevenir que pidan responsabilidades a la compañía si esta se usa para lanzar ataques de denegación de servicio o para llevar a cabo otro tipo de abuso contra terceras partes. Muchos expertos en seguridad predicen el aumento de la legislación contra compañias cuyas redes son usadas para realizar ataques. Es mucho más probable que una máquina de la DMZ sea comprometida por intrusos externos que por una máquina de la red interna. Debido a esto, las máquinas de la DMZ sólo deben tener permitido "hacer su trabajo" y con reglas de acceso a nivel de red (aplicando el principio del mínimo privilegio). Concretamente, el servidor web sólo debe tener permitido el hecho de servir páginas web, mientras que los servidores de correo acceptan y envían correos, etc... pero nada más.
Para prevenir el incidente que nos ocupa, está muy claro qué pasos debemos seguir. El administrador del sistema debe parchear el WU-FTPD usando la página de actualizaciones de Red Hat (http://www.redhat.com/apps/support/errata/). Con el FTPD actualizado, está supuestamente a salvo de este ataque en particular (vea la primera parte del artículo Estudio de un ataque FTP, 1a parte: el análisis para más detalles).
Sin embargo, la cuestión es mucho más complicada que un parcheado temporal. Mucha gente está diciendo a estas compañias que deben parchear inmediatamente al ver el parche en el sitio web del vendedor, o justo después de la fase de test, etc... Pero hablar es fácil y hablar sobre seguridad no es una excepción. Se estimó y se informó que las grandes compañias (especialmente aquellas que són sólo-Microsoft), no tendrían suficiente tiempo para completar los anteriores requisitos de parcheado antes de que saliera un nuevo parche usando el personal encargado del sistema y la red. Priorizar los parches es otro duro reto (http://www.securitywatch.com/RES/September3.html). La situación es considerablemente mejor en el mundo UNIX/LInux, pero uno todavía tiene que estar comprobando las alertas ofrecidas por el vendedor para estar razonablemente seguro. Y juzgando por el número de escaneos FTP de nuestra red trampa (honeynet), el servidor FTP vulnerable sería explotado en cuestión de días. Vemos cientos de intentos de acceso por FTP al día y bastantes ataques con éxito por semana (si habilitamos el servidor vulnerable).
Aún así, el parcheado es una buena seguridad, pero también es una batalla perdida. Puede no parecerlo, si tiene unos pocos servidores UNIX y utiliza las actualizaciones automáticas (o notificaciones), pero para un entorno grande sí lo es. Al igual que escribe Bruce Schneier en su libro "Secretos y mentiras" (Secrets and lies), los sistemas de información se están volviendo más complejos y en consecuencia más vulnerables. Su concepto de "ventana de exposición" nos muestra que siempre habrá un período de tiempo en el que los intrusos nos llevarán ventaja.
¿Cuál es el método de prevención que siempre funcionará? Un buen diseño de la red sin ir más lejos. Las máquinas fortalecidas y los cortafuegos no detendrán los ataques a nivel de aplicación, ya que siempre se debe permitir algo que pase a través de ellos. El parcheado funciona, si tiene tiempo para hacerlo y para buscar nuevos parches para todos los programas críticos cada día. Además, los parches no le protegen ante ataques desconocidos, ataques contra los programas que han llegado al fin de su ciclo de mantenimiento y ataques que los desarrolladores deciden ignorar por cualquier razón "política". Evitando los programas que tienen un mal historial de seguridad ayudará, pero los programas cambian y se introducen nuevos fallos todos los días. Por ejemplo, las viejas guías de seguridad de SunOS recomiendan reemplazar el demonio Sun ftp con un WU-FTPD "seguro". Y ahora WU-FTPD es la parte débil. Una solución es la categoría emergente de herramientas de "prevención de intrusos", en pocas palabras podemos decir que son sistemas operativos o programas especiales que limitan el comportamiento de los programas. Aunque no se posee todavía una definición precisa (vea algunas discusiones en http://www.infosecuritymag.com/2002/apr/note.shtml), estos productos a veces pueden prevenir incidentes como este (sin necesidad de parchear o actualizar). Por ejemplo, en el mundo Linux, Linux EnGarde (http://www.engardelinux.com/) y algunos otros vendedores ofrecen soluciones que pueden atenuar los ataques a aplicaciones limitando su comportamiento y deteniendo ataques en sistemas no parcheados. Por jemplo, si el servidor FTP era incapaz de proporcionar una línea de comandos de sistema, el ataque no hubiera sido satisfactorio. Sin embargo, estas herramientas de prevención són a menudo difíciles de configurar, llevando así a errores en la configuración y por lo tanto a una menor seguridad.
En el estudio de este caso la detección no fué problema. ¡Los discos duros vacíos del servidor eran un buen indicio de que algo había pasado! Sin embargo, nuestra hipótesis es que el intruso decidió borrar los contenidos del disco sólo después de entender que el entorno no era propicio para sus propósitos (sin conexiones salientes, sin nada que atacar hacia el interior). La instalación del rootkit presupone la intención de mantener la máquina para futuros propósitos. Ahora imagine que la DMZ no fuera tan robusta y el intruso sigue con la instalación del rootkit para así poder volver en un determinado momento. En este caso, un buen IDS de red (como el gratuito Snort http://www.snort.org) con las firmas de ataques actualizadas habría ayudado.
No se sorprendan, las firmas de ataques para la detección de intrusos han demostrado ser un mecanismo de detección eficiento. Pero un IDS es sólo igual de efectivo que la persona que está ante la pantalla analizando y relacionando los registros. Productos como netForensics también son efectivos en la detección de violaciones proporcionando una imagen completa del incidente y notificando al personal de seguridad. Sin embargo, sigue siendo importante que alguien observe los datos y actúe en consecuencia.
La 1a parte del texto motró una investigación involucrando un análisis forense de red y de computadoras. Se pueden extraer algunas lecciones de él.
Primero, el tener dispositivos de seguridad para la red ayudó mucho (aunque sólo después de la intrusión). La ausencia de una persona monitorizando la red en tiempo real hizo del IDS una herramienta forense (y sólo eso). Además, nos ayudamos de los programas de agregación y correlación de tráfico para el análisis forense de la red, y así obtener una idea de las acciones del intruso dentro de la DMZ. De hecho, si nos hubiéramos decidido a estudiar sólo la causa del incidente y no ir a recuperar las herramientas del hacker, el análisis forense de la red hubiera sido suficiente.
Segundo, el análisis forense del disco no es una ciencia (es un juego de habilidades). La recuperación garantizada de todos los ficheros en un sistema de archivos UNIX es simplemente imposible, especialmente cuando ha pasado largo tiempo desde el incidente. Las pruebas forenses recuperadas ayudaron a reconstruir la imagen del ataque y nos proporcionó algunas herramientas del hacker que poder analizar. Por desgracia, los procedimientos de análisis forense pueden llegar a consumir mucho de nuestro tiempo.
Tercero, el análisis detallado de los ataques del hacker y las herramientas se deja para el entorno de investigación de los equipos trampa. Los sistemas de producción y la gente que los utiliza (por ej. administradores de sistemas y de red) no están preparados para esta batalla, ya que muchos de los requisitos económicos van contra las necesidades de los investigadores en seguridad. Sin embargo, esto se permite en una red trampa, ya que puede proporcionar información valiosa de las operaciones del hacker.
Como conclusión general, el estudio de este caso resalta los riesgos de utilizar servidores vulnerables, los beneficios de una buena DMZ y algunas técnicas de investigación.
Anton Chuvakin, Ph.D., GCIA (http://www.chuvakin.org) is a Senior Security Analyst with a major information security company. His areas of infosec expertise include intrusion detection, UNIX security, honeypots, etc. In his spare time he maintains his security portal http://www.info-secure.org