Nmap - Resultado intenso vs rápido

Question

Nmap - Resultado intenso vs rápido

#1 de bonsaiviking (7 votos)

9

Heredé una pequeña red y actualmente estoy evaluando su rendimiento de seguridad.

Comencé a escanear puertos en un host (llamémoslo Weirdo ) en esa pequeña red y, desde mi perspectiva, parece que ese host específico tiene algún tipo de detector de escaneo de puertos y / o ofuscador de resultados de escaneo con iptables en marcha, porque el resultado que viene del escaneo intenso difiere mucho del de rápido uno.

Así que aquí el rápido escanea el resultado me@mypc:~# nmap -T4 -F 12.34.56.78 :

Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-18 11:48 CEST
Nmap scan report for 12.34.56.78
Host is up (0.57s latency).
Not shown: 93 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
3306/tcp open  mysql
8080/tcp open  http-proxy
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 4.15 seconds

Esto realmente muestra el mismo resultado que ejecutando el análisis rápido desde Weirdo localhost root@Weirdo:~# nmap -T4 -F localhost .

Pero este es el análisis intenso me@mypc:~# nmap -T4 -A -v 12.34.56.78 :

1/tcp     open  tcpmux?
...(every port is shown as open, except a few)
49155/tcp open  unknown
...
9102/tcp  open  jetdirect?
... 
65389/tcp open  tcpwrapped
...
Completed SYN Stealth Scan at 11:49, 18.22s elapsed (1000 total ports) 
... 
Not shown: 120 closed ports

Nota: ... significa la repetición de la línea anterior con un número de puerto diferente

Básicamente, el análisis intenso encuentra que hay muchos más puertos abiertos, pero esto es paradójico, porque el análisis intenso en el localhost root@Weirdo:~# nmap -T4 -A -v localhost de Weirdo también proporciona la misma lista de puertos abiertos que el rápido escanear.

Cuando miro el traceroute , veo lo siguiente:

TRACEROUTE (using port 199/tcp)
HOP RTT     ADDRESS
1   1.52 ms 12.99.34.255
2   1.37 ms 12.99.0.3
3   1.09 ms 12.34.56.78

Escaneo de puertos en los dos ips con me@mypc:~# nmap -sV -T4 -O -F --version-light 12.99.34.255 12.99.0.3 Veo que 12.99.34.255 es un cortafuegos Netgear Firewall FVS336Gv2 accesible con el navegador (el puerto 80, está abierto por lo tanto).

Un escaneo rápido consecutivo (1 segundo después), después del escaneo intenso produce el mismo resultado que el escaneo intenso.

Después de esperar un par de segundos y luego volver a realizar el análisis rápido, se obtiene el mismo resultado que el análisis rápido inicial.

¿Es probable que este cortafuegos esté jugando con el escaneo intenso?

Otra pequeña adición:

En el host Weirdo reviso el firewall de iptables y obtengo esto:

root@Weirdo:~# iptables -vL -t filter
Chain INPUT (policy DROP 25288 packets, 1768K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 101K   54M ACCEPT     all  --  lo     any     anywhere             anywhere            
 189K   12M ACCEPT     all  --  eth1   any     anywhere             anywhere            
  285  9686 ACCEPT     icmp --  eth0   any     anywhere             anywhere             icmp echo-request
  297 30354 garbage    all  --  eth0   any     anywhere             anywhere             state INVALID
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/NONE
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN/FIN,SYN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: SYN,RST/SYN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,RST/FIN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,ACK/FIN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: PSH,ACK/PSH
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: ACK,URG/URG
1968K 2742M ACCEPT     all  --  eth0   any     anywhere             anywhere             state RELATED,ESTABLISHED
 9564  391K ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:http
  463 27508 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:domain
   45  2392 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:8443
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:9422
25288 1768K garbage    all  --  eth0   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1361K packets, 501M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain garbage (9 references)
 pkts bytes target     prot opt in     out     source               destination

¿Estos filtros reproducen los trucos en el escaneo intenso?

¿Qué significa tener una regla con target garbage ?

firewalls ports nmap iptables

pregunta kiltek 18.04.2017 - 14:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas firewalls ports nmap iptables

Usa el seguimiento de WiFi para identificar a los ladrones Implicaciones de dejar la IU de administrador accesible para usuarios que no son administradores

score 7 · Answer 1

Primero, corrigamos algunas suposiciones y terminología que facilitarán la comprensión de los resultados:

La opción -F es un escaneo "rápido" porque escanea solo 100 puertos. Es el equivalente de --top-ports 100 . Sin esta opción, Nmap escanea 1000 puertos TCP.
La opción -A no es "intensa", sino "Todas las funciones". Es el equivalente de -sV -sC -O --traceroute .

Por lo tanto, ha ejecutado un escaneo de puertos de 100 puertos y lo está comparando con un escaneo de puertos con detección de versiones y huellas digitales de 1000 puertos. Es comprensible que tenga más resultados en el segundo análisis. Pero supongamos que literalmente quisiste decir "todos los puertos están abiertos" en el segundo análisis. ¿Cuál podría ser la causa y cómo podemos estar seguros?

Primero, sería interesante saber si el escaneo -F produce resultados diferentes si ejecuta después de el escaneo -A . Sospecho que lo haría. Esto mostraría entonces que algo (probablemente el firewall) ha cambiado la forma en que se pasan los paquetes entre el sistema de escaneo y el objetivo. Aquí están las pistas que veo en el segundo análisis:

más puertos abiertos
Servicios no identificados ( tcpmux? ) y tcpwrapped servicios
los puertos abiertos enumerados que no están en un escaneo del host local del objetivo

Iptables no es lo suficientemente inteligente como para adaptar un comportamiento como este, y tampoco hay nada en sus reglas que lo demuestre. Por lo tanto, la interferencia probablemente proviene de un sistema diferente en la ruta de la red entre el escáner y el objetivo. Si ha guardado la salida XML ( -oX o -oA ) o ha usado la opción --reason (también activada por -vv o -d ), entonces podría ver detalles sobre por qué Nmap consideró cada puerto abierto o cerrado. La parte más interesante de esto es el atributo reason_ttl , que registra el valor del campo IP Time-to-Live recibido, que normalmente se reduce una vez por cada salto de IP en la ruta de la red. Por lo tanto, para un objetivo de Linux, las respuestas comienzan en TTL 64, y con 2 saltos intermedios deben reducirse a 62. Lo que vea en la versión más precisa del análisis (es decir, el -F scan con puertos en su mayoría cerrados) es su línea de base . Si comienza a ver valores más altos que eso, probablemente significaría que algo entre usted y el objetivo es enviar respuestas en lugar del objetivo. Ejemplo (el puerto 27 es "falso-abierto"):

PORT   STATE    SERVICE REASON
25/tcp open     smtp    syn-ack ttl 60
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp open     http    syn-ack ttl 60

Evitar esto probablemente implicará ralentizar el escaneo para evitar disparar el umbral de alerta "escanear puerto". La evasión de medidas de adaptación como esta es complicada . Pero una vez que haya superado el umbral, puede hacer algunas cosas interesantes para trazar las reglas del firewall.

Si actualmente está siendo "bloqueado" de esta manera con muchos puertos abiertos, pero aún puede acceder a los servicios reales detrás del conjunto original de puertos (ssh, smtp, http, etc.), entonces puede intentar configurar un valor TTL muy bajo en sus paquetes salientes. Cuando un enrutador reduce el TTL a 0, enviará un mensaje ICMP Time Expired, lo que provocará que el puerto esté etiquetado como filtered . Si podemos elegir un TTL que caduque después de el firewall, pero antes de el objetivo, podemos obtener una lista de puertos "abiertos" causados por el firewall, y una conjunto de puertos "filtrados" que probablemente están permitidos a través. En su ejemplo, basado en la salida de traceroute, usaría la opción --ttl 2 , ya que --ttl 3 alcanzaría el objetivo. Entonces el escaneo se vería como: nmap -sS --ttl 2 -Pn example.com . Usualmente no se recomienda usar -Pn , pero en este caso es necesario, ya que las sondas nunca alcanzarán el objetivo. Recordatorio: esta exploración solo producirá resultados útiles si el firewall lo está bloqueando y si el bloqueo no está en todos los puertos, pero está permitiendo el tráfico a través de:

PORT   STATE    SERVICE REASON
25/tcp filtered smtp    time-exceeded from 12.99.34.255 ttl 252
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp filtered http    time-exceeded from 12.99.34.255 ttl 252

En esta salida, el puerto 27 recibió un acuse de recibo sincrónico para que pareciera que provenía del objetivo, aunque sabemos por nuestro --ttl 2 que nuestra sonda nunca hubiera alcanzado el objetivo. Los otros dos puertos están permitidos, ya que recibimos los mensajes de tiempo excedido de cuando expiraron. Si el firewall no permite mensajes de tiempo excedido salientes, entonces se mostrarían como filtered con un motivo no-response .