The distinction that decides whether this helps
Two very different things are called DDoS. Volumetric attacks aim to exhaust your bandwidth, sending more traffic than your link can carry. By the time those packets arrive at your server the damage is done: the pipe is full, and a firewall rule on the host discards traffic that has already consumed the resource under attack. Nothing running on the server can fix that, and any vendor implying otherwise is selling you something that cannot work.
The second kind aims to exhaust the server rather than the link: HTTP floods that tie up worker processes, connection exhaustion that fills the state table, slow-request attacks that hold connections open, and application endpoints that are expensive to serve. These arrive at volumes your link handles comfortably, and the constrained resource is on the machine.
Host-side mitigation is effective against the second category and irrelevant to the first. SecAI operates on the second.
What SecAI detects on the server
- SYN floods and half-open connection patterns, read from connection state on the host.
- Connection exhaustion, where the state table fills with connections that never complete.
- HTTP floods against the sites the server hosts, including WordPress login flooding.
- Scanner and probe traffic working through paths and ports looking for something exposed.
- UDP flood patterns against services on the machine.
What it does about it
Sources driving an attack are blocked automatically using the firewall tooling already on the server, typically within seconds of the pattern being recognised, and what one server learns is applied across your fleet so the same source is blocked before it reaches the others.
This genuinely resolves the common cases: a single abusive client, a small botnet hammering a login endpoint, a scanner sweeping your paths. These are far more frequent than headline volumetric attacks, and they are what actually takes small sites down.
Where you still need upstream protection
If your link is being saturated, you need filtering before the traffic reaches you. That means your hosting provider absorbing or null-routing it, or a CDN and scrubbing service such as Cloudflare in front of your origin.
A practical arrangement for a small deployment is a CDN in front for volumetric absorption and host-side detection behind it for the application-layer traffic that gets through, since a CDN alone does not stop a flood aimed at an endpoint it considers legitimate.
One caveat worth knowing: behind a CDN the source address the server sees is the CDN edge, not the real client. Blocking decisions have to account for that or you risk blocking the edge itself, which takes your own site offline.
Detection has value even when mitigation is upstream
Knowing that an attack is underway, which endpoints are targeted and when it started is operationally useful even if the mitigation happens elsewhere. It is the difference between escalating to your provider with specifics and reporting that the site feels slow.
It also separates causes. A server that is unreachable because it is being flooded, because a process is consuming all memory, or because an application deadlocked look identical from outside and need different responses. SecAI distinguishes them by monitoring the host and the site together.