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 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.)
