World's largest DDoS strikes US, Europe

There is a new record-setting DDoS attack on the books. This one uses an obscure feature in NTP no one ever uses.

There's a temptation to say "See, I told you so" at folks who are running an unaudited NTP daemon on their networks, but the real culprit here are the uncountable throngs of web devices that have a user-opaque NTP implementation built into them, things like wireless access points and boxes that stream media to and from various appliances in your home. The fix for this NTP configuration bug will reach saturation within a year on every actively maintained open-source server that uses Mills's NTP, but how long will it take for people to replace their D-Links and their Linksys hot spots? And this is assuming that network hardware manufacturers take an immediate interest in securing their embedded services, which is historically not a priority for them.

Advice: don't run an external NTP service. If you do, ACL it, patch your config, or switch to another timekeeping tool like clockspeed or OpenNTPD which is much simpler and doesn't support nearly as many oddball configuration options as Mills's NTP.

I am curious to know how long NTP attacks are going to supersede DNS attacks. NTP is less broadly deployed than DNS, and more and more administrators are enabling DNSSEC for their domains, which compounds the problem. So the adoption of more secure time synchronization software and configurations will dictate whether or not the trend moves back to DNS or not. I imagine that all the ignored embedded NTP implementations on the public Internet will make this the new normal for large-scale attacks until the sweet spot of patched NTP servers and increased DNSSEC adoption causes the pendulum to swing back the other way.

There aren't many more old-school protocols left to exploit. To build a weapon of this scale you need to find an exploit in an old and relatively ubiquitous piece of software. It needs to be UDP-based. It needs to have the level of adoption of DNS or NTP. Finally it needs be largely unchanged from the 1980s, back before white bread Internet engineers worried about putting discriminators or cookies into their protocols. Nobody has a public-facing DHCP or BOOTP server, and things like TFTP are too rare to reliably recruit for your cause. One long-term solution to this problem is to architect your protocols to require the client initiation packet to be larger than the server's response packet. That way, an attacker who finds an exploit in your software will have only a reflection attack of weaker magnitude than the cost of starting the attack in the first place.