So in this post i'd like to analyze what are the potential attack areas and what ideas are there to resolve it.
Lets exclude the attacks that use specific vulnerabilities of a product to deny the service and focus on brute force attacks that flood the target with excessive valid service requests.
Statement of the problem
As the attack is using valid service requests, it's hard to distinguish them from normal user requests. This means that whatever action is taken, normal user requests have to be served in reasonable time.
Secondly the service providing solution has to be capable of dealing with normal service requests. This means, it has to be elastic enough to scale up if necessary to serve all incoming requests.
The most common bottlenecks (on the side of a customer or enterprise) are:
- Server resources - system(s) that provide service might not have necessary resources to deal with user requests (no network bandwidth; not enough memory; CPU over-utilized or other)
- Firewall resources - filtering and inspection as well as tracking of all the active flows need resources as well (not as many as a server).
- Internet router - although not very probable, but still router might not be able to deal with that many packets per second
- Internet link - the most common problem, where the link to the ISP is not sized properly to deal with growing user service demand, might lead to degradation of service response time.
Mitigation of these bottlenecks is the key to deal with DoS attacks, and while scaling is always an option, it might not be the most efficient one. Plus the costs grow exponentially, so at certain point of time, it becomes important to choose an alternative solution that scaling.
Potential solutions
Excluding the possibilities of re-engineering the application (providing the service) or buying bigger hardware or upgrading the internet link speed to deal with potential distributed DoS attacks (which could be 10Gb/s or more nowadays), let's see what ideas there are.
There are 3 functions that are part of each solution:
There are 3 functions that are part of each solution:
- Detection (distinguishing what is a valid service request and what not)
- Protection (blocking invalid service requests without impacting valid ones)
- Service (providing the actual service)
Each type of solution differs based on who is responsible for these functions.
In-house DDoS prevention
This solution uses in-house detection capability to spot the DDoS attack and then request support from the internet service provider to block the source IP address(es) for limited amount of time.Having a good security event management system with all the possible event sources helps to identify attacks early and allows to provide much more reliable response (false-positives mean lost clients).
Response can be automated by using provider's service API or standard routing protocols (like BGP Flowspec) for blackholing the source, or it could be manual by reporting abuse to the appropriate ISP contact point.
There are many vendors who provide such solutions that include DPI detection as well as signalling, but there also needs to be a contract in place with service provider to support such service.
This table should summarize the location of the DDoS protection functions:
| Function | Customer | DoS protection provider |
|---|---|---|
| Attack detection | Most of the detection | |
| Attack prevention | Signaling only | Most of the protection |
| Actual service | The service is provided by customer |
Service gateway
Principle of this solution is pre-filtering all the requests via a gateway service, where only valid requests fulfilling specific set of rules (like max 10 requests per client; valid session should last longer than 1 minute; etc.) would be forwarded to the real server.
Depending on the rule-set, customer's server would receive only valid requests and would not have to deal with excessive traffic.
In this case, the location of the detection and prevention functions is at the service provider, so all the traffic ends there. But the responsibility of the service operation is still up to the customer.
| Function | Customer | DoS protection provider |
|---|---|---|
| Attack detection | Most of the detection | |
| Attack prevention | Most of the protection | |
| Actual service | The service is provided by customer |
It's important to note that these gateways are either generic (for IP or TCP packets) or highly specific for certain type of application (mail gateway; dns gateway; web application firewall;..).
CDN service
Although this is highly specific solution and requires some cooperation with the service provider, for common services like data or content distribution, this could be very effective.
Content distribution network (CDN) providers have large infrastructure geo-distributed and built for huge traffic flows. For some of them even large distributed DoS might look like minor increase in the normal traffic level.
Principle here is quite simple: customer uploads all the data to the CDN service provider, where it would become accessible to the clients.
This solution moves all the functions to the external service provider, who has to deal with the attacks and guarantee service to the customer.
| Function | Customer | DoS protection provider |
|---|---|---|
| Attack detection | Most of the detection | |
| Attack prevention | Most of the protection | |
| Actual service | Service is provided by CDN |
Conclusion
Despite having lots of great tools that promise miracles in preventing DDoS attacks, it always comes down to a specific solution for specific customer. Whether rules need to be tailored and constantly adapted for the first type of solution; or gateway needs to be adjusted to deal with non-standard protocol behavior; it all comes down to the skills of the engineers dealing with the solution.
In hands of capable engineer, it would make the promised miracles come true; in less capable hands it can make the service very unreliable or vulnerable to distributed DoS attacks.
