Pages

Wednesday, October 20, 2010

PCI DSS and Red Hat Enterprise Linux (Part #7)

Requirement 8: Assign a unique ID to each person with computer access

Summary

Most requirements presented in this chapter concern Linux password policy, which was described in details by CIS.

8.3 To verify that two-factor authentication is implemented for all remote network access, observe an employee (for example, an administrator) connecting remotely to the network.

The basic example of two-factor authentication for remote access is application of ssh certificates. To access a remote server, it is required to submit not only a file (“I do have”), but also the key to decrypt it (“I do know”). A key pair can be stored not only in the form a file, but also on a smart card.

A key pair is generated with the ssh-keygen command, for example:
ssh-keygen -t rsa -b 4096 -f /home/user/.ssh/remoteuser_at_remotehost

At that, two files will be created in the target directory (by default, it is $HOME/.ssh/): a file with the specified name (private key file) and a file with .pub extension (public key). By default, a file id_rsa[.pub] or id_dsa[.pub] is created depending on the chosen algorithm for the protocol 2. To cache decrypted keys, the ssh-agent utility is applied.

The password phrase for a private key should be not shorter than 5 symbols, but it is possible to create a key pair with an empty passphrase. Moreover, standard tools (in contrast to the mechanism of user passwords) do not allow one to define passphrase requirements. However, it is possible to determine from the private key file whether a passphrase was set for it (if so, the second line of the private key will contain an entry “ENCRYPTED”); for this purpose, perform the following actions with the root privileges:

for key in `find /home -type f \( -regex '.*/.ssh/.*' -a ! -name '*known_hosts*' -a ! -name '*.pub' \)`; do
found="`awk '(NR == 2) && /ENCRYPTED/ {print;}' "$key"`";
[ -n "$found" ] && echo "Key $key is OK" || echo "Key $key lacks its passphrase";
done

Besides the method described above, there are other implementations of two-factor authentication for SSH, including those based on USB tokens and smart cards. The worldwide leaders in this field that support Linux are Aladdin and Rainbow; on Russian market, the products of Activ company are also presented. However, the mentioned solutions are not included into the standard RHEL distribution kit, so they are not considered in this work.

8.4.a For a sample of system components, examine password files to verify that passwords are unreadable during transmission and storage.

8.4.b For service providers only, observe password files to verify that customer passwords are encrypted.

By default, the mechanism of local Linux authentication implies application of hash (MD5, SHA-1, and SHA-512) or encrypted (DES, Blowfish, etc.) passwords. To verify that such passwords are applied indeed, use the following command (for FC12):

[root@blacknet pam.d]# authconfig --test
...
shadow passwords are enabled
password hashing algorithm is sha512
...

Note. At that, RHEL4 will display a character-graphics menu. It is necessary to select “Cancel” from it; after that, the command will display settings in the console similarly to the case described above.

Corresponding settings are stored in the file /etc/sysconfig/authconfig; the following two strings serve for this task:

USESHADOW=yes
PASSWDALGORITHM=sha512

Attention. It is important to take into account that:
a) the hash function algorithm is specified not only here, but also in the PAM configuration files, which are located in /etc/pam.d/ (usually, it is an argument of the pam_unix.so module);
b) if the password hash function algorithm is changed, it is necessary to ensure synchronization of configuration files.
Furthermore, it is necessary to control the content of the file /etc/login.defs (which is used when handling user data), because it also contains definition of the password hash function algorithm.

8.5.3 Verify that first-time passwords for new users are set to a unique value for each user and changed after first use.

Standard Linux mechanisms do not allow one to configure this setting. Other UNIX systems may initially satisfy this requirement; for example, when an administrator changes some user password in AIX, the ADMCHG flag (“Changed by administrator”) is set for this password and the user will be obliged to change his/her password at next login.

However, it is possible to set the same behavior for Linux; for this purpose, execute the following commands when creating a new user:

useradd [options] newuser
passwd newuser
usermod -L newuser
chage -d 0 newuser
usermod -U newuser

After that, newuser will be obliged to change his/her password according to the applied password policy at next login (details are considered in chapter 8 below). Usermod commands (locking/unlocking) are applied so that the user will not be able to log in using the initial password set by an administrator.

To automate the process of user creation, one can develop a wrapper for the command passwd that will execute “chage -d0” for a specified user after the password is changed if the command was called by root. Here, it is necessary to take into account that if the wrapper is located in the same directory as passwd, then these modifications will be abolished in the course of a regular software update.

8.5.4 Select a sample of employees terminated in the past six months, and review current user access lists to verify that their IDs have been deactivated or removed.

It is easy to fulfill this requirement. For the selected users, verify that (one of the following options):
a) the account is removed from the system (there is no such user in /etc/passwd) or
b) the account is deactivated (the second field of the file /etc/shadow starts with the symbol “!” followed by the password hash or entirely consists of “!!”).

If a user was not removed, but deactivated, then it is recommended to check whether there are data owned by this user on the disc. This check is beyond the scope of the requirement, but it can be quite useful:

for bu in $blockedusers; do
find / \( -path /proc -o -path /sys -o -path /srv -o -path /dev -o -path /selinux \) -prune \
-o -user $bu -printf "%u %p\n";
done

8.5.5 Verify that inactive accounts over 90 days old are either removed or disabled.

There is no direct implementation of this mechanism in Linux, but the problem may be solved using password aging. For this purpose, maximum password age equal to 90 days (-M90) is set for existing users and a zero period is given to change a password after it becomes outdated (-I0):
chage -I0 -M90 -m7 -W14 user

In this example, the minimum period between successive password modifications (7 days) and the moment when the system offers a user to change the password (14 days before password expiration) are also set.
It is necessary to edit the following files to apply these settings to new users:

/etc/default/useradd:
INACTIVE=0
/etc/login.defs:
PASS_MAX_DAYS 90
PASS_MIN_DAYS 7
PASS_WARN_AGE 14

Attention. It is important to understand the difference between these two configuration files. /etc/default/useradd refers ONLY to the command useradd, and /etc/login.defs refers to all user commands. It is often necessary to edit the BOTH files if you work with useradd.

To change the default values, one can also use the following command:
useradd –D [-parameter value]
However, this command allows one to edit the content of /etc/default/useradd only.

8.5.6 Verify that any accounts used by vendors to support and maintain system components are disabled, enabled only when needed by the vendor, and monitored while being used.

For users from third-party organizations (integrators, co-developers, and outsourcers), it is necessary to apply access restriction mechanisms based on analysis of:
a) the login method (which implies the way a user can log in);
b) the login time (when a user can log in, e.g. only during working hours or only at weekends).

The both items are described in the requirement 7.2.1 (IX, X); however, the following conditions should be added here:
1. It is useful to unite accounts of users from third-party organizations into one group (or a set of groups), because it will simplify the process of configuring.
2. Access should be denied for such users by default (“deny everything that is not explicitly allowed”).
3. Accounts should be locked by default (see 8.5.4.2).
4. To control the actions of third-party users, it is necessary to configure a kernel-level auditing subsystem called auditd, which is described in details in chapter 10.

Let us assume that the members of the partners and support groups are allowed to log in only on weekdays from 9 till 18 o’clock from the network a.b.c.d/w.x.y.z. In this case, the rules of access to the system will look as follows:

/etc/pam.d/{system-auth,sshd} :
auth required pam_access.so nodefgroup

account required pam_time.so

There is no need in additional configuration of sshd if the option “auth include system-auth” is specified in it.
The nodefgroup parameter is used so that it is possible to specify group names in brackets and distinguish them from user names.

/etc/security/access.conf :
- : (support) (partners) : ALL EXCEPT a.b.c.d/w.x.y.z

Or (if a strict access policy is configured for all accounts):

+ : (support) (partners) : a.b.c.d/w.x.y.z
... (settings for other users) ...
- : ALL : ALL

/etc/security/time.conf – this file doesn’t allow one to state system groups; it is necessary to specify all accounts of third-party users in explicit form (let us assume that these are user1, user2, and user3):
sshd;pts*;user1 | user2 | user3;Wk0900-1800

From the rule syntax, one can see that time.conf is more restrictive, because if an entry for some users is found, then the module will grant them access to the system ONLY during the time periods specified in settings.

Note. With the current pam_time implementation, you can only define the time when users are allowed to login, but you cannot limit the session duration. Thus, if a member of the support group will log in to the system at 17:59, then this user will be able to work as long as he/she wants. To implement restriction of session duration, one can develop additional scripts that will track the processes of specified users and terminate them forcibly when operation is denied (according to time.conf).

8.5.8.a For a sample of system components, examine user ID lists to verify the following
Generic user IDs and accounts are disabled or removed.
Shared user IDs for system administration activities and other critical functions do not exist.
Shared and generic user IDs are not used to administer any system components.

To fulfill this requirement, it is necessary to deny root login. After that, it will be possible to track actions of every administrator. Otherwise, we will fail to find out who exactly performed some actions as root.

The required settings should be applied at least to the following two configuration files: /etc/ssh/sshd_config and /etc/security/access.conf.

Generic accounts may be interpreted both as accounts used by applications (daemon, bin, nobody, ftp, etc.) and accounts with predictable names (admin, user, test, etc.). The simplest way to check whether a user was locked is to analyze the second field in the file /etc/shadow; if the value is “*” or starts with “!”, it means that the corresponding user is locked. Furthermore, login may be denied to a user because his/her password expired, the limit of failed login attempts was exceeded, or for the reason of access time restrictions (/etc/security/time.conf).

8.5.9 For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to change periodically and that customers are given guidance as to when, and under what circumstances, passwords must change.

This requirement corresponds to the CIS item 9.3.
The following command should be executed for every user as in the item 8.5.5 of PCI DSS:
chage -I0 -M90 -m7 -W14 $USERNAME

After this, system configuration files are edited to apply the specified settings to new users (if the options of the command useradd are not redefined).

/etc/default/useradd :
INACTIVE=0
/etc/login.defs :
PASS_MAX_DAYS 90
PASS_MIN_DAYS 7
PASS_WARN_AGE 14

8.5.10 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least seven characters long. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to meet minimum length requirements.

In the file /etc/pam.d/system-auth, the following argument should be specified for the module pam_crackilb.so:
minlen=7

Furthermore, it is recommended to delete the argument nullok for the module pam_unix.so from the files in directory /etc/pam.d, because this parameter allows one to use empty passwords. A similar requirement from CIS is given in the item 11.4.

Note 1. It is impossible to check the length of existing passwords. However, you can set the minlen parameter and then oblige all users to change their passwords (a simple script using “chage -d0 $USERNAME” call for every detected system user will be necessary).

Note 2. Root is allowed to set a user password that doesn’t meet the complexity requirements.

8.5.11 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to contain both numeric and alphabetic characters. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to contain both numeric and alphabetic characters.

Configuring the system in accordance with this requirement is similar to the procedure for the item 8.5.10, with the difference that other arguments are used:
dcredit=-1 lcredit=-1 ucredit=-1

This string defines that a password must contain at least one uppercase letter, one lowercase letter, and one digit. For this PAM module, it is impossible to specify the number of letters directly (only the numbers of uppercase and lowercase letters separately).
A CIS analogue is the item 11.4. Also, see notes to the item 8.5.10.

8.5.12 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords. For service providers only, review internal processes and customer/user documentation to verify that new customer passwords cannot be the same as the previous four passwords.

It is necessary to create a file /etc/security/opasswd, set access permissions 600 for it, and then specify the following parameter in the string “password … pam_unix.so …” of the file /etc/pam.d/system-auth for the module pam_unix.so:
remember=4

After that, hashes of all passwords set by users will be stored in the specified file.
The standard CIS RHEL v1.1.2 contains no recommendations on password history storage.

Note. When a user password is modified by root, the new value is not logged in the given file.

8.5.13 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that a user’s account is locked out after not more than six invalid logon attempts. For service providers only, review internal processes and customer/user documentation to verify that customer accounts are temporarily locked-out after not more than six invalid access attempts.

For every generation of RHEL (4, 5, or 6 – FC12), the settings are different. Let is consider them in the order 4, 6, 5.

For RHEL4, the file /etc/pam.d/system-auth should contain the following strings:

auth required pam_tally.so onerr=fail no_magic_root
This string must be placed BEFORE the string

auth required /lib/security/$ISA/pam_deny.so

account required pam_tally.so deny=5 no_magic_root reset
This string must be placed BEFORE the string
account required /lib/security/$ISA/pam_permit.so

Five failed attempts to log in are specified, because the module’s logic will add 1 to the given value.
In RHEL4, PAM settings for sshd are taken from the system settings by default; therefore, it is not necessary to edit them.

In FC12 (and RHEL6), the following actions should be performed to configure the system:
The file /etc/pam.d/system-auth should contain the following string (set off in bold):

auth required pam_env.so
auth required pam_tally2.so onerr=fail deny=6 unlock_time=1800

This string must be placed into the block “auth required”, because the sequence order of modules is important. The unlock time is specified in seconds; if the unlock_time parameter is not given, then it will be possible to unlock a user only manually.

The file /etc/pam.d/sshd should contain the above string and the string given below so that account locking is applicable to remote logon, too:
auth include system-auth
For RHEL5, it is admissible to use both pam_tally and pam_tally2. In the former case, it is necessary to set options by analogy with pam_tally2 for RHEL6 (in the same configuration files and with the same string position requirements):
auth required pam_tally.so onerr=fail deny=6
(the new pam_tally version doesn’t add 1 to the specified value)
In the latter case (pam_tally2), the settings coincide with those for pam_tally2 in RHEL6.

Attention. The settings given in the section SN.8 of the standard CIS RHEL v1.1.2 are not applicable to RHEL5 and FC12.

Note. If default settings are applied, then input of an incorrect password for sudo is equated to a failed login; however, input of an incorrect password for passwd doesn’t increase the counter of failed login attempts.
Furthermore, if user1 will try to switch to a locked user2:
su - user2
then the counter of failed login attempts of user2 will also increase.


8.5.14 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account.

Here, the settings depend on the distribution version (as in the previous item).

In RHEL4, the module pam_tally doesn’t allow one to unlock a user; for this purpose, it is necessary to execute the following command:
pam_tally --user=$USERNAME --reset

For FC12 (RHEL6), the file /etc/pam.d/{system-auth,sshd} should contain the following string:
auth required pam_tally2.so onerr=fail deny=6 unlock_time=1800

This string defines that a user will be unlocked in 1800 seconds after the failed login attempt that resulted in locking. If the parameter unlock_time is not specified, then the module will not automatically unlock users; to unlock them manually (which is allowed by the standard), it will be necessary to execute the following command:
pam_tally2 --user=$USERNAME --reset

For RHEL5, it is admissible to use any one of these two methods to unlock users (depending on what method is configured in the system).

Note. If a user tries to log in before the unlock_time period expires (or before root unlocks him/her manually), the counter of failed login attempts will increase and the time of automatic unlocking will be delayed.
In the example given below, the user is locked after three successive failed login attempts; the unlocking time is 30 seconds. If the user will try to log in earlier (e.g. in 20 seconds), then the unlocking time will be delayed.

[root@blacknet pam.d]# grep pam_tally2 /etc/pam.d/sshd
auth required pam_tally2.so onerr=fail deny=3 unlock_time=30
[feodor@blacknet .ssh]$ ssh user@localhost
user@localhost's password:
Last login: Wed Jul 7 11:01:23 2010 from localhost.localdomain
[user@blacknet ~]$ sudo date
[sudo] password for user:
Sorry, try again.
[ … ]
sudo: 3 incorrect password attempts
[user@blacknet ~]$ logout
Connection to localhost closed.
[feodor@blacknet .ssh]$ sleep 20; ssh user@localhost
user@localhost's password:
[ … ]
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
[feodor@blacknet .ssh]$ sleep 20; ssh user@localhost
user@localhost's password:
Permission denied, please try again.
[ … ]
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
[feodor@blacknet .ssh]$ sleep 35; ssh user@localhost

user@localhost's password:
Last login: Wed Jul 7 11:03:03 2010 from localhost.localdomain
[user@blacknet ~]$

8.5.15 For a sample of system components, obtain and inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less.

The KDE4graphic session idle time out is specified separately by every user in the file $HOME/.kde/share/config/kscreensaverrc. The following parameters concern session idle time out:

Enabled=true
Lock=true
LockGrace=X
Timeout=Y

Here, X is the time (in milliseconds) between the moment of screensaver launching and the moment of screen locking; Y is the idle time (is seconds) to launch a screensaver. According to the requirement, Y+(X/1000) is less than 900.

1 comment:

  1. Regarding 8.5.15, you can set timeout to OpenSSH connections using the following directives in sshd_config:
    ClientAliveInterval 300
    ClientAliveCountMax 0

    ReplyDelete