That Grumpy BSD Guy: A Short Reading List

© 2025 Peter N. M. Hansteen

A collection of pointers to things I have written and that I think may be of value to you too, my fellow geek friend

I was recently (late May of 2025) asked to provide a list of things I have written over the years that would be suited to offer useful insights to someone not familiar with my work or the field(s) I cover.

In addition to the book I wrote and have revised when the time seemed right, I have written the odd blog post over the years, and this is the list I came up with, in roughly reverse chronological order:

---

Note: This piece is also available without trackers but classic formatting only here.

---

EU CRA: It's Later Than You Think, Time to Engineer Up! (2025) -- A call for stepping up to real, good engineering practices in software development and maintenance, with a slight emphasis on the fact that by the end of 2027, there will be legislation in force that will in fact compel the industry to act. Expands on the earlier No Project Is an Island: Why You Need SBOMs and Dependency Management (2025) with a view to performing an introductory workshop for working or aspiring developers and devops/sysadmins. And perhaps even their suits-clad managers.

For Upcoming PF Tutorials, We Welcome Your Questions (2025) -- I have been giving PF tutorials for about 20 years, for the last few years in cooperations with Max Stucchi and Tom Smyth. This piece was written to encourage questions and other input while we are preparing for the BSDCan 2025 session, which we are still working on preparing as I write. However, we always welcome your input and we have provided contact information in the piece itself. Also available tracked, prettified.

Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (2025) -- A long-running experiment, started all the way back in 2007, with the intent to make undesired activity less desirable to engage in, reached a milestone of sorts. That event I considered significant enough that I finally wrote that retrospective some of my readers and correspondents had been asking me to do for some time. Also available tracked, prettified.

No Project Is an Island: Why You Need SBOMs and Dependency Management (2025) -- This piece is really about software engineering coming to grips with what real world engineering is all about. The world, or parts of it, finally decided that we could no longer consider software "just a bit of typing", and we are answering the challenge by leveraging lessons learned by working on free software. A further evolved version could turn up at future public events. Also available tracked, prettified.

A Suitably Bizarre Start of the Year 2025 (2025) -- Because, well, the time around the start of the year showed up a few truly bizarre things, a surge in truly nonsensical spamming activity being one item. The number of imaginary friends collected has kept up the pace, see links in the piece itself for up to date information. Also available tracked, prettified.

You Have Installed OpenBSD. Now For The Daily Tasks. (2024) -- I am much indebted to Solène Rapenne for pointing out to me that two earlier pieces I had written about life with OpenBSD were, while not actually wrong, just quite a bit out of date. This piece recitifies that situation, and provides some basic advice for day to day life with our favorite operating system. Also available tracked, prettified.

Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End) (2024) -- Fresh off writing his excellent mail server book, Michael W. Lucas posted a thing on the Mailop list that had me write a short piece on domain-only trapping (linked in this one), and after a quick think, also this piece that offers other minimalist but actually usual configurations. Also available tracked, prettified.

The Despicable, No Good, Blackmail Campaign Targeting ... Imaginary Friends? (2022) -- A follow-up to an earlier piece on the embarrasment-based extortion spamming campaigns we had been seeing for some years. This piece makes a hopefully clearer case than the previous one that the potentially embarrasing video material the messages claim exist most likely does not. After all, multiple thousands of addresses that have been known to never have existed are targets of these campaigns, swelling temporarily the list of greytrapped hosts. Also available tracked, prettified.

A Few of My Favorite Things About The OpenBSD Packet Filter Tools (2022) -- The good people at SEMIBUG asked me to give a PF talk for one of their user group meetings. This is the writeup for that talk, with links to slides and other material. Very much colored by my tastes, but hopefully useful. Also available tracked, prettified.

Badness, Enumerated by Robots (2018) -- Way back when, I started setting my systems to collecting IP addresses that were the source of undesirable activity and publishing updated lists at intervals. That activity stayed useful for longer than I had anticipated, and at some point I wrote this summary of what those systems do, with references to other resources, of course. Also available tracked, prettified.

Maintaining A Publicly Available Blacklist - Mechanisms And Principles (2013) After running the greytrap-based blocklist for some years, I felt the need to explain my thinking about the hows and whys. The first paragraph sums it up,

When you publicly assert that somebody sent spam, you need to ensure that your data is accurate. Your process needs to be simple and verifiable, and to compensate for any errors, you want your process to be transparent to the public with clear points of contact and line of responsibility.

-- Also available tracked, prettified.

Yes, You Too Can Be An Evil Network Overlord - On The Cheap With OpenBSD, pflow And nfsen (2014) -- "Have you ever wanted to know what's really going on in your network? Some free tools with surprising origins can help you to an almost frightening degree.". Yes, with tools that are either part of OpenBSD or within easy reach via the package system, you only need to put in rather modest efforts to reveal deep truths about the life on your network. Also available tracked, prettified.

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (2014) -- Originally a BSDCan paper from the late noughties, with emphasis on the exploit mitigation techniques in OpenBSD and how to leverage them in the effort to limit or even get rid of spam and malware. Even after all those years, some aspects of this text are still quite relevant. This piece has seen occasional updates as indicated by the copyright line. Also available tracked, prettified.

The Hail Mary Cloud And The Lessons Learned (2013) -- The Hail Mary Cloud was a widely distributed, low intensity password guessing botnet that targeted Secure Shell (ssh) servers on the public Internet. The first activity may have been as early as 2007, but our first recorded data start in late 2008. This summary article describes the botnet activities and countermeasures as well as offering some more forward-looking statements about Internet security. Also available tracked, prettified.

Those, I said to my correspondent, are likely the more interesting entries.

If you have read this far and found something useful or enlightening by visiting the linked items, that will make me happy to have turned some Sunday afternoon procrastination into something useful to others. And I have this to offer as a bonus for your perseverance:

I have also been a guest blogger at blog.apnic.net:

What every IT person needs to know about OpenBSD (2021) in three parts, starting with What every IT person needs to know about OpenBSD Part 1: How it all started (also the original in one piece, What every IT person needs to know about OpenBSD (tracked, prettified), and

A few of my favourite things about the OpenBSD Packet Filter tools (2022) also ran as a two part series at APNIC, starting with A few of my favourite things about the OpenBSD Packet Filter tools (part 1) and A few more of my favourite things about the OpenBSD Packet Filter tools (part 2)

---

Upcoming events:

Ottawa, Canada: BSDCan 2025 has tutorials June 11-12, 2025 and talks June 13-14. A new version of Network Management with the OpenBSD Packet Filter Toolset will go ahead there.

A little later on in 2025, the EuroBSDcon 2025 conference is still accepting submissions for papers and tutorials, so if you have an interesting BSD-related topic you want the world to know about, your submissions will be welcome at the EuroBSDcon submissions system, where the deadline is 2025-06-21, or June 21st, 2025 (full disclosure: I'm on the program committee). This year's conference is set in beautiful Zagreb, Croatia in late September.

At EuroBSDcon 2025, there will be a Network Management with the OpenBSD Packet Filter Toolset session, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon. We are hoping to have physical copies of the book available in time for the conference, and hopefully you will be able to find it in good book stores by then.

---

Yes, You Too Can Be An Evil Network Overlord - On The Cheap With OpenBSD, pflow And nfsen

Have you ever wanted to know what's really going on in your network? Some free tools with surprising origins can help you to an almost frightening degree.

One question I get a lot (or variants that end up being very close) is, "How do you keep up with what's happening in your network?". A close cousin is "how much do you actually know about your users?".

The exact answer to both can have legal implications, so before I proceed to the tech content, I'll ask you to make sure you understand the legal framework you will be working under with respect to any regulatory requirements or other legal limits as they apply to monitoring in general and your users' privacy in particular before you proceed to setting up a monitoring infrastructure. Legalisms can be tiring to a techie, but illegality can bite you really really hard.

Now for the tech side of things, of course I have network monitoring and a few favorite tools. This article has been brewing, for some values of, for quite a while. While I was collecting notes and anecdotes, last (Northern hemisphere, 2013) summer yielded news stories that showed more pervasive surveillance than most had even imagined, operated by a three letter US government agency, and writing about the relatively benign techniques in my favorite toolbox became less appealing for a while.

But the questions about how to really get to know your network are still relevant to networking practitioners, so I'll let you in on a few not really secret facts about how it's done. Of course all of the things I describe here are easier if you're using OpenBSD, but then you probably knew that fact about our favorite operating system already.

OpenBSD has traditionally had an impressive suite of networking tools, and as we know every release brings new enhancements and sometimes brand new tools for us to make use of.



Enter pflow(4), Yet Another Network Pseudo Device

The NetFlow protocol was invented at Cisco in the early 1990s. It's designed to collect traffic metadata, where the basic unit of reference is the flow, defined as the source and destination IP address pair, the matching source and destination port for protocols that use them, the protocol identifier, time started and ended, number of packets sent, number of bytes sent, and a few other fields that have varied somewhat over the NetFlow versions.

Flows are unidirectional, and a TCP connection will typically consist of a pair of flows, one in each direction. For contexts where you do not need to store the content of the traffic, this is the data you want. A multi-gigabyte file transfer, once it concludes, will produce a netflow record that takes up only on the order of a few hundred bytes, much the same as the almost dataless name service request that probably preceded it.

On OpenBSD, various netflow sensors and collectors had been available for a while when the new network pseudo device pflow(4) debuted in OpenBSD 4.5. As you would expect on OpenBSD, pflow is tightly assosciated with PF, and collecting data from an OpenBSD machine (typically a gateway) involves adding the state option pflow to PF rules that you want to collect Netflow data for, much like you would pick rules for logging with log or log (all) options. To wit, a rule for collecting pflow data would look something like this:

pass out log inet proto tcp from <clients> to port $email keep state (pflow)

But then generating pflow data proved so enormously useful in a lot of contexts that the OpenBSD 4.5 release also included an option to set state-defaults that would apply to all rules in the rule set unless specifically excempted. You guessed it, the most popular set in a number of PF shops became

set state-defaults pflow

more or less overnight after the OpenBSD 4.5 release.

Once you have reloaded your rule set with the pflow option in place, you are generating pflow data (in this case, for any traffic that matches a pass rule in the rule set). But to actually get the data to somewhere you can study them, you need to set up both a sensor and collector. The sensor is the pflow interface, which you configure via ifconfig commands, or for a permanent configuration, in the /etc/hostname.pflow0 interface configuration file. The /etc/hostname.pflow0 on the gateway closest to me right now looks like this:

flowsrc 213.187.179.198 flowdst 192.168.103.252:9995
pflowproto 10

which means, essentially, that any pflow data generated will be sent with a source address of 213.187.179.198 to the collector we hope is listening at 192.168.103.252, UDP port 9995. Every flow is recorded, and sent to the collector. The flowproto 10 part means we use flow protocol version 10, the latest one with all the newest bells and whistles (which is recommended on OpenBSD only on version 5.5 or newer).


The Collector

Up to this point, you are free to choose any collector at all, or for that matter, let your pflow sensor send data endlessly into the void. In The Book of PF I spend quite a bit of time explaining netflow via Damien Miller's excellent flowd, mainly because it's damned fine software and very well suited for the purpose, but here I'll go the lazy route and show you the tool I actually use, which is nfsen, which comes out of the OpenBSD package system with a usable web interface as a front end to nfcapd and a host of related tools.

Do take some time to click that nfsen reference, the documentation there is quite usable and provides better illustrations than what I can offer at the moment.

Installing nfsen on OpenBSD is, as expected, as simple as can be. On an otherwise normally configured OpenBSD system, the single command

$ doas pkg_add nfsen

will get you most of the way there. Do read the package readme as the messages instruct you to. Basically, you will need edit the configuration file /etc/nfsen.conf. Adding data sources is likely the only thing you will need to do at first, look for the stanza that looks like this:

%sources = (
    'upstream1'    => { 'port' => '9995', 'col' => '#0000ff', 'type' => 'netflow' },
    'peer1'        => { 'port' => '9996', 'IP' => '172.16.17.18' },
    'peer2'        => { 'port' => '9996', 'IP' => '172.16.17.19' },
);

Here you add the sources you have configured earlier. I give all my sources a distinct color (picking among the CSS-style RGB values you youngsters probably know by heart but old farts like me always have to look up), IP address, type and port, so it's easier to tell them apart.

Then you run a perl script to configure the package, start httpd, start the nfsen package (and add it to the pkg_scripts= line in your /etc/rc.conf.local so it will start at next reboot too).

That's all there is to it. Soon the web interface will start filling in the graphs, and you can point and click your way around address ranges, time ranges and a host of other parameters. You will find that every connection you specified in your configuration is indeed logged, and you have all the metadata you asked for.

After a while you will start appreciating that nfsen displays the command line version of your point and click choices, so you have a better starting point for those wrinkles in the data that are not easily or at all accessible via the web interface.


The All-Seeing Eye Of The Evil Network Overlord

You can tell just who, or at least what IP addresses interacted with each other when, how much data was transferred and to of from what services or ports. It stands to reason that in most jurisdictions there are rules about how data of this kind is to be handled and secured. Make sure you deal properly with the data you collect, staying within whatever limits apply to you. But within those limits, here's your chance to be an evil network overlord. Use it wisely.

Netflow data has been used for a number of things. In his very readable book Network Flow Analysis, Michael W. Lucas relates a story about how they pinpointed the source of entry for a Windows worm into a corporate network using netflow data. I've found netflow to be very useful in a number of contexts myself (as briefly mentioned in the earlier DDOS article, and using netflow data to charge for metered access is not unheard of either), but the most striking example I've seen did not involve an attack, merely an intermittent network nuisance that occasionally cost insane amounts of money.

The setting was this: A couple of years ago, I was a relatively new hire in a large corporation that serves IT services of various kinds among others to an almost equally-sized financial firm. In one part of the financial firm there was a place where trades involving dollar values larger than most of us can imagine were made using a telnet interface to something else, and the 80 by 25 character displays were at times not moving at all. Trades were lost because the tiny packets did not arrive on time.

By the time I joined the company, the regular network crew that took care of that particular arm of the financial firm had been unsuccessfully trying to debug and fix the disruptions for quite a while. A call went out for help, and I proposed setting up a Netflow collector much like what I described earlier in the article.

The proposed budget was pretty close to nothing at all besides my time, so I got the go-ahead. The OpenBSD part of the configuration was done inside half an hour, and after peeking at Michael's book I even fished out the right sequence for the Cisco wranglers to input in their gear so useful data started arriving.

Then came the long wait. Graphs were accumulating, and after a while I would put several weeks' graphs on top of each other and hold them up to a light source. They matched perfectly. I could tell when people started arriving at work, I could tell when trading started in various cities, I could see the dip for lunch breaks, and the traffic peak for the nightly backups was easy to identfy.

But the source of the random network disruption did not turn up in the overall data volumes.

After a few weeks, I asked the local IT support to send me an email as soon as possible when disruptions occurred, with the name and/or IP address of the computers seeing disruption. Soon after, the first messages started arriving. I used the nfsen web interface to search the data around the reported times and looking at the IP ranges. At first, nothing really stood out. There was no sudden increase in data transferred at my sensors.

But then it occurred to me that the overall data volume was not necessarily the problem, so I started looking at hosts in the likely address range by number of flows (as in, number of open connections). That was all it took. Going back over a handful of reports, I noticed that on every occasion, for a few minutes one particular IP address stood out. For a very short time, a few days every week, one host on the network owned essentially all flows that passed by my sensors. No other host came even close.

It turned out that the machine was used to generate some rather heavy duty reports, collecting data from a large number of data sources. My guess is that the reporting software was one of those things that started small and grew over time, and after a few years it became a marked liability, simply because it was connected to the same switch that the traders were using, and reports were generated during trading hours.

I wrote up my report with graphs taken from nfsen (since destroyed and anyway not for public consumption, ever), and recommended that they find a way to move the report generator off to a separate location, perhaps even one with better connectivity to important data sources. I think they took that advice and acted upon it, but I suppose I'll never know for sure.

If you're interested in network traffic monitoring in general and NetFlow tools in particular, you could do worse than pick up a copy of Michael W. Lucas' recent book Network Flow Analysis. Michael chose to work with the flow-tools family of utilities for the book, but he does an outstanding job of explaining the subject in both theory and practical applications. What you read in Michael's book can easily be transferred to other toolsets once you get at grip on the matter.

I've focused mainly on OpenBSD here, but netflow sensors exist or should exist for essentially anything that has a TCP/IP stack. And nfsen works well on Linux and other Unix-like systems, too, I've heard tell.

---

As I write this I'm still working on the third edition of The Book of PF. The third edition came to be mainly because of changes introduced in OpenBSD 5.5, and the plan we're working towards is to have the book ready in time for the release. As you may have seen elsewhere, The Book of PF, 4th Edition is now available, with updates covering OpenBSD 7.8 and FreeBSD 14.n, with some forward looking material on OpenBSD 7.9 and FreeBSD 15 as well as previews of features that will be in FreeBSD 16 only.x

BSDCan: I will be at BSDCan again this year, offering two tutorials (see the Upcoming Talks panel at top right). More details will follow later, but these sessions will be designed mainly from input I receive from prospective attendees, and so will be critically dependent on your input, or even more so than earlier. See you there!

---

Update 2014-03-01: Thanks to Sebastian Benoit for pointing out that configuring pflow with flowproto 10 is really only well supported on OpenBSD 5.5 and newer.

Update 2014-04-27: PF tables vs html tags sometimes does not end well. Fortunately fixable.

Update 2015-10-25: For running nfsen with the OpenBSD httpd (and possibly others), you likely will be happier if you add php_fpm (which the nfsen package pulls in as a dependency) to the pkg_scripts variable in your /etc/rc.conf.local, much like this:

pkg_scripts="php_fpm nfsen" 

Discovered the hard way, one could say, only after a power outage broke the serenity of my lab's nfsen installation, the web server only spitting out 500 internal server error messages.

Update 2015-10-30: Several correspondents have asked whether NetFlow export is doable on various proprietary products. The answer is in most cases yes, but terminology may vary. On Cisco products you can be fairly sure to find terms NetFlow and IPFIX, while I discovered today that Citrix Netscaler for reasons of their own entirely mask the feature behind the term AppFlow. For other products, check the documentation for the obvious keywords.

Update 2026-02-24: Typokill and information about The Book of PF, 4th Edition.