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
