你要改变的是自己的头脑，而不是去改变别人。

HOWTO configure the auditing of the system (auditd)

Introduction

The audit service is provided for system auditing. By default, this service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo.

Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance. The audit service, configured with at least its default rules, is strongly recommended for all sites, regardless of whether they are running SELinux. Networks with high security level often have substantial auditing requirements and auditd can be configured to meet these requirements:

Ensure Auditing is Configured to Collect Certain System Events

Information on the Use of Print Command (unsuccessful and successful)

Startup and Shutdown Events (unsuccessful and successful)

Ensure the auditing software can record the following for each audit event:

When the event appears

Who initiated the event

Type of the event

Success or failure of the event

Origin of the request (example: terminal ID)

For events that introduce an object into a user’s address space, and for object deletion events, the name of the object, and in MLS systems, the objects security level.

Log files are stored in /var/log/audit/audit.log. auditd rotates logs by size of 5MB with a retention of 4 files. it results by a maximum of 20MB of audit data in total, and auditd refuses to write entries when there is not enough space left of the file system to avoid the risk of audit data filling the file system and impacting other services. However, it is possible to lose audit data if the system is too loaded.

Configure data retention

Amount of data to retain

First of all is to determine the amount of audit data (in megabytes) that will be retained in each log file. Then edit the file /etc/audit/auditd.conf:

Command: editing /etc/audit/auditd.conf

# vi /etc/audit/auditd.conf

Add or modify the following line (where SIZE is the chosen amount of audit data in megabytes):

Config File: /etc/audit/auditd.conf

...
max_log_file = SIZE
...

Dedicated partition

Use a dedicated file system for log files. It is very simple to create such a partition or logical volume during system installation time. The file system should be larger than the maximum space which auditd will use, which is in fact the maximum size of each log file (max_log_file parameter) multiplied by the number of log files (num_logs parameter).

One the file system is created, add the following line into /etc/fstab (modify it to fit the system configuration):

Avoid the loose of audit data

If you don’t want to loose any audit data, it is possible to disable the machine when auditing cannot be performed, configure auditd to shutdown the system when the file system for auditing become low.

The default action to take when the logs reach their maximum size is to rotate them, deleting the oldest one. If it is more important to retain all possible auditing information, even if it opens the possibility of filling completely the file system and taking the action defined by admin_space_left_action, add or modify the line:

Config File: /etc/audit/auditd.conf

...
max_log_file_action = keep_logs
...

Enable auditing for processes starting before the auditd service

Each process on the system has an auditable flag which indicates whether its activities can be audited. auditd takes care of enabling it for all processes which launch after it does, adding a kernel argument ensures that it is set for every process during boot.

To ensure that all processes can be audited, add the argument audit=1 to the kernel line in /etc/grub.conf:

Configure comprehensive auditing rules

The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing but should not be considered as a complete guide.

Monitoring of specific files for modifications to the file’s contents or metadata.

Auditing rules are controlled in the file /etc/audit/audit.rules. All the lines in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested as such. See documentation in /usr/share/doc/audit-VERSION and in the man pages for more details.

Recommended audit rules are provided in the template /usr/share/doc/audit-VERSION/stig.rules. To activate those rules copy them to auditd configuration directory:

Command: copying recommended audit rules

# cp /usr/share/doc/audit-VERSION/stig.rules /etc/audit/audit.rules

Then edit /etc/audit/audit.rules and comment out the lines containing arch= which are not appropriate. Then review the other rules, ensuring rules are activated as needed for the appropriate architecture. After reviewing all the rules, activate them using the following command:

Command: restarting the auditd service

# service auditd restart

Records events that modify time information

Add the following lines to /etc/audit/audit.rules, replace ARCH to b32 or b64 to fit the system:

Make the auditd Configuration Immutable

Add the following as the last rule in /etc/audit/audit.rules to make the configuration immutable:

Config File: /etc/audit/audit.rules

...
-e 2
...

After setting this rule, a reboot will be required to change any of the audit rules.

Using aureport

Use the command aureport to design a short series of audit reporting commands suitable for exploring the audit logs on a regular basis. These commands can be added as a cron job by placing an appropriately named file in /etc/cron.daily.

For example, to generate a daily report of every user to login to the machine, the following command could be run from cron:

Command: displaying a report of every user to login to the machine

# aureport -l -i -ts yesterday -te today

To review all audited activity for unusual behavior, a good place to start is to see a summary of which audit rules have been triggering:

Command: reviewing all audited activity for unusual behavior

# aureport --key --summary

If access violations stand out, review them with:

Command: reviewing access violations

# ausearch --key access --raw | aureport --file --summary

To review what executables are doing:

Command: reviewing what executables are doing

# ausearch --key access --raw | aureport -x --summary

If access violations have been occurring on a particular file (such as /etc/shadow), use the following command to determine which user is doing this: