We were barely over a week into February when the news broke of the latest and ‘largest DDoS attack in history’, with a massive 400Gbps attack hitting CloudFlare’s servers; beating last year’s Spamhaus record by around 100Gbps. Unfortunately, it’s only a matter of time until we see an even bigger attack hit the headlines. A lack of action and preparation is making it too easy for attackers to pick targets at their leisure. It doesn’t need to be this way.

The attack on one of CloudFlare’s customers depended on the network time protocol (NTP), one of the oldest internet protocols, which is used to synchronise time between networked computers. By comparison, last year’s Spamhaus attack relied on open DNS servers to launch a huge stream of traffic. However, more interesting than the differences are the technical similarities between the two attacks – both are kinds of amplification attack.

In each, the attacker spoofed the source IP address in making either an NTP or DNS request so that millions of packets sent in response would be redirected to their target. It’s a fairly straight forward attack vector, but the amplification effect means that it can be relatively trivial to launch an absolutely enormous tide of data, without resorting to expensive botnets. In fact it’s getting ever easier to carry out amplification attacks, with tools like DNS Flooder giving would-be attackers a step-by-step guide to launching attacks using a pre-defined list of known open DNS servers. Extending these toolkits to cover other attack vectors (such as NTP) would not be an insurmountable challenge for cyber criminals.

The frustrating thing for many is that defending against these kinds of attack shouldn’t be too difficult if businesses approached the problem in a co-ordinated way. For example, after Spamhaus it was frequently recounted to network and systems admins that they should look at what other connectionless protocols could be used for reflected amplification type attacks. Protocols like NTP, SNMP, CHARGEN and so on are among this list and a review of where systems need locking down accordingly should be part of any business’ security checks.

>See also: Cyber security: the solutions aren’t working?

In the case of NTP attacks, they could be mitigated by either an update of NTP code or a simple change in the NTP configuration to stop the “monlist” command being used by unknown hosts.

It is this monlist command that gives would-be attackers such a large traffic amplification opportunity, as for each NTP monlist request an NTP server can respond (to a spoofed, target IP) with a list of the last 600 hosts who have connected to the NTP server – an NTP server with 600 addresses logged can reward an attacker with an amplification factor of up to 206 times. That’s an extraordinary return on a minimal investment for an attacker. Stopping external monlist requests would stop this attack vector dead in its tracks.

For systems on the receiving end of this kind of attack, it’s much more difficult to mitigate. Businesses can and should, of course, make use of on premise intelligence with security focused Application Delivery Controllers that would allow them to check for suspect NTP requests before deciding whether to pass the NTP response onto the destination server or not. However, this still wouldn’t clear the pipe that is full of many Gbps of NTP response traffic.

As we saw from the CloudFlare attack, this really needs the cooperation of ISPs that can start dealing with this traffic as far up the pipe as possible.

The best approach to mitigation should really be a multi-layered and flexible defence with businesses working in concert with their partners. Every business should have a well thought out and rehearsed playbook that they can work through in response to an attack, ideally combined with a flexible and intelligent set of on and off premise tools in their security toolkit.