There are likely to be many points in your service where an attacker can attempt to overload or exhaust available resources, thereby preventing you from serving legitimate users. You should understand where these points are, and in each case, determine whether you, or a supplier, are responsible.
Some of the resources that could be overloaded in your service are:
The network links between your service and your users, or between components in your service, could be saturated by illegitimate traffic. Consider:
- External connectivity to your service - Network bandwidth is a finite resource. If users access your service over the internet, your internet service provider will have provisioned you with a given capacity. Increasing this capacity may only give you a small gain, as the attacker may be able to saturate the network regardless of how much you increase bandwidth.
- Whether co-located services can affect you - If your service is exposed over a network link that is also used by other services, there is a chance that an attack on one of those other services could also affect yours.
- Network connectivity within your service - Internal network capacity in your service is also a finite resource that can be exhausted. Identify parts of your internal networking (connections and devices) that could present a bottleneck, such as network components with low throughput, or where multiple networks coincide.
- Management interfaces - An attacker may purposefully or coincidentally prevent administrators or operators from accessing servers during an attack. If your administrators or operators access the service over a network interface that an attacker can overload, you may be unable to administer or operate your service during the attack.
Potential mitigations: Connectivity
- Ask your internet service or hosting provider to put in place upstream mitigations against DoS (see Upstream defences).
- If your service presents a web interface to the public, consider using a Content Delivery Network (CDN) to cache content and provide some level of DoS mitigation (see Upstream defences).
- If your service is not for direct use by the public, consider limiting access using IP address whitelisting. You can either configure this on your network infrastructure, or for additional protection, ask your upstream internet service provider to apply the required access control.
- Ask your upstream service providers to guarantee you a level of capacity in the event that one of their other customers is under attack.
- Ensure your internal networking is well provisioned to deal with increased load (see Scaling).
- Ensure you can Retain administrative access in event of an attack.
The amount of computing resource available to service legitimate requests can be overwhelmed by a surge in malicious sessions, or through a surge in compute-intensive operations performed by an attacker. Consider:
- Application capacity - An attacker may try to create more user sessions than you are able to cope with, or call application functionality which will be compute-intensive for your service. Both reduce your ability to serve legitimate users.
- Database query capacity - Depending on your service architecture, database queries could be computationally expensive to execute. An attacker can take advantage of this by calling functionality that puts a strain on your database servers, overloading your ability to respond to legitimate queries.
- Cascading failures - Putting strain on some components of your service can result in cascading failures on other components. For example, in a traditional n-tier web architecture, slowing down the response time of application servers or database servers can put stress on front-end web servers.
Potential mitigations: Compute
- Ensure your service is desgined to scale to deal with a surge in activity (see Scaling).
- Prepare a Response plan that includes Graceful degradation or services.
- Optimise your database so common queries have pre-prepared indexes, reducing the load caused by each request.
- Identify potential bottlenecks that could lead to cascade failures and add application logic to limit requests at each.
An attacker may attempt to consume your available storage capacity, leading to a service outage or causing a cascasding affect on other aspects of your system. Consider:
- Application logs - An attacker may attempt to fill your available storage by repeatedly performing an action which writes a lot of data to a log.
- Local server storage - If your system relies on receiving files, for example user uploaded files to a website, or files received from third-parties, an attacker may attempt to flood your upload and/or transfer mechanism and exhaust storage capacity.
- Database capacity - Similar to the above, an attacker may attempt to fill database storage.
Potential mitigations: Storage
- Ensure appropriate storage is provisioned to systems where logs are stored.
- Generate alerts in advance of storage issues becoming critical.
- Be aware of what logs your applications generate, especially where their contents, size or quantity can be affected by user interaction. Be prepared to reduce certain log messages in times of attack.
- Only accept file uploads from authenticated users or systems, for example where you have authenticated a user or established mutual trust with a third party end system.
- Ensure that uploaded files are audited and that alerts are generated by unexpected or unusual activity. For example, if you normally receive JPG images of around 500KB in size, then suddenly you start receiving 20MB PDF files, this might indicate either something has changed in your systems (or user instructions), or that you are under attack.