PREPROCESSOR SSLPP
Este modulo decodifica el trafico SSL y TLS, solamente sobre una conexión plenamente establecida, es decir, por defecto este preprocessor intentará determinar si una conexión dada ha sido completamente establecida con un “Handshake”, una vez inspecciona que el trafico se encuentra cifrado, no inspecciona los datos sobre la conexión establecida. Para realizar esto, el preprocessor inspecciona el trafico en ambos lados (cliente y servidor) si uno de los dos lados responde con indicios de que algo no ha ido bien en el establecimiento del handshake la sesión no es marcada como encriptada, esto le permitirá a Snort verificar dos cosas, en primer lugar que el ultimo paquete handshake enviado por el cliente no ha sido creado para evadir las reglas de Snort y por otro lado que el trafico ha sido legítimamente cifrado.
Finalmente, en algunos casos es posible que la única respuesta observable desde un endpoint sean los ACK’s especialmente cuando hay perdida de paquetes, si es posible “confiar” en el trafico encriptado de una maquina servidora, este trafico puede ser marcado como confiable y de este modo Snort podrá marcar el trafico como cifrado y legitimo, esto se hace con el uso de la propiedad “trustservers”. A continuación se indican las opciones disponibles en SSLPP
| ports {<puerto> <puerto>} | Puertos a inspeccionar. Por defecto SSLPP inspecciona los siguientes: 443 HTTPS , 465 SMTPS , 563 NNTPS , 636 LDAPS , 989 FTPS , 992 TelnetS , 993 IMAPS , 994 IRCS , 995 POPS |
| noinspect_encrypted | Desactiva la inspección sobre trafico que esta encriptado. |
| trustservers | Desactiva el requisito de que el trafico deba ser inspeccionado en ambos lados de la sesión antes de que esta sea marcada como encriptada por Snort, Si los servidores no se encuentran comprometidos (algo de lo que no siempre podemos estar seguros) permite mejorar un poco el desempeño, por otro lado tiene que estar activada la opción noinspect_encrypted |
Este preprocessor solamente cuenta con las opciones anteriormente indicadas, sin embargo para que tengan efecto, también hay que asegurarse que algunas reglas en Snort se encuentran activadas, en concreto, estas reglas son: ssl_version y ssl_state
ssl_version
Indica la versión SSL utilizada en ambos lados de la conexión, se puede especificar mas de un único valor separados por coma, ejemplos validos pueden ser:
ssl_version:sslv3;
ssl_version:tls1.0,tls1.1,tls1.2;
ssl_version:!sslv2;
El ultimo indica que no se debe utilizar SSLv2, los valores soportados son:
version = [«!»] «sslv2» | «sslv3» | «tls1.0» | «tls1.1» | «tls1.2»
ssl_state
Indica el estado de una conexión SSL durante el paso de reconocimiento (hello) y el intercambio de claves, del mismo modo que ssl_version, se permite especificar más de un valor esperados por coma, ejemplos validos pueden ser:
ssl_state:client_hello;
ssl_state:client_keyx,server_keyx;
ssl_state:!server_hello;
Los valores soportados son:
state = [«!»] «client_hello» | «server_hello» | «client_keyx» | «server_keyx» | «unknown»
Por ultimo, un ejemplo del uso de este Preprocessor puede ser el siguiente:
| 1. Preprocessor activado y no inspecciona trafico encriptado (noinspect_encrypted)preprocessor ssl: noinspect_encrypted
2.Preprocessor activado, inspecciona el trafico sobre los puertos 8081 y 9010 (ports), No inspecciona trafico encriptado (noinspect_encrypted) preprocessor ssl: \ports { 8081 9010} \ noinspect_encrypted |
PREPROCESSOR ARP SPOOF
Este preprocessor es útil para identificar posibles ataques ARP, realiza la decodificación de paquetes ARP y detecta del mismo modo inconsistencias en el mapeo de direcciones Ethernet a direcciones IP
Su funcionamiento es uno de los más simples de todos los preprocessors anteriormente indicados, a continuación se indica su uso con las alternativas de configuración disponibles:
| 1. Sin realizar detección unicast ni monitoreo de mapeo ARP, Solamente buscará inconsistencias en direcciones Ethernet.preprocessor arpspoof
2. Sin realizar detección unicast pero realizando monitoreo de mapeo ARP, especificando una dirección IP y una dirección física (MAC) de esta forma, Snort mapea dirección IP y dirección Física evitando ataques de Poisoned ARP en un segmento de red determinado. preprocessor arpspoof preprocessor arpspoof_detect_host: 192.168.1.34 fe80::a00:27ff:fe3d:d197 3. Realizando detección unicast y realizando monitoreo de mapeo ARP, especificando una dirección IP y una dirección física (MAC) de esta forma, Snort mapea dirección IP y dirección Física evitando ataques de Spoofing ARP en un segmento de red determinado preprocessor arpspoof : -unicast preprocessor arpspoof_detect_host: 192.168.1.33 54:42:49:fa:c1:0d preprocessor arpspoof_detect_host: 192.168.1.34 2a:49:af:d5:1d:ca
|
Ahora bien, para probar el preprocessor anterior, basta con realizar una simple prueba con arpspoof se trata de una herramienta que permite realizar envenenamiento de ARP contra maquinas en un segmento de red, (para ver más detalles sobre arpspoof y dsniff ver aquí)
En primera instancia se intenta realizar un ataque de envenenamiento de ARP, Asumiendo que la dirección 192.168.1.1 corresponde al router del segmento de red:
| >arpspoof -i eth0 -t 192.168.1.34 192.168.1.1>arpspoof -i eth0 -t 192.168.1.1 192.168.1.34 |
La respuesta de Snort después de ejecutar los comandos anteriores, serán una serie de alarmas por cada intento de envenenamiento que ejecute arpspoof, similares a las que se enseñan a continuación:
| ….06/23-19:56:12.863567 [**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**]06/23-19:56:29.186786 [**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**]…. |
Como puede apreciarse, el preprocessor ha detectado inconsistencias sobre el mapeo de las direcciones IP y MAC y ha alertado sobre el ataque que se esta llevando a cabo.
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 