Nesten all phishing-trening for sluttbrukere har feil utgangspunkt

© 2024 Peter N. M. Hansteen

Mange av de såkalte opplæringsprogrammene om phishing og annet med epost er tilnærmet ren støy, og det finnes mer produktive tilnærminger.

Mange av de såkalte opplæringsprogrammene om phishing og annet med epost er tilnærmet ren støy, og hele konseptet har etter mitt hode totalt kontraproduktiv tenking som utgangspunkt.

Merk: Denne artikkelen er også tilgjengelig uten sporing men bare klassisk formatering her.

Til det første - når det dukker opp en melding som har å gjøre med min ikke-eksisterende bil og parkering i en by der bedriften har et kontor jeg aldri har vært innom, så er resultatet nokså opplagt, da gidder jeg selvfølgelig ikke annet enn å gjøre slikt man gjør med spam som av inkompetansegrunner kommer forbi Exchange-serveren og tilhørende woodoo og lander i en innboks.

Men som sagt er utgangspunktet feil.

Problemet er at brukere på alle nivåer i alle organisasjoner har blitt lært opp til at grafisk støy er en nødvendig del av epost. Det er nemlig innhold med grafisk innhold og HTML-elementer som gir størst potensiale for å overføre og skjule ondsinnet innhold av alle slag. Om en holder grafisk innhold i meldinger til et minimum, utsetter en automatisk andre for mindre risiko ved bruk av epost.

Den produktive tilnærmingen ville være å lære opp brukere, spesielt de med lite teknisk bakgrunn, til å la være å sende meldinger med "rik tekst" i alle tilfeller der det ikke er helt nødvendig. I tillegg må også "ikke-tekniske" brukere faktisk få såpass grunnopplæring i verktøyene de bruker at de blir satt i stand til å forstå ramsen av "Received:"-headere som vises bare de klarer finne alternativet for det i den ÅH SÅ GRAFISKE mailklienten.

Det er mye annet en kunne si om uvettig bruk og oppsett av epost, men det kan vi la være her (interesserte finner mye av mine rants -- hovedsakelig på engelsk -- om slikt og beslektet via profilen min).

Dette er min reaksjon på en post på LinkedIn, men teksten var for lang til å være en kommentar i det mediet.

You Have Installed OpenBSD. Now For The Daily Tasks.

Despite some persistent rumors, installing OpenBSD is both quick and easy on most not too exotic hardware. But once the thing is installed, what is daily life with the most secure free operating system like?

Welcome to OpenBSD! I assume you are reading this as a new user who has just completed installing the system. If you are more experienced with the system and reading because you want to see what they're teaching the young ones these days, you are welcome here, too. And at any rate, input such as corrections and comments are always welcome.

But first, for the really impatient, here are the main points we cover in this piece:

---

TL;DR: Supported Releases and Four Commands You Need To Know

• OpenBSD has two releases per year, May 1st and November 1st (roughly). Only the two most recent releases are supported.
• The first command to run after a new install is syspatch, which pulls in any security updates and installs them. If the output indicates a reboot or other action is needed, do as the program says.
• OpenBSD's sudo replacement doas is in base, is easy to set up and use and likely fills your needs for privilege elevation.
• Third party software comes in packages. Use pkg_add to install packages. For finding packages, openbsd.app might help.
• When you need to upgrade to a new release, sysupgrade does the job well in almost all cases.
• Please keep yourself up to date on developments, and keep the length or limit of the support period for your release in mind. Also, we will offer some insight on running -current at the end.

---

Installing OpenBSD is quite straightforward on most hardware (possibly excluding some true antiques and, occasionally. the newest of the new). In the rest of this article we will assume that you have completed a basic install, following the OpenBSD Installation Guide in the OpenBSD FAQ, possibly supplemented by other sources.

In our experience, following the FAQ's instructions should get you there, and keep in mind that the defaults are sane, and it is not entirely unheard of that the interactions with the installer consist almost entirely of pressing the Enter key in response to the prompts with suggested default values. And if you have not read the afterboot(8) man page, now is likely a good time to give it at least a glance.

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

Planning Ahead: One Release Every Six Months, The Two Most Recent Releases Are Supported

When you start poking around OpenBSD and learning how things are done, it is important to keep in mind that

• The OpenBSD project makes two releases a year, with release dates normally falling on or around May 1st and November 1st.
• The project offers security updates to the base system and packages for supported releases, currently the two most recent ones. See the FAQ item about OpenBSD flavors for further explanation.
• Support is available primarily through the project mailing lists. In addition, user groups and commercial (paid) support options are available in several locations.

This means that there is no such thing as an OpenBSD Long Term Support (LTS) release, you are actually expected to upgrade to a supported version at least once a year.

At the time of this writing (early September 2024), the supported releases are OpenBSD 7.4, which was released on October 16th, 2023, and the most recent release OpenBSD 7.5, released April 5th, 2024. Once OpenBSD 7.6 becomes available (the link will start working some time before the event), OpenBSD 7.4 support stops and you need to move on to a supported release.

So once you are past the initial experimental phase, please start planning for how to maintain your systems. You will not regret doing those preparations down the road.

---

Protip: Before starting anything that produces output that likely scrolls off the top of your screen or window, start a script session so all visible events are preserved in the file you specify. See man script for details.

---

Your First Move After Install: Run syspatch

There you are, with a fresh install of a still supported release of OpenBSD.

The first thing to do is to check whether any security updates (patches) are available. The easiest way to check is to choose the Patches link from the main OpenBSD website. If you installed your release close enough to the release date, there may be no patches available yet, but you can rest assured that over the lifetime of a release, there will be some. Towards the end of their lifetimes some releases have seen twenty or more updates.

If you are on one of the more common platforms (amd64, arm64 or i386), you could even skip the manual check and let syspatch do the job for you (for the other 11 platforms, the old fashioned patch and make process, managed and verified via signify still applies, see the contents of each patch file).

To run the initial syspatch on a new system, log on with the user you created during the install process, then su to root, and run syspatch with no arguments.

If you have Internet connectivity and there are installable patches available, the command lists them as they are fetched and applied.

If no patches are available, the command exits quietly.

If the messages from syspatch or the patch description indicate that one or more services have been updated, make sure to restart those services to ensure that only the updated binary is loaded and running.

If the messages from syspatch or the patch description indicates that a reboot is required, please do reboot your system before proceeding. In that case, a shutdown -r now is likely appropriate before you go to the next steps.

For Administrative Tasks, doas Likely Fills Your Needs

With all available security in place for your OpenBSD base system, you more likely than not have a few more system administration tasks queued up, such as installing packages.

Performing those tasks require elevated privileges, so logging on as root may seem tempting. Please resist that temptation. It is much better if you only run with higher privileges when the situation actually requires it, and the OpenBSD base system has doas available for that purpose.

OpenBSD, like most of the Unixlikes around, used to rely on sudo for going to higher privileges, but feature creep happened over the years, by the time OpenBSD 5.8 was released, we had doas available for "about 95% of the things people actually use".

Out of the box, doas comes almost ready to use.

As the man page hints, the command will only work with a valid /etc/doas.conf in place.

Fortunately, the configuration file man page offers an example that is a reasonable starting point. If you do cut and paste that one, please replace the user names aja and tedu with something appropriate for your local environment.

Simpler and more specific configations are available, but even with those minimal edits, you will no longer need to log in as root or su to root to get things done.

For Anything Not In Base, Look to Packages with pkg_add and Other pkg_* Tools

A fresh OpenBSD install is a surprisingly full featured operating system. If you specified during install that you would be running the X windowing system, the system will offer a graphical login screen and present you with the fvwm window manager.

However, the default window manager may be perceived as too basic for some tastes, and in a typical end user scenario, you would typically want at least

• A desktop environment
• A web browser
• A suite of office software

This is where the OpenBSD ports and packages system comes into play. For installing packages, the tool you want to use is pkg_add (for some background and examples of how to use the ports and packages system, see my earlier piece You've Installed It. Now What? Packages!, also available prettified and tracked here).

The OpenBSD packages collection offers several options for all three categories, and a common combination is
xfce for desktop environment,
firefox for web browsing and
libreoffice for the office suite.

For package installs on OpenBSD, the general procedure is,

find the package name (your guess is likely right or quite close),
run pkg_add packagename,
read any message the command outputs at the end, and follow the steps indicated.

If the package install outputs instructions, you will likely also find the instructions in /usr/local/share/doc/pkg-readmes/packagename, but the earlier advice to run anything important in a script session applies here too.

So in our desktop scenario the sequence would be

$ doas pkg_add xfce
follow the instructions the package message prints. You may need to log out and back in after this step (and yes, you can have each user specify their own separate destop environment).

$ doas pkg_add firefox
follow the instructions the package message prints.

$ doas pkg_add libreoffice
follow the instructions the package message prints.

At this point, the packages you installed are ready to use, and you can browse the web and read and produce office documents to your heart's content. If you want a mail client too, several of the well known ones are available as packages. A simple pkg_add thunderbird will add one of the more popular ones to your set of locally installed software.

If you want to find further packages, the You've Installed It. Now What? Packages! article offers some pointers. If you do not want to install a full ports tree for search purposes only, the openbsd.app website offers a nice clickable interface.

Keeping Up to Date: Keep Running syspatch and pkg_add -u

Keeping an OpenBSD system updated is not difficult. You have already seen syspatch in action for pulling in security or reliability updates.

Over the lifetime of a -stable version of the release (which is what your system turns into after your first syspatch), more updates will inevitably become available, and you (your system administrator) should periodically check for any updates and install them in due course.

One useful way to automate the process is to set a cron job that runs syspatch -c (see the syspatch and crontab man pages) at reasonable intervals and mails the output to somebody relevant.

If you run several systems or even more than one OpenBSD version, you would be well advised to appoint one machine per version to be the syspatch canary in order to keep the noise level in your mailboxes or other alerts channels down to reasonable levels.

For keeping installed packages up to date, the command to use is pkg_add with the -u (update) flag.

The pkg_add command offers several other flags that affect its behavior, but the only ones of any real use in a production (stable) environment are the -v (verbose) and -m (print progress bars) options.

If the messages from pkg_add indicate that one or more services have been updated, make sure to restart those services to ensure that only the updated binaries are loaded and running.

At this point, you should have all the pieces in place for keeping your OpenBSD-stable systems in trim with the latest available fixes. Keep up with updates, and you should be OK for the supported lifetime of the code.

Jumping to the Next Release with sysupgrade

All good things come to an end eventually, and when a new release is available, or at the latest, when your present operating system is coming close to end of its supported life, it becomes necessary to upgrade to the next, newer release.

Fortunately, recent OpenBSD versions (since OpenBSD 6.6, in fact - released November 17th 2019), offers a command that offer a smooth upgrade for the most likely scenarios, called sysupgrade.

The sysupgrade command is designed to handle the somewhat complex upgrade process (see the earlier article Keeping Your OpenBSD System In Trim: A Works For Me Guide for some background -- also available tracked and prettified) with minimal user interaction.

The command is designed on the premise that the system to be upgraded is very close to a default install -- if you keep yourself with custom kernels or left out any of the default install sets during install, you are not part of the target audience, and you will be better served by the article referenced in the previous paragraph.

Before proceeding to upgrading to a new release, it is advisable to read the release notes for the new release to identify any changes that may require extra attention. Fortunately, the occasions when manual intervention is strictly needed are rare between releases.

When a new release is available, you upgrade to the next release (numbered by increments of 0.1 per convention) by running

$ doas sysupgrade

The command fetches the install sets for the new release, reboots into the installer, runs sysmerge to perform any needed updates to configuration files and reboots into the upgraded system.

If the sysmerge pass detects any changes that are beyond its automated capability, it will issue a warning that a manual sysmerge is needed. In most cases this will not be needed, however.

When you have the base system upgraded, you will likely want to upgrade to newer versions of any installed packages as well. The command needed is the same as the one you used previously to pull in packages with updates for any identified issues:

$ doas pkg_add -u

When upgrading packages after a system upgrade it is worth paying attention to any package messages and to check for any updates to the package readmes in the /usr/local/share/doc/pkg-readmes/ directory.

Once you have started upgrading packages (if not earlier) you will want to explore other package tools. Try apropos pkg for pointers on where to start exploring.

If you run into any problems, the support channels mentioned earlier in this piece will offer help in response to any reasonably formulated problem reports.

Ready For -current? The Same Tools, Used Slightly Differently

When you have been running OpenBSD stable versions for a while, you may be tempted to explore a bit further, and perhaps even be involved in developing the systems or packages or testing any new features or changes that will become available in upcoming releases.

This is when you may want to explore OpenBSD-current. The way in is to install a snapshot (from the snapshots directory on your favorite mirror). Just how to proceed is really up to you, but if you jump to running -current, you will probably make your life easier in debugging and development contexts if you keep fresh cvs checkout of the src and xenocara source trees as well as the ports tree.

Once you are running a snapshot, the maintenance and upgrade procedure changes slightly. As mentioned, it is advisable to keep sources and ports up to date (start with reading the Building the System from Source part of the FAQ).

For -current or snapshots, syspatch is not really relevant anymore. Instead you run the sysupgrade command with the -s flag:

$ doas sysupgrade -s

The command runs much like it would for -stable versions, but with a slightly elevated risk of needing to run a manually supervised sysmerge after booting into the upgraded system.

New snapshots are generally accompanied (or followed soon after) by updated packages, and runnining pkg_add -u after a successful sysupgrade -s generally makes sense.

Some of the debugging related pkg_add flags make more sense in a snapshot environment.

It is worth noting that for the brief period when -current reports a release equivalent version string (one without -current or -beta suffix) it is necessary to add the -D snap to the pkg_add arguments is necessary in order update packages.

If you intend to contribute in any way, including testing, it is essentially required that you read the tech@ and bugs@ mailing lists and familiarize yourself with how to interact on those forums before posting.

The Way Forward

Hopefully this piece will clear up any confusion caused by me reposting recently the two pieces Keeping Your OpenBSD System In Trim: A Works For Me Guide for some background -- also available tracked and prettified and You've Installed It. Now What? Packages!, also available prettified and tracked here), which by now are more than a decade old.

The pieces still contain mostly correct reference information, but informed readers will notice that they predate the introduction of syspatch and the availability of updated packages for -stable available via pkg_add -u.

Please keep in mind that our favorite operating system OpenBSD is in constant and rapid developement, and that anything written about that system could be quite out of date even a few years from now. I hope to revisit this and other pieces to keep them reasonably in line with evolving realities. I welcome your comments and corrections via email or other channels such as whatever social medium brought you the link to this article.

Resources For Further Reading

The OpenBSD FAQ

Michael W Lucas: Absolute OpenBSD, 2nd edition

Ted Unangst: doas Mastery

OpenBSD Journal News items about OpenBSD, generally short with references to material elsewhere.

Peter Hansteen: What every IT person needs to know about OpenBSD Part 1: How it all started,
What every IT person needs to know about OpenBSD Part 2: Why use OpenBSD?,
What every IT person needs to know about OpenBSD Part 3: That packet filter
(or the whole shebang in the raw here or with trackers at bsdly.blogspot.com)

Network Management with the OpenBSD Packet Filter toolset, by Peter N. M. Hansteen, Massimiliano Stucchi and Tom Smyth (A PF tutorial, this is the BSDCan 2024 edition). An earlier, even more extensive set of slides can be found in the 2016-vintage PF tutorial.

That Grumpy BSD Guy Blog posts by Peter N. M. Hansteen (prettified, tracked). New entries as well as still-relevant pieces that started out over there and have warranted updating will also be findable, untracked other than my webserver log, at https://nxdomain.no/~peter/blogposts/. Please let me know if there are pieces you think would warrant liberation to that space.

Fun Facts About the April 2024 Cisco Attack Data

A commendable attack data dump, lightly analyzed.

In the morning hours (CEST) of April 17, 2024, I found in my social media stream a reference to an Ars Technica article titled UNDER SIEGE — Attackers are pummeling networks around the world with millions of login attempts.

NOTE: A version without trackers but “classical” formatting is available here.

Articles about recent or ongoing attacks are not uncommon, but this time I was delighted to see that the report included a link to the actual data, provided by Cisco subsidiary Talos Intelligence.

When I downloaded the data approximately 09:15 CEST, the data consisted of

5243 unique IP addresses
2105 unique user names
71 unique passwords

I was initially a bit annoyed that the each group of data had apparently not been sorted, so I was a bit worried about possible duplicate entries, but closer inspection showed that I had not needed to worry.

Returning readers will be aware that at nxdomain.no (aka bsdly.net) we have been collecting data on attacks and attackers for some time already, as described in Badness, Enumerated by Robots (also available with nicer formatting but with trackers here) and various material linked from that article.

So naturally my impulse was to see whether there was any overlap between the data Cisco provided and the data collected here.

A few quick rounds for sorting and diffing (or very close equivalents), the results were clear:

of the 5243 unique IP addresses, none were in the currently trapped ssh bruteforcers set or the historical pop3 gropers set.
of the 2105 unique user names, a total of 1595 were not already included in the existing spamtraps list

of the 71 unique passwords, 34 or almost half of the total were not already in the spamtraps list.

If the last item made you chuckle, I am not surprised. But I have also observed at various times that bot herders (or possibly bot feeders) have managed to feed the data the wrong way around to their charges.

The biggest surprise here is that there was no overlap in hosts participating in the campaign against the Cisco customers and hosts that had participated in password guessing against my (for all practical purposes) honeypot system.

One possible explanation could be that the attackers here were targeting only specific products, possibly based on previous intelligence gathering. An alternative explanation could be that they were specifically avoiding certain hosts, such as those running the rather security oriented operating system OpenBSD that we use at this site.

The overlap in user names and passwords mistakenly used as user names with previously collected data here is less surprising.

After this very lightweight analysis, I went to the next logical step and added the offending IP addresses to the bruteforcers list and appended a @bsdly.net suffix to the user names and passwords, and added them to the spamtraps list.

I would like to thank Cisco-Talos for sharing the data on this incident freely.

If you found this article useful, interesting or even annoying, I would like to hear from you.

Good night and good luck.

---

NOTE: If you follow the references in the various other articles, please keep in mind that the command examples there were written from an OpenBSD perspective. Details of command syntax may be different from the implementations on other Unixlikes.

Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End)

Peter N. M. Hansteen

Making life harder for spammers does not necessarily require a lot of effort, if done correctly. Here are a few suggestions for how to use your spamd(8) on an OpenBSD or FreeBSD system that require minimal input but can yield noticeable gains.

Doing your bit to protect your own users and others agains scams, phising or other undesirable mail activity is good netizenship, but unfortunately there is a tendency to think that contributing in any way takes a lot of effort in addition to deep insight into all matters technical and social.

This piece is intended to give you, an aspiring or experienced OpenBSD or FreeBSD user who do not necessarily run a mail service yourself, a taste of some of the options available to you even if you do not want to expend too much effort.

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

If your system runs OpenBSD, you only need to enable spamd (overriding the NO defaults from /etc/rc.conf) by adding the following lines to your /etc/rc.conf.local:

spamd_flags=""
spamdlogd_flags=""


And adding the required lines to your pf.conf, cut-and-pasteable from the man page before reloading your ruleset. You may want to look into filling in actual flags later if your setup requires it.

If your system runs FreeBSD, you need to enable PF, install the spamd package, then run through the steps outlined in the package message which is displayed at the end of the package installation.

With those preliminaries out of the way, we can go on to the specifics of each of the low effort scenarios.

Classic imported blacklist-only

When spamd(8) was first introduced, it did only one thing: slow down incoming SMTP traffic from known bad sources. The known bad addresses were the ones fetched from address lists generated locally or elsewhere, as specified in spamd.conf.

The pure blacklisting mode is still available. If you have one or more sources of blocklists that you consider reliable, you can use those. To enable this mode on OpenBSD, add the line

spamd_black=YES

to /etc/rc.conf.local or add the -b flag to any options in the spamd_flags= variable, edit in any lists to fetch in your spamd.conf, restart spamd and add a crontab entry to run spamd-setup at reasonable intervals.

On FreeBSD, the procedure is basically the same, but adding the -b flag to the spamd_flags= variable is the only way to enable the feature.

Once you have the -b mode enabled, any SMTP traffic from the known bad hosts will be stuttered at -- answers arriving at a rate of one byte per second until they give up, and spamd-setup will refresh your lists at the intervals you have specified.

You can then sit back and enjoy the feeling of getting to waste spammers' (or at least spambots') time.

Checking your system logs for spamd log entries occasionally will likely lead to giggles.

Classic greylisting without imported lists

The original version of spamd(8) did not know how to do greylisting, but since the version that shipped with OpenBSD 4.1, greylisting mode is the default mode.

If you simply enable spamd without touching any other options, you will have greylisting enabled.

This means that any SMTP traffic from hosts that have not previously contacted your spamd will be stuttered at (one byte at the time, remember) for ten seconds at first.

If they come back within a reasonable time, they will be added to the allowable list. If you have a real mail server in the back somewhere, the traffic will eventually be let through.

Once set up, this mode is also extremely low maintenance.

After a while, your system logs may offer some occasional entertainment.

Allowed domains only

If you're still reading this article, you more likely than not have at least heard about the greytrapping concept. I have written about the concept and practice at length (see the reading materials at the end), and it is one of the topics that I sense is generally perceived as being complicated and labor intensive.

I am here to tell you that there is in fact an easy, low maintenance way in to greytrapping, by making allowed domains be the only criterion for trapping and blocking. This is the method I described in more detail in the previous article A Simpler Life: Trapping Spambots Based on Target Domain Only (or with nicer formatting and Big G's trackers here).

Simply put, if you are running your spamd in the default greylisting mode, with or without imported blocklists, you can tiptoe into greytrapping by adding the domains you want to receive mail for to your spamd.alloweddomains file. If you want to disallow subdomains of otherwise wanted domains, you add an entry with the otherwise wanted domain with an @ at sign prepended.

Make the configuration changes specified in the article. Do read the man pages and other relevant references, the article has quite a few links.

Once you have input the wanted domains in your spamd.alloweddomains file and reloaded your spamd service, any attempt at delivery to any domain that is not specificed in your configuration will lead to blocklisting and subsquent stuttering until the sender gives up.

With this minimal trapping configuration in place, your logs will soon offer some excellent entertainment. Such as this, which demonstrates that I do not own that domain and do not want to receive or relay mail from elsewhere to it:

Jan 25 16:29:14 skapet spamd[84681]: (GREY) 185.196.10.236: <htg@dataped.no> -> <captainjohnwhite3@gmail.com>
Jan 25 16:29:14 skapet spamd[4259]: Trapping 185.196.10.236 for tuple 185.196.10.236 tTzhEgT <htg@dataped.no> <captainjohnwhite3@gmail.com>
Jan 25 16:29:14 skapet spamd[4259]: new greytrap entry 185.196.10.236 from <htg@dataped.no> to <captainjohnwhite3@gmail.com>, helo tTzhEgT


Bonus tracks: The MX-less merry prankster, and more

All of the things mentioned here will work equally well each on their own or in combination, and those things will, should you choose to go on to set up a mail service, ease the load considerably on the parts of your setup that does the heavier duty computing involved in mail delivery, the content filtering, either for match against known bad code (aka antivirus or antimalware) patterns or text patterns known to be part of scammy spam.

But one fun fact that one of my correspondents pointed out to me some years back is that you can run a spamd service with no real mail service available.

This correspondent reported that sure, they had an OpenBSD machine in an internet facing position, but did not run a mail service.

They set up a combination of the methods outlined earlier, but their mail was handled elsewhere. Anything that finally cleared the barriers of their spamd config would have nowhere to go.

The fact that they did not run an actual mail service did not stop spam senders for trying, and the setup proved ideal for testing how well spamd(8)'s -S and -s options worked.

Please check out the man page to see what they do.

And yes, the effect of -s seemed to be quite linear according to my correspondent's data.

If you want to go further, here is some reading material for you

I hope you find the previous entries informative and possibly even useful.

As you have seen, you can contribute to spam protection efforts even if you do not run an actual mail service. If any of the things suggested earlier suit your needs, enjoy!

However, if you are entertaining the idea of running your own mail service, I have some further reading that I suggest and recommend you spend some time digesting.

First, if you want to run a mail service, do yourself a favor and not only read the relevant man pages, but also sign up for the mailop mailing list, read the Mailop FAQ and the Best Practices for Servers document.

Please also do yourself the favor or lurking, or listening in a bit to get some idea of what kind of discussions are expected there, before posting yourself. Also, familiarize yourself with the mailing list archives. Your question may very well have been answered extensively and well in the past.

If you want to dig deeper in matters related to spam, greytrapping and the OpenBSD spamd(8) program in general, here are a few resources for you:

In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes (also with trackers)

Badness, enumerated by robots (also with trackers)

Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also with trackers)

Maintaining A Publicly Available Blacklist (tracked only, sorry)

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (also tracked only, sorry)

The Book of PF, 3rd edition (now again available as physical copies).

---

Thanks to Michael Lucas, who wrote a message on the mailop mailing list that spurred me to write both this article and the previous A Simpler Life: Trapping Spambots Based on Target Domain Only (or with nicer formatting and Big G's trackers here).

A Simpler Life: Trapping Spambots Based on Target Domain Only

If you want to hurt spammers, you can get away with maintaining a list of domains you want to receive mail for in your spamd.alloweddomains.

I have at times written at length about spam countermeasures, and I must take responsibility for sometimes going into too much detail about options and nuances that are on offer if you enjoy fighting back at the spammers and watching them fail.

So it was a bit refreshing to be reminded that you can, in fact, make good use of the OpenBSD spam deferral daemon spamd(8) without maintaining lengthy lists of anything or even pulling in externally generated data, unless you want to.

The key to the simplest version of spam fightng life with spamd(8) is to put a list of the domains you do want to receive mail for in a file called spamd.alloweddomains, in /etc/mail/ if your system runs OpenBSD, and in /usr/local/etc/spamd/ if you are setting up on a FreeBSD system. Make sure the file is readable for the user that runs the spamd(8) process, and restart or reload your spamd.

The result will be that any host that tries to deliver mail to addresses that are not listed in spamd.alloweddomains will be greytrapped and added to your spamd-greytrap. The host will be stuttered at until it gives up.

If you have no use for external blocklists or allowlists, you can even empty spamd.conf if you want (or comment out any content with # hash characters). The spamd process will run fine without one.

Here is an example lifted from my nxdomain.no server recently:

Jan 23 15:18:27 skapet spamd[84681]: (GREY) 193.222.96.180: <test@bsdly.net> -> <director_ericmoore@hotmail.com>
Jan 23 15:18:27 skapet spamd[4259]: Trapping 193.222.96.180 for tuple 193.222.96.180 win-4tti4dh7sgh.domain <test@bsdly.net> <director_ericmoore@hotmail.com>
Jan 23 15:18:27 skapet spamd[4259]: new greytrap entry 193.222.96.180 from &kt;test@bsdly.net>M to <director_ericmoore@hotmail.com>, helo win-4tti4dh7sgh.domain

Needless to say I am not Microsoft, so hotmail.com is not in nxdomain.no's /etc/mail/spamd.alloweddomains.

If you want to pull in external blocklists or pass lists, you can pull in a spamd.conf with content. One useful starting point is the default version, or if you want you can stat with mine, which pulls in some other resources.

Finally, if you want to run a mail service, do yourself a favor and not only read the relevant man pages, but also sign up for the mailop mailing list, read the Mailop FAQ and the Best Services for Servers document.

Thanks to Michael Lucas, who wrote a message on the mailop mailing list that spurred me to write this article.

---

If you want to dig deeper in matters related to spam, greytrapping and the OpenBSD spamd(8) program in general, here are a few resources for you:

In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes (also with trackers)

Badness, enumerated by robots (also with trackers)

Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also with trackers)

Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End) (also with trackers

Maintaining A Publicly Available Blacklist (tracked only, sorry)

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (also tracked only, sorry)

The Book of PF, 3rd edition (now again available as physical copies)

I asked ChatGPT to write a pf.conf to spec, 2023-06-07 version

ChatGPT prompt and answer

Prompted by this exchange

I just had to check what its capabilities were. Here is what happened:

Note: A version without trackers but “classical” formatting is available here.

---

PNMH::
write an OpenBSD pf.conf that blocks by default, allows traffic from the local host, allows name resolution, network time and ssh out from the DMZ, lets http and https through to the web server, and allows smtp that has been whitelisted by spamd to pass to the mail server.

To which ChatGPT answered:

Sure! Here's an example of an OpenBSD pf.conf configuration file that meets your requirements:

# Define network interfaces
ext_if = "em0"  # External interface (connected to the internet)
dmz_if = "em1"  # DMZ interface
lan_if = "em2"  # Local LAN interface

# Set default block policy
block all

# Allow traffic from the local host
pass quick on lo0 all

# Allow name resolution (DNS)
pass out on $ext_if inet proto udp to any port domain

# Allow network time (NTP)
pass out on $ext_if inet proto udp to any port ntp

# Allow SSH out from the DMZ
pass out on $dmz_if inet proto tcp to any port ssh

# Allow HTTP and HTTPS traffic to the web server
pass in on $ext_if inet proto tcp to $ext_if port { http, https }

# Allow SMTP traffic that has been whitelisted by spamd to the mail server
pass in on $ext_if inet proto tcp to $ext_if port smtp \
    rdr-to $lan_if port spamd

# Log and block any remaining traffic
block log all

    

Make sure to replace the interface names (em0, em1, em2) with the appropriate interface names on your OpenBSD system. Additionally, adjust the names of the web server and mail server as needed.

Remember to save the pf.conf file in the correct location (/etc/pf.conf by default on OpenBSD) and reload the firewall rules using the pfctl command for the changes to take effect.

Note: This configuration assumes you have already set up spamd and whitelisted the desired SMTP traffic.

---

I will leave it as an excercise to the reader to point out why this would earn an F.

Or you can take in things like our Network mananagement with the OpenBSD Packet Filter Toolset or just get yourself a copy of The Book of PF , as an option after after looking up the PF user guide.

Update: Point it at specific sources! After posting the original result I got a few responses, with lots of smileys and other emojis.

Then, a colleague advised that pointing the system at specific sources such as the man pages would likely produce better results.

So here is the second exchange:

PNMH:
based on the information in https://man.openbsd.org/pf.conf and https://man.openbsd.org/spamd write an OpenBSD pf.conf that blocks by default, allows traffic from the local host, allows name resolution, network time and ssh out from the DMZ, lets http and https through to the web server, and allows smtp that has been whitelisted by spamd to pass to the mail server.

The response was,

Certainly! Here's an updated version of the pf.conf configuration file based on the information from the OpenBSD man pages for pf.conf and spamd:

# Define macros for network interfaces and IP addresses
ext_if = "em0"  # External interface (connected to the internet)
dmz_if = "em1"  # DMZ interface
lan_if = "em2"  # Local LAN interface

# Set default block policy
block all

# Allow traffic from the local host
pass quick on lo0 all

# Allow name resolution (DNS)
pass out on $ext_if inet proto udp to any port domain

# Allow network time (NTP)
pass out on $ext_if inet proto udp to any port ntp

# Allow SSH out from the DMZ
pass out on $dmz_if inet proto tcp to any port ssh

# Allow HTTP and HTTPS traffic to the web server
pass in on $ext_if inet proto tcp to $ext_if port { http, https }

# Allow SMTP traffic that has been whitelisted by spamd to the mail server
table  persist file "/etc/spamd.whitelist"
pass in on $ext_if inet proto tcp to $ext_if port smtp \
    rdr-to $lan_if port spamd if-bound \
    spammed by 

# Log and block any remaining traffic
block log all

In this version, we have added the table, which is populated by the /etc/spamd.whitelist file. This file should contain the IP addresses or networks that have been whitelisted by spamd. Make sure to save the pf.conf file in the correct location (/etc/pf.conf by default on OpenBSD) and reload the firewall rules using the pfctl command for the changes to take effect. Please note that this configuration assumes you have correctly set up spamd and have populated the /etc/spamd.whitelist file with the desired IP addresses or networks.

---

It did pick up a few clues from the man pages I fed it, but it still has fairly obvious flaws that would stem from it not being able to take in the actual interdependencies of even a very clearly worded, if slightly complex document like man pf.conf.

But then what would happen if we in addition feed it the PF user guide?

Let's try:

PNMH:
based on the information in https://www.openbsd.org/faq/pf/index.html and links therein as well as https://man.openbsd.org/pf.conf and https://man.openbsd.org/spamd write an OpenBSD pf.conf that blocks by default, allows traffic from the local host, allows name resolution, network time and ssh out from the DMZ, lets http and https through to the web server, and allows smtp that has been whitelisted by spamd to pass to the mail server.

The third try response was,

Certainly! Here's an updated version of the pf.conf configuration file based on the OpenBSD FAQ for pf, as well as the pf.conf and spamd man pages:

# Define macros for network interfaces and IP addresses
ext_if = "em0"  # External interface (connected to the internet)
dmz_if = "em1"  # DMZ interface
lan_if = "em2"  # Local LAN interface

# Set default block policy
block all

# Allow traffic from the local host
pass quick on lo0 all

# Allow name resolution (DNS)
pass out on $ext_if inet proto { udp, tcp } to any port domain

# Allow network time (NTP)
pass out on $ext_if inet proto udp to any port ntp

# Allow SSH out from the DMZ
pass out on $dmz_if inet proto tcp to any port ssh

# Allow HTTP and HTTPS traffic to the web server
pass in on $ext_if inet proto { tcp, udp } to $ext_if port { http, https }

# Allow SMTP traffic that has been whitelisted by spamd to the mail server
table  persist file "/etc/spamd.whitelist"
pass in on $ext_if inet proto tcp to $ext_if port smtp \
    rdr-to $lan_if port spamd if-bound \
    spammed by 

# Log and block any remaining traffic
block log all
    

In this version, the rules have been updated to align with the OpenBSD pf FAQ and provide a more comprehensive configuration. Make sure to save the pf.conf file in the correct location (/etc/pf.conf by default on OpenBSD) and reload the firewall rules using the pfctl command for the changes to take effect. Please note that this configuration assumes you have correctly set up spamd and have populated the /etc/spamd.whitelist file with the desired IP addresses or networks.

---

It is fairly obvious that this would not have passed the pfctl parser, and that feeding it the relevant man pages as well as the PF user guide did not make the system more capable of understanding how rule evaluation actually works.

In fact, all three tries would be functionally equivalent to the rather terser

block

But arriving at that conclusion would require the reader to actually understand the content fed to it.

---

My favorite take on this so far came via Mastodon, from Mark Shane Hayden, in this toot, which reads in full:

@mwl @pitrh I suppose we can take solace in that if Skynet ever came into existence for real it would be unreachable

ChatGPT opines on IPv6 procastination, waxes lyrical over OpenBSD

Are the robots indeed capable of helping us in our tech writing, or even help our creativity? This writer tries on the robot that's been in the news for size. OpenBSD material to be had at the end.

For a number of years, those involved in networking things have all had one thing in common: A TODO item about either getting started implementing IPv6 in their networks, or at least getting started on planning to go dual-stack or even purely IPv6.

And as anybody who follows networking things is aware, IPv6 adoption in some parts of the world has been advancing hardly at all, even in jurisdictions where actual legislation is in place that mandates IPv6 use and leaves IPv4 support as an allowable option.

I have been involved in some capacity or other in enough of these efforts over the years that I have been pondering writing a piece about the slow rate of adoption, and of course I hoped to be able to write something witty or at least entertaining about something that is in fact, to some of us at least, a somewhat frustrating situation.

Then today I attended an internal presentation by a colleague that included some examples of ChatGPT use writing as well as programming.

The demonstration was enough fun that I thought I would see if the robot could offer some insights and perhaps get me started on writing the piece I had been pondering.

Signing up and getting access to a trial was painless and quick, so some things have improved since I first tried to access the service a few weeks ago when news about the service first hit.

First try: Please write me a story

The first chat went like this:

PNMH: managers and admins put off setting up IPv6 in their networks. write a short story on how and why they procrastinate and make excuses.

ChatGPT: Once upon a time, in a large corporation, there was a group of managers and administrators responsible for the network infrastructure. They had heard about IPv6, the new internet protocol, and knew that it was important to adopt it to future-proof the company's network. However, they kept putting off the task of implementing IPv6, and s why:

Firstly, they felt overwhelmed by the complexity of IPv6. They were used to IPv4, and the thought of transitioning to a new protocol seemed daunting. They convinced themselves that they needed more time to research and plan the transition thoroughly.

Secondly, they thought that their current IPv4 infrastructure was sufficient, and that there was no need to change anything. They believed that IPv6 adoption was only necessary for larger companies and service providers, not for their organization.

Thirdly, they were concerned about the cost of implementing IPv6. They felt that it would require a significant investment in new hardware, software, and training, and they were not sure if the benefits of IPv6 would justify the expense.

Finally, they were preoccupied with other pressing matters, such as meeting deadlines, managing budgets, and dealing with daily operational issues. IPv6 implementation was not a top priority for them, and they kept pushing it back on their to-do lists.

As time went by, the managers and administrators continued to procrastinate, making excuses and justifications for not implementing IPv6. They were oblivious to the fact that their competitors were already using IPv6 and gaining a competitive edge. They failed to realize that IPv6 adoption was not a choice but a necessity for staying relevant and competitive in the digital age.

In the end, the managers and administrators were forced to implement IPv6 when their IPv4 addresses ran out, causing network disruptions and downtime. They learned the hard way that procrastination and excuses only lead to costly delays and missed opportunities.

Also accesssible as pure text as chatgpt_on_ipv6_procrastination.txt

As one of my mastodon commenters said, it looks like this robot has peeked into too many IT Management meetings.

I would myself have been more worried about ensuring that services we run are accessible to IPv6-only networks, and for that matter that users in our own networks should be able to access services in IPv6-only parts of the Internet.

This shows that whatever they trained the system on seems to have included the most frequently cited reasons for not actually moving forward with IPv6 implemenation or other network modernization. But the thing had stylistic issues and I was looking for something fresher. So on to the next try.

Second try: Tease the legal requirements

Some stakeholders, such as Norwegian public sector entities, are under legal obligation to make their services available on IPv6 and to enable clients in their network to access IPv6 resources, the final deadline for that implementation in principle passed at the end of 2022.

So I tried stressing that point in my second try. Here is a record of hat session:

PNMH: why do network designers always postpone their IPv6 implementation even past legally required deadlines?

ChatGPT: There are a few reasons why network designers may postpone their IPv6 implementation, even past legally required deadlines:

Compatibility issues: IPv4 and IPv6 are not directly compatible with each other, which means that devices using IPv4 cannot communicate directly with devices using IPv6. This creates interoperability issues that can make it difficult for organizations to transition to IPv6 without causing disruptions to their existing networks.

Cost: Implementing IPv6 requires an investment in new hardware, software, and training. For some organizations, the cost of upgrading their infrastructure to support IPv6 may be prohibitive, especially if they have already invested heavily in their existing IPv4 infrastructure.

Lack of perceived need: Some organizations may not see the urgency in transitioning to IPv6, especially if they are not experiencing any immediate problems with their IPv4 networks. This can lead to a "wait and see" approach, where organizations postpone their IPv6 implementation until they are forced to do so by external factors.

Complexity: IPv6 is more complex than IPv4, which can make it more difficult for network designers to implement and manage. This complexity can also make it more challenging to troubleshoot network issues that may arise after the transition to IPv6.

Lack of IPv6 support from vendors: Some network hardware and software vendors may not yet fully support IPv6, which can make it difficult for organizations to transition to IPv6 without making significant changes to their existing infrastructure.

Overall, transitioning to IPv6 requires a significant investment of time and resources, and network designers may delay implementation for various reasons. However, as the pool of available IPv4 addresses continues to dwindle, and as more organizations begin to adopt IPv6, it is becoming increasingly important for organizations to make the transition to IPv6 in a timely manner.

Also accesssible as pure text as chatgpt_on_ipv6_procrastination_legal.txt

This was actually an improvement. The reachability point is made clearer here, and the system clearly picked up on the legal requirement part.

Whether IPv6 is in fact more complex than IPv4 is debatable, but the robot is right that this is at least a common perception, factual or otherwise.

A clear improvement, but when I publish something, I make an effort to make it witty or at least a bit snarky.

Time to tweak the query once again.

Third try: Once more, with wit and feeling

My third and final IPv6-themed query of the day ran like this:

PNMH: write a funny story about why IPv6 implementation is so hard and scary to plan for and actually do

ChatGPT: Once upon a time, there was a small company that had been using IPv4 for all their networking needs. One day, their IT manager decided that it was time to upgrade to IPv6.

Excited by the prospect of faster speeds and improved security, the IT manager decided to jump right in and start planning for the implementation of IPv6. However, as they began to research and plan, they soon discovered that implementing IPv6 was not as easy as they had thought.

First, they realized that they would need to upgrade all of their networking equipment to support IPv6. This was going to be expensive, but the IT manager was determined to make it happen. They went ahead and ordered all the necessary equipment and started scheduling the installation.

However, as the installation date approached, the IT manager began to feel a sense of dread. What if the new equipment didn't work with their existing systems? What if they couldn't get everything up and running in time?

Feeling overwhelmed, the IT manager decided to take a break and watch some TV. As luck would have it, they stumbled upon a horror movie about a group of people who get lost in a network of tunnels and are pursued by an army of rogue IPv6 addresses.

Suddenly, the IT manager's fear of implementing IPv6 reached new heights. They couldn't shake the feeling that something was going to go horribly wrong. They started imagining all sorts of terrifying scenarios: their network crashing, their data being compromised, even their computers coming to life and taking over the office!

In the end, the IT manager decided to put the IPv6 implementation on hold indefinitely. They just couldn't bring themselves to take the risk. And so, the small company continued to chug along on IPv4, while their competitors raced ahead with faster, more secure networks.

The moral of the story? Don't let fear hold you back from upgrading to IPv6. Sure, it can be scary and complicated, but with the right planning and support, you can make the transition smoothly and reap the benefits of a faster, more secure network. And who knows, maybe you'll even get a good horror story out of it!

Also accesssible as pure text as chatgpt_on_ipv6_procrastination_funny.txt

Ouch. The Once upon a time lead-in is back. But the rest is something that I might actually manage to editstomptwistcrunch into something presentable given enough coffee and time.

I have had worse material handed to me to edit by humans, and I may have done worse first drafts myself when writing when I should not have.

There are some logic issues in there, but nothing that could not be edited out or around.

By this time of the day, I had to go attend to a few things with deadlines, but I took the time to do a final query on a slightly different topic.

And now for something completely different: Write me OpenBSD poetry

So after looking into a slightly painful topic, what better than to see what our robot friend has learned about our favorite operating system and poetry:

PNMH: write a poem about OpenBSD

ChatGPT: In a world of code and bytes,
Where hackers lurk in endless nights,
There shines a system, strong and bright,
A fortress of security, with OpenBSD in sight.

Like a lighthouse on a stormy shore,
It guards the network from cyber war,
With firewalls, cryptography, and more,
It stands tall, unyielding, forevermore.

In its heart, a philosophy,
Of code that's clean and free,
No backdoors, no secret keys,
Just trust and transparency.

From humble beginnings, it arose,
A gift to the world, from the chosen few,
A beacon of hope, for those who oppose,
The tyranny of those who seek to control.

So let us raise a toast, to OpenBSD,
A shining example of what can be,
When we dare to dream, and we dare to be free,
For a better tomorrow, for you and for me.

Also accesssible as pure text as chatgpt_poem_about_openbsd.txt

I just had to post that to openbsd-misc, and it will be interesting to see how the thread develops. And is a fitting end to what is, I think, the piece I have posted under my own name that contains the least material written by myself.

Good night and good luck.

<