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?
