I’ve been in the industry a while. I learned Unix and Linux administration in the mid to late 90s. I remember the old monolithic configurations, and I’ve seen the overly complex modular configurations for things we have now.
So yesterday, I thought I was all good on Fail2Ban today’s logcheck emails show there were still problems with Dovecot.
|
1 2 3 4 5 6 7 8 |
May 2 12:12:07 village auth: pam_unix(dovecot:auth): check pass; user unknown May 2 12:12:07 village auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=internet rhost=201.249.206.34 May 2 12:12:07 village auth: pam_unix(dovecot:auth): check pass; user unknown 2015-05-02 12:07:04,643 fail2ban.filter [3798]: INFO [dovecot] Found 201.249.206.34 2015-05-02 12:07:04,804 fail2ban.actions [3798]: NOTICE [dovecot] 201.249.206.34 already banned 2015-05-02 12:12:07,168 fail2ban.filter [3798]: INFO [dovecot] Found 201.249.206.34 2015-05-02 12:12:07,173 fail2ban.actions [3798]: NOTICE [dovecot] 201.249.206.34 already banned |
Yesterday, going through email yesterday, mostly logcheck emails, I found that Apache wasn’t blocking the attackers. It was seeing them, but not adding the ip address to iptables block list.
The fix was setting up the maxretry it was set rather high, I moved it down to 1 like I had it in the past. I also adjusted the search time to 1 hour and the ban time to 7 days. I thought I was good, and didn’t give it a second thought.
Today, looking at the logcheck emails (really it’s a great IDS for system admins to get a view into their box), there are a lot of automated attacks on the mail server NOT BEING BLOCKED!!! It worked yesterday, there were even banned ip addresses in the chain.
After lots of digging, and several changes that didn’t work, I decided to go for the bad option.
|
1 2 3 4 5 6 7 |
cd /etc/ # I was several folders deep at the time apt-get purge fail2ban cd fail2ban mv jail.local.bakup ~ cd .. rmdir fail2ban apt-get install fail2ban |
Really the real reason was that Fail2Ban had been around for a while. Things changed, and I had a weird mishmash of configuration files. After the install I removed the files in the package that were not debian related, not sure why bsd; osx; or fedora are in the Debian package to start with.
Followed the local customization file directions creating jail.d/server-defaults.conf with apache-auth and dovecot in them. ssh is handled by defaults-debian.conf. Why the new file, in case the Debian one gets over-written by new stuff later.
Restart the service and…
Still not working for dovecot.!? (tailing the log and watching iptables).
Turns out, it’s where Fail2Ban was set for default to watch for login errors for Dovecot (also noted through the logs). It’s looking in /var/log/mail.warn. I don’t know if I changed it, or it’s legacy left over, or what, but my box it’s /var/log/auth.log where Dovecot login failures go. So I added the logpath to jail.d/server-defaults.conf, restarted Fail2Ban and it worked.
This week The Debian project released “Jessie” (Debian 8.0) as stable. I like to keep my servers a little more ahead of the curve than that, so I upgraded to the new testing branch “Stretch”.
While going through my logs from yesterday and this morning, log checker is awesome, I saw someone hitting my mail server. Normally you only get 1 chance to log in as a non-existent account before Fail2ban kicks in and adds the ip address to my Netfilter iptables jail. This address kept showing up, hour after hour in the logs, and multiple user names.
Looking, I found out that while running, it wasn’t catching all the rules for Fail2ban. I checked the configuration files, and things checked out OK. So I fell back on the old restart the service and see what errors pop.