tencent cloud

TencentOS Server

DocumentaçãoTencentOS ServerUser GuideSecurity ConfigurationIntegrity Protection and Security Auditing

Integrity Protection and Security Auditing

Baixar
Modo Foco
Tamanho da Fonte
Última atualização: 2026-10-19 17:22:50
Traduzido por IA
TencentOS Server provides comprehensive integrity protection and security audit mechanisms, including AIDE file integrity checking, the IMA kernel integrity measurement architecture, and the auditd security audit system. This document describes the principles, configuration, and usage of these three components.

AIDE

Introduction to AIDE

AIDE (Advanced Intrusion Detection Environment) is an open-source file integrity checking tool that detects whether files have been tampered with by creating database snapshots of critical system files and periodically comparing file attributes and content hashes. AIDE can monitor various file attributes such as permissions, owner, group, size, modification time, and content hashes, making it an important means of host intrusion detection.

Installing AIDE

To install AIDE on TencentOS Server, run the following command:
dnf install aide

Initializing Database

After installation, you need to first create the initial AIDE database, which will serve as the baseline for subsequent integrity checks:
aide --init
After initialization, the generated database file is located at /var/lib/aide/aide.db.new.gz. To save the database as a baseline, remove the .new string from the initial filename:
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Performing the Integrity Check

After the initial database is established, manually check for changes to protected files:
sudo aide --check
If no changes are detected, the following message is displayed:
AIDE found NO differences between database and filesystem. Looks okay!!
If changes are detected, the following message is displayed: AIDE found differences between database and filesystem. The output example is as follows:
Start timestamp: 2023-05-06 10:35:53 +0800 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
  Total number of entries: 116821
  Added entries:          0
  Removed entries:        0
  Changed entries:         4
---------------------------------------------------
Changed entries:
---------------------------------------------------
d = ... mc.. ... : /root
f ... i . . : /root/.viminfo
f = ... mc...... : /usr/lib/sysimage/rpm/rpmdb.sqlite-shm
f = ... .c...... : /usr/lib/sysimage/rpm/rpmdb.sqlite-wal
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
Directory: /root
  Mtime : 2023-05-05 17:35:34 +0800 | 2023-05-06 10:22:45 +0800
  Ctime : 2023-05-05 17:35:34 +0800 | 2023-05-06 10:22:45 +0800
...(omit partial output)...

Periodic Inspection

AIDE typically needs to run checks periodically, so you can also schedule periodic checks through cron. For example, you can add the following configuration to the /etc/crontab file to run an AIDE check at 6:30 every day:
30 6 * * * root /usr/sbin/aide --check

Updating the AIDE Database

After active changes are made to a system, it is necessary to update the database and execute the following procedure to refresh the AIDE database:
aide --update
The updated database file is located at /var/lib/aide/aide.db.new.gz. Similarly, you need to remove the .new string from the initial filename before the updated database can be used for integrity checks:
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

IMA

Introduction to IMA

Integrity Measurement Architecture (IMA) is part of the Linux kernel integrity subsystem. By adding hooks to system calls such as execve(), mmap(), and open(), IMA performs integrity measurements on accessed files. The measurement results can be further used for remote attestation or compared with reference values in extended file attributes to control file access.
IMA features are primarily categorized into the following three types:
Measure: Measure files and record the measurement results in the runtime measurement list.
Appraise: Measure files and compare them with a reference value stored in the extended attributes, then perform access control based on the integrity check results.
Audit: Record the measurement results into the system audit logs.
It should be noted that IMA cannot prevent files from being tampered with. Both attackers and system administrators can modify file contents through legitimate means, provided they have sufficient privileges. However, after such modification, the next time the file is accessed, IMA can detect the tampering by verifying the file's content integrity. If the appraise feature is enabled, it can further prevent subsequent access to the file.
Additionally, it is recommended that the Secure Boot protection mechanism be enabled before IMA is used to protect the kernel and kernel boot parameters from being tampered with.

IMA Initialization

After TencentOS Server is installed, IMA is enabled by default. You only need to load an IMA policy to start using IMA integrity measurement. There are two ways to load a policy, and you can choose either one based on your needs:
Specify the preset policy via the boot parameter ima_policy.
Import a manual policy via the /sys/kernel/security/ima/policy API.

Method 1: Specifying a Preset Policy via Boot Parameters

Add the ima_policy policy parameter to the kernel boot parameters as follows:
grubby --args="ima_policy=tcb" --update-kernel=/boot/vmlinuz-`uname -r`
In addition to specifying IMA policies, kernel boot parameters provide finer-grained control over IMA behavior. Common IMA boot parameters include:
Boot Parameter
Value
Meaning
ima_hash
sha1/sha256/sm3/md5/...
Sets the measurement algorithm used by IMA, which defaults to SHA256.
ima_template
ima/ima-ng/ima-sig
Sets the measurement template used by IMA.
ima_appraise
off
Disables the IMA appraise feature.
fix
Sets the IMA appraisal fix mode, which labels files with the security.ima extended attribute and can be used during environment initialization.
log
Sets the IMA appraisal log mode, which only verifies file integrity but does not perform access control, and only records audit logs.
enforce
Sets the IMA appraisal enforcement mode, which verifies file integrity and enforces access control based on the verification results.
ima_policy
tcb
Uses the IMA preset measurement policy. See the next section for details.
appraise_tcb
Uses the IMA preset appraisal policy to appraise all files owned by the root user.
secure_boot
Uses the IMA preset appraisal policy to appraise the integrity of the kernel, kernel modules, firmware, IMA policies, and others.
integrity_audit
0
Provides basic audit information (by default).
1
Provides detailed audit information.
A restart is required after the boot parameter is added for it to take effect.

Method 2: Importing a Custom Policy via the Policy API

At runtime, you can interact with IMA through the SecurityFS interface, which is located at /sys/kernel/security/ima:
SecurityFS API
Permissions
Function
ascii_runtime_measurement
440
Provides a runtime measurement list in ASCII format.
binary_runtime_measurement
440
Provides a runtime measurement list in binary form.
runtime_measurement_count
440
Provides the total number of system IMA measurement logs.
violations
440
Provides the number of system IMA measurement conflicts.
policy
600
Custom IMA policy read-write API.
The above five APIs all have read permissions, which can be viewed using the cat command. Among them, the fifth API has write permission and can be used to update custom policies into the kernel:
echo /etc/ima/ima-policy > /sys/kernel/security/ima/policy
Note: Here, /etc/ima/ima-policy can be replaced with any other absolute path.

Configuring an IMA Measurement Policy

IMA measurement policies define the specific behavior of IMA. The measurement policy file contains multiple policy rules, each consisting of one or more tokens. Tokens are mainly divided into two categories:
Behavior token: specifies the behavior mode of IMA (measurement/appraisal/audit). Each rule must have exactly one behavior token. For common values, see the table below.
Condition matching token: checks whether a request to be measured matches the condition. Multiple condition matching tokens are allowed, but a condition matching token of the same type can be specified only once within a rule. For common values, see the table below.
Commonly used behavior tokens supported by IMA are as follows:
Behavior Token
Description
measure
Indicates the measurement of file objects. During the measurement process, a digest value is calculated for the file content, and this digest, along with related information, is written into a measurement log entry. The log entry is then added to the list of IMA runtime measurements. If the system has a TPM chip installed, the measurement value will be extended to PCR 10 of the TPM. IMA does not measure an object twice, meaning that duplicate file entries do not exist in a list of runtime measurements (unless the file content is modified), and the digest values of previously measured objects will not be extended to the TPM's PCR.
dont_measure
Indicates that file objects are not measured.
appraise
Indicates the appraisal of file objects, which uses the file's extended attribute security.ima to verify the integrity of the file content. If integrity is compromised and the current IMA appraise mode is enforce, an error is reported, indicating an appraisal failure.
dont_appraise
Indicates that file objects are not appraised.
audit
Indicates the audit of file objects. The audit log records the absolute path of the measured files along with the digest algorithm and digest value.
Commonly used condition matching tokens supported by IMA are as follows:
Condition Matching Token
Value
Meaning
func
FILE_CHECK
Indicates that before a regular file (including an existing regular file or a new one) is opened, this rule is used to measure the content of the target file. If a behavior token is specified but no condition matching token is specified, the default value of func is FILE_CHECK.
BPRM_CHECK
Indicates that before an executable file, shared library, or script called via a shebang interpreter is run, the content of the target file is measured.
MMAP_CHECK
Indicates that before memory mapping of a regular file (an existing regular file or a new one) with executable permissions, this rule is used to measure the content of the target file.
MODULE_CHECK
Indicates that before the kernel module file is loaded, the content of the target module file is measured.
FIRMWARE_CHECK
Indicates that before the firmware is loaded, the content of the target firmware file is measured.
mask
MAY_EXEC
Access points should be loading executable files/kernel modules/firmware or memory-mapping a regular file in EXEC-only mode.
MAY_WRITE
Access points should open regular files in write-only access mode.
MAY_READ
Access points should open regular files in read-only access mode.
MAY_APPEND
Access points should open regular files in append-only access mode.
^MAY_EXEC
Access points should be executing executable files or memory-mapping a regular file in READ|WRITE|EXEC mode.
^MAY_WRITE
Access points should open regular files in write access mode.
^MAY_READ
Access points should open regular files in read access mode.
^MAY_APPEND
Access points should open regular files in append access mode.
fsmagic
Hexadecimal string
File system fsmagic value.
fsuuid
Hexadecimal string
Block device file system UUID.
uid
Decimal number
Process UID.
euid
Decimal number
Process EUID.
fowner
Decimal number
File UID.
obj_user
LSM subject user
LSM subject user.
obj_role
LSM subject role
LSM subject role.
obj_type
LSM subject type
LSM subject type.
subj_user
LSM object user
LSM object user.
subj_role
LSM object role
LSM object role.
subj_type
LSM object type
LSM object type.
The following takes the default measurement policy corresponding to the kernel boot parameter ima_policy=tcb as an example to explain how IMA measures system files under this policy:
dont_measure fsmagic=0x9fa0
dont_measure fsmagic=0x62656572
dont_measure fsmagic=0x64626720
dont_measure fsmagic=0x1021994
dont_measure fsmagic=0x1cd1
dont_measure fsmagic=0x42494e4d
dont_measure fsmagic=0x73636673
dont_measure fsmagic=0xf97cff8c
dont_measure fsmagic=0x27e0eb
dont_measure fsmagic=0x6e736673
measure func=MMAP_CHECK mask=MAY_EXEC
measure func=BPRM_CHECK mask=MAY_EXEC
measure func=FILE_CHECK euid=0
measure func=FILE_CHECK uid=0
measure func=MODULE_CHECK
measure func=FIRMWARE_CHECK
measure func=POLICY_CHECK
dont_measure fsmagic=xxx indicates that files in specific file system types (identified by file system superblock identifiers) will not be measured. These file systems are:
magic Value
File System Name
0x9fa0
procfs pseudo file system
0x62656572
sysfs pseudo file system
0x64626720
debugfs pseudo file system
0x1021994
tmpfs pseudo file system
0x1cd1
devpts pseudo file system
0x42494e4d
binfmt_misc pseudo file system
0x73636673
securityfs pseudo file system
0x27e0eb
cgroup pseudo file system
0x6e736673
namespace pseudo file system
These file systems that do not require measurement are all memory-resident pseudo file systems. Their data is not written to disk, so measuring them is of no practical significance.
measure func=MMAP_CHECK mask=MAY_EXEC indicates measuring the content of mmap() file mappings with the PROT_EXEC flag. Since shared libraries are typically loaded into the process address space through this mechanism, this rule can be approximately understood as measuring the integrity of shared libraries.
measure func=BPRM_CHECK mask=MAY_EXEC indicates measuring executable files (including scripts) executed through the execve() system call.
measure func=FILE_CHECK euid=0 indicates measuring the content of files accessed by users with an EUID of 0 (root users and users with sudo permissions).
measure func=FILE_CHECK uid=0 indicates measuring the content of files accessed by users with a UID of 0 (root users).
measure func=MODULE_CHECK indicates measuring loaded kernel modules.
measure func=FIRMWARE_CHECK indicates measuring loaded firmware files.
measure func=POLICY_CHECK indicates measuring the content of the IMA policy additionally written to /sys/kernel/security/ima/policy.

auditd

Introduction to Audit

Linux Audit provides a way to track security-related information in the system. Through preconfigured rules, Audit generates log entries that record information about events occurring in the system. Audit itself does not provide additional security — it cannot prevent system vulnerabilities or malicious exploitation of the system. Audit is only used to track relevant security events and help users take additional security measures (such as SELinux) to prevent these issues.
Audit consists of multiple components, each providing critical functionality for the overall framework. The Audit kernel module intercepts system calls and records relevant events. The auditd daemon writes audit reports to disk. Various command line utilities handle the display, querying, and archiving of audit trails.
Audit mainly consists of the following programs:
auditd: The Audit daemon process is responsible for writing audit information generated through the audit kernel interface to the audit.log file and saving it to disk. The startup of auditd is controlled by systemd, and the functionality of auditd is controlled by /etc/audit/auditd.conf.
auditctl: Controls the log generation parameters and kernel settings of the kernel audit interface, as well as the audit rule set for tracking events.
audit.rules: /etc/audit/audit.rules contains a series of auditctl commands, which are loaded by auditd.
aureport: Can create custom reports based on audit event logs.
ausearch: Used to search for specific events in the audit log file audit.log.
audispd: Relays audit event notifications to other programs instead of writing them to the audit log on disk.
autrace: Traces a single process in a manner similar to strace and records the output to the audit log.

Basic Audit Configurations

Configuring auditd

Before performing Linux system auditing, you need to configure Audit. The Audit configuration file is located at /etc/audit/auditd.conf and can be opened with any text editor. Common configuration items are as follows:
log_file: Defines the location and name of the audit log file. The default location is usually /var/log/audit/audit.log.
log_format: Defines the format of the audit log. It supports five parameters: raw, user, json, enriched, and verbose.
max_log_file_action: Defines the action to take when the audit log file reaches its maximum size. It is generally set to keep_logs to prevent the audit log file from being overwritten.
space_left: Defines the free space that must be reserved in the audit log file system.
space_left_action: Defines the action to take when free space in the audit log file system is insufficient. It is recommended to set this parameter to email or exec with an appropriate notification method configured.
admin_space_left: Defines the free space that must be reserved in the administrator space.
admin_space_left_action: Defines the action to take when free space in the administrator space is insufficient. It should generally be set to single to put the system into single-user mode.

Audit Daemon Process

First, the kernel needs to enable the CONFIG_AUDIT and CONFIG_AUDITSYSCALL configurations. The TencentOS Server kernel enables Audit-related configurations by default.
After confirming that the kernel supports the auditing feature, start the auditd service to collect relevant audit information and save it to a log file. Run the following command as the root user to start auditd:
service auditd start
Configure auditd to start at boot. TencentOS Server 4 does not enable auditd auto-start at boot by default. Run the following command to enable it:
systemctl enable auditd
To temporarily disable auditd, run auditctl -e 0. To re-enable it, run auditctl -e 1.
You can use service auditd <command> to control auditd to perform other operations. The command can be one of the following:
Command
Function
stop
Stops auditd.
restart
Restarts auditd.
reload/force-reload
Reloads the auditd configuration in /etc/audit/auditd.conf.
rotate
Backs up old log files and writes logs to new blank log files.
resume
Resumes temporarily disabled auditd.
condrestart/try-restart
Restarts auditd when it is running.
status
Shows the running status of auditd.
Note:
The service command is the only way to properly interact with the auditd process. The systemctl command can only be used for two operations: enable and status. All other commands must use service.

Introduction to Audit Logs

To use Audit, you must understand how the logs generated by the audit daemon are structured and what specific information Audit records for events. Only after obtaining this information can you determine which report types best suit your needs.
By default, Audit records log entries in the /var/log/audit/audit.log file. We use an example to describe the record parameters of Audit logs. Add the following audit rule to record read and write operations on the /boot/grub2/grub.cfg file.
auditctl -D
auditctl -w /boot/grub2/grub.cfg -p warx -k grub.cfg
The record of this event in audit.log is as follows:
type=SYSCALL msg=audit(1677250085.590:313): arch=c000003e syscall=257
success=yes exit=3 a0=ffffff9c a1=7fff8b0d2d09 a2=0 a3=0 items=1
ppid=1098 pid=1649 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=ttyS0 ses=1 comm="cat" exe="/usr/bin/cat"
subj=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 key="grub.cfg" ARCH=x86_64
AUID="root" UID="root" GID="root" EUID="root" SUID="root"
FSUID="root" EGID="root" SGID="root" FSGID="root"
type=CWD msg=audit(1677250085.590:313): cwd="/var/log/audit"
type=PATH msg=audit(1677250085.590:313): item=0
name="/boot/grub2/grub.cfg" inode=524302 dev=fc:01 mode=0100600 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:boot_t:s0 nametype=NORMAL
cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 OUID="root"
OGID="root"
type=PROCTITLE msg=audit(1677250085.590:313):
proctitle=636174002F626F6F742F67727562322F677275622E636667
The above event consists of four records that share the same timestamp and serial number. A record always starts with the type= keyword. Each record consists of multiple name=value pairs separated by spaces or commas. A detailed analysis of the above event is as follows:
First record:
Field
Description
type=SYSCALL
The type field contains the record type. In this example, the SYSCALL value specifies that this record is triggered by a system call to the kernel.
msg=audit(1677250085.590:313)
The msg field records the timestamp and unique ID of the record, in the format of audit(time_stamp:ID). If multiple records are generated as part of the same audit event, they share the same timestamp and ID. The timestamp uses the Unix time format - the number of seconds since 00:00:00 UTC on January 1, 1970.
arch=c000003e
The arch field contains the CPU architecture information of the system. The value c000003e is encoded in hexadecimal notation. When using the ausearch command to search audit records, use the -i or --interpret option to automatically convert hexadecimal values into human-readable equivalents. The c000003e value is interpreted as x86_64.
syscall=257
The syscall field records the type of system call sent to the kernel. The value 257 can be matched with its human-readable equivalent in the /usr/include/asm/unistd_64.h file. In this example, 257 is the openat system call. The ausyscall utility can convert system call numbers to their human-readable equivalents. Use the ausyscall --dump command to display a list of all system calls and their numbers.
success=yes
The success field records whether the system call recorded in this specific event succeeded or failed. In this case, the call succeeded.
exit=3
The exit field contains a value that specifies the exit code returned by the system call. This value varies with different system calls.
a0=ffffff9c, a1=7fff8b0d2d09, a2=0, a3=0
The a0 to a3 fields record the first four arguments of the system call in this event, encoded in hexadecimal notation. These arguments depend on the system call used and can be interpreted by using the ausearch utility.
items=1
The items field contains the number of PATH auxiliary records that follow the system call record.
ppid=1098
The ppid field records the parent process ID (PPID). In this case, 1098 is the PPID of the parent process, such as bash.
pid=1649
The pid field records the process ID (PID). In this example, 1649 is the PID of the cat process.
auid=0
The auid field records the audit user ID, that is, the loginuid. This ID is assigned to the user at login and is inherited by every process, even if the user identity changes, for example, when the su - user command is used to switch user accounts.
uid=0
The uid field records the user ID of the user who started the analysis process. Use the following command to interpret the user ID as a username: ausearch -i --uid UID.
gid=0
The gid field records the group ID of the user who started the analysis process.
euid=0
The euid field records the effective user ID of the user who started the analysis process.
suid=0
The suid field records the set user ID of the user who started the analysis process.
fsuid=0
The fsuid field records the file system user ID of the user who started the analysis process.
egid=0
The egid field records the effective group ID of the user who started the analysis process.
sgid=0
The sgid field records the group ID of the user who started the analysis process.
fsgid=0
The fsgid field records the file system group ID of the user who started the analysis process.
tty=ttyS0
The tty field records the terminal from which the analysis process was invoked.
ses=1
The ses field records the session ID of the session from which the analysis process was invoked.
comm="cat"
The comm field records the command line name used to invoke the analysis process. In this example, the cat command is used to trigger this audit event.
exe="/usr/bin/cat"
The exe field records the path of the executable file used to invoke the analysis process.
subj=root:sysadm_r:sysadm_t:s0-s15:c0.c1023
The subj field records the SELinux context with which the analyzed process was labeled during execution.
key="grub.cfg"
The key field records an administrator-defined string associated with the rule that generated the event in the audit log. If a series of repeated keys follows, the preceding key=value is interpreted into a human-readable explanation.
Second record:
Field
Description
type=CWD
In the second record, the type field value is CWD - current working directory. This type is used to record the working directory of the process from which the system call specified in the first record is invoked. The purpose of this record is to record the location of the current process in case a relative path is captured in the related PATH record. In this way, the absolute path can be reconstructed.
msg=audit(1677250085.590:313)
The msg field holds the same timestamp and ID values as those in the first record. The timestamp uses the Unix time format.
cwd="/var/log/audit"
The cwd field contains the path of the directory where the system call is located.
Third record:
Field
Description
type=PATH
In the third record, the type field value is PATH. An audit event contains a PATH type record for each path passed as a parameter to a system call. In this audit event, only one path (/boot/grub2/grub.cfg) is used as a parameter.
msg=audit(1677250085.590:313)
The msg field has the same timestamp and ID values as those in the first and second records.
item=0
The item field indicates which item the current record is among the total number of items referenced by a SYSCALL type record. This number is zero-based, and a value of 0 indicates that it is the first item.
name="/boot/grub2/grub.cfg"
The name field records the path of the file or directory passed as a parameter to a system call. In this example, it is the /boot/grub2/grub.cfg file.
inode=524302
The inode field contains the inode number associated with the file or directory recorded in this event.
dev=fc:01
The dev field specifies the minor and major IDs of the device containing the file or directory recorded in this event. In this example, the value represents the /dev/fc/1 device.
mode=0100600
The mode field records the permissions of a file or directory, represented by a numeric value. It is the value in the st_mode field returned by the stat command. For more information, see the stat(2) man page. In this case, 0100600 can be interpreted as -rw-------, which means that only the root user has read and write permissions on the /boot/grub2/grub.cfg file.
ouid=0
The ouid field records the user ID of the object owner.
ogid=0
The ogid field records the group ID of the object owner.
rdev=00:00
The rdev field contains a recorded device identifier and is used only for special files. In this case, it is not used because the recorded file is a regular file.
obj=system_u:object_r:boot_t:s0
The obj field records the SELinux context with which the recorded file or directory was labeled during execution.
nametype=NORMAL
The nametype field records the operation intent of each path record in the context of a given system call.
cap_fp=none
The cap_fp field records data related to setting the file system-based allowed capabilities of a file or directory object.
cap_fi=none
The cap_fi field records data related to the inherited file system-based capability settings of a file or directory object.
cap_fe=0
The cap_fe field records the setting of the effective bits of file system-based capabilities for a file or directory object.
cap_fver=0
The cap_fver field records the version of file system-based capabilities for a file or directory object. Similar to the first record, when two duplicate keys follow, the preceding key=value is explained in a human-readable translation.
Fourth record:
Field
Description
type=PROCTITLE
The type field contains the record type. In this example, the PROCTITLE value specifies that this record provides the full command line that triggered this audit event, which was triggered by a system call to the kernel.
proctitle=636174002F626F6F742F67727562322F677275622E636667
The proctitle field records the full command line used to invoke the analysis process. This field is encoded in hexadecimal notation to prevent users from influencing the audit log parser. The 636174002F626F6F742F67727562322F677275622E636667 value is interpreted as cat /boot/grub2/grub.cfg. When using the ausearch command to search audit records, use the -i or --interpret option to automatically convert hexadecimal values into human-readable equivalents.

Defining an Audit Rule

The audit system operates based on a set of rules that define what is captured in log files. You can use the auditctl tool to set audit rules on the command line or in the /etc/audit/rules.d/ directory.
Use the auditctl command to control the basic features of the audit system and define rules that determine which audit events are recorded. Here are some examples for reference:
Define a rule to record all write access and attribute modifications to the /etc/passwd file:
auditctl -w /etc/passwd -p wa -k passwd_changes
Define a rule to record all write access and attribute modifications to all files in the /etc/selinux/ directory:
auditctl -w /etc/selinux/ -p wa -k selinux_changes
Define a rule to create a log entry whenever a program uses the adjtimex or settimeofday system call on a 64-bit architecture:
auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
Define a rule to create a log entry whenever a system user with an ID of 1000 or above deletes or renames a file:
auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
-F auid!=4294967295 is used to exclude users who have not set a login UID.
Define a rule to record all executions of the /bin/id program, and run the following command:
auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id

Persisting an Audit Rule

To ensure that audit rules persist after a restart, you must include them directly in the /etc/audit/rules.d/audit.rules file, or use the augenrules program to read rules from the /etc/audit/rules.d/ directory. Note that the /etc/audit/audit.rules file is generated each time the auditd service starts. Files in /etc/audit/rules.d/ can use the same auditctl command-line syntax to specify rules. The preceding examples can be recorded in the audit.rules file as follows:
-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux/ -p wa -k selinux_changes
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
-a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id
After modifying the rule file, use the augenrules command to load the rules:
augenrules --load

Using a key to Identify an Audit Event

In the preceding audit rule examples, each rule specifies a key through the -k parameter, such as passwd_changes, selinux_changes, and time_change. A key is an administrator-defined string identifier used to mark audit log entries generated by that rule. You can use keys to efficiently filter massive volumes of audit logs and quickly locate events for specific rules, improving the efficiency of audit analysis and event tracking.

Querying an Audit Log with ausearch

The ausearch command is used to search for specific events in audit log files. It supports queries by various criteria, including key, user, time, and system call. Common options are as follows:
Option
Description
-k, --key <key>
Search audit events by key string
-i, --interpret
Interpret hexadecimal values in a human-readable form.
-a, --event <event>
Search by event ID.
-ua, --uid <uid>
Search by user ID (including uid and auid).
-ts, --start <start>
Specify the start time of the search.
-te, --end <end>
Specify the end time of the search.
-f, --file <file>
Search by file name.
-sc, --syscall <syscall>
Search by system call name or number.
-x, --executable <executable>
Search by executable file path.
-m, --message <message>
Search by message type.
The following are some common examples of using ausearch:
Search for audit events by key and display them in a readable format:
 ausearch -k grub.cfg -i
Search for audit events by time range:
 ausearch -ts today -te now -i
Search for audit events by file name:
 ausearch -f /etc/passwd -i
Search for audit events by system call:
ausearch -sc openat -i
Search for audit events by user:
 ausearch -ua 0 -i

Generating an Audit Report with aureport

The aureport command is used to generate custom summary reports based on audit event logs, helping administrators quickly understand the system security status. Common options are as follows:
Option
Description
-l, --login
Generate login-related reports.
-f, --file
Generate file access-related reports.
-s, --syscall
Generate system call-related reports.
-u, --user
Generate user-related reports.
-e, --event
Generate event-related reports.
-p, --pid
Generate process-related reports.
-x, --executable
Generate executable file-related reports.
-c, --config
Generate configuration change-related reports.
-ts, --start <start>
Specify the start time of the report.
-te, --end <end>
Specify the end time of the report.
-i, --interpret
Interpret hexadecimal values in a human-readable form.
--failed
Include only failed events.
--success
Include only successful events.
The following are some common examples of using aureport:
Generate a login-related report:
aureport -l -i
Generate a report on file access:
 aureport -f -i
Generate a user-related report:
aureport -u -i
Generate a system call-related report:
aureport -s -i
Generate a report for a specified time range:
aureport -ts today -te now -i
Generate a report that contains only failed events:
aureport --failed -i

Anterior: OpenSCAP Security Compliance ScanningPróximo: Network Configuration Guide

Ajuda e Suporte

Esta página foi útil?

comentários

Search
    Enter keywords to search documentation