Date: Tue, 20 Jan 2004 21:18:27 -0500 From: "fbsd_user" <fbsd_user@a1poweruser.com> To: "Micheal Patterson" <micheal@tsgincorporated.com>, <freebsd-questions@freebsd.org> Subject: RE: ipfw/nated stateful rules example Message-ID: <MIEPLLIBMLEEABPDBIEGIEGCFFAA.fbsd_user@a1poweruser.com> In-Reply-To: <02d501c3dfc1$796e4da0$0201a8c0@dredster>
next in thread | previous in thread | raw e-mail | index | archive | help
You are doing keep-state on both the Lan interface and the public interface and it only works because the returning public packet is being matched to stateful table entries posted by the Lan interface keep-state rules and not the stateful table entries posted by the external interface. Yes you are making it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. This would never be allowed by an real firewall security professional. If you fell secure in using this method, be my guest. But know it's not really providing you protection for packets inserted by an attacker. It nullifies the benefits of keep state on the interface facing the public internet. -----Original Message----- From: owner-freebsd-questions@freebsd.org [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Micheal Patterson Sent: Tuesday, January 20, 2004 8:48 PM To: freebsd-questions@freebsd.org Subject: Re: ipfw/nated stateful rules example ----- Original Message ----- From: "fbsd_user" <fbsd_user@a1poweruser.com> To: "Micheal Patterson" <micheal@tsgincorporated.com>; "Ken Bolingbroke" <hacker@bolingbroke.com> Cc: <freebsd-questions@freebsd.org> Sent: Tuesday, January 20, 2004 8:41 AM Subject: RE: ipfw/nated stateful rules example > As the original poster of this thread, I want to say thank you to > Ken Bolingbroke who posted his rule set and to the other posters who > voiced their comments. > > I want to point out that Ken Bolingbroke acknowledged that has work > around of doing keep-state on both the Lan interface and the public > interface only works because the returning public packet is being > matched by stateful table entries posted from the Lan interface > keep-state rules. Yes he provided he could make it work, but not > work correctly. In the true security sense, this is un-secure and > invalidates the whole purpose of using keep-state rules at all. > > I an surprised that I have not yet heard the old timers dogma that > the Nated process it self is really performing an keep-state like > process and that is why keep-state does not work with divert/Natd. > There is some truth to that because the Nat process does have to > keep it's own internal table to remap IP address, but it just > blindly does the mapping with out any regard to if the packet > belongs to an authorized session conversation, like the keep-state > function does. > > The conclusion so far is that ipfw1 and ipfw2 using keep-state rules > on the interface facing the public internet with divert/nated does > not work period. By all accounts this is an long time bug propagated > by the continued use of the legacy divert keyword sub-routine call > to ipfw's userland Natd function. The using of keep-state rules on > the interface facing the public internet is restricted to situations > where there are no Lans behind the ipfw firewall or when 'user > ppp' -NAT function is used. I have tested using ipnat as an front > end to ipfw with keep-state but that also ends up handing off the > packet to ipfw at the wrong time. > > Now that ipfw2 has replaced ipfw1 in 5.2, maybe some of that ipfw2 > programming teams effort can be directed at fixing this problem. The > IPNAT code of IPFILTER runs in the kernel and could be modified to > be ipfw2's external Nat function. > > So firewall users who want the maximum level of protection have to > use IPFILTER. IPFILTER has had the keep state function long before > the keep-state option was ever added to ipfw1. > > Still would like to be provided wrong on my conclusion. Again I'll use this simple ruleset as a base. I've just used it on my network here at home to test for stateful inspection. ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check-state #Stateful Test Deny Rule ipfw add 25 deny log ip from any to any in via ep0 #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state #Default Deny ipfw add 65000 deny ip from any to any In order for traffic to hit your internal network, for a packet inbound to your LAN, 2 things have to happen. 1. A NAT entry that matches source ip / port to target ip / port. 2. A stateful dynamic rule that matches the LAN ip / port pair as well. If #1. doesn't occur, the traffic is treated as if it were heading to the firewall system itself. If there's no state match, it's dropped by the default deny rule at 65000. If #1 occurs, the traffic is translated, handed back to ipfw to check for #2. If #2 exists, the traffic passes onwards to the LAN. If not, it's dropped by the deny rule at 65000. If #1 doesn't occur, the traffic is treated as if it's heading to the firewall system and is checked against state for a match for the WAN IP / Port. If there's a match, traffic is allowed. If there's no match, the traffic is dropped by the default route. If you'd like to test this, here's how. Create the firewall ruleset as above (adjusted for your setup of course). Get on the net. Run an ipfw -d list to show your statefule rules, then edit the rulset and simply comment ouf the check-state entry. Rerun your ipfw ruleset and try again. Tail your /var/log/security file and watch the denies come rolling in for rule 25. Then try it with it enabled again and you'll see that stateful is indeed working as it jumps rule 25 completely and allows the traffic to pass once you're tried to access the remote site. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MIEPLLIBMLEEABPDBIEGIEGCFFAA.fbsd_user>