I have certain users who only use IMAP clients for their email. One of the GroupWise components I have to facilitate this is a standalone GWIA running as a SMTP submission service on encrypted port 587 and this has worked well for many years. I have always required that users log in to SMTP before they can send to prevent this from becoming a spam relay. I use LDAP authentication. Recently I’ve had a problem with hackers running brute force password crackers against my submission port which causes the intruder lockout counter on my LDAP accounts to increase and in many cases go over the threshold, thereby locking out the user.

I was not able to find any settings within GroupWise that could somehow deal with this. Not even the class of service settings work here because that relies on knowing who the user is in order to allow or block them from a service. Essentially a user has to login in so class of service can then deny them which is too late in this case. The damage is already done before login by increasing the intruder lockout count while trying to login in every time a bad password is attempted. This is a problem for any user in the system, not just my IMAP/smtp users.

Just a little background: For my first attempt at a quick temporary fix I wrote a script that would login as whatever user was affected at regular intervals which would then reset the intruder lockout count for that particular user. This made it so the affected users could do their daily work without getting randomly locked out all day long, but was only a quick stopgap and certainly no long term solution. As more and more users were starting to get affected by this I had to do something, and since GroupWise itself doesn’t have any way to deal with it I wrote this script which monitors the GWIA log for intruder attempts and then if it finds any it will modify the firewall so that the intruder’s IP is blocked from further attempts. Keep in mind these password crack attempts don’t just come from one IP. They come from many IP’s all at once in a concerted effort to crack someone’s account. Some days I get tens of thousands of bad login attempts coming from hundreds of IP’s, so an automated system is the only way to deal with this.

The script is written in Perl and runs on the same server that the GWIA is actually running on. I run my GWIA on SLES 11 sp3 so these directions are designed for that. My GWIA is running the 2012 version, and I don't know if this will work for other versions of GroupWise either. The built in firewall for your server must be configured to run before this script can be ran. Once the firewall is running you have to enable custom rules by editing the file: /etc/sysconfig/SuSEfirewall2

Find the line that contains:

#FW_CUSTOMRULES=”/etc/sysconfig/scripts/SuSEfirewall2-custom”

Uncomment it then save it .

Then edit the file:
/etc/sysconfig/scripts/SuSEfirewall2-custom and scroll to the bottom. Insert a line that says:

#GWIABLOCK

right before the second to last line that says “true”. This is so the script knows what block to insert the new rules in which is the input chain of the firewall.

Edit the script file itself and change the logfolder variable to match wherever your GWIA log folder is. Then just run the script with a cron job as often as you feel necessary. It looks for 3 or more bad password attempts in a log file before blocking, but you can change that to whatever you like. Since legitimate users who have a client already set up typically have the SMTP password saved, the chances of a bad password from a real user are pretty slim.

Just a few things to note since my main goal was to whip this up really quickly. When the script runs it only looks at the last log file that has been created. Therefore the least number of log files that are created each day, the more accurate it will be when considering how many bad logins per day. I increased the default log file size of my system so that it is less likely to need to create multiple files, but if the GWIA has to restart, then it will always create a new file. The script cannot currently deal with more then 9 log files in a day. I’ve never had that problem, so I didn’t account for it, but something you should be aware of in case you do.

There is no provision for removing blocked IPs other then to edit the /etc/sysconfig/scripts/SuSEfirewall2-custom file and removing the entry manually in case of a false positive.

The other problem I’ve noticed is that the data from GWIA doesn’t actually make it to the log file until about 10 minutes after the fact. This 10 minute delay has the potential for allowing a long string of password attempts before the script even has a chance to see it, so there is a potential for intruder lockouts to still occur. If there’s some other file like a tmp file somewhere that has realtime log info I’d sure love to know about it.

Since I’ve started using this script I haven’t had anyone get locked out and have the benefit of knowing that my users are safer against brute force password cracking attempts.

Download the script: gwia_intruderblock.zip