Infosec from @rattis' point of view

Monthly Archives: May 2015

I just finished reading The Linux Journal’s “Geek’s Guide to Enterprise Monitoring Success“. It was good, talking about how to leverage the monitoring to work for the IT department in an organization. This also talked about some business problems you can face, which I’ve seen first hand. I’ve been in the “metrics from another group’s monitoring tools” meeting before. Trust me, you need to be sure of yourself and what you’re doing for the company before that happens. I’ve also seen monitoring systems destroyed because the wrong people had too much access and trying to tune the system for their needs only.

For what it was, this was a good guide. From the title though, I expected something different.

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.