Tuesday, March 28, 2017

PCI DSS and Red Hat Enterprise Linux Part 7

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 ";
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.