Configuring Fail2Ban on Debian Squeeze

This always start with a package installation:

$ aptitude install fail2ban

Then I simply create a local configuration file where I’ll put all my custom config:

$ touch /etc/fail2ban/jail.local

Here is the content of that file:

[DEFAULT]
# Do not filter connexion from my apartment and from the server itself
ignoreip  = 127.0.0.1 88.123.123.123 91.123.123.123
# Ban for a week
bantime   = 604800
maxretry  = 3
destemail = user@example.com
banaction = iptables-allports
action    = %(action_mwl)s

[ssh]
enabled  = true
port     = 22
maxretry = 2

[ssh-ddos]
enabled = true
port     = 22

[apache]
# Apache basic auth
enabled   = true
maxretry  = 3
# Ban for 1 hour
bantime   = 3600

[apache-noscript]
enabled = true

[apache-overflows]
enabled = true

[apache-badbots]
enabled  = true
filter   = apache-badbots
port     = http,https
action   = iptables-allports
logpath  = /var/log/apache*/*access.log
maxretry = 1

[apache-nohome]
enabled  = true
filter   = apache-nohome
port     = http,https
action   = iptables-allports
logpath  = /var/log/apache*/*access.log
maxretry = 1

[exim]
enabled  = true
filter   = exim
port     = smtp,ssmtp
action   = iptables-allports
logpath  = /var/log/exim*/rejectlog
maxretry = 1

[exim-relay]
enabled  = true
filter   = exim-relay
port     = smtp,ssmtp
action   = iptables-allports
logpath  = /var/log/exim*/rejectlog
maxretry = 1

While adjusting Fail2Ban, I was surprised by how sensitive this software is. It can just refuse to start without any notice in the log or on the command line. Even if its log_level variable is set to 4 (= DEBUG) in /etc/fail2ban/fail2ban.conf.

In such a case, a sure way to find the culprit is to use a brute force debugging method: first set all the enabled variable of your jail.local‘s sections to false. Then activate one section after another until Fail2Ban refuse to restart.

For me, the problem was that I forgot to add my custom exim-relay filter to Fail2Ban. So I fixed my issue by creating an empty file at /etc/fail2ban/filter.d/exim-relay.conf in which I pasted the following content:

# Based on default exim.conf filter by Cyril Jaquier
# Real life exemaple:
# 2009-07-02 08:16:42 H=118-167-129-21.dynamic.hinet.net (91.121.198.84) [118.167.129.21] F=<titieueue@hotmail.com> rejected RCPT <s2288@mail2000.com.tw>: relay not permitted

[Definition]

# Option:  failregex
# Notes.:  regex to match use of my exim mail server as a relay it does not
#          allow.
# Values:  TEXT
#
failregex = \[<HOST>\] .*(?:relay not permitted)

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Speaking of custom filters, here is one to filter DFind scans (file located at /etc/fail2ban/filter.d/apache-w00tw00t.conf):

# Based on http://howflow.com/tricks/block_w00tw00t_scan_hosts_with_fail2ban
# Real life exemaple:
# [Sat Jun 27 16:43:08 2009] [error] [client 94.23.57.77] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Definition]

# Option:  failregex
# Notes.:  regex to match the w00tw00t scan messages in the logfile.
# Values:  TEXT
failregex = ^.*\[client <HOST>\].*w00tw00t\.at\.ISC\.SANS\.DFind.*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
ignoreregex =

And here is the corresponding section from my jail.local file:

[apache-w00tw00t]
enabled  = true
filter   = apache-w00tw00t
action   = iptables-allports
logpath  = /var/log/apache*/*error.log
maxretry = 1

Cool Cavemen WebDesign Retrospective

Here is a collection of all themes I created for the Cool Cavemen website over the years.

Before settling on its current name, the Cool Cavemen project was referred to by its members as The Ultimate Band (talk about rock-star egos…). Here is a screenshot of the theme I did for e107:

In fact the original HTML mockup this theme is based on still exists. It is dated back to November 1st, 2004, which is now the official Cool Cavemen anniversary. The theme above was created two weeks later.

When I created the Cool Cavemen’s site, I choose e107. Back then I perceived it to be the only Open Source PHP-based CMS having the best balance between a clean and a powerful theme engine. That was my opinion before decided to switch to WordPress.

At the end of November ’04, our theme was updated to this:

The header above is based on a photo of a green laser, that was taken by Cool Cavemen’s guitarist.

2005 started with an updated version of the theme, featuring a photo of Cool Cavemen’s first gig. They were only three on stage, our bass player was still drumming at the time:

In February we finally had our official photo featuring all members of the band ! But it was cold outside so we added some fur to keep our website warm:

I spent the next months trying to build my own version of the Holy Grail: a perfect CSS-based 3-columns fluid layout (with a middle column placed in the top of the HTML). This explain Eric Mayer‘s quote in these mockups and the references to the Skidoo Too template:

I never found the Holy Grail, and the tests above remained unseen by the public. Tired by this journey, I never touched the theme again.

Until September 2005 when I updated it to this:

Notice the box in the top of the right column, which was designed to publish a new track every week. The code behind this box is available in another article.

So that was the last major version of the theme. Basically our e107 site looked that way for most of its life.

In November 2005 I attempted to reboot the theme. I made these 3 propositions to the band:

The last one had an interactive header, with tiny sketches showing up on mouse over:

Unfortunately we didn’t found any of these themes matching the Cool Cavemen spirit (whatever that is). If these alternatives were publicly discussed, we decided that no one was going to replace our previous theme.

The final update we made was when our Raw EP was released. We basically applied filters on the header to match Raw’s cover. We also updated our logo to use the one designed for us by QPX:

e107 Importer v1.3 released

A month after the last one, here is a brand new version of my e107 Importer, numbered 1.3.

This version add loads of polishing and is not far from being feature-complete. I think I’m reaching the end of the active development of this plugin. I don’t see the need to add new features.

I also feel this way because last week, I succeeded in moving to WordPress all news and pages from the old e107′s Cool Cavemen website. I now only need to import all forums to definitively get rid of e107 from my life. At that point, I will declare the plugin no longer active. This mean I will no longer update it, but will still integrate code other developers are willing to contribute.

Before that happen, I will of course release one or two revisions of this plugin in the next few months. But expect bug fixes and tiny enhancements, not big new features.

That being said, here is the changelog of the brand new e107 Importer 1.3:

  • Upgrade embedded e107 code with latest 0.7.25.
  • Redirect imported images to attachments.
  • Purge invalid mapping entries on import.
  • Replace old e107 URLs in content by new WordPress permalinks.
  • Allow both imported and already-existing content to by updated with new permalinks.
  • Let user specify the list of e107 forums to import.
  • Phased imports should work without major problems.

e107 Importer 1.2 is out, with an enhanced BBCode parser.

Here is a brand new version of my e107 Importer plugin. This release fix lots of nasty bugs. Better, I added an enhanced BBCode parser which try to clean-up what e107′s parser output. This new parser also try to align the final HTML with what WordPress produce by default.

As usual, my plugin is available on the official WordPress plugin directory.

Here is the detailed changelog:

  • Upgrade e107 code to match latest 0.7.25-rc1.
  • Fix variable bleeding when importing items in batches.
  • Add a new way of handling e107 extended news using WordPress’ excerpts.
  • Parse BBCode and replace e107 constants in news excerpt.
  • Use internal WordPress library (kses) to parse HTML in the image upload step.
  • Do not upload the same images more than once.
  • Add a new enhanced BBCode parser on top of the one from e107. Make it the default parser.
  • Each time we alter the original imported content, we create a post revision.

Feed Tracking Tool released under an Open-Source license

I’ve just open-sourced the Feed Tracking Tool project (aka “FTT”), my first (and only) Ruby on Rails experience.

This tool was developed within Uperto, the company I currently work for, for its internal needs. The project had an ancestor written in 2006 that was based on Pylons. It was a prototype and was barely working. Iterating over the abandoned Python code base was considered a waste of time. So in summer 2007, it was decided to rewrite this application from scratch.

As my co-worker was available and already played with Ruby on Rails, he was tasked to create the initial code base. I joined the project early on, as it was a great opportunity to play with the (then really trendy) Ruby on Rails framework.

At the end FTT was essentially a test project to explore Ruby on Rails. It was never deployed on a production server and was never used.

After roting for more than 3 years, and representing absolutely no business value in itself, I decided to release it under a GPLv2 license (with Uperto’s approval of course). My intention with this open-source release is to share back knowledge and code with the community.

FTT was living in a private Subversion repository at Uperto, but we unfortunately lost it. During the last few weeks I tried to rebuild the code history from old and partial backups. I then used my Git-based reconstruction method to consolidate everything in a Git repository. The code is now available on GitHub.

I don’t plan to maintain this project. But I may reboot it in the future if I need feed-related features, or if I need an excuse to play with Ruby on Rails again. But for now beware: the code is quite outdated and is only running on old Rails 1.2.x. This project should be considered as an ugly legacy code base. So please be indulgent while looking at FTT’s code: it was the work of unexperienced RoR developers ! ;)

Why I chose Ubercart instead of Magento or osCommerce.

About a year ago a friend asked me why I chose the Ubercart/Drupal combo as the engine for Cool Cavemen’s online shop. He specifically asked me why not choose Magento or osCommerce. I never really took the time to answer him. Let’s fix this.

First, I selected a couple of web eCommerce solution based on the same requirements upon which I choose WordPress some years ago. Namely:

  • Open-source free software
  • Active project
  • Healthy community

I excluded osCommerce right away. I quickly played with it in 2005 and in 2007 for projects that never came to fruition. And I keep a really bad memory of these experiences: both code and templates felt poorly designed and implemented. That’s why osCommerce is classified in my brain as a giant legacy code base, hard to maintain. Maybe the project has evolved a lot since then. I should have looked back at it, but was attracted by another project…

…which was Magento. So yes, I seriously considered to use Magento at some point. It looked great. And clean. But digging deeper I found that something was missing.

My shop was supposed to sell tee-shirts for the band. And a tee-shirt is a product that can have lots of variations:

  • different colors (white, black, yellow, …),
  • of different sizes (S, M, L, X, XL, …),
  • in different shapes (teeshirt, hoodie, sweatshirt, …),
  • for different peoples (guy, girl, baby, …).

I wanted to track stocks and prices for each combination. And this degree of complexity is not supported by Magento. To be fair, I remember to have heard of this feature, but was only available in a third party module (that I don’t remember the name). Alas, this module was proprietary. That is the main reason I discarded Magento.

And then I found Ubercart, which allowed me to do exactly what I wanted. Here is for example prices and stocks for a black Cool Cavemen tee-shirt:

I use Ubercart since 2008 and I’m really happy with it. The future is interesting, as Ubercart was forked as the Drupal Commerce project a year ago. I’m waiting for the 1.0 release of the latter to decide if it is worth switching to the fork or not. But having it based on Drupal 7 is good news, as Ubertcart still stick to the (old) Drupal 6.