The Internet utterly depends on the kindness of users. Its free and open nature has always meant that reliable operation is the norm only as long as most users and nearly all devices are well-behaved. Recent attacks – especially the Mirai DDoS attacks on security researcher Brian Krebs and Dyn DNS – show how easy it can be for a lone attacker to bring large parts of the Internet to its knees for hours or days at a time. This reality is now impossible to ignore.

Akamai Security Report

In the aftermath of the pre-election Internet security breaches, we’re amassing data and about the attacks and hearing suggestions about how to restore a semblance of security.  The (Q3 2016) Akamai State of the Internet Security Report released today describes common attacks and their respective relevance over time.

Each attack type requires a unique mitigation, consequently it’s not always possible to prepare for them in advance. This means lines of defense tend to be prioritized according to expectations, which can be wrong. Mirai used a type of attack that wasn’t common, the so-called Generic Routing Encapsulation (gre) flood attack. Such attacks “remain a very minor component of the overall attack landscape” according to Akamai. But they may become more common in the future.

NTP reflector attacks illustrate an important security dynamic. NTP means “Network Time Protocol”, and it’s simply a way to look up the time. It becomes an attack vector because a short request to an NTP server can produce a great deal of response data. One of the things an NTP server will do is send a list of the most recent 600 systems that have requested the time. This list not only provides the attacker with innocent IP addresses, it amplifies the attacker’s data load. Hence, such attacks are know as “amplifier” or “reflector” attacks.

Here’s Akamai’s narrative on the NTP attack (page 12):

When NTP reflection became a common vector in 2014, we saw large spikes in attack traffic. This was caused by attackers discovering the vulnerability and then sharing information about the pools of vulnerable NTP servers amongst themselves. At the same time, system administrators worked diligently to patch NTP servers, making the lists of vulnerable servers more unstable and less valuable. After the most active system owners were finished, we were still left with a large pool of more stable, rarely patched systems. Slowly, the number of botnets using NTP reflection rose and the total amount of traffic rose with it.

The number of NTP servers available to use for reflection attacks is finite and shrinking . As more botnets use NTP reflection, the servers that are vulnerable receive more traffic, which brings more traffic to the vulnerable servers and draws more attention to them. In some cases, the owners patch them, and in other cases, third parties bring the vulnerable servers to the owner’s attention. In a few cases, old, vulnerable NTP servers went offline. It appears that June was the critical inflection point, when not only did available NTP reflection bandwidth shrink, but botnet owners pivoted to other protocols for their traffic.

Diminishing returns of NTP Reflection Attacks

The fix for NTP attacks is to update the NTP server code and to turn off the command – monlist – that reports on recent queries. Similar methods have been used on DNS and other parts of the Internet’s plumbing. These attacks illustrate the downside of public servers playing nice with anonymous users who aren’t so nice.

DHS Security Recommendations

DHS offers some recommendations for preventing IoT-based attacks in a document on Strategic Principles for Securing the Internet of Things. This is, of course, one step better than dealing with them after the fact. Most of the DHS recommendations deal with IoT device design:

• Incorporate Security at the Design Phase: Security should be evaluated as an integral component of any network-connected device. While there are notable exceptions, economic drivers motivate businesses to push devices to market with little regard for security.
• Advance Security Updates and Vulnerability Management: Even where security is accounted for at the design stage, it is common for vulnerabilities to be discovered in products after they have been deployed. These flaws can be mitigated through patching and security updates and vulnerability management strategies.
• Build on Proven Security Practices: Many tested practices used in traditional security can be used as a starting point for enhancing security of IoT. These approaches can help identify vulnerabilities, detect irregularities, respond to potential incidents, and recover from damage or disruption to IoT devices.
• Prioritize Security Measures According to Potential Impact: Risk models vary substantially across the IoT ecosystem, as do the consequences of security failures. Focusing on the potential consequences of disruption, breach or malicious activity is therefore critical for determining where in the IoT ecosystem particular security efforts should be directed.
• Promote Transparency across the IoT: Where possible, developers and manufacturers need to know their supply chain, namely, what their software and hardware components are and whether there are any associated vulnerabilities. Increased awareness can help manufacturers and industrial consumers identify where and how to apply security measures or build in redundancies.
• Connect Carefully and Deliberately: IoT consumers, particularly in the industrial context, should deliberately consider whether continuous connectivity is needed given the use of the IoT device and the risks associated with its disruption.

The most important thing about the DHS recommendations is that they pertain to the nature of the devices themselves rather than to the myriad Internet services they may be made to attack. In this sense, the DHS recommendations are directionally correct even if they’re not especially detailed. The DHS recommendations boil down to things manufacturers can do today, which is only fine as far as it goes. Some additional steps need to be taken to beef up the Internet’s security toolkit however.

Making the Internet More Secure

Internet security depends on interactions between Internet devices and services. The Internet is managed by applications for the most part, so there’s very little that Internet Service Providers can do to make it more secure. Some writers have suggested that ISPs can solve the security problem, but such suggestions are misguided.

Internet devices and applications request services from web sites and other destinations on the Internet. This basic model of interaction, known as “client-server” or  “the end-to-end principle,” has to be taken as given. Hence, the interaction between end points is where the action takes place on the Internet. The client seeks out the server, who asks for credentials such as user name and password. If these are validated, the server supplies the user with information and everyone’s happy.

But this model is wrapped up in the assumption that clients are general-purpose computers capable of running a variety of applications. In the IoT world, this assumption doesn’t hold.

Hence, the Internet Engineering Task Force (IETF), the people who design Internet standards, is working on single-purpose variations on the end-to-end model that limit the damage that can be done by hijacked devices. It does this by inserting some checking in between client and server. This system is known as “Manufacturer Usage Description” or MUD. A MUD is a list of sites and interactions that the device is permitted to access and perform. The flow looks like this:

MUD Architecture

This means the device is managed by a local firewall at the end user premises operating according to rules obtained from the device manufacturer. Hence, if the code in the IoT device were hijacked, the hijack would have little effect on the Internet. As long as the local Network Management System is not corrupted, the hijacker can’t use the IoT device to attack other systems. This is a deliberate bottleneck that disables Denial of Service attacks by IoT devices.

MUD’s Larger Security Message

The Internet is insecure because it depends on two insecure protocols, TCP and IP. Generally speaking, IP is insecure because it is a “connectionless protocol”, the equivalent of a stack of postcards that can be sent from anyone to anyone else with or without the recipient’s permission. This is fine much of the time, but not when the sender is a malicious actor who wants to saturate the recipient with unwanted information. Anyone can shout anyone else down on the Internet because the design of IP permits shouting.

There are companies that sell insurance against DoS attacks, such as Cloudflare and Akamai. They simply place user websites on high capacity servers with high-bandwidth Internet connections that can’t be saturated by common attacks. But the Mirai attack overwhelmed their capacity, so this solution isn’t universal.  The solution is to redesign IP.

The same thing goes with TCP, the basic end-to-end protocol. TCP has an ungainly and delicate connection establishment protocol – called the three-way-handshake – that has become an attack vector. TCP is an extremely inelegant solution to a problem that has had better solutions for 40 years as John Day explained in our podcast.

But in the meantime, we can make a lot of progress by integrating IoT applications with IoT hardware with MUD. This simply recognizes the special-purpose nature of IoT devices for what it is.