Category Archives: Technical

Technical

Knocking out multiple fail2ban notifications to admin

Ever since I’ve been troubleshooting and tweaking Fail2ban, it seems the ban notifications sent to the server admin email address has steadily increased. For example, a ban event currently sends 5 identical emails to the server admin.

I thought it was my limited understanding of how Fail2ban worked. But I soon realized that the culprit had to be multiple instances of Fail2ban causing the behavior. I had to dig up some Linux/Centos knowledge on how to figure out where to pull up processes (similar to the Windows services and task manager).

To show a master list of processes and pids:
ps aux || less

To display a list of pids with the name “fail2ban”:
pgrep fail2ban

To kill all pids with the name “fail2ban”:
pkill fail2ban

However, this kills all but one server instance of the Fail2ban server. I still had to start the server, reload the configuration and verify the status to ensure that it worked.

Remember to save and reload iptables prior to and after the above operations.

Technical

Fail2Ban configs

I was fed up with all the dictionary attacks on POP3. So I decided to lookup configuring Fail2ban on that port.

First off, always remember to save your iptables: service iptables save

Next, I located the jail.local file saved under /etc/fail2ban. This file is a copy of the original /etc/fail2ban/jail.conf which I want to leave untouched.

Based on the following code, I will modify it to follow the current filters in my jail.local file. So that:

[courierauth]

enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
logpath = /var/log/mail.log

Will turn into this:

[pop3]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
action = iptables[name=POP3, port="smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s" protocol=tcp]
sendmail-whois[name=POP3, dest=anna@ffdepot.com, sender=fail2ban@ffdepot.com]
logpath = /var/log/maillog
maxretry = 3
ignoreip = 184.7.254.24 202.62.124.147 200.74.244.86 127.0.0.1

The newly revised code is enabled and scans the default mail ports. It creates a jail called POP3 and scans the appropriate mail log specified by logpath. The maxretry before banning is set to 3 tries. Fail2ban will then email the whois info of the IP to me, similar to what it does for SSH attempts today. The filter calls on /etc/fail2ban/filter.d/courierlogin.conf which contains the regex format which Fail2ban uses to scan mail log entries:

failregex = LOGIN FAILED, .*, ip=\[\]$

Once the jail.local file is saved, restart the Fail2ban server:


fail2ban-server -x
fail2ban-client reload
fail2ban-client status

Which responds with the corresponding number of jails, which includes one called POP3.

Afterwards, I reloaded my iptables again:

service iptables restart

Then to view the iptables: iptables -nL
Stay tuned this weekend to see if this new config pays off.

Technical

Killing stopped jobs

Sometimes I’ve had to CTRL-Z my way out of a Linux (Centos) command line that won’t work, accumulating a list of stopped jobs. This makes exiting impossible because the server will report that there are stopped jobs.

Use the following command line to get a list of stopped jobs:

jobs

Then by applying the following, the job can be killed and terminated right away without resorting to a process id number. Just enter the corresponding jobs number after the percent sign:

kill -9 %1

Once all the stopped jobs are killed, you can exit gracefully.

Technical

Fail2ban usage pains

What a pain it’s been trying to figure out how to get Fail2ban working again. I discovered that I no longer was receiving Fail2ban notifications some time mid January, and it’s been annoying as hell trying to get it to restart. The magic command line that got me back on track was to restart the server instance by deleting the socket file:

fail2ban-server -x

This command kick-started the service into daemon mode. So now it was a matter of reloading the configuration:

fail2ban-client reload

Thus when running fail2ban-client status, the system responded with the number of jails and a jail list.

Retrieving the status of the jail, I could already see that Fail2ban had gone straight to work:

fail2ban-client status ssh-iptables

Therefore, when I checked iptables -L, the newest banned IP showed up at the top of the list for the fail2ban-SSH chain. And, I was getting my ban notification emails again.