Denial of Service (DoS) Attacks Detection and Mitigation Controls

Summary

BeeTcore protects platform availability against denial of service attacks with layered controls. Cloudflare absorbs and filters attack traffic at the edge before it reaches the server. Rate limiting and bot controls stop abuse at the application level, and the server itself is kept out of direct reach. Attacks are detected through continuous monitoring, handled under a defined response process, and analysed afterwards to strengthen the rules.

1. Approach

A denial of service (DoS) attack tries to make a platform unavailable by overwhelming it with traffic. When the traffic comes from many sources at once, it is a distributed denial of service (DDoS) attack. BeeTcore defends in layers: the edge absorbs volume, the application limits abuse, and the infrastructure is kept resilient. This document sits within the Cloud Security Framework.

2. Edge protection

• Always-on DDoS mitigation: Cloudflare filters attack traffic at both the network and application levels, across every platform.
• Global network: attack traffic is absorbed across Cloudflare’s worldwide network, not at the platform’s own server.
• Caching and content delivery: pages and files are served from the edge where possible, so traffic surges reach the server far less often.
• Web application firewall: managed rules block known malicious request patterns before they reach the platform.

3. Rate limiting and bot management

• Rate limiting: limits on how often a single source can make requests, applied to sensitive areas such as logins, search, forms, and APIs.
• Bot management: legitimate crawlers, such as search engines, are allowed through. Automated abuse is challenged or blocked.
• Fake bot verification: traffic claiming to be a known crawler is checked, and impostors are blocked.
• Cache-busting protection: floods that use randomised web addresses to force every request past the cache are detected and blocked.
• WordPress platforms: Wordfence and MalCare add login rate limiting and bot protection at the application level.
• Custom applications: APIs enforce their own rate limits, so abuse is contained even if it gets past the edge.

4. Origin protection

The platform’s server address is kept behind Cloudflare, so attackers cannot easily bypass the edge. Where the hosting environment allows, the server accepts web traffic only through Cloudflare.

5. Detection

Traffic is monitored continuously for signs of attack: sudden spikes, unusual sources or locations, abnormal request patterns, and rising server load. Detection is part of Security Continuous Monitoring.

6. Response

When an attack is detected:

1. The attack is confirmed and its pattern identified.
2. Protection is tightened: targeted rules challenge or block the attack traffic by pattern, source, or location, and stricter protection modes are enabled while the attack lasts.
3. The hosting provider and Cloudflare are engaged where the attack needs their support.
4. The client is kept informed, and the event is handled under the Incident Management Response Strategy.
5. Temporary measures are lifted once traffic returns to normal, and the rules that worked are kept.

7. Scalability

Caching absorbs most traffic surges. On major cloud platforms, load balancing and automatic scaling spread traffic across servers where the architecture includes them, as confirmed in the project agreement.

8. Analysis and improvement

After every attack, the traffic analytics are reviewed to understand what happened. Rules are refined, and lasting protections are added where needed. Findings feed into Continuous Service Improvement. This document is reviewed annually and after any significant attack.

Frequently asked questions