The recent increase in NTP amplification attack has shed the light on the utility of control-plane filtering. A few days ago, the US-CERT issued an advisory that warns the public about this emerging form of Distributed Denial of Service (DDoS) attack. As you know, the Network Time Protocol (NTP) is a very popular UDP based protocol, used by a large number of computers and devices, including routers and switches to keep their software clocks synchronized with remote references clocks. The protocol support a number of administrative requests that returns statistical information, such as a list of the last 600 associated clients, the statistical counters associated with the protocol's I/O module, and so on. Most of these commands are ideal for amplification attacks, because they returns a large number of information, and therefore their replies have sizes significantly higher than their initial requests.
By making use of these administrative commands and by spoofing the request's source IP address, an attacker can generate a massive amount of UDP traffic toward its victim. A 230 bytes MON_GETLIST request can generate a reply up to 48'000 bytes long, which represent an amplification factor 206 times. The number of packets generated or amplified could also be significant, as a single request can generate more than 10 reply packets.
The NTP attack is not very different from the DNS amplification attack. The attacker still use the request's source address to direct the attack toward its victim, therefore, they've common mitigation techniques like firewall filters and uRPF check. What is new though, is the fact, NTP is something of a very under-looked protocol. It runs on a large number of devices, from servers, switches, routers, firewalls, to your home's fridge. In fact, some network vendors even automatically enable the server component of NTP as soon as you configure the client. Not only it enable the server if you've no use for it, it allows the administrative commands by default, which make your gear a DDoS amplifier, and also a potential victim of the attack. Yes, routers and switches have usually very limited CPU resources and there is already a number of operators and enterprises that have seen major spikes of CPU utilization. If you think, you will never be impacted because nobody knows you run NTP on your gears, don't be so confident, there is very good reconnaissance tools out there, like nmap to discover your vulnerable hosts.
If you would like to know if your device is vulnerable, you can use the
ntpdc client utility, as follow:
# ntpdc -n -c iostats 193.*.*.1 time since reset: 2426998 receive buffers: 9 free receive buffers: 9 used receive buffers: 9 low water refills: 0 dropped packets: 0 ignored packets: 0 received packets: 32 packets sent: 9564 packets not sent: 8 interrupts handled: 32 received by int: 32 # ntpdc -n -c monlist 193.*.*.1 | wc -l 602 # ntpdc -n -c iostats 193.*.*.2 126.96.36.199: timed out, nothing received ***Request timed out
If you get an answer, it's not good at all. If your device support it, disable the NTP administrative commands so they are only available to your management system. If you can't, configure control-plane protection and make sure you implement BCP38.
What I would recommend, is to implement all of above mentioned mitigation techniques, because NTP is no exception. NTP is a very good example of a service long time used, which turned out to be a source of security and stability issues. The best approach is therefore to block all inbound traffic destined to the control-plane of your equipments, except the traffic from trusted sources and from known protocols (e,g. IGP Hellos, VRRP PDUs, eBGP Peering Sessions and SNMP).