Caddy + fail2ban

published 2025-03-25

I’ve been running Caddy for several years. I rarely look at the log files, mostly because it makes me sad to see the sheer volume of automated scanners, followed by crawlers and indexers, and then the few piddling legitimate requests I serve. But after a look yesterday, I became a little motivated to do something.

I’ve been running fail2ban to block SSH scanners for some time. I decided to try to get it to read Caddy’s log file and block some of the web scrapers.

First, I added these values to my site’s stanza in my Caddy file:

  error /*.php 400
  error /wp-json* 400
  error /wp-includes/* 400
  error /wp-admin/* 400
  error /wp-content/* 400
  error /WEB-INF/* 400
  error /var/* 400
  error /?url=* 400
  error /?target=* 400
  respond /robots.txt 200
  log {
    output file /var/log/caddy/skippy.log
    format json {
      time_format common_log
    }
  }

and then ran sudo systemctl reload caddy to get them to take effect. I elected to return an HTTP 400 code to people poking for PHP or WordPress URLs. You may prefer 403 or something else.

TODO: find a way to apply these to all sites in my Caddyfile via one block, rather than adding this to each site I host.

My server runs Ubuntu, which Debian based, so the fail2ban configs are split according to Debain packager’s standards. Your locations and file names may be different.

I created /etc/fail2ban/filter.d/caddy.local with the following:

[Definition]
failregex = ^.*"remote_ip":"<HOST>",.*?"status":(?:400|401|403|500),.*$
ignoreregex =
datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

This tells fail2ban to look for log lines that contain an IP address (either v4 or v6) and one of the listed status codes. I don’t emit many of these error codes, but any of them suggests a high probability of a potentially malicious request.

It took me a fait bit of fiddling to get the datepattern right. Caddy’s default timestamp wasn’t recognized by fail2ban’s default EPOCH or LONGEPOCH options. I tried iso8601 format, too, but Caddy appends microsecond time and the fail2ban filter for that format doesn’t expect microseconds. So I played to the lowest common denominator of common_log format and manually defined the regex. If you have a better idea, please send it to me!

Next, create /etc/fail2ban/jail.d/caddy.local:

[caddy]
enabled  = true
backend  = auto
bantime  = 86400
port     = http,https
filter   = caddy
logpath  = /var/log/caddy/skippy.log
maxretry = 1

Point to your caddy log file(s) (or get fancy and tell fail2ban to read the journal). Adjust your bantime and maxretry as desired. If someone is poking my site for a PHP file, I’ve decided to just block them for a day.

NOTE: Debian’s /etc/fail2ban/jail.d/defaults-debian.conf config sets the default backend to systemd. Thus, I had to specify the auto backend for the Caddy jail so that it would actually read the logpath value.

You can test your configuration with sudo fail2ban-regex -v -l debug /path/to/caddy/log /etc/fail2ban/filter.d/caddy/.local. This will show you how many IPs would match your filter. You should have some.

Finally, run sudo fail2ban-client reload to get things into action. You can confirm that it’s working with fail2ban-client status caddy:

$ sudo fail2ban-client status caddy
Status for the jail: caddy
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	12
|  `- File list:	/var/log/caddy/skippy.log
`- Actions
   |- Currently banned:	2
   |- Total banned:	2
   `- Banned IP list:	2600:1009:b091:3e6d:b9a3:60ff:1dac:5a2 174.200.95.142

To confirm this worked, without accidentally blocking myself, I switched off WiFi for my phone and then tried to visit a few fake .php pages. After the first one, I was blocked!

Notes:

I added allowipv6 = auto to the [DEFAULT] section of my /etc/fail2ban/fail2ban.local file, just to make sure I was blocking ipv6 addresses, too. It’s not entirely clear to me if that’s the default or not.

Helpful references: