CrowdSec

On a Debian server with limited memory, I originally used CrowdSec to analyze SSH and web logs, then used Firewall Bouncer to synchronize ban decisions to nftables. This setup could dynamically ban IP addresses based on attack behavior. However, for a server with only a few hundred MiB of RAM running several personal services, its resource overhead needed to be reconsidered. I ultimately adopted the following combination: Website: Caddy GeoIP and a manual IP allowlist, with an option to exempt CDN-to-origin traffic on a per-site basis. SSH: Fail2ban reads the systemd journal and bans anomalous sources through nftables. This article documents the complete migration procedure, as well as the log-source and startup-ordering issues encountered during deployment. All domains, addresses, and host identifiers have been replaced with examples. Commands are run as the root user. ...

Automatically Banning Malicious IPs on a Debian Server with CrowdSec Public-facing servers face all kinds of automated scanning every single day. Even when you never advertise a service address, your SSH port still routinely receives login attempts against usernames like root, admin and test. Web services may get probed for paths such as .env, wp-admin and phpinfo.php. Most of these requests come from automated scanners. They may not amount to an actual intrusion, but they generate a huge amount of pointless log noise and widen the exposed attack surface. ...