There are quite a lot of NTP-amplified denial of service attacks going around at the moment targeting tech and ecommerce companies, including some in the email space.

What does NTP-amplifed mean?

NTP is “Network Time Protocol”—it allows computers to set their clocks based on an accurate source, and keep them accurate. It’s very widely used—OS X and Windows desktops typically use it by default, and most servers should have it running.

NTP is a UDP based service, like DNS, one that works by sending a packet to a server and the server sending a packet back rather than opening a persistent connection to the server as TCP based services (e.g. SMTP, HTTP, …) do. That simpler protocol means that it’s easy for me to send a request to an NTP server with a false source address, claiming I’m someone else—and the NTP server will send it’s reply back to that fake source address rather than to me. So if I want to DoS someone by flooding their network with packets I can send NTP requests to a public NTP server claiming to be the victims server. The NTP server will send the replies back to the victim—and it’ll be almost impossible for the victim, or the NTP server, to trace where I’m sending those request packets from.

As a malicious attacker that already sounds good—but it gets better. The size of a reply is often bigger than the size of a request, sometimes a lot bigger. If I choose the request I make carefully I can easily make sure the reply is at least an order of magnitude bigger than the request. So for every megabit of forged requests I sent to NTP servers, the victim might see at least 10 times that hitting their servers. That’s amplification.

What can you do about it?

If you’re running NTP servers that will respond to requests from the general Internet, you ideally need to lock those down so that they’ll only respond to requests from your own clients. You can use the instructions and information at the open NTP project to check to see if you’re running open NTP servers and use the templates provided by Project Cymru as a basis to secure your NTP servers and appliances.

What can you do to prepare for this sort of attack?

Have monitoring in place, so that you’re notified if there are large volumes of unexpected traffic. Overprovision your bandwidth, if possible, to give you more time to react. Block “large” (>90 bytes for IPv4, >110 for IPv6) UDP packets with a source or destination port of 123 as far upstream as possible, and all UDP packets that have both a source port of 123 and a destination port of 80 or 25—this shouldn’t affect legitimate use of NTP by your users. Consider having your production servers use NTP servers operated by you, rather than public NTP servers—that way, if they’re targeted you can block any traffic that looks like NTP to them without affecting their time synchronization. Research DoS mitigation providers—different providers have different strengths and cost structures, and they can be much more reasonably priced if you talk to them before an attack rather than during one.

What if you’re targeted by this sort of attack?

If you’re not a sysadmin, stay out of your sysadmins way and make sure there’s coffee, food and a quiet place without interruptions available. If you are a sysadmin, talk to your upstream NOC. They’re in a much better place, in information, resources and knowledge, than you to help mitigate. Reach out to your peers who are also being attacked and offer to share information. Look at Cisco’s mitigation advice. The attack will probably target your publicly visible website. If so, consider moving that to another network (or behind a commercial DoS mitigation provider) so that your production servers and customer portal web presence isn’t impacted.

More information
NTP and the Winter of 2013 DRDoS Attacks
Ongoing NTP Amplification Attacks
Hackers spend Christmas break launching large-scale NTP-reflection attacks
Cisco Event Response: NTP Amplification Distributed Denial of Service Attacks