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 a minute or two of the pattern being recognised, on a server set to Automatic, and every block expires on its own after 6 hours, longer for an address that keeps coming back, never more than 7 days. Each server blocks what attacks it; a block on one server is not copied to your 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.
The five layers, and which one SecAI is
Flood protection is a stack, and each layer stops a different thing. Knowing which layer a product lives in is most of choosing it:
- Upstream DDoS mitigation: a scrubbing service or your provider's network absorbs volumetric traffic before it reaches your link. Nothing on the server can do this.
- Provider firewall or security groups: drops traffic to ports you never meant to expose, before it reaches the machine.
- Reverse proxy or CDN: terminates connections at the edge, caches, rate-limits, and hides the origin address.
- Host firewall: the last place a packet can be dropped, and where a block of one abusive source is applied.
- Host telemetry: what the machine itself experienced, connection state, backlog, the endpoints being hit, which process ran out of what. This is SecAI, together with the block it applies at the layer above.
When the server goes quiet
A server under enough pressure stops reporting, and from outside an overwhelmed server, a dead link and a crashed process look the same. The agent is built for that moment. It is protected from the OOM killer, and while the machine is being exhausted or cannot reach SecAI it keeps a per-second record of pressure, memory, forks, sockets and the TCP backlog, classifies what it saw, a SYN flood, connection exhaustion, memory exhaustion, a fork bomb, with a confidence and the evidence, and works out which silence it was: SecAI unreachable, the link down, DNS failing, or the machine flooded. When the link returns, the record arrives and the outage has a story.
Recording is the default on every server. If you set a server to Protect, the agent may also act during the episode: drop a flooding source at the host firewall, or cap, throttle or freeze the one process group exhausting the machine, and it undoes each action when the episode ends or at its next start. It never kills a process and never touches init, SSH, a database, a web server, a control panel or a live login session.
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.