contains 68 rules |
System Settingsgroup |
contains 61 rules |
Installing and Maintaining SoftwaregroupThe 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 SoftwaregroupThe 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 ConfigurationruleThe 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 RepositoriesruleTo 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 AIDEgroupAIDE 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 RPMgroupThe 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 RPMruleThe 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 MasksgroupTraditional 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 DirectoriesgroupSome 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 PermissionsruleSystem-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 OwnershipruleSystem-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 ControlgroupIn 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 LogingroupConventionally, 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 AllowedruleTo 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 RestrictedruleTo 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 ImpossibleruleIf 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 ExistruleThe .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 ParametersgroupThe 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 LengthruleTo 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 AgeruleTo 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 AgeruleTo 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 AgeruleTo 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 AccountsgroupWhen 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 PathgroupThe 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 PAMgroupPAM, 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 NotificationruleTo 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 auditdgroupThe 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 RetainedruleDetermine 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 SizeruleDetermine 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 SpaceruleThe 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 SpaceruleThe 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 SpaceruleThe 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 pluginruleTo 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 AuditinggroupThe 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 InformationgroupArbitrary 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 adjtimexruleIf 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 settimeofdayruleIf 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 stimeruleIf 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_settimeruleIf 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 FileruleIf 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 ControlsgroupAt 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 - chmodruleAt 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 - chownruleAt 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 - fchmodruleAt 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 - fchmodatruleAt 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 - fchownruleAt 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 - fchownatruleAt 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 - fremovexattrruleAt 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 - fsetxattrruleAt 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 - lchownruleAt 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 - lremovexattrruleAt 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 - lsetxattrruleAt 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 - removexattrruleAt 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 - setxattrruleAt 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 InformationruleIf 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 EnvironmentruleIf 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 ControlsruleIf 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 EventsruleThe 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 InformationruleThe 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)ruleAt 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 CommandsruleAt 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)ruleAt 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 UserruleAt 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 ActionsruleAt 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 UnloadingruleIf 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 ImmutableruleIf 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 DaemonruleTo 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 ServergroupThe 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 NecessarygroupIf 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 DisabledruleThe 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 DisabledruleTo 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 UsedruleSSH 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 UsedruleTo 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 ProtocolgroupThe 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 ServerruleTo 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 |