At 4am yesterday morning I was awake. Luckily so, as I checked my email and saw a warning that my VPS had been running at 199% CPU for two hours. I went into my office and checked the logs. Someone had been hammering this site with HEAD requests since just after midnight with nearly 30,000 requests across different URLs in four hours.
If they’d hit the same page repeatedly, cached responses would have handled it. But by requesting thousands of distinct URLs, each request generated a fresh cache file, forcing PHP and the database to do real work every time. My small server was coping, but the load average was high.
I blocked the offending IP in .htaccess immediately. That stopped requests from reaching PHP, but I wanted a proper defence, something that would catch this kind of abuse automatically next time.
I already had Fail2Ban installed. I’d just never configured it for web server attacks. Time to do that.
Fail2Ban works by watching log files for patterns, then banning IPs that match too often. I needed two files: a filter to match Apache access log lines, and a jail to define the thresholds.
First, the filter at /etc/fail2ban/filter.d/apache-ratelimit.conf:
[Definition]
# Matches any request line in Apache access log (combined/common format)
failregex = ^<HOST> -."(GET|HEAD|POST|PUT|DELETE|OPTIONS) .
ignoreregex =
This matches every request in the log.
The jail decides what volume of requests counts as abuse. It lives at /etc/fail2ban/jail.d/apache-ratelimit.conf:
[apache-ratelimit]
enabled = true
filter = apache-ratelimit
logpath = /var/www/logs/access.log
# Triggers a ban after too many requests in a short window
maxretry = 500
findtime = 30
# Ban for 24 hours
bantime = 86400
# Use iptables to drop packets from banned IPs
banaction = iptables-multiport
port = http,https
protocol = tcp
# Allowlist trusted networks
ignoreip = 127.0.0.1
The logic: if a single IP makes more than 500 requests in 30 seconds then ban it for 24 hours. Adjust maxretry and findtime to suit your traffic patterns. Legitimate crawlers and real users won’t come close to these numbers, but an attacker blasting thousands
of requests will trip the threshold fast. These are not the numbers I’m using.
The ignoreip directive keeps trusted networks (monitoring services, your own IPs) from getting caught.
The changes to Fail2Ban are activated with the following command (as root):
systemctl restart fail2ban
And I verified it was running by checking the status:
fail2ban-client status apache-ratelimit
Within a couple of minutes, the offending IP appeared in the banned list. I checked the access log, and there was nothing more from that IP. The requests weren’t just being rejected by Apache; iptables was dropping the packets before they reached the web server at all.
That’s the key advantage over an .htaccess block: banned traffic never touches Apache.
A VPS with limited resources can’t absorb a flood of uncached requests. Caching helps with repeat visits to the same page, but an attacker who rotates URLs defeats that entirely. Fail2Ban shifts the defence from the application layer down to the network
layer, where it’s cheap to enforce.
If you run a small site on a VPS, configure fail2ban for your web server. It takes ten minutes and it works.
Anyway, I presume whoever did that attack is reading this post since they seem to like my blog so much. Why did you do it?
