Learning Objectives

By the end of this lab, you need to have acquired the following
knowledge and skill set:
• Understand the different files in the linux file system that
governs user account and password settings
• Secure user account and password settings

1
Recap: Key files for user account settings
What do these files contain?
• /etc/passwd - important file containing the list of user account, UID, GID, GECOS, home directory and login.
• /etc/shadow
- Stores the “password hashes” and also allowed password aging and expiration features to be implemented
- The capture below shows the “password hash” for the root account

- 6: Indicates SHA-512 hashing algorithm is used. A “1” indicates MD5 is used.

- NC6S0iuCR5Iy8MAy: The salt used to encrypt the hash. This is combined with the unencrypted password
and hashed using SHA-512 to generate the password hash. The use of the salt prevents two users with the
same password from having identical entries in the /etc/shadow file.
- ZaZtvDQzIKzWt ……… J7ci/: The encrypted hash.
- 16449: The number of days since January 1, 1970 (also called the epoch) that the password was last
changed.
- 2: The minimum number of days that must pass before the password can be changed. 0 indicates no
restriction.
- 90: The number of days that must pass before the password must be changed. 99999 indicates no expiry.
- 14: The number of days before password expiration during which the user is warned of the impending
expiration
- 16800: The number of days since January 1, 1970 when the account will be disabled.
• /etc/group – list the group names, GID and secondary members 2
Recap: Viewing and changing password-aging
parameters
max days (-M) inactive days (-I)

min days warn days

(-m) (-W)

time

last change password inactive

date (-d) expiration date
date
# chage -l root
# chage -m 0 -M 90 -W 7 -I 14 root

3
Recap: Default User Account Settings upon
Creation
# vi /etc/login.defs

See sample output on the right ->

This file determines the default

account / password settings when an
account is created.

Any changes to the account /

password settings after the account is
created is determined by the use of
chage command and the settings in
the “/etc/security/pwquality.conf”
file

# vi /etc/security/pwquality.conf
See next page for a sample output of
the pwquality.conf file

4
Recap: Password quality control

The following password quality settings can be

controlled after account creation using this file:
1. number of characters in the old
password that must not be present in
the new password
2. password length
3. number of digits
4. number of uppercase characters
5. number of lowercase characters
6. number of special characters

The settings can be configured for

maximum (positive) or minimum
(negative) number of characters.

5
Set Password Expiration Days
Description:
The PASS_MAX_DAYS parameter in /etc/login.defs allows an administrator to force passwords to expire
once they reach a defined age. It is recommended that the PASS_MAX_DAYS parameter be set to less
than or equal to 90 days.

Rationale:
The window of opportunity for an attacker to leverage compromised credentials or successfully
compromise credentials via an online brute force attack is limited by the age of the password. Therefore,
reducing the maximum age of a password also reduces an attacker's window of opportunity.

Verification:
Execute the following command to check whether the system has been configured as required:
# grep ^PASS_MAX_DAYS /etc/login.defs
PASS_MAX_DAYS <number of days>
The <number of days> should be determined by the organisation’s user account policies, in the
absence of which, the auditor should recommend an acceptable standard based on the nature of the
system. If the system is mission critical or holds very important information, this should be as low as 30
days. For other systems, it can be as high as 180 days. A generally acceptable standard is 90 days,
which is also mentioned by the CIS benchmark.
6
Set Password Expiration Days (Cont)
Verification:
Modifying the PASS_MAX_DAYS parameter in /etc/login.defs only affects new user accounts created
and existing accounts which has to change their passwords.
To check that all existing user accounts have been updated to the <number of days>, execute the
following command for each user account in the system:
# chage --list <user account name>
Maximum number of days between password change: <number of days>

Remediation:
If the system is not configured as recommended, set the PASS_MAX_DAYS parameter to <number of
days> in /etc/login.defs:
PASS_MAX_DAYS <number of days>

Modify active user parameters to match:

# chage --maxdays <number of days> <user account name>

7
Set Password Change Minimum Number of Days

Description:
The PASS_MIN_DAYS parameter in /etc/login.defs allows an administrator to prevent users from
changing their password until a minimum number of days have passed since the last time the user
changed their password. It is recommended that PASS_MIN_DAYS parameter be set to 7 or more days.

Rationale:
By restricting the frequency of password changes, an administrator can prevent users from repeatedly
changing their password in an attempt to circumvent password reuse controls.

Verification:
Execute the following command to check whether the system has been configured as required:
# grep PASS_MIN_DAYS /etc/login.defs
PASS_MIN_DAYS <number of days>
Similar to PASS_MAX_DAYS setting, the <number of days> should be determined by the
organisation’s user account policies, in the absence of which, the auditor should recommend an
acceptable standard based on the nature of the system. If the system is mission critical or holds very
important information, this should be as high as 15 days. For other systems, it can be as low as 1-2
days. A generally acceptable standard is 7 days, which is also mentioned by the CIS benchmark.

8
Set Password Change Minimum Number of Days
(Cont)
Verification:
Modifying the PASS_MIN_DAYS parameter in /etc/login.defs only affects new user accounts created
and existing accounts which has to change their passwords.
To check that all existing user accounts have been updated to the <number of days>, execute the
following command for each user account in the system:
# chage --list <user account name>
Minimum number of days between password change: <number of days>
Remediation:
If the system is not configured as recommended, set the PASS_MIN_DAYS parameter to <number of
days> in /etc/login.defs:
PASS_MIN_DAYS <number of days>

Modify active user parameters to match:

# chage --mindays <number of days> <user account name>

9
Set Password Expiring Warning Days

Description:
The PASS_WARN_AGE parameter in /etc/login.defs allows an administrator to notify users that their
password will expire in a defined number of days. It is recommended that the PASS_WARN_AGE
parameter be set to 7 or more days.

Rationale:
Providing an advance warning that a password will be expiring gives users time to think of a secure
password. Users caught unaware may choose a simple password or write it down where it may be
discovered.

Verification: Remediation:
# grep PASS_WARN_AGE /etc/login.defs Set the PASS_WARN_AGE parameter to 7 in
PASS_WARN_AGE 7 /etc/login.defs:

# chage --list <user> PASS_WARN_AGE 7

Number of days of warning before password

expires: 7 Modify active user parameters to match:
# chage --warndays 7 <user>

10
What are System Accounts?

Execute the following command:

# cat /etc/passwd
Which are the system accounts?

11
Disable System Accounts
Description:
There are a number of accounts provided with the Red Hat Enterprise Linux that are used to manage
applications and are not intended to provide an interactive shell.

Rationale:
It is important to make sure that accounts that are not being used by regular users are locked to prevent
them from being used to provide an interactive shell. By default, Red Hat sets the password field for
these accounts to an invalid string, but it is also recommended that the shell field in the password file be
set to /sbin/nologin. This prevents the account from potentially being used to run any commands.

It is also important as an IT auditor to know what are the purpose of some of these system accounts. The
table below list some of the common ones and their purpose:

User Group Description

root root Administrative user with all appropriate privileges

bin bin The bin user/group is included for compatibility with legacy
applications. New applications should no longer use the bin
user/group.

12
Disable System Accounts (cont)
User Group Description

root root Administrative user with all appropriate privileges

daemon daemon The daemon user/group was used as an unprivileged user/group

for daemons to execute under in order to limit their access to the
system. Generally not used now because daemons should run
under individual user/group in order to further partition daemons
from one another.
adm adm Administrative special privileges

lp lp Owner of files used by printing subsystem. Used for the printer

system. lp stands for line printer.
sync sync Similar to the shutdown user

shutdown shutdown Instead of logging on as a regular user and then issuing the
'sudo shutdown' command, simply log in as user "shutdown",
and the login takes care of running the shutdown command
immediately.
halt halt Similar to the shutdown user

mail mail Used by the sendmail application.

news news News special privileges

13
Disable System Accounts (cont)
User Group Description

uucp uucp Owner of hidden files used by uucp protocol. The uucp user
account is used for the UNIX-to-UNIX Copy Program, which is a
group of commands, programs, and files, present on most Unix
systems, that allows the user to communicate with another Unix
system over a dedicated line or a telephone line.
operator operator Operator special privileges

postfix postfix Account used to run the postfix application

man man Man special privileges

nobody nobody nobody is the conventional name of a user account which owns
no files, is in no privileged groups, and has no abilities except
those which every other user has. It is common to run daemons
as nobody, especially servers, in order to limit the damage that
could be done by a malicious user who gained control of them.
However, the usefulness of this technique is reduced if more than
one daemon is run like this, because then gaining control of one
daemon would provide control of them all. The reason is that
nobody-owned processes have the ability to send signals to each
other and even debug each other, allowing them to read or even
modify each other's memory.

14
Disable System Accounts (cont’d)
Verification:

Run the following command to determine if any system accounts can be accessed:
# awk -F: '($1!="root" && $1!="sync" && $1!="shutdown" && $1!="halt" && $3<1000 &&
$7!="/sbin/nologin") {print}‘ /etc/passwd

Remediation:
Execute the following commands for each misconfigured system account,
# usermod -L <user name>
# usermod -s /sbin/nologin <user name>

15
Set Default Group for root Account
Description:
The usermod command can be used to specify which group the root user belongs to. This affects
permissions of files that are created by the root user.

Rationale:
Using GID 0 for the root account helps prevent root-owned files from accidentally becoming accessible to
non-privileged users.

Verification: Remediation:
# grep "^root:" /etc/passwd | cut -f4 –d: # usermod -g 0 root
If the command returns “0”, then the system is
correctly configured.
Alternatively, you can run:
# grep “^root:” /etc/passwd
Check that the four field is a value of “0”

16
How is umask value set?

The tale of 2 files /etc/profile and /etc/bashrc

Open 2 terminals and in the first terminal run # vi /etc/profile while in the second terminal run # vi /etc/bashrc

Do you see a difference?

In the first terminal where /etc/profile is shown, look for the line umask=002 and change the value to 077.
Save the file.

Now press Ctrl-Alt-F2 and login as student with password=password

Type # umask
What value is returned?

17
How is umask value set?

Press Ctrl-Alt-F1 and logout of the root user account.

Login again using student and launch the terminal window again.
Type # umask
What value is returned?

What do you observe? Can you explain the behavior?

https://bencane.com/2013/09/16/understanding-a-little-more-about-etcprofile-and-etcbashrc/

18
Set Default umask for Users
Description:
The default umask determines the permissions of files created by users. The user creating the file has
the discretion of making their files and directories readable by others via the chmod command. Users
who wish to allow their files and directories to be readable by others by default may choose a different
default umask by inserting the umask command into the standard shell configuration files (.profile, .cshrc,
etc.) in their home directories.

Rationale:
Setting a very secure default value for umask ensures that users make a conscious choice about their
file permissions. A default umask setting of 077 causes files and directories created by users to not be
readable by any other user on the system. A umask of 027 would make files and directories readable by
users in the same Unix group, while a umask of 022 would make files readable by every user on the
system.

Verification: Remediation:
# grep "^umask 077" /etc/bashrc Edit the /etc/bashrc and /etc/profile.d/cis.sh files
umask 077 (and the appropriate files for any other shell
supported on your system) and add the
# grep "^umask 077" /etc/profile.d/* following the UMASK parameter as shown:
umask 077 umask 077

19
Ensure Password Fields are Not Empty
Description:
An account with an empty password field means that anybody may log in as that user without providing a
password.

Rationale:
All accounts must have passwords or be locked to prevent the account from being used by an
unauthorized user.

Verification: Remediation:
Run the following command and verify that no If any accounts in the /etc/shadow file do not
output is returned: have a password, run the following command to
# cat /etc/shadow | awk -F: '($2 == "" ) { print $1 " lock the account until it can be determined why
does not have a password "}‘ it does not have a password:

Alternatively, access the /etc/shadow file and check # /usr/bin/passwd -l <username>

that none of the line has an empty second field. In Also, check to see if the account is logged in
the screenshot below, notice that user1 has an and investigate what it is being used for to
empty second field. determine if it needs to be forced off.

20
Verify No UID 0 Accounts Exist Other Than root

Description:
Any account with UID 0 has superuser privileges on the system.

Rationale:
This access must be limited to only the default root account and only from the system console.
Administrative access must be through an unprivileged account using an approved mechanism such as
su command.

Verification: Remediation:
Run the following command and verify that only the Delete any other entries that are displayed.
word "root" is returned:
# /bin/cat /etc/passwd | /bin/awk -F: '($3 == 0) { print
$1 }‘
root
Alternatively, view the /etc/passwd file and check
that the only “root” has uid “0” [uid is the third field]

21