Keep State is not working on 6.1-RELAESE-p1

Travis H. solinym at gmail.com
Wed Jun 28 09:02:52 UTC 2006


On 6/27/06, Daniel Hartmeier <daniel at benzedrine.cx> wrote:
> One common approach is to only filter incoming packets, and to let
> everything pass out from the firewall. This covers all forwarded
> traffic: anything leaving the firewall must first have passed in (and
> has, therefore, been checked). It does not cover connections originating
> from the firewall itself. But often, you either don't run any processes
> on the firewall (that need to connect out), or you trust those
> implicitely.

One could also compromise and write a very short rule specific to the
firewall's IPs, providing outbound filtering only for those source
IPs.

> Another common case is three (or more) legged firewall, where you have
> strict policies about what interface a type of connection may enter and
> where it may and may not leave (e.g. in on if1, out on if2, but never
> out on if3), i.e. you don't trust the routing table (which might be
> dynamically updated). In this case, you DO need per-interface rules,
> and they are not really duplicates. Tagging helps in this case, too
> (you'd tag passed incoming packets so they'd be allowed out on a
> specific other interface).

Often if one uses antispoof, one can eliminate the interface
specifications entirely.  In his case, he could also eliminate in/out
entirely, and be left with a fairly terse ruleset.  Note however that
antispoof doesn't help too much if a particular interface leads to
distant networks.  Therefore, you shouldn't eliminate e.g. the WAN
interface from rules, since antispoof won't prevent arbitrary Internet
IPs from appearing on the non-WAN interfaces.
-- 
`I put my heart and my soul into my work, and have lost my mind in the
process.''
-- van Gogh | Security "guru" for rent or hire -
http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484


More information about the freebsd-pf mailing list