The STIG requires all systems to have the audit daemon, auditd
, running to
monitor system calls and other critical events. The daemon has rules that
define which events are noteworthy on the system and it can generate alerts
based on the events it finds.
The auditd rules are deployed in a single task via a template
(templates/osas-auditd-rhel7.j2
). Each rule or set of similar rules are
controlled by an Ansible variable that starts with security_audit_rhel7
.
Refer to defaults/main.yml
for a list of these variables.
Example:
# Add audit rules for commands/syscalls.
security_rhel7_audit_chsh: yes # V-72167
security_rhel7_audit_chage: yes # V-72155
security_rhel7_audit_chcon: yes # V-72139
security_rhel7_audit_chmod: no # V-72105
security_rhel7_audit_chown: no # V-72097
For example, setting security_rhel7_audit_chown
to yes
will
ensure that the rule for auditing the usage of the chown
are included
on each host. Setting security_rhel7_audit_chown
to no
will omit that
rule on each host.
There are several configurations for auditd which are critical for deployers
to review in detail. The options beneath the ## Audit daemon (auditd)
comment will change how auditd handles log files and what it should do in
case of emergencies.
Warning
Deployers should thoroughly test all changes to auditd emergency configurations. Some of these configuration options can cause serious issues on production systems, ranging from a reduction in security to servers going offline unexpectedly. There is extensive documentation in the developer notes below for each STIG requirement.
All of the tasks for these STIG requirements are included in
tasks/rhel7stig/auditd.yml
.
The tasks in the security role start the audit daemon immediately and ensure that it starts at boot time.
The audit daemon takes various actions when there is an auditing failure. There
are three options for the -f
flag for auditctl
:
0
: In the event of an auditing failure, do nothing.1
: In the event of an auditing failure, write messages to the kernel log.2
: In the event of an auditing failure, cause a kernel panic.Most operating systems set the failure flag to 1
by default, which
maximizes system availability while still causing an alert. The tasks in the
security role set the flag to 1
by default.
Deployers can adjust the following Ansible variable to customize the failure flag:
security_rhel7_audit_failure_flag: 1
Warning
Setting the failure flag to 2
is strongly discouraged unless the
security of the system takes priority over its availability. Any failure in
auditing causes a kernel panic and the system requires a hard reboot.
The audispd
service transmits audit logs to other servers. Deployers
should specify the address of another server that can receive audit logs by
setting the following Ansible variable:
security_audisp_remote_server: '10.0.21.1'
The audispd
daemon transmits audit logs without encryption by default. The
STIG requires that these logs are encrypted while they are transferred across
the network. The encryption is controlled by the enable_krb5
option in
/etc/audisp/audisp-remote.conf
.
Deployers can opt-in for encrypted audit log transmission by setting the following Ansible variable:
security_audisp_enable_krb5: yes
Warning
Only enable this setting if kerberos is already configured.
The tasks in the security role set the disk_full_action
and
network_failure_action
to syslog
in the audispd remote configuration.
In the event of a full disk on the remote log server or a network interruption,
the local system sends warnings to syslog. This is the safest option since it
maximizes the availability of the local system.
Deployers have two other options available:
single
: Switch the local server into single-user mode in the event of a
logging failure.halt
: Shut off the local server gracefully in the event of a logging
failure.Warning
Choosing single
or halt
causes a server to go into a degraded or
offline state immediately after a logging failure.
Deployers can adjust these configurations by setting the following Ansible variables (the safe defaults are shown here):
security_rhel7_auditd_disk_full_action: syslog
security_rhel7_auditd_network_failure_action: syslog
The space_left
configuration is set to 25% of the size of the disk mounted
on /
. This calculation is done automatically.
Deployers can set a custom threshold for the space_left
configuration (in
megabytes) by setting the following Ansible variable:
# Example: A setting of 1GB (1024MB)
security_rhel7_auditd_space_left: 1024
The space_left_action
in the audit daemon configuration is set to
email
. This configuration causes the root user to receive an email when the
space_left
threshold is reached.
Deployers can customize this configuration by setting the following Ansible variable:
security_rhel7_auditd_space_left_action: email
The action_mail_acct
configuration in the audit daemon configuration file
is set to root
to meet the requirements of the STIG. Deployers can
customize the recipient of the emails that come from auditd by setting the
following Ansible variable:
security_rhel7_auditd_action_mail_acct: root
This STIG is difficult to implement in an automated way because the number of applications on a system with setuid/setgid permissions changes over time. In addition, adding audit rules for some of these automatically could cause a significant increase in logging traffic when these applications are used regularly.
Deployers are urged to do the following instead:
The STIG requires that all chown
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_chown: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all fchown
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_fchown: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all lchown
syscalls are audited, but this change
creates a significant increase in logging on most systems. This increase can
cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_lchown: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all fchownat
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_fchownat: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all chmod
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_chmod: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all fchmod
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_fchmod: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all fchmodat
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_fchmodat: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all setxattr
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_setxattr: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all fsetxattr
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_fsetxattr: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all lsetxattr
syscalls are audited, but this change
creates a significant increase in logging on most systems. This increase can
cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_lsetxattr: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all removexattr
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_removexattr: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all fremovexattr
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_fremovexattr: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
The STIG requires that all lremovexattr
syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.
Warning
This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.
Deployers can opt in for this change by setting the following Ansible variable:
security_rhel7_audit_lremovexattr: yes
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all creat
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_creat: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all open
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_open: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all openat
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_openat: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all open_by_handle_at
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_open_by_handle_at: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all truncate
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_truncate: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all ftruncate
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_ftruncate: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit any time the semanage
command is used.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_semanage: no
Rules are added to audit any time the setsebool
command is used.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_setsebool: no
The tasks add a rule to auditd that logs each time the chcon
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_chcon: no
The tasks add a rule to auditd that logs each time the restorecon
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_restorecon: no
Rules are added to audit all successful and unsuccessful account access events. Deployers can opt out of this change by setting the following Ansible variable:
security_rhel7_audit_account_access: no
This control is implemented by the tasks for another control:
The tasks add a rule to auditd that logs each time an account is accessed.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_account_access: no
The tasks add a rule to auditd that logs each time the passwd
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_passwd_command: no
The tasks add a rule to auditd that logs each time the unix_chkpwd
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_unix_chkpwd: no
The tasks add a rule to auditd that logs each time the gpasswd
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_gpasswd: no
The tasks add a rule to auditd that logs each time the chage
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_chage: no
The tasks add a rule to auditd that logs each time the userhelper
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_userhelper: no
The tasks add a rule to auditd that logs each time the su
command is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_su: no
The tasks add a rule to auditd that logs each time the sudo
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_sudo: no
The tasks add a rule to auditd that logs each time a user manages the
configuration files for sudo
.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_sudo_config_changes: no
The tasks add a rule to auditd that logs each time the newgrp
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_newgrp: no
The tasks add a rule to auditd that logs each time the chsh
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_chsh: no
The tasks add a rule to auditd that logs each time the sudoedit
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_sudoedit: no
The tasks add a rule to auditd that logs each time the mount
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_mount: no
The tasks add a rule to auditd that logs each time the umount
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_umount: no
The tasks add a rule to auditd that logs each time the postdrop
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_postdrop: no
The tasks add a rule to auditd that logs each time the postqueue
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_postqueue: no
The tasks add a rule to auditd that logs each time the ssh-keysign
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_ssh_keysign: no
The tasks add a rule to auditd that logs each time the pt_chown
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_pt_chown: no
Note
No action is taken on Ubuntu 16.04, openSUSE Leap and SUSE Linux Enterprise
because pt_chown
is not available.
The tasks add a rule to auditd that logs each time the crontab
command
is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_crontab: no
The tasks add a rule to auditd that logs each time the pam_timestamp_check
command is used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_pam_timestamp_check: no
Rules are added to audit all init_module
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_init_module: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all delete_module
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_delete_module: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
The tasks add a rule to auditd that logs each time the insmod
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_insmod: no
The tasks add a rule to auditd that logs each time the rmmod
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_rmmod: no
The tasks add a rule to auditd that logs each time the modprobe
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_modprobe: no
The tasks add a rule to auditd that logs each time that an account is modified. This includes changes to the following files:
/etc/group
/etc/passwd
/etc/gshadow
/etc/shadow
/etc/security/opasswd
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_account_actions: no
Rules are added to audit all rename
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_rename: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all renameat
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_renameat: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
Rules are added to audit all rmdir
syscalls on the system.
Deployers can opt out of this change by setting an Ansible variable:
security_rhel7_audit_rmdir: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
The tasks add a rule to auditd that logs each time the unlink
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_unlink: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
The tasks add a rule to auditd that logs each time the unlinkat
command is
used.
Deployers can opt-out of this change by setting an Ansible variable:
security_rhel7_audit_unlinkat: no
This rule is compatible with x86, x86_64, and ppc64 architectures.
This control is implemented by the tasks for another control:
This control is implemented by the tasks for another control:
This control is implemented by the tasks for another control:
This control is implemented by the tasks for another control:
This control is implemented by the tasks for another control:
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.