As soon as a home service becomes reachable from the Internet, the logs start showing login attempts from unknown addresses. It is not a targeted attack: these are automated scans that try common passwords and look for forgotten admin panels and known vulnerabilities. The first defence remains exposing as little as possible. For what must stay public, tools such as fail2ban and CrowdSec watch the logs and block whoever misbehaves, reducing both noise and risk.
First of all: reduce exposure
No blocking tool replaces a sound architecture. Before installing any protection, ask yourself:
- Does this service really need to be public, or is reaching it through a VPN enough?
- Is the admin panel separated from the public part and accessible only from the home network?
- Do all accounts have strong passwords and, where possible, a second factor?
- Is the software up to date?
If the answer to the first question is «the VPN is enough», the rest of this article becomes almost superfluous. For services shared with friends or relatives, however, an active defence makes sense.
The common principle: reading logs
fail2ban and CrowdSec work in the same basic way: they read service logs, recognise suspicious patterns and decide to block the address producing them. Typical recognisable behaviour includes:
- Many failed login attempts within a few minutes.
- Requests to non-existent paths typical of other software, such as admin panels of CMSs you do not use.
- Requests carrying signatures of known vulnerabilities.
- An abnormal number of requests in a short interval.
For this to work, the logs must contain the client's real address. Behind a reverse proxy this needs care: the service must trust the headers sent by the proxy, otherwise it will always see the proxy's own address and would end up blocking itself.
fail2ban: simple and local
fail2ban is a long-established, proven tool. It is configured with «jails», each tied to a service: a filter with regular expressions that recognises suspicious log lines, a threshold (for example five failures in ten minutes) and an action, usually a firewall rule that blocks the address for a set time.
Strengths: it is lightweight, does not depend on external services, and filters can be written by hand for any application. Limitations: each server learns only from what it sees, and writing reliable filters for modern web applications can take time.
CrowdSec: detection and blocking kept apart
CrowdSec splits the work into separate components:
| Component | Role |
|---|---|
| Agent (security engine) | Reads logs, applies scenarios and makes decisions |
| Collections | Packages of parsers and scenarios for common services |
| Bouncer (remediation component) | Enforces decisions: firewall, reverse proxy, challenge page |
| Community blocklist | A list of addresses reported by other installations |
The advantage of this separation is practical: the agent can run on one machine and the bouncers on others, for example in the firewall and the reverse proxy. Ready-made collections for popular services spare you from writing filters by hand. The community blocklist lets you block in advance addresses already known for aggressive behaviour, in exchange for sharing your own signals.
The cscli command-line tool shows what is happening: which decisions are active, which scenarios have triggered and which addresses have been blocked.
Avoid blocking yourself
The most concrete risk with these tools is locking out exactly the people who should get in. Some precautions:
- Allow lists: add the home network and the VPN addresses to those never blocked.
- Reasonable durations: a block of a few hours discourages scans without overly punishing a family member who mistyped a password several times.
- Trial mode: watch for a few days what would be blocked before enforcing decisions.
- Alternative access: always keep a way into the server even if the firewall blocks everything, for example from the local console.
Rate limiting at the proxy
Besides log-based blocking, the reverse proxy can limit the number of requests per address within a given interval. It is a simple defence against rapid-fire password guessing or aggressive scraping. It is best applied above all to login pages, leaving more headroom for parts that load many resources, such as photo galleries.
What these tools do not do
fail2ban and CrowdSec reduce noise and stop the most common automated attacks, but they do not fix a software vulnerability, do not protect against a stolen password and do not see attacks that leave no trace in the logs. They are an extra layer, not a substitute for updates, strong authentication and minimal exposure.
In short
- Exposing as little as possible remains the most effective defence.
- fail2ban and CrowdSec read logs and block addresses that abuse services.
- Behind a reverse proxy, logs must record the client's real address.
- CrowdSec separates detection from blocking and offers ready scenarios and a shared blocklist.
- Allow lists and alternative access keep you from locking yourself out.
