Protection against DDoS attacks: do’s and don’ts

The wave of DDoS attacks that flooded the Internet resources this spring and summer made everyone aware of the relevance of this type of cyber threats and removed the last doubts about the need to protect against them. The question is how to properly protect yourself from DDoS attacks and what mistakes to avoid.

The analysis presented here is the result of observations based on nearly a decade of StormWall’s practice in the field of DDoS protection. It will be of great use to anyone seeking to increase DDoS resistance of their business in a way that is cost-effective and reliable. And while companies at all stages can apply these practices, they will be especially valuable for those who are just starting to build their Internet systems, when there is still an opportunity to design with DDoS protectability in mind.

The basis of the basics is protectability

To keep an Internet resource (network, server, website or application providing mobile or web services) available not only in “attack free” time but also when it is under attack, it is often not enough to simply connect DDoS protection. And the right settings do not always help either. The fact is that different resources have different levels of resistance to DDoS attacks. This depends not only on the technical characteristics of the resource, but also on how its owners or those responsible for it cooperate with the providers of solutions for protection against DDoS attacks.

In 2017, we wanted to come up with a sort of framework that companies could follow to ensure a high resistance to DDoS attacks. We decided to call it “DDoS Protectability,” and the term stuck.

In our understanding, security is the ability of Internet-connected resources to be effectively protected against DDoS attacks with minimal cost, time, and effort. In this case, we interpret efficiency as the ratio between the length of time that the consequences of an attack do not affect the availability of resources and the total duration of the attack. Ideally, this ratio should tend toward one. A lower value indicates that the availability of the attacked resource has become critically low at a certain point in time.

Protectability is the immunity of a resource to the effects of DDoS attacks: the higher it is, the more effective its protection can be. On the other hand, a weak immunity cannot save the resource – it will certainly be unavailable for some time.

To ensure the safety of the resource, you need to solve four important tasks:

1. Provide the attacker with as little information about the resource as possible: to an attacker, your resource should be as much of a “black box” as possible.

2. Provide as much information as possible to the DDoS protection provider so they understand what exactly needs to be protected, what features your resources have, etc. 

3. Provide the provider with understandable functions for filtering attacks (especially for protecting applications).

4. Ensure reliable and stable operation of the resource during the attack. You need to be aware of the fact that, firstly, the attack may occur for some reason on the unprotected components of the resource. And secondly, you must always expect that some part of the attack, no matter how small, can break through DDoS protection and significantly increase the load on the resource.

The first step matters

Your first step, which should be done before purchasing anti-DDoS services, is to make a list of the resources you want to protect and a detailed description of the levels of protection you need. You need to think thoroughly about which websites, web applications, mobile device services, as well as servers, networks, IP addresses and other resources could be exposed to DDoS attacks and therefore need to be protected.

Otherwise, it can backfire, as in the case of our client, who urgently began to connect protection only when they realized that they could not resist a strong attack. And then it turned out that their specialists had neither a list of all Internet services at hand, nor certificates and private keys to them. While the customer was desperately trying to find or rebuild a list of their services, their network was down. And since they could not log into the network, they could not find out which of his resources were the target of the attack.

You also need to determine what kind of protection your resources need: is it enough to filter network-layer (L3 according to the OSI model) and transport-layer (L4) packets, is it necessary to analyze application-layer (L7) traffic transmitted over HTTP/HTTPS protocols or on top of it, which resources can be protected with SSL private key disclosure and which are not allowed.

A detailed analysis of protection needs will help avoid many problems caused by DDoS attacks.

Here is an example of what insufficient investigation of these needs can lead to. One of our customers has anti-DDoS services connected not only from a major international provider, but also from their Internet provider, but these services failed to protect the company from DDoS attacks last spring. When we started to understand at what levels the protection is provided, it turned out that there is protection against packet floods at the L3 and L4 levels, but no protection against attacks at the L7 level – this was the reason for the unavailability of Internet applications that turned out to be the target of the attack.

Special requirements for the processing of personal and financial data

If your resource is a financial service or an application that provides for the exchange of confidential data, you will most likely need to use protection without revealing the SSL private keys. It is especially necessary for systems that must comply with the international payment system standard PCI DSS.

At the L7 level, private key disclosure protection through SSL is typically used because this method provides numerous opportunities for interactive checks on application customers (those who have made a request to it) and facilitates the decision of whether it is safe for an application to deal with a particular customer.

However, if the application exchanges financial or other confidential data, you must use protection without exposing private keys. In this case, the application’s ability to perform customer controls is severely limited. Without going into details, let us say that to assess legitimacy in such scenarios, an analysis of system logs for signatures is used, as well as a more complex analysis with building a behavioral model of application clients based on machine learning: a model of normal behavior is built based on the data collected in the system logs, and a noticeable deviation from it is perceived as a signal alert. When such a signal is received, traffic associated with a suspicious client is blocked.

Sometimes it is useful to use a hybrid approach, where a separate pair of a certificate and a key created specifically to protect against DDoS attacks is used. In this scenario, it is possible to hide the original private key, but at the same time use protection with disclosure – StormWall offers this possibility.

Not all security services are equally useful

After making a list of all the resources you need to protect and determining how to protect them, you need to select a high-quality, reliable anti-DDoS provider with a good reputation that not only has sufficient expertise in providing protection services, but also advises on building defenses against cyberattacks and how best to connect anti-DDoS services.

Typically, companies that do not specialize in providing DDoS protection services simply sell access to the web interfaces of some solutions or devices without really understanding how they work. All the other problems are associated with this: the protection is usually offered only “on paper”, but in reality it either does not work at all or proves to be ineffective.

Similarly, if the operator of a commercial data center, cloud or Internet provider resells the anti-DDoS protection services of its partner. There is nothing wrong with this. The only question is in what quality and to what extent the support is provided in the event of an attack: do you have a direct connection to the anti-DDoS service provider and its support service, and does the hoster or Internet provider that sells anti-DDoS services directly have its own DDoS protection specialists.

But what can we say about hosters and Internet service providers… Even specialized DDoS defenders have a very different level and quality of their services. For example, not every anti-DDoS provider is able to adapt its protection to the characteristics of your Internet resources. Therefore, clarify in advance to what extent they are ready to adapt to your requirements and specifics.

Not all anti-DDoS providers also provide access to protection settings, and for those that do, the capabilities of these settings can vary widely. It makes sense to find out the capacity of the provider’s filtering system – 100, 200, 600 Gbps or anything else – and check whether the filters themselves can withstand a serious performance attack.

It is very important to understand what kind of protection a particular provider offers. Often (especially if the protection is offered in addition to the Internet service) it is protection at the L3/L4 levels of the OSI model. However, it is basically unable to protect websites and applications from attacks by HTML bots. If the attack originates from multiple computers, some abnormal activity can be detected at the batch level, which must be filtered out. However, if the number of attacking bots is in the thousands (such botnets can literally be rented for pennies), then no L3/L4 level protection can filter out such an attack. Nor should it. To defend against such attacks, a full-fledged L7 level protection is required, which allows analyzing every HTTP request, performing some additional checks, studying system logs, examining them and finding out what kind of requests are made, what kind of activity is observed, drawing conclusions and making decisions based on those conclusions.

You also need to make sure that the anti-DDoS provider knows how to filter the most critical types of DDoS attacks for you, and that it has the necessary methods and tools to successfully stop the illegal traffic. For example, we know that not all DDoS defense systems are capable of filtering UDP traffic. 

Difficulties often arise when protecting UDP applications because it is harder to filter UDP traffic than TCP traffic. To more accurately determine whether the next visitor to such an application is legitimate, the anti-DDoS provider must have a thorough understanding of the protocol of its interaction with clients. They can set up a pre-approval process to assess legitimacy. Or, there may be clear rules for interaction with legitimate clients that the traffic filter can use to determine that this client is legitimate. Sometimes it is also possible to assess legitimacy using a TCP service.

In addition, they often become active only when the customer’s resources are no longer available. Some defenders that detect the attack simply block UDP traffic without even attempting to filter it. Many anti-DDoS providers are unable to filter DNS traffic at the application layer and so on.

It is also very important to understand what options the anti-DDoS provider offers for operational communication with customers: does its technical support service have a phone, a chat, a system for accepting requests (tickets) or other channels through which you can ask a question and receive a quick response. This is also very important, because the worst thing that can happen during a DDoS attack is a long wait for a response, lasting hours or even days (for example, if the attack occurred on the eve of the weekend).

All these nuances must be discussed and worked out in advance with the provider before signing the contract. It is desirable that they took the time and advised you: suggested options for more effective protection of your perimeter, told you what to consider and what protection methods to use to secure certain components of your Internet resources, etc.

Moreover, do not forget to systematically check the functionality after the protection is connected, for example, using stress tests – this will help to get at least a general idea of what can happen to your service in case of a real attack. Particularly, it is important to understand how the support of its protection services works and what happens if the attack starts on Friday evening or Sunday morning, when most specialists are not at work, whether someone from the provider will help you in this case, etc.

Stress testing also helps to assess the stability of your resource in case of a weak DDoS attack. It is not certain that the provider will be able to filter out 100% of all unauthorized traffic. And if it cuts off 99%, the remaining 1% of a strong attack can easily make your resource unavailable if it has insufficient performance and is unable to handle illegal traffic.

What should not be allowed to the attacker

In practice, it often happens that when building protection against DDoS attacks, a certain number of unclosed gaps remain. By analyzing them, an attacker can learn enough about your resources to carry out a successful attack, even if not on the first try. Sometimes they even manage to understand the characteristics of your infrastructure better than you do.

Exploitation of resource vulnerabilities is especially characteristic of DDoS attacks against server components of mobile and Internet applications. Connecting the protection with a change of IP address to the address of the anti-DDoS provider, firstly, the previous IP address of the website may already be known to the attackers, and secondly, if desired, it can be easily found through various resources. One of them (which we do not mention for ethical reasons) allows you to track the entire history of changes in the address of a particular IP domain. Through another, you can get a list of all IP addresses to which that domain is connected. And so on. The actual IP address can also be determined by analyzing the packet headers of the SMTP e-mail protocol that your website sends, for example, when registering users, sending letters and other similar operations.

Another common mistake is the “partial approach” to building DDoS defenses, where one part of the resources is covered and the other part is not. Attackers can easily find all your resources and identify among them the unprotected ones vulnerable to DDoS attacks. You can be sure that these resources will be found and attacked sooner or later if they have the right motivation.

If you have your own autonomous system, your own prefix, if you use BGP, then that network needs to be protected as well. A DDoS attack can hit an unprotected IP address, and even a firewall and an ACL filter will not protect against an attack with a capacity of, say, 400 Gbps. This is a very real threat! At the end of last year and the beginning of this year, StormWall specialists observed a capacity of 1.2 Tbps almost every day. Such an attack can put an excessive load not only on your resources, but also on your provider’s entire network. So, if you use BGP protocol, you need to turn on protection over BGP.

Of course, the possibility of attacks on the DNS must be considered. Be sure to check how securely and reliably the DNS services your resources are connected to are working. When during the massive attacks last spring a major domain name registrar began to work unstably, many of its customers greatly regretted that they had not arranged for a connection to another DNS service that was reliably protected against DDoS attacks. Similar services are offered by anti-DDoS providers and companies that specialize in providing DNS services. It is best to connect to at least two DNS service providers. And it is highly desirable that the providers of at least two such services offer their DDoS protection.

If the DNS server is located in your own network, then this network should be protected via BGP. To do this, you need to find out from the anti-DDoS provider if it can filter attacks on DNS. If so, tell them the addresses of DNS servers so that he can configure traffic filtering for the corresponding protocol on them.

A good Anti-DDoS provider should use multiple methods of filtering DNS traffic at the application level, from simple restrictions on the number of requests to the domain, requests from an IP address, etc., to convert DNS traffic to TCP traffic and other methods specific to DNS servers.

In a word, it is useless to enable DDoS protection only partially. It is necessary to take a comprehensive approach and protect the entire chain through which traffic flows, starting with DNS and ending with application server components, and make sure that each of your resources is sufficiently protected.

Do not leave “rakes”!

Often, protection against DDoS attacks seems to be built, but due to ridiculous flaws, it turns out to be ineffective. These mistakes can be cartoonishly comical, and usually stem from simple carelessness. Like scattering your tools around the garden and eventually stepping on a rake. That’s what we started calling them in StormWall: “rakes.”

Here is an example that shows why you have to be very careful when accessing Internet resources directly through the IP address, bypassing the DNS. The attack on one of our customers was made through one of the IP addresses that the customer’s applications accessed directly, rather than through a domain name. It is extremely difficult to replace such an address, as it is firmly integrated into the applications. And it is almost impossible to protect it during a DDoS attack, because for that you would have to convince the provider of this rented IP address to secure its entire network /24 (that is 256 addresses) with anti-DDoS services. However, the provider will certainly not do that so quickly.

Another unpleasant case: applications are written to use the HTTP protocol, but adhere to it in their own way. For example, one of our client’s banking applications performed authorization over HTTP, using standard methods to do so, and then started sending a data stream without adhering to the protocol. Any normal DDoS protection that distinguishes between HTTP protocol methods will miss such requests. This problem is solvable, but its solution takes time. And if the DDoS attack has already started, every minute is precious.

Some clients found outdated systems that did not support the SNI protocol (an extension of the TLS computer protocol) and did not transmit in the headers the IP address of the HTTP host to which the request is sent. This problem can also be solved, but again, you need to take your time.

Another “encyclopedic” problem: often a device (e.g., a router, firewall, or load balancer) with low performance is located at the network boundary. Very often Cisco ASA firewalls and MikroTik routers are among such devices – they cope well with the usual load, but cannot deal with even a weak flood and block any network connection they pass. In the event of an attack, the device’s processor will be at one hundred percent capacity, making it almost impossible to understand what is happening to the device during the attack. And if filtering based on SPI (Stateful Packet Inspection) technology works on these devices, the situation is even worse.

It is not so easy to resolve situations where a customer uses DDoS protection from their transit provider, as it can kick in at an unpredictable time. One of our customers was using upstream routing and DDoS protection from a major mobile carrier, and it didn’t work for them. Any worthwhile Anti-DDoS provider will run their upstream channels through an operator’s network anyway, filtering through it and only sending cleared traffic to customers.

When even a weak attack starts, the operator fixes it (since the provider still has the same settings) and starts intercepting (hijacking) traffic to the /32 IP address, which loops and goes nowhere. As a result, the customer’s banking application becomes unavailable. The solution to this problem is usually very simple: just ask the operator to disable DDoS protection for this customer. Since several organizations have already faced such a problem, it is likely to become quite common in the future, as many operators and vendors now offer DDoS protection services at one level or another.

The most difficult problems are those that were originally set

Typically, customers request DDoS protection when their applications have already been built and deployed and are in commercial operation. And at that point, it often turns out that protecting them is not so easy, because neither the customers of the applications nor their developers originally thought about the risks associated with DDoS attacks and initially designed these applications poorly.

Here is an example – a typical, but far from exhaustive, spectrum of application development- related mistakes. A massive wave of requests – about 10,000 per second – suddenly rolled into the remote banking service (RBS) application of one of the banks, which normally receives an average of 500 requests per second, and 200 requests per second came from each source IP address, and they all received a 401 Unauthorized response from the application (“access denied”). Suspecting the beginning of the attack, we started blocking the requests. Unexpectedly, the bank contacted us asking why legitimate visitors were suddenly blocked. We tried to understand the situation and contacted the developers, who explained that the application had started to unload and that this wave of requests should be considered normal behavior. We were surprised: if this behavior is considered normal, what could an attack on this application look like? And how can we distinguish normal activities from those initiated by attackers if the application does not mark itself in any way – neither by special methods, nor by locations, nor by headers, and what if the traffic of this RBS application is no different from what a bot would generate?

Usually, DDoS protection of mobile applications works as follows: first, a diagram is created of how the application works (what locations visitors come from, what headers and methods it uses, with what intensity, etc.), then a model of normal interaction is created based on this diagram, against which all requests made to the application are compared. If there are no signs to distinguish legitimate requests from those generated by bots, then it becomes very difficult to detect illegitimate requests from bots.

We have also come across many other mistakes made in the design phase of applications and services, due to which software products turned out to be poorly protected, and it cost a lot of money, time and effort to reduce their vulnerability to DDoS attacks. The solution to the problem is obvious: customers and application developers should involve information security specialists in their projects, including DDoS protection, from the earliest stages of their products’ development. The information security industry has been saying this for decades…

Once more on protectability

In conclusion, we will once again describe the most important tasks to ensure safety, but in more detail and with the help of specialists.

First, you must provide the attacker with as little information as possible: if possible, hide the details of your architecture and the protocols for interacting with your resources from them, so that the attacker can neither identify vulnerabilities in them, nor assess possible damage from exposure to those vulnerabilities, nor identify possible attack targets, nor understand how successful the attack was, nor hack your systems to obtain the necessary information or take control of their individual components. If an attacker determines that the attack has failed, they will (with proper motivation, of course) begin to look for vulnerabilities in the system they are targeting and attempt to identify vulnerabilities in the infrastructure or application in order to organize a more effective attack.

Second, you should provide the DDoS protection provider with as much information as possible. They need to fully understand the architecture of your resources and the rules by which they interact with each other and with external resources. He also needs to know which services (website, DNS, VPN, etc.) are attached to which IP addresses and be able to tell how well your resources are performing at any given time. If you have UDP applications, you need to specify where and how they are deployed, what they do, and how.

Third, it is necessary to provide anti-DDoS capabilities that are understandable to the provider to filter attacks – this is especially important for application protection. It is highly desirable to have these features built in – they will allow the protection provider to almost unmistakably distinguish the behavior of legitimate visitors from the behavior of bots based on specific formal characters. The solution to this problem will largely determine the fundamental effectiveness of the protection of your applications.

Because if among your resources there are APIs and mobile applications, for example, and you have not taken care in advance about the differences between their interaction with legitimate customers and the behavior of bots, then the only thing that distinguishes the attackers’ requests from others is a suspiciously high activity and (possibly) the presence of bots’ IP addresses in the databases of unwanted addresses. And if the bot’s activity does not exceed that of a regular visitor, no DDoS protection provider will be able to identify and block it.

As we have said before, it’s ideal to specify attack filtering capabilities when you build an application. To do this, you need to tell your developers in detail how you plan to distinguish legitimate from illegitimate clients when discussing the general outlines of the future software product. This knowledge must be documented, stored and then passed on to the DDoS defender.

If your application has been in productive use for a long time, you can go the other way: take your time and work with the anti-DDoS provider to find out how your application works. A detailed analysis of its behavior will help the provider create a protection profile that takes into account the characteristics of this application as much as possible.

Fourth, it is important to ensure a sufficiently high resistance of your resource to DDoS attacks. To do this, you need to determine in advance how the components of your resource depend on each other and what vulnerabilities it has.

The simplest example: the website works with a mobile client application that retrieves currency rates or other data from it. What happens if the website is unavailable? Will there be problems with the mobile application then? Ideally, it should no longer display the current exchange rates on the screen or respond in some other way, but generally continue to function.

In addition, it is necessary to provide capacity redundancy and achieve resilience of resources to weak attacks. This is especially important when asymmetric protection is used. As mentioned earlier, when filtering some types of DDoS attacks, some traffic passes anyway. And if there is a strong attack, say at 40 Gbps, then cutting off 99% of the unauthorized traffic will result in a DDoS attack with a capacity of 400 Mbps falling on the protected resource. Whether it can withstand this is a big question. For this to be possible, your router, firewall, and server must have sufficiently high performance.

By the way, separating different functions and services of the resource to different IP addresses helps to better configure the protection rules: websites and HTTP applications – on some, UDP applications – on others, services providing a pull scheme – on third, and so on. And it is better to block unused network services altogether to prevent the possibility of DDoS attacks on them.

The Golden Rules of DDoS protection

Finally, three simple rules that will help you build a reliable line of defense against DDoS attacks.

1. Get advice from expert anti-DDoS providers who will help you make the right decisions to organize the protection of your infrastructure. This will significantly reduce your business risks.

2. Start discussing measures to protect against DDoS risks as early as possible – preferably during the design phase of your future systems and applications. This will help ensure the resilience of your resources against DDoS attacks.

3. Harmoniously integrate protection against DDoS risks into your organization’s overall information security strategy. Many of the principles that the information security industry has developed are ideally suited for DDoS protection. But of course, it also has its own specifics regarding the characteristics of DDoS risks.

Conclusion

As we have noted many times, security is a key indicator on which the stability of Internet systems and resources against DDoS risks fundamentally depends. Ideally, the protectability should be established in the design phase of Internet systems – the right steps in this phase will enable high resistance to DDoS and, when the protection is enabled, will provide a favorable ratio of efficiency and cost in defending against this type of attacks.

And, of course, you must understand that ensuring security is a multi-faceted task that affects all phases of the Internet systems lifecycle. To ensure security, many aspects need to be thought through, because many miscalculations and mistakes made during development reduce the effectiveness of protection against DDoS attacks and increase the cost of subsequent measures required to achieve a high level of DDoS resistance. In order to deal with the whole complex of difficult issues related to ensuring the security of Internet systems and resources, we recommend that you do not rely on your own experience, but actively involve professional companies specializing in protection against DDoS risks.