pam Archives : FATMIN

This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however, then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.

So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.

The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,

Below is my stock /etc/pam.d/system-auth file

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.

[root@ip-172-31-21-28 pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=root
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.

Much Todo About Linux/RHEL Passwords

RHEL6 – How to Manually Logout of an Iscsi Disk

Fun With PAM: Working with pam_cracklib and pam_tally2

Plugable Authentication Modules, or PAM, is the standard mechanism that most Unix and Linux Operatng Systems use for user credential authentication. By design, PAM is broken out into a number of files, each with a specific purpose. Before you can get started with PAM you need to understand a bit about how PAM configuration files are formatted. So lets get into that first before we try to bite off anything more.

PAM Config File Standards:

PAM config files follow a standard format as shown below.

Rule Types Control Module [module arguments]

There are 4 Rule Types

auth – used to authenticate users/passwords
account – set properties for a user's account
password – controls password changes
session – sets and controls environmental variables

And there are 5 Control Types

required – a module that a user is required to pass
sufficient – a user is not required to pass a sufficient module
optional – these modules do not have to be passed sucessfully
include – these rules reference other PAM config files
requisite – similar to required, but if failed, no further rules are checked

Configuring pam_cracklib:

Pam_cracklib is used to define password complexity. It has several module arguments that can be used to define password complexity and lenght. Its most common arguments are show below

ucredit – when used in the following format (ucredit=-n) requires the defined number of uppercase characters in a password
dcredit – when used in the following format (dcredit=-n) requires the defined number of digits in a password
ocredit – when used in the following format (ocredit=-n) requires the defined number of other (think symbols) type charaters in a password
lcredit – when used in the following format (lcredit=-n) requires the defined number of lower case letters in a password
minclass – defines the minimum number of different character classes that must be present in a password.
minlen – defines the minimum required lenght of a password.

Here's a usage example of the cracklib module from a /etc/pam.d/system-auth file. In this example try_first_pass tells pam to try to use any cached credentials, while retry allows a user to try their password 3 times before the fail this module.

password requisite pam_cracklib.so minlen=8 ocredit=-1 ucredit=-1 try_first_pass retry=3

Configuring pam_tally2:

Pam_tally2 can be used to lock users after a defined number of failed login attempts. The example below, taken from the system-auth file will lock a user after 3 failed login attempts, will automatically unlock the user after 300 seconds, and will do so quietly, without any notification to the user.

auth required pam_tally2.so deny=3 unlock_time=300 quiet

The command pam_tally2 can be used to list users with failed logins and can also be used to reset a user's failed login count. See reset example below

pam_tally2 –reset –u testuser

Note that pam_tally2 deprecates the faillock module.

Supplementary PAM Configuration Options:

Want to limit a user to a particular number of concurrent ssh sessions? You can set this up in /etc/security/limits.conf if you are calling the pam_limits.so in your pam configs. Limits.conf provides the example below. Just copy the format and you are off to the races. Remember to remove the #.

#@student - maxlogins 4