Date: Sun, 16 Nov 2008 23:48:39 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Jin Guojun[VFF]" <jguojun@gmail.com> Cc: questions@freebsd.org Subject: Re: some ipfw filter does not function under Release 6.3 Message-ID: <20081116224655.J70117@sola.nimnet.asn.au> In-Reply-To: <491F6466.40309@gmail.com> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> <491F6466.40309@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Nov 2008, Jin Guojun[VFF] wrote: > I think this is a bug in ipfw because after change the rule order, the > problem persists: > 00566 26 3090 deny ip from 221.192.199.36 to any > 65330 2018 983473 allow tcp from any to any established > 65535 0 0 deny ip from any to any Are you saying that the packets shown below from 221.192.199.36 arrived =after= you added rule 566, which denys all traffic from that address? Are you showing us your entire ruleset; it is just those three rules? Is the tcpdump shown running on the same box as ipfw, or another box? If another box, how is it connected through the firewall, to the net? Which machine performs NAT for your network? None of this is obvious. Please show output of 'ifconfig' and 'netstat -rn' on the ipfw box? > 15:47:21.238720 IP 221.192.199.36.4469 > 192.168.2.14.80: S > 3191960249:3191960249(0) win 65535 <mss 1452,nop,nop,sackOK> > 15:47:21.238768 IP 192.168.2.14.80 > 221.192.199.36.4469: S > 2102254306:2102254306(0) ack 3191960250 win 65535 <mss > 1460,sackOK,eol> > 15:47:21.483754 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win > 65535 > 15:47:21.499489 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) > ack 1 win 65535 > 15:47:24.238570 IP 192.168.2.14.80 > 221.192.199.36.4469: S > 2102254306:2102254306(0) ack 3191960250 win 65535 <mss > 1460,sackOK,eol> > 15:47:24.482113 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win > 65535 > 15:47:24.498613 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) > ack 1 win 65535 > 15:47:30.238574 IP 192.168.2.14.80 > 221.192.199.36.4469: S > 2102254306:2102254306(0) ack 3191960250 win 65535 <mss > 1460,sackOK,eol> > 15:47:30.482746 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win > 65535 > 15:47:30.513193 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) > ack 1 win 65535 > 15:47:42.238577 IP 192.168.2.14.80 > 221.192.199.36.4469: S > 2102254306:2102254306(0) ack 3191960250 win 65535 <mss > 1460,sackOK,eol> > 15:47:42.435040 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) > ack 1 win 65535 > 15:47:42.466055 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win > 65535 > 15:47:54.466599 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) > ack 1 win 65535 > 15:47:59.703272 IP 221.192.199.36.4469 > 192.168.2.14.80: R 206:206(0) > ack 1 win 0 > > Jin Guojun[VFF] wrote: > > But the rule 330 should only allow established TCP pass through. In > other words, Sync should NOT > allowed by rule 330, or I missed something for this rule? > Erik Trulsson wrote: > > On Sat, Nov 15, 2008 at 01:38:02PM -0800, Jin Guojun[VFF] wrote: > > > Below is set of ipfw rules, but it seems that not all rules are > functioning properly. > From rule 361 to first two of rule 567 are not blocking any traffic and > not measuring any traffic. > Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a > known issue in R-6.3? Misattribution here: Erik Trulsson wrote this next paragraph. Please fix your quoting to show clearly who said what .. it will help us all. Can you see why we try to discourage top-posting in the freebsd lists? > In general the first matching rule is the one that is applied. > In your case this means that if a packet matches your rule 330 then > it will be allowed through, and the rules further down the list will > not be considered. Erik is right; you'll have to deny unwanted traffic before allowing the established traffic. 'established' here really means 'not setup', ie not SYN-only packets; ipfw doesn't track TCP sessions, the stack does. People can send bogus established packets, and though they won't have a socket to connect to, they're still inbound traffic you have to receive to even block, which can consume bandwidth and perhaps money. Sometimes these are a result of someone sending TCP setup packets to some other host, with the source address forged as yours .. you get the SYN+ACK packets, which do pass as established through ipfw. It's possible that the host you see as attacking you may itself be victim .. Yes, did I read your PR .. no sign of that host here so far, so it might just be scanning networks a bit closer to home: http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=221.192.199.36&submit=Go > The second and third rules in rule set 567 seem working well. > > -Jin > > ---------------- ipfw rule sets --------- > 00330 3108378 2700826874 allow tcp from any to any established > 00361 0 0 deny ip from 203.83.248.93 to any > 00361 0 0 deny ip from 72.30.142.215 to any > 00567 0 0 deny ip from 193.200.241.171 to any > 00567 0 0 deny ip from 221.192.199.36 to any > 00567 3 180 deny ip from 118.153.18.186 to any > 00567 3 180 deny ip from 203.78.214.180 to any > 00567 0 0 deny ip from 118.219.232.123 to any > 65500 220 20043 allow udp from any to any > 65535 2 120 deny ip from any to any Not much use allowing established tcp traffic if you never allow any setup of tcp sessions? This seems like a partial set of rules .. > ------ traffic captured by tcpdump behind ipfw machine ----- > > 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200229998:200229998(0) win 8192 > 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200229999:200229999(0) win 0 > 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200233658:200233658(0) win 8192 > 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200233659:200233659(0) win 0 > 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200244634:200244634(0) win 8192 > 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200244635:200244635(0) win 0 > 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S > 2422872529:2422872529(0) win 65535 <mss 1452,nop,nop,sackOK> > 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack > 3968474717 win 65535 > 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) > ack 1 win 65535 > 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) > ack 473 win 0 In this (earlier) case, 192.168.2.14 was receiving but apparently not responding to those packets .. whereas above (later) it was responding? More details of your setup might help to dispel these mysteries. cheers, Ian PS removing ipfw@ from ccs .. that's more about ipfw development.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081116224655.J70117>