Fail2Ban on Ubuntu 10.04
Configuration files
/etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1
bantime = 10 # made for test purposes
maxretry = 3
backend = polling
destemail = [email protected]
banaction = iptables-multiport
mta = sendmail
protocol = tcp
action = %(action_mw)s
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
[pam-generic]
enabled = true
filter = pam-generic
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 6
The rest of the fail2ban configs are just the default ones.
default /etc/pam.d/common-session-noninteractive
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_unix.so
session optional pam_winbind.so
session required pam_loginuid.so
changed /etc/pam.d/common-session-noninteractive
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
session required pam_unix.so
session optional pam_winbind.so
session required pam_loginuid.so
Please note the only difference is adding session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid.
Logs
extract from /var/log/auth.log with default /etc/pam.d/common-session-noninteractive
May 22 15:30:01 node1 CRON[16029]: pam_unix(cron:session): session opened for user root by (uid=0)
May 22 15:30:01 node1 CRON[16029]: pam_unix(cron:session): session closed for user root
May 22 15:35:01 node1 CRON[16514]: pam_unix(cron:session): session opened for user root by (uid=0)
May 22 15:35:01 node1 CRON[16514]: pam_unix(cron:session): session closed for user root
Summary
- If I execute
fail2ban-client set ssh banip 1.2.3.4
in 15:26 the IP will get banned at 15:30. This is why I associate it with the above listed cron job. - If I modify
/etc/pam.d/common-session-noninteractive
and repeat the fail2ban-client command, got no entry in/var/log/auth.log
and no ban.
More info:
default
/etc/pam.d/common-session-noninteractive
:fail2ban-client set ssh banip 1.2.3.4
-> the IP gets banned by an invisible cron job, which runs every 5 minutes. I checked every single file in/etc/cron*
and/var/spool/cron/*
and there was no such job present. Bottom line: the manual ban works with up to 5 minutes delay.added
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
in/etc/pam.d/common-session-noninteractive
as suggested here:fail2ban-client set ssh banip 1.2.3.4
-> the invisible cron job does not run and no ban happens.
My question:
how does the change in /etc/pam.d/common-session-noninteractive
prevents the fail2ban-client to ban an IP? And why?
Edit
- Running in debug:
root@node1:~# fail2ban-client set loglevel 4 Current logging level is DEBUG root@node1:~# fail2ban-client -vvv set ssh banip 1.2.3.4 DEBUG Reading /etc/fail2ban/fail2ban DEBUG Reading files: ['/etc/fail2ban/fail2ban.conf', '/etc/fail2ban/fail2ban.local'] INFO Using socket file /var/run/fail2ban/fail2ban.sock DEBUG OK : '1.2.3.4' DEBUG Beautify '1.2.3.4' with ['set', 'ssh', 'banip', '1.2.3.4'] 1.2.3.4 root@zap:~# tail -f /var/log/fail2ban.log 2013-05-24 21:32:07,695 fail2ban.comm : DEBUG Command: ['set', 'ssh', 'banip', '1.2.3.4'] 2013-05-24 21:32:07,696 fail2ban.filter : DEBUG Currently have failures from 1 IPs: ['1.2.3.4'] 2013-05-24 21:32:07,696 fail2ban.filter : DEBUG Currently have failures from 1 IPs: ['1.2.3.4'] 2013-05-24 21:32:07,696 fail2ban.filter : DEBUG Currently have failures from 1 IPs: ['1.2.3.4']
Result: No Ban.
- Removing
quiet
fromsession [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
in/etc/pam.d/common-session-noninteractive
:
Result: Successful Ban.
/var/log/auth.log
:
May 24 22:00:01 node1 CRON[22483]: pam_succeed_if(cron:session): requirement "service in cron" was met by user "root"
May 24 22:00:01 node1 CRON[22483]: pam_succeed_if(cron:session): requirement "service in cron" was met by user "root"
/var/log/fail2ban.log
:
2013-05-24 21:56:07,955 fail2ban.comm : DEBUG Command: ['set', 'loglevel', '4']
2013-05-24 21:56:20,155 fail2ban.comm : DEBUG Command: ['set', 'ssh', 'banip', '1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 21:56:20,156 fail2ban.filter : DEBUG Currently have failures from 1 IPs: ['1.2.3.4']
2013-05-24 22:00:01,079 fail2ban.filter : DEBUG /var/log/auth.log has been modified
2013-05-24 22:00:01,079 fail2ban.filter.datedetector: DEBUG Sorting the template list
2013-05-24 22:00:01,853 fail2ban.filter : DEBUG /var/log/auth.log has been modified
2013-05-24 22:00:01,853 fail2ban.filter.datedetector: DEBUG Sorting the template list
2013-05-24 22:00:01,870 fail2ban.actions: WARNING [ssh] Ban 1.2.3.4
2013-05-24 22:00:01,870 fail2ban.actions.action: DEBUG iptables -n -L INPUT | grep -q fail2ban-ssh
2013-05-24 22:00:01,876 fail2ban.actions.action: DEBUG iptables -n -L INPUT | grep -q fail2ban-ssh returned successfully
2013-05-24 22:00:01,877 fail2ban.actions.action: DEBUG iptables -I fail2ban-ssh 1 -s 1.2.3.4 -j DROP
2013-05-24 22:00:01,919 fail2ban.actions.action: DEBUG iptables -I fail2ban-ssh 1 -s 1.2.3.4 -j DROP
2013-05-24 22:00:01,920 fail2ban.actions.action: DEBUG
2013-05-24 22:00:01,923 fail2ban.actions.action: DEBUG returned successfully
...
Fail2Ban version
fail2ban 0.8.7.1-2~ppa7~lucid from here. The stock one (version 0.8.4) kept failing with:
"global name 'time' is not defined"
which prompt me to look for newer version.
I think (but not confirmed) what fail2ban simply waits for new lines in auth.log before applying fail2ban-client command, so ban is done not by "an invisible cron job, which runs every 5 minutes" but "by infinite loop which reads 'logpath'", auth.log in the particular case. If this is true, change you have done in /etc/pam.d/common-session-noninteractive does not prevent the fail2ban-client to ban an IP, but postpones it till any new line appear in auth.log. New log lines appear less frequently, because you disabled cron messages, and it is necessary to wait longer for IP ban.