Honey Pots o el arte de seducir a las abejas con miel
A altas horas de la madrugada un intruso utiliza la herramienta Nmap contra su red víctima, buscando servidores vulnerables de ser atacados. Después de encontrar un puñado de servidores Web, activa su favorito escáner de CGIs y sorprendentemente se encuentra que uno de los servidores Web de producción es vulnerable a algunos fallos de seguridad conocidos. Sin dudarlo un instante, se prepara para un ataque inminente –igual que los administradores de la red destino–. El atacante ha sido atraído por un Honey Pot (tarrito de miel), un señuelo diseñado específicamente para detectar intrusos.
Mientras puede ser difícil separar el tráfico malicioso del tráfico legítimo destinado a un servidor Web en producción, los administradores de la red saben que sólo un intruso se atrevería a destapar su tarrito de miel.
¿Qué son los Honey Pots?
De acuerdo con la definición general, el objetivo de un Honey Pot es el de emular servidores en producción mientras alertan y registran la actividad del atacante. Cómo se debería conseguir este objetivo está abierto a diferentes interpretaciones. En el recuadro “Honey Pots a la venta” podrá echar un vistazo a algunas de las alternativas viables para crear uno de estos dispositivos en la infraestructura de su empresa.
Todos los paquetes que incluyen un Honey Pot intentan emular una fachada de un sistema real capaz de seducir a los posibles intrusos a usar estos servicios, y entonces engatusarlos fácilmente. El grado de emulación ofrecido por diferentes fabricantes varía enormemente.
Es posible endulzar un Honey Pot usando contenido Web real (si el Honey Pot corre sobre un servidor Web), y usar nombres de usuarios reales (pero no sus contraseñas, claro) para rellenar la base de datos del sistema.
Por supuesto, ningún sistema de detección de intrusos (IDS, Intrusión Detection System) puede estar completo sin una buena cantidad de alertas y sistemas de registro en tiempo real. Esto incluye, obviamente, el uso del correo electrónico para avisar a los administradores legítimos que sus sistemas están siendo atacados, o incluso métodos más modernos como una llamada telefónica del propio sistema de detección al administrador. También, es posible activar el Honey Pot para que cree un registro de todos los paquetes de red que pasen a través de él; esto es útil para poder evaluar el impacto que podría tener el ataque en un sistema de producción real; aunque eso sí, los recursos consumidos serán mucho mayores que si simplemente se envía una alerta por cualquier método a la persona o personas responsables. Igual que los sistemas de detección de intrusos, es más importante el registro y la alerta que la propia detección del intruso.
Integrando un Honey Pot
La integración de un Honey Pot en su propia red influirá en su eficacia, es decir, la implementación inicial será la que le proporcione mayor o menor grado de seguridad.
Un método común es emular un servidor no en producción en los sistemas en producción. Usando una simple redirección de puertos en un router o firewall anterior, puede hacer que un Honey Pot parezca que se encuentra en el lugar exacto que el servidor de producción. Esta táctica, recomendada por Recourse Technologies (fabricantes de ManTrap, www.recourse.com) es ilustrada en una de las imágenes adjuntas a este artículo. Por ejemplo, si mantengo un servidor Web (puerto 80) en producción, podría redirigir el puerto de acceso remoto mediante telnet (puerto 23) y el puerto del servidor de correo o SMTP (puerto 25) a un Honey Pot. Debido a que estos servicios no son usados realmente en el sistema de producción, el Honey Pot deberá enviar inmediatamente una alerta y registrar toda la actividad. Esto requerirá un router o firewall de entrada capaz de realizar una simple redirección de puertos. La mayoría de los productos comercializados en la actualidad permiten efectuar esta redirección fácilmente (incluso los routers ADSL disponen de esta capacidad), incluso en conjunción con NAT (Network Address Translation). La ventaja de este método es que el atacante no podrá saber a ciencia cierta (al menos en los primeros escaneos) la dirección IP pública de la máquina que está atacando, el Honey Pot.
Una configuración de este estilo permitirá al administrador monitorizar posibles ataques en los servicios que no se encuentren en producción, ya que son estos los que son redirigidos al Honey Pot y no el tráfico con destino a puertos en uso. El principal inconveniente es que no se producirán alertas de ningún tipo en los ataques producidos al servidor Web al no estar redirigido su tráfico al Honey Pot.
Otra forma de implementar un Honey Pot es ubicarlo directamente entre los sistemas de producción. Un ejemplo de este uso sería que sus sistemas tuvieran direcciones IP terminadas en .1, .2, .3, .5 y su Honey Pot estuviera intercalado con .4. También es posible hacer que el Honey Pot aparezca en la red con múltiples direcciones de red mediante el uso de IP Aliasing. Este es quizás el método tradicional en el cual no es necesario configurar el router o firewall específicamente, con la ventaja en tiempo que ello implica.
El objetivo en esta última forma es atrapar a los intrusos que escaneen una subred completa –la mayoría de los atacantes lo hacen una vez con el control de un equipo- buscando servicios vulnerables. Si su sistema de producción está ejecutando un servidor DNS, tamb
Mientras puede ser difícil separar el tráfico malicioso del tráfico legítimo destinado a un servidor Web en producción, los administradores de la red saben que sólo un intruso se atrevería a destapar su tarrito de miel.
¿Qué son los Honey Pots?
De acuerdo con la definición general, el objetivo de un Honey Pot es el de emular servidores en producción mientras alertan y registran la actividad del atacante. Cómo se debería conseguir este objetivo está abierto a diferentes interpretaciones. En el recuadro “Honey Pots a la venta” podrá echar un vistazo a algunas de las alternativas viables para crear uno de estos dispositivos en la infraestructura de su empresa.
Todos los paquetes que incluyen un Honey Pot intentan emular una fachada de un sistema real capaz de seducir a los posibles intrusos a usar estos servicios, y entonces engatusarlos fácilmente. El grado de emulación ofrecido por diferentes fabricantes varía enormemente.
Es posible endulzar un Honey Pot usando contenido Web real (si el Honey Pot corre sobre un servidor Web), y usar nombres de usuarios reales (pero no sus contraseñas, claro) para rellenar la base de datos del sistema.
Por supuesto, ningún sistema de detección de intrusos (IDS, Intrusión Detection System) puede estar completo sin una buena cantidad de alertas y sistemas de registro en tiempo real. Esto incluye, obviamente, el uso del correo electrónico para avisar a los administradores legítimos que sus sistemas están siendo atacados, o incluso métodos más modernos como una llamada telefónica del propio sistema de detección al administrador. También, es posible activar el Honey Pot para que cree un registro de todos los paquetes de red que pasen a través de él; esto es útil para poder evaluar el impacto que podría tener el ataque en un sistema de producción real; aunque eso sí, los recursos consumidos serán mucho mayores que si simplemente se envía una alerta por cualquier método a la persona o personas responsables. Igual que los sistemas de detección de intrusos, es más importante el registro y la alerta que la propia detección del intruso.
Integrando un Honey Pot
La integración de un Honey Pot en su propia red influirá en su eficacia, es decir, la implementación inicial será la que le proporcione mayor o menor grado de seguridad.
Un método común es emular un servidor no en producción en los sistemas en producción. Usando una simple redirección de puertos en un router o firewall anterior, puede hacer que un Honey Pot parezca que se encuentra en el lugar exacto que el servidor de producción. Esta táctica, recomendada por Recourse Technologies (fabricantes de ManTrap, www.recourse.com) es ilustrada en una de las imágenes adjuntas a este artículo. Por ejemplo, si mantengo un servidor Web (puerto 80) en producción, podría redirigir el puerto de acceso remoto mediante telnet (puerto 23) y el puerto del servidor de correo o SMTP (puerto 25) a un Honey Pot. Debido a que estos servicios no son usados realmente en el sistema de producción, el Honey Pot deberá enviar inmediatamente una alerta y registrar toda la actividad. Esto requerirá un router o firewall de entrada capaz de realizar una simple redirección de puertos. La mayoría de los productos comercializados en la actualidad permiten efectuar esta redirección fácilmente (incluso los routers ADSL disponen de esta capacidad), incluso en conjunción con NAT (Network Address Translation). La ventaja de este método es que el atacante no podrá saber a ciencia cierta (al menos en los primeros escaneos) la dirección IP pública de la máquina que está atacando, el Honey Pot.
Una configuración de este estilo permitirá al administrador monitorizar posibles ataques en los servicios que no se encuentren en producción, ya que son estos los que son redirigidos al Honey Pot y no el tráfico con destino a puertos en uso. El principal inconveniente es que no se producirán alertas de ningún tipo en los ataques producidos al servidor Web al no estar redirigido su tráfico al Honey Pot.
Otra forma de implementar un Honey Pot es ubicarlo directamente entre los sistemas de producción. Un ejemplo de este uso sería que sus sistemas tuvieran direcciones IP terminadas en .1, .2, .3, .5 y su Honey Pot estuviera intercalado con .4. También es posible hacer que el Honey Pot aparezca en la red con múltiples direcciones de red mediante el uso de IP Aliasing. Este es quizás el método tradicional en el cual no es necesario configurar el router o firewall específicamente, con la ventaja en tiempo que ello implica.
El objetivo en esta última forma es atrapar a los intrusos que escaneen una subred completa –la mayoría de los atacantes lo hacen una vez con el control de un equipo- buscando servicios vulnerables. Si su sistema de producción está ejecutando un servidor DNS, tamb
