Firewall rules

Robert Downes nullentropy at lineone.net
Tue Jun 15 17:33:34 PDT 2004


JJB wrote:

>Fundamentally his keep-state rules work and yours don't.
>
I have used his script exactly, modifying only for the differences in my 
ISP's addresses. Everything works as before, and still the check-state 
rule is showing zero packets and zero bytes, even though keep-state 
rules have been triggered. Are you sure this is not just a quirk of IPFW?

>  The use of
>the skipto rule to control what ip address goes into the dynamic
>keep-state table, IE the lan ip or the natd public ip.  The bottom
>line is native ipfw with natd and stateful rules does not work
>together at all, unless you do some gymnastics with skipto rule so
>the dynamic keep-state table always has the private lan ip address
>for matching against.
>
Yes, this is the mechanism I cannot find a clear explanation for. Can 
you recommend a link to a page that defines how IPFW stumbles on NAT and 
keep-state, because I've read and re-read the IPFW man page, and it does 
me no good whatsoever.

> If you want the max in firewall protection you
>need stateful rules to monitor the bi-directional exchange of
>session packets conversation so forged packets can not be inserted.
>  
>
I agree.

>My recommendation is to scrap your rule file and use the posted
>archive example with changes for your network. Like the 2 lan nic
>cards, lo0 interface, and the correct public facing nic card
>interface for the via interface name.
>
I've done that. Much better ruleset, but I still cannot see how it is 
handling NAT + keep-state any differently.

>  Second problem is you are
>allowing every thing out your firewall. This is very bad as it
>allows out any trojons or spy-ware from windows boxs on your lan so
>thet can report their harvested info to the person who planted them.
>Take control of your firewall and only allow out the exact services
>you know you are using.
>
No arguments there. I'm running ZoneAlarm on all Windows boxes, but it's 
still better to aim for traffic to be killed on sight by the router.

-- 
Bob



More information about the freebsd-questions mailing list