While deploying a port upgrade this afternoon, I ran into a problem that I knew was coming eventually. FreeBSD's daily run output has been warning me for months that Perl 5.24 would be reaching end-of-life, and it just happened. It turns out that perl5.24's expiration date was May 9th 2019, so portmaster bombed out while working on a port with a dependency on Perl:

The lang/perl5.24 port has been deleted: Has expired

portmaster helpfully (?) installed a newer-but-not-newest version of Perl, 5.26.3, but something about it didn't "stick." Running perl -v showed the 5.24 version remained in place, and portmaster itself was still unable to upgrade any ports with a dependency on Perl. After some digging in the ports collection's UPDATING docs, here are the steps I took to get Perl back in proper working order (and upgraded to the latest stable, 5.28).

First, edit /etc/make.conf and append the following l...

Update

Reddit user megalomaniacs4u has found a more elegant solution that you probably want to try first. It achieves the same goals (importing a good certificate, re-verifying your add-ons) in fewer, easier steps.

Original post

This is an interim fix for Armagadd-on 2.0 on Firefox 61, 56, and potentially other old versions. As of this writing, Mozilla's official hotfix XPI doesn't work on these versions, so manual workarounds are needed.

This process successfully reactivated my extensions on Firefox 61 and Firefox 56 under Windows. It also worked on an old copy of Firefox 48 for Mac OS X. I can't promise that your add-ons won't be disabled again in the future, but this might get them working for now.

There are two objectives: one, get a working Mozilla signing certificate imported into Firefox; and two, tell Firefox to re-verify your extensions. You must complete all of the steps below. Use this g...

One of my DNS servers has been seeing some unusual bursts of traffic over the past month. At random intervals, several hundred rapid queries for qname miep and qtype ANY will arrive, appearing in BIND's security log like this:

03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0cb600 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied

At first glance, this resembles a DNS amplification attack. For one thing, the deprecated ANY qtype is used in such attacks to maximize the size of the answer packets. Secondly, the origin IPs are probably forged, considering the legitimate resolver 1.1.1.1...

With a couple of my domains now past 20 years old, dozens of email addresses I've used over the years have made their way onto countless different spammer mailing lists. As such, my mail server rejects a lot of spam, thousands of attempts daily. Keeping an eye on the rejection stats lets me observe spam trends, and an interesting one caught my eye over the weekend.

For reasons unknown, someone launched a high-volume spam campaign targeting completely bogus and undeliverable addresses.

I'm used to dictionary attacks, where a spammer pumps messages to common aliases like david@ every domain he can find, hoping that many of them reach a real person. This is something different. The user parts of these recipients are longer, unique strings that somewhat resemble compound words or names. Here are a few examples,

awproceed    
brigmanramac    
celiavolkan    
hginherent    
kalenametzge    
ksuassignment    
phileyburlin    
straussotokar    
wickertmilos    

Not only have thes...

If you're looking to speed up your FreeBSD kernel and world builds, try using the WITH_META_MODE compile option and/or installing and enabling ccache. Turning these on gave me a 30x speed boost for the buildworld and buildkernel process. That's not a typo. Compiling a complete kernel and world on my test machine used to take over 6 hours, even with /usr/obj/ having been left intact from prior builds. My most recent build finished in just 13 minutes, or around 1/30th of the old time!

WITH_META_MODE

The WITH_META_MODE compile option takes advantage of the filemon kernel module, creating and inspecting metadata about the objects compiled during a system build. New metadata files get stored in /usr/obj alongside the object files they refer to. On subsequent builds, when the compiler goes to build an object, if nothing about the build command or its related files (headers, libraries, etc.) has changed, the cached object can be used instead...

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