Reducing the Risks of Distributed Denial of Service Attacks
Picture what may just be one of the scariest scenarios in your career: The network has slowed to a crawl. You can barely hold a management interface, let alone control the network elements involved. The attack propagates, and as it does you watch your services drop one by one. Panic sets in. You’re experiencing a Denial of Service (DoS) attack. All resources are focused on stamping this fire out—and that may very well be the intention of the attackers.
A DoS attack might be a smokescreen to get you to focus elsewhere while the intruder goes about covert business in a much safer fashion, leaving little forensics afterward.
DoS attacks are an easy thing to comprehend. Even the term Distributed Denial of Service (DDoS) is an easy extension. But the strategy behind why they’re used and their intent can vary dramatically. A DoS attack can occur in an array of sophistication. Here’s a quick breakout from the simplest to most complex attacks:
Network Level attacks:
The simplest ones—TCP, UDP, ICMP, Floods
Service focused—DNS, NTP, SNMP, SSDP, Specific floods
Session specific—overlaps, missing, too many
Repetitive GET, slow READ or loop calls
Stack and protocol level, buffer resources
These methods are often overlapped in a targeted fashion. In essence the attack is a series of waves that each hit in varying degrees of sophistication and focus. Other times the attack is relatively primitive and easy to isolate. The reason for this is that in the simplest levels, it’s an easy thing to do. As an example, a disgruntled student, upset over a new vending matching policy, could mount a DoS attack against his or her school administration. On the other end of the spectrum is a much darker orchestration, the sleight of the hand to get you to look elsewhere. This is typically the signature of an Advanced Persistent Threat (APT).
Unless an attack is very simple and short-lived, it needs to be distributed in the way it operates. It needs to be generated from various points of origin. This is referred to as a DDoS attack. The attacker needs to coordinate a series of end points to execute some particular event at the same point in time or perhaps, in more sophisticated examples, as phased against a time series. For a DDoS attack, the attacker requires a command and control (C2) capability. This means that they need to have access and response to the compromised systems. This is referred to as a Botnet.
Botnets do not have to be sophisticated to be successful. They only have to implement a simple set of instructions at the right point in time. Let’s take the recent reflective/amplified DDoS attack on Dynamic DNS services on the East coast of the U.S., which affected several large firms such as Amazon and Yahoo. The attack was mounted from residential video surveillance cameras. Even though there was no direct intrusion, the firms were impacted. Which leads us to two lessons.
Lesson number one: Security in IoT needs to be taken more seriously in the product design stages. Perhaps the concept and treatment of residential security systems needs to be rethought.
Lesson number two: As we move to outsourcing and cloud services we need to realize that we spread the reality of our exposed risk. Due diligence is required to assure that service providers and partners are doing their role in end-to-end security. But do you recall I mentioned that the source of the orchestrated attack was from the residential network? This brings about a new degree of challenges as we look at the new world of consumer IoT.
How do we maintain security in that sector? Clearly the residence itself should uphold best practices with a well-maintained and monitored gateway. But let’s face it, this is generally not going to happen. The monitoring of behaviors and abnormalities at the provider interface level is the next best catch and many providers are moving to reach this goal.
The other key point to remember about botnets is that in order to command, one has to control. This can happen in various ways. One is automatic. It infects and sits until a predefined time and then activates. This is the simplest. Another method requires true C2. Either way, bad code gets residence or existing code gets leveraged in negative ways. You should be able to pick out the anomalies.
Proper design with hyper-segmentation can greatly reduce the risk of propagation from the initial infection. The botnet is contained and should be readily identified, if you’re watching. Are you?