Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jan 2010 14:35:17 -0800
From:      Doug Hardie <bc979@lafn.org>
To:        Erik Norgaard <norgaard@locolomo.org>
Cc:        freebsd-questions - <freebsd-questions@freebsd.org>
Subject:   Re: pf rules
Message-ID:  <D7B32DD2-9A3C-4CBA-B9E9-6C54ED7F7141@lafn.org>
In-Reply-To: <4B59887E.30301@locolomo.org>
References:  <4B594FC0.3010200@el.net> <4B5973AD.8070603@locolomo.org> <772FAD6A-C534-4217-9AA7-274561879E86@lafn.org> <4B59887E.30301@locolomo.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On 22 January 2010, at 03:14, Erik Norgaard wrote:

> Doug Hardie wrote:
>> On 22 January 2010, at 01:45, Erik Norgaard wrote:
>>> To debug pf rules:
>>>=20
>>> - always add direction to the rule, pass or block, add interface to =
all
>>> rules except default policy, keep state on all pass rules
>>> - group your rules per direction, then per interface
>>> - add log to all rules and watch pflog to see which rule blocks or
>>> passes traffic.
>>> - use keyword quick for any decisive rule
>>> - check the parsing of your ruleset, pfctl -sr
>>>=20
>>> then come back and ask for help.
>> Where do you find the rule information in the pflog output from =
tcpdump? =20
>=20
> a snip:
>=20
> alpha# tcpdump -n -e -i pflog0
> tcpdump: WARNING: pflog0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol =
decode
> listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture =
size 96 bytes
> 11:55:20.910140 rule 81/0(match): block in on vr1: 172.16.1.127.52444 =
> 172.16.0.1.23:  tcp 44 [bad hdr length 0 - too short, < 20]
>=20
> rule 81 blocks. Now, problem is that your rules may be more compact, =
you'll find the rule with pfctl -sr. Now admittedly, I got:
>=20
> pass in quick on vr1 inet proto udp from 172.16.0.0/23 to <local_ip> =
port =3D secret_service keep state
>=20
> ofcourse, that rule didn't block. But two lines down I found:
>=20
> block return in log quick on vr1 inet from 172.16.0.0/23 to <local_ip>
>=20
> This makes sence, so why the offset 2? The first line of the output =
from pfctl -sr is
>=20
> scrub all fragment reassemble
>=20
> that shouldn't count as a rule. And then, if pflog starts counting =
with 0 while vi counts from 1 that explains it.
>=20
> Yet another reason to check the rules as parsed using pfctl -sr.
>=20
> Anyway, not trying to cut corners is the first step, then add log so =
you can see whats going on, use quick to avoid some packet fall through =
and being matched by a different rule than intended, organizes your =
rules so you can easily separate things out.
>=20
> My rules are grouped together like this:
>=20
> # default policy
> block all
>=20
> block in log <general condition>
> pass  in quick some packets keep state
> block in log quick <general condition>
>=20
> block out log <general condition>
> pass  out quick some packets keep state
> block out log quick <general condition>
>=20
> # Default policy catch all should never apply
> block log all
>=20
> the conditions for the pass rules should match those of the first =
block and then be more specific, say, only apply to one port. Doing so, =
the pf rule parser will optimize the ruleset.
>=20
> Even if I know that a given rule can only match packets on the vr0 =
interface, I explicitly state the interface. It makes it clear what's =
going on.
>=20
> Once the ruleset is debugged and working you can remove the log =
statements.

Thanks.  That is really helpful.  The key is that the rule information =
is in the link layer.  I never guessed that.  Now I see it just fine.  =
This approach sure beats monitoring the statistics and the input and =
trying to correlate them.  That was the approach I was using.




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?D7B32DD2-9A3C-4CBA-B9E9-6C54ED7F7141>