Poking around at a project this morning, I encountered an unusual error from subversion:

[myuser@host ~/projects/slice]$ svn ci -m "Parse EDNS options from log lines"
Sending        ingest.php
Transmitting file data .svn: E000013: Commit failed (details follow):
svn: E000013: Unable to create pristine install stream
svn: E000013: Can't create temporary file from template 
    '/home/myuser/projects/slice/.svn/tmp/svn-XXXXXX': Permission denied

Well that's interesting, I've been committing to this repository for days now without any errors. What happened?

[myuser@host ~/projects/slice]$ ls -la .svn/tmp/
total 8
drwxr-xr-x  2 root    myuser  512 Dec 21 19:23 .
drwxr-xr-x  4 myuser  myuser  512 Dec 21 19:23 ..

Aha, my project's .svn/tmp directory is suddenly owned by root. This was my own mistake. A few days ago, while logged in as root, I had run svn cleanup in this working copy; during the cleanup process, root took ownership of .svn/tmp. The fix was as eas...

DNS Monitoring with SmokePing

SmokePing, the popular network latency monitor, comes bundled with several probes to measure the response time of DNS servers. Instead of just gauging the ping time, they perform DNS queries to test the performance of the service itself. I prefer Christoph Heine's AnotherDNS probe, since it's capable of high-resolution timing and offers a few extra options that the other DNS plugins don't have.

In addition to tracking latency, recently I've wanted to track the contents of DNS responses, too. A spate of high-profile DNS hijacks like the one that hit linux.org got me curious whether I could keep an eye on DNS integrity without installing any new monitoring tools. SmokePing seemed like the obvious choice because I already watch DNS from there, but none of the probes were capable of inspecting response records.

So, I've added some functionality to the AnotherDNS....

After watching the root DNSSEC KSK rollover transpire with no notable fallout, I thought it would be a good time to try a rollover of my own. My attitude towards DNSSEC has been to set it and forget it, so I've never touched a zone's keys after the initial signing procedure. What better time to practice a rollover than when it's top of mind?

While I was poking around, I decided the key tags for this zone were a little boring and could use some spicing up:

[parse@stemmons ~]$ delv DNSKEY shaunc.com. +nocrypto +short
    256 3 8 [key id = 18723]  ; ZSK; alg = RSASHA256 ; key id = 18723
    257 3 8 [key id = 1300]  ; KSK; alg = RSASHA256 ; key id = 1300

Key tags, like 1300 and 18723 above, are generated random-ish-ly when you mint a new key with dnssec-keygen. There's a function that computes the key tag based on the key type, protocol, algorithm, and key text. Considering that the ...

As noticed in a tweet from @AlecMuffett, there's a large DDoS attack taking place involving forged packets that appear to come from 23.225.141.70.

I have servers on a variety of networks, and tcpdump shows traffic "from" 23.225.141.70, destination port 80, at all of them. My points of observation are widespread, so this attack is likely spraying much of the IPv4 space. The volume I'm seeing to any given host is only ~25 packets per second, but reflected traffic could be millions of times that number.

CeraNetworks/CloudRadium, the owner of 23.224.0.0/15, is responding to abuse reports with a statement that 23.225.141.70 is the target and not the source of the DDoS.

Dropping traffic to and from 23.225.141.70 can prevent your system from contributing to the reflection:

    [root@host ~]# iptables -I OUTPUT -d 23.225.141.70 -j DROP
    [root@host ~]# iptables -I INPUT -s 23.225.141.70 -j DROP

...or the equivalent for yo...

This month has brought news of two very high-profile website breaches involving credit card theft:

• On September 6th, British Airways announced that its payment website had been compromised for a 15-day period spanning late August into September.

• On September 19th it was revealed that PC retailer NewEgg suffered a nearly identical breach, that one affecting transactions for more than a month.

In these attacks, a group dubbed MageCart first gained illicit access to each victim's web servers, then inserted malicious code into JavaScript files included by their payment processing applications. That extra code secretly siphoned customer payment data off to a separate server under the attackers' control. Between the two companies, it's likely that credit card details were stolen from more than a million transactions.

Nobody noticed? For weeks‽

M...

New SpamAssassin 3.4.2 release

Apache has released version 3.4.2 of SpamAssassin.

Important security fixes

If you're using SpamAssassin, you should upgrade as soon as possible because this release addresses four security issues:

• CVE-2017-15705, a malformed HTML email part may cause a denial of service through resource exhaustion;

• CVE-2016-1238, incomplete sanitization of Perl's include path;

• CVE-2018-11780, potential remote code execution in SpamAssassin's PDFInfo plugin;

• CVE-2018-11781, code injection in SpamAssassin meta rule definitions

The source distribution...

I've been using Pidgin as my primary messenger client for the better part of twenty years, having found it back when it was called GAIM. There's a lot to like about Pidgin: it's open source, it's cross-platform, its interface is simple and effective, its memory footprint is relatively tiny. And at least until recently, it supported all of the messaging protocols I use on a regular basis.

When Oath decided to turn off the AIM service, I racked my brain for awhile to recall my old ICQ number and then hopped back over there. I don't know many people who still use ICQ, but there are a few, especially with AIM shuttered, so it's nice having everyone in one client. Unfortunately, that changed a couple of months ago when Pidgin started throwing this error during the connection to ICQ:

Received unexpected response from https://api.icq.net/aim/startOSCARSession: Request Timeout

Looking at the debug window, it's clear that the connection is established properly and Pidgin sen...

Another year relegated to the annals of history! In a twist I'd never have predicted, the best birthday presents came from the Southern District of New York and the Eastern District of Virginia. I should probably send thank-you notes.

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