Instalacion y configuracion de una Honeypot

Lo primero que vamos a hacer es instalar el paquete honeyd
#apt-get install honeyd

Los principales archivos que se instalan son los siguientes

/etc/init.d/honeyd
/etc/logrotate.d/honeyd
/etc/default/honeyd
/usr/lib/honeyd
/usr/share/honeyd
/usr/share/doc/honeyd
/usr/include/honeyd
/usr/bin/honeyd


ahora pasamos ala configuracion de nuestra honeypot y este seria el archivo de configuracion

############################
#Configuration du réseau virtuel utilisé
route entry 10.0.0.1
route 10.0.0.1 link 10.2.0.0/24
route 10.0.0.1 add net 10.3.0.0/16 10.3.0.1 latency 8ms bandwidth 10Mbps
route 10.3.0.1 link 10.3.0.0/24
route 10.3.0.1 add net 10.3.1.0/24 10.3.1.1 latency 7ms loss 0.5
route 10.3.1.1 link 10.3.1.0/24

############################
# Création d'un profil template
create template
set template personality "Microsoft Windows XP Professional SP1"
set template uptime 1728650
set template maxfds 35
# For a complex IIS server
add template tcp port 80 "sh /usr/share/honeyd/scripts/win32/web.sh"
add template tcp port 22 "/usr/share/honeyd/scripts/test.sh $ipsrc $dport"
add template tcp port 23 proxy $ipsrc:23
add template udp port 53 proxy 141.211.92.141:53
set template default tcp action reset
# Use this if you are not running honeyd as 'honeyd' user:
# Debian-specific (use nobody = 65534 instead of 32767)
# set template uid 65534 gid 65534

############################
#Création d'un profil default
create default
set default default tcp action block
set default default udp action block
set default default icmp action block

############################
#Création d'un profil router
create router
set router personality "Cisco 1601R router running IOS 12.1(5)"
set router default tcp action reset
add router tcp port 22 "/usr/share/honeyd/scripts/test.sh"
#add router tcp port 23 "/usr/share/honeyd/scripts/router-telnet.pl"
add router tcp port 23 "/usr/share/honeyd/scripts/telnet/fake.pl"

###########################
#On démarre les hotes en spécifiant l'IP et le profil
bind 10.3.0.1 router
bind 10.3.1.1 router
bind 10.3.1.12 template
bind 10.3.1.11 template
bind 10.3.1.10 template
set 10.3.1.11 personality "Microsoft Windows NT 4.0 SP3"
set 10.3.1.10 personality "IBM AIX 4.2"

Para poner en marcha la red virtual más arriba tendremos que declarar un camino (real) en la tabla de enrutamiento para llegar a ella. La passerelle utilisée pour cette route sera l'interface loopback (localhost) afin de ne pas perturber le réseau existant. El puente utilizado para esta ruta va a proporcionar una interfaz loopback (localhost) con el fin de no perturbar la red existente.

route add -net 10.0.0.0 netmask 255.0.0.0 gw localhost

 Para
probar esta configuración nos Honeyd primer lanzamiento en modo interactivo ejecutando el
comando a continuación en una consola

#honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf
-i lo 10.0.0.0/8

gold@deb ~# honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
Honeyd V1.5b Copyright (c) 2002-2004 Niels Provos
honeyd[3676]: started with -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
honeyd[3676]: listening on lo: ip and (dst net 10.0.0.0/8)

esto es lo que deveria salir si todo a marchado bien ahora lo paramos con ctrl+c
y vamos a funcionar nuestra honeypot como demonio

Para ello vamos a cambiar el archivo de configuración del diablo. editaremos el fichero
#pico /etc/default/honeyd
Como primer paso, tenemos que cambiar la constante RUN para iniciar el demonio

RUN="yes"

A continuación, indicar la interfaz utilizada y el rango de direcciones IP de la red:

INTERFACE="eth0"
NETWORK=10.0.0.0/8

A continuación, iniciar el demonio Honeyd con el comando

/etc/init.d/honeyd start / Etc / init.d / honeyd inicio

Si no hay ningun error nos debe salir lo siguiente

Starting Honeyd daemon: honeyd.

para emular los servicios corriendo en una maquina virtual. honeyd permite el uso de unos scripts.
los ejemplos de estos scripts se encuentran en el directorio

/usr/share/honeyd/scripts


conesto vamos a probar ke la honey esta funcionado

 honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
Honeyd V1.5b Copyright (c) 2002-2004 Niels Provos
honeyd[3753]: started with -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
honeyd[3753]: listening on lo: ip and (dst net 10.0.0.0/8)

ahora vamos a probar haciendo un ping

# ping 10.3.0.1
PING 10.3.0.1 (10.3.0.1) 56(84) bytes of data.
64 bytes from 10.3.0.1: icmp_seq=1 ttl=63 time=10.0 ms
64 bytes from 10.3.0.1: icmp_seq=2 ttl=63 time=10.0 ms
64 bytes from 10.3.0.1: icmp_seq=3 ttl=63 time=10.0 ms
64 bytes from 10.3.0.1: icmp_seq=4 ttl=63 time=10.0 ms
64 bytes from 10.3.0.1: icmp_seq=5 ttl=63 time=10.0 ms
64 bytes from 10.3.0.1: icmp_seq=6 ttl=63 time=10.0 ms


y este seria el resultado de la honeyd respondiendo al ping

# honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
Honeyd V1.5b Copyright (c) 2002-2004 Niels Provos
honeyd[3753]: started with -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
honeyd[3753]: listening on lo: ip and (dst net 10.0.0.0/8)
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249

ahora vamos a probar utilizando un scrip de simulacion de sevicios

# telnet 10.3.0.1 23
Trying 10.3.0.1...
Connected to 10.3.0.1.
y la honeyd debe responder al telnet de la siguiente manera

honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
Honeyd V1.5b Copyright (c) 2002-2004 Niels Provos
honeyd[3753]: started with -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
honeyd[3753]: listening on lo: ip and (dst net 10.0.0.0/8)
honeyd[3753]: Sending ICMP Echo Reply: 10.3.0.1 -> 192.168.0.249
honeyd[3753]: Connection request: tcp (192.168.0.249:1584 - 10.3.0.1:23)
honeyd[3753]: Connection established: tcp (192.168.0.249:1584 - 10.3.0.1:23) <-> /usr/share/honeyd/scripts/telnet/fake.pl



y asi damos terminada la configuracion de esta honeypot y podemos ver que los
resultados fueron satisfactorios con base en las perspectivas que teniamos sobre el tema.

Fallo en seguridad en SNORT

Salto de restricciones a través de valores TTL en Snort

 
Se ha descubierto un fallo de seguridad en Snort que podría permitir a 
un atacante remoto saltar restricciones de seguridad. 
 
Snort es uno de los IDS (Sistema de Detección de Intrusiones) más 
extendidos. Distribuido de forma gratuita como Open Source, Snort puede 
detectar muchos de los patrones de ataque conocidos basándose en el 
análisis de los paquetes de red según unas bases de datos de firmas, 
además de reglas genéricas. Habitualmente la función de estos detectores 
es la de alertar sobre actividades sospechosas a través de cualquier 
mecanismo, aunque en ocasiones puede usarse para lanzar medidas 
destinadas a mitigar de forma automática el posible problema descubierto 
por el sensor. 
 
El fallo reside en el reensamblado de paquetes IP fragmentados. Cuando 
Snort recibe paquetes fragmentados compara sus valores TTL. Snort tiene 
un valor predefinido para la diferencia de valores TTL entre paquetes, 
si el valor de la diferencia entre el primero de ellos y el resto es 
mayor que este valor los descartará y no aplicará ningún filtro o examen 
sobre ellos. Un atacante remoto podría aprovechar este fallo para saltar 
restricciones de seguridad modificando los valores TTL de los paquetes 
IP. 
 
El problema se ha confirmado en Snort 2.8 y 2.6. Snort 2.4 no es 
vulnerable. Como contramedida en el archivo de configuración snort.conf, 
se puede establecer el valor ttl_limit a 255 con la siguiente línea: 
preprocessor frag3_engine: ttl_limit 255 
 
Además el fallo queda corregido en la versión 2.8.1 disponible en el 
repositorio: 
cvs.snort.org

mas informacion en:
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=701

SNORT con base de datos en MYSQL

MYSQL Base de datos

ahora pondremos el snort a funcionar con un base de datos en mysql.

primero instalaremos el paquete snort-mysql

#apt-get install snort-mysql

y pasamos a la configuracion de mysql

#mysql
>create user snort identified by 'xxxx'(password);

>grant all on snort.* to snort@localhost identified by 'xxxx'(password);

>flush privileges

La base de datos llamada snort se crea por defecto con la instalcion el paquete snort-mysql.
En los comandos pasados lo que hicimos fue primero crear el usuario snort , luego garantizarle al usuario snort permiso sobre todas la tablas almacenadas en el mysql .

ahora en el archivo snort.conf descomentaremos la linea que habias comentado anteriormente

output database: log, mysql, user=snort password=sena dbname=snort host=localhost

cambiando los parametros poniendo el nombre de la base de datos el nombre de del usuario y el password

#snort -c snort/snort.conf

luego con este comando iniciamos el snort y si todo esta bien el snort cargara sin ningun prolema.

SNORT Configuracion y Analisis de Ataques

En esta entrada vamos a explicar como fue la instalacion, configuracion y puesta en funcionamiento de snort.

primero instalamos el snort

#apt-get install snort

en la instalacion nos hara unas preguntas sobre el rango de direcciones que queremos analizar, le damos la opcion any que analize todas las direcciones ip de todos los rangos internos y externos.

luego pasamos a la configuracion que por el momento es algo muy basico, nos vamos al directorio #cd /etc/snort y este sera el archivo de configuracion del snort hay varias opciones como snort.debian.conf

DEBIAN_SNORT_STARTUP="boot"
DEBIAN_SNORT_HOME_NET="any"
DEBIAN_SNORT_OPTIONS=""
DEBIAN_SNORT_INTERFACE="eth0"
DEBIAN_SNORT_SEND_STATS="true"
DEBIAN_SNORT_STATS_RCPT="root"
DEBIAN_SNORT_STATS_THRESHOLD="1"

que seria una configuracion muy basica escuchara en la eth0 y analizara los paquetes desde cualquier destino

Pero ahora nos concentraremos en el snort.conf que es el archivo de configuracion de snort
# output database: log, mysql, user=root password=test dbname=db host=localhost

comentamos esta linea para decirle que no use una base de datos mysql sino que las alertas las genere en el directorio por defecto /var/log/snort/alert

#snort -c /etc/snort/snort.conf &

con este comando inicamos el snort manualmete y nos saldran todas las opciones que se correran con el snort y en caso de problemas los errores que tengas.Esta seria la configuracion basica del snort y haora vamos a hacer unas pruebas para probar el funcionamiento del snort ,haciendo un nmap desde un equipo en esta red y y el snort nos debe generan una alerta sobre este posible ataque.

como se puede ver en la imagen las alertas se generaron por que se hizo un analisis de puertos (NMAP) y como el snort toma esto como un posible ataque desde la direccion 10.3.16.107 que es la ip desde donde se hizo el presunto ataque, se generaron las alertas que nos demuestarn que nuestro snort tiene un buen funcionamiento

Tipos de Deteccion

-Detección de anomalías.
La base del funcionamiento de estos sistemas es suponer que una intrusión se puede ver como una anomalía de nuestro sistema, por lo que si fuéramos capaces de establecer un perfil del comportamiento habitual de los sistemas seríamos capaces de detectar las intrusiones por pura estadística: probablemente una intrusión sería una desviación excesiva de la media de nuestro perfil de comportamiento.

-Detección de usos indebidos.
El funcionamiento de los IDSes basados en la detección de usos indebidos presupone que podemos establecer patrones para los diferentes ataques conocidos y algunas de sus variaciones; mientras que la detección de anomalías conoce lo normal (en ocasiones se dice que tienen un `conocimiento positivo', positive knowledge) y detecta lo que no lo es, este esquema se limita a conocer lo anormal para poderlo detectar (conocimiento negativo, negative knowledge).

CGIs

Interfaz de entrada común ( Common Gateway Interface, abreviado CGI) es una importante tecnología de la World Wide Web que permite a un cliente (explorador web) solicitar datos de un programa ejecutado en un servidorweb. CGI especifica un estandar para transferir datos entre el cliente y el programa. Es un mecanismo de comunicación entre el servidor web y una aplicación externa cuyo resultado final de la ejecución son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el nombre de CGIs.

Las aplicaciones CGI fueron una de las primeras maneras prácticas de crear contenido dinamico para las paginas web. En una aplicación CGI, el servidor web pasa las solicitudes del cliente a un programa externo. Este programa puede estar hecho en cualquier lenguaje que soporte el servidor, aunque por razones de portabilidad se suelen usar lenguage script. La salida de dicho programa es enviada al cliente en lugar del archivo estático tradicional.

CGI ha hecho posible la implementación de funciones nuevas y variadas en las páginas web, de tal manera que esta interfaz rápidamente se volvió un estándar, siendo implementada en todo tipo de servidores web.

SNORT

es un sniffer capaz de actuar como sistema de detección de intrusos en redes de tráfico moderado; su facilidad de configuración, su adaptabilidad, sus requerimientos mínimos (funciona en diferentes Unices, incluyendo un simple PC con Linux, Solaris o cualquier BSD gratuito), y sobre todo su precio (se trata de un software completamente gratuito que podemos descargar desde su página oficial en INet, http://www.snort.org/) lo convierten en una óptima elección en multitud de entornos, frente a otros sistemas como NFR (Network Flight Recorder) o ISS RealSecure que, aunque quizás sean más potentes, son también mucho más pesados e infinitamente más caros.

Para instalar un sistema de detección de intrusos basado en SNORT en primer lugar necesitamos evidentemente este programa, que podemos descargar desde su página web. Además, para compilarlo correctamente es necesario disponer de las librerías libpcap, un interfaz para tratamiento de paquetes de red desde espacio de usuario, y es recomendable también (aunque no obligatorio) instalar Libnet, librería para la construcción y el manejo de paquetes de red. Con este software correctamente instalado en nuestro sistema, la compilación de SNORT sera muy buena.

el SNORT se clasifica como un IDS basado en red y que funciona mediante detección de usos indebidos. Estos usos indebidos - o cuanto menos sospechosos - se reflejan en una base de datos formada por patrones de ataques; dicha base de datos se puede descargar también desde la propia página web de SNORT, donde además se pueden generar bases de patrones `a medida' de diferentes entornos (por ejemplo, ataques contra servidores web, intentos de negaciones de servicio, exploits...). El archivo que utilicemos en nuestro entorno será la base para el correcto funcionamiento de nuestro sistema de detección de intrusos.

Honey NET

Para finalizar este punto dedicado a los sistemas de detección de intrusos basados en red es necesario hablar de las honeynets - literalmente, `redes de miel' -. Se trata de un concepto muy parecido al de los honeypots, de los que ya hemos hablado, pero extendido ahora a redes completas: redes diseñadas para ser comprometidas, formadas por sistemas reales de todo tipo que, una vez penetrados, permiten capturar y analizar las acciones que está realizando el atacante para así poder aprender más sobre aspectos como sus técnicas o sus objetivos. Realmente, aunque la idea general sea común, existen dos grandes diferencias de diseño entre un tarro de miel y una honeynet: por un lado, esta última evidentemente es una red completa que alberga diferentes entornos de trabajo, no se trata de una única máquina; por otro, los sistemas dentro de esta red son sistemas reales, en el sentido de que no simulan ninguna vulnerabilidad, sino que ejecutan aplicaciones típicas (bases de datos, sistemas de desarrollo...) similares a las que podemos encontrar en cualquier entorno de trabajo `normal'. El objetivo de una honeynet no es la decepción, sino principalmente conocer los movimientos de un pirata en entornos semireales, de forma que aspectos como sus vulnerabilidades o sus configuraciones incorrectas se puedan extrapolar a muchos de los sistemas que cualquier empresa posee en la actualidad; de esta forma podemos prevenir nuevos ataques exitosos contra entornos reales.

En el funcionamiento de una `red de miel' existen dos aspectos fundamentales y especialmente críticos, que son los que introducen la gran cantidad trabajo de administración extra que una honeynet implica para cualquier organización. Por un lado, tenemos el control del flujo de los datos: es vital para nuestra seguridad garantizar que una vez que un sistema dentro de la honeynet ha sido penetrado, este no se utilice como plataforma de salto para atacar otras máquinas, ni de nuestra organización ni de cualquier otra; la `red de miel' ha de permanecer perfectamente controlada, y por supuesto aislada del resto de los segmentos de nuestra organización. En segundo lugar, otro aspecto básico es la captura de datos, la monitorización de las actividades que un atacante lleva a cabo en la honeynet. Recordemos que nuestro objetivo principal era conocer los movimientos de la comunidad pirata para poder extrapolarlos a sistemas reales, por lo que también es muy importante para el correcto funcionamiento de una honeynet una correcta recogida de datos generados por el atacante: ha de ser capturada toda la información posible de cada acción, de una forma poco agresiva (esto es, sin tener que realizar grandes cambios en cada uno de los sistemas) y por supuesto sin que el atacante se entere. Además (muy importante), estos datos recogidos nunca se han de mantener dentro del perímetro de la honeynet, ya que si fuera así cualquier pirata podría destruirlos con una probabilidad demasiado elevada.

El concepto de honeynet es relativamente nuevo dentro del mundo de la seguridad y, en concreto, de los sistemas de detección de intrusos; a pesar de ello, se trata de una idea muy interesante que presumiblemente va a extenderse de una forma más o menos rápida cada día más, las herramientas de seguridad no se conforman con detectar problemas conocidos, sino que tratan de anticiparse a nuevas vulnerabilidades que aún no se han publicado pero que pueden estar - y de hecho están - presentes en multitud de sistemas. Conocer cuanto antes cualquier avance de la comunidad underground es algo vital si queremos lograr este objetivo.

QUE ES HONEYNET

Los Honeynet son un tipo especial de honeypots de alta interacción que actúan sobre una red entera, diseñada para ser atacada y recobrar así mucha más información sobre posibles atacantes. Se usan equipos reales con sistemas operativos reales y corriendo aplicaciones reales.

Este tipo de honeypots se usan principalmente para la investigación de nuevas técnicas de ataque y para comprobar el modus-operandi de los intrusos.

Tipos Honeypots

Honeypots de baja interactividad:
Los honeypot de baja interactividad son instalados para emular sistemas operativos o servicios con los cuales los atacantes están acostumbrados a infringir. El atacante cree que se encuentra un servicio o una maquina cuando realmente es una aplicación escrita para hacerse pasar por tal. En este su estado de captura es muy bajo relacionado con los de alta interactividad.
Honeypots de alta interactividad:

En estos el atacante puede interactuar de forma total, es decir no emulan servicios son servicios reales, se suele montar en maquinas virtuales, o en otras maquinas, pues de esta forma estaríamos evitando el ingreso real a nuestras maquinas, su configuración es mas difícil, pero igual captura comandos, pulsaciones, trafico, etc.

IDS

¿Que es un sistema de detección de intrusos "IDS"?

La seguridad en un sistema podríamos clasificarla de dos modos: activa y preventiva. La seguridad activa de un sistema consiste en protegerlo todo lo posible ante potenciales intentos de abuso del mismo. Un firewall es un buen ejemplo de seguridad activa, trata de filtrar el acceso a ciertos servicios en determinadas conexiones para evitar el intento de forzamiento desde alguno de ellos.

Por otro lado, la seguridad preventiva es aquella que implantamos en nuestro sistema para que nos informe si en el está teniendo lugar una incidencia de seguridad. No pretende proteger el sistema, pretende alertarnos de que algo extraño esta sucediendo en el. Un buen ejemplo de seguridad preventiva es un sistema de detección de intrusos.

Un sistema de detección de intrusos es aquel que nos permite recabar información de distintas fuentes del sistema en el que se implanta para alertar de un posible intrusión en nuestras redes o máquinas. La alerta puede ser del hecho de que existe un intento de intrusión, como del modo en el que este se está realizando y en algunos casos por parte de quén esta siendo efectuado. Podemos considerar un sistema de detección de intrusos como un control de auditoría que nos permitirá tomar decisiones a la hora de realizar una auditoría de seguridad de nuestro sistema.

Un sistema de detección de intrusos surge como una medida preventiva, nunca como una medida para asegurar nuestros sistemas, ayudan al administrador de dicho sistema a permanecer al tanto de cualquier intención aviesa contra el sistema que administra.

tipos de IDS

Existen tres tipos de sistemas de detección de intrusos:

1. HIDS (HostIDS): un IDS vigilando un único ordenador y por tanto su interfaz corre en modo no promiscuo. La ventaja es que la carga de procesado es mucho menor.
2. NIDS (NetworkIDS): un IDS basado en red, detectando ataques a todo el segmento de la red. Su interfaz debe funcionar en modo promiscuo capturando así todo el tráfico de la red.
3. DIDS (DistributedIDS): sistema basado en la ARQUITECTURA CLIENTE-SERVIDOR compuesto por una serie de NIDS (IDS de redes) que actúan como sensores centralizando la información de posibles ataques en una unidad central que puede almacenar o recuperar los datos de una base de datos centralizada. La ventaja es que en cada NIDS se puede fijar unas reglas de control especializándose para cada segmento de red. Es la estructura habitual en redes privadas virtueles (VPN)

Sistemas de Decepcion

Los sistemas de decepción o tarros de miel (honeypots), como Deception Toolkit (DTK), son mecanismos encargados de simular servicios con problemas de seguridad de forma que un pirata piense que realmente el problema se puede aprovechar para acceder a un sistema, cuando realmente se está aprovechando para registrar todas sus actividades. Se trata de un mecanismo útil en muchas ocasiones como por ejemplo, para conseguir "entretener" al atacante mientras se tracea su conexión