Login floods
Repeated attempts against a login endpoint are rate limited per source and per account, then blocked with an escalating lifetime.
Answered before the appDefence
What it stops, and where it stops.
A firewall has a boundary. Naming it honestly is more useful than promising everything.
In scope
Handled by CDPGuard.
Path probing
Requests hunting for /.git/config, /.env, backup files or admin paths mark the source immediately.
Known tooling
Mass scanners announce themselves through their request pattern and are blocked for the whole server, not per site.
Server wideMalformed and spoofed traffic
Invalid states, impossible source addresses and abusive connection patterns are dropped in the kernel.
Dropped, not answeredConnection floods
Limits on new connections per source keep a single origin from occupying the server’s capacity.
Per source limitsEverything not served
Ports without a service behind them are closed, so a forgotten daemon cannot become an entry point.
Closed by defaultOut of scope — on purpose
CDPGuard does not audit code, does not test applications, does not run compliance programmes and does not investigate incidents. That work belongs to CyberGuard, the cybersecurity services division of CertThor PlatForms Ltd. Keeping the two apart is deliberate: a product that claims to do everything can be trusted with nothing.
Volumetric attacks that exceed the capacity of the uplink are also not a firewall problem. Filtering happens on the server; a flood that saturates the line has to be handled before it — at the network edge.
Where you see it
Blocks, rates and events are visible in ControlDeskPanel. Availability of the protected sites is measured from outside by UptimeRobot.org, so protection and reachability can be judged separately.