Some network services are predestinated to be used as DDoS helper: They are UDP based and the response payload is much bigger than the sent request. UDP makes it easy to fake the sender IP. So anyone can send a request on behalf of some other IP which then gets the response of the request.
That creates a so called amplificated attack. Some examples:
- Asking an NTP server the
MON_GETLISTcommand, which is 234 bytes long, can lead to an answer which is up to 152100 bytes long. The amplification factor here is up to 650. Read more about it here: Understanding and mitigating NTP-based DDoS attacks (CloudFlare blog) - An average DNS request to UDP port 53 is approx. 60 bytes long. According to the asked record, the answer could be up to 3000 bytes long. This creates an amplification factor around 50. This attack is called “DNS Amplification Attack”. Read more about it here: How to Launch a 65Gbps DDoS, and How to Stop One (CloudFlare blog)
NTP
UPDATE: According to CloudFlare, more and more NTP servers are being updated: Good News: Vulnerable NTP Servers Closing Down
To find vulnerable servers to the NTP attacks, nmap is your best friend in doing this. I’m using a NSE script to identify NTP servers which respond to the MON_GETLIST command:
sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist-simple -oN ntp-monlist.txt <prefix>
This scans all IPs defined in <prefix> and saves the output to ntp-monlist.txt. This file can now easily being grepped for affected IPs including their PTRs:
for i in $(grep Affected ntp-monlist.txt | awk '{print $3}'); do echo -n $i "- "; host $i; done
Nmap ships an NSE script by default: ntp-monlist. I’m using a modified version, which only prints "Affected" or "Not affected". Here is the diff:
--- /usr/share/nmap/scripts/ntp-monlist.nse 2013-10-10 15:04:12.000000000 +0200
+++ /usr/share/nmap/scripts/ntp-monlist-simple.nse 2014-02-14 09:55:13.155293422 +0100
@@ -119,21 +119,10 @@
-- end here if there are zero records.
if #records == 0 then
- if sock then sock:close() end
- return nil
+ return "Not affected: " .. host.ip
+ else
+ return "Affected: " .. host.ip
end
-
- -- send peers command and add the responses to records.peerlist.
- rcode = REQ_PEER_LIST
- sock = doquery(sock, host, port, inum, rcode, records)
- if sock then sock:close() end
-
- -- now we can interpret the collected records.
- local interpreted = interpret(records, host.ip)
-
- -- output.
- return summary(interpreted)
-
end
@@ -1089,3 +1078,4 @@
end
return o
end
+
An easier way would be to use ntpdc –c monlist <IP> which get's the output of the monlist command.
UPDATE: You could also have a look at the list here: OpenNTPProject.org - NTP Scanning Project
What to do against this vulnerability?
Upgrade to the latest version of ntpd. For other operating systems, there is a nice list here: Secure NTP Template. In my opinion: The best way would be to don't allow access to the NTP service from the Internet, only allow it if it's really needed.
DNS Open Resolver
The best way to find open DNS resolver in your network is also Nmap:
sudo nmap -sU -pU:53 -sV -P0 --script="dns-recursion" -oN open-dns-resolver.txt <prefix>
This command should be run from outside your network because your internal hosts are most likely allowed to use your DNS resolver to make recursive queries.
Another way would be to query an online database, such as DNS SURVEY: OPEN RESOLVERS
What to do against this vulnerability?
Only allow hosts from your network to access the DNS recursor. It makes no sense to allow everyone to use your recursor, unless you are Google, OpenDNS or similar. These providers have special counter measures against such vulnerabilities, like rate limiting.
Detect suspicious traffic
A good way to detect suspicious traffic, such as the above mentioned, is a sFlow or Netflow tool like NfSen. They are able to create profiles which can find anomalies an send alerts.
