Even in these tumultuous times of omnipresent DDoS threats, you may have found a way to convince yourself that your website is immune. You might think you don’t have many competitors, certainly not the kind who would launch a DDoS attack for a marketplace advantage. You might know that if you receive a DDoS ransom note the best thing to do is ignore it and then ride out any tiny DDoS-for-hire attack that could follow. You might not be on anyone’s political radar for hacktivism, and you might be too small for script kiddies to target you in the hopes of watching the ensuing downtime backlash on social media.
Yes, you think, my tiny online store selling pillows cross-stitched with obscenities is perfectly safe. However, did you know that one of the most significant DDoS threats is accidental attacks, either from outside influence or due to your own code? Truly, no one is immune.
Business As Usual
When you think of DDoS or distributed denial of service attacks, you tend to think of the instances where malicious actors direct a huge amount of traffic at a target website or service using a network of compromised devices, either stuffing the network full of these junk requests so legitimate requests can’t get through, or consuming server resources so there’s none left for actual users.
This thought process is understandable since DDoS attacks are called DDoS attacks, not oopsy-daisy server over-flowy time, but as it turns out, accidental DDoS can happen just as easily as the malicious variety and the end result is the same – site or service outages and frustrated users who start questioning their website or brand loyalty. With attacks potentially coming from almost literally all angles, professional DDoS protection is looking more imperative than ever.
Recent DDoS Slip-Ups
A widespread DDoS attack hitting a bunch of Russian domains may not come as a surprise to anyone. After all, Russia has reportedly not been shy about getting in on the distributed denial of service attack action, going after high-profile targets in the United States and the Ukraine, to name a couple of recent state-sponsored victims.
However, one massive attack in the fourth quarter of 2017 couldn’t be attributed to any of Russia’s cyber enemies. Instead it was traced back to a malfunctioning spambot firing junk requests at non-existent domains in the RU national domain zone, leading to a bunch of DNS servers buckling under the strain and taking swaths of websites down with them.
Additionally, an Apple iOS update in March of last year had to include a patch for a flaw that allowed a phone number to be repeatedly dialled. This flaw was exploited by a teenager who posted a link on Twitter that caused anyone with an iPhone who clicked the link to automatically dial and redial 911 emergency services at a volume that had the potential to shut down emergency service call centres across the teen’s entire county. Rather than make it so people having a heart attack couldn’t call for an ambulance, the teen was just trying to show Apple the flaw could be exploited to produce pop-ups on phones in order to claim a bug bounty. It was mission accomplished in one sense as the flaw was obviously exploitable, though it is unclear if the teenager received the bounty payment.
Coming From Inside The Code
There’s also a good chance that DDoS attacks can stem from a developer’s own actions rather than anyone else’s. Software and application developers often make the mistake of assuming system load will be distributed evenly across an application’s users. This makes complete sense…in a vacuum.
There needs to be a contingency plan to deal with unevenly distributed load because there are several reasons servers could suddenly be hit with at least double the expected or provisioned-for traffic. If a server glitches and requests for data encounter an error, it’s likely written in the code that those requests will retry after a set time, say 60 seconds. When the server comes back online it will have to deal with the requests it would normally have at that time as well as all the requests being retried as a group. Essentially, one minute of downtime has the potential to turn into a self-DDoS attack. The longer the initial downtime, the bigger the struggle a server may have to return to normal function.
There are certainly tricks developers can use to try and avoid those self-DDoS attacks. Exponential back-offs for retry attempts, for one. More dedicated load balancing servers, for another. Those options are well worth looking into, but at the end of the attack-riddled day, it’s just necessary to have DDoS protection. No matter how immune you might think you are and no matter how many accidental or purposeful disaster scenarios you think you’ve accounted for, there’s always another DDoS method on the horizon creeping ever closer with the end result of denying your market their cross-stitched expletives, or whatever product, service or entertainment you offer.