On this page
DDoS at the edge means large floods are filtered on the network before they reach your server’s network card. DDoS “at the box” means tools on the server itself, such as a host firewall or application rules, which only see traffic that already arrived. Volumetric attacks fill the link and must be handled upstream. Application-layer floods abuse expensive pages or login paths and are handled in the app, cache, or a WAF.
Volume floods versus application floods
A volume flood shows packet or bit rates that do not match normal customers, a saturated NIC, and sometimes a host you cannot reach over SSH on the same address. An application flood often looks like a slow site, high PHP worker use, costly search URLs, or XML-RPC traffic from many sources. The first case needs edge filtering. The second case needs application fixes and, when useful, a web application firewall. Blackholing a whole prefix because one IP is under a volume attack can take other customers offline, so plan routing options with us before an emergency if you may need that path.
Why the host firewall is not the edge
iptables, nftables, CSF, and plugins that claim DDoS protection all run after packets have already reached the server. If the flood is larger than the NIC can accept, those tools never get a useful chance to help. A WAF can still reduce layer-7 abuse. It cannot clear a pipe that is already full. Putting a CDN or similar proxy in front moves the volume problem to that provider only when DNS points there and clients are not hitting the origin IP directly. If a name is proxied but bookmarks or old records still use the bare server IP, traffic can bypass the protection you set up.
What to do, in order
If SSH is already down and the NIC is saturated, open a ticket with the attacked IP and the time in UTC. Do not reboot while we check from the edge. If SSH still works and PHP or the app is overloaded, treat it as layer 7: cache safe GET responses, disable XML-RPC if you do not need it, rate-limit logins, and use a WAF where it fits. Do not request a null route of an entire prefix only because one script or plugin is expensive to run.
A single ping failure from café Wi-Fi is not proof of a flood. If you can still SSH, include interface counters or vnstat output and the URL that hurts. If you cannot SSH, the ticket only needs the IP and a clear note that the NIC is full and you cannot get in. We will inspect from the network side; checks on the box only show what already arrived. Write down the attacked IP. If a CDN is already in front, tell us whether the flood appears to hit the origin IP directly.
Tagged
Was this article helpful?
Be the first to rate this article.
