Denial-of-service attack (DoS / DDoS): understand it and protect yourself
In just a few years, the number of denial-of-service attacks has almost doubled. Their consequences range from a simple slowdown to the total unavailability of the information system. When service continuity is vital, this risk cannot be ignored.
DoS, DDoS: what are we talking about?
A denial-of-service (DoS) attack aims to slow down or make a server or resource unavailable. Motivations vary: most often extortion, but also ideological, political or personal convictions.
The difference with a distributed denial of service (DDoS) lies in the number of sources: in a DoS, the victim is attacked from a single system; in a DDoS, the attacker mobilizes many machines at the same time. A DDoS is therefore generally faster, harder to block and harder to trace.
Key point: a DDoS can never be completely prevented if the attacker devotes unlimited resources to it. However, many DoS attacks exploit configuration or application flaws that can be fixed sustainably. That is precisely the scope of a penetration test.
The main types of attacks
Protocol attacks
A SYN Flood saturates a server with connection requests that are never finalized; Teardrop sends abnormally fragmented packets to destabilize the target. These attacks exploit TCP/IP protocols.
Volumetric attacks
The objective is to saturate the victim's bandwidth, for example through a flood of ICMP requests. The network then allows only a few legitimate requests through.
Application-layer attacks (layer 7)
Slowloris keeps as many connections as possible open with deliberately slow HTTP requests, until the server can no longer accept new ones.
Feature abuse
An export function without safeguards, a GraphQL API that allows fragment loops, an “XML bomb”… All are legitimate features diverted to exhaust resources.
Three recurring causes behind a DoS
In a web application context, an exploitable denial of service most often results from one of three weaknesses: poor server configuration (for example, an old server without a timeout module), a poorly implemented feature (an expensive process that can be triggered repeatedly), or a vulnerable component (an outdated library targeted by a CVE). The good news: these three causes can be fixed, provided they have first been identified.
Testing denial of service methodically
During a penetration test, the goal is not to “bring down” a service with overwhelming resources: a DDoS will always manage that. Instead, we look for the specific cases where a single attacker, using one machine and a few tools, could be enough to cause unavailability. These tests are carried out in a controlled framework: preferably on a test environment, or otherwise during an agreed time window, with close communication with the technical team so they can react quickly and limit the impact. As soon as the flaw is demonstrated, we stop: the objective is to fix it, not to cause harm.
Protect yourself, step by step
Harden the server configuration
Enable timeout modules (receive timeouts, minimum data rates) to close overly slow connections, such as Slowloris.
Limit and distribute traffic
Set up rate limiting and one or more load balancers so a single server is not overloaded.
Filter with a web application firewall
A web application firewall (WAF) recognizes and blocks malicious traffic before it reaches the server.
Fix risky features
Control expensive processing (one export at a time), limit API query depth, disable XML external entities.
Keep components up to date
Inventory versions, monitor major vulnerabilities and apply a rigorous patch management process.
Monitor and prepare recovery
Analyze traffic to detect an attack early, and include the scenario in your business continuity and disaster recovery plan, in coordination with your incident response.
Why work with BCIT?
Controlled tests
We look for denial-of-service weaknesses that can genuinely be fixed, within a controlled framework that protects your activity.
Resilience, not fear
Our objective: reduce the impact of an attack on your availability, with concrete and prioritized measures.
Not ready to talk yet? Discover our cybersecurity diagnostic →
Protect the availability of your services
Let's take 15 minutes to assess your exposure to denial of service and define the measures that will concretely strengthen your resilience.
Denial-of-service attack (DoS / DDoS): understand it and protect yourself
In just a few years, the number of denial-of-service attacks has almost doubled. Their consequences range from a simple slowdown to the total unavailability of the information system. When service continuity is vital, this risk cannot be ignored.
DoS, DDoS: what are we talking about?
A denial-of-service (DoS) attack aims to slow down or make a server or resource unavailable. Motivations vary: most often extortion, but also ideological, political or personal convictions.
The difference with a distributed denial of service (DDoS) lies in the number of sources: in a DoS, the victim is attacked from a single system; in a DDoS, the attacker mobilizes many machines at the same time. A DDoS is therefore generally faster, harder to block and harder to trace.
Key point: a DDoS can never be completely prevented if the attacker devotes unlimited resources to it. However, many DoS attacks exploit configuration or application flaws that can be fixed sustainably. That is precisely the scope of a penetration test.
The main types of attacks
Protocol attacks
A SYN Flood saturates a server with connection requests that are never finalized; Teardrop sends abnormally fragmented packets to destabilize the target. These attacks exploit TCP/IP protocols.
Volumetric attacks
The objective is to saturate the victim's bandwidth, for example through a flood of ICMP requests. The network then allows only a few legitimate requests through.
Application-layer attacks (layer 7)
Slowloris keeps as many connections as possible open with deliberately slow HTTP requests, until the server can no longer accept new ones.
Feature abuse
An export function without safeguards, a GraphQL API that allows fragment loops, an “XML bomb”… All are legitimate features diverted to exhaust resources.
Three recurring causes behind a DoS
In a web application context, an exploitable denial of service most often results from one of three weaknesses: poor server configuration (for example, an old server without a timeout module), a poorly implemented feature (an expensive process that can be triggered repeatedly), or a vulnerable component (an outdated library targeted by a CVE). The good news: these three causes can be fixed, provided they have first been identified.
Testing denial of service methodically
During a penetration test, the goal is not to “bring down” a service with overwhelming resources: a DDoS will always manage that. Instead, we look for the specific cases where a single attacker, using one machine and a few tools, could be enough to cause unavailability. These tests are carried out in a controlled framework: preferably on a test environment, or otherwise during an agreed time window, with close communication with the technical team so they can react quickly and limit the impact. As soon as the flaw is demonstrated, we stop: the objective is to fix it, not to cause harm.
Protect yourself, step by step
Harden the server configuration
Enable timeout modules (receive timeouts, minimum data rates) to close overly slow connections, such as Slowloris.
Limit and distribute traffic
Set up rate limiting and one or more load balancers so a single server is not overloaded.
Filter with a web application firewall
A web application firewall (WAF) recognizes and blocks malicious traffic before it reaches the server.
Fix risky features
Control expensive processing (one export at a time), limit API query depth, disable XML external entities.
Keep components up to date
Inventory versions, monitor major vulnerabilities and apply a rigorous patch management process.
Monitor and prepare recovery
Analyze traffic to detect an attack early, and include the scenario in your business continuity and disaster recovery plan, in coordination with your incident response.
Why work with BCIT?
Controlled tests
We look for denial-of-service weaknesses that can genuinely be fixed, within a controlled framework that protects your activity.
Resilience, not fear
Our objective: reduce the impact of an attack on your availability, with concrete and prioritized measures.
Not ready to talk yet? Discover our cybersecurity diagnostic →
Protect the availability of your services
Let's take 15 minutes to assess your exposure to denial of service and define the measures that will concretely strengthen your resilience.