Catching an SSH or RDP brute force in seconds, not on the next poll

A password-guessing attack against SSH or RDP is one of the few security events a monitoring agent can catch reliably, cheaply, and early. It leaves an unmistakable signature in the authentication log, and it happens fast - a few thousand attempts a minute is ordinary.

Why the panel cannot do it

The obvious architecture is to ship the auth log to the server and analyse it centrally. It works, and it is the wrong trade. Log shipping is expensive on hosts that are already under load, and central analysis puts a polling interval between the attack and the alert. If metrics arrive every 60 seconds, a burst that starts and ends inside one window is invisible.

So the detection runs where the log is. The agent watches journald//var/log/auth.log on Linux and the Security event log on Windows, keeps a small in-memory window of failures by source address, and raises an event the moment the pattern is unambiguous - before the next metrics tick, and without sending the log anywhere.

What counts as unambiguous

Naive thresholds on failure count produce constant false positives, because the public internet is a continuous low-grade scan. Anything with a public SSH port sees a few hundred failures a day from unrelated addresses and that is simply weather, not an incident.

What separates an attack from background noise is concentration:

• many failures from one source in a short window, rather than a few each from many;
• the same username tried repeatedly, or a dictionary walk through common ones;
• a success immediately following a run of failures - the case that matters most, and the one a pure rate threshold misses entirely.

What it deliberately does not do

The agent does not block, ban or drop traffic. Monitoring that mutates firewall state is monitoring that can take a production host off the network because of a parsing bug, and the failure mode is worse than the attack. It reports; you decide. Everything the agent does is read-only, it opens no inbound ports, and it has no offensive capability at all.

If you want automatic response, wire the webhook to whatever already owns your firewall. That keeps the decision, and the blast radius, in a system designed for it.