Después de una larga ausencia por motivos laborales estamos de regreso para dar respuesta a todas aquellas inquietudes que he recibido vía Twitter y por supuesto concluir con la serie de artículos destinados a las mejores distribuciones de Linux.
Antes de comenzar con el artículo quisiera responder a todos aquellos tuits que preguntaban acerca del funcionamiento de algunas de las herramientas mencionadas en el artículo anterior. Pues bien, para todos ellos en lugar de explicarles más detalles sobre cada una de ellas decidí hablarles un poco de una distribución (lamentablemente ya retirada) que en su momento dio mucho de qué hablar debido a su nombre.
PHLAK, mejor conocida como Professional Hackers Linux Assault Kit, fue una distribución pionera en cuanto a las distribuciones orientadas a realizar pruebas de seguridad a infraestructura o componentes de tecnologías de información. Su modo de ejecución LiveCD permitía al usuario final adentrarse al mundo de estar herramientas sin necesidad de tener conocimientos previos de como instalar un sistema operativo Linux o estarse rompiendo la cabeza en cómo configurar el servidor X para poder ejecutar la interfaz gráfica.
En resumen, para todos aquellos que están interesados en el pen testing y sus herramientas les recomiendo encarecidamente iniciar con esta distribución, la cual aún está disponible para su descarga desde el sitio de http://sourceforge.net
Y claro, para que puedan poner a prueba sus conocimientos sin que nuestro buen amigo Andrés Velázquez los quiera amedrentar con “mandarlos a la sombra” nos ocuparemos en este artículo a hablar de unos de los componentes centrales en toda lucha contra el cibercrimen, los famosos Honeypot.
¿Qué es un Honeypot?
Aunque quizá la gran mayoría de ustedes están familiarizados con el concepto, no está por demás una breve explicación para entrar en contexto.
Un Honeypot básicamente es un conjunto de hardware y software cuya finalidad es simular o construir sistemas vulnerables (inseguros) y propensos a ser atacados.
Partiendo de esta definición comenzaremos a dar un poco de mayor claridad a la misma, ya que la anterior engloba de manera general los dos tipos de honeypot más comunes en el ambiente.
El primero consiste en simular equipos o sistemas vulnerables. Cuando nos referimos a equipos estamos considerando todo el hardware de una infraestructura de IT (routers, switches, etcétera) y cuando nos referimos a sistemas, consideramos todas aquellas aplicaciones o servicios que corren sobre esa infraestructura de hardware.
Este tipo de Honeypot pretenden actuar como una pieza de hardware, servicios o aplicaciones que realmente no tenemos instalados en el equipo que está realizando la función de Honeypot. Es decir, únicamente simulamos tener los puertos abiertos o servicios que un atacante espera encontrar sin que estos necesariamente estén configurados realmente.
Para explicar un poco mejor este punto imaginemos el siguiente escenario:
Supongamos que queremos simular un servicio FTP. Para esto lo único que tendríamos que hacer sería utilizar el comando net cat para que escuchara sobre el puerto 21 y que cuando este recibiera una conexión ejecutara un script, que desplegara el contenido del banner del servicio FTP, así como la palabra usuario y realizara una pausa hasta que recibiera como parámetro el código generado por la tecla Enter; posterior a eso desplegara en una nueva línea la palabra contraseña, esperara de nuevo el golpe de la tecla Enter y finalmente desplegara un mensaje de usuario o contraseña incorrecta.
Con esta acción estaríamos simulando un servicio de FTP, que en realidad no existe, con el único objetivo de recolectar todos aquellos usuarios y/o passwords que alguien ingresara.
Esta es un forma bastante sencilla de realizar una simulación pero espero les haya servido para comprender un poco más aquellos sistemas Honeypot basados en simulación de servicios o aplicaciones.
Por otro lado, tenemos los Honeypot que son construidos con servicios vulnerables reales, ya que un atacante más experimentado, seguramente analizando el tráfico de red, se daría cuenta que están simulando un servicio y no gastaría su tiempo en intentar vulnerar algo que no es vulnerable. En especial a sabiendas de que muchos de estos panales de miel virtuales son comúnmente utilizados por autoridades como el FBI o la Interpol, e incluso por firmas de seguridad IT.
Para la construcción de este tipo de Honeypots generalmente suelen utilizarse equipos con configuraciones débiles de seguridad, faltos de alguno que otro parche para el operativo y que de preferencia no existan exploits (programas que saquen provecho de la vulnerabilidad) liberados. Esto permite entender a los administradores de seguridad cómo un atacante intentaría vulnerar los sistemas expuestos sin necesidad de exponer un sistema productivo.
Por lo general, estas implementaciones se realizan en una DMZ aislada puesto que un atacante pudiera tener éxito y comprometer el sistema Honeypot, pero al estar aislado de la red principal no podría comprometer otros sistemas de la red a partir de éste.
¿Para qué me sirve un HoneyPot?
Como lo mencionaba al inicio del artículo sirve para evitar el amedrentamiento del señor Velázquez y una eventual excursión a la sombrita…
Pero hablando en serio su objetivo real es poder analizar las técnicas empleadas por los cibercriminales, hacktivistas y hackers más gris oscuro que blancos durante una intrusión. Un Honeypot puede ser de mucho valor para una organización sobre todo si esta última maneja información que pudiera ser redituable en términos económicos por los atacantes.
La construcción en sí misma, del Honeypot, es un ejercicio que involucra tener conocimientos profundos sobre la arquitectura y los servicios o aplicaciones de la organización, ya que no se puede pretender construir uno si no se tiene claro cómo operan tanto la arquitectura como las distintas aplicaciones y servicios proporcionados. De tal forma que la identificación y el entendimiento de estos componentes ya es de gran valor para la organización, independientemente si cuando éste (Honeypot) se exponga sea atacado o no.
Como dicen por ahí… no podemos resolver un problema si antes no entendemos qué esta ocasionado el problema, situación que muchas veces no es clara dentro de las organizaciones y esto afecta directamente al proceso de respuesta a incidentes de una organización (en caso de que exista).
Otro beneficio indirecto es el análisis, ya que no es lo mismo responder a un incidente de seguridad de la información con la presión del director de IT encima, a resolver el mismo incidente basado en las acciones correctivas identificadas durante una intrusión del mismo tipo o similar ocurrida tiempo atrás en un Honeypot.
Como ven, el mundo de los Honeypots es bastante interesante ya que para poder implementar uno de manera efectiva debemos de conocer cómo funciona cada uno de los sistemas o servicios que queremos analizar lo que inevitablemente conlleva a tener un conocimiento actualizado de las técnicas de ataque y las herramientas disponibles.
Finalmente, quisiera terminar este artículo recomendándoles algunas aplicaciones y links interesantes para todos aquellos que quieran adentrase en este fascinante mundo de los Honeypots, en donde la polémica no es la excepción ya que para algunos un Honeypot compromete más los sistemas de lo que puede ayudar y para otros (me incluyo) trae innumerables beneficios para la organización (realizando la adecuada implementación del mismo).
Apps:
Para Windows: Winhoneyd
Para Linux: Deception Toolkit
Links:
No se olviden de dejar sus comentarios o sugerencia vía twitter o directamente al correo electrónico ehernandezh@produban.com.mx saludos y gracias por su preferencia.
Elihú B. Hernández es analista forense digital e integrante del grupo de respuesta a incidentes de Produban México (Grupo Santander). Posee las certificaciones ACE (AccessData) y GCFA (SANS) respectivamente así como formación especializada en TI. Síguelo en Twitter: @elihu_hernandez
SÍGUENOS
© 2012 Netmedia S.A. de C.V.
Políticas de privacidad
Sócrates 128 4to piso, Polanco
CP 11560, México D.F.
Tel: 2629 7260