Guide to the Secure Configuration of WRLinux
with profile Basic Profile for Embedded SystemsThis profile contains items common to many embedded Linux installations. Regardless of your system's deployment objective, all of these checks should pass.
https://www.open-scap.org/security-policies/scap-security-guide
scap-security-guide
package which is developed at
https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for WRLinux, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Profile Title | Basic Profile for Embedded Systems |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_basic-embedded |
Revision History
Current version: 0.1.31
- draft (as of 2017-03-31)
Platforms
- cpe:/o:windriver:wrlinux:8
Table of Contents
Checklist
contains 11 rules | ||||||
System Settings [ref]groupContains rules that check correct system settings. | ||||||
contains 11 rules | ||||||
Account and Access Control [ref]groupIn 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. | ||||||
contains 11 rules | ||||||
Protect Accounts by Restricting Password-Based Login [ref]groupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the | ||||||
contains 4 rules | ||||||
Restrict Root Logins [ref]group
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 | ||||||
contains 1 rule | ||||||
Only Root Has UID 0 [ref]ruleIf 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 | ||||||
Proper Storage and Existence of Password Hashes [ref]group
By default, password hashes for local accounts are stored in the second field (colon-separated) in | ||||||
contains 3 rules | ||||||
Log In to Accounts With Empty Password Impossible [ref]rule
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
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.
Severity: high References: IA-5(b), IA-5(c), IA-5(1)(a) | ||||||
Password Hashes For Each Account Shadowed [ref]rule
If any password hashes are stored in
The hashes for all user account passwords should be stored in the file Severity: medium | ||||||
netrc Files Do Not Exist [ref]rule
The
Unencrypted passwords for remote FTP servers may be stored in Severity: medium | ||||||
Secure Session Configuration Files for Login Accounts [ref]groupWhen 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. | ||||||
contains 7 rules | ||||||
Ensure that No Dangerous Directories Exist in Root's Path [ref]groupThe active path of the root account can be obtained by starting a new root shell and running: $ sudo echo $PATHThis 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. | ||||||
contains 2 rules | ||||||
Ensure that Root's Path Does Not Include Relative Paths or Null Directories [ref]rule
Ensure that none of the directories in root's path is equal to a single
PATH=:/bin PATH=/bin: PATH=/bin::/sbinThese 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: low | ||||||
Ensure that Root's Path Does Not Include World or Group-Writable Directories [ref]ruleFor each element in root's path, run: $ sudo ls -ld DIRand 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: low | ||||||
Ensure that Users Have Sensible Umask Values [ref]group
The umask setting controls the default permissions for the creation of new files.
With a default | ||||||
contains 2 rules | ||||||
Ensure the Default Umask is Set Correctly in /etc/profile [ref]rule
To ensure the default umask controlled by umask 077Rationale: 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: low | ||||||
Ensure the Default Umask is Set Correctly in login.defs [ref]rule
To ensure the default umask controlled by UMASK 077Rationale: 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: low | ||||||
Limit the Number of Concurrent Login Sessions Allowed Per User [ref]rule
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 * hard maxlogins 1Rationale: 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
| ||||||
Ensure the Logon Failure Delay is Set Correctly in login.defs [ref]rule
To ensure the logon failure delay controlled by FAIL_DELAY 4Rationale: Increasing the time between a failed authentication attempt and re-prompting to enter credentials helps to slow a single-threaded brute force attack. Severity: low | ||||||
Ensure that User Home Directories are not Group-Writable or World-Readable [ref]ruleFor each human user of the system, view the permissions of the user's home directory: $ sudo ls -ld /home/USEREnsure 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 Warning:
This action may involve modifying user home directories.
Notify your user community, and solicit input if appropriate, before making this type of change.
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: low |