Honeynets III: Arquitectura (Para aprender, perder… o no)

Seguimos con la serie sobre Honeynets, esta vez para hablar de las tipologías, que dependerán de los recursos de los que disponemos para implantar la honeynet. Según la tipología, aún siendo válidas todas ellas, estarán más o menos limitadas en el cumplimiento de los objetivos propuestos.

Tendremos en cuenta la clasificación que propusimos en el anterior post donde se diferenciaba por localización. El tipo de honeynet a implantar, bien sea conviviendo con nuestros sistemas en producción o en un entorno totalmente aislado de la organización, marcará las directrices a la hora de decidir que tecnologías utilizar.

Entorno de PRODUCCIÓN

Si nos decantamos por una honeynet integrada en nuestra red organizativa en producción, debemos conocer las tecnologías que forman parte de nuestros sistemas para no utilizar otra que pueda interferir en el modelo productivo. En este caso y como ejemplo, si tenemos una política de seguridad donde se exige que la implantación de nuevos sistemas debe hacerse mediante virtualización, sabemos que la instalación de los diferentes honeypots no podrá realizarse en sistemas físicos convencionales.

Por otra parte, también debemos acordar la parte de comunicaciones y redes, tanto la IP o el rango de IPs utilizadas como los requisitos de seguridad acordes a la política de seguridad adoptada. Puesto que la honeynet va a funcionar junto a otros sistemas corporativos, deberemos tener en cuenta la importancia que toman elementos de seguridad perimetral como son el firewall, el NIDS y el sistema de monitorización del que dispongamos.

De esta forma, debemos refinar bastante la accesibilidad a los servicios a través del firewall para que los atacantes no puedan eludir las medidas de seguridad. A su vez, deben configurarse las reglas oportunas del sistema de detección de intrusos que nos permita conocer en cada momento la actividad sospechosa en nuestra infraestructura. En este caso, toma mayor relevancia la actividad detectada ya que sabemos que los atacantes pueden verse atraídos por las características de los propios honeypots, con el riesgo de que puedan aprovechar cualquier vulnerabilidad no conocida para saltarse las limitaciones que hemos implantado. La monitorización de cada sistema, servicio y en general de cada recurso que forma parte de la nueva arquitectura, facilita el mantenimiento e incluso la detección de actividades sospechosas. En el caso de que un recurso quedara inoperativo, bien por un fallo del propio sistema, o por un ataque dedicado que no ha sido capaz de soportar, tendríamos la suficiente información como para restaurarlo y prevenir el fallo en un futuro. De forma adicional, utilizaremos esta información para ampliar informes periódicos de los que ya hablaremos en otro artículo.

Entorno de INVESTIGACIÓN

La otra opción en cuanto a la localización de la honeynet es la de un entorno aislado y totalmente independiente del de la organización. En este caso podemos diseñar una arquitectura dedicada exclusivamente a la honeynet teniendo en cuenta que la deberemos dotar de conectividad a Internet, por lo que son necesarias una o varias IPs públicas en el caso de querer ofrecer varios servicios.

Así pues, proponemos un diseño ordenado y enfocado a futuras ampliaciones de la infraestructura. Empezaremos por la implantación de un firewall con las reglas configuradas para que realice NAT sobre los servicios que queremos ofertar. El propio firewall es el que divide la infraestructura de la honeynet, a nuestro entender, dependiendo de la función de cada elemento. Por una parte tenemos en cuenta los elementos de detección y monitorización, formados por IDS y monitores de servicios y recursos. Por otra parte, incluimos los elementos de gestión de la propia honeynet. Estos elementos son los que recopilan y representan la información recogida en cada uno de los honeypots.

Por último contamos con los propios honeypots, que a su vez, es interesante dividirlos según sean de alta o baja interacción. Tal y como hemos comentado, este diseño es totalmente subjetivo. Cada administrador de la honeynet puede optar por el diseño que considere más oportuno aunque dividirlos otorga a la infraestructura un enfoque seguro y lógico. Una vez diseñada, debemos elegir qué tecnología emplear en nuestra honeynet. Según la tecnología por la que nos decantemos, tendremos una serie de ventajas e inconvenientes a tener en cuenta.

En primer lugar el coste. No tiene el mismo coste el utilizar un servidor para cada sistema, que un único servidor lo suficientemente potente como para virtualizarlos todos ellos.

En cuanto a la seguridad, como hemos comentado anteriormente, el elemento central será el firewall. Deberemos elegir entre un sistema dedicado tipo appliance o un software basado en el kernel de un sistema que ya dispongamos, lo cual evitaría la adquisición de un nuevo sistema. No vamos a discutir cuál sería la mejor opción, puesto que ambos pueden otorgar un nivel de seguridad aceptable, dependiendo, y mucho, de cómo los hayamos configurado.

Otra característica a tener en cuenta es la continuidad. Si un sistema es vulnerado o deteriorado, bien por acción del atacante o por fallo del sistema, sabemos que si se trata de un sistema virtualizado, y se han realizado las operaciones de mantenimiento necesarios (p.e. backups de seguridad en forma de snapshots), es trivial y rápido el realizar una restauración del mismo. Por contra, si el sistema es un servidor físico, aparte del coste en caso de tener que sustituirlo, tendremos que sumar el tiempo de restauración para dejarlo en un estado consistente y sin que hayamos sufrido pérdida excesiva de datos que invalide los resultados obtenidos. En contrapartida, a los riesgos de los sistemas virtualizados deberemos sumarle los riesgos del propio servidor de virtualización, el cuál puede estar expuesto a nuevas vulnerabilidades desconocidas e incluso desatendidas.

Finalmente, debemos considerar qué sistemas operativos utilizar para cada uno de los elementos que conforman la honeynet. En la mayoría de los casos vendrá condicionado por la compatibilidad que ofrezcan las aplicaciones, ya sean los propios honeypots, o bien el software de gestión y monitorización.

Tanto la manejabilidad como la funcionalidad vienen definidas por los propios honeypots y los sistemas de gestión de alertas, pero esto es otra historia, que será contada en otra ocasión…

(Imagen de http://honeynet.uncc.edu. Entrada escrita en colaboración con Alberto Segovia, co-autor de la serie)