Introduction to Containerized Infrastructure Security

As businesses increasingly migrate their workloads to virtual private servers (VPS) managed via Docker, securing these containerized environments becomes paramount. While Docker provides excellent isolation for applications, exposing web services directly to the internet invites a barrage of automated cyber threats, including SQL injections, Cross-Site Scripting (XSS), brute-force attacks, and distributed denial-of-service (DDoS) attempts.

To establish a resilient defense-in-depth architecture, modern system administrators are turning away from traditional, static firewalls. Instead, they are adopting automated, collaborative security stacks. This guide explores a highly effective combination for Docker-based infrastructures: BunkerWeb WAF acting as an intelligent reverse proxy, paired with CrowdSec, a crowd-sourced, behavior-based intrusion prevention system. Together, they form an automated, proactive shield for your enterprise workloads.

Understanding the Core Components

What is BunkerWeb WAF?

BunkerWeb is an open-source, next-generation Web Application Firewall (WAF) designed inherently for modern cloud-native environments like Docker, Kubernetes, and Swarm. It functions as a secure reverse proxy, intercepting all incoming HTTP/HTTPS traffic before it reaches your backend application containers. BunkerWeb comes pre-configured with robust security defaults, including:

Protection against OWASP Top 10 vulnerabilities
Automated Let's Encrypt SSL/TLS certificate management
Built-in rate limiting and anti-bot challenges (like CAPTCHA and JS cookies)
Hardened HTTP configuration blocks to prevent server fingerprinting

What is CrowdSec?

CrowdSec is a modernized, high-performance alternative to legacy tools like Fail2ban. Written in Go, CrowdSec analyzes server logs (from web servers, SSH, databases, etc.) to detect malicious behavior using a set of decoupled scenarios. When a threat is identified, CrowdSec takes two vital actions:

Local Mitigation: It signals a local component called a "Bouncer" to block or challenge the offending IP address.
Global Intelligence Sharing: It shares the metadata of the attack anonymously with the global CrowdSec Network. If an IP is flagged by multiple independent nodes globally, it enters a highly accurate, community-driven blocklist distributed back to all users.

"The true power of this architecture lies in the synergy: BunkerWeb detects and logs application-layer anomalies, while CrowdSec parses those logs to instantly neutralize the malicious actors across the entire network tier."

Architectural Overview: The Collaborative Shield

When integrated into a unified Docker network, BunkerWeb and CrowdSec operate as a synchronized dual-layer defense system. The traffic flow behaves as follows:

1. Ingress Traffic: An external user requests access to your web application hosted on the Docker VPS cluster.
2. WAF Inspection: BunkerWeb intercepts the request, inspecting it against security rules. If the request is a web attack (e.g., an exploitation attempt), BunkerWeb blocks the request and generates a standardized access log entry.
3. Log Parsers: The CrowdSec container monitors BunkerWeb’s log files in real-time using specialized parsers. It detects the malicious behavior pattern or excessive error rates.
4. Decision & Execution: CrowdSec registers a local "decision" to ban the culprit's IP. It communicates this to the BunkerWeb instance (which contains an integrated CrowdSec Bouncer module). Subsequent requests from that specific IP are dropped immediately at the edge, saving critical backend compute resources.

Step-by-Step Deployment Guide via Docker Compose

To implement this setup, we will configure a multi-container environment using Docker Compose. Ensure you have Docker and Docker Compose installed on your VPS before proceeding.

1. Designing the Directory Structure

Maintain a clean organizational layout for configuration persistence and log sharing:

/opt/security-stack/ ├── docker-compose.yml ├── crowdsec-data/ └── bw-logs/

2. Crafting the Docker Compose Configuration

Below is a production-ready docker-compose.yml snippet defining the interconnected BunkerWeb and CrowdSec services, along with an example backend application:

version: '3.8' services: bunkerweb: image: bunkerity/bunkerweb:1.5.8 container_name: bunkerweb ports: - "80:8080" - "443:8443" volumes: - ./bw-logs:/var/log/bunkerweb environment: - SERVER_NAME=example.com - USE_REVERSE_PROXY=yes - REVERSE_PROXY_URL=/=http://webapp:80 - USE_CROWDSEC=yes - CROWDSEC_API_URL=http://crowdsec:8080 - CROWDSEC_API_KEY=YourSuperSecureBouncerAPIKey123 networks: - security_net crowdsec: image: crowdsecurity/crowdsec:v1.6.0 container_name: crowdsec volumes: - ./crowdsec-data:/etc/crowdsec - ./bw-logs:/var/log/bunkerweb:ro environment: - COLLECTIONS=crowdsecurity/nginx crowdsecurity/http-cve crowdsecurity/base-http-scenarios networks: - security_net webapp: image: nginx:alpine container_name: target_app networks: - security_net networks: security_net: driver: bridge

3. Configuring the CrowdSec Bouncer and Registration

Once the containers are deployed using docker compose up -d, you must complete the authorization handshake between the two systems:

Execute into the CrowdSec container to generate an API key for the BunkerWeb bouncer if you didn't define it statically:
docker exec crowdsec cscli bouncers add bunkerweb-bouncer --key YourSuperSecureBouncerAPIKey123
Install the required Nginx log parser collection inside the CrowdSec container to ensure it correctly interprets BunkerWeb's underlying log format:
docker exec crowdsec cscli collections install crowdsecurity/nginx
Restart the CrowdSec daemon to apply changes:
docker compose restart crowdsec

Testing and Validating the Automated Defense

To verify that your newly established shield is functional, you can safely simulate a malicious threat vector from a remote machine. Execute an aggressive directory traversal or vulnerability scan against your public domain name:

curl -I "http://example.com/?exec=/bin/sh"

BunkerWeb will immediately register a 403 Forbidden response. Within seconds, check the CrowdSec decision engine to observe automated IP ban actions:

docker exec crowdsec cscli decisions list

The resulting terminal table will display the offending IP address, the triggered scenario (e.g., crowdsecurity/http-cve), and the active remediation action (ban/block) with an expiration duration.

Production Best Practices for DevOps Teams

When running BunkerWeb and CrowdSec at scale across production workloads, ensure you apply these essential operational patterns:

Persistent Whitelisting: Always configure local whitelists within CrowdSec (via /etc/crowdsec/parsers/s02-fast/whitelists.yaml) to protect internal infrastructure monitoring agents, corporate VPN ranges, and development IPs from accidental bans.
Real-time Log Rotation: Because both systems rely heavily on I/O for logging, configure Docker log rotation policies to prevent storage saturation on your host VPS drives.
Monitor False Positives: Periodically audit your security dashboards. Tuning specific parameters in BunkerWeb (such as modifying strictness levels on SQLi rulesets) helps prevent blocking legitimate business traffic.

Conclusion

Securing a Docker-based VPS doesn't require overly complex enterprise hardware firewalls. By unifying BunkerWeb WAF and CrowdSec into a combined automated framework, you build an efficient, self-healing security ecosystem. This infrastructure not only isolates and thwarts web threats targeting your containers locally but also benefits dynamically from the collective defense of thousands of sysadmins worldwide. Implement this cloud-native shield today to secure your digital assets against evolving threats.

Securing Docker VPS Clusters: Deploying BunkerWeb WAF and CrowdSec as an Automated Security Shield