PF firewall rules and documentation
Da Rock
directions in the handbook. It redirected me to the openbsd site for
pf.conf, and recommended it as the most comprehensive documentation for pf.
Firstly, I didn't find that. I had to translate the instructions into
the current version used in FreeBSD, OpenBSD appears to be further
advanced than this based on the current docs.
Secondly, some of the rules don't appear to be following. From my
understanding based on the documentation in the handbook and on the site
pf is default allowing traffic. So explicit rules to block should be set
first and then rules set to allow what is needed in. Some assumptions
are made in the rules by the interpreter, so according to OpenBSD one
can (even in the older versions) simply state block and it is
interpreted as 'block on $interfaces all'. This turned out to not be the
case.
I know this has come up before, but I think it might be time to document
pf.conf properly. It seems to be a bit of security risk not to. Users
may be mistaken in their belief of their security on the network using
pf, and may be less likely to trust again when it breaks.
Cheers
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
Da Rock
> I think that kind of user should never be in charge of anything security related
>
Reading my own post I realise I forgot my question due to kiddie issues
that were occuring in my vicinity. That is, how would one go about this?
As for user suitability, how else does one learn if not through practice?
Patrick Lamaiziere
Da Rock <freebsd-...@herveybayaustralia.com.au> a �crit :
> I spent some time playing with pf and pf.conf, and followed the
> directions in the handbook. It redirected me to the openbsd site for
> pf.conf, and recommended it as the most comprehensive documentation
> for pf.
>
> Firstly, I didn't find that. I had to translate the instructions into
> the current version used in FreeBSD, OpenBSD appears to be further
> advanced than this based on the current docs.
Yes, you should refer to the OpenBSD 4.1 Packet FAQ :
http://ftp.openbsd.org/pub/OpenBSD/doc/history/pf-faq41.pdf
> Secondly, some of the rules don't appear to be following. From my
> understanding based on the documentation in the handbook and on the
> site pf is default allowing traffic.
According to a current discussion on mi...@openbsd.org. It allows
traffic to pass but without creating states.
> So explicit rules to block
> should be set first and then rules set to allow what is needed in.
> Some assumptions are made in the rules by the interpreter, so
> according to OpenBSD one can (even in the older versions) simply
> state block and it is interpreted as 'block on $interfaces all'. This
> turned out to not be the case.
Ah? Do have an example for this?
> I know this has come up before, but I think it might be time to
> document pf.conf properly. It seems to be a bit of security risk not
> to. Users may be mistaken in their belief of their security on the
> network using pf, and may be less likely to trust again when it
> breaks.
This is true, many things are now more precise in the manual page of
OpenBSD's PF. But it will be hard to merge only these precisions in our
pf.conf manual page.
There are some plans to update PF to a more recent version. So may
be it will be better.
Regards.
Da Rock
> Le Sat, 29 Jan 2011 12:39:18 +1000,
> Da Rock<freebsd-...@herveybayaustralia.com.au> a �crit :
>
>
>> I spent some time playing with pf and pf.conf, and followed the
>> directions in the handbook. It redirected me to the openbsd site for
>> pf.conf, and recommended it as the most comprehensive documentation
>> for pf.
>>
>> Firstly, I didn't find that. I had to translate the instructions into
>> the current version used in FreeBSD, OpenBSD appears to be further
>> advanced than this based on the current docs.
>>
> Yes, you should refer to the OpenBSD 4.1 Packet FAQ :
> http://ftp.openbsd.org/pub/OpenBSD/doc/history/pf-faq41.pdf
>
>
>> Secondly, some of the rules don't appear to be following. From my
>> understanding based on the documentation in the handbook and on the
>> site pf is default allowing traffic.
>>
> According to a current discussion on mi...@openbsd.org. It allows
> traffic to pass but without creating states.
>
>
>> So explicit rules to block
>> should be set first and then rules set to allow what is needed in.
>> Some assumptions are made in the rules by the interpreter, so
>> according to OpenBSD one can (even in the older versions) simply
>> state block and it is interpreted as 'block on $interfaces all'. This
>> turned out to not be the case.
>>
> Ah? Do have an example for this?
>
though. I had a little thief attack one of my ports and attempt login on
the firewall. I had to change it to 'block in $log on $ext_if all
block out $log on $ext_if all' to actually block the traffic. Bit of a
doozy really, I'm still monitoring the traffic very closely with tcpdump
on the interface and not the log.
Thankfully I was also getting ready to update and completely rebuild
most (scratch that- all) of my systems to newer and more manageable levels.
>
>
>> I know this has come up before, but I think it might be time to
>> document pf.conf properly. It seems to be a bit of security risk not
>> to. Users may be mistaken in their belief of their security on the
>> network using pf, and may be less likely to trust again when it
>> breaks.
>>
> This is true, many things are now more precise in the manual page of
> OpenBSD's PF. But it will be hard to merge only these precisions in our
> pf.conf manual page.
>
> There are some plans to update PF to a more recent version. So may
> be it will be better.
>
Actually, that sounds like a better idea than mine ;) Kills 2 birds with
one stone then...
Kevin Wilcox
<freebsd-...@herveybayaustralia.com.au> wrote:
> Yes. Me unfortunately, but I did manage to pick it up quite quickly though.
> I had a little thief attack one of my ports and attempt login on the
> firewall. I had to change it to 'block in $log on $ext_if all
> block out $log on $ext_if all' to actually block the traffic. Bit of a doozy
> really, I'm still monitoring the traffic very closely with tcpdump on the
> interface and not the log.
Unless you have an explicit need to block in/out, it's easier to
maintain a ruleset that uses
block log on $ext_if
For example, I use the following as a "starting point" for some of my
routing firewalls:
=============================
int_if=bge1
ext_if=bge0
set skip on lo
# block everything
block
# NAT rule
pass out log(all) on $ext_if from ($int_if:network) to any nat-to ($ext_if)
# allow traffic in on the internal interface
pass in on $int_if from ($int_if:network) to any keep state
=============================
There are at least three things in that basic config that some people
would jump on me for.
1) why block all if I'm then allowing every in on the internal interface?
2) why block all if I'm allowing everything out on the external interface?
3) why not pass everything on the internal interface and then filter
on the external?
The shortest answer is because I happen to like that starting point
and it serves as a syntactical reminder if I deploy without a pf
reference handy.
Regarding 1) and 2), the longer answer is that I like to control
traffic flow. I don't want to allow inbound connections on the
external interface and I don't have a need for the firewall to connect
to machines inside the NAT. On my bridges I'll set skip on the
internal interface and filter on the other but I don't like doing that
for a router.
>> There are some plans to update PF to a more recent version. So may
>> be it will be better.
>>
>
> Actually, that sounds like a better idea than mine ;) Kills 2 birds with one
> stone then...
I am truly excited about this as the NAT and RDR stuff was
significantly cleaned up (and the OpenBSD pf FAQ is a great resource).
I'm even more excited about the patch to tcpdump that Daniel just sent
to freebsd-pf@ that allows you to tcpdump a pfsync device and pull the
state creation/updates - in my opinion, that's the weakest area for a
BSD firewall (we'll ignore span ports on routers since you can bridge
two addressed interfaces and create a span of that bridge) and being
able to easily pull those NAT translations fulfills some serious
accountability issues.
If you need a reliable printed reference, you should really consider
picking up Hansteen's _The Book of PF_, available from No Starch
Press:
I have the first edition and it's incredible but somewhat dated. The
author suggests the second edition for FreeBSD 8.x+.
kmw
Da Rock
But that was the point of this whole thread- that block statement
doesn't cut it. I started there and noticed a little sneak getting
through anyway. Set it to the block explicitly and bam! No problem. Just
a little heads up anyway...
>>> There are some plans to update PF to a more recent version. So may
>>> be it will be better.
>>>
>>>
>> Actually, that sounds like a better idea than mine ;) Kills 2 birds with one
>> stone then...
>>
> I am truly excited about this as the NAT and RDR stuff was
> significantly cleaned up (and the OpenBSD pf FAQ is a great resource).
> I'm even more excited about the patch to tcpdump that Daniel just sent
> to freebsd-pf@ that allows you to tcpdump a pfsync device and pull the
> state creation/updates - in my opinion, that's the weakest area for a
> BSD firewall (we'll ignore span ports on routers since you can bridge
> two addressed interfaces and create a span of that bridge) and being
> able to easily pull those NAT translations fulfills some serious
> accountability issues.
>
You think?! Man I was scratching a bit trying to translate between
versions there- not too long, but long enough to a PITA. It would be
nice to have it all nice and tidy...