Another year relegated to the annals of history!

If you have a web application that accepts any user input, you're probably dealing with spam bots. There's been a steady increase in automated spamming of blog comments, contact forms, order forms, and other types of interactive web resources. If they can post to it, they're trying to spam it, even in cases where it makes no sense, like submitting advertising pitches to API endpoints or search forms where no human will ever see the message.

Web spammers have been busy escalating and evolving. The adversary is no longer some guy in Elbonia running XRumer over his dial-up connection; these days you're likely to encounter dedicated and distributed web spamming networks. In these cases, the spammer spins up multiple VPSes at different providers, all communicating with one another as part of the spam operation. Often a recon visit will come from one IP address, followed immediately by several POST requests from other hosts in the spam network. This method attempts to fly under the radar of rate limiting and o...

It looks like automake-wrapper-20131203 has been replaced with automake-1.16.1 in the FreeBSD 11.1 ports tree. Unfortunately, portmaster is stumbling over the change and failing with an error. If you're receiving the output below, scroll down for the fix:

[root@host /tmp]# portmaster -avw
===>>> Sorting ports by category
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates

===>>> Root ports: 18
===>>> automake-wrapper-20131203

        ===>>> The devel/automake-wrapper port moved to devel/automake
        ===>>> Reason: No longer needed

===>>> Launching child to update automake-wrapper-20131203 to automake-1.16.1

===>>> All >> automake-wrapper-20131203 (1/1)

        ===>>> The devel/automake-wrapper port moved to devel/automake
        ===>>> Reason: No longer needed

===>>> Currently installed version: automake-wrapper-20131203
===>>> Port directory: /usr/ports/devel/automake

[...snip checking all in...

In late May of 2018, the LibreNMS project released version 1.40. This update brought the Laravel framework to LibreNMS, and with it came some interesting new errors. Most of them are covered in the community announcement titled New Requirements for 1.4.0. I've encountered some errata that I wanted to cover here.

Command changes for FreeBSD

FreeBSD users will need to make a couple of modifications to the release guidance:

1. FreeBSD doesn't have a standalone usermod command. Instead of the usermod command suggested by LibreNMS, run pw usermod instead, such that the user that runs Apache on your system is added to the librenms group. In my case, Apache runs as daemon, so I ran:

   [root@host librenms]# pw usermod daemon -G librenms

2. FreeBSD's setfacl command lacks a recursive -R option. Disregard the setfacl commands suggested by LibreNMS and run the following chmod instead, ...

The launch of Cloudflare's new 1.1.1.1 DNS service has brought much fanfare and a heap of praise. More choice is always a good thing, and support for both DNS-over-TLS and DNS-over-HTTPS make 1.1.1.1 an interesting option. In this post I'm going to explain why I won't use it yet, and why you might not want to switch either without doing some testing first.

Fastest isn't always best

Cloudflare touts 1.1.1.1 as "the Internet's fastest DNS directory." In terms of pure response time, they might be right. But when dealing with DNS, response time is only part of the equation. Just as important are the replies you get from a DNS server, the IP addresses it hands out in response to domain queries. Responses from centralized DNS services are sometimes unsatisfactory and can lead to service degradation. The answers come fast, but are they the right ones?

I like to use a telephone analogy here. Imagine you dial 9-1-1 and your call is answered so quickly you ne...

Today I saw an interesting IMAP probe. These are usually background noise, occurring by the hundreds each day and mostly trying weak passwords against non-existent accounts. This particular login attempt was made on a valid alias, so I took a few seconds to dig deeper, and found an indicator of attack I hadn't seen before.

Immediately preceding the IMAP authentication attempt, the same IP address had issued one HTTP GET request and two HTTP POST requests for /autodiscover/autodiscover.xml on the same domain (the file doesn't exist). Not being familiar with autodiscover.xml, I looked up the documentation and it's a WPAD-like configuration discovery scheme for Outlook. Aside from people whose own Outlook clients and/or Exchange servers are spamming their own web server logs with requests, I couldn't find many people talking about seeing it in their httpd logs. autodiscover.xml doesn't seem to be commonly scanned, spidered, or ab...

Facebook's data collection tactics make waves

With Facebook and Cambridge Analytica in the news, Facebook's threat to privacy is finally getting the widespread attention it deserves. Beyond the obvious political propaganda concerns, the wider implications of Facebook's data collection are coming to light, and some of the examples are alarming. Multiple users have downloaded their history and discovered that Facebook had records of all of their phone calls and text messages.

In addition to siphoning up phone-related data, much of the web has become infected with Facebook tracking beacons that collect your browsing history on desktop PCs and mobile devices. When you see a Facebook "Like" or "Share" button on a web page, your browser typically loads these directly from Facebook's servers. Some websites without visi...

Let's Encrypt, a leading issuer of SSL/TLS certificates, has taken a big step forward by adding support for Certificate Transparency. This capability, now merged into Let's Encrypt's Boulder CA suite, resolves a long-standing feature request by embedding Signed Certificate Timestamps (SCTs) into newly minted certificates. Because the SCT is attached directly to the certificate, no additional server modules or configuration is needed by site administrators.

Certificate Transparency support allows websites using Let's Encrypt certificates to implement the Expect-CT HTTP header. This header provides additional security by instructing web browsers to verify the certificates they receive against public certificate transparency logs. Forged or otherwise malicious certificates are often absent from these logs, and will ...

If you run a mail server, whether it's for your own personal email or for your company and its employees, one of the biggest challenges you'll face is keeping spam at bay. Fortunately, several organizations maintain DNSBLs available for public use. These blacklists of known spammer servers and networks are the biggest hammer in a mail admin's toolbox, and are easy to configure in most common MTAs.

Used wisely, a good selection of DNSBLs can reject most of your incoming spam early in the SMTP conversation. This prevents your server from having to process those messages through other, more resource-intensive filtering strategies. On the other hand, each blacklist you enable adds another potential DNS lookup for every incoming message, and another opportunity for false positives that discard legitimate mail. To that end, it's a good idea to keep an eye on how the DNSBLs you choose are working on your system.

In this post I'll share some methods for gauging how DNSBLs ...

While doing a bit of housecleaning on a system, I hit a subversion error I've never seen before:

[user@host]$ svn ci -m "Replace symlink with hard copy of file"
svn: E145001: Commit failed (details follow):
svn: E145001: Node '/path/to/my/myfile' has unexpectedly changed kind

I'd replaced a symlink, which was already versioned, with a copy of the target file itself. I'm usually pretty good at convincing subversion to accept whatever arcane mangling I've done, but it just wouldn't take this one, and Google was no help. I was able to get things right again with the nuclear option, removing the offending object from version control and then adding it back. Specifying --keep-local removes the file from the subversion repo but leaves it in place on disk.

[user@host]$ svn status
~       myfile
[user@host]$ svn rm --keep-local myfile
D         myfile
[user@host]$ svn ci -m "Remove symlink, will add back as a file"
Deleting       myfile
Committed revision 1602.
[user@host]$ svn add ...