There’s been a lot of talk recently about DDoS (distributed denial-of-service) attacks in the wake of an incident that left thousands of users without internet access as a result of the collapse of the servers at Dyn, a DNS hosting service. Needless to say, we should be aware of this threat, know how it works, and how to defend ourselves against it. Especially now, in the age of the Internet of Things, which has made it easier for cybercriminals to build an army of infected devices to carry out this kind of attack.
Protecting multiple devices in the Internet of Things leaves much to be desired, opening up a broad avenue for attackers to easily gain access to and control over these devices in order to use them as weapons. In a DDoS, all of these involuntary recruits connect to the server at the same time in order to overwhelm it and render it incapable of responding to legitimate requests. It’s as though a mob of people jumped in front of you in the check-out line at the supermarket not with the intention of buying anything themselves, but rather just to block you from doing so.
This danger may be commonplace and companies should, of course, be weary of it, but the truth is that a company’s servers are much more likely to collapse as a result of their own errors than from an external exploit. This has been confirmed by Google’s experts, who, without citing concrete data, warn of the alarming frequency with which this occurs.
A company’s servers are more likely to collapse as a result of their own errors
Researchers at the search engine giant allege that programmers and developers often assume that a traffic load will be correctly and evenly distributed by the system, with no contingency plan in place in case it doesn’t work out that way.
Google gives us this example in the way of an explanation. A good amount of mobile apps establish a connection with their servers in a given increment of time in order to fetch information. If there’s no urgency, many apps connect every 15 minutes. In the event of an error, these apps are programmed to resubmit the petition every 60 seconds so as not to have to wait an additional 15 minutes if something in case something goes wrong on the first attempt.
This system reveals its shortcomings when the server, for whatever reason, is unavailable for a given period of time (not necessarily a long one). When it’s back up and running, it receives not only the usual requests every 15 minutes, but will also receive, all at once, an onslaught of requests that were made every 60 seconds during its time offline.
The outcome? A self-inflicted DDoS attack, which could shut down the app as a result of excessive simultaneous connections. If, on top of that, the server goes back offline following this bottleneck of traffic, the chain of incidents will start all over again.
Tips to avoid DDoS attacks
In order to prevent this from happening, the experts at Google offer some advice:
- First, make it so that the initial 60 second delay doubles with each failed request, so that the second attempt is submitted after 120 seconds, the third after 240 seconds, and so on. That way, the number of requests piled up will be lower when the server returns to normal.
- They also recommend that the app keep count of the number of reconnection attempts that each user has made, so that the most urgent requests are given priority when the server gets back to normal. This way, the requests that have been waiting the longest will be attended to first, while the rest continue waiting. A traffic bottleneck will therefore be averted, along with unwanted downtime caused by a DDoS attack launched against yourself.
1 comment
I am trying this on my own site and its working. Thanks man!