Fail2ban vs CrowdSec on a Single Server

Choose the tool for the services you expose

For a server hosting an application behind a reverse proxy, start by identifying what you want to stop. Repeated SSH authentication failures are a narrow problem that Fail2ban handles with a small configuration. Suspicious web requests require rules that understand the relevant logs and enforcement that reaches the actual visitor.

Fail2ban can protect services beyond SSH, and CrowdSec can protect a server that only exposes SSH. The choice is operational: how much configuration will you maintain, and what additional behavior will it detect? We would not replace a working SSH jail just to collect a larger ban list.

Separate detection from the component that blocks traffic

Fail2ban groups a log source, a filter and an action into a jail. When matching failures cross the configured threshold, the jail runs its action, commonly a firewall ban. The action must match your firewall and the service's actual listening port.

CrowdSec reads events through acquisition sources and evaluates them with parsers and scenarios. Its local API makes decisions available to a separate remediation component, usually called a bouncer. Installing the Security Engine alone does not block connections. CrowdSec makes that separation explicit in its Linux installation documentation.

Shared intelligence can supply decisions about addresses your own server has not encountered. It does not guarantee that every listed address is still hostile or that an unlisted address is safe. Local detection still depends on useful logs, while enforcement depends on a working action or bouncer.

CrowdSec also supports application security integrations, but a firewall bouncer does not inspect HTTP requests. Request inspection needs the appropriate AppSec configuration and a compatible web integration. Treat that as additional functionality you deliberately configure, rather than an automatic consequence of installing CrowdSec.

Secure access before adding automated bans

Make SSH key authentication work before disabling password authentication, and verify a fresh login before closing your existing session. Restrict administrative access where practical. Use the Ubuntu hardening checklist to establish that baseline before tuning ban thresholds.

Neither tool repairs a vulnerable application or makes a stolen SSH key harmless. A successful login may never generate the failure pattern your rule expects. Keep application authentication controls in place, including account-level throttling where appropriate.

Before enabling bans, verify that your provider's console gives you a working recovery path. Keep an administrative session open, but do not assume an established connection will survive every firewall change. Record how to remove a ban through the selected tool before you need that procedure.

Start with temporary bans and conservative matching. An office or mobile connection can place unrelated users behind the same public address, so an IP ban can affect more than the person who triggered it. Permanent bans are a poor default for a small server with limited incident review.

Give Fail2ban one explicit SSH jail

On Ubuntu 24.04 LTS, install Fail2ban through the distribution package manager and ensure its systemd Python bindings are available. Confirm where SSH events actually appear before configuring the jail. Do not assume that /var/log/auth.log exists on your server image.

For journal-based SSH logging, create /etc/fail2ban/jail.d/sshd.local with the following configuration. This example assumes SSH uses its standard port; change port to your actual listening port if necessary. Keep overrides separate from package-managed defaults.

[sshd]
enabled = true
backend = systemd
port = ssh
maxretry = 5
findtime = 10m
bantime = 10m

This sets a temporary ban after matching failures reach the threshold within the configured window. With the systemd backend, the SSH filter's journal matching selects events; do not add a file-based logpath to solve a journal acquisition problem. The Fail2ban jail configuration reference explains that distinction.

Validate the configuration with Fail2ban's configuration check before starting or restarting the service. Then inspect the SSH jail through fail2ban-client and check the service log for acquisition or action errors. A process reported as active is only the first check.

Keep the packaged SSH filter initially instead of writing a custom expression. If legitimate activity is matched, inspect the exact event before changing the threshold. Adding more jails should follow a demonstrated need and a verified log source.

Install CrowdSec on Ubuntu as a complete detection path

For CrowdSec on Ubuntu 24.04 LTS, follow the official Linux installation instructions linked above and check that the package candidate comes from your intended repository. Prefer the documented manual repository setup when you want to inspect the trust configuration. Plan the remediation component before installing the engine.

1. Install the Security Engine and inspect the detected services. Keep its local API private to the host when every component runs there.
2. Enable collections for the services you actually expose. A collection supplies related detection configuration; it does not make an unreadable log source readable.
3. Check acquisition configuration against the real journal or log files. Avoid acquiring the same SSH events through both the journal and a mirrored authentication log.
4. Install a compatible bouncer. Use firewall enforcement for direct SSH connections and choose web enforcement according to where the visitor's address is available.

Use cscli to inspect acquisition metrics and bouncer registration before investigating missing bans. Zero parsed events during known relevant activity suggests a source or parser problem. Follow the CrowdSec setup health check to distinguish detection failures from remediation failures.

We would begin with the collection for the service that motivated the installation. Adding unrelated scenarios creates configuration to maintain without establishing useful coverage. Measure resource use on your own VPS under its normal traffic, because log volume and enabled integrations affect the workload.

Verify blocking on the path your users take

A recorded ban is a decision, not proof that a packet was dropped. With either tool, use a separate external source you control to verify enforcement while preserving administrative access from another address. Confirm that the two connections do not share the same public source address.

1. Generate a small, controlled sequence of failed authentication attempts from the test source. Confirm that the expected detector recognizes those events.
2. Observe the resulting ban and attempt a new connection from that same source. Check the enforcement component's logs or firewall counters alongside the client result.
3. Remove the ban through the tool that created it, or wait for its configured expiry. Confirm that a new connection works again.

Behind a CDN, the origin firewall usually sees the CDN's connection address. Restoring the visitor's address in an HTTP log does not change that packet source. Blocking the visitor at the origin firewall can therefore accomplish nothing, while banning the CDN address can interrupt legitimate traffic.

Use enforcement at a layer that can act on the real visitor, and accept forwarded client addresses only from trusted proxies. For containerized applications, also verify the forwarding path rather than assuming host input rules cover published ports. The Docker Compose production checklist helps identify those exposure boundaries.

Repeat the connection check for each address family your service exposes. Also verify representative application traffic after enabling web enforcement, especially automated integrations such as payment webhooks. A security rule that blocks those requests can look like an application outage.

Choose what you share and how you handle false positives

A conventional Fail2ban jail can operate locally without a shared reputation service. CrowdSec's network features exchange attack signals and obtain external decisions. Review signal sharing and Console context settings separately in the CrowdSec configuration reference; changing sharing settings can affect the community intelligence supplied.

Do not assume that enabling a dashboard means no operational data leaves the server. Review configured alert context before enabling its export, especially when application logs contain request details. Choose local-only operation deliberately if that better fits your requirements, understanding that it removes or limits the shared-intelligence benefit.

Keep exceptions narrow and document why each exists. A stable management address may justify an allowlist entry, but a broad network exemption can conceal unrelated abuse. Check whether a CrowdSec exception affects local detection, external decisions or enforcement, because those are different stages.

Avoid running both tools against the same service without a specific migration reason. Their decisions and firewall rules are independent, so removing a ban in one may leave the other blocking access. During a migration, verify the replacement's detection first, then transfer enforcement in a controlled change.

Schedule one verified rollout and a recovery check

Choose one exposed service and record the log source, detection rule and intended blocking location before making changes. For a basic SSH requirement, make the first rollout the Fail2ban jail above. If web abuse and shared intelligence justify CrowdSec, begin with the relevant collection and its matching bouncer.

We recommend Claude Code for inspecting configuration and drafting the change, with bounded access to the relevant files and redacted logs. Have it explain where enforcement occurs and prepare the recovery procedure for review. Use the production agent guardrails to keep firewall changes and broad allowlist edits behind explicit approval.

After the external blocking check succeeds, add monitoring for service failure and broken ingestion where metrics are available. CrowdSec also needs attention when the bouncer stops pulling decisions. Fit those checks into your minimum server monitoring setup, and repeat the connection check after changes to logging or the traffic path.

Before ending the maintenance session, remove the temporary test ban and verify a fresh administrative login. Save the working configuration and recovery instructions somewhere accessible without SSH to this server. Your next operational task is to review the first real bans for correct attribution and unintended blocking.