Vuelvo, de nuevo, a la serie que sobre los preprocesdores de Snort comenzamos con la primera parte como introducción, Snort. Preprocesadores. frag3 y Snort. Preprocesadores. Stream4 / Stream5. Parte 1.
Recordad que decíamos…. «Los preprocesadores, básicamente, son unos módulos, añadidos o plugins que usa Snort para arreglar, rearmar, modificar tramas que vienen del decodificador de paquetes antes de que pasen por el motor de detección y las reglas. Pero dónde se sitúan, como actúan, que preprocesadores tiene Snort y como funcionan….»
En esta ocasión estudiaremos sfportscan. Este preprocesador tiene como función detectar acciones que conforman la fase de descubrimiento como escenario previo a un ataque a nuestra red, es decir, se encarga de detectar scan de puertos.
Introducción a SfPortscan.
SfPortscan es capaz de detectar escaneos TCP, UDP, IP, Decoys, sweep scan, etc. (ver artículo relacionado: NetGrok, InetVis, Scapy y Nmap. Detección y visualización scan de puertos. Parte I) Además, se diseñó, tomando en cuenta, sobre todo, los escaneos basados en la herramienta nmap. Por tanto, y como ya os he indicado, es capaz de detectar:
Para su uso es necesario lo siguiente:
- Tener activado el proprocesador stream5 (por defecto lo está).
Esto es así porque sfPortscan necesita de el para inspeccionar el portocolo UDP, protocolo no orientado conexión. Para ello necesita un seguimiento de las sesiones UDP.
Además es neciesario para algunas configuraciones de sfPortscan como ignore-scanners y include-midstream.
Configuración de sfPortscan.
Vamos a tomar como base Snort 2.8.5 y una configuración muy básica. La explicamos y avanzamos.
La síntáxis es la siguiente:
preprocessor sfportscan: proto { all } \
memcap { 10000000 } \
sense_level { medium } \
scan_type { all } \
logfile { scan.log }
- proto. aquí indicamos que protocolo queremos que inspeccione para detectar un scas. Podemos usar tcp, udp, ip, all (todos).
- memcap. máxima cantidad de memoria a usar por sfportscan expresada en bytes. A mayor cantidad, mayor capacidad de detección.
- sense_level. ajustamos aquí el nivel de sensibilidad de la detección. Podemos usar low, medium o high. Es importante este ajuste para no generar falsos positivos / negativos. Dependiendo del nivel indicado, podrá en proprocesador detectar mayor número de scans pero a cambio de la generación de falsas alertas.
- scan_type. Aquí indicamos el tipos de escaneo a detectar. Podemos usar portsweep, decoy_portscan, distributed_portscan, o all (todos).
- logfile. nombre del fichero donde sfPortscan almacenará los logs de alertas.
Junto a estas directivas u opciones, podemos usar otras como:
- watch-ip. indica a sfportscan que máquinas/hosts o redes vamos a inspeccionar. Los demás se ignoran para la detección. Podemos usar, por ejemplo una IP, varias o redes con notación CIDR. Además podemos indicar qué puertos serán inspeccionados.
- ignore-scanners. prácticamente igual que watch-ip pero para ignorar IPs, redes y/o puertos en la detección en caso de que se identifiquen como escaners activos, es decir, el origen del escaneo.
- ignore-scanned. para ignorar IPs, redes, puertos que son objetivos de un escaneo.
Otras dos directivas, que están por defecto desactivas son:
- detect-ack-scans. para la detección de ACK scan. Hace uso, como hemos comentado de stream5.
- include-midstream. para análisis de sesiones en punto intermedio. También hace uso de stream5.
Un ejemplo de configuración sería:
preprocessor sfportscan:
proto { all } \
scan_type { all } \
memcap { 10000000 } \
sense_level { medium } \
logfile { portscan.log } \
ignore_scanners { 192.168.1.107, 192.168.1.108 } \
ignore_scanned { 192.168.100.0/24}
Log sfPortscaner.
La información que se almacena en el archivo incluído en la directiva logfile, es la siguiente, vemos las más importantes:
Time: 12/01-18:26:47.259010
event_ref: 0
213.96.140.208 -> 192.168.1.5 (portscan) UDP Distributed Portscan
Priority Count: 30
Connection Count: 30
IP Count: 30
Scanner IP Range: 213.96.140.9:213.96.140.254
Port/Proto Count: 30
Port/Proto Range: 178:207
- Time. marca de tiempo
- event_ref.
- IP origen > IP destino
la siguientes son:
- Priority Count.
- Connection Count.
- IP Count.
- Port/ProtoCount
que hay que entenderlas, básicamente, según las relaciones entre ellas de la siguiente forma:
Las pruebas.
¿ Sería capaz sfPortscan de detectar un scan de puerto realizado mediante Scapy ?. Vamos a verlo.
Prueba 1.
ans,unans=sr(IP(src=RandIP(‘213.96.140.0/24′),dst=’192.168.1.5’)/UDP(dport=[(1,1024)]),inter=0.5,retry=3,timeout=1)
Detectado como:
Time: 12/01-18:26:47.259010
event_ref: 0
213.96.140.208 -> 192.168.1.5 (portscan) UDP Distributed Portscan
Priority Count: 30
Connection Count: 30
IP Count: 30
Scanner IP Range: 213.96.140.9:213.96.140.254
Port/Proto Count: 30
Port/Proto Range: 178:207
Time: 12/01-18:28:18.443931
event_ref: 0
213.96.140.99 -> 192.168.1.5 (portscan) UDP Distributed Portscan
Priority Count: 30
Connection Count: 31
IP Count: 31
Scanner IP Range: 213.96.140.26:213.96.140.255
Port/Proto Count: 31
Port/Proto Range: 355:385
Time: 12/01-18:29:49.139014
event_ref: 0
213.96.140.175 -> 192.168.1.5 (portscan) UDP Distributed Portscan
Priority Count: 30
Connection Count: 30
IP Count: 29
Scanner IP Range: 213.96.140.7:213.96.140.234
Port/Proto Count: 30
Port/Proto Range: 533:562
Time: 12/01-18:31:20.324751
event_ref: 0
213.96.140.12 -> 192.168.1.5 (portscan) UDP Distributed Portscan
Priority Count: 30
Connection Count: 30
IP Count: 29
Scanner IP Range: 213.96.140.6:213.96.140.254
Port/Proto Count: 30
Port/Proto Range: 711:740
Como veis lo detecta como un UDP Distributed Portscan; justamente lo que es.
Prueba 2.
Realizamos un scan con nmap:
nmap -sS -sV -P0 192.168.1.5
Y el resultado es:
Time: 12/13-12:26:07.141727
event_ref: 0
192.168.1.106 -> 192.168.1.5 (portscan) TCP Portscan
Priority Count: 10
Connection Count: 15
IP Count: 1
Scanner IP Range: 192.168.1.106:192.168.1.106
Port/Proto Count: 15
Port/Proto Range: 22:8888
Prueba 3.
nmap -sS 192.168.1.5 -e eth0 -T4 -p1-1024 -S 213.96.160.32
Time: 12/13-13:12:08.538949
event_ref: 0
213.96.160.32 -> 192.168.1.5 (portscan) TCP Portscan
Priority Count: 10
Connection Count: 15
IP Count: 2
Scanner IP Range: 192.168.1.106:213.96.160.32
Port/Proto Count: 15
Port/Proto Range: 25:587
Aquí vemos como detecta el scan, pero además ,nos informa de la verdadera IP del origen del scan (192.168.1.106), también la dirección spoofeada (213.96.160.32).
Ahora vamos a usar el mismo ejemplo que en el artículo dedicado a InetVis, usando varias opciones y decoys:
nmap -sS 192.168.1.5 -e eth0 -T5 –host-timeout 5m –max-retries 0 –initial-rtt-timeout 25ms –max-rtt-timeout 250ms –max-scan-delay 250ms –scan-delay 10ms –min-hostgroup 32 –max-hostgroup 32 -D 213.96.169.1,213.96.121.213,213.96.160.21,213.96.11.111,213.96.96.1
El resultado:
Time: 12/13-13:17:47.461323
event_ref: 0
213.96.169.1 -> 192.168.1.5 (portscan) TCP Decoy Portscan
Priority Count: 324
Connection Count: 355
IP Count: 355
Scanner IP Range: 192.168.1.106:213.96.169.1
Port/Proto Count: 60
Port/Proto Range: 1:60443
Prueba 4.
Vamos ahora a usar un T2 con nmap usando decoys. Comprobamos si lo detecta sfPorscan:
nmap -sS 192.168.1.5 -e eth0 -T2 -D 213.96.169.1,213.96.121.213,213.96.160.21,213.96.11.111,213.96.96.1
Time: 12/13-13:33:33.531558
event_ref: 0
213.96.169.1 -> 192.168.1.5 (portscan) TCP Decoy Portscan
Priority Count: 323
Connection Count: 355
IP Count: 355
Scanner IP Range: 192.168.1.106:213.96.169.1
Port/Proto Count: 60
Port/Proto Range: 4:61900
Time: 12/13-13:35:03.634939
event_ref: 0
213.96.169.1 -> 192.168.1.5 (portscan) TCP Decoy Portscan
Priority Count: 354
Connection Count: 355
IP Count: 355
Scanner IP Range: 192.168.1.106:213.96.169.1
Port/Proto Count: 60
Port/Proto Range: 85:54045
Time: 12/13-13:36:34.939449
event_ref: 0
213.96.169.1 -> 192.168.1.5 (portscan) TCP Decoy Portscan
Priority Count: 349
Connection Count: 355
IP Count: 355
Scanner IP Range: 192.168.1.106:213.96.169.1
Port/Proto Count: 60
Port/Proto Range: 99:62078
Evadir la detección on scapy.
¿ Podríamos, con scapy, evadir la detección por parte de sfportscan ? Sabemos que con scapy tenemos las siguientes opciones:
- inter intervalo, en segundo, entre paquetes enviados
- retry reintenar de nuevo si los paquetes no obtuvieron respuesta
- timeout tiempo de espera máximo desde el último paquete
Hacemos la prueba. vamos aumentar el inter y lo ponemos a 5 seg. El resultado es:
ans,unans=sr(IP(src=RandIP(‘213.96.140.0/24′),dst=’192.168.1.5’)/UDP(dport=[(1,1024)]),inter=5,retry=3,timeout=1)
[**] [1:402:8] ICMP Destination Unreachable Port Unreachable [**]
[Classification: Misc activity] [Priority: 3]
12/13-12:18:53.412136 0:4:75:ED:89:DF -> 0:13:72:82:C:77 type:0x800 len:0x46
192.168.1.5 -> 213.96.140.65 ICMP TTL:128 TOS:0x0 ID:17517 IpLen:20 DgmLen:56
Type:3 Code:3 DESTINATION UNREACHABLE: PORT UNREACHABLE
** ORIGINAL DATAGRAM DUMP:
213.96.140.65:53 -> 192.168.1.5:29 UDP TTL:64 TOS:0x0 ID:1 IpLen:20 DgmLen:28
Len: 0 Csum: 56380
** END OF DUMP
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0068%5D%5BXref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0790%5D
Vemos arriba una de las respuestas del host objetivo, pero no se registra nada en scan.log.
Otras formas de scan más simples con scapy no son detectados por sfPortscan:
- ACK scan: ans,unans = sr(IP(dst=»192.168.1.5″)/TCP(dport=[80,23],flags=»A»))
- TCP SYN scan: ans,unans = sr(IP(dst=»192.168.1.5″)/TCP(dport=[80,23],flags=»S»))
- Xmas scan: ans,unans = sr(IP(dst=»192.168.1.5″)/TCP(dport=[80,23],flags=»FPU»))
Evadir la detección con nmap.
Sfportscan, en condiciones normales, es muy eficiente en la detección de scan nmap. Pero, usando las opciones de rendimiento / tiempo, es posible que Sfportscan no los detecte.
Ya lo viemos aquí: NetGrok, InetVis, Scapy y Nmap. Detección y visualización scan de puertos. Parte I
pero lo recordamos:
Plantillas T0 – T5 nmap.
¿ Variará el resultado de la gráfica depndiendo del nivel de tasa de envió ?.
Lo vamos a ver. Usaremos T2, y T4 por ejemplo.
Brévemente. Las plantillas -T0-T5 son opciones usan unos determinados valores de rendimiento y tiempo para el escaneo.
La plantilla T2 de Nmap denominada polite, la usaremos en el ejemplo sobre todo porque T0 y T1 pueden causar una ralentización muy grande en el escaneo. Si bien es cierto que T1 y T2 son muy parecidas, difieren en que para T1 el tiempo entre una sonda y otra es de 15 segundos y 0,4 para T2. Una gran diferencia de tiempos. T0 y T1 se usan para evasión de IDS.
Podemos personalizar, ya lo hemos hecho en uno de los ejemplos anteriores, indicando valores exactos para:
- –scan-delay
- –min-hostgroup
- –max-hostgroup
- –min-rate
- –max-rate
- –min-parallelism
- –max-parallelism
- –min-rtt-timeout
- –max-rtt-timeout
- –initial-rtt-timeout
- –max-retries
- –host-timeout
Por ejemplo. Para explicarlo algo mejor:
–host-timeout para especificar el tiempo máximo que nmap espera una respuesta. Se puede especificar en milisegundos si no se añade opción alguna o en segundos y minutos e incluso horas (s,m,h). De esta forma si un host tarda en responder o simplemente no esta «activo», no tenemos porqué perder tiempo. Ejemplo: –host-timeout 100s.
–scan-delay para el tiempo de espera entre un «scan» o sonda y otro para limitar tráfico, etc.
Así pues, si usamos la plantilla T1, junto a P0 (no hace ping) y -f (para fragmentación):
nmap -sS -P0 -F -T1 -f 192.168.1.5
En este caso sfPortscan no detectará nada.
Y alert.ids que dice…
El fichero donde se almacenan los logs de Snort, procedentes de las alertas generadas según las reglas que tengamos activas, no siempre nos informará que estamos sufriendo un scan de puertos. Es muy posible que se generen otro tipo de alertas, por ejemplo:
En algunos casos, un scan -sS de nmap, puede generar alertas del tipo:
[**] [1:1418:13] SNMP request tcp [**]
[Classification: Attempted Information Leak] [Priority: 2]
12/13-17:48:15.755516 0:4:75:ED:89:C3 -> 0:4:75:ED:89:DF type:0x800 len:0x3C
192.168.1.30:59319 -> 192.168.1.5:161 TCP TTL:55 TOS:0x0 ID:51212 IpLen:20 DgmLen:44
******S* Seq: 0x4DA5FCBA Ack: 0x0 Win: 0x1000 TcpLen: 24
TCP Options (1) => MSS: 1460
[**] [1:1418:13] SNMP request tcp [**]
[Classification: Attempted Information Leak] [Priority: 2]
12/13-17:48:15.869662 0:4:75:ED:89:C3 -> 0:4:75:ED:89:DF type:0x800 len:0x3C
192.168.1.30:59320 -> 192.168.1.5:161 TCP TTL:58 TOS:0x0 ID:20996 IpLen:20 DgmLen:44
******S* Seq: 0x4DA4FCBB Ack: 0x0 Win: 0xC00 TcpLen: 24
TCP Options (1) => MSS: 1460
[**] [1:1420:13] SNMP trap tcp [**]
[Classification: Attempted Information Leak] [Priority: 2]
12/13-17:48:15.876955 0:4:75:ED:89:C3 -> 0:4:75:ED:89:DF type:0x800 len:0x3C
192.168.1.30:59319 -> 192.168.1.5:162 TCP TTL:43 TOS:0x0 ID:62776 IpLen:20 DgmLen:44
******S* Seq: 0x4DA5FCBA Ack: 0x0 Win: 0x1000 TcpLen: 24
TCP Options (1) => MSS: 1460
Para otros tipos, podemos obterner alertas de SNMP AgentX/tcp request. Pero esto es otra historia… y lo veremos en otro artículo.
Enlaces relacionados con scan y detección de scan de puertos y alertas e interpretacion de alertas Snort:
NetGrok, InetVis, Scapy y Nmap. Detección y visualización scan de puertos. Parte I
Scapy. Manipulación avanzada e interactiva de paquetes. Parte 6
Snort. Formato, tipos e interpretación de las alertas. Actualización.
===
Hasta aquí por hoy. En otra ocasión realizaremos algunas otras perrerias a sfportscan. Hasta la próxima.
Seguridad y Redes 