DDOS using ntp server
These attacks have been around for ages, they just became popular again the last couple of months. They work like any regular amplification attack: a host spoofs a query so that the source IP address seems to be the targetted host. The NTP server sends its answer to the spoofed address. Since the answer for specific query types can be quite large and usually is UDP, this can quite rapidly become a problem for the targetted host: it's being swamped with NTP packets.
Unfortunately this isn't a vulnerability in NTP servers, it's just a feature which is being abused. One thing to consider is if you need to run NTP servers which can be queried from the entire internet. If that's not needed, create an access list or firewall policy to block queries coming from untrusted sources. Then, what you can do to check if your NTP servers are vulnerable is doing NTP queries from untrusted sources and verify if you get an answer. But unfortunately there are quite a number of NTP servers which are public by intent (e.g. all servers in pool.ntp.org). If you need to run a public NTP server, you can consider implementing query ratelimiting to reduce impact to the targetted host in case of abuse.
Another, more generic part of the solution is that networks need to implement BCP38, which tells them to filter traffic leaving their networks so sending spoofed packets is impossible. Unfortunately, there are still a large number of networks which do not implement this kind of filtering, so all attacks with spoofed source packets (using any protocol like NTP, DNS or chargen) are still possible.
What you can do to mitigate such an attack depends a bit on your network and tools available, but one thing you should consider is blocking incoming NTP packets from untrusted sources (so check which NTP servers you're using). Of course, this doesn't help if your uplink is congested. In that case, you'll need to ask your ISP to help you filter the traffic.
My answers:
- The attacks use monlist commands (which will show as ntpv2 reserved in tcpdump). These commands are not rate limited by the normal rate limiting. Monlist (and other monitoring commands) will only work from IPs that are allowed to 'query' your server so add 'noquery' to your defaults.
- Try a ntpdc -nc monlist yourip from an outside IP to see whether your server answers.
- Ratelimit your incoming ntp traffic. Not in the ntpd itself but before it reaches the daemon. How to set this up in linux is discussed in "my rate limiting setup" on the ntp pool mailing list
- Can you please give details on how they work and clarify? Since ntp is ran over UDP, I suppose there must be some kind of forged packet somewhere?
The US-CERT has a great description of this attack at "Alert (TA14-017A) UDP-based Amplification Attacks" and "Alert (TA14-013A) NTP Amplification Attacks Using CVE-2013-5211".
TA14-013A says it best:
Description
UDP, by design, is a connection-less protocol that does not validate source IP addresses. Unless the application-layer protocol uses countermeasures such as session initiation, it is very easy to forge the IP packet datagram to include an arbitrary source IP address [7]. When many UDP packets have their source IP address forged to a single address, the server responds to that victim, creating a reflected Denial of Service (DoS) Attack.
Recently, certain UDP protocols have been found to have particular responses to certain commands that are much larger than the initial request. Where before, attackers were limited linearly by the number of packets directly sent to the target to conduct a DoS attack, now a single packet can generate tens or hundreds of times the bandwidth in its response. This is called an amplification attack, and when combined with a reflective DoS attack on a large scale it makes it relatively easy to conduct DDoS attacks.
The included chart regarding "bandwidth amplification factor (BAF)" shows that NTP exhibits the worst behavior. Since NTP is an extremely common protocol, and many Linux OSes ship with an active NTP server, this problem is particularly bad.