SNORT COMO IDS/IPS EN LINUX
Fuentes Edison, Marcos Ruiz, Caicedo Julio, Erazo Cristian, Tapia Ramiro UNIVERSIDAD TÉCNICA DEL NORTE
FICA-CIERCOM FICA-CIERC OM
Tabla de contenido A. TÍTULO DE LA PRÁCTICA .................................................................................................................. 2 B. INTRODUCCIÓN ............................................................................................................................... 2 C. OBJETIVO DE LA PRÁCTICA .............................................................................................................. 3 General: ........................................................................................................................................... 3 Específicos: ...................................................................................................................................... 3 D. METODOLOGÍA ............................................................................................................................... 3 Marco Teórico ................................................................................................................................. 3 Metodología a seguir ...................................................................................................................... 4 E. RECURSOS MATERIALES Y EQUIPO .................................................................................................. 5 F. DESCRIPCIÓN DEL DESARROLLO DE LA PRÁCTICA............................................................................ 5
Instalación del servidor SNORT en Ubuntu ............................................................................. 5 Configuración como IDS/IPS ...................................................................................................... 6 G. EVALUACIÓN .............................................................................................................................. 8 Snort como un SNIFFER ............................................................................................................. 8 Pruebas denegando protocolo ICMP ............................................................................................ 10 Pruebas denegando protocolo HTTP puerto 80 ............................................................................ 11 Pruebas denegando protocolo FTP puerto 21 .............................................................................. 12 Prueba denegando protocolo SSH puerto 22 ............................................................................... 13 Prueba denegando protocolo TELNET puerto 23.......................................................................... 15 H. BIBLIOGRAFÍA ................................................................................................................................ 16 I. RESULTADOS Y CONCLUSIONES...................................................................................................... 17 Conclusiones: ................................................................................................................................ 17
GUIA DE PRACTICA DE LA BORATORIO
Asignatura: Seguridad en Redes No. de Práctica:
A. TÍTULO DE LA PRÁCTICA SNORT COMO IDS/IPS EN LINUX
B. INTRODUCCIÓN Las herramientas de análisis de tráfico son más o menos sencillas de instalar y configurar; pero la complicación viene a la hora de interpretar los resultados. Para sacar el máximo partido a estas herramientas se necesitan muchos conocimientos de base y una amplia experiencia en protocolos de comunicaciones. Hay un segundo problema: aunque dispongamos de personal tan cualificado, no es humanamente posible revisar una a una todas las conversaciones que ocurren a diario en una red normal. Sobre todo porque la mayoría son interacciones normales, libres de toda sospecha. Los expertos hay que reservarlos para los casos difíciles. Para solucionar ambos problemas existen los sistemas IDS/IPS (Intrusion Detection System/ Intrusion Prevention System). Los IDS detectan los ataques y los IPS actúan contra ellos. Tenemos dos tipos de IDS/IPS: NIDS/NIPS (Network Intrusion y Network Prevention). Buscan ataques sobre servicios de comunicaciones. Se basan en el análisis de los paquetes que forman parte de la comunicación entre dos máquinas, comprobando que se ajustan al protocolo estándar. HIDS/HIPS (Host Intrusion y Host Prevention). Buscan ataques sobre las aplicaciones y el sistema operativo de la máquina. Se basan en el análisis de los procesos actuales (ocupación de CPU y memoria, puertos abiertos) y la configuración y el log de cada uno de los servicios. En este tema vamos a referirnos a los NIDS/NIPS. Estos sistemas procesan un fichero de captura de tráfico (o la realizan ellos mismos) y buscan patrones de comportamiento en los paquetes intercambiados entre los equipos. No se limitan a revisar las cabeceras del protocolo, sino que también miran en el contenido del paquete (payload). Cuando detectan un posible ataque, si es un IDS solo avisa al usuario (como mínimo, fichero de log) y si es un IPS solo responde al ataque (también se puede hacer que los IPS avisen). La respuesta de un IPS puede ser impedir que ese paquete y los siguientes de esa conexión lleguen a su destino. En los más avanzados se puede configurar que permitan que el paquete llegue, pero adecuadamente modificado para que no prospere el ataque.
La inteligencia de estas herramientas suele residir en un conjunto de reglas que se cargan en el programa desde un fichero de configuración. Las reglas son elaboradas por expertos en seguridad que, cuando han identificado un nuevo tipo de ataque, escriben la regla que permitirá al IDS detectarlo.
C. OBJETIVO DE LA PRÁCTICA General: Configurar la herramienta Snort como un IDS/IPS para detectar ataques en un entorno LAN. •
Específicos: Instalar Ubuntu en dos máquinas virtuales para realizar las configuraciones necesarias. Crear reglas para que snort funcione como IPS. Analizar el funcionamiento de snort como una herramienta de seguridad. •
• •
D. METODOLOGÍA Marco Teórico El lenguaje usado por Snort es flexible y potente, basado en una serie de normas que serán las que nos sirvan de guía para la escritura de las reglas. Dentro de estas normas tenemos: -
La descripción de cada regla Cabecera opciones
Uso de preprocesadores Las reglas Snort (Snort Rules) deben ser escritas en una sola línea, de lo contrario habrá que usar el carácter de escape: alert
tcp
any
110 “filename= \”TOMOFONICA.TXT. vbs\””;\
->
(content:
La reglas Snort las podemos dividir en dos secciones lógicas, a saber: cabecera de la regla y opciones:
La cabecera contiene la acción de la regla en sí, protocolo, IPs, máscaras de red, puertos origen y destino y destino del paquete o dirección de la operación. La sección opciones contiene los mensajes y la información necesaria para la decisión a tomar por parte de la alerta en forma de opciones.
Metodología a seguir Topología de la Red utilizada para la práctica.
Como se observa en la figura los servicios que se integran en la figura son los más comunes en una red y para probar la eficacia de un IDS/IPS se proseguirá a denegar cada uno de los servicos y verificar la funcionalidad de la herramienta snort. Para la presente practica se realizarán los siguientes pasos basados en el diagrama de bloques que se presenta a continuación:
La secuencia del diagrama de bloques indica el funcionamiento de la práctica donde el tráfico que entra a la red y luego al host, primero deberá pasar por el servidor snort el cual leerá los paquetes que entran, en el caso de un IPS rechazará la conexión y descartará los paquetes. Cuando se utilice la funcionalidad de IDS cada paquete bloqueado por el software snort será registrado en un archivo que constante mente irá guardando todas las alertas generadas cuando se cumplen las reglas que se configuran.
E. RECURSOS MATERIALES Y EQUIPO Para la siguiente practica se requerirá de los siguientes materiales: 3 SERVIDORES LINUX FTP, HTTP, SHH/TELNET 1 SERVIDOR IDS/IPS
F. DESCRIPCIÓN DEL DESARROLLO DE LA PRÁCTICA Instalación del servidor SNORT en Ubuntu Necesitaremos el ordenador Ubuntu Server (dirección 10.0.1.4) y el Ubuntu Desktop (dirección 10.0.1.3) de la maqueta de red que estamos utilizando a lo largo de esta unidad. En el Ubuntu Server instalaremos la herramienta mediante: # apt-get install snort Durante la instalación nos preguntará algunos parámetros, como la red que queremos controlar. Más adelante podremos cambiar esta primera configuración.
Configuración como IDS/IPS Para nmap vamos a utilizar las reglas del preprocesador. Estas reglas no están en el paquete binario snort que hemos instalado, sino que hay que bajarse las fuentes de la web del producto (www.snort.org). De ese fichero .tar.gz extraemos el directorio preproc _ rules y lo situamos en /etc/snort.
Ya tenemos las reglas. Ahora falta activarlas. En el fichero etc/snort/snort.conf hay que modificar dos líneas (las líneas están, pero comentadas: debemos descomentarlas):
También cambiaremos esta línea, porque solo nos interesa vigilar nuestra subred:
G. EVALUACIÓN Snort como un SNIFFER Los ficheros de configuración están en el directorio /etc/snort, y los ficheros de log en /var/log/snort. La herramienta admite varios modos de funcionamiento. Puede ser un simple sniffer ejecutando: # snort –i eth1
Desde este momento estamos capturando paquetes de la interfaz eth1. Por ejemplo, si entramos en el Ubuntu Desktop y hacemos un ping al Ubuntu Server, veremos los paquetes echo. Por cada paquete aparece la fecha de la captura (con mucha precisión), la IP origen e IP destino del paquete, el tipo de protocolo (en este caso, ICMP) y detalles del protocolo (ECHO, ECHO REPLY). Una vez capturados, Snort pasa los paquetes por varias etapas de procesamiento. Primero los decodifica para identificar el protocolo que siguen. Después aplica un preprocesamiento que deja la información lista para el analizador. Finalmente, genera el resultado del análisis.
Pruebas denegando protocolo ICMP - Para realizar el sistema de detección de intrusos así como también el sistema de prevención de intrusos mediante el protocolo ICMP, procedemos a dar la Alerta colocando icmp en lugar del protocolo tcp, para ello nos ingresamos a la configuración de reglas mediante el siguiente comando: gedit /etc/snort/rules/local.rules. De la misma manera procedemos a colocar un mensaje “ICMP DETECTADO”, cuando se establezca la conexión.
-
Una vez configurado este parámetro, procedemos a guardar la regla y a restaurar el sistema Snort.
-
Desde el usuario con la ip: 192.168.137.164 procedemos a hacer ping a la Ip del servidor: 192.168.137.82. Como podemos observar el mensaje de ICMP DETECTADO se ha registrado exitosamente.
-
Para la visualización de detección a través de la consola, procedemos a activarlo mediante el siguiente comando: snort –A console –i enp0s3 –q –c /etc/snort/snort.conf
-
Procedemos a capturar los paquetes ICMP que se generan desde el usuario al servidor, como se puede observar
Pruebas denegando protocolo HTTP puerto 80 Se agregan las reglas para rechazar las conexiones del servicio web tanto en protocolo TCP como UDP en el puerto 80.
Se muestra que el acceso del servicio web está negado.
Se muestra la alerta para el servicio web.
Se indica la alerta al acceder al servicio web.
Pruebas denegando protocolo FTP puerto 21 Se configura la regla para rechazar el servicio ftp en el puerto 21
A continuación, se indica el acceso rechazado al cliente de ftp.
Se coloca la regla para generar alerta cuando se detecte las conexiones ftp
Se puede apreciar las alertaas al conectar con el servidor ftp.
Prueba denegando protocolo SSH puerto 22 Las reglas se configuran de la siguiente manera para bloquear el servicio ssh.
Accesso remoto por shh rechazado.
Se muestra la configuración para generar alertas cuando se inicie sección por ssh.
Alerta cuadno se conecta por ssh. Función IDS
Prueba denegando protocolo TELNET puerto 23 Regla para el rechazo de telnet.
Conexión remota por telnet rechazada.
Regla para generar alertas para coneciones TelNet. Función IDS.
Muestra la alerta generada cuando se ingresa al escririo de manera remota por el protoloco telnet.
H. BIBLIOGRAFÍA Roesch, M. (1999, November). Snort: Lightweight intrusion detection for networks. In Lisa (Vol. 99, No. 1, pp. 229-238). Coit, C. J., Staniford, S., & McAlerney, J. (2001). Towards faster string matching for intrusion detection or exceeding the speed of snort. In DARPA Information Survivability Conference & Exposition II, 2001. DISCEX'01. Proceedings (Vol. 1, pp. 367-373). IEEE. Caswell, B., & Beale, J. (2004). Snort 2.1 intrusion detection. Syngress. Patton, S., Yurcik, W., & Doss, D. (2001, October). An Achilles’ heel in signature based IDS: Squealing false positives in SNORT. In Proceedings of RAID (Vol. 2001). Buendía, J. F. (2013). Sseguridad Informática. Madrid: Mc Graw Hill Education. Ayuso, J. G. (2012). Protocolos criptográficos y seguridad en redes. México: Rialpa S.A. Aguirre, J. R. (2006). Libro Electrónico de Seguridad Información y Criptografía. Madrid-España. Alulema, D. (Junio de 2008). Estudio y Diseño de un Sistema de Seguridad Perimetral. Quito.
I. RESULTADOS Y CONCLUSIONES Conclusiones: La herramienta Snort permite establecer sistemas de detección de intrusos y prevención de intrusos, constituyendo a la empresa u organización una seguridad básica en la red. De esta manera se puede identificar y bloquear servicios no autorizados en la red. Para la configuración de las reglas se las realiza ingresandoce al fichero siguiente: vi /etc/snort/rules/local.rules en el cual se procede a cambiar Alert para la detección de intrusos, y Reject para la prevención de intrusos. Al realizar la práctic a Snort se pudo analizar 2 tipos de reglas, “Alarm y Reject”, la regla Alarm actúa como un sistema de detección de intrusos, lo cual no permite bloquear la petición simplemente notifica la sesión que se está estableciendo, mientras que la regla Reject actúa como un sistema de prevención de intrusos, permitiendo denegar el servicio cuando un usuario establece la conexión. Los IDS/IPS se asemejan a la seguridad de una Access-list ya que de la misma manera permite bloquear la comunicación al usuario que requiere obtener un servicio como: HTTP, FTP, SSH, etc. Por lo tanto el administrador de la red, estará al tanto de la situación actual que la organización u empresa realiza
