Re: nmap Issue on 3.8-release?
On Sun, Feb 05, 2006 at 10:03:57PM -0500, Melameth, Daniel D. wrote: Joachim Schipper wrote: On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. Look into what the return packets actually contain. If, for instance, the remote end is a OpenBSD firewall that has been configured explicitly to drop nmap (using pf's passive OS recognition feature, for instance), you'd see exactly what you see now. (Discarding OpenBSD for a while, almost any decent firewall can be configured to drop traffic that looks like it came from nmap.) And the return packets are not too useful - is that first icmp packet an echo reply or a destination-unreachable notice? And the TCP packet - is it a SYN/ACK or RST packet? The remote end is an OpenBSD machine that has not been configured to drop nmap packets and allows incoming ssh and http connections. On second thought, I'd not certain why I made tcpdump quiet--habit perhaps. Here is the same test with more verbosity: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-05 19:43 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.163 seconds $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms $ sudo tcpdump -ni pppoe0 host 208.139.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:43:01.507785 209.180.x.x 208.139.x.x: icmp: echo request 19:43:01.507980 209.180.x.x.60199 208.139.x.x.80: . ack 2409580574 win 1024 19:43:01.595748 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:01.600100 208.139.x.x.80 209.180.x.x.60199: R 2409580574:2409580574(0) win 0 (DF) 19:43:02.520065 209.180.x.x 208.139.x.x: icmp: echo request 19:43:02.520244 209.180.x.x.60200 208.139.x.x.80: . ack 2829011038 win 1024 19:43:02.609989 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:02.611334 208.139.x.x.80 209.180.x.x.60200: R 2829011038:2829011038(0) win 0 (DF) 19:43:37.650310 209.180.x.x 208.139.x.x: icmp: echo request 19:43:37.735247 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:38.660020 209.180.x.x 208.139.x.x: icmp: echo request 19:43:38.743035 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:39.669973 209.180.x.x 208.139.x.x: icmp: echo request 19:43:39.759944 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:40.679970 209.180.x.x 208.139.x.x: icmp: echo request 19:43:40.766399 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:41.689986 209.180.x.x 208.139.x.x: icmp: echo request 19:43:41.781991 208.139.x.x 209.180.x.x: icmp: echo reply $ sudo tcpdump -ni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG So the return packets are definitely coming back, but nmap is not seeing them. (On the TCP end, it appears nmap is sending an ACK and the target is send a RST.) Looks strange. Unless I am mistaken, though, you check the output of nmap against a trace of ping. Could you please post a tcpdump for nmap? Also, check /etc/pf.conf for any rules marked block without being marked log; and please post your routing table if it's interesting. Joachim
Re: nmap Issue on 3.8-release?
On Mon 2006.02.06 at 20:31 +0100, Joachim Schipper wrote: On Sun, Feb 05, 2006 at 10:03:57PM -0500, Melameth, Daniel D. wrote: Joachim Schipper wrote: On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. Look into what the return packets actually contain. If, for instance, the remote end is a OpenBSD firewall that has been configured explicitly to drop nmap (using pf's passive OS recognition feature, for instance), you'd see exactly what you see now. (Discarding OpenBSD for a while, almost any decent firewall can be configured to drop traffic that looks like it came from nmap.) And the return packets are not too useful - is that first icmp packet an echo reply or a destination-unreachable notice? And the TCP packet - is it a SYN/ACK or RST packet? The remote end is an OpenBSD machine that has not been configured to drop nmap packets and allows incoming ssh and http connections. On second thought, I'd not certain why I made tcpdump quiet--habit perhaps. Here is the same test with more verbosity: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-05 19:43 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.163 seconds $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms $ sudo tcpdump -ni pppoe0 host 208.139.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:43:01.507785 209.180.x.x 208.139.x.x: icmp: echo request 19:43:01.507980 209.180.x.x.60199 208.139.x.x.80: . ack 2409580574 win 1024 19:43:01.595748 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:01.600100 208.139.x.x.80 209.180.x.x.60199: R 2409580574:2409580574(0) win 0 (DF) 19:43:02.520065 209.180.x.x 208.139.x.x: icmp: echo request 19:43:02.520244 209.180.x.x.60200 208.139.x.x.80: . ack 2829011038 win 1024 19:43:02.609989 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:02.611334 208.139.x.x.80 209.180.x.x.60200: R 2829011038:2829011038(0) win 0 (DF) 19:43:37.650310 209.180.x.x 208.139.x.x: icmp: echo request 19:43:37.735247 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:38.660020 209.180.x.x 208.139.x.x: icmp: echo request 19:43:38.743035 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:39.669973 209.180.x.x 208.139.x.x: icmp: echo request 19:43:39.759944 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:40.679970 209.180.x.x 208.139.x.x: icmp: echo request 19:43:40.766399 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:41.689986 209.180.x.x 208.139.x.x: icmp: echo request 19:43:41.781991 208.139.x.x 209.180.x.x: icmp: echo reply $ sudo tcpdump -ni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG So the return packets are definitely coming back, but nmap is not seeing them. (On the TCP end, it appears nmap is sending an ACK and the target is send a RST.) Looks strange. Unless I am mistaken, though, you check the output of nmap against a trace of ping. Could you please post a tcpdump for nmap? Also, check /etc/pf.conf for any rules marked block without being marked log; and please post your routing table if it's interesting. i too would look at pf(4) - disable it, pass quick, no state, log, whatever; but look at your state table. also, you may have mentioned this before, but what arch is this on?
Re: nmap Issue on 3.8-release?
Okan Demirmen wrote: On Mon 2006.02.06 at 20:31 +0100, Joachim Schipper wrote: On Sun, Feb 05, 2006 at 10:03:57PM -0500, Melameth, Daniel D. wrote: Joachim Schipper wrote: On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. Look into what the return packets actually contain. If, for instance, the remote end is a OpenBSD firewall that has been configured explicitly to drop nmap (using pf's passive OS recognition feature, for instance), you'd see exactly what you see now. (Discarding OpenBSD for a while, almost any decent firewall can be configured to drop traffic that looks like it came from nmap.) And the return packets are not too useful - is that first icmp packet an echo reply or a destination-unreachable notice? And the TCP packet - is it a SYN/ACK or RST packet? The remote end is an OpenBSD machine that has not been configured to drop nmap packets and allows incoming ssh and http connections. On second thought, I'd not certain why I made tcpdump quiet--habit perhaps. Here is the same test with more verbosity: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-05 19:43 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.163 seconds $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms $ sudo tcpdump -ni pppoe0 host 208.139.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:43:01.507785 209.180.x.x 208.139.x.x: icmp: echo request 19:43:01.507980 209.180.x.x.60199 208.139.x.x.80: . ack 2409580574 win 1024 19:43:01.595748 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:01.600100 208.139.x.x.80 209.180.x.x.60199: R 2409580574:2409580574(0) win 0 (DF) 19:43:02.520065 209.180.x.x 208.139.x.x: icmp: echo request 19:43:02.520244 209.180.x.x.60200 208.139.x.x.80: . ack 2829011038 win 1024 19:43:02.609989 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:02.611334 208.139.x.x.80 209.180.x.x.60200: R 2829011038:2829011038(0) win 0 (DF) 19:43:37.650310 209.180.x.x 208.139.x.x: icmp: echo request 19:43:37.735247 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:38.660020 209.180.x.x 208.139.x.x: icmp: echo request 19:43:38.743035 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:39.669973 209.180.x.x 208.139.x.x: icmp: echo request 19:43:39.759944 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:40.679970 209.180.x.x 208.139.x.x: icmp: echo request 19:43:40.766399 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:41.689986 209.180.x.x 208.139.x.x: icmp: echo request 19:43:41.781991 208.139.x.x 209.180.x.x: icmp: echo reply $ sudo tcpdump -ni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG So the return packets are definitely coming back, but nmap is not seeing them. (On the TCP end, it appears nmap is sending an ACK and the target is send a RST.) Looks strange. Unless I am mistaken, though, you check the output of nmap against a trace of ping. Could you please post a tcpdump for nmap? The full tcpdump of nmap is reflected in the first eight full lines directly above. Also, check /etc/pf.conf for any rules marked block without being marked log; and please post your routing table if it's interesting. There is really only one block rule and it
Re: nmap Issue on 3.8-release?
FWIW, it appears the issue only happens in relation to the pppoe interface--meaning, nmap scans over wi and fxp work as expected. Melameth, Daniel D. wrote: Okan Demirmen wrote: On Mon 2006.02.06 at 20:31 +0100, Joachim Schipper wrote: On Sun, Feb 05, 2006 at 10:03:57PM -0500, Melameth, Daniel D. wrote: Joachim Schipper wrote: On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. Look into what the return packets actually contain. If, for instance, the remote end is a OpenBSD firewall that has been configured explicitly to drop nmap (using pf's passive OS recognition feature, for instance), you'd see exactly what you see now. (Discarding OpenBSD for a while, almost any decent firewall can be configured to drop traffic that looks like it came from nmap.) And the return packets are not too useful - is that first icmp packet an echo reply or a destination-unreachable notice? And the TCP packet - is it a SYN/ACK or RST packet? The remote end is an OpenBSD machine that has not been configured to drop nmap packets and allows incoming ssh and http connections. On second thought, I'd not certain why I made tcpdump quiet--habit perhaps. Here is the same test with more verbosity: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-05 19:43 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.163 seconds $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms $ sudo tcpdump -ni pppoe0 host 208.139.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:43:01.507785 209.180.x.x 208.139.x.x: icmp: echo request 19:43:01.507980 209.180.x.x.60199 208.139.x.x.80: . ack 2409580574 win 1024 19:43:01.595748 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:01.600100 208.139.x.x.80 209.180.x.x.60199: R 2409580574:2409580574(0) win 0 (DF) 19:43:02.520065 209.180.x.x 208.139.x.x: icmp: echo request 19:43:02.520244 209.180.x.x.60200 208.139.x.x.80: . ack 2829011038 win 1024 19:43:02.609989 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:02.611334 208.139.x.x.80 209.180.x.x.60200: R 2829011038:2829011038(0) win 0 (DF) 19:43:37.650310 209.180.x.x 208.139.x.x: icmp: echo request 19:43:37.735247 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:38.660020 209.180.x.x 208.139.x.x: icmp: echo request 19:43:38.743035 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:39.669973 209.180.x.x 208.139.x.x: icmp: echo request 19:43:39.759944 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:40.679970 209.180.x.x 208.139.x.x: icmp: echo request 19:43:40.766399 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:41.689986 209.180.x.x 208.139.x.x: icmp: echo request 19:43:41.781991 208.139.x.x 209.180.x.x: icmp: echo reply $ sudo tcpdump -ni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG So the return packets are definitely coming back, but nmap is not seeing them. (On the TCP end, it appears nmap is sending an ACK and the target is send a RST.) Looks strange. Unless I am mistaken, though, you check the output of nmap against a trace of ping. Could you please post a tcpdump for
Re: nmap Issue on 3.8-release?
Joachim Schipper wrote: On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: I don't get it--it appears nmap is broken. Perhaps I'm overlooking something obvious, but any thoughts appreciated... An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=84.497 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=82.354 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=87.825 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=85.699 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:45:49.671358 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:49.674068 208.139.x.x.80 209.180.x.x.57989: tcp 0 (DF) 19:45:50.683407 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:50.691346 208.139.x.x.80 209.180.x.x.57985: tcp 0 (DF) 19:46:00.565862 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:01.565834 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:02.573631 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:03.589132 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:04.596986 208.139.x.x 209.180.x.x: icmp: 0 0 $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. Look into what the return packets actually contain. If, for instance, the remote end is a OpenBSD firewall that has been configured explicitly to drop nmap (using pf's passive OS recognition feature, for instance), you'd see exactly what you see now. (Discarding OpenBSD for a while, almost any decent firewall can be configured to drop traffic that looks like it came from nmap.) And the return packets are not too useful - is that first icmp packet an echo reply or a destination-unreachable notice? And the TCP packet - is it a SYN/ACK or RST packet? The remote end is an OpenBSD machine that has not been configured to drop nmap packets and allows incoming ssh and http connections. On second thought, I'd not certain why I made tcpdump quiet--habit perhaps. Here is the same test with more verbosity: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-05 19:43 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.163 seconds $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms $ sudo tcpdump -ni pppoe0 host 208.139.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:43:01.507785 209.180.x.x 208.139.x.x: icmp: echo request 19:43:01.507980 209.180.x.x.60199 208.139.x.x.80: . ack 2409580574 win 1024 19:43:01.595748 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:01.600100 208.139.x.x.80 209.180.x.x.60199: R 2409580574:2409580574(0) win 0 (DF) 19:43:02.520065 209.180.x.x 208.139.x.x: icmp: echo request 19:43:02.520244 209.180.x.x.60200 208.139.x.x.80: . ack 2829011038 win 1024 19:43:02.609989 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:02.611334 208.139.x.x.80 209.180.x.x.60200: R 2829011038:2829011038(0) win 0 (DF) 19:43:37.650310 209.180.x.x 208.139.x.x: icmp: echo request 19:43:37.735247 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:38.660020 209.180.x.x 208.139.x.x: icmp: echo request 19:43:38.743035 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:39.669973 209.180.x.x 208.139.x.x: icmp: echo request 19:43:39.759944 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:40.679970 209.180.x.x 208.139.x.x: icmp: echo request 19:43:40.766399 208.139.x.x 209.180.x.x: icmp: echo reply 19:43:41.689986 209.180.x.x 208.139.x.x: icmp: echo request 19:43:41.781991 208.139.x.x 209.180.x.x: icmp: echo reply $ sudo tcpdump -ni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG So the return
Re: nmap Issue on 3.8-release?
On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: I don't get it--it appears nmap is broken. Perhaps I'm overlooking something obvious, but any thoughts appreciated... An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=84.497 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=82.354 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=87.825 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=85.699 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:45:49.671358 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:49.674068 208.139.x.x.80 209.180.x.x.57989: tcp 0 (DF) 19:45:50.683407 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:50.691346 208.139.x.x.80 209.180.x.x.57985: tcp 0 (DF) 19:46:00.565862 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:01.565834 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:02.573631 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:03.589132 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:04.596986 208.139.x.x 209.180.x.x: icmp: 0 0 $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. This is normal behaviour (at least with the many 3.* versions I have used). Nmap checks for open ports like http (look at your tcpdump output) and does not always rely on icmp. Nothing OpenBSD specific, you have that on a linux box, too. Tobias
Re: nmap Issue on 3.8-release?
Sorry if I wasn't clear--I agree. The issue here is not the behavior of nmap, but the fact that nmap does not see the icmp and http responses from the target and assumes the host is offline. Tobias Ulmer wrote: On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: I don't get it--it appears nmap is broken. Perhaps I'm overlooking something obvious, but any thoughts appreciated... An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=84.497 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=82.354 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=87.825 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=85.699 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:45:49.671358 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:49.674068 208.139.x.x.80 209.180.x.x.57989: tcp 0 (DF) 19:45:50.683407 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:50.691346 208.139.x.x.80 209.180.x.x.57985: tcp 0 (DF) 19:46:00.565862 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:01.565834 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:02.573631 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:03.589132 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:04.596986 208.139.x.x 209.180.x.x: icmp: 0 0 $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. This is normal behaviour (at least with the many 3.* versions I have used). Nmap checks for open ports like http (look at your tcpdump output) and does not always rely on icmp. Nothing OpenBSD specific, you have that on a linux box, too.
Re: nmap Issue on 3.8-release?
On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote: I don't get it--it appears nmap is broken. Perhaps I'm overlooking something obvious, but any thoughts appreciated... An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=84.497 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=82.354 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=87.825 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=85.699 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:45:49.671358 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:49.674068 208.139.x.x.80 209.180.x.x.57989: tcp 0 (DF) 19:45:50.683407 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:50.691346 208.139.x.x.80 209.180.x.x.57985: tcp 0 (DF) 19:46:00.565862 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:01.565834 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:02.573631 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:03.589132 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:04.596986 208.139.x.x 209.180.x.x: icmp: 0 0 $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next. Look into what the return packets actually contain. If, for instance, the remote end is a OpenBSD firewall that has been configured explicitly to drop nmap (using pf's passive OS recognition feature, for instance), you'd see exactly what you see now. (Discarding OpenBSD for a while, almost any decent firewall can be configured to drop traffic that looks like it came from nmap.) And the return packets are not too useful - is that first icmp packet an echo reply or a destination-unreachable notice? And the TCP packet - is it a SYN/ACK or RST packet? Joachim
nmap Issue on 3.8-release?
I don't get it--it appears nmap is broken. Perhaps I'm overlooking something obvious, but any thoughts appreciated... An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Which I follow up with a: $ ping -c 5 208.139.x.x PING 208.139.x.x (208.139.x.x): 56 data bytes 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=84.497 ms 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=82.354 ms 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=87.825 ms 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=85.699 ms --- 208.139.x.x ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms Running while the above is happening, tcpdumps yield: $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 19:45:49.671358 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:49.674068 208.139.x.x.80 209.180.x.x.57989: tcp 0 (DF) 19:45:50.683407 208.139.x.x 209.180.x.x: icmp: 0 0 19:45:50.691346 208.139.x.x.80 209.180.x.x.57985: tcp 0 (DF) 19:46:00.565862 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:01.565834 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:02.573631 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:03.589132 208.139.x.x 209.180.x.x: icmp: 0 0 19:46:04.596986 208.139.x.x 209.180.x.x: icmp: 0 0 $ sudo tcpdump -qni pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG I'm not certain where to look next.
Re: nmap Issue on 3.8-release?
Nick Guenther wrote: On 2/3/06, Melameth, Daniel D. [EMAIL PROTECTED] wrote: I don't get it--it appears nmap is broken. Perhaps I'm overlooking something obvious, but any thoughts appreciated... An nmap scan gives me this: $ sudo nmap 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 19:45 MST Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up) scanned in 2.109 seconds Try following the suggestion: $ sudo nmap -P0 208.139.x.x and then if that still doesn't work, post again. Perhaps nmap has a different sort of ping than the standard? Same issue... It's as if nmap is blind to the return packets... $ sudo nmap -P0 208.139.x.x Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03 20:30 MST All 1663 scanned ports on 208.139.x.x (208.139.x.x) are: filtered Nmap finished: 1 IP address (1 host up) scanned in 338.874 seconds $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER 20:30:30.036433 208.139.x.x.80 209.180.x.x.58108: tcp 0 (DF) 20:30:30.052043 208.139.x.x.22 209.180.x.x.58108: tcp 0 (DF) 20:30:32.059800 208.139.x.x.22 209.180.x.x.58109: tcp 0 (DF) 20:30:32.066842 208.139.x.x.80 209.180.x.x.58109: tcp 0 (DF) $ sudo tcpdump -nqi pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG
