DoS Guidance - Upstream defences

Created:  31 Jan 2018
Updated:  31 Jan 2018
Ensure your service providers are ready to deal with resource exhaustion in places where they are uniquely placed to help.

A determined attacker will nearly always be able to send more traffic than most organisations could cope with unaided. Therefore, you may have to rely on your service providers to help you mitigate denial of service attacks.

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
  • Consider deploying a Content Delivery Network, for web-based services
  • Understand when your service providers would throttle access to your service 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 partiular 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 blacklisting 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 your site so that an attacker cannot discover the true origin. You may wish to implement ISP-level IP whitelisting 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?
  • 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.

Was this guidance helpful?

We need your feedback to improve this content.

Yes No