On Thu, Jan 13, 2011 at 03:38:44PM -0800, Daniel C. Sinclair wrote:
> On Tue, Jan 11, 2011 at 2:15 AM, Henning Brauer <lists-open...@bsws.de>
> wrote:
> > * Daniel C. Sinclair <daniel.c.sincl...@gmail.com> [2011-01-11 09:46]:
> >> From the firewalls point of view interfaces are not inside or outside
> >> - they are just interfaces with some network behind them.
> >
> > sigh.
> >
> > you can continue to twist words, or you can solve your problem. if you
> > prefer to twist words I'm out.
> >
> > internet OUTSIDE
> >
> > firewall
> >
> > shitloads of vlans INSIDE
>
> My situation is different from yours.
>
> I have many internet links in multiple buildings, private T1s between
> some buildings, a bunch of servers in one location, staff PCs all
> over, public kiosks, public internet stations, public wifi everywhere,
> and firewalls to segregate everything. What is inside, what is
> outside? Public wifi is not in the egress group and is full of
> uncontrolled and often hostile hosts - is this inside? People have
> even done weird things like get on the wifi and NAT their own internet
> connection behind that so they can access our in-building only
> services from anywhere they want. Now I have their internet on the
> 'inside' of my network?
>
> I gave up trying to twist inside/outside to fit my situation. All my
> firewalls block in all with pass in exceptions on some interfaces, and
> pass out all with pflow. This solved my problems and is easy to
> understand.
>
Please don't confuse the internal versus external LANs from in and
outgoing traffic on an interface. While you may not have a strict internal
external setup you have traffic comming in and going out of interfaces.
In case you want to have flow records for all traffic passing that box
make sure that all states created because of incomming traffic generate a
pflow state. So add keep state (pflow) to all pass in rules.
> >> Where do you put the 'keep state(pflow)'?
> >
> > just one spot.
> >
> > ks = "keep state(pflow)"
> >
> > doubt that helped you know tho
> >
> >> Do you have to add it to more than one rule?
> >
> > me? yes.
> >
> >> In my case I always want pflow on everything and
> >> I prefer to eliminate the chance that I (or someone else) forget to
> >> add it somewhere. Adding it on the single 'pass out' rule keeps
> >> things simple.
> >
> > aha. you want fine grained (because otherwise you get it twice, bu
> > definition), but you only want to use one giant global hammer. now
> > that is going to work out.
>
> Your 'giant global hammer' equals my 'sane default expressed in a
> single location'. I want non-duplicated netflow everywhere and I
> don't want to specify it on every rule. It doesn't matter if it's
> 'keep state(pflow)' or '$ks', I don't want to repeat it all over and
> risk omitting it somewhere. I tried 'set state-defaults pflow' and
> then turning off pflow on some rules to avoid duplicates but that
> wasn't as simple as what I'm using.
>
> Is there ever a case where one would want some of their netflow
> duplicated? (only traffic that goes through is duplicated, to/from
> the firewall isn't). It just inflates statistics/accounting and
> wastes disk space.
>
> Is Claudios idea for 'match in keep state(pflow)' really that
> different from my 'pass out keep state(pflow)'?
>
Yes it is. Since match works totally different from pass. If you have other
pass rules then your pass out rule will be overruled by the later one.
Match has a sticky behaviour and will inherit the match settings to the
last pass rule. But it does not matter since match does not handle keep
state options at the moment.
> >> Feel free to give an example. I'm sure many people would like to see
> >> how you use pf. :)
> >
> > i'm not going to post my production rulesets. i already said how I'm
> > doing things, and I am under the impression that was pretty
> > straightforward.
>
> I didn't ask for your production ruleset - I expect that it is
> thousands of lines long. I wouldn't want to bother people with my
> entire ruleset either since most of it has nothing to do with this
> thread. Instead I posted a simple example of how I'm doing things so
> people could see one way of avoiding duplicate flows. Claudios single
> line example could work well too.
>
> > heck, here's one.
> >
> > block
> > pass in on egress to $mynetworks
> > pass out on vlan proto tcp to port { 80 443 } $ks
> >
> >
> > making this more fine grained, add fw self protection, spoof
> > protection, the set skips for loopback, pfsync and the physical if
> > under the vlans and allowing the INSIDE machines to initiate
> > connections to the OUTSIDE is left as excercise to the reader.
>
> Thanks for this. I will try it out and see how well it works in my
> situation.
>
Add keep state(pflow) to either all in or all out rules. Don't use any
pass rules that have no direction specifier and your double accounting is
history. Every connection beeing forwarded through a pf firewall ends up
with two states (unless you skip the outgoing interface in pf.conf). So
you need to ensure that only one of the two states has keep state (pflow)
set.
--
:wq Claudio
