Request Tracker and Fail2ban (Ubuntu)

From Request Tracker Wiki
Revision as of 16:36, 6 April 2016 by Admin (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

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 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

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]

Feb 15 15:22:50 myrt RT: [38319] FAILED LOGIN for test from

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.


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



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



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