Denial of Service (DoS) guidance
Page 8 of 8
Responding to a DoS attack
You should design your service, and plan your response to an attack, so that the service can continue to operate, albeit in a degraded fashion.
If you suspect your organisation is experiencing a DoS attack, your priorities are to:
Clarify what is happening
Your aim here is to gather data to understand the causes of the unusual activity.
First, gather as much data as you can that may be helpful to determine the cause of your unusual traffic. Monitoring data from all system components will help you identify any unusual activity. Data sources include:
- traffic volumes
- use of bandwidth or server processors
- database transactions and alerts triggered by anomalous activity
You should also include information from other sources you might not initially consider, such as helpdesk tickets or social media feeds, which could explain a surge in traffic.
Now interpret the data. There may be non-malicious reasons why a system has slowed down or stopped. Analysing and understanding the causes of observed anomalies will help you determine the actions to take to fully restore your system.
| Observed anomaly | Possible cause | |
|---|---|---|
| Non-malicious | DoS attack | |
| Unusually large volumes of traffic that exceed bandwidth capacity, meaning that not all legitimate traffic is reaching its destination. | There may be more traffic than normal to your website – for example, an item on it is attracting high interest or your organisation is receiving lots of external attention for some reason. | Volumetric attack: an attempt by an attacker to overload the bandwidth (capacity) of a network by sending large volumes of attacker traffic to the target network. |
| Unusually large processing loads on a router with relatively normal bandwidth use, meaning that not all legitimate traffic is being passed through. | An internal network misconfiguration has caused more traffic than intended to route through the router. | Protocol attack: an attempt to exceed the capacity of network equipment by exploiting how network protocols legitimately function. |
| Unusually large volumes of database queries or server load, resulting in significantly slower database response times. | A recently updated internal tool has an unintentional coding error, causing the tool to generate large volumes of database transactions. | Application attack: an attempt by an attacker to overload the processing resources of servers by sending large volumes of legitimate-looking requests that servers must process. |
Put in place the right defences
Once you have identified the probable causes and determined that it is a DoS attack, it will help you assess which defences to put in place. For example, it may be the right initial course of action to increase the computing resource in an overloaded system. But later actions will require you to understand whether the cause was non-malicious, such as a newly misconfigured internal component that requires fixing, or malicious, such as an IP address used by attackers that needs blocking.
Possible defences against DoS attacks
DoS defence | Description |
|---|---|
| Automated protections | Ideally most DoS defences will be automatically triggered when a DoS attack is identified. This requires your organisation to set up defences before a DoS attack begins. Examples here are:
Continual monitoring to understand when automatic defences are triggered will help you maintain situational awareness. |
| Defences offered by a service provider, such as an ISP or cloud service | Internet service providers (ISPs) may offer preventative services, as well as responsive controls. Some preventative controls could be used to respond to a DoS attack, such as blocking traffic coming from malicious or suspected spoofed IP addresses, or using geo-blocking functions to only accept connections from specified geographical locations. Third parties, such as cloud service providers, may have their own DoS protection services, which can also help if you have already set them up. They should also have configurable settings, for example, the option to change the threshold for alerting, or to introduce a challenge-response protocol like CAPTCHA which can help with your DoS response. |
| Changes to infrastructure resources | If infrastructure resource is close to capacity, you could provide additional resources, such as bandwidth, processing power or storage capacity to meet the demand. Another mitigation you may wish to consider is to route known malicious traffic to a sinkhole. You should be careful when configuring this so you don’t inadvertently route legitimate traffic there. You can also manually activate failover systems to help absorb the attack, as well as making changes to systems, such as firewall rules. |
| Application layer changes | It may be appropriate to make temporary changes to the application layer to reduce the system’s attack surface, or use of resources. For example, temporarily disabling a website’s search feature can reduce an attacker's ability to exhaust system resources. |
Once initial defences are deployed to the system, you should monitor for signs of recovery and if necessary, deploy further defences.
If you need help analysing your logs or applying defences, a commercial cyber incident response (CIR) provider may be able to help. The NCSC operates an assured CIR scheme.
Continually review the situation, communicate and recover
Continually review the whole system
It’s important to continually monitor all parts of a system during a DoS attack, including those which don’t initially appear to be affected.
You should be on heightened alert for other attacks because in some cases, a DoS attack might be a diversion for a more penetrative attack into a system or because adversaries may attack in waves. You should make sure that you continue to review alerts from other security tools so that not all resources are consumed by investigating the DoS attack.
Things you should look out for include:
- Is the amount of traffic increasing or returning to normal?
- Does the type of traffic appear to be changing?
- Are system processing times increasing or decreasing?
- What alerts are you continuing to see and are they changing?
- Are you noticing more, or fewer, systems and services being negatively affected?
- Are you receiving notification or alerts from third parties, and is anyone else affected by this attack?
- How is the impact of the attack changing for you over time?
Communicate about what is happening
You should provide stakeholders with timely, clear and accurate information. This includes employees and risk owners internally, and externally, service providers, business-to-business partners and users or customers.
Things you might communicate here include:
- informing users or customers that a confirmed DoS attack is making the system slow, which may reduce queries to customer support channels
- where corporate resources are targeted, put in place appropriately secure alternative ways for employees to communicate
- sharing information with your service provider that might be useful for DoS defence, such as attacking IP addresses
Recover from the attack and begin to restore
Once the attack has been mitigated to an acceptable level, you should consider restoring systems and returning to normal activities.
Things which may indicate an attack is subsiding:
- traffic volumes starting to return to a manageable amount
- system resources starting to stabilise
- the type of traffic becoming more consistent with normal activities
- a reduction in the number of alerts
- users reporting that systems are back online, or a significant reduction in new reports from users
When should recovery begin?
Although mitigating the DoS attack is the immediate priority, recovery should begin as soon as it’s appropriate. This is normally when you have evidence the attack has reduced and you have put in place the appropriate mitigations. This will help make sure your organisation doesn’t suffer unnecessary downtime, cost or risk.
It’s particularly important that where possible, you mitigate vulnerabilities that may have been exploited in the affected systems so you don’t fall victim to the same attack immediately. You should judge this on a case-by-case basis, taking into account the risk of another attack against the risk to your organisation by keeping systems offline.
Examples of recovery activities include:
- restarting systems or services that were taken offline or disabled
- reconfiguring temporary traffic filters you may have put in place
- reverting to any primary systems if additional systems have been used temporarily to mitigate some of the attack
Consider the lessons learned
After a DoS attack has subsided and systems are fully restored, you should review all phases of the response. Your aim here is to identify areas of improvement and understand how attacks can be prevented or the impact reduced in the future. You should also review the technology used to detect and respond to DoS attacks.
It may also be helpful to carry out effective post-incident analysis, which will require you to collect and analyse relevant information to drive improvements. The NCSC has separate guidance on post-incident analysis.
You should be looking how to quickly identify a DoS attack, faster intervention of defences, or reduced observable impact using both tactical fixes as well as more strategic solutions. These strategic solutions may only be identifiable by looking at the organisation as a whole.
Report it
Reporting a DoS attack to UK authorities using the cyber incident signposting service helps inform the wider threat picture, to understand the prevalence, scale and impact of such attacks in the UK.