ISC.org DRDoS Update 2: Problems with .nl Netherlands TLD

I provided a netfilter rule in my last update that indiscriminately drops packets containing the string "isc.org" on port 53/UDP which I have had to implement on a client's network due to one of their name servers being targeted as an amplifier in a UDP bandwidth-starvation DRDoS attack. I was afraid this sort of blunt-object type of approach might have unforeseen ramifications when I wrote a snort rule of similar design and today one has reared its ugly head. It turns out this string is part of the payload in transactions with (at least) the .nl root servers. This would not normally be much of a problem for a small Canadian network but for the fact the registered name servers for kijiji.ca (a popular free classifieds site) are all under .nl.

As you can see, my friends haven't taken the hint and buggered off to greener pastures yet; the spike correlates with my removing and replacing the netfilter rule. You'll notice the inbound stays steady after the outbound drops off, that's because the packets are only being dropped at the name servers rather than the gateway as usual (I double-wrap for his pleasure).

I have a number of options and currently I find none of them particularly satisfactory. For the interim the solution has been to provide clients with a secondary name server off the network. More to come?



They've learned to alter the source port. You can block queries from any port or address without interfering with resolving .nl addresses by simply expanding the search string to: 00000000000103697363036f726700

So obvious I'm not sure why I didn't think of it first. Derp. :/


I should have added this ages ago: the solution is to add the source port of the attacks to the rule.

• ISC Operations

Hi, if you can send a email to the address attached to this comment, we'd like to take a look at the data you are seeing. We keep getting off and on reports of the isc.org joejob, but are looking for more hard data.

Thanks - ISC Operations.