Guide to the Secure Configuration of Fedora
with profile Common Profile for General-Purpose Fedora SystemsThis profile contains items common to general-purpose Fedora installations.
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).
Profile Title | Common Profile for General-Purpose Fedora Systems |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_common |
Revision History
Current version: 0.1.30
- draft (as of 2016-06-27)
Platforms
- cpe:/o:fedoraproject:fedora:25
- cpe:/o:fedoraproject:fedora:24
- cpe:/o:fedoraproject:fedora:23
- cpe:/o:fedoraproject:fedora:22
Table of Contents
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- Account and Access Control
- Network Configuration and Firewalls
- System Accounting with auditd
- Services
Checklist
contains 74 rules |
System Settingsgroup |
contains 67 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 6 rules |
Updating SoftwaregroupThe |
contains 2 rules |
gpgcheck Enabled In Main Dnf ConfigurationruleThe gpgcheck=1Rationale: Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering. |
gpgcheck Enabled For All Dnf Package RepositoriesruleTo ensure signature checking is not disabled for
any repos, remove any lines from files in gpgcheck=0Rationale: Ensuring all packages' cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering. |
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.
|
contains 4 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 |
contains 2 rules |
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
PRELINKING=noNext, run the following command to return binaries to a normal, non-prelinked state: $ sudo /usr/sbin/prelink -uaRationale: The prelinking feature can interfere with the operation of AIDE, because it changes binaries. Remediation script:
|
Build and Test AIDE DatabaseruleRun the following command to generate a new database: # /usr/sbin/aide --initBy default, the database will be written to the file /var/lib/aide/aide.db.new.gz .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzTo initiate a manual check, run the following command: # /usr/sbin/aide --checkIf this check produces any unexpected output, investigate. Rationale: For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. |
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 -qVaSee the man page for rpm to see a complete explanation of each column.
|
contains 2 rules |
Verify and Correct File Permissions with RPMruleThe 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 FILENAMENext, run the following command to reset its permissions to the correct values: # rpm --setperms PACKAGENAMERationale: Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. |
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 FILENAMEThe package can be reinstalled from a dnf repository using the command: dnf reinstall PACKAGENAMEAlternatively, the package can be reinstalled from trusted media using the command: rpm -Uvh PACKAGENAMERationale: The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system. |
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 5 rules |
Restrict Dynamic Mounting and Unmounting of FilesystemsgroupLinux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d .
|
contains 1 rule |
Disable Kernel Support for USB via Bootloader Configurationrule
All USB support can be disabled by adding the kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousbWARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common.Rationale: Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems. Remediation script:
|
Verify Permissions on Important Files and DirectoriesgroupPermissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. |
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 |
Verify that 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/lib64Kernel 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:
$ sudo chmod go-w FILERationale: Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Verify that 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/lib64Kernel 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:
$ sudo chown root FILERationale: Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Verify that System Executables Have Restrictive PermissionsruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll 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: $ sudo chmod go-w FILERationale: System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Verify that System Executables Have Root OwnershipruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll 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:
$ sudo chown root FILERationale: System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
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 15 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 |
contains 13 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 |
contains 4 rules |
Direct root Logins Not AllowedruleTo further limit access to the echo > /etc/securettyRationale: Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This scenario is nowadays required by security standards. 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 vc/1 vc/2 vc/3 vc/4Rationale: Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. Remediation script:
|
Serial Port Root Logins RestrictedruleTo restrict root logins on serial ports,
ensure lines of this form do not appear in ttyS0 ttyS1Rationale: Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account. Remediation script:
|
Only Root Has UID 0ruleIf any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed. Rationale:An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. |
Proper Storage and Existence of Password Hashesgroup
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
|
contains 4 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 If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. references: IA-5(b), IA-5(c), IA-5(1)(a) |
Password Hashes For Each Account Shadowedrule
If any password hashes are stored in
The hashes for all user account passwords should be stored in
the file |
All GIDs referenced in /etc/passwd Defined in /etc/groupruleAdd a group to the system for each GID referenced without a corresponding group. Rationale:
Inconsistency in GIDs between references: 366 |
netrc Files Do Not ExistruleThe
Unencrypted passwords for remote FTP servers may be stored in |
Set Password Expiration ParametersgroupThe file # chage -M 180 -m 7 -W 7 USER |
contains 4 rules |
Password Minimum LengthruleTo specify password length requirements for new accounts,
edit the file PASS_MIN_LEN LENGTHand 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.
Rationale:Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result. references: IA-5(f), IA-5(1)(a), 205
|
Password Minimum AgeruleTo specify password minimum age for new accounts,
edit the file PASS_MIN_DAYS DAYSand 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. Rationale: Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. references: IA-5(f), IA-5(1)(d), 198
|
Password Maximum AgeruleTo specify password maximum age for new accounts,
edit the file PASS_MAX_DAYS DAYSand correct it to have the form of: PASS_MAX_DAYS 90 A value less than 180 days is sufficient for many environments. Rationale: Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. references: IA-5(f), IA-5(g), IA-5(1)(d), 180, 199
|
Password Warning AgeruleTo specify how many days prior to password
expiration that a warning will be issued to users,
edit the file PASS_WARN_AGE DAYSand correct it to have the form of: PASS_WARN_AGE 7 A value of 7 days would be nowadays considered to be a standard. Rationale: Setting the password warning age enables users to make the change at a practical time. references: IA-5(f)
|
Set Account Expiration ParametersgroupAccounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting $ sudo chage -I NUM_DAYS USERAccounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities.
|
contains 1 rule |
Ensure All Accounts on the System Have Unique NamesruleChange usernames, or delete accounts, so each has a unique name. Rationale:Unique usernames allow for accountability on the system. |
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 $PATHThis will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute privileged commands by typing the full path to the command. |
contains 1 rule |
Ensure that Root's Path Does Not Include World or Group-Writable DirectoriesruleFor each element in root's path, run: $ sudo ls -ld DIRand ensure that write permissions are disabled for group and other. Rationale: Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code. |
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.
warning
Be careful when making changes to PAM's
configuration files. The syntax for these files is complex, and
modifications can have unexpected consequences. The default
configurations shipped with applications should be sufficient for
most users. warning
Running authconfig or
system-config-authentication will re-write the PAM configuration
files, destroying any manually made changes and replacing them with
a series of system defaults. One reference to the configuration
file syntax can be found at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html. |
contains 1 rule |
Set Last Logon/Access NotificationruleTo configure the system to notify users of last logon/access
using 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 showfailedRationale: Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. references: 53 |
Network Configuration and FirewallsgroupMost machines must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
|
contains 2 rules |
firewalldgroupThe dynamic firewall daemon |
contains 2 rules |
Inspect and Activate Default firewalld RulesgroupFirewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network.
It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager , they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-allExample output of this command might look like the following: # firewall-cmd --zone=public --list-all public interfaces: services: mdns dhcpv6-client ssh ports: forward-ports: icmp-blocks: source-quenchTo view the network zones currently active, enter the following command as root: # firewall-cmd --get-serviceThe following listing displays the result of this command on common Fedora Server system: # firewall-cmd --get-service amanda-client amanda-k5-client bacula bacula-client cockpit dhcp dhcpv6 dhcpv6-client dns dropbox-lansync freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability http https imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mosh mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s postgresql privoxy proxy-dhcp ptp puppetmaster radius rpc-bind rsyncd samba samba-client sane smtp squid ssh synergy telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-serverFinally to view the network zones that will be active after the next firewalld service reload, enter the following command as root: # firewall-cmd --get-service --permanent |
contains 1 rule |
Verify firewalld Enabledrule
The $ sudo systemctl enable firewalld.serviceRationale:
The dynamic firewall daemon |
Strengthen the Default RulesetgroupThe default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in configuration files under the warning
The program firewall-config
allows additional services to penetrate the default firewall rules
and automatically adjusts the firewalld ruleset(s). |
contains 1 rule |
Set Default firewalld Zone for Incoming PacketsruleTo set the default zone to DefaultZone=dropRationale: In |
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, ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rulesin 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 --loadin 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/22/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)
|
contains 39 rules |
Configure auditd Data Retentiongroup
The audit system writes data to |
contains 7 rules |
Configure auditd Number of Logs RetainedruleDetermine how many log files
num_logs = NUMLOGSSet the value to 5 for general-purpose systems. Note that values less than 2 result in no log rotation.Rationale: The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained. |
Configure auditd Max Log File SizeruleDetermine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
max_log_file = STOREMBSet the value to 6 (MB) or higher for general-purpose systems.
Larger values, of course,
support retention of even more audit data.Rationale:The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained. |
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 max_log_file_action = ACTIONPossible values for ACTION are described in the auditd.conf man
page. These include:
ACTION to rotate to ensure log rotation
occurs. This is the default. The setting is case-insensitive.
Rationale:Automatically rotating logs (by setting this to |
Configure auditd space_left Action on Low Disk SpaceruleThe space_left_action = ACTIONPossible values for ACTION are described in the auditd.conf man page.
These include:
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 .
Rationale:Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. |
Configure auditd admin_space_left Action on Low Disk SpaceruleThe admin_space_left_action = ACTIONSet 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.
Rationale:Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur. |
Configure auditd mail_acct Action on Low Disk SpaceruleThe action_mail_acct = rootRationale: Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. |
Configure auditd to use audispd's syslog pluginruleTo configure the $ sudo service auditd restartRationale: The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server |
Configure auditd Rules for Comprehensive AuditinggroupThe
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 -a always,exit -F arch=b32 -S adjtimex -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rulesIf 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rulesThe -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 -k audit_time_rulesRationale: 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 (such as sshd). All changes to the system time should be audited. |
Record attempts to alter time through settimeofdayruleIf the -a always,exit -F arch=b32 -S settimeofday -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rulesIf 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rulesThe -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 -k audit_time_rulesRationale: 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 (such as sshd). All changes to the system time should be audited. |
Record Attempts to Alter Time Through stimeruleIf the -a always,exit -F arch=b32 -S stime -k audit_time_rulesSince 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_rulesSince 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 -k audit_time_rulesRationale: 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 (such as sshd). All changes to the system time should be audited. |
Record Attempts to Alter Time Through clock_settimeruleIf the -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeIf 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 -F a0=0x0 -F key=time-changeIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeThe -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 -k audit_time_rulesRationale: 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 (such as sshd). All changes to the system time should be audited. Remediation script:
|
Record Attempts to Alter the localtime FileruleIf the -w /etc/localtime -p wa -k audit_time_rulesIf 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_rulesThe -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. Rationale: 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 (such as sshd). All changes to the system time should be audited. |
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 -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_modIf 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 -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
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 -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf 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_modIf 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_modIf 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 warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. |
Record Events that Modify User/Group InformationruleIf the -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_modificationIf 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_modificationRationale: In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. |
Record Events that Modify the System's Network EnvironmentruleIf the -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_modificationIf 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_modificationRationale: The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. |
System Audit Logs Must Be Owned By Rootrule
To properly set the owner of $ sudo chown root /var/logRationale: Failure to give ownership of the audit log files to root allows the designated owner, and unauthorized users, potential access to sensitive information. |
Record Events that Modify the System's Mandatory Access ControlsruleIf the -w /etc/selinux/ -p wa -k MAC-policyIf 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-policyRationale: The system's mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited. |
Record Attempts to Alter Logon and Logout EventsruleThe audit system already collects login information for all users
and root. If the -w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsIf 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/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Remediation script:
|
Record Attempts to Alter Process and Session Initiation InformationruleThe audit system already collects process information for all
users and root. If the -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k sessionIf 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 sessionRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. |
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 -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 accessIf 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 accessIf 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 accessIf 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 accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. |
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/nullIf 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 privilegedIf 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 privilegedRationale: Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. |
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 -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k exportIf 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 exportRationale: The unauthorized exportation of data to external media could result in an information leak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time a filesystem is mounted to help identify and guard against information loss. |
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 -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k deleteIf 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 deleteRationale: Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. |
Ensure auditd Collects System Administrator ActionsruleAt a minimum the audit system should collect administrator actions
for all users and root. If the -w /etc/sudoers -p wa -k actionsIf 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 actionsRationale: The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. |
Ensure auditd Collects Information on Kernel Module Loading and UnloadingruleIf the -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 modulesIf 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 modulesRationale: The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. |
Make the auditd Configuration ImmutableruleIf the -e 2If 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 2With this setting, a reboot will be required to change any audit rules. Rationale: Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation Remediation script:
|
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 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" warning
The GRUB 2 configuration file, grub.cfg ,
is automatically updated each time a new kernel is installed. Note that any
changes to /etc/default/grub require rebuilding the grub.cfg
file. To update the GRUB 2 configuration file manually, use the
grub2-mkconfig -ocommand as follows:
Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although |
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.
|
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 |
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
|
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 PermitRootLogin noRationale: Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password. Remediation script:
|
SSH Access via Empty Passwords DisabledruleTo explicitly disallow remote login from accounts with empty
passwords, add or correct the following line in PermitEmptyPasswords noAny accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. Rationale: Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. Remediation script:
|
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.
ClientAliveInterval INTERVALand correct it to have the form of: ClientAliveInterval 300The 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. Rationale: Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. Remediation script:
|
SSH Client Alive Count UsedruleTo ensure the SSH idle timeout occurs precisely when the
ClientAliveCountMax 0Rationale:
This ensures a user login will be terminated as soon as the
|
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.
|
contains 2 rules |
Enable the Chrony Daemonrule
The $ sudo systemctl enable ntpd.serviceRationale: Enabling the
|
Specify a Remote NTP ServerruleTo specify a remote NTP server for time synchronization, edit
the file server ntpserverThis instructs the NTP software to contact that remote server to obtain time data. Rationale: Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. |
Audit DeamongroupThe 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 $ sudo systemctl enable audit.serviceRationale: Enabling the |