NTP reflection attacks continue

Published: 2014-02-17. Last Updated: 2014-02-17 22:23:39 UTC
by Chris Mohan (Version: 1)
5 comment(s)
 
As we discussed here back in January, there has been a significant rise in large Network Time Protocol (NTP) reflection DDoS attacks. In such an attack, an attacker sends a crafted packet that requests a large amount of data that is ultimately sent to the spoofed host. 
 
In our previous post[1], we discussed in detail the “monlist” command but it’s not just “monlist” that can be abused but many level-6 and level-7 commands such as “showpeer”, “sysstats”, “peers”, “listpeers”.
 
To lock down your NTP server, please follow our previous post and upgrade your NTP version as outlined by US-Cert here[2].
 
Additionally, as a FYI, a recent US Cert alert [3] identified other possible sources of UDP amplification attacks and it is recommended to review.
 
For those that think, well that won't happen to me or "Who cares, DDoS attacks have been happening since 1999" this year has already shown an excessive number of public attacks using NTP, creating a devastating flood of traffic to anyone without top notch mitigation* measures lined up. And we're only in February.
 
Brian Krebs's web site, a reporter that write about cyber security stories,  was hit by a 200Gbps of NTP traffic over the last week [4]. Brian reports how and by whom launched the attack in a detail story that's well worth a read. It's not just small targets; since the start of 2014, as reported here, many online gaming websites have been targeted through these reflection-type attacks with the attackers taking to Twitter to announce the upcoming attack and later bask in the glory. The latest Arbor report [5] talks about this in further detail, mentions attacks of up to 309Gbps and names the relevant Twitter IDs tweeting about DDOS. Cloudflare indicated that the attack they saw earlier this week was 400Gbps. The sheer size of these attacks mean that they just don’t break the target but significant areas of the Internet, i.e. large collateral damage.
 
If you see NTP reflection attacks being targeted towards you, the standard best practice follows – 
 
• Apply ACLs to your perimeter network and as far possible upstream 
 
• Work with your ISP(s) to do the same [6]
 
• Lock down your own NTP servers and other UDP-listening servers 
 
• If you detect open ntp servers, report them to the Open NTP project [7]
 
For those that are looking for a handy DDoS quick reference guide explaining the different DDoS attack http://www.us-cert.gov/sites/default/files/publications/DDoS%20Quick%20Guide.pdf
 
* For the majority of businesses DDoS mitigation has a financial cost associated with it that increases upward for increased protection
 
[1] https://isc.sans.edu/diary/NTP+reflection+attack/17300
[2] https://www.us-cert.gov/ncas/alerts/TA14-013A
[3] https://www.us-cert.gov/ncas/alerts/TA14-017A 
[4] http://krebsonsecurity.com/2014/02/the-new-normal-200-400-gbps-ddos-attacks/
[5] http://www.arbornetworks.com/asert/2014/02/ntp-attacks-welcome-to-the-hockey-stick-era/
[6] http://www.ietf.org/rfc/rfc3704.txt 
[7] http://openntpproject.org/
 

Chris Mohan --- Internet Storm Center Handler on Duty

5 comment(s)

Comments

One usually missed source is remote management devices such as IPMI. Supermicro IPMI firmware 2.38 for the X9 (or X8 either/or) series motherboards, for instance, has NTP enabled, and good luck disabling it. Amongst the list of unmentioned devices that have NTP on by default in a less than desirable configuration include Dell's Compellent Storage System...

There are lot of embedded linux systems out there that we use all the time but don't really think about. What about SOHO routers? OOB management platforms?

Zach W.
Zach, most of the cases you mention are NTP clients, the issue here is misconfigured NTP servers, and the fact that DNS and NTP use UDP for communication. If we moved DNS and NTP over to TCP, this issue would go away overnight.

But for what it's worth, as a NTP Pool participant, I've been receiving a large amount of traffic supposedly from 2 hosts in the 67.208.0.0/19 block. I had to block them because I kept exceeding my connections limit. Since blocking them over 24 hours ago, I'm still receiving 3-5 packets/second "from" these two hosts. In bursts, I've seen upwards of 15,000 connections (each) "from" these two alone. The strange thing about them though, is that they're "symmetric active" packets and not monitor-related or synchronization packets. I'm hoping they leave me alone soon, or else I'll have to drop from the pool and close off public access. I realize blocking them might sound dumb, but sending back no response is better than sending back any response, even if it's minimized by disabling non-synchronization queries.
For service providers with customers running open ntpd on their KVM guests, one way to prevent these VMs from responding ntp monlist requests is to add an iptables rule to the FORWARD chain of their hypervisors. For details here is a blog I wrote a few days ago. <http://packetpushers.net/one-liner-iptables-rule-to-filter-ntp-reflection-on-linux-hypervisor/>
The IP block you mention is assigned to Radiant Communications in Toronto Canada. You can contact their tech support at 1.877.257.0555 or by email support@radiant.net
Won't do me any good if they're not the ones causing the traffic. UDP can be easily spoofed, which is part of the problem with NTP amplification/reflection attacks.

Diary Archives