Guide to the Secure Configuration of Fedora

Description

This guide presents a catalog of security-relevant configuration settings for Fedora operating system formatted in the eXtensible Configuration Checklist Description Format (XCCDF). 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).

Notices

Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Selected profile

TitleCommon Profile for General-Purpose Fedora Systems
IDxccdf_org.ssgproject.content_profile_common

Revision History

Current version: 0.0.4

  • draft (as of 2015-09-28)

Platforms

  • cpe:/o:fedoraproject:fedora:23
  • cpe:/o:fedoraproject:fedora:22
  • cpe:/o:fedoraproject:fedora:21

Checklist

contains 68 rules

System Settingsgroup

contains 61 rules

Installing and Maintaining Softwaregroup

The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

contains 5 rules

Updating Softwaregroup

The yum command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update. Fedora systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Tools such as yum or the graphical Software Update ensure usage of RPM packages for software installation. This allows for insight into the current inventory of installed software on the system, and is highly recommended.

contains 2 rules

gpgcheck Enabled In Main Yum Configurationrule

The gpgcheck option should be used to ensure checking of an RPM package's signature always occurs prior to its installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section: gpgcheck=1

references:  SI-7, MA-1(b), 352, 663

gpgcheck Enabled For All Yum Package Repositoriesrule

To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form: gpgcheck=0

references:  SI-7, MA-1(b), 352, 663

Software Integrity Checkinggroup

Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system. Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

contains 3 rules

Verify Integrity with AIDEgroup

AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION.

contains 1 rule

Disable Prelinkingrule

The prelinking feature changes binaries in an attempt to decrease their startup time. In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink: PRELINKING=no Next, run the following command to return binaries to a normal, non-prelinked state: $ sudo /usr/sbin/prelink -ua

references:  CM-6(d), CM-6(3), SC-28, SI-7

Remediation script:
#
# Disable prelinking altogether
#
if grep -q ^PRELINKING /etc/sysconfig/prelink
then
  sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink
else
  echo -e "\n# Set PRELINKING=no per security requirements" >> /etc/sysconfig/prelink
  echo "PRELINKING=no" >> /etc/sysconfig/prelink
fi

#
# Undo previous prelink changes to binaries
#
/usr/sbin/prelink -ua

Verify Integrity with RPMgroup

The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database: # rpm -qVa See the man page for rpm to see a complete explanation of each column.

contains 2 rules

Verify and Correct File Permissions with RPMrule

The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it: # rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: # rpm --setperms PACKAGENAME

references:  AC-6, CM-6(d), CM-6(3), 1493, 1494, 1495

Verify File Hashes with RPMrule

The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: # rpm -Va | grep '^..5' A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: # rpm -qf FILENAME The package can be reinstalled from a yum repository using the command: yum reinstall PACKAGENAME Alternatively, the package can be reinstalled from trusted media using the command: rpm -Uvh PACKAGENAME

references:  CM-6(d), CM-6(3), SI-7, 1496

File Permissions and Masksgroup

Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.

contains 4 rules

Verify File Permissions Within Some Important Directoriesgroup

Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.

contains 4 rules

Shared Library Files Have Restrictive Permissionsrule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: # chmod go-w FILE

references:  AC-6, 1499

Shared Library Files Have Root Ownershiprule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command: # chown root FILE

references:  AC-6, 1499

System Executables Have Restrictive Permissionsrule

System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: # chmod go-w FILE

references:  AC-6, 1499

System Executables Have Root Ownershiprule

System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: # chown root FILE

references:  AC-6, 1499

Account and Access Controlgroup

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 Fedora.

contains 13 rules

Protect Accounts by Restricting Password-Based Logingroup

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.

contains 11 rules

Restrict Root Loginsgroup

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.

contains 4 rules

Direct root Logins Not Allowedrule

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to his machine as root via Telnet, which sends the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command: echo > /etc/securetty

references:  IA-2(1)

Virtual Console Root Logins Restrictedrule

To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty: vc/1 vc/2 vc/3 vc/4

references:  AC-6(2), 770

Serial Port Root Logins Restrictedrule

To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty: ttyS0 ttyS1

references:  AC-6(2), 770

Only Root Has UID 0rule

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.

references:  AC-6, IA-2(1), 366

Proper Storage and Existence of Password Hashesgroup

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.

contains 3 rules

Log In to Accounts With Empty Password Impossiblerule

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.

references:  IA-5(b), IA-5(c), IA-5(1)(a)

Password Hashes For Each Account Shadowedrule

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. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.

references:  IA-5(h), 201

netrc Files Do Not Existrule

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.

references:  IA-5(h), 196

Set Password Expiration Parametersgroup

The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information. Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag. The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire. For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command: # chage -M 180 -m 7 -W 7 USER

contains 4 rules

Password Minimum Lengthrule

To specify password length requirements for new accounts, edit the file /etc/login.defs, locate the following line: PASS_MIN_LEN LENGTH and correct it to have the form of: PASS_MIN_LEN 12 Nowadays recommended values, considered as secure by various organizations focused on topic of computer security, range from 12 (FISMA) up to 14 (DoD) characters for password length requirements. If a program consults /etc/login.defs and also another PAM module (such as pam_pwquality) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements.

references:  IA-5(f), IA-5(1)(a), 205

Remediation script:
var_accounts_password_minlen_login_defs="12"
grep -q ^PASS_MIN_LEN /etc/login.defs && \
sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]
then
  echo -e "PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs" >> /etc/login.defs
fi

Password Minimum Agerule

To specify password minimum age for new accounts, edit the file /etc/login.defs, locate the following line: PASS_MIN_DAYS DAYS and correct it to have the form of: PASS_MIN_DAYS 7 A value greater than 1 day is considered to be sufficient for many environments.

references:  IA-5(f), IA-5(1)(d), 198

Remediation script:
var_accounts_minimum_age_login_defs="7"
grep -q ^PASS_MIN_DAYS /etc/login.defs && \
sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS\t$var_accounts_minimum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]
then
  echo -e "PASS_MIN_DAYS\t$var_accounts_minimum_age_login_defs" >> /etc/login.defs
fi

Password Maximum Agerule

To specify password maximum age for new accounts, edit the file /etc/login.defs, locate the following line: PASS_MAX_DAYS DAYS and correct it to have the form of: PASS_MAX_DAYS 90 A value less than 180 days is sufficient for many environments.

references:  IA-5(f), IA-5(g), IA-5(1)(d), 180, 199

Remediation script:
var_accounts_maximum_age_login_defs="90"
grep -q ^PASS_MAX_DAYS /etc/login.defs && \
sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS\t$var_accounts_maximum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]
then
  echo -e "PASS_MAX_DAYS\t$var_accounts_maximum_age_login_defs" >> /etc/login.defs
fi

Password Warning Agerule

To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs, locate the following line: PASS_WARN_AGE DAYS and correct it to have the form of: PASS_WARN_AGE 7 A value of 7 days would be nowadays considered to be a standard.

references:  IA-5(f)

Remediation script:
var_accounts_password_warn_age_login_defs="7"
grep -q ^PASS_WARN_AGE /etc/login.defs && \
sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE\t$var_accounts_password_warn_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]
then
  echo -e "PASS_WARN_AGE\t$var_accounts_password_warn_age_login_defs" >> /etc/login.defs
fi

Secure Session Configuration Files for Login Accountsgroup

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.

contains 1 rule

Ensure that No Dangerous Directories Exist in Root's Pathgroup

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.

contains 1 rule

Ensure that Root's Path Does Not Include World or Group-Writable Directoriesrule

For each element in root's path, run: $ sudo ls -ld DIR and ensure that write permissions are disabled for group and other.

references:  CM-6(b), 366

Protect Accounts by Configuring PAMgroup

PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that. PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM. PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken. One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service.

contains 1 rule

Set Last Logon/Access Notificationrule

To configure the system to notify users of last logon/access using pam_lastlog, add or correct the pam_lastlog settings in /etc/pam.d/postlogin to read as follows: session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed

references:  53

System Accounting with auditdgroup

The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance. NOTE: The Linux Audit daemon auditd can be configured to use the auditctl utility to read audit rules from the /etc/audit/audit.rules configuration file, and load them into the kernel during daemon startup (default configuration). Alternatively, the auditd daemon can be configured to use the augenrules program to read audit rules files (*.rules) located in /etc/audit/rules.d location and compile them to create the resulting form of the /etc/audit/audit.rules configuration file during the daemon startup. The expected behavior is configured via the appropriate ExecStartPost directive setting in the /usr/lib/systemd/system/auditd.service configuration file. To instruct the auditd daemon to use the auditctl utility to read audit rules (default configuration), use the following setting: ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules in the /usr/lib/systemd/system/auditd.service configuration file. In order to instruct the auditd daemon to use the augenrules program to read audit rules, use the following setting: ExecStartPost=-/sbin/augenrules --load in the /usr/lib/systemd/system/auditd.service configuration file. Refer to [Service] section of the /usr/lib/systemd/system/auditd.service configuration for further details. Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at http://docs.fedoraproject.org/en-US/Fedora/21/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type): type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) msg=audit(1226874073.147:96)The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command. { getattr }The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.comm="httpd"The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd". path="/var/www/html/file1"The path to the object (target) the process attempted to access. scontext="unconfined_u:system_r:httpd_t:s0"The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain. tcontext="unconfined_u:object_r:samba_share_t:s0"The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain. From the system call (SYSCALL) message, two items are of interest: success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t. exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

contains 39 rules

Configure auditd Data Retentiongroup

The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insufficient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period. Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally.

references:  AU-11, 138

contains 7 rules

Configure auditd Number of Logs Retainedrule

Determine how many log files auditd should retain when it rotates logs. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting NUMLOGS with the correct value of 5: num_logs = NUMLOGS Set the value to 5 for general-purpose systems. Note that values less than 2 result in no log rotation.

references:  AU-1(b), AU-11, IR-5

Configure auditd Max Log File Sizerule

Determine the amount of audit data (in megabytes) which should be retained in each log file. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting the correct value of 6 for STOREMB: max_log_file = STOREMB Set the value to 6 (MB) or higher for general-purpose systems. Larger values, of course, support retention of even more audit data.

references:  AU-1(b), AU-11, IR-5

Configure auditd max_log_file_action Upon Reaching Maximum Log Sizerule

The default action to take when the logs reach their maximum size is to rotate the log files, discarding the oldest one. To configure the action taken by auditd, add or correct the line in /etc/audit/auditd.conf: max_log_file_action = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogsuspendrotatekeep_logs Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive.

references:  AU-1(b), AU-4, AU-11, IR-5

Configure auditd space_left Action on Low Disk Spacerule

The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately: space_left_action = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogemailexecsuspendsinglehalt Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt.

references:  AU-1(b), AU-4, AU-5(b), IR-5, 140, 143

Configure auditd admin_space_left Action on Low Disk Spacerule

The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: admin_space_left_action = ACTION Set this value to single to cause the system to switch to single user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.

references:  AU-1(b), AU-4, AU-5(b), IR-5, 140, 1343

Configure auditd mail_acct Action on Low Disk Spacerule

The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: action_mail_acct = root

references:  AU-1(b), AU-4, AU-5(a), IR-5, 139, 144

Configure auditd to use audispd's syslog pluginrule

To configure the auditd service to use the syslog plug-in of the audispd audit event multiplexor, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditd service: $ sudo service auditd restart

references:  AU-1(b), AU-3(2), IR-5, 136

Configure auditd Rules for Comprehensive Auditinggroup

The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system. The audit subsystem supports extensive collection of events, including: Tracing of arbitrary system calls (identified by name or number) on entry or exit.Filtering by PID, UID, call success, system call argument (with some limitations), etc.Monitoring of specific files for modifications to the file's contents or metadata. Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details. If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture. After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: $ sudo service auditd restart

contains 31 rules

Records Events that Modify Date and Time Informationgroup

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited.

contains 5 rules

Record attempts to alter time through adjtimexrule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rules If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169

Record attempts to alter time through settimeofdayrule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169

Record Attempts to Alter Time Through stimerule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file for both 32 bit and 64 bit systems: -a always,exit -F arch=b32 -S stime -k audit_time_rules Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d for both 32 bit and 64 bit systems: -a always,exit -F arch=b32 -S stime -k audit_time_rules Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined system calls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169

Record Attempts to Alter Time Through clock_settimerule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S clock_settime -k audit_time_rules If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -k audit_time_rules If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S clock_settime -k audit_time_rules If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169

Record Attempts to Alter the localtime Filerule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -w /etc/localtime -p wa -k audit_time_rules If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/localtime -p wa -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used.

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(b), IR-5, 1487, 169

Record Events that Modify the System's Discretionary Access Controlsgroup

At a minimum the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

contains 13 rules

Record Events that Modify the System's Discretionary Access Controls - chmodrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - chownrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchmodrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchmodatrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchownrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchownatrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fremovexattrrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fsetxattrrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - lchownrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - lremovexattrrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - lsetxattrrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - removexattrrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - setxattrrule

At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Record Events that Modify User/Group Informationrule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes: -w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, in order to capture events that modify account changes: -w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

references:  AC-2(4), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 18, 1403, 1404, 1405, 1684, 1683, 1685, 1686

Record Events that Modify the System's Network Environmentrule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5

System Audit Logs Must Be Owned By Rootrule

To properly set the owner of /var/log, run the command: $ sudo chown root /var/log

references:  AC-6, AU-1(b), AU-9, IR-5, 166

Record Events that Modify the System's Mandatory Access Controlsrule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -w /etc/selinux/ -p wa -k MAC-policy If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/selinux/ -p wa -k MAC-policy

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5

Record Attempts to Alter Logon and Logout Eventsrule

The audit system already collects login information for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file in order to watch for attempted manual edits of files involved in storing logon events: -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k logins If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events: -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k logins

references:  AC-17(7), AU-1(b), AU-12(a), AU-12(c), IR-5

Record Attempts to Alter Process and Session Initiation Informationrule

The audit system already collects process information for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file in order to watch for attempted manual edits of files involved in storing such process information: -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k session If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing such process information: -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k session

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5

Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Ensure auditd Collects Information on the Use of Privileged Commandsrule

At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART: $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-2(4), AU-12(a), AU-12(c), IR-5, 40

Ensure auditd Collects Information on Exporting to Media (successful)rule

At a minimum the audit system should collect media exportation events for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Ensure auditd Collects File Deletion Events by Userrule

At a minimum the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Ensure auditd Collects System Administrator Actionsrule

At a minimum the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: -w /etc/sudoers -p wa -k actions If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions

references:  AC-2(7)(b), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Ensure auditd Collects Information on Kernel Module Loading and Unloadingrule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: -w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modules If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: -w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modules

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126

Make the auditd Configuration Immutablerule

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file in order to make the auditd configuration immutable: -e 2 If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make the auditd configuration immutable: -e 2 With this setting, a reboot will be required to change any audit rules.

references:  AC-6, AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5

Enable Auditing for Processes Which Start Prior to the Audit Daemonrule

To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-3431fd4f-80aa-436e-8acf-24f5bcb4e23a rhgb quiet audit=1"

references:  AC-17(1), AU-14(1), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-10, IR-5, 1464, 130

Servicesgroup

The best protection against vulnerable software is running less software. This section describes how to review the software which Fedora installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Fedora system and provides guidance about which ones can be safely disabled. Fedora provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Fedora servers, it is highly recommended to select the minimal packages and then build up the system from there.

contains 7 rules

SSH Servergroup

The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called sshd and provided by the RPM package openssh-server.

contains 4 rules

Configure OpenSSH Server if Necessarygroup

If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information.

contains 4 rules

SSH Root Login Disabledrule

The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config: PermitRootLogin no

references:  AC-6(2), IA-2(1), 770

Remediation script:

SSHD_CONFIG='/etc/ssh/sshd_config'

# Obtain line number of first uncommented case-insensitive occurrence of Match
# block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG
FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG)

# Obtain line number of first uncommented case-insensitive occurence of
# PermitRootLogin directive (possibly prefixed with whitespace) present in
# $SSHD_CONFIG
FIRST_PERMIT_ROOT_LOGIN=$(sed -n '/^[[:space:]]*PermitRootLogin[^\n]*/I{=;q}' $SSHD_CONFIG)

# Case: Match block directive not present in $SSHD_CONFIG
if [ -z "$FIRST_MATCH_BLOCK" ]
then

    # Case: PermitRootLogin directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ]
    then
        # Append 'PermitRootLogin no' at the end of $SSHD_CONFIG
        echo -e "\nPermitRootLogin no" >> $SSHD_CONFIG

    # Case: PermitRootLogin directive present in $SSHD_CONFIG already
    else
        # Replace first uncommented case-insensitive occurrence
        # of PermitRootLogin directive
        sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG
    fi

# Case: Match block directive present in $SSHD_CONFIG
else

    # Case: PermitRootLogin directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ]
    then
        # Prepend 'PermitRootLogin no' before first uncommented
        # case-insensitive occurrence of Match block directive
        sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG

    # Case: PermitRootLogin directive present in $SSHD_CONFIG and placed
    #       before first Match block directive
    elif [ "$FIRST_PERMIT_ROOT_LOGIN" -lt "$FIRST_MATCH_BLOCK" ]
    then
        # Replace first uncommented case-insensitive occurrence
        # of PermitRootLogin directive
        sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG

    # Case: PermitRootLogin directive present in $SSHD_CONFIG and placed
    # after first Match block directive
    else
         # Prepend 'PermitRootLogin no' before first uncommented
         # case-insensitive occurrence of Match block directive
         sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG
    fi
fi

SSH Access via Empty Passwords Disabledrule

To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config: PermitEmptyPasswords no Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.

references:  765, 766

Remediation script:

SSHD_CONFIG='/etc/ssh/sshd_config'

# Obtain line number of first uncommented case-insensitive occurrence of Match
# block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG
FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG)

# Obtain line number of first uncommented case-insensitive occurence of
# PermitEmptyPasswords directive (possibly prefixed with whitespace) present in
# $SSHD_CONFIG
FIRST_PERMIT_EMPTY_PASSWORDS=$(sed -n '/^[[:space:]]*PermitEmptyPasswords[^\n]*/I{=;q}' $SSHD_CONFIG)

# Case: Match block directive not present in $SSHD_CONFIG
if [ -z "$FIRST_MATCH_BLOCK" ]
then

    # Case: PermitEmptyPasswords directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_PERMIT_EMPTY_PASSWORDS" ]
    then
        # Append 'PermitEmptyPasswords no' at the end of $SSHD_CONFIG
        echo -e "\nPermitEmptyPasswords no" >> $SSHD_CONFIG

    # Case: PermitEmptyPasswords directive present in $SSHD_CONFIG already
    else
        # Replace first uncommented case-insensitive occurrence
        # of PermitEmptyPasswords directive
        sed -i "$FIRST_PERMIT_EMPTY_PASSWORDS s/^[[:space:]]*PermitEmptyPasswords.*$/PermitEmptyPasswords no/I" $SSHD_CONFIG
    fi

# Case: Match block directive present in $SSHD_CONFIG
else

    # Case: PermitEmptyPasswords directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_PERMIT_EMPTY_PASSWORDS" ]
    then
        # Prepend 'PermitEmptyPasswords no' before first uncommented
        # case-insensitive occurrence of Match block directive
        sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitEmptyPasswords no\n\1/I" $SSHD_CONFIG

    # Case: PermitEmptyPasswords directive present in $SSHD_CONFIG and placed
    #       before first Match block directive
    elif [ "$FIRST_PERMIT_EMPTY_PASSWORDS" -lt "$FIRST_MATCH_BLOCK" ]
    then
        # Replace first uncommented case-insensitive occurrence
        # of PermitEmptyPasswords directive
        sed -i "$FIRST_PERMIT_EMPTY_PASSWORDS s/^[[:space:]]*PermitEmptyPasswords.*$/PermitEmptyPasswords no/I" $SSHD_CONFIG

    # Case: PermitEmptyPasswords directive present in $SSHD_CONFIG and placed
    # after first Match block directive
    else
         # Prepend 'PermitEmptyPasswords no' before first uncommented
         # case-insensitive occurrence of Match block directive
         sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitEmptyPasswords no\n\1/I" $SSHD_CONFIG
    fi
fi

SSH Idle Timeout Interval Usedrule

SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out. To set an idle timeout interval, edit the /etc/ssh/sshd_config file, locate the following line: ClientAliveInterval INTERVAL and correct it to have the form of: ClientAliveInterval 300 The timeout INTERVAL is given in seconds. To have a timeout of 15 minutes, set INTERVAL to 900. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

references:  879, 1133

Remediation script:
sshd_idle_timeout_value="300"
SSHD_CONFIG='/etc/ssh/sshd_config'

# Obtain line number of first uncommented case-insensitive occurrence of Match
# block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG
FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG)

# Obtain line number of first uncommented case-insensitive occurence of
# ClientAliveInterval directive (possibly prefixed with whitespace) present in
# $SSHD_CONFIG
FIRST_CLIENT_ALIVE_INTERVAL=$(sed -n '/^[[:space:]]*ClientAliveInterval[^\n]*/I{=;q}' $SSHD_CONFIG)

# Case: Match block directive not present in $SSHD_CONFIG
if [ -z "$FIRST_MATCH_BLOCK" ]
then

    # Case: ClientAliveInterval directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_CLIENT_ALIVE_INTERVAL" ]
    then
        # Append 'ClientAliveInterval $sshd_idle_timeout_value' at the end of $SSHD_CONFIG
        echo -e "\nClientAliveInterval $sshd_idle_timeout_value" >> $SSHD_CONFIG

    # Case: ClientAliveInterval directive present in $SSHD_CONFIG already
    else
        # Replace first uncommented case-insensitive occurrence
        # of ClientAliveInterval directive
        sed -i "$FIRST_CLIENT_ALIVE_INTERVAL s/^[[:space:]]*ClientAliveInterval.*$/ClientAliveInterval $sshd_idle_timeout_value/I" $SSHD_CONFIG
    fi

# Case: Match block directive present in $SSHD_CONFIG
else

    # Case: ClientAliveInterval directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_CLIENT_ALIVE_INTERVAL" ]
    then
        # Prepend 'ClientAliveInterval $sshd_idle_timeout_value' before first uncommented
        # case-insensitive occurrence of Match block directive
        sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveInterval $sshd_idle_timeout_value\n\1/I" $SSHD_CONFIG

    # Case: ClientAliveInterval directive present in $SSHD_CONFIG and placed
    #       before first Match block directive
    elif [ "$FIRST_CLIENT_ALIVE_INTERVAL" -lt "$FIRST_MATCH_BLOCK" ]
    then
        # Replace first uncommented case-insensitive occurrence
        # of ClientAliveInterval directive
        sed -i "$FIRST_CLIENT_ALIVE_INTERVAL s/^[[:space:]]*ClientAliveInterval.*$/ClientAliveInterval $sshd_idle_timeout_value/I" $SSHD_CONFIG

    # Case: ClientAliveInterval directive present in $SSHD_CONFIG and placed
    # after first Match block directive
    else
         # Prepend 'ClientAliveInterval $sshd_idle_timeout_value' before first uncommented
         # case-insensitive occurrence of Match block directive
         sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveInterval $sshd_idle_timeout_value\n\1/I" $SSHD_CONFIG
    fi
fi

SSH Client Alive Count Usedrule

To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows: ClientAliveCountMax 0

references:  879, 1133

Remediation script:

SSHD_CONFIG='/etc/ssh/sshd_config'

# Obtain line number of first uncommented case-insensitive occurrence of Match
# block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG
FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG)

# Obtain line number of first uncommented case-insensitive occurence of
# ClientAliveCountMax directive (possibly prefixed with whitespace) present in
# $SSHD_CONFIG
FIRST_CLIENT_ALIVE_COUNT_MAX=$(sed -n '/^[[:space:]]*ClientAliveCountMax[^\n]*/I{=;q}' $SSHD_CONFIG)

# Case: Match block directive not present in $SSHD_CONFIG
if [ -z "$FIRST_MATCH_BLOCK" ]
then

    # Case: ClientAliveCountMax directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_CLIENT_ALIVE_COUNT_MAX" ]
    then
        # Append 'ClientAliveCountMax 0' at the end of $SSHD_CONFIG
        echo -e "\nClientAliveCountMax 0" >> $SSHD_CONFIG

    # Case: ClientAliveCountMax directive present in $SSHD_CONFIG already
    else
        # Replace first uncommented case-insensitive occurrence
        # of ClientAliveCountMax directive
        sed -i "$FIRST_CLIENT_ALIVE_COUNT_MAX s/^[[:space:]]*ClientAliveCountMax.*$/ClientAliveCountMax 0/I" $SSHD_CONFIG
    fi

# Case: Match block directive present in $SSHD_CONFIG
else

    # Case: ClientAliveCountMax directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_CLIENT_ALIVE_COUNT_MAX" ]
    then
        # Prepend 'ClientAliveCountMax 0' before first uncommented
        # case-insensitive occurrence of Match block directive
        sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveCountMax 0\n\1/I" $SSHD_CONFIG

    # Case: ClientAliveCountMax directive present in $SSHD_CONFIG and placed
    #       before first Match block directive
    elif [ "$FIRST_CLIENT_ALIVE_COUNT_MAX" -lt "$FIRST_MATCH_BLOCK" ]
    then
        # Replace first uncommented case-insensitive occurrence
        # of ClientAliveCountMax directive
        sed -i "$FIRST_CLIENT_ALIVE_COUNT_MAX s/^[[:space:]]*ClientAliveCountMax.*$/ClientAliveCountMax 0/I" $SSHD_CONFIG

    # Case: ClientAliveCountMax directive present in $SSHD_CONFIG and placed
    # after first Match block directive
    else
         # Prepend 'ClientAliveCountMax 0' before first uncommented
         # case-insensitive occurrence of Match block directive
         sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveCountMax 0\n\1/I" $SSHD_CONFIG
    fi
fi

Network Time Protocolgroup

The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of machines, and that their time is consistent with the outside world. If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable. Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network. A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers. More information on how to configure the NTP server software, including configuration of cryptographic authentication for time data, is available at http://www.ntp.org.

contains 2 rules

Enable the Chrony Daemonrule

The ntpd service can be enabled with the following command: $ sudo systemctl enable ntpd.service

references:  AU-8(1), 160

Remediation script:
#
# Install chrony package if necessary
#

yum -y install chrony

#
# Enable chronyd service (for current systemd target)
#

systemctl enable chronyd.service

#
# Start chronyd if not currently running
#

systemctl start chronyd.service

Specify a Remote NTP Serverrule

To specify a remote NTP server for time synchronization, edit the file /etc/chrony.conf. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver: server ntpserver This instructs the NTP software to contact that remote server to obtain time data.

references:  AU-8(1), 160

Audit Deamongroup

The Linux Audit system provides a way to track security-relevant information on your system. Based on pre-configured rules, Audit generates log entries to record as much information about the events that are happening on your system as possible. This information is crucial for mission-critical environments to determine the violator of the security policy and the actions they performed. Audit does not provide additional security to your system; rather, it can be used to discover violations of security policies used on your system. These violations can further be prevented by additional security measures such as SELinux.

contains 1 rule

Enable the Audit Daemonrule

The audit service can be enabled with the following command: $ sudo systemctl enable audit.service

references:  AU-8(1), 160

Red Hat and Fedora are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.