I use fail2ban to detect malcious requests to any of my hosted domains, which is working very well, with one exception.

If a requests is sent to the IP instead of a fqdn or a subdomain, it gets catched and written into other_vhosts_access.log since the ip itself is no virtualhost.

Example entry:

somedomain.de:80 - - [24/Jan/2020:15:47:04 +0100] "POST //4walls/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 587 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"

So it seems, apache does a reverse lookup to the IP and writes down the hostname at first place.

This causes fail2ban to selfban the servers ip instead of the requesters IP.

How can i prevent the somedomain.de:80 entry?


apache does a reverse lookup to the IP and writes down the hostname at first place.

If your filter made correctly (e. g. anchored regex without catch-all's) it does no matter where exactly the domain and foreign address are written.

I assume in your example log entry, the somedomain.de is yours and is an address of "intruder". Then the proper failregex would look like:

# ban everything (with code 300-599):
failregex = ^\S+\s+<ADDR>\s+\S+\s+\S+\s+\[\]\s+"[^\"]+" [345]\d+

The anchored part ^\S+\s+<ADDR> matches somedomain.de:80 and would search in the string from begin only due to the anchor ^.
This would be also enough as regex, if you have to ban everything from other_vhosts_access.log (regardless the resulting http-status).

If you have fail2ban version <= 0.9 use <HOST> instead of <ADDR>.

You could also check with fail2ban-regex whether it'd capture some false positives, for example:

fail2ban-regex --raw -vv /path/to/log '^\S+\s+<ADDR>\s+\S+\s+\S+\s+\[\]\s+"[^\"]+" [345]\d+' \
  | grep <your-IP-or-hostname>
  • Yeah, this would have been a working solution, but my filter explicitly looked for 404 codes to detect exploit bruteforceing. I changed the default logformat from vhost_combined to combined and this fixed my issue – Tim Altgeld Jan 30 '20 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.