Linux – How does changes in /etc/pam.d/common-session-noninteractive affect fail2ban and possibly other programs/services

fail2banlinuxpamUbuntu

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@mycompany.com


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 from session [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.

Best Answer

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.

Related Solutions

Linux (Ubuntu vs CentOS) LDAP Client for 389-ds – password policy

I have been playing around with 389-ds on Ubuntu for a work project and came across the exact same issue.

I'm not sure about copying the config over from CentOS - I didn't have a box handy.

But when I looked and read up on PAM, it turned out to all be in the file /etc/pam.d/common-account.

pam_unix.so was above pam_ldap.so, and it also had [success=2 default=ignore], which means if it succeeds skip the next two rules, and for anything else, ignore the line.

Now since LDAP accounts are valid UNIX accounts since we added ldap to /etc/nsswitch.conf, this rule will return success and the pam_ldap.so module will never get run.

To get around this, my /etc/pam.d/common-account now looks like this:

# here are the per-package modules (the "Primary" block)
account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet
account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet
account [success=2 user_unknown=ignore default=ok]      pam_ldap.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

As you can see, I've also added some rules in there to only allow users in either the LDAP group "auth-access", or system users with a UID below 500 to be seen as valid accounts.

And to explain a little:

We hit the first rule

account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet

Which succeeds if the user is in that group and if so, we skip the next line as we know that'll fail (they're a valid LDAP user, so they won't have a system UID below 500) - if it doesn't succeed, return a fail (bad).

Then the next rule if it wasn't skipped

account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet

So if this on succeeds (because the UID is below 500), reset the fail value set by the module above, because they won't be part of that LDAP group.

And the important part

account [success=2 user_unknown=ignore default=ok]      pam_ldap.so

Check the LDAP server for the account status - if it succeeds, we know an LDAP user is a valid UNIX user, so go ahead and skip the next two lines (to take us to pam_permit.so and let the user login). If the user is unknown to the LDAP server, ignore this line and move to the next one - and for all other statuses, "ok" means it's ok to pass those return codes as-is, which will pass things like password expired, etc.

And then:

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so

We weren't a valid LDAP user if we hit this rule, so check if we're a valid system user - if succeed, skip next 1 line (takes us to pam_permit.so). Otherwise, ignore, which will take us to pam_deny.so.

Hope that helps explain a little more - the document that helped me if I wasn't very easy to understand was: http://uw714doc.sco.com/en/SEC_pam/pam-4.html

Regards, iamacarpet

Ubuntu – fail2ban not working on fresh install of ubuntu 14.04, why

not sure if related but I deleted and recreated /var/log/auth.log, because I needed to empty it, to debug the situation

This could well be the problem. It's likely that the syslog daemon is still writing to the original fd. You should try restarting the syslog daemon to see if it starts to log to the correct file.

service rsyslog restart

Once you have messages going to the auth.log it should start working.