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.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Micheal
Sent: Tuesday, January 20, 2004 8:48 PM
To: [EMAIL PROTECTED]
Subject: Re: ipfw/nated stateful rules example
----- Original Message -----
From: "fbsd_user" <[EMAIL PROTECTED]>
To: "Micheal Patterson" <[EMAIL PROTECTED]>; "Ken
Cc: <[EMAIL PROTECTED]>
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
> voiced their comments.
> I want to point out that Ken Bolingbroke acknowledged that has
> around of doing keep-state on both the Lan interface and the
> 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
> on the interface facing the public internet with divert/nated does
> not work period. By all accounts this is an long time bug
> 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
> 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.
> 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
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
ipfw add 65000 deny ip from any to any
In order for traffic to hit your internal network, for a packet
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
If #1. doesn't occur, the traffic is treated as if it were heading
firewall system itself. If there's no state match, it's dropped by
default deny rule at 65000.
If #1 occurs, the traffic is translated, handed back to ipfw to
#2. If #2 exists, the traffic passes onwards to the LAN. If not,
dropped by the deny rule at 65000.
If #1 doesn't occur, the traffic is treated as if it's heading to
firewall system and is checked against state for a match for the WAN
Port. If there's a match, traffic is allowed. If there's no match,
traffic is dropped by the default route.
If you'd like to test this, here's how. Create the firewall ruleset
(adjusted for your setup of course). Get on the net. Run an ipfw -d
show your statefule rules, then edit the rulset and simply comment
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
Then try it with it enabled again and you'll see that stateful is
working as it jumps rule 25 completely and allows the traffic to
you're tried to access the remote site.
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"