Yes, the Book of PF, fourth edition is coming soon | Hacker News Reader

Yes, the Book of PF, fourth edition is coming soon

bsdly.blogspot.com

138 pointsturtleyacht40 comments

I’ll toss this out there: pf ruined all other firewalls for me. Once you’ve been spoiled by pf.conf, it’s awfully hard to look at any other without running away screaming. Seriously, it’s a joy, like discovering Python after you’ve learned Brainfuck.

I wish Linux’s firewalls were so easy to configure. The closest I’ve found there is with ufw, which isn’t nearly so comprehensive or straightforward, but at least goes in the right direction.

> I wish Linux’s firewalls were so easy to configure.

nft (nftables) is easy and has a similar pf-like 'feel' while offering way more functionality. After decades of `iptables` (and `ipchains` before) nft(ables) is a breath of fresh air.

I still greatly prefer pf, but yes, nftables is vastly better than iptables. Ipchains always looked like a RAM dump converted to Forth. It got the job done, mostly, but I never could understand how it got popular when the BSDs were already using nicer alternatives.

Nftables is a step forward in the Linux firewall. It evolved a lot in the last years and nowadays it really requires that the tooling linked to iptables setups do the migration step.

The scenario is like the cgroup v1 and v2 change.

Iptables suffers from the common "it's a command line program so we are going to use getopt to parse it" I find the getopt style... tolerable at best for short commands. But for long expressions in a dsl(like find or iptables) it is noisy and ugly. Iptables would have been twice as nice to use if they got rid of all the pointless dashes(and I have written preprocessors to do just this).

The clearest example of this was the megaraid command for lsi raid cards. It's commands are documented in the getopt style but I accidentally found out that the dashes were optional. And while the syntax was still sort of ass, my scripts were much easier to read.

Totally agree. I rarely need to adjust my pf.conf but it's a joy when I do. The syntax is easy to read and I can easily get up to speed on my rules just by paging through the file.

FWIW I have the previous edition of the Book of PF on my bookshelf but I rarely reference it after reading through it a couple years back. Standard homelab-grade rulesets are pretty straightforward to setup.

I've written firewall rules in many dialects, include Linux with ipchains and iptables, FreeBSD with ipfw and pf.

I will say, they all pretty much work, until you get into more esoteric stuff; do you want to drop syns where the last 16-bits of seq match the client's port number? Do you want to drop UDP RTP packets for a specific SSRC? If so, that need may guide your firewall choice. If you need to sync states between two stateful firewalls, that pushes you to pf with pfsync. Etc.

I guess I didn't see a big difference in perceived happiness between any of the rules systems? pf.conf is maybe more picky and checks everything at once, which is nice so you don't end up with a half baked ruleset.

Otoh, pf has the feature that OpenBSD changed the rule syntax, and the ported versions didn't; I'm not sure a forced migration of rule config would have sparked joy for OpenBSD users anyway, but it certainly doesn't spark joy when I read current documentation for the OpenBSD pf and can't apply it directly, and have to translate the config language to the original language.

Pf also has the extra special feature that Apple ported pf to MacOs but some things don't work properly for a host firewall (synproxy in mac os pf only works if the mac is operating as a router, not as a host... And mac os's tcp stack has no syn flood mitigation, beyond having a small listen backlog or not accepting syns directly from the internet). That's an Apple failing, not really a pf failing, but still, frustrating.

I'll have to look again and see if FreeBSD pf has gotten the features I need from ipfw, so maybe I don't have to run two firewalls at the same time. :(

> do you want to drop syns where the last 16-bits of seq match the client's port number?

I'm guessing this is something about a vulnerability in client sequence number selection? I'm curious about the details here for what would motivate this.

Oh I'm really sorry, this wasn't a real filter I've used. It was just an off the cuff weird, but doable request. Speculatively you want to block abusive syn floods and your abuser made a weird choice in their packet generator.

Sorry again! I really did just make this up.

yep, i feel like a network magician when I work with pf. it's so pleasant. it's at just the right abstraction level to be powerful and intuitive.

I had a tough time even with PF. I got a basic config going for my network by copying stuff from the book of PF. When I tried to go beyond that things got frustrating. I think I was trying to set up a VPN which, I know this is a famously frustrating task, but I was hoping that PF would be somehow more legible or less opaque. There was nowhere to reference for the syntax and what it’s capable of.

I was hoping it was like a nice programming language whose internal structure made sense to an experienced developer. Where I can incrementally build things up and log things to the console as I go along and troubleshoot. But it turns out that setting up a vpn involves a big bang config with a dozen lines and it’s unclear which of them is broken.

It’s a DSL and not a programming language and often there is very little you can do to troubleshoot that’s short of reading the source code, the protocol spec, and firing up wireshark.

I found various configs on random websites or in the openbsd manual, but none seemed to do the trick. I gave up and installed Tailscale.

This isn’t a knock on PF. But years of reading glowing comments like this gave me some false hope that I could finally grok this stuff and maybe do some creative projects with it.

Also worth checking out Michael W Lucas' books:

* https://mwl.io/nonfiction

I've heard (but not read) good things about his fictional works as well, e.g., $ git commit murder:

* https://mwl.io/fiction/crime#gcm

* https://mwl.io/fiction

I wish there was a "book of nftables" or something like that.

When you choose BSD, many common Linux frustrations evaporate. :)

Rusty Russell’s old iptables HOWTO was okay—or as okay as an iptables anything can be. An nftables HOWTO covering basically the same issues that The Book of PF does has the potential to be much better, simply because it would concern a much less messy system, but somebody has to write it. There’s little Linux-specific about this situation.

It is Linux-specific to some degree.

There's a culture of documentation in BSD which exceeds Linux. There's a larger commercial/reputational market for a Linux book of course, but that attracts different writers, who are often not as good/knowledgeable/motivated/dedicated/etc as the BSD documentation writers.

Additionally, BSD has a culture of simplicity and consistency which is entirely absent in Linux. This makes documentation more clear and much more durable.

yeah, but many new ones appear, sadly.

(I've used both FreeBSD and NetBSD in the past, this is not a baseless claim)

Yeah, but some of us like pf and systemd. It's so confusing.

Oh come now, no one likes systemd!

I kid. Sort of. Systemd is a great startup launcher -- maybe even an improvement over rc.d. Although I confess I've never had any issues with rc.d. Systemd can be quicker, which is nice, but 15 seconds saved on a server that reboots very infrequently is not super interesting. More importantly, the rest of systemd is less compelling.

Now a comprehensive book on systemd would be really nice. Most of the stuff out there is focused on service files, but there's a LOT of other stuff in the systemd ecosystem that doesn't have much easily accessible content available.

I think I agree that there’s not a _ton_ of content out there on 80%+ of the systemd featureset.

However, the first-party docs are really quite good. Considering that some blog posts are written to compensate for a lack of docs, I wonder if there’s a causal relation there.

But then you're stuck in the 90s together with the two aging guys who maintain it.

I'm joking of course, but that is a bit how I always feel when trying BSD. It reminds me a lot of Linux in the 90s, plus its development appears kind of glacial compared to Linux.

Judging from the comments here, it should be called "the book of nft" for comedic effect :)

Take a look to “Linux Firewalls: Enhancing Security with Nftables and Beyond”

Thank you! I will!

Don't know if it's allowed here, but I'm selling my PC Engines APU2 if anyone is interested :)

It has OpnSense installed, but you can install anything you want

4GB RAM, 16GB ssd, wifi

https://www.facebook.com/marketplace/item/4038077093121720

PF: Packet Filtering (Open BSD Firewall). Saved you a click there.

Thank you

Interestingly, the author dodged that one:

>A few questions immediately pop into readers' minds on hearing this news. The ones I get most often are,

> Why now? What took you so long?

>which quite frequently combines with

> What changed? Are previous editions now useless?

Which somehow contribute to highlight the inadequacy of the reader for not knowing what PF stands for in the first place.

There has arisen this strange obsession on this website with every page having to explain what a project is about. This makes some sense for the marketing of the project, if there is for example a new version of some software. But for a personal blog it really does not. If a reader of a technical website is incapable of searching for "openbsd pf" then maybe they are indeed inadequate and are better off reading something else.

Right. It's a question of context. And here we all are on a website that is basically purpose built for taking things out of context. We might just need to manage our expections in this regard.

I just think it would be nice if "The Book of PF" was quoted so it's obvious it's a book title, not just a weirdly phrased sentence. After that, yeah, it's pretty obvious whether you care about the topic or can just move on without commenting on your apathy.

I've been rightfully downvoted above. My comment was not perceived as pH-neutral as I was imagining it.

HN is a place where people come to get exposed to a very diverse list of topics, from seismic faults to quantum computing.

As such, my expectation is that an article linked on the front page has a minimum of context for those coming from far away. In this case, the article that was chosen onto the front page not only lacks that context, but also is blissfully unaware of this expectation. Which is perfectly fine and normal for the author and for the intended readership.

I found that mismatch fun to read, in the "frequent questions" part of the article, and did not anticipate that my remark would be taken as caustic.

It’s a post in a BSD blog, specifically of the author of The Book of PF, that is in its entirety concerned with the question of whether a new edition of The Book of PF is coming. It’s not an ad in a computer magazine. It’s fair to presuppose that a reader of the blog knows what The Book of PF is. (It’s then arguably not fair to post it for a general audience on HN, but the author can hardly control that.)

Please don’t assume everybody who presupposes knowledge does so to assert their intellectual superiority. Presupposing knowledge is how we can communicate anything at all in a culture where one can be a dozen inferences or a couple of years of learning away from even understanding a question. And people who assert their intellectual superiority usually aren’t worth listening to at all—so if you end up concluding that every smart person is doing it, or even most of them, or most of them in a field, then you have a wide-ranging misunderstanding of some sort. This, about presupposing knowledge, is one that could be. (Another popular one is not understanding that, in mathematics, “obvious”, etc., does not mean “skill issue if you don’t get it” but rather “you’ve missed something important if you don’t get it, go back and think on it some more”.)

Ok, great, so we put Packet Filter in the title. Still doesn't explain it. So let's put Packet Filter for BSD in the title. You didn't explain what BSD is.

Eventually let's just put the entire article in the title.

> not knowing what PF stands for in the first place

I'm going to level you up 10x right now.

1. Select the text "Book of PF" in Chrome

2. Right click on it

3. Search with Google

4. Read the summary "OpenBSD's stateful packet filter, PF, is the heart of the OpenBSD firewall"

BOOM! You can now do this with anything you don't know! You no longer need to ask someone to explain everything to you!

I’m using Opera, what should I do? Unclear.

Works the same! I'd google it, though.

Basic question: Is PF related to ebpf by any chance?

PF stands for packet filter in both cases

no, but b in bpf stands for Berkeley, so the interface originated from bsd.

bpf is a virtual machine to process network packets in kernel space. So it is sort of like the low level assembly language of network processing. It is entirely possible to build a high-level packet filtering language that compiles down to bpf, But I don't think PF does this. PF appears to use it's own specific network processing interface.

https://man.openbsd.org/pf

Note the pf specific ioctls used to inject rules into the kernel.

Reply on news.ycombinator.com