From owner-freebsd-ipfw@FreeBSD.ORG Sun Nov 16 21:21:22 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D8C51065678 for ; Sun, 16 Nov 2008 21:21:22 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by mx1.freebsd.org (Postfix) with SMTP id 572758FC16 for ; Sun, 16 Nov 2008 21:21:22 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: (qmail 8867 invoked from network); 16 Nov 2008 21:21:22 -0000 Received: from unknown (HELO ?192.168.2.14?) (jguojun@75.37.2.43 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 16 Nov 2008 21:21:21 -0000 X-YMail-OSG: QESFeQkVM1mr0EnDpQoxke59ut1H7VCXsikGqKa3qiTaSqZc5Gia29L53cApYNw4VrmyankZtN5iKkLVdTgehFky5QK01LLIhb_OGIW4gbdzXVWjHsU_iO_xFkSFik879UJEl1Gfx4rPoMlUldBF9owMzkdoICmQl6kNfOPU.sFqodda7lP4E8mmIZaT X-Yahoo-Newman-Property: ymail-3 Message-ID: <49208ECC.5020008@gmail.com> Date: Sun, 16 Nov 2008 13:21:16 -0800 From: "Jin Guojun[VFF]" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20071201 X-Accept-Language: en, zh, zh-CN MIME-Version: 1.0 To: Ian Smith References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> <491F6466.40309@gmail.com> <20081116224655.J70117@sola.nimnet.asn.au> In-Reply-To: <20081116224655.J70117@sola.nimnet.asn.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, questions@freebsd.org Subject: Re: some ipfw filter does not function under Release 6.3 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2008 21:21:22 -0000 Ian Smith wrote: >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? > > Let's clear this little bit. Above rule order actually worked after machine is rebooted. I do not know whay it was not working when changed rule 65330 from 00330. This may be another bug. But again, after rebooting the machine, this rule order works. This demonstrates that rule order 00330 did not block the Sync packet as it supposed to do. You also mentioned and confirmed it should do in this way below, ---------- working order --------- 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 ---------- Non working order --------- 00330 2018 983473 allow tcp from any to any established 00566 0 0 deny ip from 221.192.199.36 to any 65535 0 0 deny ip from any to any -------------------------------------------------- > > 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. > > We see this (Sync only packet) passed through, so this is the problem. Because once Sync packet is passed through, the receiver will respond Sync/ACK, then attacker knows the machine is in service. >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. > > We saw this too, from 221.192.199.36, but I did not complain for this. Becasue we do not bother since receiving machine will not respond it. Attacker also sends bogus Reset packets, and the FreeBSD ignores it too. So, this is not the problem. >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 > > It does not matter if this is a fake machine or victim machine, ipfw should always block it as instructed to do so. We cannot give it mercy and let it pass through becasue it is a victim. Otherwise, we will be the victim :-) That is why I filed PR for problem for rule order 00330-00566-65535. I did not say rule order 00566-65330-65535 is the problem in the PR. Hopefully, this makes clear. BTW, the ipfw machine is the gateway (between WAN-LAN). Rest machines are behind it on LAN.