I have nt been following this much so I apologise if the turns out to not
be relevent.
If you are setting up a firewall for outbound connections only then Linux
has a stateful packet filter. If you turn on masquerading (many->1 NAT)
the system has to track everything to know how to map the ports. As the
ports go away as connections close (or are idle longer then the allowed
time) you end up with state being maintained.
David Lang
On Fri, 24 Sep 1999, Bennett Todd wrote:
> Date: Fri, 24 Sep 1999 13:29:24 -0400
> From: Bennett Todd <[EMAIL PROTECTED]>
> To: Ben Nagy <[EMAIL PROTECTED]>
> Cc: 'Bennett Samowich' <[EMAIL PROTECTED]>,
Firewalls <[EMAIL PROTECTED]>
> Subject: Re: Hardware vs Software - Reprise
>
> 1999-09-23-20:12:45 Ben Nagy:
> > Also I understand it, you've got to go either application gateway (ala FWTK)
> > or just neat packet filtering and NAT (ala ipfw / ipchains). The PIX does
> > smart-ish stateful packet filtering which is kind of a middle ground.
>
> If you want stateful packet filtering (in the sense it's being used here ---
> tracking TCP connections) you can use IPFilter[1], which comes with OpenBSD,
> and has been ported to Linux.
>
> > (Am I out of date? Has anyone looked at the SPF stuff that can be plugged
> > into IPChains or written anything cool along those lines?)
>
> Both IPChains and the newer gizmo being hacked up for the 2.4 kernel series
> claim to have callouts capable of supporting exotic and clever stuff, like
> stateful filtering, but as far as I know the basic tcp-connection-tracking
> stateful trick hasn't been done yet for either of them.
>
> > Remember that time is money - even yours.
>
> Yup. But I really think that the difference between installing RH6.0 or
> OpenBSD 2.5 and configuring packet filtering, and installing a Pix and
> configuring packet filtering, is negligible; either way, the vast majority of
> the learning required is in the basics of how to write an appropriate security
> policy, and how to implement it with packet filters perhaps assisted by
> proxies. If you come into the game knowing Unix, the RH or OpenBSD solution
> might be easier; if you come in knowing IOS the Pix might be easier, but they
> represent comparable hurdles to master from scratch.
>
> > I would suggest that you go with one Linux box and one openBSD box or some
> > similar mis-match of OSs between the two. You don't want one bug to cut a
> > hole through _both_ your firewalls.
>
> That would depend on the architecture proposed. I haven't heard what's being
> proposed here. If the firewalls are in series, you have a point --- although I
> tend to neglect it, since I don't believe my firewalls have holes. But if the
> firewalls are in parallel, for high-availability and/or load-balancing, then
> the argument works the other way; best to have both firewalls identical, since
> if _either_ of them has a hole you're sunk, so you don't want to add diversity
> between the boxes to improve the odds that one might have a hole that's absent
> in the other.
>
> -Bennett
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
