Securing Traefik Docker Proxy

When exposing a reverse proxy like Traefik to the public internet, security should be a top priority. I recently deployed Traefik on a public-facing Linux server to route traffic to Docker containers - and I wanted a robust, layered security model to defend against port scans, brute-force attacks, and misbehaving clients.

In this post, I’ll walk through how I secured my Traefik setup using UFW, Fail2Ban, and PSAD - combining firewall rules, intrusion detection, and log-based banning into an effective security stack.

Each component of this stack plays a specific role:

UFW: Acts as our first line of defense by controlling which ports are exposed and accessible
iptables: Powers UFW and handles low-level packet filtering; we'll also configure it directly.
PSAD: Monitors network traffic to detect and block potential intrusion attempts like port scans
Fail2Ban: Analyzes application logs (Traefik in our case) to identify and block malicious behavior

Think of these tools as concentric security rings:

UFW defines what doors are open to the internet
PSAD monitors suspicious activity at those doors
Fail2Ban watches how visitors behave once they're allowed through a door

UFW provides a simplified interface to iptables. My approach is "deny by default" - block everything unless explicitly allowed.

sudo apt install ufw

# Deny all traffic by default
sudo ufw default deny outgoing comment 'deny all outgoing traffic'
sudo ufw default deny incoming comment 'deny all incoming traffic'
 
# Allow SSH (don't lock yourself out!)
sudo ufw limit in ssh comment 'allow SSH connections in'
 
# Allow web traffic for Traefik
sudo ufw allow 80/tcp comment 'allow HTTP'
sudo ufw allow 443/tcp comment 'allow HTTPS'
 
# Allow essential outbound traffic
sudo ufw allow out 53 comment 'allow DNS calls out'
sudo ufw allow out 123 comment 'allow NTP out'
sudo ufw allow out http comment 'allow HTTP traffic out'
sudo ufw allow out https comment 'allow HTTPS traffic out'

sudo ufw enable
sudo ufw status verbose

PSAD monitors network traffic through iptables logs to detect and optionally block scanning activity and other suspicious traffic.

sudo apt install psad

Make a backup of the configuration:

sudo cp --archive /etc/psad/psad.conf /etc/psad/psad.conf-BACKUP

Edit /etc/psad/psad.conf and update these settings:

EMAIL_ADDRESSES         [email protected];
HOSTNAME                your-server-hostname;
EXPECT_TCP_OPTIONS      Y;         # Enable TCP options logging
ENABLE_PSADWATCHD       Y;
ENABLE_AUTO_IDS         Y;         # Enable auto-blocking
ENABLE_AUTO_IDS_EMAILS  Y;         # Enable email notifications

Configure UFW to log traffic for PSAD by modifying both /etc/ufw/before.rules (for IPv4) and /etc/ufw/before6.rules (for IPv6). First make a backup of both files:

sudo cp --archive /etc/ufw/before.rules /etc/ufw/before.rules-BACKUP
sudo cp --archive /etc/ufw/before6.rules /etc/ufw/before6.rules-BACKUP

Add these lines to both files before the COMMIT line:

In /etc/ufw/before.rules:

# log all traffic so psad can analyze
 
-A ufw-before-input -j LOG --log-tcp-options --log-prefix "[IPTABLES] "
-A ufw-before-forward -j LOG --log-tcp-options --log-prefix "[IPTABLES] "

In /etc/ufw/before6.rules:

# log all traffic so psad can analyze
 
-A ufw6-before-input -j LOG --log-tcp-options --log-prefix "[IPTABLES] "
-A ufw6-before-forward -j LOG --log-tcp-options --log-prefix "[IPTABLES] "

Note: Using ufw-before-input and ufw-before-forward chains instead of directly modifying INPUT and FORWARD is crucial for proper integration with UFW.

Reload and Verify

sudo ufw reload
sudo psad -R
sudo psad --sig-update
sudo psad -H

Analyze Firewall Logs and Check PSAD Status
```
sudo psad --fw-analyze
sudo psad --Status
```
If psad --fw-analyze shows issues, you can check your mail by executing the mail command. For this to work, you need to provide <user>@localhost as the email address in EMAIL_ADDRESSES field of the psad.conf file.

Fail2Ban scans log files for malicious activity and blocks offending IPs using iptables. We will configure it to monitor Traefik logs for suspicious behavior.

sudo apt install fail2ban

Create a local configuration file to avoid editing the default one:

sudo vim /etc/fail2ban/jail.local

Add the following content:

[DEFAULT]
 
# Ignore local IPs
ignoreip = 127.0.0.1/8 192.168.0.0/16 10.0.0.0/8 172.16.0.0/12
 
# Email notifications
destemail = [email protected]
sender = [email protected]
mta = mail
 
# Get detailed email alerts
action = %(action_mwl)s

First, make sure Traefik is configured to output access logs in a format Fail2Ban can process:

# In traefik.yml
log:
  level: debug
 
accessLog:
  filepath: /var/log/traefik/access.log
  format: common

# In docker-compose.yml
services:
  traefik:
    image: traefik:v3
    container_name: traefik
    volumes:
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - ./logs:/var/log/traefik
      ...
      ...

Create a filter for authentication failures:

sudo vim /etc/fail2ban/filter.d/traefik-auth.conf

Add this content:

[Definition]
failregex = ^<HOST> - .* "GET .* (401|403) .*$
            ^<HOST> - .* "POST .* (401|403) .*$
ignoreregex =

Create a filter for rate limiting (this will require setting up Traefik's rate limiting middleware):

sudo vim /etc/fail2ban/filter.d/traefik-ratelimit.conf

Add this content:

[Definition]
failregex = ^<HOST> - .* "GET .* (429) .*$
            ^<HOST> - .* "POST .* (429) .*$
            ^<HOST> - .* "PUT .* (429) .*$
            ^<HOST> - .* "DELETE .* (429) .*$
ignoreregex =

Create a jail file for Traefik:

sudo vim /etc/fail2ban/jail.d/traefik.conf

Add this content:

[traefik-auth]
enabled = true
port = http,https
filter = traefik-auth
logpath = /path/to/your/traefik/logs/access.log
maxretry = 3
bantime = 1h
findtime = 10m
 
[traefik-ratelimit]
enabled = true
port = http,https
filter = traefik-ratelimit
logpath = /path/to/your/traefik/logs/access.log
maxretry = 5
bantime = 30m
findtime = 5m

Docker's networking requires special attention to ensure our security tools work properly.

When you use Docker, it creates its own network namespace and manipulates iptables rules to handle routing between containers and the outside world. This presents two main challenges for Fail2Ban:

Visibility Issue: In a standard Docker setup, container logs show the internal Docker network IPs (like 172.17.0.x) rather than the actual client IPs.
Ban Enforcement Issue: When Fail2Ban tries to ban an IP, it adds rules to the host's iptables, but these rules might not affect traffic that's already being handled by Docker's networking rules.

sudo vim /etc/fail2ban/action.d/iptables-traefik-docker.conf

Add this content:

[Definition]
actionstart = iptables -N f2b-traefik
              iptables -A f2b-traefik -j RETURN
              iptables -I FORWARD -p tcp -m multiport --dports 80,443 -j f2b-traefik
 
actionstop = iptables -D FORWARD -p tcp -m multiport --dports 80,443 -j f2b-traefik
             iptables -F f2b-traefik
             iptables -X f2b-traefik
 
actionban = iptables -I f2b-traefik 1 -s <ip> -j DROP
 
actionunban = iptables -D f2b-traefik -s <ip> -j DROP

Update your jail configuration to use this action:

[traefik-auth]
# ... existing configuration
action = iptables-traefik-docker
 
[traefik-ratelimit]
# ... existing configuration
action = iptables-traefik-docker

Getting Real Client IPs in Traefik First, we need to ensure Traefik logs show the real client IPs:
- Traefik automatically captures the real client IP when properly configured
- The accesslog.format=common setting ensures these IPs are logged in a format Fail2Ban can parse
The Custom iptables Action (iptables-traefik-docker.conf) modifies iptables to work with Docker's networking:
1. On Start (actionstart):
  1. iptables -N f2b-traefik: Creates a new custom chain called "f2b-traefik"
  2. iptables -A f2b-traefik -j RETURN: Adds a default rule that returns traffic flow to the parent chain
  3. iptables -I FORWARD -p tcp -m multiport --dports 80,443 -j f2b-traefik: Inserts a rule at the beginning of the FORWARD chain to route HTTP/HTTPS traffic through our custom chain
  This setup intercepts packets in the FORWARD chain, which is crucial because Docker traffic typically passes through this chain.
2. On Ban (actionban):
  - iptables -I f2b-traefik 1 -s <ip> -j DROP: Inserts a rule at the beginning of our custom chain to drop packets from the banned IP
3. On Unban (actionunban):
  - iptables -D f2b-traefik -s <ip> -j DROP: Removes the ban rule for the specific IP
4. On Stop (actionstop):
  1. iptables -D FORWARD -p tcp -m multiport --dports 80,443 -j f2b-traefik: Removes our custom chain from the FORWARD chain
  2. iptables -F f2b-traefik: Flushes (clears) all rules in our custom chain
  3. iptables -X f2b-traefik: Deletes our custom chain

This approach ensures bans are effective even with Docker's network abstractions.

After configuring all components, it's important to test your setup:

sudo ufw status verbose

sudo psad --Status

sudo fail2ban-client status
sudo fail2ban-client status traefik-auth
sudo fail2ban-client status traefik-ratelimit

sudo iptables -L f2b-traefik -n

Regular maintenance is crucial for keeping your security stack effective:

sudo tail -f /var/log/fail2ban.log
sudo tail -f /var/log/psad/psad.log

sudo psad --sig-update

sudo fail2ban-client set traefik-auth unbanip 192.168.1.100

sudo fail2ban-client status traefik-auth

To better understand how these components interact during an attack, let's visualize two common scenarios:

Port Scan Attack: An attacker scans for open ports on your server.
Brute Force Login: An attacker tries to guess login credentials for your applications.

Hardening a reverse proxy like Traefik on a public host isn’t a set-it-and-forget-it operation. This layered approach - combining firewall rules, intrusion detection, and log-based banning - ensures you're actively defending against real-world threats.

If you're running Docker in production or even just experimenting in a homelab, these practices are well worth the effort.

Let me know if you have any questions or if you want to share your own security setups! If you found this post helpful, consider sharing it with others who might benefit from it. Happy homelabbing!

How to Secure a Linux Server