What Is DDoS?

Author: Published

In brief: DDoS is an attack designed to overload a website, server or other internet service with traffic from multiple sources, making it difficult or impossible to use. It does not necessarily involve a break-in or data theft—its main goal is to make the service unavailable. Protection involves identifying and filtering out malicious traffic, ideally before it reaches the overloaded infrastructure.

How does a DDoS attack work?

DDoS stands for Distributed Denial of Service. A server has limited network bandwidth, processing power and capacity for simultaneous connections. The attacker attempts to exhaust at least one of these resources, causing legitimate users to encounter errors, wait for a response or fail to connect.

You can compare it to a shop whose entrance and checkouts are blocked by a crowd of people with no intention of buying anything. The shop still exists, but ordinary customers cannot shop efficiently. On the internet, the disruption can affect an individual website, a game server, email or a network operator’s infrastructure.

The word “distributed” means that the attack uses multiple sources of traffic. This often involves a botnet—a network of devices taken over by criminals, such as computers, routers and cameras. An attack can also use external servers that are induced to send responses to the victim’s address. Not every device participating in this traffic therefore has to be infected.

DoS is the broader term for attacks that cause a denial of service; DDoS is the distributed variant. Blocking a single IP address, meaning the address of a device or network endpoint, is usually not enough to stop an attack from multiple sources.

What exactly can become overloaded?

Not every DDoS attack simply involves sending an enormous amount of data. Three types of attack are commonly distinguished:

For example, an online shop might display existing images quickly but handle complex catalogue searches much more slowly. Invoking that function on a massive scale can overload the database, even while network bandwidth remains unused. Protection therefore needs to match the resource that actually becomes the bottleneck.

How can you distinguish DDoS from an outage or high demand?

A slow website is not proof of an attack. A successful advertising campaign, an application error, database problems or a hosting outage can cause similar symptoms. Additional signs are needed to strengthen the suspicion of DDoS: an unusual increase in the number of connections, repeated requests to a single function or alerts from the protection provider.

Check availability monitoring, traffic statistics and logs—the records of events and requests handled by the server. Compare the time performance deteriorated with the launch of an advertisement, configuration changes and announcements from the operator. Page-view counts in an analytics tool may not show the entire attack, because some malicious traffic does not execute the website’s analytics code.

DDoS alone does not confirm a data leak, but it does not rule one out either. If unfamiliar logins or file changes occur at the same time, treat them as separate signs of a possible security breach.

How can you reduce the risk and choose protection?

The foundation is protection that operates upstream of the server, within the operator’s network or through a specialised traffic-filtering service. A local firewall can reject requests, but it cannot recover the bandwidth of a connection already saturated by an attack.

A CDN, a network of servers that act as intermediaries in delivering content, can reduce the load on a website and provide DDoS protection features. A WAF, or web application firewall, helps filter suspicious requests to the website. However, these safeguards are not interchangeable, nor do they guarantee resilience: the scope of the service, its configuration and the type of attack all matter.

Before choosing hosting or additional protection, check the provider’s current documentation for the following:

If you use a protective intermediary, direct access to the origin server should be restricted according to its recommendations. Otherwise, an attacker may bypass the filter. Backups help recover data after other incidents, but do not stop DDoS on their own.

What should you do when a service starts failing?

First, contact your hosting provider or protection operator. Provide the time the problem began, the affected services, the symptoms and any available measurements. Ask them to confirm the cause and activate appropriate filtering.

For an application attack, temporarily limiting the number of requests or disabling a particularly resource-intensive function can help. However, these measures may also make the service harder for legitimate customers to use. For example, restricting product searches may reduce the load on a shop, but an overly restrictive filter will block some shoppers.

Do not treat restarting the server or purchasing more processing capacity as a guaranteed solution. Preserve logs, record the changes you make and communicate updates to users through an independent channel. If the service is currently working properly, prepare one specific part of your response plan now: an emergency contact for the operator, together with the procedure for reporting an attack.

Read also

Learn how PHP-FPM handles PHP requests, how it differs from a web server, and how to tune processes for traffic and hosting resources.
Learn how BIND, open-source DNS server software, handles domains, how its two roles differ and when running it yourself makes sense.
Learn what Poland’s REGON register and identification number mean, how they differ from NIP and KRS, and how to check a business’s details.