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.

---

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.

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.

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.

---

For Upcoming PF Tutorials, We Welcome Your Questions

© 2025 Peter N. M. Hansteen

A good tutorial should sound to passersby much like an intense but amicable discussion between colleagues.

In a little over a month, I'll be heading out to Ottawa to attend BSDCan 2025, to help run the conference and to give this year's Network Management with the OpenBSD Packet Filter Toolset tutorial, with my co-presenters Max Stucchi and Tom Smyth.

I've been a regular at BSDCan since 2006, attending every year since except 2008 -- I wanted to go that year too, but other business (actually the business of getting out of a company I'd helped build) kept blocking my preparations even though I had a fresh book out with the first edition of The Book of PF published late 2007. The most recent edition, the third, is available from here and from other good book sources.

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

But I've kept coming back after that, and I've almost always given the PF tutorial at BSDCan, this year again there is a PF tutorial, Network Management with the OpenBSD Packet Filter Toolset, which is likely to follow the format from the previous years.

The format of the session is a sequence of short, intensive lectures interspersed with lab excercises. You can get a reasonable idea of what to expect by looking at the slides from the last sesssion. It can be worth noting that future updated versions of the slides will be available in the same location.

But we're still weeks away from the session, and we are in the period of time when we are making revisions and adjustments. So this is a good time to tell us what topics you would like to see us cover in the next session.

If you have one or more questions or suggestions, please do send them on to us at questions@pftutorial.net, preferably after taking a peek at the slides from the last sesssion.

We will consider each carefully, and if your question or suggestion turns into a new or changed topic, we will give credit where credit is due.

We are looking forward to seeing you in Ottawa in June!

Check out the BSDCan 2025 site for more information on the conference.

If you are unable to attend BSDCan, all is not lost: 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.

---

You might also enjoy

A Few of My Favorite Things About The OpenBSD Packet Filter Tools (2022)
The Hail Mary Cloud And The Lessons Learned (2013 - 2024)
What every IT person needs to know about OpenBSD (2021)

No Project Is an Island: Why You Need SBOMs and Dependency Management

© 2025 Peter N. M. Hansteen

The system you develop and maintain does not exist in isolation. Providing SBOMs for our work is our way to show we care.

Software is a relatively recent phenomenon. For a long time, you could credibly say most of its existence, software was poorly understood by society and industry at large.

There was a time -- and I am old enough to remember that time -- when software was considered a minor but necessary component in IT deliveries. That perception changed over time, and during recent decades it is no longer in doubt that the software industry is just that, an industry in its own right.

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

What we did not have at all until recently was a set of formal requirements to verifiably show what it is we deliver.

In other fields, the term Bill of Materials, or BOM for short, is a familiar term. The Bill of Materials is a document or set of documents that lists all component parts of a delivery.

This is the kind of document that becomes crucial in contexts where the procuring organization is geared toward accounting for everything and auditing when the supplier least expects it.

One such context could be when your organization has landed a contract to supply a backhoe, an armored personnel carrier or even a ship, and the contract requires you to specify component materials used, down to the nuts and bolts level.

Your delivery would not be considered complete without the Bill of Materials or Manifest.

As an aside, it is likely worth noting that the US Department of Defense's need for structured text markup in processing inventory information such as bills of materials was one of the more important drivers, albeit not the only one, behind the creation of SGML, the direct precursor to HTML and XML.

For physical deliveries to organizations of some stature, a Bill of Materials has been a standard part of the process across industries as an important part of quality assurance and a fundamental part of maintenance processes.

Software, on the other hand, has traditionally not been subject to that kind of scrutiny.

Until software that made critical infrastructure work broke, that is.

During the twenty-tens and -teens, we had several incidents where software bugs were tickled enough to lead to costly and embarrasing episodes, and the powers that be (the kind wearing suits) discovered that software was indeed something they needed to care about.

These episodes spurred several things, one being memes like

(XKCD #2347, please also read the explainer), which lead to the common belief that supply chain management and the subtopic dependency management is mainly a problem that concerns open source software.

This assertion is simply not true, in that no project is an island.

Whether you let others see the code you wrote nor not, the software does not exist in isolation.

All software has dependencies, and in the open source world this fact has been treated as a truth out in the open. Every free operating system, and in fact most modern-ish programming languages come with a package system to install software and to track and handle the web of depenencies, and you are supposed to use the corresponding package manager for the bulk of maintenance tasks.

So when the security relevant incidents hit, the open source world was fairly well stocked with code that did almost all the things that were needed for producing what became known as Software Bill of Materials, or SBOM for short.

So what would a Software Bill of Materials even look like?

Obviously nuts and bots would not be involved, but items such as the source code files in your project, any libraries or tools needed to build the thing would be nice-to-knows, and once you have the thing built, what other things -- libraries, suites of utilities, services that are required to be running or other software frameworks of any kind -- that are required in order to have the thing run are obvious items of interest.

So basically, any item your code would need comes out as a dependency, and you will find that your code has both build time and run time dependencies.

Those terms will be quite familiar to users and the developers of the package manager systems for the various open source operating systems. The very same items you would recognize from a listing of package dependencies in a package management tool will turn up in our Software Bill of Materials too. Depending on the specific tool and options you use, the SBOM could contain additional information that may not be entirely relevant in a package manager context.

Under any circumstances, with package systems in place, and even vulnerability scanners available to scan for unsecure code at rest or while running, the free and open source software communities were in fact well positioned for the legal requirements when they hit, and the lessons learned from package management came in quite useful in meeting and satisfying the updated requirements.

Several pieces of legislation emerged from the at times panic flavored fallout from the security incidents. Which ones are more relevant to you will become clear as we move on.

Depending on what parts of the world you care more about, the emphasis will either be on US Executive Order 14028 of May 12, 2021, Improving the Nation's Cybersecurity and its summaries found at the Software Bill of Materials Home page hosted by the National Telecommunications and Information Administration, or for the EU and our neighborhood, the EU Cyber Resilience Act (CRA) with slightly less hardcore legalese available at the Cyber Resilience Act start page.

So that's our backdrop for now. The name of the SBOM game is compliance with those legal requirements, and to not only generate the information -- that's the relatively easy part -- but also to present the information in a way that is understandable and actionable to stakeholders who are not themselves software developers.

The information is there in our code, and with development tools and code scanners a developer is well placed to poke around.

The next challenge it to take that information and present it in a way that conforms with the legal specification and is presented in a way that is usable for stakeholders that are not developers.

In addition to module or package names and versions, the expected SBOM product will typically include information on any identified security problems such as CVEs and a specification of the licenses that apply to each of the identified dependencies.

Thanks in large measure to the open source heritage of the specifications and tools, both of the commonly used SBOM specifications (SPDX and CycloneDX) consider information on licenses used in a file or project as tagging and tracking relevant items, and the tools we describe have some measure of support for tracking and reporting on licenses in use. This can be useful for flagging licenses that may be mutually incompatible or even incompatible with your organization's business goals.

As I hinted at earlier, there are tools available for all of this. If you want to go on and explore for yourself, I would recommend going to the awesome-sbom site, which offers a curated collection of SBOM resources and tools hosted as a Github rego.

There are a large number of tools available, with varying feature sets. In addition to the free tools you find via that collection, several tool suites exist that are exclusively commercial or with free trial or reduced features set versions out with full features available only to paying customers.

The tool set I found the most accessible for my poking around was the combination of syft for generating SBOMs and bomber for display and presentation. The home pages for both are linked from the awesome-sbom collection.

As you can see from that page, there are several SBOM formats around, and to some extent standardization and interoperability efforts are under way. But enough of that, let's look at the actual tools in use.

As a first step, it is instructive to point syft at the base directory of your project and see if it can tell you something you did not know already. syft supports a number of output formats, so if XML is the more readable format to you,

$ syft . -s all-layers -o cyclonedx-xml | xq

will give you pretty-printed XML (assuming you have xq installed) output of what syft found out. Do explore the various command line options for extracting various information about your project.

If you prefer JSON over XML, something like

$ syft . -s all-layers -o cyclonedx-json | jq

will give you readable JSON of the same information. Again, there are a number of options to explore.

When you have explored a bit, you may want to look into how you incorporate these tools in your project and make the SBOM a build artifact.

The bomber documentation has this example suggestion for inclusion in a CI/CD pipeline:

# Make sure you include the - character at the end of the command. This triggers bomber to read from STDIN
syft packages . -o cyclonedx-json | bomber scan --provider ossindex --output json -

In a real world scenario, I could imagine that non-developers would appreciate it if you supplement that line with one using the --output=html option. The HTML output provides a report that lists licenses involved before listing know vulnerabilites by severity and assigned CVE.

While I was writing this article, a colleague who had been reviewing it told me of an episode that shows that even extremely basic use of the SBOM tools can be useful. A customer had called, saying they needed a complete list of tools and dependencies involved in a project, and right away. As a first step, my colleague cd'ed in to the main directory of one of the subprojects for that customer, and issued the command

$ cdxgen .

and was rewarded with a bom.json file that listed somewhere in excess of three hundred dependencies for that relatively minor subproject alone. The customer was suitably impressed and granted my colleague a more realistic and less immediate time frame for submitting the full dependency tree.

More SBOM-savvy co-stakeholders in your project may even be capable of processing your json or xml formatted SBOMs themselves, using tools of their choice.

Your project and customer may already have chosen a different toolset, or you may find that some other SBOM generating and presentation tool set are better matches for your requirements.

It is in fact conceivable that you have SBOM-capable tools within reach in your environment already. The fairly popular images-and-sundry repository system Harbor supports automatic SBOM generation on image push by hooking in trivy for image scanning duty, should you choose to enable that feature for your Harbor hosted projects.

If you want to explore further, please dive into the resource references at the end here.

For the more Bill of Materials savvy developers who want to explore even more, it may be of interest that the OWASP and SPDX teams are working on more specialized BOM variants, including OBOM (Operating system Bill of Materials), SaaSBOM (Software as a Service Bill of Materials), CBOM (Cryptography Bill of Materials), and several more. Again, see the referenced resources at the end here and follow the breadcrumbs.

SBOM Resources

Linux Foundation Training: Automating Supply Chain Security: SBOMs and Signatures (LFEL1007) is a short but information- and reference-filled introduction (free, requires registration, gives you a badge at the end)

The Software Bill of Materials home page at NTIA is the mother ship of SBOM documentation

Browse OWASP CycloneDX for all things about the CycloneDX specification and related tools, also their CycloneDX tool center

Browse the System Package Data Exchange specification (SPDX) for all things SPDX (supported by the Linux Foundation), including copious linked reference material

awesome-sbom is a curated list of SBOM tools and resources

EU residents will want to poke around the Cyber Resilience Act site for reference

Brewing Transparency: How OWASP's TEA Is Revolutionizing Software Supply Chains is a summary of recent work on OWASP Transparency Exchange API (TEA)

SBOM buyer’s guide: 8 top software bill of materials tools to consider is a readable overview of (some) SBOM tools

Olle Johansson's FOSDEM presentations are among several good SBOM talks at that conference (search the site for more)

Peter N. M. Hansteen: Open Source in Enterprise Environments - Where Are We Now and What Is Our Way Forward? (2022, also here) has some insights on how open source software plays a crucial role in enterprise environments and elsewhere

No Project Is an Island: Why You Need SBOMs and Dependency Management is this article (also here)

A Suitably Bizarre Start of the Year 2025

© 2025 Peter N. M. Hansteen

Already somewhat blasé from life in the honeypots, yours truly registers an even more bizarre level of events after a some routine logs spelunking

If you're reading this soon after the piece is published, 2025 is a fresh new year, and I would like to wish you all the best for the year ahead.

Then I want to relate what happened here (or rather at the Internet facing network interface of the server in question) during the initial few hours of the new year 2025.

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

If you are a returning reader, you will be familiar with my ongoing experiment and studies of Internet miscreants and how to thwart their efforts as effectively as possible while expending no more than absolutely necessary in terms of time or energy on our end. Central to those efforts are the greytrapping based blocklist and the ever-growing list of spamtraps, which late in 2024 passed the half a million mark, right now numbering 568212 entries of known bad, not deliverable email addresses in our domains (almost certain to have increased by the time you read this).

I have written about the daily maintenance tasks for the lists, such as they are, in previous entries such as the list homepage pointed to in the previous paragraph and the traplist ethics page as well as the blog post Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (November 2018, also here) or for that matter the piece I wrote about the arrival of the three hundred thousandth spamtrap, The Things Spammers Believe - A Tale of 300,000 Imaginary Friends (also here).

All of those pieces show that the original emphasis was to keep the working environment sane for the local users, and the fact that I could generate resources that I could make available for others to use was really just a byproduct of that work, while of course a welcome one for its users.

After some years, and certainly around the time the list of spamtraps had reached the hundreds of thousands, the "salt the mine and poison the well" part (the fourth principle listed on the ethics page) part had subtly slid more into central focus, and I was adding incrementally to my arsenal of scripts and one-liners to expand the list of "imaginary friends" as I came to think of new angles.

Most of these would involve fishing out potential local parts to (the parts before the '@') from the din of spamd log entries. Some of these are hinted at in Harvesting the Noise While it's Fresh, Revisited (also here).

The pace of growth for the spamtraps list did pick up as a consequence, and as I reported in a fediverse post, the total made the half millon mark at some point in December of 2024.

Part of the updating procedure is to search logs for addresses not already in the spamtraps list. One of the things I tend to do after extracting the list of addresses somebot tried to deliver to and that we have not been included already in the spamtraps is to extract the log entries involving those supposedly new addresses for further processing. The output from that grep centered one liner from the overnight run taken during the late morning of January 1st, 2025 can be found here.

Take a few moments to look at that one if you want.

You will be looking at the output of a series of grep searches for destination addresses.

The bulk of the data shows that hosts not in our local networks tried to deliver largish numbers of messages to third party domains such as qq.com and gmail.com, using our spamtrap addresses as the purported sender addresses, only of course to be added to the set of greytrapped addresses.

Making up addresses in other people's domains to use as From or Reply-to addresses on your spam messages is not a new thing, of course, as long as you do not care to get any feedback on what actually happened with those attempted deliveries.

What baffled me more than a little was that the addresses were apparently used in the exact sequence they would have been found at this site after a fairly recent update run.

Apart from the sheer number of addresses and their freshness, the only item of interest was that behind each of the IP addresses involved there appears to be a number of hosts -- likely virtual machines -- with distinct identifiers in their HELO/EHLO sequence, likely generated strings of a handful of characters such AXBPvDt.

These quasi-random, generated IDs were of course soon made into local parts for new spamtraps. As would, at times some other items it is possible to extract from logs with common unix commands.

So as a start to the new year, this was surprisingly fitting. The general insanity we have seen in this particular field continues, but appears to have reached a new level at the tail end of the tumultous year just past, possibly heading for new levels still.

Good night and good luck.

Addendum 2025-01-13

For those so inclined, it is perhaps worth noting that after a bit of pondering some time after writing this other piece (also here), I started looking at extracting other items from the spamd logs log entries.

I ended up with extracting the local parts for new spamtraps from the purported sender addreses of entries for trapped delivery attempts some time mid-2024. This made for a significant increase in the number of new imaginary friends, and by the final months of that year I had also started extracting similarly from the string offered by the spam senders as their host name in the EHLO/HELO exchange, which of course swelled the population further.

The effect is clearly to be seen in the file that records the number of spamtraps added per year, updated via trivial scriptery roughly daily.

I hope this article and its addenda helps inspire others in our efforts of green cybercrime prevention by giving the actually intelligent detection methods less work to do.

Addendum 2025-03-20

Only a couple of weeks after the previous addendum was written, it was outdated. Due to some trivial resource restraints lead do a slightly different organization of the log data, now as per year files up to and including 2024, and per month from 2025 onwards, in this directory, while the main traplist page still has the list of spamtraps itself in one piece.

---

Upcoming Events to watch for:
BSDCan 2025 June 11 through June 14th 2025, in Ottawa, Canada. The Call for papers is active, with February 12 2025 as the deadline for submissions.

EuroBSDCon 2025 September 25-28, 2025 in Zagreb, Croatia.