nmap findet keine lebenden Hosts mit Ping-Scan

Ich versuche, mein lokales Netzwerk mit nmap per Ping zu scannen, aber es scheint keine Computer zu finden, die mit Sicherheit am Leben sind. Es reagiert auf Ping, aber weiter auf Ping-Scan.

Ergebnisse für 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

Und Ausgabe von 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

Aber wenn ich versuche, nmap zu verwenden, wird es trotz empfangener Antwort nicht angezeigt.

$ 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

Tcpdump-Ausgabe:

$ 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

Warum sagt nmap, dass der Host nicht verfügbar ist, wenn er auf Anfragen reagiert?

Bearbeiten

Nmap-Version:

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

Die erste Filterregel in der Firewall lautet natürlich:

pass quick on fxp0

Habe es gerade mit meinem OpenBSD 5.1 versucht. Ja, Sie haben FreeBSD 7.4, aber wir sprechen von einem ziemlich ähnlichen Biest.

Als normaler Benutzer nmap -sn my.hostkehrt er auch Host seems downfür mich zurück, obwohl mein Testgerät sicherlich als regulärer Benutzer auf Ping reagiert.

As root nmap -sn my.hostkehrt jedoch Host is upwie gewünscht zurück.

Wenn Sie sich Ihre Eingabeaufforderung ansehen, versuchen Sie wahrscheinlich auch, nmap als Nicht-Root-Benutzer zu verwenden. Versuchen Sie, ob nmap als root funktioniert.

BEARBEITEN: Habe gerade mein FreeBSD 9.0 gestartet, dort funktioniert der nmap Ping Scan gut als Nicht-Root.

Meine erste Beobachtung wäre, dass tcpdump -i fxp0die Pakete, die auf dem ankommen, ausgegeben werden fxp0, jedoch nmapals Userspace-Prozess ausgeführt werden. Daher könnte eine Reihe von Dingen verhindern, dass nmap die Antwort sieht.

1. wie eine Netzfilterregel (Benutzer iptables -t filter -n -L)
2. selinux (Ich habe diese spezielle Sache nicht gesehen, aber Selinux ist immer eine gute Wette, wenn dummes Scheiße passiert
3. Überprüfen Sie auch die iptables nat-Tabellen, um sicherzugehen iptables -t nat -n -L

Ich hatte gerade das gleiche Problem und löste es mit teilweiser Hilfe von hier.

Ich habe ein neues, kopfloses RaspberryPi mit WLAN-Dongle eingerichtet und die SD-Karte bearbeitet, um meine WLAN-Anmeldeinformationen in wpa_supplicant.conf abzulegen.

Das RPi wurde gut gebootet und mit WiFi verbunden, aber der nmap-Ping-Scan auf meinem Ubuntu-Laptop hat es erst gefunden, als ich ZWEI Dinge getan habe:

1. gebraucht sudo
2. hat die Option hinzugefügt --disable-arp-ping