Mitigating Denial of Service (DoS) Attacks
Security guidance for public sector organisations wishing to mitigate Denial of Service (DoS) attacks against their digital services.
Note: This publication is in ALPHA. Please send any feedback to the address platform@cesg.gsi.gov.uk.
Introduction
About this guidance
This ALPHA guidance describes some of the most common methods used by groups or individuals wishing to disrupt an online service, and suggests some possible mitigations. It is particularly relevant for public sector organisations operating at OFFICIAL.
It is not a comprehensive list of Denial of Service (DoS) mitigations; rather organisations can use this guidance to inform the type of DoS mitigations to implement. This will vary based on the technologies used within their services.
What is Denial of Service (DoS)?
Denial of Service (DoS) is a term used to cover a wide range of techniques used to prevent legitimate users of a service from gaining access.
DDoS refers to a Distributed Denial of Service attack, where several computers take part in a simultaneous attack on a service.
How do DoS attacks work?
It is unlikely that one attacker acting alone could generate enough traffic to exceed the bandwidth of a service’s connection or exceed its processing capability. Such an attack should also be simple to identify and counter where appropriate logging is being carried out.
However, by distributing the DoS attack across many computers, the collective bandwidth and processing power of the group can be harnessed to exceed the capacity of the victim. Computers used to attack a target are often members of a botnet (a group of computers running malware usually under the control of a third party) and are termed ‘zombies’ (because the user of the computer is often unaware of their participation). The computers are often infected with malware which allows them to be controlled silently, thus hiding the true identity of the attacker.
In addition, groups of malicious users may volunteer their devices to become part of a botnet using freely downloadable tools.
Who is behind DDoS attacks?
A number of individuals and groups carry out DDoS attacks. This includes:
- state sponsored groups, often with aims aligned with the political goals of their sponsoring state
- hacktivists who are politically motivated by a desire to protest against a government policy, regulating body or a corporate entity
- criminal gangs who use DDoS as a method to extort money from a service owner through the threat of lost revenue.
Common DoS attacks and mitigations
This section describes the most common DoS attack methods used to disrupt online services. For each method, we suggest some possible mitigations your organisation should consider implementing.
SYN Flood
SYN is the first message in a TCP handshake at the start of communication between two devices. Devices respond to a SYN request with a SYN-ACK message and then hold open a session for the requesting device expecting an ACK response. By sending repeated SYN requests to a device it will hold open more and more connections eventually exhausting its ability to respond to requests. Connections will eventually time out and be dropped, so this type of attack relies on the attacker making requests faster than they can be dropped.
SYN Flood mitigation
Many network devices such as routers and firewalls can manage the threat of a SYN flood by blacklisting clients that repeatedly send SYN requests without completing the full TCP handshake. This protects the service from attack, but the device or internet connection can still be prone to bandwidth exhaustion.
ICMP/UDP Flood
These attacks rely on the attacker exceeding the available network bandwidth of the victim with ICMP/UDP packets or making requests at a faster rate than the victim can reply.
ICMP/UDP Flood mitigation
Most network devices such as routers and firewalls can be configured to drop ICMP and UDP traffic, provided they are not needed for the correct operation of the service. ICMP is not usually necessary; as a result accepted best practice recommends that system administrators drop ICMP traffic at their network boundary.
Low-rate attack
This attack relies on the safeguards built in to TCP to create a DoS condition. The attacker sends a burst of traffic to the server which lasts approximately as long as the average round trip time for data sent to the server. This has the effect of causing most active TCP flows to enter backoff. The attacker then waits for the backoff time and retransmits a full bandwidth burst. The attacker is able to maintain a DoS condition without sending much data.
Low-rate attack mitigation
Algorithms have been designed which can detect a low-rate attack. Consider an Intrusion Detection System product or service designed to detect this type of attack.
Peer-to-peer attacks
Clients using a file sharing network can be used to cause a DoS condition on a target through the inclusion of the targets’ IP address as a location of popular files to download.
Peer-to-peer attacks mitigation
Consider a product that will help reduce the impact of this type of attack by dropping connection requests which are identified as outside of the identified norm for the service.
Application DoS
Application layer DoS attacks do not target the network or the devices used to serve content to clients. Instead, these attacks target the application and the server.
The most common method is to repeatedly request resources from an application which the attacker knows will generate a large amount of processing on the server. Examples of this include:
- Bypassing the caching mechanisms used by web servers to efficiently service common requests. This attack usually relies on making unique requests for resources which may not exist. Requests can be made to look more unique by altering the header of the HTML request (for example altering the User-Agent, Referer, Cache-Control and Keep-Alive).
- Repeated requests to a feature of the application which uses a comparatively large amount of processor resource, such as a complicated search or calculation which may exhaust the ability of the service to respond.
- Attempting to initiate multiple Transport Layer Security (TLS) connections in order to consume computing resources on the server.
- Using an encrypted transfer to consume resources on the server to decrypt the data before it can be identified as irrelevant.
There are also various attacks (Slowloris, Slow Read, Slow POST) which work by deliberately slowing down requests made to the server, or the servers ability to respond to requests, thereby keeping connections open.
Due to the diverse nature of applications which rely on many different technologies it is impossible to discuss every possible attack.
Application DoS mitigation
System designers should consider DoS when designing their application, configuring the server to automatically restart any application which crashes, and then promptly investigating the cause of the crash. Where organisations are unable to influence the design of a commercially purchased service; use an application aware defence such as an application firewall. Services which rely on TLS could offload the TLS to a device or external service specifically designed to perform this task.
Reflection and amplification attack
This technique is used to hide the IP address of the attacker. This is achieved by spoofing the IP address that the original request is sent from, and sending the request to an innocent third party server. This server will attempt to respond to the request, but reply to the spoofed IP address rather than the originator of the attack. This technique relies on the third party server responding to the requests from the attacker. If the third party employs common DoS mitigation techniques, this may not occur thus reducing the effectiveness of the attack.
The bandwidth required by the attacker can be reduced by reflecting a request off a third party server which will respond with a larger response to the victim. DNS is often used to achieve this as the request to the third party server is much smaller than the response sent back to the victim.
Reflection and amplification attack mitigation
To limit the effectiveness of this attack, only allow the low service ports that are required for the correct operation of the service (eg up to 1024) at the border to a network. Most traffic will originate from another server on the internet hosting a legitimate service on a low port number. This may limit the functionality of legitimate services on the target network, and should be investigated before introduction.
General DoS mitigations
Mitigations are available for every known type of DoS attack. However it is not possible to fully remove the risk that a DoS attack will be successful. Regardless of the technique used to attack a network, if the ability for the service to react to the attack is exceeded, a DoS condition will take effect. When choosing DoS protection for a service, system administrators and designers should consider any device introduced into the network’s ability to cope with the attack.
Each component of the service should be considered because increasing capacity in one component (in order to deal with an attack) may only move the bottleneck to another component within the infrastructure.
The five common methods used to help prevent exhaustion of resources are summarised below. Each should be considered as just one possible component that contributes to an overall response to DDoS attacks:
Purchase more bandwidth or resources
On its own, this approach will have limited benefit. A determined attacker will nearly always be able to send more traffic than most organisations’ hardware or internet connection can handle.
Employ preventative measures upstream
In order to reduce the requirements on the system infrastructure, move as much protection upstream to the ISP as possible. Most ISPs are able to filter DDoS traffic before it reaches the connection to the client network. In the simplest case asking the ISP to implement stringent firewall rules will block many types of DoS attack.
Use a Content Delivery Network (CDN)
Content Delivery Networks typically serve the core static content from a web application and manage dynamic requests. They often have access to infrastructure distributed globally with multiple routes into and out of the network. Consequently it is very difficult to successfully DoS a CDN.
If you’re using a CDN then it will be hosting your users’ sessions with your service. Assuming your service is presented over HTTPS then the CDN provider has your private keys, or a certificate that will be trusted as if it were yours. If the CDN were to be attacked and compromised then your service (as far as the users are concerned) is effectively compromised too. For this reason it is important that you take care when choosing a CDN provider to select one you have confidence in the security of. We recommend you use the Cloud Security Principles to structure that decision.
Monitor your systems
It is important that system monitoring is in place to allow you to spot an attack when it begins and analyse and respond to the attack while it is underway. In the short term, disabling functionality or scaling compute resources is the only legitimate option available.
Host in the cloud
Cloud hosting providers often support preventative measures to reduce the impact of DoS attacks. While many cloud providers offer similar services care should be taken to investigate the ability of the provider to host your service should an attack occur. Some cloud providers offer their services from several different regional or geographic locations, well thought out use of multiple locations may increase your service’s resilience to an attack, since if one region is successfully attacked the service may continue to operate from another.
Configuring the service to automatically scale up under high load is another way to reduce the impact of an attack. If taking this approach be sure to think through how to scale most cost effectively, as it may be expensive to scale to keep your service fully operational during an attack. It may be more appropriate to temporarily reduce functionality while under attack.
A hybrid approach which makes use of two or more service providers may help address concerns around capacity whilst enabling more stringent controls to be put closer to the data. For example, hosting the presentation tier of a web application on a public cloud provider, and hosting the application and data tiers within a community cloud.
Be aware that the security properties of cloud services can vary greatly. We recommend you use our Cloud Security Principles to help you consider the significant security properties of services when choosing which to use.