PSEiBlog

While examining my webserver statistics, I noticed that quite a lot 404′s are being served on most of my domains to scan bots that are trying to find exploits in possible running PHPMyAdmin configurations.
Though harmless if you keep a clean ship with a decently configured PHPMyAdmin and the latest updates like I do, I still decided I couldn’t let this behaviour unanswered. So I took action, and wrote a small fail2ban filter that permanently drops all traffic from the IP addresses these scans originate from, like I do with every address that misbehaves in any way.

The regex used won’t capture all attempts, but with my configuration only 1 hit is enough to get you banned (the scripts these scans call are main.php and config.inc.php, which aren’t to be called directly, especially not when they fail with a 404 like these), and all scanning attempts I’ve seen so far cycle through at least 20 different combinations.

Well, enough talk, here is the filter.d file:

# Fail2Ban configuration file
#
# Author: Remco Overdijk
#
# $Revision: 4 $
#

[Definition]
 
# Option:  failregex
# Notes.:  regex to match the 404'ed PMA file in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>\S+)
# Values:  TEXT
#
failregex = <HOST> -.*"GET .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/config\.inc|main)\.php.*".*404.*
 
# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

And this is of course accompanied by a bit in jail.conf:

[apache-pma]
 
enabled = true
filter = apache-pma
action = iptables-allports[name=pma]
mail-whois[name=pma, dest=<YOURADDRHERE>]
logpath = /var/log/apache2/access_log
bantime = -1
maxretry = 1

Works for me, another 20 additional IPs/day onto the shitlist!

Update: It seems another variation of these scans are hitting the NIC’s quite often; One for Zen Cart to be more precise.
You can easily add support countering this scanner as well, simply by expanding the failregex with this line:

^<HOST> -.*"GET .*(cart|boutique|catalog|butik|shop|zen|store).*/install\.txt.*".*404.*

You can put multiple regexes within one failregex, just put each one on a new line.

On my servers I use the nifty program Fail2Ban to perform logbased automatic fire walling of ‘bad’ ip’s.

The idea behind this is easy: Some IP performs an action I don’t approve of. This can be any number of things, e.g. requesting pages in Apache that are commonly accessed by bots and/or scanners, or trying to log in to SSH with accounts that do not exist on the system. This bad behavior gets logged, and Fail2Ban keeps tabs on those logs, and using a number of rules it determines if a host is ‘bad’ enough to temporarily or permanently ban all access to the server. It does so by adding a few chains to Iptables (one for each thing it checks for), and dynamically adding/removing IP’s to/from these chains.

This all works perfectly. However, there’s one issue; When Iptables gets reloaded, it restores its default rules, removing the Fail2Ban chains and all the rules they contain, even if the ip’s in the chain were marked as permanent.
Read more…