some ipfw filter does not function under Release 6.3
jguojun at gmail.com
Sun Nov 16 13:21:22 PST 2008
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 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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
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 184.108.40.206, 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:
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.
More information about the freebsd-questions