Protecting your hosted e-mail from spoofing

For a couple of months I’ve been getting a trickle of badly-put-together (but frustratingly well-spoofed) extortion spam at my main website e-mail address.

Some of the gems not shown here are “I am in shock of your reach fantasies!” and “My Trojan have auto alert, after this email is looked, I will be know it!”… then they ask for $928 in Bitcoin.

It didn’t bother me that much beyond my inability to track down the culprits (the spammers seem to be mainly using other people’s vulnerable ADSL routers in various countries to send their spam), but what really crossed the line for me was when I started getting delivery failure notifications for spam messages to other people:

Same basic idea, but this time they’re sending it to other people and putting my address on it. Destination address censored in case it does actually belong to someone.

Yes, the spammers were spoofing their messages to come from my address, and my domain wasn’t configured to give mail servers any rules about who is allowed to send e-mail from my address by default, so everything was being allowed through. I found some great resources like this Lifehacker article that explain how e-mail spoofing works, and I determined that I needed to add a Sender Policy Framework (SPF) record and a “Domain-based Message Authentication, Reporting & Conformance” (DMARC) record to my DNS settings.

Long story short, SPF tells mail servers who is allowed to send e-mail from a given domain name and DMARC tells mail servers what to do if a message is sent from an unauthorized server. They work together with SPF forming a security foundation for DMARC to build on. They’re both specified as TXT records and each has a specific format. I found some extremely helpful resources from DMARC Analyzer for putting together those records: they have guides for SPF and DMARC and even an online record checker for verifying that everything looks good.

I set up my DNS records so hopefully mail servers will now reject messages that I don’t personally send through my server, and I should now get reports about any future spoofing activity. I plan to write a follow-up post if I get any interesting results back from that. For now, stay safe out there and don’t give any Bitcoin to strangers!

Lightbox plugin now available!

Yes, the custom lightbox plugin I developed for my website’s photos page is finally officially released! It is lightweight, functional, nice-looking (in my opinion at least), and it even does a little trickery when the page loads to make it a bit harder for visitors to download copies of your images.

I have a page dedicated to the plugin right here on this site, but more importantly, you can also find the plugin on WordPress.org and take a look at the source code on GitHub. Please do feel free to use it if it’s what you need for your website.

A quick note about PHP error logs

For some time I’ve been noticing a strange issue on my website: every once in a while, a file named error_log would appear in a subdirectory of my document root, visible to anyone who knew to look for it. It seems that whenever there was a PHP error (for example, when a vulnerability probe tried to access a theme file), PHP would dump the error message to a file in that same directory.

Those error messages contained absolute filenames within the server filesystem, so obviously that’s not something I want to be publicly viewable. I figured out that PHP has a setting for where to store error logs, and my web host had it set to just ‘error_log’. When there was an error message to output, PHP would send it to that relative filename, meaning the log file would show up in the same directory as the file where the error occurred.

Luckily, I have the ability to override PHP settings in a .user.ini file. The WordFence firewall (which I highly recommend, by the way) had already created one, so I just added a line setting error_log to an absolute path in my home directory. Problem solved! Now all my PHP errors go to a private file that the rest of the world can’t see.

<head> cleanup plugin now available!

Now that my website redesign is complete-ish, or at least launched, I’m starting to work on cleaning up and releasing some of the custom code I wrote to make it happen. This is one of those pieces: a tiny, lightweight plugin that removes unneeded stuff from the head section of each page to make everything a little more lightweight, improving loading times, bandwidth usage, and site security.

You can find an informational page about the plugin right here on my site, or just jump straight into what code there is over on GitHub.

Enjoy!

New website design!

I’m very excited to announce a new version of my website! This has been a very long time coming, but I have finally redesigned it in WordPress and added a bunch of new content. It will be a lot easier for me to add more on an ongoing basis too, and I plan to write blog posts every so often about my software projects.

MODX worked great for me for a while, but one of the security updates actually broke my ability to save content in the administrator backend. I did a couple of important edits by manually running UPDATE queries, but that’s not a sustainable publishing workflow by any stretch of the imagination. It’s advertised as a more secure CMS, but with some simple plugins and minor customizations, I think WordPress can be just as secure.

I’m excited to share more of my software and write more as I learn my way around. Let’s do this!