No Starch Press was kind enough to send me a review copy of the new 3rd edition of Peter Hansteen’s Book of PF. The first two editions are the standard reference work on the OpenBSD packet filter, and this is a topic I’ve written about in some depth before, so I’m fully prepared to eviscerate Hansteen if he screwed up.
Third edition, huh? So how does this stack up?
Let’s get the obvious out of the way. All three editions have yellow covers, but the first edition had blue trim; the second edition, pumpkin; the third, a kind of fern green.
Once you open the cover, you find that the third edition works much like the earlier editions, starting with a simple packet filter setup and building upon it. Building upon success is perhaps the best education technique, and it fits the topic quite well.
Structurally, BoPF3 is very similar to the earlier editions. CARP and redundancy now gets its own chapter, which is a welcome addition.
The real meat of this book is in the examples, tutorials, and explanations. PF has changed since the second edition, notably with more flexible traffic management and some syntax changes. Not all BSDs have remained synchronized with OpenBSD’s PF, so he has the unenviable job of documenting the differences between OpenBSD, NetBSD, and FreeBSD. He’s done an excellent job of this by combining information where appropriate, but breaking out some topics by operating system. For example, if a topic needs a sysctl, he lists them for each operating system. When a topic requires more in-depth explanation, such as traffic prioritization, he breaks out OpenBSD’s new priority system into one section and FreeBSD/NetBSD’s older altq prioritization scheme in another. This makes it very easy to find what you’re looking for. This book teaches you how to use PF to filter packets just as well as a million dollar appliance, with more insight and control.
One impressive thing is that this book is very clear. Giving a section a title like “Things You Can Tweak and What You Probably Should Leave Alone” gives you very definite ideas about what’s in this part of the book. Hansteen explicitly describes how PF works. He also discusses what happens when the real world impacts your firewall. He hasn’t just got PF up and running in his lab: he actually uses this stuff in the real world, with all its malformed packets and stupid protocol implementations and worse protocols, and keeps services running despite all that.
Complaints with this edition?
As with the earlier editions, the footnotes contain actual facts. It’s like Hansteen wants you to be able to go look up actual sources to verify what he says, instead of requiring us to trust him. As a writer, I prefer assuming blind faith and unyielding obedience from my readers.
If you use PF on any platform, buy this book. You can get it from Amazon (of course), and also get a combined print/DRM-free ebook deal direct from No Starch Press.
This ends the actual review. But someone is going to ask a couple things in the comments, so I’m jumping ahead of them here.
First: my general thoughts on authors writing reviews.
Second: Why hasn’t FreeBSD imported the latest PF?
The FreeBSD and OpenBSD network stacks have massively diverged in the last twenty years. OpenBSD’s kernel uses the Big Giant Lock model. FreeBSD’s kernel is much more finely locked, and the network stack can be in multiple CPU cores simultaneously. Despite their common heritage and licenses, FreeBSD and OpenBSD are different operating systems. They have different use cases. They are designed for different uses. They target different hardware.
FreeBSD’s previous PF import required a lot of work to make it fit its network stack. The FreeBSD Foundation invested a fair chunk of change in thrashing PF in the network test cluster and on high-performance customers so that it didn’t slow down the network stack. (It’s not that OpenBSD is slow, it’s just designed differently than FreeBSD.)
A “new import” is not trivial.
FreeBSD has a flexible firewall system, however. A new PF could be imported as, say, pf56.ko, without impacting the older PF import. You could use mailwrapper-like functionality to transparently assign the proper userland programs to the PF version in use. This can be done.
Nobody has done the work.
I suggest you get coding.
