Thursday, January 25, 2024

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.

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).

Wednesday, January 24, 2024

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)

Wednesday, June 7, 2023

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

Friday, March 3, 2023

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.

ChatGPT goes to work on our first task

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.

<

Sunday, December 25, 2022

The Despicable, No Good, Blackmail Campaign Targeting ... Imaginary Friends?

Natalia here speaks to our imaginary friend 185.150.184.92

In which we confront the pundits' assumption that the embarrasment-based extortion attempts would grow more “sophisticated and credible” over time with real data.

It's a problem that should not exist. 

It's a scam that's so obvious it should not work.

Yet we still see a stream of reports about people who have actually gone out and bought their first bitcoins (or more likely fractions of one) in order to pay off blackmailers who claim to have in their possesion videos that record the vicim while performing some autoerotic activity and the material they were supposedly viewing while performing that activity.

And occasionally one of those messages actually find their way to some pundit's inbox (like yours truly), and at times some of those pundits will say things like that those messages represent a real problem and will evolve to be ever more sophisticated.

Note: This piece is also available, with more basic formatting but with no trackers, here.

I am here to tell you that

  1. That incriminating video does not exist, and
  2. The pundits who predicted that those scams would evolve to become more sophisticated were wrong.

If you stumbled on this article because one of those messages reached you, it's safe to not read any further and please do ignore the extortion attempt.

I wrote a piece in 2019 The 'sextortion' Scams: The Numbers Show That What We Have Is A Failure Of Education, also available without trackers, where the summary is,

Every time I see one of those messages reach a mailbox that is actually read by one or more persons, I also see delivery attempts for near identical messages aimed at a subset of my now more than three hundred thousand spamtraps, also known imaginary friends.

Over the years since the piece was originally written, I have added several updates — generally when some of this nonsense reaches a mailbox I read — and while I have seen the messages in several languages, no real development beyond some variations in wording has happened.

Whenever one of those things does reach an inbox, my sequence of actions is generally to save the message and add it to the archive, see if the sending IP address has already entered the blocklist that is later exported and add it by hand if not. Then check if the number of trapped addesses has swelled recently by checking the log file from the export script

$ tail -n 96 /var/log/traplistcounts

See if there is a sharp increase since the last blocklist export

$ doas spamdb | grep -c TRAPPED

Then check for related activity in the log

$ tail -n 500 -f /var/log/spamd

Check for the full subject in the same log file

$ grep "You are in really big troubles therefore, you much better read" /var/log/spamd

Then check older, archived logs to see how long this campaign has been going on for

$ zgrep "You are in really big troubles therefore, you much better read" /var/log/spamd.0.gz

This time, the campaign had not gone on for long enough to show traces in the older archive, so I go on to extracting the sending IP addresses

$ grep "You are in really big troubles therefore, you much better read" /var/log/spamd | awk '{print $6}' | tr -d ':' | sort -u

Check for activity from one of the extracted addresses

$ grep 183.111.115.4 /var/log/spamd | tee wankstortion/20221123_trapped_183.111.115.4.txt

Extract the sender IP addresses to an environment variable to use in the next oneliner,

$ grep trouble /var/log/spamd | awk '{print $6}' | tr -d ':' | sort -u | grep -vc BLACK | tee -a wankstortion/20221123_campaign_ip_addresses.txt

which will record all activity involving those IP addresses since the last log rotation:

$ for foo in $troubles ; do grep $foo /var/log/spamd | tee -a wankstortion/20221123_campaign_log_extract.txt ; done

You will find all those files, along with some earlier samples, and by the time you read this, possibly even newer samples, in the archive.

When something of the sort inboxes, I probably will go on adding to the archive, and if I have time on my hands, also run similar extraction activities as the ones I just described. But unless something unexpected such as actual development in the senders' methods occurs, I will not bother to write about it.

The subject is simply not worth attention past persuading supposed victims to not bother to get bitcoins or spend any they might have to hand. None of my imaginary friends have, and they are just as fine as they were before somebot tried to scam them.

Good night and good luck.


 

Friday, December 23, 2022

Can Your Spam-eater Manage to Catch Seventy-one Percent Like This Other Service?

Measuring the effect of what you do is important. Equally important is knowing what is the measure of your actions.

A question turned up on IRC that had me thinking.

Do you have a percentage of the spam traffic you catch on your MXes? The reason I ask is I lust learned that fastmail.com claim they catch 71% of all incoming spam. Also a rate of false positives would be nice to have, but that's likely harder to measure.

My first impulse was that I would consider a seventy-one percent hit rate on the low side of what we are seeing here at bsdly.net and associated domains.

But getting actually useful data would require some thinking. That said, comparing a major mail operator that sells deliverability and promises a 71 percent catch rate for incoming spam and bsdly.net would be like comparing apples and oranges at best. 

While bsdly.net (which is also known under a few other domain names) is my main mail service for my personal use and for a very select number of other people, to the rest of the world it is primarily a honeypot that generates security relevant data that other sites use, and that contributes to IP reputation rankings.

The site has been in operation in those roles for a little more than 15 years, since shortly before the original announcement in the article Hey, spammer! Here's a list for you!. When we started using the greylisting and greytrapping based setup, we saw a sharp drop in undesirable messages actually reaching inboxes, and I observed a marked decrease in load on the mail servers that did the content filtering.

Not long after I had set up our early greylisting setup, a message turned up on the openbsd-misc mailing list that pretty much matched our experience — a 95% reduction in spam in line to be treated to content filtering — so setting up precise measuring became a thing to do when we could get around to it.

Now enough with the background. It is relatively easy to extract at least some data that would give us a rough picture of the relative effectiveness of the greylisting and greytrapping versus the content filtering on receipt. The setup is very similar to the one described in the practically-oriented parts of the Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools and is part of a syncronizing multi-domain setup rougly as described in the earlier article In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes In Play - A Full Recipe.

Using only tools found in the OpenBSD base system, I went on to collect data.

Whenever spamd(8) closes a connection it logs a message to that effect, so

$ zgrep "Nov  1" /var/log/spamd.6.gz | grep -c disconnected

Supplies the total number of connections closed by spamd(8) during November 1st, fetched from the archived log file.

Similarily

$ zgrep "Nov  1" /var/log/spamd.6.gz | grep -c BLACK

provides the number of connections during the same 24 hour period initiated by hosts that were already in one of the blocklists used.

The command to get the number of connections that had cleared the first hurdle and entered greylisted status would be

$ zgrep "Nov  1" /var/log/spamd.6.gz | grep -c GREY

And the number of hosts that had been well behaved enough to enter the whitelist and be allowed to talk to the real SMTP service comes out of

$ zgrep "Nov  1" /var/log/spamd.6.gz | grep -c whitelisting

For hosts that have reached this far and did not fail the content filtering we do during receipt, we get the number with

$ doas zgrep 2022-11-02 /var/spool/exim/logs/main.log.6.gz | grep -c Completed

It is however worth noting that our MTA exim reports Completed for apparently message deliveries in both directions, so the number of received messages, or messages that did inbox is likely about thirty percent lower.

The number of messages rejected for one reason or the other, by being addressed to an undeliverable address or by failing content filtering we find with

$ doas zgrep 2022-11-02 /var/spool/exim/logs/main.log.6.gz | grep -c rejected

And finally, a side effect of a frequently run log reading script that adds hosts with certain kinds of characteristics such as not having a correct reverse DNS entry to a blocklist and kills all their connections will at times produce an unexpected disconnection while reading SMTP command message. We find those with

$ doas zgrep 2022-11-02 /var/spool/exim/logs/main.log.6.gz | grep -c unexpected

Those are hosts that somehow got past spamd(8) by behaving enough like a real SMTP server to clear greylisting. However spamd(8) does not have the ability to check for valid reverse, so that part is left in our case to check for by reading the log files at intervals.

The following table has the data for November 2022 —

Date Incoming SMTP
connections
BLACK
connections
GREY
connections
New whitelist
entries
Deliveries Rejected Unexpected
disconnect
2022-11-01 53303 38951 2580 54 1347 409 384
2022-11-02 55653 40467 2174 121 1297 549 330
2022-11-03 59658 43901 2086 85 1260 865 759
2022-11-04 57462 45674 1683 71 1270 30 0
2022-11-05 44993 43571 2146 105 1182 43 0
2022-11-06 36768 37802 2322 86 1366 184 0
2022-11-07 49464 44213 2398 182 1424 67 0
2022-11-08 52285 45904 2676 113 1513 69 3
2022-11-09 47652 47988 2085 105 1438 154 0
2022-11-10 57850 49875 2614 104 1435 192 2
2022-11-11 60269 56719 2355 99 1420 90 1
2022-11-12 46139 54073 1160 96 1182 29 0
2022-11-13 40497 40221 1777 70 1239 189 0
2022-11-14 59965 59951 2062 63 1382 145 73
2022-11-15 56265 32727 2304 113 1298 351 301
2022-11-16 77252 58029 1925 109 1340 282 33
2022-11-17 43107 30713 786 131 1250 215 17
2022-11-18 49448 48999 1590 96 1327 194 1
2022-11-19 42413 45927 973 92 1182 182 70
2022-11-20 50890 55318 1558 77 1203 358 33
2022-11-21 36601 35070 1707 125 1321 241 146
2022-11-22 37840 35499 2055 99 1359 142 17
2022-11-23 43186 34545 1314 114 1345 103 21
2022-11-24 46802 45765 1856 66 1269 729 52
2022-11-25 70911 52404 1315 89 1326 1488 395
2022-11-26 39780 32226 1500 77 1175 954 379
2022-11-27 67578 41581 1743 85 1231 523 315
2022-11-28 54688 37534 2433 77 1337 321 269
2022-11-29 70893 45917 2502 65 1248 87 39
2022-11-30 50280 35585 2567 67 1324 1293 1113

The table is also available as a comma separated (CSV) file.

As I mentioned earlier, the number of connections to the outer layer spamd(8) is likely higher than what would be expected on sites that are not considered a honeypot and home to in excess of three hundred thousand imaginary friends (see The Things Spammers Believe - A Tale of 300,000 Imaginary Friends or the trackerless version.

That said, I think the data shows that catching the unwanted traffic early, and discarding as much as possible of that traffic before it reaches the resource hungry content filtering is definitely beneficial. 

Even sites that do not actively bait the baddies out there would likely see noticeable energy bill savings by having their mail servers run quiter and cooler, as they definitely will after getting a greylisting, and optionally greytrapping setup in front of them. Those services have a truly low energy consumption profile.

If you found this article interesting, useful or just simply irritating, I would like to hear from you. Please use the comment field, or if you prefer, send email to nix at nxdomain dot no with a subject that at least tries to sound sensible and relevant.

As always, if you are interested in research on items mentioned in this article, I will be able to provide data for study. I will honor reasonable requests.


Friday, December 9, 2022

Harvesting the Noise While it's Fresh, Revisited

A year's worth of logs yields entertaining but unsurprising findings about spammer behavior.
Spam mail, masked but detected, from the archive

Returning readers will be almost painfully aware that here at nxdomain.no (also known as bsdly.net) we host and maintain a blocklist, which in turn is the product of traffic that hits our mail system with attempts at delivery to one or more of the now more than three hundred thousand known bad addresses, also featured at the blocklist home page.

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

When I first set up the greytrapping back in 2007, the initial spamtraps were non-deliverable addresses in our domains that I had extracted from mail server logs. I won't bore you with the details (which are anyway documented at length in earlier articles), but it was clear from those logs that the domains we hosted back then were more or less continously subject to Joe jobs, as in somebody sending messages with a forged From: field with a made up address in our domains.

After a while I started extracting the potential new spamtraps from the greylist — actually dumping data from there once per hour as part of the script that also generated the exported blocklist. The basic process is described in the July 25 2007 article Harvesting the noise while it's still fresh; SPF found potentially useful (also available trackerless but with links to tracked articles).

Then today it struck me that while that method is useful, by extracting only from the greylist we will only ever collect the address from the initial connections. Any addresses attempted after the miscreants enter the blocklist will simply not be recorded there.

This of course lead to the question: What did we miss?

Fortunately I keep my logs around for a while, the most easily accessible log archive for my main spamd spans a lttle over a year. So I set about with some very basic grep and awk, which netted me this raw list of targeted addresses from the spamd logs.

The list weighs in at a total of 269903 entries, as counted by wc -l.

Some of those addresses are valid, and a small, but actually significant, number are in domains we do not actually serve here, and some entries do not look like mail addresses at all. The stranger ones could be strings encoded in a character set that spamd is not equipped to handle, or could be other binary data that might have been intended to trigger bugs in some of the variants of fully equipped SMTP servers that are out there. Or simply noise of any other kind, including a byproduct of the not very intelligent extraction one-liner I used.

The target addresses in foreign domains I take as a sign that at least some spamming operators mistake a reasonably configured spamd for an open relay, just like they did all those years ago when I started running the greytrapping.

Some things apparently stay the same no matter how the rest of the world has found a way to move forward.

While I did a few other tasks and finally started writing this article, the bulk of the processes that would answer the question posed earlier (What did we miss?) could fortunately run unattended in the background, and after some manual massaging we are left with a results file, with 1530 entries that were none of

  • actually useful deliverable addresses in our domains
  • existing spamtraps

This means of course that the collection of imaginary friends expanded by the same number, and now stands at 304154 entries.

Which I suppose means that harvesting the noise even after a period of aging for refinement can be a good thing.

The entries added represent a wide variety of phenomena. Quite a few seem to be truncated versions of earlier spamtrap entries, and a fair number of the new entries look like they may have descended from artifacts of stupidity such as products of SMTP callbacks. Proving mainly that in mail and spam handling, there appears to be a space still for the less intellectually astute.

With all of this said, the natural followup question is, given the modest net result, was this worth the effort?

Well, the raw output that yielded 269903 entries needed some manual operations in order to weed out the obvious noise (exact time used not recorded), followed by another background task that took, according to time(1)

    real        105m24.220s
    user        73m3.280s
    sys	        29m14.930s
    

which yielded 1577 entries that were pared down to 1530 entries that met the criteria for inclusion in the circle of imaginary friends (also known as spamtraps).

Before this experiment, the spamtraps list numbered 302625, after including the result here, the count stands at 304154, for a gain of less than one percent of the previous total. Again, if you check back at the traplist home page now, the total number is likely to have increased again.

So was it worth the effort? I feel that as an experiment, it was worth doing.

Whether or not it is an experiment that is worth repeating is a question for another day.

If you have opinions on this, I would love to hear from you, in comments, via email or messages on whichever social media brought you the link to this article.

As always, parties interested in studying the data referenced in this article and other pieces I have written are welcome to contact me for arrangements. I can easily dig out more and rawer data than directly referenced here on request.

Stay safe out there.


As a side note, a slightly improved way of extracting useful data about other domains' mail service via SPF records can be found in the November 2018 artice Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting.

That article (naturally) works from the premise that you are running a recent OpenBSD system.