> > ### corp_if rules ###
> >
> > # allow corporate network anywhere
> > pass in on $corp_if proto tcp from $corp_net to any flags S
> keep state
> > pass in on $corp_if proto { udp, icmp } from $corp_net to any keep
> > state
>
> These are the only two rules that apply to $corp_if
> explicitely, and they only deal with packets coming in on
> that interface. This means that you're not passing any
> connections _out_ through $corp_if.
>
> If that's intentional (i.e. none of the the other networks
> should be able to connect into $corp_net), that's fine, of course.
>
Yep. In this template the only connection on $corp_if should be the inbound
tcp/udp/icmp from $corp_net and the subsequent return traffic which should
be passed by the keep state flags.
> > Feel free to offer suggestions and comments! Daniel, any thoughts?
> > Would using 'quick' rules in certain places me rule parsing faster?
>
> I wouldn't make the rule set more complicated before you're
> actually forced to (because rule set evaluation turns out to
> be too slow). Some people use 'quick' because they feel more
> comfortable with 'final' rules, so they don't have to think
> about how one rule is overridden by later rules. In your rule
> set, I think overriding is used pretty straight forward, and
> you obviously understand how it works, so I don't think you
> should use 'quick' just for the sake of it.
>
Thanks. I think that using quick rules without thought in this scenario
could inadvertently open up large holes. Some rules I'll probably write in
as quick, others not.
I've kept the skip step functionality in mind so that should hopefully speed
up rule parsing.
> As with any non-trivial rule set, it's always a good idea to
> verify the filter by trying several different valid and
> invalid connections (between all networks, in your case) and
> see if the right ones are blocked.
>
Definitely.
> I'd recommend you express the general policy ('everything
> should be blocked, except for the following connections:
> $corp_net may connect into $dmz_net using tcp/udp/icmp,
> etc.') and put that as a comment. Without that information,
> it's impossible to tell whether the rule set implements your
> policy, I could only guess your policy from the rule set, and
> couldn't detect differences, of course :)
>
> Daniel
>
Thanks for your pointers. I'll start writing the more specific rules soon.
Like I said before, these are the basis for the overall security policy and
each specific rule will alter that in some way. Glad to hear I'm on the
right track.
Cheers,
Adrian.
