PSEiBlog

Many scripts like my Persistent Iptables bans from Fail2Ban script add a bunch of DROP statements to Iptables chains.

I noticed that quite a lot of people ask questions on mailing lists and forums requesting a method to automatically remove any duplicate IP’s that might exist within a given chain.

Well, that’s quite easy to accomplish really, just run this little PHP script I created as root, and your Iptables is once again clean as a whistle!

/**
 * Configuration
 */
$chain = "Blocklist";
$safelist = array("x.x.x.x"
                 ,"y.y.y.y"
                 ,"z.z.z.z");
 
$data = shell_exec('iptables -S '.$chain);
$iparr = explode(' ',$data);
$j = 0;
$ref = array();
for($i=0;$i<sizeof($iparr);$i++) {
        if(substr_count($iparr[$i],".")==3) {
                $ref[$j] = $iparr[$i];
                $j++;
        }
}
sort($ref);
 
for($i=0;$i<sizeof($ref);$i++) {
        $ip = $ref[$i];
        $ref[$i] = "";
        if(stristr($ip,"0.0.0.0")) $ip="";
        if(strlen($ip)>2 && !in_array($ip,$safelist) && in_array($ip,$ref)) {
                echo "Duplicate IP found: $ip\r\n";
                while(in_array($ip,$ref)) {
                        shell_exec('iptables -D '.$chain.' -s '.$ip.' -j DROP');
                        $ref[array_search($ip,$ref)] = "";
                }
        }
 
}

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.

It is possible to monitor fan speeds and temperatures on Dell Poweredge servers under Linux. You can achieve this by reading out the IPMI data that is available on the system.
I used the steps on this website to buffer the data gathered by IPMI to use in Cacti.

However, in addition to Cacti I also use Munin to monitor various system parameters. Wouldn’t it be nice to incorporate graphs for fan speeds and temperatures in Munin? I thought so, so I developed a way to do this.
Read more…

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…

This is why, right here:

Gentoo kernel panic while emering courier-imap which triggered PaX
Oh well, the little card saved me a trip to Amsterdam, and the system appears to boot without any troubles after a hardpanic, so I guess that test is out of the way

While configuring your MTA and additional services on a Gentoo machine, you are likely to follow the handbook at http://www.gentoo.org/doc/en/qmail-howto.xml .
Though this guide is pretty good, at one point you will encounter a rather large annoyance.
Once you’re ready to set up webmail, by means of horde imp, it seems the only thing you have to do is
emerge horde-imp what should do the trick.
Usually this is true, except for the fact that imp heavily relies on a load of PEAR modules. These PEAR modules will be merged prior to merging imp, and this is where all goes to hell.
You probably had PHP preinstalled on the system, and each PEAR module (there’s about 25 of them for imp) will try to use your premerged PHP installation. If you used a default PHP merge, nearly every single one of them will break, because PHP was compiled without a USE flag that the module needs.
So you’ll find yourself adding the USE flag to your /etc/make.conf, re-emering php, and trying to re-emerge horde-imp afterwards, which results in the module installing, and the process breaking on the next module once more, forcing you to repeat the process. This can take you quite a while, since PHP isn’t quite the smallest package and even on a quite powerful server it takes nearly 10 minutes each run.

So.. how can you avoid a solid 3 hour emerge stint? By learning from my trial-and-error-process, and adding all of the needed USE flags to your /etc/make.conf:
pam tcpd ssl mysql apache2 cli pcre xml zlib ftp ctype pcre session imap
afterwards emerge php and emerge horde-imp and you’re good to go.

When you are building a non-generic linux kernel (e.g. when using ‘make menuconfig’), be sure to include the Device Driver for “megaraid_mbox”, otherwise your kernel won’t be able to locate your /dev/sda device!