Well. Here we are!

New year, new approach to blogging.

In the past year I haven’t managed to push out a lot of blog articles though I’ve been working with loads of new, interesting technologies and approaches.

Being a programmer, I blame the software I use to blog. In my case that’s the TYPO3 installation at rem.co. It’s recently been updated to TYPO3 6.0, and I haven’t gotten around to fixing all the bugs that appeared after such a major upgrade.

Moreover, that site uses the ancient tt_news plugin as a blog substitute, which makes blogging a bit… troublesome to put it mildly. Especially “advanced” stuff like including code snippets and multiple layouts in one article.

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.

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.

This article is only available in Dutch.

Sinds een recente verhuizing beschik ik thuis over een Ziggo Alles-in-1 Plus pakket, met internet, tv, én telefonie.

Daarvoor maakte ik gebruik van een Cisco VoIP netwerk op basis van een externe SIP provider. Natuurlijk wilde ik mijn Cisco netwerk blijven gebruiken, maar dan wel op basis van de Ziggo telefonie aansluiting.

Helaas maakt Ziggo gebruik van het PacketCable protocol over EuroDocsis, in plaats van SIP. Daarnaast heeft het Motorola SurfBoard modem dat bij het Ziggo abonnement geleverd wordt geen SIP interface voor het LAN, maar beschikt over 2 POTS poorten op RJ11 connectoren.

On my servers I use the nifty program Fail2Ban to perform logbased automatic firewalling 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.