nmap ne trouve pas d'hôtes vivants avec l'analyse ping

12

J'essaie de faire un ping sur mon réseau local à l'aide de nmap, mais il ne semble pas trouver de machines qui sont sûrement vivantes. Il répond au ping mais au ping.

Résultats pour 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

Et sortie de 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

Mais lorsque j'essaie d'utiliser nmap, il ne le voit pas malgré la réception de la réponse.

$ 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

Sortie 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

Pourquoi nmap dit que l' hôte semble arrêté lorsqu'il répond aux demandes?

Éditer

Version 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:

Pour être sûr, la première règle de filtrage dans le pare-feu est:

pass quick on fxp0
networking ping nmap aadam
la source
Ce n'est pas un comportement normal. Si vous vérifiez tout Tom H mentionne dans sa réponse ci - dessous et ont encore le problème, envoyez la sortie nmap --version, nmap --iflistet ce que vous avez publié ici pour [email protected], la liste de diffusion des développeurs Nmap.
bonsaiviking

Réponses:

4

Je viens de l'essayer avec mon OpenBSD 5.1. Oui, vous avez FreeBSD 7.4, mais nous parlons d'une bête assez similaire.

En tant qu'utilisateur régulier, nmap -sn my.hostrevient aussi Host seems downpour moi, même si ma machine de test répond sûrement au ping en tant qu'utilisateur régulier.

En tant que root, cependant, nmap -sn my.hostrenvoie Host is upcomme il se doit.

En regardant votre invite, vous essayez probablement également de nmap en tant qu'utilisateur non root. Essayez si nmap fonctionne en tant que root.

EDIT: Je viens de lancer mon FreeBSD 9.0, le scan ping nmap fonctionne bien en tant que non root.

Janne Pikkarainen
la source
1

Ma première observation serait de tcpdump -i fxp0vider les paquets qui arrivent sur le fxp0, mais nmapfonctionne comme un processus de l'espace utilisateur, donc un certain nombre de choses pourraient empêcher nmap de voir la réponse.

  1. comme une règle netfilter (utilisateur iptables -t filter -n -L)
  2. selinux (pas vu cette chose en particulier, mais selinux est toujours un bon pari quand une merde stupide se produit
  3. vérifiez également les tables nat iptables pour être sûr iptables -t nat -n -L
Tom H
la source
euh. est fxp0 bsd? aucune idée alors ...
Tom H
1
si vous êtes sous linux, essayez est sous strace et voyez si cela vous donne plus d'un indice ...strace -t -e trace=network nmap -sn 192.168.0.2
Tom H
Le système d'exploitation est FreeBSD. J'ai mis à jour la question d'origine avec la version nmap et des informations sur la règle de pare-feu.
aadam
1

Je viens d'avoir ce même problème et je l'ai résolu avec une aide partielle à partir d'ici.

J'ai installé un nouveau RaspberryPi sans tête avec un dongle WiFi et j'ai modifié la carte SD pour mettre mes informations d'identification WiFi dans wpa_supplicant.conf.

Le RPi a démarré et s'est connecté au WiFi très bien, mais le scan ping nmap sur mon ordinateur portable Ubuntu ne l'a trouvé que lorsque j'ai fait DEUX choses:

  1. utilisé sudo
  2. ajouté l'option --disable-arp-ping
Rob K
la source