Group
Guide to the Secure Configuration of WRLinux
Group contains 8 groups and 11 rules |
Group
System Settings
Group contains 7 groups and 11 rules |
[ref]
Contains rules that check correct system settings. |
Group
Account and Access Control
Group contains 6 groups and 11 rules |
[ref]
In traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
WRLinux. |
Group
Protect Accounts by Restricting Password-Based Login
Group contains 2 groups and 4 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
Group
Restrict Root Logins
Group contains 1 rule |
[ref]
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands.
Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators.
Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account.
The login program uses the file /etc/securetty to determine which interfaces should allow root logins.
The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation).
The default securetty file also contains /dev/vc/* .
These are likely to be deprecated in most environments, but may be retained for compatibility.
Furthermore, /dev/hvc* represent virtio-serial consoles, /dev/hvsi* IBM pSeries serial consoles, and finally /dev/xvc0 Xen virtual console.
Root should also be prohibited from connecting via network protocols.
Other sections of this document include guidance describing how to prevent root from logging in via SSH. |
Rule
Only Root Has UID 0
[ref] | If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed. | Rationale: | An account has root authority if it has a UID of 0.
Multiple accounts with a UID of 0 afford greater opportunity for potential intruders to guess or decrypt the password for a privileged account.
Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero | Identifiers and References | References:
CCI-000366, AC-6, IA-2(1) | |
|
Group
Proper Storage and Existence of Password Hashes
Group contains 3 rules |
[ref]
By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow .
This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them.
However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd , or to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration. |
Rule
Password Hashes For Each Account Shadowed
[ref] | If any password hashes are stored in /etc/passwd (in the second field, instead of an x ), the cause of this misconfiguration should be investigated.
Every affected account should have its password reset and the hash should be properly stored, or the account should be deleted entirely. | Rationale: | The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd , which is readable by all users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed | Identifiers and References | References:
CCI-000201, IA-5(h) | |
|
Rule
netrc Files Do Not Exist
[ref] | The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory.
These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used.
Any .netrc files should be removed. | Rationale: | Unencrypted passwords for remote FTP servers may be stored in .netrc files.
DoD policy requires passwords be encrypted in storage and not used in access scripts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_netrc_files | Identifiers and References | References:
CCI-000196, IA-5(h) | |
|
Rule
Log In to Accounts With Empty Password Impossible
[ref] | If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication.
Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords. | Rationale: | If an account has an empty password, anyone could log in and run commands with the privileges of that account.
Accounts with empty passwords should never be used in operational environments.
Note that if the output includes nullok-secure but not nullok , then the vulnerability is limited to the specified set of terminals listed in /etc/securetty . | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords | Identifiers and References | References:
IA-5(b), IA-5(c), IA-5(1)(a) | |
|
Group
Secure Session Configuration Files for Login Accounts
Group contains 2 groups and 7 rules |
[ref]
When a user logs into a Unix account, the system configures the user's session by reading a number of files.
Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration.
If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account.
Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. |
Group
Ensure that Users Have Sensible Umask Values
Group contains 2 rules |
[ref]
The umask setting controls the default permissions for the creation of new files.
With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system.
Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files.
If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.
|
Rule
Ensure the Default Umask is Set Correctly in login.defs
[ref] | To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK 077 | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and written to by unauthorized users. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | Identifiers and References | | |
|
Rule
Ensure the Default Umask is Set Correctly in /etc/profile
[ref] | To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:
umask 077 | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile | Identifiers and References | References:
CCI-000366, SA-8 | |
|
Group
Ensure that No Dangerous Directories Exist in Root's Path
Group contains 2 rules |
[ref]
The active path of the root account can be obtained by starting a new root shell and running:
$ sudo echo $PATH
This will produce a colon-separated list of directories in the path.
Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code.
Since root may sometimes work inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user.
It is a good practice for administrators to always execute privileged commands by typing the full path to the command. |
Rule
Ensure that Root's Path Does Not Include Relative Paths or Null Directories
[ref] | Ensure that none of the directories in root's path is equal to a single
. character, or
that it contains any instances that lead to relative path traversal, such as
.. or beginning a path without the slash (/ ) character.
Also ensure that there are no "empty" elements in the path, such as in these examples:
PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
These empty elements have the same effect as a single . character. | Rationale: | Including these entries increases the risk that root could
execute code from an untrusted location. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_root_path_no_dot | Identifiers and References | References:
CCI-000366, CM-6(b) | |
|
Rule
Ensure that Root's Path Does Not Include World or Group-Writable Directories
[ref] | For each element in root's path, run:
$ sudo ls -ld DIR
and ensure that write permissions are disabled for group and other. | Rationale: | Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_root_path_dirs_no_write | Identifiers and References | References:
CCI-000366, CM-6(b) | |
|
Rule
Ensure that User Home Directories are not Group-Writable or World-Readable
[ref] | For each human user of the system, view the permissions of the user's home directory:
$ sudo ls -ld /home/USER
Ensure that the directory is not group-writable and that it is not world-readable.
If necessary, repair the permissions:
$ sudo chmod g-w /home/USER
$ sudo chmod o-rwx /home/USER | Rationale: | User home directories contain many configuration files which affect the behavior of a user's account.
No user should ever have write permission to another user's home directory.
Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed.
Typically, user home directories should not be world-readable, as it would disclose file names to other users.
If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_home_dirs | Identifiers and References | References:
CCI-000225, AC-6(7) | |
|
Rule
Ensure the Logon Failure Delay is Set Correctly in login.defs
[ref] | To ensure the logon failure delay controlled by /etc/login.defs is set properly, add or correct the FAIL_DELAY setting in /etc/login.defs to read as follows:
FAIL_DELAY 4 | Rationale: | Increasing the time between a failed authentication attempt and re-prompting to enter credentials helps to slow a single-threaded brute force attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_logon_fail_delay | Identifiers and References | | |
|
Rule
Limit the Number of Concurrent Login Sessions Allowed Per User
[ref] | Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks.
This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts.
To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf :
* hard maxlogins (N/A) | Rationale: | Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins.
Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_max_concurrent_login_sessions | Identifiers and References | | |
|