Archive for April, 2011
While this article is a good starting point, I thought it was worth documenting some more details on configure Fail2Ban for these applications.
To begin, install Fail2Ban:
sudo aptitude install fail2ban
Ensure that your application is logging access attempts. I have Apache in front of both standalone applications:
LogLevel warn ErrorLog /var/log/apache2/jira-error.log CustomLog /var/log/apache2/jira-access.log combined
Next, update the /etc/fail2ban/jail.local file:
[confluence] enabled = true filter = confluence action = iptables-allports[name=Confluence, protocol=all] sendmail-whois[name=Confluence, dest=root, sender=fail2ban] logpath = /var/log/apache2/confluence-access.* maxretry = 5 bantime = 300 [jira] enabled = true filter = jira action = iptables-allports[name=JIRA, protocol=all] sendmail-whois[name=JIRA, dest=root, sender=fail2ban] logpath = /var/log/apache2/jira-access.* maxretry = 5 bantime = 300
You’ll see I decided to ban the offending IP from all ports, not just port accessed. After 5 failed attempts at logging in, the IP is banned for 5 minutes.
Now, setup a filter file for each application:
[Definition] failregex = <HOST>.*"GET /login.jsp <HOST>.*"POST /rest/gadget/1.0/login ignoreregex =
[Definition] failregex = <HOST>.*"GET /login.action <HOST>.*"POST /dologin.action ignoreregex =
Finally, restart Apache and Fail2Ban:
sudo /etc/init.d/apache restart && sudo /etc/init.d/fail2ban restart
I wrongly assume Fail2Ban was working just fine. I recently audited it’s logs and found very little in the way of banning. I tried to get banned from another host via ssh, but that failed:
2011-04-11 12:32:02,098 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q fail2ban-ssh-iptables returned 100
2011-04-11 12:32:02,099 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
Luckily, someone else posted a solution to this on serverfault.
def __processCmd(self, cmd, showRet = True):
beautifier = Beautifier()
for c in cmd:
time.sleep(0.1) ## Added per http://serverfault.com/questions/84569/fail2ban-error-gentoo
I created a custom field for a project with a custom field type of Number. It quickly became evident that this should have been a Text Field instead. Unfortunately, you can’t change this in JIRA (at least not without some convoluted custom field configuration scheming).
Direct SQL access to the rescue!
First, stop JIRA before access the database directly:
--This will change the field type to text UPDATE customfield set customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:textfield', customfieldsearcherkey = 'com.atlassian.jira.plugin.system.customfieldtypes:textsearcher' where cfname = '<customfield_name>'; --Find all the possible values that need to be changed select distinct numbervalue from customfieldvalue where customfield = (select id from customfield where cfname = '<customfield_name>'); --each of these values will be included in the case statement update customfieldvalue SET stringvalue = case when numbervalue = 1 then '1' when numbervalue = 2 then '2' when numbervalue = 3 then '3' else stringvalue end where customfield = (select id from customfield where cfname = '<customfield_name>'); --Now, remove the number values that were copied to string values UPDATE customfieldvalue set numbervalue = null where customfield = (select id from customfield where cfname = '<customfield_name>');
Now, you can start JIRA and check that everything went as planned. Once you’ve confirmed the changes, you should reindex JIRA.