Some years ago there was an attack on BIND9 where an attacker would exploit the default values in the BIND9 config allowing for recursion, a blind recursive attack was placed, and it caused a server to overload and die, or lag really bad.
This attack was mitigated by custom ACL rule sets within the ACL of bind9. However, a new breed of attack emerged, and effectively does the same thing. I will explain how it works.
An attacker will send a spoofed dig command to a dns server with a source address of another dns server for a bogus domain that doesn't exist, or a blind "." request. Even with recursion off, this still creates an attack if sent in the masses. Why? Because even though the DNS server (if setup correctly), will respond with a fail or blocked reply, it will still send that reply to the spoofed source IP. It's kind of like an old ack/syn flood.
This attack creates load on the targeted server, and the spoofed server since they don't filter these types of requests. Now there are ways to defeat this, using iptables, or APF, and of course a properly configured dns server.
Here is what the attack looks like:
cat /var/log/messages
May 21 12:15:37 <your hostname> named[2158]: client 82.196.3.203#61935: query (cache) 'isc.org/ANY/IN' denied
Now, if you were to run wireshark on this server, you would see that the protocol is UDP on port 53. The attacks have gotten more advanced, as the attacker will forge the packet size, etc to try and bypass filters/firewalls.
Now; what does it look like when it's blocked by APF/iptables?
tail -f /var/log/messages
May 24 11:28:06 u16937963 kernel: ** IN_UDP DROP ** IN=eth0 OUT= MAC=your:mac:here SRC=46.105.124.172 DST=your.ip.here LEN=64 TOS=0x00 PREC=0x00 TTL=117 ID=37644 PROTO=UDP SPT=28164 DPT=53 LEN=44
Breaking this down;
The source attacker was IP under SRC= the Destination = DST and that is your IP. The packet length is LEN=64 the Time To LIve or TTL=117 Protocol is PROTO=UDP SPT = source port and DPT = Destination Port of 53 / dns. Len=44
We do syn_cookies on this server too, to block any spoofing attacks. This is what helps pick it up.
This is a live environment of a web hosting company that I maintain and monitor. The reason I picked up on this was because BIND9 kept crashing, SMTP/POP3/IMAP kept crashing, etc. This would cause the mail server queue to get stuck with un-deliverable mail because DNS was not running, and it had no way to route the mail messages to who ever the recipient was. So in the mail queue in their Plesk panel was shown as
from " " to " " subject " " date "December 31st, 1969 7:00pm" - obviously this is no good. However if you went into the mail queue in a terminal and manually opened the message, it had the correct headers, etc. So, I Knew this had to be an issue with dns, after I ruled out an attack on the mail server itself. Mail server is not a relay.
Further investigation into the logs showed the following in the hundreds at around the time the mail server was erroring, and other service were crashing.
May 21 12:23:19 u16937963 named[2158]: client 37.153.98.159#51340: query (cache) 'isc.org/ANY/IN' denied
May 21 12:23:19 u16937963 named[2158]: client 189.120.90.245#49940: query (cache) 'isc.org/ANY/IN' denied
May 21 12:23:19 u16937963 named[2158]: client 37.153.98.159#51340: query (cache) 'isc.org/ANY/IN' denied
May 21 12:23:19 u16937963 named[2158]: client 37.153.98.159#51340: query (cache) 'isc.org/ANY/IN' denied
As you can see by the above, there is a query being sent to the dns server for records for isc.org and searching for any, or wild card. Obviously isc.org is not hosted by us, and the developer of BIND9 dns servers, which we use. You can see the request was denied, however, it still lags. Explaining further, lets do some research on that IP's who made the request;
using nslookup to resolve a hostname didn't give any results. Using
GeoIpTool.com I could see this was coming from Switzerland. Umm, that shouldn't be..
So trying the other IP 189.120.90.245
# nslookup 189.120.90.245
Non-authoritative answer:
245.90.120.189.in-addr.arpa name = bd785af5.virtua.com.br.
Ok so opening a browser and going to that domain virtua.com.br at the time brought us to what looked like a web hosting company.
So knowing they probably are not attacking us, I noticed that they were probably being spoofed. So I flipped back on APF, enabled syncookies, and logging. Bingo, attacks blocked and logged.
Now the logs will fill up quick if this is a massive attack. So, if it's one IP doing the mass of the attack, just add them to the firewall to block all traffic.
That's all for now. This was a brand new server setup that I just started to admin. After I secured the box initially, I noticed all sorts of attacks coming its way. I believe we have mitigated at least 90% of that now.
I also suggest you install BFD (Brute Force Detection) which works with APF to block any kind of brute force attempts. It's also available from their website.
