bad rule, or special filtering needed for bootp packets?
The very, very first rule in my pf ruleset is part of a fairly vanilla
anti-spoof/sanity check set, intended to catch incoming bogon/martian
packets:
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32
}
block drop in log quick on ! lo0 inet from unroutable_ips to any
label block unroutable ip
I can see it being evaluated using pfctl -v -s rules, but so far
(~40hrs uptime) it hasn't matched anything yet. That would normally
not be of concern, except I'm seeing stuff like this in the pflog that
I think it should have caught - but had to get caught by a later,
fail-safe rule at the bottom of the ruleset. In particular, I'm seeing
lots of bootp packets from badly-configured Windows clients:
Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on
em0: 0.0.0.0.68 255.255.255.255.67: xid:0x64f14f [|bootp] (DF) [tos
0x10] (ttl 64, id 0, len 330)
So:
- Is there something wrong with my first rule that I'm not seeing that
causes these 0.0.0.0 bootp packets to miss it, OR
- Is there something special about the bootp packets [remember, bootp
uses UDP] that they won't match that rule, even though the source is
in the unroutable_ips table?
Thanks for any insight, or other debugging ideas I can test.
/d/
PS: Notice the quick keyword in the block rule - this isn't a last
rule that matches issue, in case you're tempted to reply with
something about that - I would think a packet from 0.0.0.0 should hit
the rule, match, and then due to quick undergo no further
evaluation, end of story.
Re: bad rule, or special filtering needed for bootp packets?
Thanks to Jan for pointing out I neglected to include the macro defs
for the nets (though they're vanilla and what you'd expect). Here's
the full source for the first rule, the one I think should catch the
bogon packets but doesn't:
int_net = 192.168.5.128/25
wls_net = 192.168.10.128/25
ptr_net = 192.168.99.128/25
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32
}
block drop in log quick on ! lo0 inet from unroutable_ips to any
label block unroutable ip
The rest of the question below remains the same.
thankee much /david/
On Wed, Mar 27, 2013 at 10:12 AM, David Ruggiero
thatseattle...@gmail.com wrote:
The very, very first rule in my pf ruleset is part of a fairly vanilla
anti-spoof/sanity check set, intended to catch incoming bogon/martian packets:
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
!$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32 }
block drop in log quick on ! lo0 inet from unroutable_ips to any label
block unroutable ip
I can see it being evaluated using pfctl -v -s rules, but so far (~40hrs
uptime) it hasn't matched anything yet. That would normally
not be of concern, except I'm seeing stuff like this in the pflog that I
think it should have caught - but had to get caught by a later,
fail-safe rule at the bottom of the ruleset. In particular, I'm seeing lots
of bootp packets from badly-configured Windows clients:
Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on em0:
0.0.0.0.68 255.255.255.255.67: xid:0x64f14f [|bootp] (DF) [tos
0x10] (ttl 64, id 0, len 330)
So:
- Is there something wrong with my first rule that I'm not seeing that causes
these 0.0.0.0 bootp packets to miss it, OR
- Is there something special about the bootp packets [remember, bootp uses
UDP] that they won't match that rule, even
though the source is in the unroutable_ips table?
Thanks for any insight, or other debugging ideas I can test.
/d/
PS: Notice the quick keyword in the block rule - this isn't a last rule
that matches issue, in case you're tempted to reply with
something about that - I would think a packet from 0.0.0.0 should hit the
rule, match, and then due to quick undergo no further
evaluation, end of story.
Re: bad rule, or special filtering needed for bootp packets?
Thanks! No, it didn't occur to me, so very appreciated. I didn't remember that you could do that form of the table command to show explicit members in a list, so that's also really helpful. FWIW, though..I would not have expected that pf would silently drop - without any warning message or complaint - an address explicitly stated as being a member of a constant table definition. Even that address. You're right that (at least in hindsight) 0.0.0.0/mask might be treated differently - maybe it uses it as a marker for an empty slot or the like? But regardless of that, I would (a) expect that fact to be documented (if it is, I missed it), and (b) expect that the pf parser would say something as it was throwing it away (at least a warning message about unparseable address at line XX - ignored or the like). For it to just drop it on the floor and say nothing at all seems - well, kind of non-pf-ish. Perhaps worth a documentation patch, if not an actual code patch. Again, much thanks. /d/ Did you take the time to display the content of the table? 'pfctl -t unroutable_ips -Ts' should do the trick, and then you would see that 0.0.0.0 is *not* in the table. I just ran a quick test to verify that it is not possible to add such an address to a table. I did not dig through the source code and is not an expert on the IP stack as some devs on this list, but I do suspect that there are many special properties attached to a null address field.
empty pf log / pflogd not starting?
I'm playing with the latest 5.3 snapshot and I'm getting an always-empty /var/log/pflog. I'm wondering if there's a problem with the snapshot (unlikely) or something I did wrong in my configuration (much more likely). ps -aux shows pflogd is not running, which I assume is the source of the problem. In rc.conf (which I did not change of course) the pf lines are: pf=YES # Packet filter / NAT pf_rules=/etc/pf.conf # Packet filter rules file pflogd_flags= # add more flags, e.g. -s 256 And here's my rc.conf.local: ntpd_flags= hotplugd_flags= named_flags= check_quotas=NO That's it. Is there something I should be doing in rc.conf.local or elsewhere to get pflogd running? (I could do pflogd_flags=YES, maybe, but I thought that wasn't necessary, that pflogd would start automagically if pf was enabled.)
Re: empty pf log / pflogd not starting?
Jan: Your question is ignoring what I wrote, which is that pflogd is not started at all, so logging will not happen regardless of my ruleset. But yes, logging in enabled in pf.conf and yes, I can see the rules are being executed that should log via pf.control. I didn't think as a reasonably experienced user, clearly comfortable playing with a snapshot, that I would need to say that, especially as I was pointing the discussion at the starting / not starting status of the daemon. On Sun, Mar 24, 2013 at 10:22 AM, Jan Stary h...@stare.cz wrote: On Mar 24 10:13:05, thatseattle...@gmail.com wrote: I'm playing with the latest 5.3 snapshot and I'm getting an always-empty /var/log/pflog. I'm wondering if there's a problem with the snapshot (unlikely) or something I did wrong in my configuration (much more likely). ps -aux shows pflogd is not running, which I assume is the source of the problem. In rc.conf (which I did not change of course) the pf lines are: pf=YES # Packet filter / NAT pf_rules=/etc/pf.conf # Packet filter rules file pflogd_flags= # add more flags, e.g. -s 256 And here's my rc.conf.local: ntpd_flags= hotplugd_flags= named_flags= check_quotas=NO That's it. Is there something I should be doing in rc.conf.local or elsewhere to get pflogd running? (I could do pflogd_flags=YES, maybe, but I thought that wasn't necessary, that pflogd would start automagically if pf was enabled.) Do you actually log something in your pf.conf? Does such traffic actually occur?
Re: empty pf log / pflogd not starting?
Answering own posting: The problem is that 'pfctl -si' returns: DIOCGETSTATUS: Permission denied so when rc.d/pflogd uses that command to see if pf is running, it doesn't get a nice answer, woofs its cookies, and doesn't start. Issue apparently is a bug in the current 5.3 snapshot, see: http://openbsd.7691.n7.nabble.com/pf-query-query-counters-failed-td225607.html (I'm running GENERIC#68 from 3/22). I'll hack the pflogd script for now until full 5.3 is released, when things presumably will work better. This is why you download snapshots, so things can break and you can report them. Or, conversely, why you don't run snapshots. :) -d- On Sun, Mar 24, 2013 at 10:13 AM, David Ruggiero thatseattle...@gmail.com wrote: I'm playing with the latest 5.3 snapshot and I'm getting an always-empty /var/log/pflog. I'm wondering if there's a problem with the snapshot (unlikely) or something I did wrong in my configuration (much more likely). ps -aux shows pflogd is not running, which I assume is the source of the problem. In rc.conf (which I did not change of course) the pf lines are: pf=YES # Packet filter / NAT pf_rules=/etc/pf.conf # Packet filter rules file pflogd_flags= # add more flags, e.g. -s 256 And here's my rc.conf.local: ntpd_flags= hotplugd_flags= named_flags= check_quotas=NO That's it. Is there something I should be doing in rc.conf.local or elsewhere to get pflogd running? (I could do pflogd_flags=YES, maybe, but I thought that wasn't necessary, that pflogd would start automagically if pf was enabled.)
Intel hyperthreading w/ Atom E6xx OpenBSD 5.2?
I've been using OpenBsd for 8+ years on my main router/firewall (4 NICs). Time to upgrade (I'm back on v3.8, yikes). Past time, really. Solots to learn / re-learn here. Have patience. First question: I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris net6501). That chip has two Hyperthreading cores. Several net-references (esp. calomel.org ) advocate turning off HTT in the bios when using OpenBSD for faster interrupt servicing / task switching latency. Butperhaps that advice is pre-5.2, when we got pthreads(3) support? What's the best current advice for that kind of one-cpu, multi-logical-thread system? 1) Single processor kernel or multi-processor (smp) kernel? 2) If the latter, HTT turned on or off? Thanks. Bonnie
Re: Intel hyperthreading w/ Atom E6xx OpenBSD 5.2?
The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. Thanks. That's the piece of info I needed, as (at least per current plans) 95% of the machine's time will be in PF-land, with few or no userland programs besides the occasional log-muncher. I do understand the ruleset for PF has changed, and then changed again, in the intervening years. I planned to start from scratch with my rules, not try to port anything from the old system except as a don't forget to allow this kind of reminder. thx D On Thu, Mar 7, 2013 at 8:51 PM, System Administrator ad...@bitwise.netwrote: On 7 Mar 2013 at 20:24, David Ruggiero wrote: I've been using OpenBsd for 8+ years on my main router/firewall (4 NICs). Time to upgrade (I'm back on v3.8, yikes). Past time, really. Solots to learn / re-learn here. Have patience. First question: I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris net6501). That chip has two Hyperthreading cores. Several net-references (esp. ca**mel.org ) advocate turning off HTT in the bios when using OpenBSD for faster interrupt servicing / task switching latency. Butperhaps that advice is pre-5.2, when we got pthreads(3) support? What's the best current advice for that kind of one-cpu, multi-logical-thread system? 1) Single processor kernel or multi-processor (smp) kernel? 2) If the latter, HTT turned on or off? Thanks. Bonnie First thing first, read, read, and re-read the official documentation. Many things changed in the intervening years, in particular, PF configuration syntax has changed a fair bit. Do note that unlike the Linux world where you have to dig for third party how-tos, OpenBSD official documentation is very complete and up to date. Which is one of the reasons the website you referenced is frowned upon as most of its information is either out of date or simply wrong. That said, the particular point you bring up may still be valid -- much depends on your specific situation. Whether or not to use hyperthreading and multiprocessor (MP) kernel depends on the workload of your firewall. The OpenBSD kernel and network stack still do run only on CPU0, so if all you plan to do is use PF to filter traffic, then you are indeed better off disabling HTT. However, if your firewall is also going to be running a fair amount of userland processes (e.g. your website with db backend) then you may well benefit from multiprocessor support.
