Deploy CrowdSec with Nginx: Block Brute-Force Attacks on Shared Hosting

Why CrowdSec Belongs on Every Shared Hosting Server#

Shared hosting servers are under constant assault. WordPress wp-login.php, cPanel's port 2083, webmail portals, SSH — they all get hammered by credential-stuffing bots around the clock. Traditional fail2ban helps, but it only sees your own logs. CrowdSec takes a different approach: it's a crowd-sourced, open-source threat intelligence engine that detects attacks locally and can share signals with a global community. Think of it as fail2ban that learns from the entire internet.

This tutorial walks you through a production-ready CrowdSec + Nginx setup on a shared hosting box. You'll end up with real-time brute-force blocking, automatic IP reputation enrichment, and a lightweight bouncer that rejects malicious traffic before it ever hits PHP-FPM.

Prerequisites#

• A Linux server (Ubuntu 22.04/24.04, Debian 12, or RHEL 9) running Nginx as a reverse proxy or web server.
• Root or sudo access.
• At least one shared hosting site with a login-protected endpoint (WordPress admin, phpMyAdmin, webmail, etc.).
• CrowdSec's package repository added (we'll cover this).

Step 1: Install CrowdSec#

CrowdSec ships as a single agent plus optional bouncers. The agent parses logs and makes decisions; the bouncer enforces them.

# Add the CrowdSec repository (Ubuntu/Debian)
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

# Install the CrowdSec agent
sudo apt update && sudo apt install crowdsec -y

# Verify it's running
sudo systemctl status crowdsec

On RHEL/Alma/Rocky:

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash
sudo dnf install crowdsec -y
sudo systemctl enable --now crowdsec

Step 2: Install the Nginx Collection#

CrowdSec uses "collections" — bundles of parsers and scenarios tailored to specific services. The Nginx collection includes parsers for access and error logs plus scenarios for web brute-force, crawling, and vulnerability scanning.

# Install the Nginx log parser and brute-force scenarios
sudo cscli collections install crowdsecurity/nginx

# Restart CrowdSec to load the new parsers
sudo systemctl restart crowdsec

Verify the collection is active:

sudo cscli collections list

You should see crowdsecurity/nginx with status enabled.

Step 3: Point CrowdSec at Your Nginx Logs#

CrowdSec auto-detects common log paths, but on shared hosting setups your Nginx config might log to custom directories per account. Open the acquisition file:

sudo nano /etc/crowdsec/acquis.yaml

Ensure you have entries for your Nginx access and error logs:

filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
  # Add per-account logs if they live elsewhere
  # - /var/log/nginx/*/access.log
labels:
  type: nginx

If you use per-vhost logging with glob patterns, CrowdSec supports them. Restart after editing:

sudo systemctl restart crowdsec

Step 4: Install the Nginx Bouncer#

The bouncer is the enforcement layer. For Nginx, there are two options:

• `crowdsec-nginx-bouncer` — a compiled Nginx dynamic module that queries CrowdSec's local API on every request. Fast, no extra process.
• `crowdsec-firewall-bouncer` — pushes bans to iptables/nftables. Better for blocking at the network layer but less granular.

For shared hosting where you want to block specific URLs (like /wp-login.php) without dropping all traffic from an IP, the Nginx module is ideal.

sudo apt install crowdsec-nginx-bouncer -y

The installer automatically adds the required directives to your Nginx config. Verify by checking your main nginx.conf or the generated snippet:

grep -r crowdsec /etc/nginx/

You should see something like:

server {
    ...
    SecRulesEnabled;
    DeniedReconDirectDenied;
    CrowdSecLocalAPI http://127.0.0.1:8080;
    ...
}

Reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

Step 5: Tune Scenarios for Shared Hosting Traffic#

Out of the box, CrowdSec's Nginx collection includes scenarios like:

• crowdsecurity/http-crawl-non404 — flags aggressive crawling.
• crowdsecurity/http-probing — detects vulnerability scanning.
• crowdsecurity/http-bad-user-agent — blocks known malicious user agents.

For shared hosting, you almost certainly want to add the WordPress-specific collection too:

sudo cscli collections install crowdsecurity/wordpress
sudo systemctl restart crowdsec

This adds scenarios for brute-force attacks on xmlrpc.php and wp-login.php, which are the two most attacked endpoints on any shared server.

Adjusting thresholds#

Default thresholds may be too aggressive for a busy shared server. Check current decisions:

sudo cscli decisions list

If legitimate users are getting banned, inspect the scenario and raise the threshold:

sudo cscli scenarios inspect crowdsecurity/http-probing

Then override in /etc/crowdsec/parsers/s02-enrich/ or create a local profile:

sudo cscli scenarios inspect crowdsecurity/http-bruteforce
# Note the capacity and duration, then adjust if needed

Step 6: Enroll in CrowdSec's Community Threat Intelligence#

This is where CrowdSec differentiates itself from fail2ban. By enrolling your agent, you both consume and contribute to a shared blocklist of malicious IPs.

sudo cscli console enroll -e [email protected]

Confirm via the link sent to your email. Once enrolled, your server receives curated blocklists from the CrowdSec network — meaning IPs that attacked other hosts are pre-blocked on yours before they even try.

You can verify enrichment:

sudo cscli metrics

Look for the acquisition and parsers sections to confirm logs are being processed.

Step 7: Monitor and Maintain#

CrowdSec's CLI gives you a real-time dashboard:

# Live alerts
sudo cscli alerts list

# Current bans
sudo cscli decisions list

# Processing metrics
sudo cscli metrics

# Update community blocklists
sudo cscli hub update && sudo cscli hub upgrade

Set up a cron job to keep collections and blocklists fresh:

0 3 * * * /usr/bin/cscli hub update && /usr/bin/cscli hub upgrade

What You've Built#

Your shared hosting server now has a multi-layer defense:

• Log parsing detects brute-force patterns across Nginx access and error logs.
• Scenarios trigger on repeated failed logins, malicious bots, and known attack signatures.
• The Nginx bouncer blocks offending IPs at the HTTP layer before requests reach PHP-FPM.
• Community blocklists pre-block globally flagged IPs, reducing your exposure to zero-hour attacks.

For resellers running Salieno Core or any panel on Nginx, this stack sits transparently in front of your sites without modifying application code. It's one of the highest-ROI security additions you can make to a shared hosting box — and it's free.