How to Protect Traefik from DDoS Floods Using Fail2Ban: A Step-by-Step Guide

Introduction

Running a public-facing reverse proxy like Traefik is convenient, but it also exposes your infrastructure to potential abuse and DDoS attacks. If you’ve ever woken up to find your nodes overloaded by thousands of requests per second, you know how disruptive this can be. Fortunately, with Fail2Ban, you can automate the detection and blocking of abusive IPs based on Traefik’s access logs. In this guide, we’ll walk through a practical setup to protect your Traefik endpoints from HTTP flood attacks.

Background: The Problem

Our platform allows users to create HTTP tunnels, with Traefik handling HTTPS termination and routing. One day, we noticed a massive spike in requests to a single domain—thousands per second from dozens of AWS IPs. Despite having throttling rules (returning HTTP 429), the attack persisted, saturating CPU and degrading service for all users on the node.

Manual intervention (blocking IPs via the firewall) worked temporarily, but the attacks returned. Clearly, we needed an automated solution.

Why Fail2Ban?

Fail2Ban is a Python daemon that scans log files for suspicious patterns (using regular expressions) and bans offending IPs by updating firewall rules. It’s highly configurable, widely supported, and comes with many prebuilt filters (e.g., for SSH brute force). Importantly, bans are temporary and automatically lifted after a set period.

Step 1: Install Fail2Ban

On Debian/Ubuntu:

sudo apt update
sudo apt install -y fail2ban

Note: On Debian 12+, SSH logs are handled by journald instead of log files. To fix Fail2Ban startup issues, edit /etc/fail2ban/jail.d/defaults-debian.conf and add:

[sshd]
enabled = true
backend = systemd

Start Fail2Ban:

sudo fail2ban-client start

Check status:

sudo fail2ban-client status

Step 2: Create a Custom Filter for Traefik 429s

We want to ban IPs that trigger too many HTTP 429 responses (Too Many Requests). Traefik logs requests in JSON, so we’ll create a filter that matches lines with "DownstreamStatus":429 and extracts the client IP.

Create /etc/fail2ban/filter.d/traefik-429.conf:

[INCLUDES]
before = common.conf

[Definition]
# Match lines with 429 status and extract ClientHost as 
failregex = ^{.*"ClientHost":"".*"DownstreamStatus":s*429.*}$
ignoreregex =

Step 3: Define the Jail

Now, configure a jail to use this filter and specify how many 429s are tolerated before banning an IP.

Create /etc/fail2ban/jail.d/traefik-429.conf:

[traefik-429]
enabled  = true
filter   = traefik-429
logpath  = /var/log/traefik/access.log
maxretry = 1000
findtime = 1m
bantime  = 1m

Parameters explained:

  • enabled: Activates this jail.
  • filter: The filter name created above.
  • logpath: Path to Traefik’s access log.
  • maxretry: Number of 429s from one IP before banning.
  • findtime: Time window for counting retries (1 minute).
  • bantime: How long to ban the IP (1 minute).

Step 4: Reload and Verify

Apply your changes:

sudo fail2ban-client reload --all

Check that your jail is active:

sudo fail2ban-client status
sudo fail2ban-client status traefik-429

You should see stats for failed attempts and banned IPs.

Step 5: Testing the Setup

To test, use a tool like wrk to simulate a flood of requests:

wrk -c 10 -t 10 -d 10s https://your.traefik.domain

Monitor Fail2Ban status:

sudo fail2ban-client status traefik-429

Once the threshold is exceeded, your test IP should be banned. Further requests will be blocked at the firewall level.

Step 6: Monitoring and Alerting

For visibility, integrate fail2ban-prometheus-exporter to export metrics to Prometheus and visualize them in Grafana. This lets you track bans over time and set up alerts.

Example Prometheus alert rule:

- alert: F2BBannedIncrease
  expr: increase(f2b_jail_banned_total{jail="traefik-429"}[1h]) > 10
  for: 1s
  labels:
    severity: warning
  annotations:
    description: "Number of banned IPs in Fail2Ban increased by {{ $value }} in the last hour on {{ $labels.instance }}"

Results

After deploying this setup, we saw a dramatic reduction in CPU load during attacks. Offending IPs were automatically banned, and normal traffic was unaffected. Monitoring and alerting provided valuable insights and peace of mind.

Conclusion & Tips

Automating DDoS protection for Traefik with Fail2Ban is straightforward, effective, and flexible. Here are some final tips:

  • Tune thresholds: Adjust maxretry, findtime, and bantime to balance between blocking abusers and avoiding false positives.
  • Monitor regularly: Use Prometheus/Grafana for visibility and incident response.
  • Keep Fail2Ban updated: Benefit from new features and security fixes.
  • Test before production: Simulate attacks from a VPS, not your own IP, to avoid locking yourself out.

With this setup, your Traefik nodes are much better protected against HTTP flood attacks. Happy deploying!

Need more help or want to learn about our platform?

  • Check out Tuna for developer tools, HTTP/TCP/SSH tunnels, cloud gateways, password management, and more.
  • Questions? Reach us at [email protected] or join our Telegram chat.

Thanks for reading and stay secure!