Diferencia entre “open”, “closed” y “filtered” en nmap

Al realizar un escaneo de puertos con nmap podemos obtener 3 posibles resultados: open, closed y filtered. Vamos a ver que es cada uno y como devolver según nos interese.

Un ejemplo de resultado de nmap es el siguiente:

# nmap -sS -p T80-82 10.10.10.11

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-02 09:23 CET
Interesting ports on systemadmin.es (10.10.10.11):
PORT   STATE    SERVICE
80/tcp open     http
81/tcp closed   hosts2-ns
82/tcp filtered xfer

Puerto en estado open

Para el caso que considera el puerto open vemos como mediante el escaneo de nmap con un TCP SYN (opción -sS) lo considera abierto cuando se intercambian un SYNC:

# tcpdump -nni eth0 'host 10.10.10.22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:37:05.181394 IP 10.10.10.22.57049 > 10.10.10.11.80: . ack 4160220446 win 1024
09:37:05.181458 IP 10.10.10.11.80 > 10.10.10.22.57049: R 4160220446:4160220446(0) win 0
09:37:05.330649 IP 10.10.10.22.57026 > 10.10.10.11.80: S 1534929235:1534929235(0) win 4096 <mss 1460>
09:37:05.330689 IP 10.10.10.11.80 > 10.10.10.22.57026: S 577548275:577548275(0) ack 1534929236 win 5840 <mss 1460>
09:37:05.330853 IP 10.10.10.22.57026 > 10.10.10.11.80: R 1534929236:1534929236(0) win 0

La conexión no queda establecida porque no se manda el ACK del SYNC que manda el servidor destino, sino que se manda un RESET. Una conexión completa tendría esta forma:

09:48:33.974473 IP 10.10.10.22.49275 > 10.10.10.11.80: S 17458123:17458123(0) win 5840 <mss 1460,sackOK,timestamp 1629969320 0,nop,wscale 7>
09:48:33.974563 IP 10.10.10.11.80 > 10.10.10.22.49275: S 2788705600:2788705600(0) ack 17458124 win 5792 <mss 1460,sackOK,timestamp 812523620 1629969320,nop,wscale 6>
09:48:33.974793 IP 10.10.10.22.49275 > 10.10.10.11.80: . ack 1 win 46 <nop,nop,timestamp 1629969320 812523620>

Puerto en estado filtered

Para el caso que el puerto se considera filtered vemos como va mandando SYNCs pero no responde ni con un RESET ni con un SYNC o se manda un mensaje ICMP tipo 3 (unreachable):

# tcpdump -nni eth0 'host 10.10.10.22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:24:02.607261 IP 10.10.10.22.43045 > 10.10.10.11.82: S 2786441433:2786441433(0) win 5840 <mss 1460,sackOK,timestamp 1629602427 0,nop,wscale 7>
09:24:05.618959 IP 10.10.10.22.43045 > 10.10.10.11.82: S 2786441433:2786441433(0) win 5840 <mss 1460,sackOK,timestamp 1629603178 0,nop,wscale 7>
09:24:11.638496 IP 10.10.10.22.43045 > 10.10.10.11.82: S 2786441433:2786441433(0) win 5840 <mss 1460,sackOK,timestamp 1629604678 0,nop,wscale 7>
09:24:23.669523 IP 10.10.10.22.43045 > 10.10.10.11.82: S 2786441433:2786441433(0) win 5840 <mss 1460,sackOK,timestamp 1629607678 0,nop,wscale 7>
09:24:47.727050 IP 10.10.10.22.43045 > 10.10.10.11.82: S 2786441433:2786441433(0) win 5840 <mss 1460,sackOK,timestamp 1629613678 0,nop,wscale 7>

Este comportamiento suele indicar que se ha establecido una política de DROP o que el servidor esta caído (no escucha la red):

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 81 -j DROP

En el caso que se use la política de REJECT también se considera filtered. En este caso se manda un ICMP tipo 3:

12:20:10.434115 IP 10.10.10.22.63549 > 10.10.10.11.82: S 3640754468:3640754468(0) win 4096 <mss 1460>
12:20:10.434161 IP 10.10.10.11 > 10.10.10.22: ICMP 10.10.10.11 tcp port 82 unreachable, length 52

El comando de iptables sería:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 81 -j REJECT

Puerto en estado closed

Para el caso de considerar el puerto closed vemos como devuelve un RESET:

# tcpdump -nni eth0 'host 10.10.10.22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:22:37.860344 IP 10.10.10.22.39720 > 10.10.10.11.81: S 1310154393:1310154393(0) win 5840 <mss 1460,sackOK,timestamp 1629581294 0,nop,wscale 7>
09:22:37.860409 IP 10.10.10.11.81 > 10.10.10.22.39720: R 0:0(0) ack 1310154394 win 0

Con iptables también se puede simular este comportamiento indicando que al target REJECT que lo haga con un TCP-RESET:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 81 -j REJECT --reject-with tcp-reset