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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7B32DD2-9A3C-4CBA-B9E9-6C54ED7F7141>