One of our clients experienced a number of DDoS attacks over the course of few days.
The website couldn’t withstand those attacks since the server couldn’t handle the significantly increased loads.
During such attacks, the website was unavailable to the visitors and was showing a 503 error.
The fact that such attacks were happening during the grand sale our client was conducting at his e-shop was only increasing the damage.
The client asked WiserBrand to investigate the situation within quite short timelines and help to stop the DDoS attack.
WiserBrand’s technical team and VP of Technology was brought in to analyze the situation, look through the server logs with fail-to-ban and suggest a solution.
As emergency actions, our team suggested to block certain IPs and ranges, as well as introduce CloudFlare as basic protection.
At the same time, we understood that the kind of attacks our client dealt with were not the kind of attacks that could be fixed with the help of generalized solutions.
After a thorough analysis of server logs, we discovered that the attack was quite clever: it was mimicking human behavior.
A lot of IPs belonging to different ranges were hitting the website, often the same page, at the same time.
However, each IP was making only a few hits, and they were trying to humanize their actions: go to the website search, visit the product page first, and only then - shopping cart.
We were able to determine that those were not actual people browsing the site since the bots were reaching the website’s pages without proper ref parameters.
Unfortunately, the pattern of the attack was still too intricate to implement a standard DDoS protection solution, which couldn’t distinguish such bots from regular people.
Additionally, the attacks were coming from the ranges that included regular Internet users. Most of the mitigation services are based on the previous actions. For instance, when they notice that certain machines are causing a significant load on the server, which was never detected before, they block them.
But in case if a lot of machines participate in the attack, and each of them generates traffic that’s common for an ordinary website visitor, such mitigation services (CloudFlare’s “I’m Under Attack” mode) aren’t providing satisfactory results.
If the website isn’t able to handle such attacks, it means that part of the website isn’t developed properly and it has to be reworked. However, it’s impossible to review the code and re-develop a part of the website within the reasonable timeframes.
While that is being done, it’s necessary to provide regular users with the ability to browse the website without noticing any problems and eliminate the business damage the DDoS attack is causing.
That’s why after explaining the results of initial analysis to the client, it was decided to implement a custom DDoS attack protection and prevention solution.
Our developer created a Python script (custom DDoS protection and prevention software) that was meant to automatically detect the suspicious traffic coming from the web and causing extensive server loads, distinguish it from the activity of regular website visitors and notify the client or the designated people in such instances, who can make a decision whether it’s necessary to block certain IPs or ranges.
Besides, when blocking a certain range, we were risking to block regular users from accessing the website.
That’s why we decided to avoid harsh blocking but redirect the suspicious visitors to a separate page where they’re offered to solve the reCaptcha.
If they manage to do that, they are allowed to go back to browsing the site.
The script provides the client and his appointed people with the information about the range, as well as the web interface where certain IPs and ranges could be blocked or unblocked.
After our developer finished and tested the script, our DevOps specialist implemented it on client’s server.
The server configuration was altered as well to help the website handle higher loads a lot better.
The implementation part of the task was complicated by the fact that the client had a managed server, and the provider refused to give us root access.
Since that time, client’s server managed to withstand a few attacks without any problems.