ipfw/nated stateful rules example

[Micheal Patterson]

----- Original Message ----- 
From: "fbsd_user" <fbsd_user at a1poweruser.com>
To: "Micheal Patterson" <micheal at tsgincorporated.com>; "Ken Bolingbroke"
<hacker at bolingbroke.com>
Cc: <freebsd-questions at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: SecureCRT 3.3.lnk
Type: application/octet-stream
Size: 708 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040120/c41090cc/SecureCRT3.3-0001.obj