After mastering some basic Linux commands, adding and removing Linux software, and understanding the overall Linux filesystem, consider learning how to manage Linux user account security, which includes understanding:
- PAM.
- Different Linux account types.
- Enforcing good Password security.
- Shadow passwords and why they are important.
- Managing and forcing account expiry.
- Locking/unlocking accounts.
- Monitoring authentication logs and using intrusion detection systems.
- Multifactor authentication implementation.
Managing Linux User Account Security
- It’s easier to attack a system from the inside.
- Having a user account access makes life easier for an attacker in order to escalate privileges.
- Privilege escalation attacks are a major threat and one of the most common attacks methods.
- Involves gaining elevated access to protected resources by exploiting bugs/misconfiguration.
- Keep unwanted users out is the first line of defence.
- Secure accounts by implementing the concept of least privileges.
- This involves understanding how Linux user authentication works.
Understanding Linux’ Pluggable Authentication Modules
A centralized authentication system. Secur covered network user authentication in an earlier article.
Historically, each application required its own way to authenticate users, for example the login program would need to check the following files:
- /etc/passwd
- /etc/shadow
To make sure the credentials were valid
With PAM in place, applications offload that responsibility to PAM. As new authentication are developed, they can be configured to work with PAM
PAM Configuration Files
- PAM configuration files live in /etc/pam.d
- Each PAM aware application has a configuration file in this directory:
- /etc/pam.d/login
- /etc/pam.d/sshd
The configuration file has a list of directives:
PAM Module Interfaces (module_interface)
4 different types of interfaces that correspond to different aspects of the authentication process. A module may have 1 or more of these interfaces. Each interface generates a pass or fail output when called.
- auth – Authenticates users. Requests/verifies the validity of the password.
- account – Verifies if access is permitted. Validates restrictions on account access
- password – Changes a user’s password.
- session – Manages user’s sessions. Can mount a users home directory
PAM Control Flags (control_flag)
These simple control flags (there are many complex flags) act on the output of PAM Module Interfaces and tell PAM what to do with the result. Modules can be stacked in any order and the control flags determine how critical the pass or failure of any module interface is to the goal of user authentication:
Required – Module result must be successful to continue. If the test fails at this point, the user is not informed until all the test that reference this particular interface are complete.
Requisite – Like required, but no other modules are
invoked. User is notified on initial failure of the interface test
Sufficient – If a module marked with succeeds passes and no required modules. have failed, authenticates user and no other modules are checked at this point. If this fails, it is ignored and configuration directives are checked.
Optional – causes the result of the module tot be ignored unless it is the only module referencing the interface.
include – Includes all the lines configuration which match the given parameter and appends them as an argument to the module. This control flag is typically used to pull in configuration that applies to multiple PAM aware services.
There are many more complex flags that can be set using attribute=value pairs, a full list can be found in the PAM.d man page.
PAM Configuration File Example
In the sample file above, you can see the directives; the first word is the module interface, in this case “session”, the second is the control flag, in this directive it is required, followed by an authentication module, pam_evn.so.
Linux Account Password Security
Linux Account Types
Three main account types on a Linux system
- root, the superuser
- Root can do anything.
- Can see all files on the system
- Always has the UID of 0.
- Account name is actually meaningless
- Root can do anything.
- Linux System Account
- UIDs < 1,000
- Can be changed
- Configured in /etc/login.defs
- The command “useradd -r system_account_name” is used to create an account in system account range
- Normal User Accounts
- UIDs >= 1,000
- No real difference between system and user accounts other than organization by the system admin
- Intended for human (interactive) use
- UIDs >= 1,000
Password Security
- Enforce strong passwords.
- Users will use weak passwords and increase risk of brute force attack
- Use pam_pwquality, based on pam_cracklib, which was the older version of enforcing password quality
- Use this as directive in in a configuration file:
- /etc/security/pwquality.conf
- PAM Usage:
- password requisite pam_pwquality.so
- Module attributes: man pam_pwquality
Using Shadow Passwords
- Historically passwords are stored in an encrypted form in /etc/passwd , which is an unencrypted file.
root:$43L3Zdm2M3H3:0:0:root:/root:/bin/bash
- the second field is the password
- The downside of storing passwords in /etc/passwd is that the file is readable by all as lots of files read this document to convert usernames into uids.
- The encrypted password could be broken by someone running a dictionary attack.
- Would download the encrypted passwords to another system to run the attack so that the attacker would not leave a trail of attempted login in the system log.
- The solution is to enable Shadow Passwords
- This means that the password was originally stored in a hashed from:
- /etc/passwd unencrypted: root:$43L3Zdm2M3H3:0:0:root:/root:/bin/bash
- is replaced by an x in the unencrepted /etc/password file
- root:x:0:0:root:/root:/bin/bash
- The encrypted password is stored in /etc/shadow: root:$43L3Zdm2M3H3::0:99999:7:::
- /etc/shadow is only readable by the root user and reduces the system susceptibility to brute force attacks
- This means that the password was originally stored in a hashed from:
How to Convert Passwords to Shadow Passwords
If you come across a system not using the shadow password system, you can modify the system to doing so by running the following command as root.
- pwconv – convert to shadow passwords.
- pwunconv – convert from shadow passwords.
Format of /etc/shadow File
The format /etc/shadow (seen below) is of fields separated by colons “:”.
The fields in the file above are as follows (Please note that not all fields are filled out):
- Username
- Hashed password
- Days since epoch (January 1 1970) of last password change
- Days until change allowed
- Days before change required
- Days warning for expiration.
- Days before account inactive.
- Days since epoch when account expires.
- Reserved for future use.
chage: Display user account expiry info
- The image above shows the aging information associated with the root account.
- When the minimum number of days between password change is “0”, the user can change the password at any time.
- Administrators can use the chage command to change user account expiry info
- -M – Set the maximum number of days during which a password is valid. For example, “-M 25 account_name” would force the named account to change passwords every 25 days.
- -E – Date on which the user’s account will no longer be accessible. The EXPIRE_DATE format can be either:
- Days since epoch
- YYYY-MM-DD format
- -1 will unlock an account
- -d – Set the last day the password was changed. Set this option to “0” force password change on next login.
- Can combine these options.
How To Set The Default Account Aging Options
You can set the default account aging options in the /etc/login.defs file
- PASS_MAX_DAYS 99999
- Sets the default number of days for which a password can be used
- PASS_MIN_DAYS 0
- Minimum number of days between password changes
- PASS_MIN_LEN 5
- Sets a required minimum length for a password
- PASS_WARN_AGE 7
- Number of days in advance of password expiration that users are warned.
Preventing Password Reuse
- Use the following PAM directive to prevent password reuse:
password required pam_pwhistory.so- # remember=N’
- By default the pam_pwhistory.so module stores the last 10 passwords used by each account. To modify the number of passwords remembered, modify the “N” associated with the “remember” key.
Controlling Account Access
Locking and Unlocking accounts
- passwd -l : locks the user account.
- passwd -u : unlocks the user account.
- Another way to lock an account or make sure it is not used interactively is setting the account’s shell to nologin.
- Example:
- System account entries in /etc/passwd file:
- sql:x:41:41:Apache:/usr/share/httpd:/sbin/nologin
- www-data:x:39:39:www-data:/var/www:/usr/sbin/nologin
- If you were to switch to these accounts, you would get a message saying the account is not available
- You can manually edit the /etc/passwd file but the preferred way to change shells on an account is using the chsh command.
- format: chsh -s
- To lock someone out, set the shell account to no login
- chsh -s /sbin/nologin donald_t.
Centralized Authentication
- If you configure a system to authentication against a central system, when you lock and account you can lock everywhere
- Example authentication systems include:
- freeIPA
- LDAP
- Drawbacks associated with centralized authentication
- If a hacker attack the centralized login system, they get wide access.
Disabling Linux Logins
- Use the pam_nologin module when you want to lock people out for a period of time.
- Looks for /etc/nologin or /var/run/nologin
- Disables logins and displays contents of nologin file.
- Can place a message for users when they want to log in
- To re-enable login, remove the nologin file
Monitoring Authentication Logs
When users authenticate into a Linux system, their activty are recorded in log files The following commands will help you scan authentication logs quickly:
- “last” command
- Shows last users to log in.
- Pulls data from var/log/wtmp file.
- “lastb” command
- Shows failed login attempts.
- Pulls data from the var/log/btmp file.
- “lastlog” command
- Shows the last time a user has logged in
- Pulls from the /var/log/lastlog file
- Monitoring authentication logs
- Authentication data is stored in various files depending on your system’s configuration:
- /var/log/messages
- /var/log/syslog
- /var/log/secure
- /var/log/auth.log
Intrusion Prevention with fail2ban
- Rather than manually inspecting log files, use an IPS/IDS type system like fail2ban.
- Monitors log files.
- Configured to create a firewall rule:
- Blocks IP address of attacker after repeated attempts
- Automatic unban of an IP address after a period of time to allow for genuine connections that may be been misconfigured
- Not just for Linux logins, can work on apache, etc.
Multifactor Authentication
- Tightens up security
- Google Authenticator PAM module
- When you authenticate via, you will be sent a message on your Google Authenticator app that you need to enter to the host system.
- DuoSecurity’s pam_duo module
- RSA SecurID PAM module
Security by Account Type
Account Security – root
- Most important account
- Use a normal account for normal activities.
- Do not use root
- Avoid logging in as root; in fact, you should block root logins
- Escalate the privileges on your personal account
- Use sudo instead of su.
- sudo keeps a better audit trail
- Avoid using the same root password on every system.
- You want to make containers of security in the event of a breach.
- Ensure only the root account has UID 0.
- If another account has zero, they are root.
- awk -F: ‘($3 == “0”) {print}’ /etc/passwd
Disabling root Logins
- pam_securetty can disable root logins
- The directive below can disable them for you
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
○ /etc/securetty contains a list of locations where root is allowed to log in- For example if you want root to be able to log into console or tty1, list them in the file, each on a separate line.
- To allow no root logins, leave the file blank. Root logins will still be allowed in single user mode.
- The directive below can disable them for you
Disable root from SSH Logins
- In the /etc/ssh/sshd_config file
- Add this line: PermitRootLogin no
- Then reload the file:
- systemctl reload sshd
- Now you won’t be able to login as root user over SSH.
System / Application Accounts
- By default there are several application or services accounts on Linux.
- Best practice is to use one account per service.
- web service (httpd), web service account (apache)
- Don’t activate the account. Keep it locked. Set it to nologin for the shell.
- Don’t allow direct logins from the account.
- Can deny ssh access for specific accounts by using:
- sshd_config: DenyUsers
- Rather than share access to the account, use sudo for all access.
- sudo can be configured to run commands as other accounts, not just root.
- eg: $ sudo -u apache apachectl configtest
User Accounts
One account per person. We want to keep our audit trail intact.
Deleting Accounts
When people leave an organization, delete their accounts. Do the same with service accounts when you remove software.
- Determine the UID
- id ACCOUNT
- Delete their account and home directory
- userdel -r
- This does not remove other files that belong to the deleted user on the system as these files are associated with the UID (and could be assigned to a new user if they have the same UID as a deleted user). This means you need to search for files owned by users with a specific UID.
- find / -user UID
- find / -nouser finds all the files on a system with no owner.
Using and Configuring Sudo
sudo vs su
- “SuperUser Do” or “Substitute User Do”
- Use sudo instead of the su command.
- Complete shell access with su.
- With su you need to know the password of
the other account. - Breaks the Principle of Least Privilege.
- Vague audit trail with su.
- With su you need to know the password of
Sudo
- Fine grain controls.
- No need to share passwords.
- Clear audit trail.
- Sudo configuration live in /etc/sudoers.
- Additional configuration in /etc/sudoers.d.
Sudoers Format
- User Specification Format:
- user host=(run_as) command
- Examples:
jim webdev01=(root) /sbin/apachectl %web web*=(root) /sbin/apachectl
%wheel ALL=(ALL) ALL
- Examples:
- user host=(run_as) command
Sudo Authentication
- Sudo requires a user to authenticate.
- Default 5 minute grace period (timeout).
- You may not want to use a password.
Displaying the Sudo Configuration
- List commands you are allowed to run:
- sudo -l
- Verbose listing of commands: sudo -ll
- List commands another USER is allowed: sudo -l -U user
Running Commands with sudo
- Run as root:
- sudo COMMAND
- Run as USER:
- sudo -u USER COMMAND
- Get a shell
- sudo -s
- sudo -s -u USER
