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
