Request Tracker and Fail2ban (Ubuntu)
Before I let RT out in the wild, our IT department wanted to have some protection against script kiddies and anyone trying to brute force their way in. They've used Fail2ban in the past, and installed it on our RT instance.
Trying to configure Fail2ban for RT was a bit of a challenge and took me a while to sort out, so below is a summary of the steps required to get it working on Ubuntu. I haven't tested this extensively, however initial results look promising. Use at your own risk.
I won't go into the installation of RT or Fail2ban, just configuration changes required to get it going.
Request Tracker version is RT 4.2.12.
Request Tracker RT_SiteConfig.pm
For Fail2ban to work, first it needs to see the RT log file date/time stamps in your local time zone.
It won't work with the RT default of GMT. As such, there is no reason pointing a Fail2ban 'jail' to the RT logfile /opt/rt4/var/log/rt.log
You need to set RT to log to the syslog file as the syslog daemon will then handle the time stamp formatting. Edit RT_SiteConfig.pm to include the following...
# Redirect RT logs to syslog for Fail2ban
Set($LogToSyslog, "warning");
Restart the webserver for the change to take effect.
Ubuntu syslog & RT Failed logins
Any login failures (indeed all RT log messages) now appear in /var/log/syslog. Login failures will look like this.
Feb 15 15:12:50 myrt RT: [38319] FAILED LOGIN for user from xx.x.x.xxx
However, this message will only appear each time the message changes (i.e. the user name changes), and the message will NOT appear each time a different password is used for the same user. Obviously, this is a problem as an attacker can then try many different passwords with the same username and only one message will be returned.
When a different message is eventually sent (i.e. a login failure for a different user name), you'll see something like this.
Feb 15 15:20:56 myrt RT: message repeated 17 times: [ [38319] FAILED LOGIN for user from xx.x.x.xxx]
Feb 15 15:22:50 myrt RT: [38319] FAILED LOGIN for test from xx.x.x.xxx
By default, the Ubuntu syslog has repeated message reduction turned on, which is the cause of the behavior seen above. To turn it off, edit /etc/rsyslog.conf.
Look for the section Filter duplicate messages and edit as per below.
# Filter duplicated messages
#$RepeatedMsgReduction on
# Turned repeat message reduction off so fail2ban can read every failed password attempt in syslog
$RepeatedMsgReduction off
After editing and saving the file, restart the syslog for changes to take effect.
sudo service rsyslog restart
Fail2ban jail file
We need to now make a new Jail in our jail file for RT specific connections over http/https.
Edit /etc/fail2ban/jail.local and add the following to it.
[apache-rt]
enabled = true
port = http,https
filter = requesttracker
logpath = /var/log/syslog
maxretry = 3
Above I've called my jail 'apache-rt'. It references a custom filter called 'requesttracker' that we will create shortly. Note above I'm working with jail.local and not jail.conf - read the Fail2ban installation and configuration documentation if you don't understand why.
Fail2ban filter file
You need to create a Fail2ban filter file that is tailored to the RT message format for failed logins.
Create a text file called requesttracker.conf in the path /etc/fail2ban/filter.d/ and add the following text to it.
# fail2Ban requesttracker filter
#
[Definition]
failregex = myrt RT: (?:\[\d+\]) FAILED LOGIN for .* from
ignoreregex =
Important: - In the failregex line above replace 'myrt' with the instance name of your RT.
Failure to do this will result in the failregex match failing on your system. To be honest, I only just realised this oversight as I was writing this. I'm not great with regular expressions, but cleverer people than I will undoubtedly suggest a good way to regex 'myrt' so it is fully portable.
A possible (totally untested) example that may work...
# fail2Ban requesttracker filter
#
[Definition]
failregex = .* RT: (?:\[\d+\]) FAILED LOGIN for .* from
ignoreregex =
Write out the file, and reload the jails.
sudo fail2ban-client reload
Hopefully that should be it. Three login failures (either due to consecutive bad user names or passwords) should ban your IP Address for HTTP/HTTPS requests for 10 minutes.
If it works, unban yourself with the following command in the shell.
sudo fail2ban-client set apache-rt unbanip xx.x.x.xxx