A denial of service attack does not break into anything. Nothing is stolen, nothing is altered, and when it stops there is usually nothing to clean up. The server is simply given more work than it can finish, and everybody who wanted the site joins a queue that never clears. The distributed part is what makes it awkward: the work arrives from thousands of addresses at once, so the first instinct, find the attacker and block them, has nothing to aim at.
Most of those addresses belong to people who have no idea they are involved. Home routers running firmware nobody has updated in six years, cameras, television boxes, and the occasional compromised server with a far better connection than any of them. Somebody rents that collection by the hour, points it at a name and goes away. The hourly rate is lower than a month of hosting, which is why small sites are attacked as often as large ones, and why the motive is more often a grudge or a competitor than money.
Three families, and why the difference is the whole answer
Attacks are grouped by which resource runs out first, and the group decides where the problem can be solved at all.
- Volumetric. UDP and ICMP floods, and amplification against services that answer a small question with a large answer. Measured in gigabits per second. The network link fills before the server notices anything is wrong, so nothing installed on the machine helps. This family can only be answered upstream, in front of the hardware.
- Protocol. SYN floods and their relatives. Measured in packets per second. These exhaust connection tracking tables in the operating system, the firewall or the load balancer. The signature is a machine that refuses new connections while its processor sits nearly idle.
- Application layer. HTTP floods: requests that are individually indistinguishable from real ones. Measured in requests per second, and the number can be surprisingly small. A few thousand requests a second aimed at a search box that runs an uncached database query will finish a site that would have shrugged off ten times that volume against its home page. This is the hardest family to filter, because every single request is legitimate.
Telling an attack from a good day
Being linked from somewhere popular looks like an attack for about ninety seconds. The two separate quickly once you know what to look at.
- Shape. Real traffic arrives as a curve. An attack arrives as a step, at full volume, inside a minute or two.
- Breadth. Real visitors fetch the page, then the stylesheet, then the images. A flood usually fetches one URL and nothing else, so the ratio of page requests to asset requests inverts.
- Variety. Real traffic carries a scatter of browsers, languages and referrers. A flood often carries one browser string repeated tens of thousands of times, or none at all.
- Which resource ran out. A saturated network interface beside an idle processor is volumetric. A pinned processor beside a normal interface is usually application layer. Connections refused with both idle is usually protocol.
On a shared account the quickest check is the resource usage display in cPanel read next to the raw access log. The log tells you which URL is being hit and the usage graph tells you what it cost.
What helps, in the order it helps
- Filtering in front of the machine. This is the only place a volumetric attack can be answered, because by the time the traffic reaches your server the link is already full. Our shared hosting and the Istanbul virtual servers list DDoS protection among what the plan includes, and that filtering sits upstream of the host rather than on it.
- Do not publish the origin address. If anything is proxying for you, one DNS record pointing straight at the server undoes it. The usual leaks are records nobody tidied up:
mail,ftp,dev, and an old hostname sitting in a public certificate transparency log. - Cache, because an application flood is an economics problem. A page served from cache costs a fraction of the same page rendered from the database on every request. The attack has to find something expensive to be worth running, so the work is making sure the expensive things are few and that you know their names.
- Rate limit the endpoints that cost money. Search, login, password reset, anything that writes, anything that sends mail. Most application layer attacks go at one of those five, because the attacker is looking for the same thing you are: the slowest page on the site.
- Know where to send a report. A ticket opened from the client area arrives with the service attached, so nobody has to ask which machine you mean while it is happening.
On the day
Do not reboot repeatedly. It clears nothing and it costs you the evidence. Write down the time it started, the URL or the protocol being hit, and ten sample lines from the access log, and send those with the first message rather than after the first reply. Resist buying a larger plan in the middle of it: capacity bought under pressure is almost always the wrong size, and an attack sized to beat you will simply be resized the moment it does not.
Afterwards is when the useful work happens. Find the single endpoint that carried the load, make it cheap or make it rate limited, and check whether the origin address was ever exposed.
What nobody can promise
There is no plan on any provider's price list that makes a site immune, and a host that implies otherwise is describing a filter's capacity and calling it a guarantee. The honest version is where the filtering sits and what it absorbs. Ours sits upstream of the machine, which is the part that decides whether a volumetric attack is your problem or ours. Everything above the network layer stays a job shared between us and whoever wrote the application, and the five measures above are worth putting in place whoever you host with.