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 is set to log. As for the route table, I didn't find it interesting, but someone else might: $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 0.0.0.1 UGS 8 1138874 - pppoe0 0.0.0.1 0.0.0.0 UH 1 0 - pppoe0 loopback localhost UGRS 0 0 33224 lo0 localhost localhost UH 1 651 33224 lo0 192.168.255.220/30 link#6 UC 0 0 - fxp0 192.168.255.224/27 link#5 UC 1 0 - wi0 192.168.255.240 0:c:f1:5:ce:6b UHLc 1 601267 - wi0 BASE-ADDRESS.MCAST localhost URS 0 0 33224 lo0 > 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? I just disabled pf and the issue is reproducible. This is on i386.
