O nmap não encontra hosts ativos com verificação de ping

12

Eu tento executar o ping na minha rede local usando o nmap, mas não parece encontrar máquinas que estejam com certeza vivas. Ele responde ao ping, mas ao ping.

Resultados para ping:

$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=1.585 ms

E saída do tcpdump:

$ tcpdump -i fxp0 -n host 192.168.0.2
12:43:07.624911 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 61023, seq 0, length 64
12:43:07.625029 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 61023, seq 0, length 64

Mas quando tento usar o nmap, ele não o vê, apesar de receber resposta.

$ nmap -sn 192.168.0.2

Starting Nmap 5.61TEST5 ( http://nmap.org ) at 2012-05-13 12:44 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.02 seconds

Saída tcpdump:

$ tcpdump -i fxp0 -n host 192.168.0.2
12:45:30.742933 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 2715, seq 0, length 8
12:45:30.742974 IP 192.168.0.222.36388 > 192.168.0.2.443: S 3607279099:3607279099(0) win 1024 <mss 1460>
12:45:30.743001 IP 192.168.0.222.36388 > 192.168.0.2.80: . ack 3607279099 win 1024
12:45:30.743025 IP 192.168.0.222 > 192.168.0.2: ICMP time stamp query id 45449 seq 0, length 20
12:45:30.743061 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 2715, seq 0, length 8
12:45:30.743097 IP 192.168.0.2.443 > 192.168.0.222.36388: S 2602942480:2602942480(0) ack 3607279100 win 5840 <mss 1460>
12:45:30.743130 IP 192.168.0.222.36388 > 192.168.0.2.443: R 3607279100:3607279100(0) win 0
12:45:30.743134 IP 192.168.0.2.80 > 192.168.0.222.36388: R 3607279099:3607279099(0) win 0
12:45:30.743148 IP 192.168.0.2 > 192.168.0.222: ICMP time stamp reply id 45449 seq 0: org 00:00:00.000, recv 11:04:04.243, xmit 11:04:04.243, length 20
12:45:32.745245 IP 192.168.0.222 > 192.168.0.2: ICMP time stamp query id 48722 seq 0, length 20
12:45:32.745281 IP 192.168.0.222.36389 > 192.168.0.2.80: . ack 3607344634 win 1024
12:45:32.745307 IP 192.168.0.222.36389 > 192.168.0.2.443: S 3607344634:3607344634(0) win 1024 <mss 1460>
12:45:32.745340 IP 192.168.0.2 > 192.168.0.222: ICMP time stamp reply id 48722 seq 0: org 00:00:00.000, recv 11:04:06.245, xmit 11:04:06.245, length 20
12:45:32.745380 IP 192.168.0.2.80 > 192.168.0.222.36389: R 3607344634:3607344634(0) win 0
12:45:32.745401 IP 192.168.0.2.443 > 192.168.0.222.36389: S 2629695507:2629695507(0) ack 3607344635 win 5840 <mss 1460>
12:45:32.745421 IP 192.168.0.222.36389 > 192.168.0.2.443: R 3607344635:3607344635(0) win 0
12:45:32.745431 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 38289, seq 0, length 8
12:45:32.745517 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 38289, seq 0, length 8

Por que o nmap diz que o host parece desativado quando responde a solicitações?

Editar

Versão do Nmap:

$ nmap --version

Nmap version 5.61TEST5 ( http://nmap.org )
Platform: i386-portbld-freebsd7.4
Compiled with: liblua-5.1.5 openssl-0.9.8q libpcre-8.30 libpcap-0.9.8 nmap-libdnet-1.12 ipv6
Compiled without:

Para ter certeza, a primeira regra de filtro no firewall é:

pass quick on fxp0

networking ping nmap

— aadam
fonte

Este não é um comportamento normal. Se você verificar tudo Tom H menciona em sua resposta abaixo e ainda tem o problema, enviar a saída nmap --version, nmap --ifliste que você postou aqui para nmap-dev@insecure.org, lista de discussão dos desenvolvedores do Nmap.

— Bonsaiviking

4

Apenas tentei isso com o meu OpenBSD 5.1. Sim, você tem o FreeBSD 7.4, mas estamos falando de uma fera parecida.

Como usuário comum, também nmap -sn my.hostretorna Host seems downpara mim, embora minha máquina de teste certamente responda ao ping como usuário comum.

Como raiz, no entanto, nmap -sn my.hostretorna Host is upcomo deveria.

Olhando para o seu prompt, você provavelmente também está tentando nmap como um usuário não root. Tente se o nmap funcionar como raiz.

EDIT: Apenas iniciei o FreeBSD 9.0, o nmap ping scan funciona bem como não root.

— Janne Pikkarainen
fonte

1

Minha primeira observação seria que tcpdump -i fxp0está despejando os pacotes que chegam no fxp0, mas nmapestá sendo executado como um processo de espaço do usuário, portanto, várias coisas podem impedir o nmap de ver a resposta.

como uma regra netfilter (usuário iptables -t filter -n -L)
selinux (não vi essa coisa em particular, mas o selinux é sempre uma boa aposta quando isso acontece
verifique também as tabelas nat do iptables para ter certeza iptables -t nat -n -L

— Tom H
fonte

umm. é fxp0 bsd? nenhuma idéia então ...

— Tom H

1

se você estiver em experimentar o Linux está sob strace e ver se ele dá-lhe mais de uma pista ...strace -t -e trace=network nmap -sn 192.168.0.2

— Tom H

OS é FreeBSD. Atualizei a pergunta original com a versão do nmap e informações sobre a regra do firewall.

— Aadam

1

Eu apenas tive esse mesmo problema e o resolvi com ajuda parcial daqui.

Configurei um novo RaspberryPi decapitado com dongle WiFi e editei o cartão SD para colocar minhas credenciais WiFi em wpa_supplicant.conf.

O RPi inicializou e se conectou ao WiFi muito bem, mas a verificação de nmap ping no meu laptop Ubuntu não a encontrou até que eu fiz DUAS coisas:

usava sudo
adicionou a opção --disable-arp-ping

— Rob K
fonte