How to increase the sustainability of websites and Internet applications against DDoS attacks

Do not expect that by connecting even the best DDoS protection service in the world, you can protect your websites and Internet applications from them 100%. And this is not about the shortcomings of the services, but about the fact that different Internet resources have different resistance to DDoS attacks, and to bring them to about the same level may require different efforts, means and deadlines.

In 2017, our company proposed to use the concept of protectability as a characteristic of DDoS resistance. We would like to briefly point out that by protectability we mean the property of Internet resources to be reliably protected from DDoS attacks with minimal expenditure of money, time and effort.

In this article we will discuss how to achieve security of websites and server components of browsers, mobile applications and services that interact with HTTP/HTTPS-based protocols via APIs.

The specifics of website protection

Modern websites are multicomponent online applications that provide many different Internet services to customers of different types: web browsers from different developers, mobile applications, and other online services that interact via both HTTP requests and APIs. These are typically complex, business-critical applications implemented using a variety of technologies, including modern technologies that were not widely used 10 years ago, such as AJAX, API, BFF, and so on.

An unpleasant side effect of their architectural and technological complexity is often high vulnerability to cyber risks, including DDoS attacks. Therefore, they need to be protected against attacks carried out at different layers of the OSI model: Network (L3), Transport (L4) and Application layer (L7).

In addition, so-called "smart" application layer attacks that go beyond the usual DDoS attacks have become more common in recent years - they aim to find and exploit vulnerabilities not in the HTTP/HTTPS-based protocols themselves, which are quite standard, but in certain types of interaction between server components of web applications with client software modules and with other systems (for example, with DBMS or data buses).

To protect web applications reliably and effectively, a high level of expertise is required. Therefore, we recommend choosing an anti-DDoS service provider very carefully and not looking for cheapness at the expense of the quality of protection.

What to do in the design phase of an Internet application

As you know, it is most difficult to correct mistakes made on the earliest stages of the product life cycle. In particular, remediating vulnerabilities in a software package that is being transitioned into commercial operation is several orders of magnitude more expensive than their timely detection and remediation early in the design phase. Therefore, information security experts strongly recommend that software products and systems, including websites and Internet applications, be developed in close cooperation with information security specialists - ultimately saving both time and money.

Usually, most mistakes are made in the design phase of Internet applications, which result in them being less well protected against DDoS. Here are some typical examples.

Sometimes Internet application developers get carried away with some of their arguments by setting up access to other Internet resources directly through their IP addresses, without using DNS - these addresses are integrated hard into the program code. These addresses are integrated hard into the program code. It can be extremely problematic to replace them, and it becomes almost impossible to protect them during a DDoS attack - for the provider protecting them involves additional difficulties and costs that they are unlikely to incur.

Cases when standard protocols are not used by default are not uncommon, for example, when an application uses HTTP but handles it in a very peculiar way: for one part of the interaction operations, the application adheres to HTTP, and for another part, it does not. As a result, it is almost impossible for an anti-DDoS provider to understand which traffic can be considered legitimate and which cannot. However, there is a way out of this situation, but it is unlikely that it is possible to look for it directly during a DDoS attack, when it is necessary to protect the application from it as soon as possible.

Note that this example points to another problem related to providing clear packet filtering rules - these rules are needed by the anti-DDoS provider to accurately detect legitimate traffic and block attacks.

Vulnerabilities that occur as a result of bad architectural solutions can be identified in a separate group. For example, the components of Internet applications are often so interdependent that in the event of a successful DDoS attack on one of the components, the others either become unavailable or fail to function properly, causing confusion among users. It would be right to reduce the interdependence between the components and provide for the possibility, if not to duplicate the access to the functions through different IP addresses from different subnets, at least to continue the work temporarily and partially replace the functionality of the attacked components. An Internet application created in this way is much more resistant to DDoS attacks.

Perform an audit of the application and its security, assess of the need for DDoS protection and plan its development

Before you start buying and connecting anti-DDoS services, you should know exactly what components and resources your Internet application has, which of them need to be protected, and what type and level of protection they require. A comprehensive picture of your application will help you clearly describe your security requirements and ensure comprehensive coverage.

Comprehensive coverage is very important because partial protection against DDoS attacks allows an attacker to find unprotected components and hit them directly. To avoid obvious loopholes in protection, you should take care to protect all layers where attacks can occur from DDoS attacks: Network (L3 according to the OSI model), Transport (L4) and Application layer (L7).

To create a sufficiently complete protection loop against attacks on Internet applications, you should use specialized services that include not only anti-DDoS functions, but also firewalls protecting Web applications (Web Application Firewall, WAF), which help protect applications from "smart" attacks. Since WAFs themselves are not designed to protect against high-intensity DDoS attacks, it is recommended to use WAF and anti-DDoS services as a bundle.

To systematically build application protection against DDoS risks, we recommend creating a roadmap for connectivity and deployment in the initial phase, as well as a medium-term strategy that takes into account your Internet application development plans, DDoS trends, and the dynamics of risks relevant to you. Since DDoS protection is one of the areas of information security, it is very important to harmonize your company's information security development strategy and DDoS protection improvement plans.

Do you need to keep it private?

If your Internet application provides financial services (e.g., for remote banking or payments, it must comply with the PCI-DSS standard) or enables other interactions with personal data, you should consider protection without disclosing SSL private keys.

By default, a more convenient option for protecting applications is usually chosen - protection with disclosure of SSL private keys. However, if the exchange of financial or confidential data is required, you should build protection without revealing private keys. This limits the ability to verify the clients of the application (how was it accessed, from where - from which browser or mobile application, etc.), but it enables more reliable protection of confidential data.

In organizations, there are often situations when some resources need to be protected without disclosing private keys, while for others it is not strictly necessary. In such cases, for the security of resources of the second type, it is better to combine protection with disclosure, as this is more efficient and can work with a single request.

In some cases, you can use a hybrid approach, using a certificate-key pair created specifically to protect against DDoS attacks (StormWall can do this automatically with the Let us Encrypt service, for example). This way you can hide a real private key and have the option to use protection with key disclosure.

Provide the anti-DDoS provider with clear options for filtering attacks

In order for the anti-DDoS provider to be able to clearly identify which traffic is legitimate and be able to accurately filter it out of all other packets without losing legitimate packets, it is necessary to give the provider clear ways to filter attacks.

As we noted earlier, it would be good to define these capabilities in the design phase of the application and explain in detail to the developers how they will detect legitimate client requests and reject illegitimate ones. It is very important to document these rules in detail to pass on to the anti-DDoS provider.

If the application is already in production, you should find an opportunity to discuss and clarify the intricacies of their work together with the security provider so that they understand how to filter your traffic.

It should be clarified that DDoS protection of applications that use non-standard interaction methods (this is especially true for mobile applications and software clients that access via API) usually works as follows. In the first step, the machine learning mechanism of the anti-DDoS service uncovers the scheme of the application, finding out important details such as the geography of the sources of legitimate requests, signatures of headers and interaction methods, the dynamics and intensity of requests, etc. The second step is to build a model of normal activity based on this model, against which all requests occurring in the traffic flow will be compared in the future. If these requests match the model of normal behavior, they are forwarded to the application for execution, otherwise they are blocked.

The key to this scheme is the ability to distinguish legitimate requests from fake ones. At the same time, the provider assumes that illegitimate requests can be generated by malicious bots in particular and should therefore be blocked.

And if you, as the owner or operator of the application, have not taken care of the possibility of uniquely identifying legitimate clients in advance, then the anti-DDoS provider can only take the suspiciously high activity of individual client groups or the presence of their IP addresses in the databases of unwanted addresses as a sign of the beginning of the attack. In this case, however, the ability of the anti-DDoS provider to detect malicious activity is severely limited: clever bots cannot make the application available without sending a flood of requests to it, but force it, for example, to generate heavy responses, the preparation and sending of which leads to performance or bandwidth exhaustion.

Prepare information for an Anti-DDoS provider

Based on the information gathered during the Internet application audit and the audit of its information security, it is necessary to prepare information for the anti-DDoS service provider that will help them build reliable and effective protection.

First of all, you need to specify for the protection provider a list of locations from which non-browser clients can access your application: mobile applications, services that access via API, AJAX, etc. - This way, the provider can more accurately configure the process of checking application clients and protect their requests from incorrect blocking.

In addition, it is useful to provide descriptions of the application architecture, the protocols used, and how the components interact and integrate with external systems. These descriptions should be detailed enough to allow the provider to clearly distinguish the traffic generated by the application components and the legitimate client modules that interact with them from everything else.

When the application is accessed by mobile applications or legitimate bots, the defender needs to know as much as possible about them: what user agents they have, what types and with what headers requests come from them, what legitimate locations they may originate from, how often requests come from an IP address during normal client activity. This data enables better filtering of traffic.

By the way, if the provider itself asks you for such details, it means that it is most likely quite professional. For comparison, there are quite a few anti-DDoS providers that just plug in their services and consider their mission accomplished.

Hide information about your application as much as possible from an attacker

A well-motivated and sufficiently skilled attacker will certainly look for an opportunity to carry out a successful attack, so it is very important not only not to give them an opportunity to do so, but also not to let them know whether the attack was successful. If this is not done, there is a risk that the information about your application will turn into a whole set of vulnerabilities.

Once an attacker finds out the IP address of your application or its component, they can target it, and just replacing the IP address, which is done when anti-DDoS services are connected, will not help protect it from DDoS risks, since IP addresses of Internet resources are easy to calculate - there are many tools on the Internet for that. For example, ones that allow you to track the entire history of changes to the IP address of a domain registered in the DNS. Others offer the possibility to get a list of all IP addresses associated with a certain domain. And so on. IP addresses can also be found in the headers of SMTP e-mail packets that your application probably exchanges. If the hostname of the server where the application is installed matches the name of the website, SSH will display it in its banner, for example, and with the help of simple tools an attacker can determine its IP address. Ideally, the IP address of the real server should not be visible from the outside, neither through mail headers, nor through open ports or other services.

Disable unused services and close unneeded ports

When checking the Internet security of an Internet application, it is very useful to determine which services and ports are used and which are not - these must be closed. Otherwise, the risk of an attack on them will remain, and such an attack will most likely be very unexpected for both you and your anti-DDoS provider.

Besides, once the protection is connected, it is very important to allow access to the website only through the IP address provided by the anti-DDoS provider and block access to all other IP addresses by configuring the firewall properly - this will prevent DDoS attacks from bypassing the protection services.

Optimize server components

Optimization is necessary to ensure the resilience of your Internet applications against weak DDoS attacks. The fact is that protection services cannot always guarantee 100% cleaning of traffic from inadmissible packets, and in this case, some of the packets, even if only a small part, may leak through the filter. However, if the attack is very strong (for example, if it reaches tens of gigabits per second), then one percent of the packets may be enough to make your application inaccessible. To prevent this, the application's server components and the infrastructure on which it is deployed must have sufficiently high performance. The goal of optimization is to increase this.

The further optimization steps depend on whether you have access to the server on which the application is deployed. If you not only have access, but can control it completely, you should optimize the operating system's network stack to increase the server's ability to process incoming requests. In particular, you need to pay attention to the parameters that determine the server's performance when working with popular web servers and CMS engines, as well as the network stack. In addition, you need to take care of optimizing the performance of DBMS if your Internet application uses it.

If you have deployed the application on a hosting server or in a public cloud, you should discuss with the technical support of your cloud or hosting provider the possibilities for optimization and performance improvement. You might want to consider switching to more powerful hardware or to virtual machines with a large amount of resources - this measure will not only increase your application's resistance to weak DDoS attacks, but also allow you to better handle peak loads.

Connect protected DNS services

When building protection against DDoS risks, it is of course necessary to take into account the possibility of attacks on the DNS, because if they are successful, users will not be able to access your application, or they will be very unstable. It is necessary to check whether the DNS services to which your application is connected are protected against DDoS attacks, and how powerful and reliable they are. We recommend connecting to at least two DNS service providers, and at least one of them should be protected from DDoS attacks at all levels - L3/L4 and L7. Such DNS services can be found both at anti-DDoS providers and at companies specializing in DNS services. One of the DNS services can be connected as a primary service, the other as a secondary service.

Just in case, we remind you that StormWall has a wide arsenal of methods to filter DNS traffic at the application level.

Regularly check the protection

Performing regular stress tests is necessary so that you can verify the functionality and effectiveness of your protection against DDoS attacks. The fact is that both the strength and intensity of attacks are increasing year by year. The technologies and tools for carrying them out are constantly improving - attackers not only increase the strength of their botnets, but also invent new types and methods of attacks. In addition, your applications are also gradually changing - versions are likely to be updated regularly, so they also need to be regularly checked for their resistance to DDoS risks.

Stress tests are typically used for security testing - they help assess your application's resilience to weak DDoS impacts and simulate its behavior during an attack. It is important that stress tests are not performed formally, but carefully, so that they cover not only almost all externally accessible components, but also all their services. Such comprehensive tests help to identify and eliminate bottlenecks and vulnerabilities in the application in time, before they are discovered by intruders.

Moreover, it makes sense to perform the tests not only on normal working days, but also on weekends, holidays and before public holidays, when the probability is quite high that the technical support of the anti-DDoS provider is relaxed and does not expect massive attacks. At the same time, it is possible to check the reaction of the technical support to your reports about attacks. For example, if a protected resource becomes unavailable, StormWall technical support will contact the owner of this resource regardless of whether there is a DDoS attack on it at the moment or not.

Build processes to protect against DDoS attacks

It is very important to ensure that protection against DDoS attacks is, firstly, not limited to one-off events but is built up in the form of a process and, secondly, that it is closely integrated with other information security processes.

As both external cyber threats and applications change dynamically, it is necessary to achieve systematic implementation of measures that ensure protection, from systematic controls and meetings with the anti-DDoS provider to comprehensive audits of applications and audits of their information security. Ensuring that the effectiveness of protection against DDoS attacks does not diminish requires consistent cooperation from both your own professionals and the anti-DDoS provider's staff. You may also need help from representatives of your cloud or hosting provider if you use their services.

In addition, it is necessary to closely integrate the DDoS protection process with other information security processes, including monitoring and auditing, as well as vulnerability management, configurations, incidents, etc.

And since there are no trends yet to reduce DDoS risks, it is necessary to be prepared for long-term work to ensure protection against them.

increase-resistance-to-ddos-attacks

Final checklist

Lay the foundation for security at the design phase
Perform an audit of the application and its security, assess of the need for DDoS protection and plan its development
Assess whether protection without disclosure of private SSL keys is required
Provide the anti-DDoS provider with clear options for filtering attacks
Prepare information for an Anti-DDoS provider
Hide information about your application as much as possible from an attacker
Disable unused services and close unneeded ports
Optimize server components
Connect protected DNS services
Regularly check the protection
Build processes to protect against DDoS attacks