Denial of Service (DoS) guidance
Pages
Page 4 of 8
Upstream defences
A determined attacker will nearly always be able to send more traffic than most organisations could cope with unaided. To successfully mitigate denial of service attacks you may need to call on one or more service provider(s) to help you.
We recommend that you:
- Understand the denial of service mitigations that your ISP has in place on your account. If additional mitigations are available, decide whether you want them enabled on your account, or the circumstances under which you could deploy them if an attack was threatened. Examine the service's SLA for details of any mitigation.
- Look into third party DDOS mitigation services that can be used to protect against network traffic based attacks.
- Consider deploying a Content Delivery Network, for web-based services
- Understand when and how your service provider might limit your network access in order to protect their other customers.
- Consider using multiple service providers for some functionality
Protections offered by Internet Service Providers (ISPs)
When it comes to helping their customers deal with denial of service attacks, ISPs have varying capabilities. Some of these will be inherent in their networks, others may only be made available at additional cost. The capabilities of your particular ISPs are something you should understand, either from their published literature or through your relationship with them.
One service that many ISPs may offer, either directly or via a third party, is a 'packet scrubbing' service. These services can perform basic filtering of packets that appear to be intended to cause a denial of service. The rules which determine whether a packet is filtered can vary from service to service, they might be very simple (such as deny listing IP addresses that have sent too much traffic) or more sophisticated. If purchasing such a service you should understand which types of denial of service attack it will help you mitigate.
Some ISPs may offer denial of service mitigations for attacks at higher levels of the network stack. We recommend understanding exactly what level of protection is achieved in this case, as it is likely to be difficult for ISPs to understand the nuances of your applications. Additionally, if your application is using an encrypted protocol, such as HTTPS or TLS, your provider may be limited in what heuristics they can deploy to spot unusual activity.
In some cases, you may wish to ask the ISP to implement simple network traffic filtering rules upstream too, to prevent your network firewalls being overwhelmed by inbound access requests.
Using a Content Delivery Network (CDN)
For web-based services, CDNs typically serve the 'static' content from a web application and manage dynamic requests. They often have access to edge infrastructure distributed globally with multiple routes into and out of the network. Consequently, it is very difficult to successfully DoS a CDN. CDNs often have capabilities to help with application-layer attacks, for example, by rate limiting access to particular URLs to prevent search queries overloading backend databases.
If you’re using a CDN, it will be hosting your users’ sessions. Assuming your service is presented over HTTPS, the CDN provider will therefore hold your private keys, or a certificate that will be trusted as if it were yours. If the CDN were to be attacked and compromised, your service (as far as the users are concerned) is effectively compromised too. For this reason, it is important that you choose a CDN provider whose security you trust. We recommend you use the Cloud Security Principles to structure that decision.
You should ensure that your CDN appropriately masks or 'cloaks' your site so that an attacker cannot discover the true origin. You may wish to implement ISP-level IP allow listing to ensure that all requests must reach you via the CDN to avoid an attacker being able to directly target your services, bypassing the CDN.
Understanding your service provider's response
Ensure you are aware of any contractual terms which cover how your service providers will handle denial of service attacks. You may wish to consider the following:
- Will your provider automatically apply denial of service mitigations, and will they notify you when they do?
- Will your service provider throttle your bandwidth beyond a certain limit?
- How long will it take to turn on additional mitigations? How would you do this?
- Will you start being billed for excess resource usage?
- Does your provider reserve the right to terminate your service or 'sink hole' your traffic to avoid affecting their other customers?
- Will your provider contact you before taking action?
- How quickly can your service be re-enabled if shut down?
Using multiple service providers
By using multiple service providers, you may be able to improve availability of some functions - such as DNS, network connectivity or hosting. This can give you more confidence that you'll continue to offer your users a good service when one provider is under attack. However, this approach can also add complexity to your system architecture that may need careful management.
If you decide to use multiple providers, be aware of any shared resources. A worst case would be where one provider is simply a re-seller of the second. However, there may be more subtle links such as shared backbone capacity, shared connections to key data centres (such as a cloud provider) or even using the same cloud provider for their service. Similarly, be aware if both providers are in a similar location, or even in the same data centre.
