Amplified DNS Attack, general information, and fixes.

How I got my hands into this.

Well, the step by step on how I met this new challenge. You may find the general info here (https://derekdemuro.me/blog/server-downtime-due-network-outage(link is external)), don’t get me wrong, the solution is not that big deal, yet it can get a bit tricky if you have a complicated network with our limitations.

You may find our network diagram on the site.

Well, everything started while I was working. On one of the networks, I noticed a constant 120 KByte/s, so I head up to the server and started trying to filter its source from the logs, thankfully. As I began using Munin, we were logging the queries on the Bind Server. After “tail -f /var/log/bind” I noticed many questions for isc.org, strangely asking for all the records on that domain.

So to that moment, I thought, Research TIME!.

Well yeah, so the attack is old as time itself, but I did not know as it never happened to us, so we never cared to follow this kind of threat.

Well going over this we found:?

After this happened, we started noticing this has been going for a while, as you can see at the blog post, so here’s the fix!.

Depending on your scenario here are some options:

1.On windows (Turn off recursive queries).

On Linux (two ways).

First:

As some may know, iptables are extensive and a robust way to protect a standard server without external help, so adding these two lines to your INPUT chains should get it fixed right away.

iptables -A INPUT -p udp -m string –hex-string “|03697363036f726700|” –algo bm –to 65535 -j DROP

That should match (isc.org) another way is:

iptables -A INPUT -p udp -m string –string “isc?org?” –algo bm –to 65535 -j DROP

Remember, if another attack appears, check the packets with Wireshark or similar.

Second:

Turn off recursive queries for networks outside your own with ACL’s.

Example:

On Bind 9

/etc/bind/named.conf

acl vpn_nets {
10.8.0.0/24;
10.9.0.0/24;
};
acl external_nets {
any;
vpn_nets;
};
acl local_nets {
192.168.5.0/24;
127.0.0.1;
};

Add this at the beginning of the configuration file.

This should not happen anymore, and you should be outside the red zone.