some ipfw filter does not function under Release 6.3

[Jin Guojun[VFF]]

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.