An HTTP DDoS attack is a malicious attempt to overwhelm the resources of a web service, or an in-line network intermediary device, to prevent it from serving legitimate requests from legitimate users. Bad actors launch these attacks leveraging a large group of devices, called a botnet, so they can send a high rate of requests and thereby create a debilitating load on them.
The amplitude of an attack is measured by the total request rate received by the victim web service. This rate is a result of the size of the botnet and the malicious request rate from each one of its bots.
Each malicious request may look legitimate, or at least might not match a typical web application attack. Differentiating the malicious requests from legitimate ones to detect an HTTP DDoS attack can usually be done by:
Fingerprinting source clients to differentiate malicious from legitimate traffic can be done using web challenges, triggered by the attacked web service itself or a WAF. Incriminated clients can then be blocked. These web challenges can include:
The problem is bad actors have figured out that traditional tooling can recognize these automated, high-rate attacks, and they’ve adjusted their method of attack. To avoid detection by traditional security tools, bad actors slow down their rate of attack, staying below the rate-limiting thresholds. But if they reduce the speed of attacks, how can they still compromise the web service? The answer is simple math. They reduce the request-sending rate of any given single bot, to keep them undetected, but they add more and more bots. As a result, the total request rate into the web service remains high – high enough to compromise service availability.
So what’s a company to do? How can you protect yourself from these increasingly sophisticated API attacks? You need technology that can stitch together the traffic patterns of seemingly disconnected “users” to spot this kind of attack. Today’s WAFs, while more intelligent than their peers of 20 years ago, still see transactions and “users” in isolation and cannot see such patterns in aggregate and over time.
To thwart this kind of attack, you need perspective – or context – across a longer timeframe and across 100s of “users” and API interactions. That’s what the Salt platform does.
WAFs can track the number of requests from a client in timeframes of seconds and minutes, whereas the Salt Security API Protection Platform tracks client requests over much longer and more diverse timeframes and durations. With its cloud-scale big data platform and artificial intelligence (AI) and machine learning (ML) algorithms, Salt can easily identify requests that differ from legitimate requests. This dynamic anomaly detection empowers users to quickly spot malicious low-rate requests with a very low rate of false positives.
A few weeks ago, a Salt Security customer notified our SOC Group that one of the company’s web services was being exhausted by an unknown threat. At the same time, the Salt platform detected high inbound traffic. Using the Salt platform, our analysts detected an HTTP DDoS attack against an authentication (aka login) endpoint launched by a botnet that included thousands of bots. Because each individual bot would send only one request a minute, the cloud WAF deemed the traffic legitimate and let it pass through. As a consequence of the cumulative load, however, legitimate users could not authenticate to the web service. The Salt API discovery algorithms also immediately detected the following anomaly – that the malicious requests missed required payload fields. The web service responded to those invalid requests with 400 Bad Request response code, and the Salt platform detected it as an abnormal response code from this API endpoint, which helped further differentiate the bot traffic from legitimate authentication attempts.
Our analysts reported these findings back to the customer’s security engineers, and they activated an already defined integration between Salt and the cloud WAF to block the source IPs of the entire botnet. With this automated blocking in place, the load on the web service dropped significantly, and legitimate users were able to authenticate once again.
Salt customers have the choice to enable automated or manual blocking when the Salt platform detects an attack. Customers tend to start with manual blocking, giving them the chance to investigate the identified attack before taking action. This on-demand option is slower but avoids blocking a legitimate user in the case of a false positive.
Upon seeing the same attack repeated, many customers often then choose to set the Salt integration with their inline device into auto-blocking mode. This approach effectively turns the Salt out-of-band deployment (which avoids any application impact) into an inline protective device, immediately stopping the attack traffic. Having this flexibility means the Salt platform supports a range of customer approaches and adjusts with them as they move through their API security maturity model.
WAFs provide helpful protections against a lot of traditional attacks that are still prevalent. However, because of their proxy architecture, they cannot correlate activity across users and across time to detect today’s sophisticated API attacks. Relying on WAFs alone for API protection is insufficient and leaves companies vulnerable. We here at Salt do not claim that our platform is a DDoS protection solution. However, by leveraging our anomaly detection capabilities, we can catch attacks your WAF will miss. And we can integrate with your WAF to provide the inline blocking needed to protect your services.
To learn about the Salt award-winning API security platform and how it can help you discover and secure both in-house developed and third-party APIs in your environment, contact us or sign up for a personalized demo.
By having Salt Security available on all three cloud marketplaces, we deliver on our promise to provide customers with the industry’s most comprehensive API security solution.
In general, most API data breaches are usually the result of one or a combination of four different attack scenarios.