Re: allow dhcpd with pf
Theo de Raadt wrote: Where are the details written up for how pf is bypassed by dhcpd and dhclient? Would that mean that the machine with dhcpd could still serve dhcp requests despite a filter ruleset like this: block in all pass out all Damn right it will. Where is it written up? In the manual pages. I can't believe we are here in 2009 and people still believe they can get away with being an idiot because they believe they are above doing research: From the dhclient manual page: You must have the Berkeley Packet Filter (BPF) configured in your kernel. dhclient requires at least one /dev/bpf* file for each broadcast network interface that is attached to your system. See bpf(4) for more informa- tion. See that last sentence? From the bpf manual page: The Berkeley Packet Filter provides a raw interface to data link layers in a protocol-independent fashion. All packets on the network, even those destined for other hosts, are accessible through this mechanism. See that last sentence? "All packets on the network". Maybe it should read, "All packets on the network, even those filtered by pf, and those caused by sunspots, and those sent from the planet that has sent their ambassador Linus to live among us, and those coming from Theo himself, and..." Seriously, I never gave much thought to the fact that dhcp worked regardless of pf until reading this thread. But I did know that it uses bpf, and what bpf is, so Claudio's explanation makes perfect sense. One thing I'll say about debugging connectivity problems in general is that you can go nuts trying to tweak your pf.conf when the problem isn't pf. I try to refrain from modifying my ruleset unless I can prove pf is blocking packets by examining the logs and/or using tcpdump. Corey
Re: Security via the NSA?
Doug Milam wrote: Will OpenBSD be the next to be 'helped'? http://www.npr.org/blogs/thetwo-way/2009/11/nsa_microsoft_windows_7.html Only if they Paypal some $$$ to http://www.openbsd.org/donations.html :)
Re: Match rule with scrub options cause some websites to "hang"
Here's a brief overview of what I did. If it's not what you are looking for, let me know (or we can take a more detailed discussion off-list). I don't claim to be an expert in this. I did a lot of Googling/reading, and cobbled together my "strategy" from several sources. Even then, I think I'm going to change it a bit with the next snapshot I load. I installed the snapshot onto a 8GB CF card mounted as a raw disk in Sun VirtualBox PUEL. I'm sure you could do it all on the Soekris as well, but VirtualBox on my Core i7 workstation is faster than the Soekris :/ I then dd'ed the image to a raw disk file and worked from it to set most everything up, then dd'ed it back to the CF, popped it in the Soekris, and there did the final config and testing. I have /tmp, /dev, and /var in MFS, and everything else mounted read-only, so that I can unplug the thing with impunity. From what I read that's really the only reason to put things in MFS, because a modern CF card will last years even used as a hard disk, and doing the MFS thing is definitely extra effort. If it's your home router and you are willing to treat it like a "regular" computer, it's easier to just use the CF like any other hard disk and install in the normal manner. My one big change I'll make is actually having some swap space. I have a very small amount now to support the MFS, but based on discussion on this list in the last month or so there's no reason not to have a normal amount of swap with a 4GB or more CF. The Soekris makes a fine home firewall, but I'm not sure how it would perform under heavier loads. The VIA vr network interfaces are not known as the most efficient (though there is a PCI slot to add something different if you desire), and I don't know how the Geode CPU would handle a lot of encryption, say, several simultaneous IPSec or ssh users. I'm looking at mini-ITX Atom boards as the basis for a multipurpose, CF-booting platform (firewall, X-terminal, NAS/backup server) I want to use at work. Each machine would do only one thing in that list, but I could keep one spare for all and just swap out CF cards to change their "role". The Atom boards probably don't have much more horsepower than the Soekris, but some have better network interfaces (Intel em), and they can be had with dual video interfaces too. stan wrote: On Sun, Nov 08, 2009 at 10:32:07PM -0600, Cor wrote: I'm running a late-October post-4.6 snapshot on a new Soekris firewall, and noticed something peculiar after setting up the rules per the new pf.conf(5) man page. I had a few lesser-known websites just hang and eventually time out (the "majors" still work fine), but thought little of it until I went to the ISA web site (www.isa.org) to renew my membership there and noticed the same effect. I need to build a couple of those. Which methodolgy are you using to build these?
Match rule with scrub options cause some websites to "hang"
I'm running a late-October post-4.6 snapshot on a new Soekris firewall, and noticed something peculiar after setting up the rules per the new pf.conf(5) man page. I had a few lesser-known websites just hang and eventually time out (the "majors" still work fine), but thought little of it until I went to the ISA web site (www.isa.org) to renew my membership there and noticed the same effect. I changed the following rule: match in all scrub (reassemble tcp no-df random-id) to match in all scrub (no-df random-id) and then www.isa.org came up as normal. (This latter match incantation may be useless, or otherwise not make sense; I just removed "reassemble tcp" as an experiment.) This of course could just be coincidence, Internet problems, etc. so I just wanted to ask if anyone else was experiencing this. I suspect the answer will be that this should work fine, is the way things should be, and these web sites are errant somehow, and that's OK, but I wanted to make sure. Thanks, Corey
Re: http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/
My interpretation is that yes, they identified it as a possibility, but due to limitations of the Intel platform, there wasn't an obvious, clean, "correct" way to fix it. I don't think this is a "primary" exploit, however. You would have to have a buffer overflow or something in some other app first. Fixing this, as someone stated, mitigates the consequences of other primary exploits. But feel free to correct me if I'm wrong (do I really need to say that? :) C2 Claire beuserie wrote: Hi, On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt wrote: 2) At least three of our developers were aware of this exploitation method going back perhaps two years before than the commit, but we gnashed our teeth a lot to try to find other solutions. Clever cpu architectures don't have this issue because the virtual address spaces are seperate, so i386/amd64 are the ones with the big impact. We did think long and hard about tlb bashing page 0 everytime we switch into the kernel, but it still does not look attractive from a performance standpoint. I'm confused. That came out a bit weird: are you saying you knew about the bug for 2 years but did not fix it? c.b-
Re: pf changes the order of filtering rules
Henning Brauer wrote: how about reading the manpages for a change. sometimes i wonder why we write them. Please, PLEASE don't stop :) Seriously, this is one area where OpenBSD (and probably other BSDs, too) romp on Linux. I was debugging my pf syntax last weekend and took the time to learn how the "BNF" info at the end works (first time I've really noticed that, but I'm not a CS major). It was immensely helpful, and way better than trial and error, in getting my syntax correct. C2
