Red Hat Enterprise Linux Diagnostics and Troubleshooting
Advanced Intrusion Detection Environment (AIDE) is a tool that compares and reports file and directory modifications. Configure AIDE to monitor files for changes including to permissions or ownership, timestamps (modification or access), or file contents. When changes are detected, a log entry is created in the /var/log/aide/aide.log file.
Install AIDE from the aide RPM package. The aide package provides the aide utility, configuration files, and documentation on tuning to monitor specific changes of interest.
[root@host ~]# yum install aideThe /etc/aide.conf file is the primary configuration file for AIDE. It has three types of configuration directive: configuration, selection, and macro.
- Configuration
Configuration lines take the form
param = value. When param is not a built-in AIDE setting, it is a group definition that lists which changes to look for. By default, AIDE provides the following group definitions in the/etc/aide.conffile:PERMS = p+i+u+g+acl+selinux
This line defines a group called
PERMSthat looks for changes in file permissions (p), inode (i), user ownership (u), group ownership (g), ACLs (acl), or SELinux context (selinux).- Selection
Selection lines define which checks are performed on matched directories. The following lines are examples of selection lines:
/dir1
group=/dir2group!/dir3The first line performs the group of checks on
/dir1and all of its subdirectories. The second line performs the group of checks on/dir2. The equal sign indicates to check the directory only and not to recurse below it. The third line excludes from checks/dir3and everything below it.- Macro
Macro lines define variables, with this syntax:
@@define VAR value
@@{VAR}refers to the defined macro.
The aide.conf configuration file can include comments, which start with the # character.
After configuring the aide.conf file, initialize the AIDE database, and initially scan the file system.
To initialize the AIDE database, use the aide --init command.
[root@host ~]# aide --initInitializing AIDE creates the database in a /var/lib/aide/aide.db.new.gz file. Rename the file to /var/lib/aide/aide.db.gz, by removing the new string, to create the expected database name for the AIDE service.
[root@host ~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzWarning
Because users with local system access might manipulate the database, recommended security practice is to move or copy the database to a secured location between validation runs. To perform an AIDE check, the database must be restored or compared to the secure archived version to detect any tampering.
Use the aide --check command to check a file system. After the database is created, you can check a file system by running the aide --check command. This command scans the file system and compares the current state of files with the information in the AIDE database. Any differences are displayed to the terminal, and show both the original file state and the new condition.
[root@host ~]# aide --checkNote
Several applications or services can create, touch, or modify many files. For example, the prelink cron job creates dynamic library links to launch executable file launching faster. AIDE captures these changes in an AIDE database, with the impression that the binaries changed. Either disable the prelink cron job, if appropriate, or learn to recognize non-intrusive file changes.
Create a shell script that checks the /var/log/aide/aide.log file for alerts and then emails selected users.
if ! grep "Looks okay" /var/log/aide/aide.log &>/dev/null then cat /var/log/aide/aide.log | /usr/bin/mail -s "AIDE Alert" user@host fi
To automate the file system check, create the /etc/cron.d/aide cron job with the following content:
# AIDE Checks and alert */2 * * * * root /sbin/aide --check & /root/aide_mon.sh
Use the aide --update command to update the AIDE database with wanted changes to files.
[root@host ~]# aide --updateFor each database update, you must rename the new /var/lib/aide/aide.db.new.gz file to /var/lib/aide/aide.db.gz for the next run of an AIDE check. After completing the update, run the aide --check command to verify that the database and the file system match.
Update the database with wanted changes:
[root@host ~]# aide --updateNote
It is recommended to back up the previous database file before renaming the new database file.
Create a backup copy of the current database:
[root@host ~]# mv /var/lib/aide/aide.db.gz /var/lib/aide/aide.db.old.gzRename the new database by removing the new substring:
[root@host ~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzVerify that no differences exist between the current database and the file system:
[root@host ~]# aide --checkThe auditd daemon is the user-space component of the Linux auditing subsystem. When auditd is running, kernel-generated audit messages are collected in the auditd file, by default /var/log/audit/audit.log. If auditd is not running for any reason, kernel audit messages are sent to rsyslog.
By default, limited messages are passed through the audit system, such as authentication and authorization messages when users log in or use sudo, and SELinux messages. Security administrators can use auditctl to add auditing rules for any system call, including file operations. By default, auditing rules are added to the bottom of the current list. Rules can be inserted to manage rule order.
Important
Because audit rules work on a first-match-wins basis, ordering is important for rules to function as intended. For example, if one rule logs access to all files in the /etc directory and a later rule logs access to all files in the /etc/sysconfig directory, then the later rule would never be reached because the earlier rule was already triggered for any access at or below the /etc directory. By switching the order of these two rules, both rules would work as intended.
A watch rule is one of the most basic rules. Watch rules are set on files and directories, and can be configured for specific types of access, such as read, write, attribute change, and execute. Watches are triggered on the initial open system call, which requests the access type, and not on the subsequent, repetitive read or write calls to the same open file.
Some examples of watches:
auditctl -w /etc/passwd -p wa -k user-edit
This line adds a watch rule for /etc/passwd write and attribute change access, and adds a custom user-edit key to all log messages.
auditctl -w /etc/sysconfig/ -p rwa -k sysconfig-access
This line adds a recursive watch to the /etc/sysconfig directory and to all files and directories beneath it. Logs read, write, and attribute change access, and add a custom sysconfig-access key to all log messages.
auditctl -w /bin -p x
This line audits the execution of binaries under /bin, and does not add a key phrase to the log messages.
Use the uppercase -W option to remove a file system watch rule. Do not confuse the uppercase W option with the lowercase -w option, which is used to write the original rule. Use the lowercase -d option to remove rules that were added with lowercase -a or uppercase -A.
Use the auditctl -D command to remove all rules.
To make auditing rules persistent, add them to the /etc/audit/rules.d/audit.rules file. This file contains auditctl command syntax as entered on the command line, without the auditctl command itself. Empty lines are permitted, and comment lines start with the hash character (#).
When the auditd service is started, it activates all rules from /etc/audit/rules.d/audit.rules. The auditctl command can load rules from a file with the -R option.
Important
By design, auditd cannot be reloaded with systemctl restart auditd, because this action would log the credentials of the kernel (PID 1) as the process that sends the kill signal. Instead, use service auditd restart to reload changes to persistent rules. The service command intentionally logs the UID of the user who initiated the action.
Audit messages that are logged to /var/log/audit/audit.log contain significant information. The fields, which are each labeled, differ by message types. The following example is a typical audit record from /var/log/audit/audit.log.
type=SYSCALLmsg=audit(1371716130.596:28708)
: arch=c000003e syscall=2 success=yes exit=4 a0=261b130 a1=90800 a2=e a3=19 items=1 ppid=2548 pid=26131 auid=500
uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="aureport"
exe="/sbin/aureport"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="audit-access"
type=CWD msg=audit(1371716130.596:28708): cwd="/root" type=PATH msg=audit(1371716130.596:28708): item=0 name="/var/log/audit" inode=17998 dev=fd:01 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:auditd_log_t:s0
| The type of audit message. In this example, a system call was audited. |
| The timestamp and ID of the audit message. The number before the colon (in this case, |
| The original, or Audit, UID of the user who triggered this audit message. The audit system tracks the original UID even when a user elevates their privileges through |
| The Effective UID of the user who triggered this audit message. The Effective UID might be different from the Audit UID, and even from the regular UID; for example, when running a binary with the |
| The executable name that triggered this audit message, as reported by |
| The name of the stored binary file for the process that triggered this audit message. |
| An identifier to search for events. Custom auditing rules typically set keys to help to filter for event types. |
The auditing system includes the ausearch audit log searching tool. Not only does ausearch easily search for and filter various event types, it can also interpret events by translating numeric values into readable values such as user names or system call names. Common ausearch options are listed here, and more options are available to search for events based on user, terminal, or virtual machine.
| Option | Description |
|---|---|
-i
| Interpret log line, and translate numeric values into names. |
--raw
| Print raw log entries, without record separators between entries. |
-a
| Show all lines for the event with this event ID. |
--file
| Include all events for a specific file name. |
-k
| Search for all events that are labeled with a key. |
--start
| Include only events after the date and time.
If no start time is included, then assume midnight.
Omitting a starting date assumes today. |
The appropriate time format depends on your system's current locale. Other acceptable time values include recent (past 10 minutes), this-week, this-month, and this-year. The --end time option specifies all remaining audit entries.
In this example, ausearch displays an interpreted version of the previous example, filtered by the audit-access key value.
[root@host ]# ausearch -i -k audit-access
type=PATH msg=audit(06/20/2013 10:15:30.596:28708) : item=0 name=/var/log/audit inode=17998 dev=fd:01 mode=dir,750 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:auditd_log_t:s0
type=CWD msg=audit(06/20/2013 10:15:30.596:28708) : cwd=/root
type=SYSCALL msg=audit(06/20/2013 10:15:30.596:28708) : arch=x86_64 syscall=open success=yes exit=4 a0=261b130 a1=90800 a2=e a3=19 items=1 ppid=2548 pid=26131 auid=student uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=aureport exe=/sbin/aureport subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=audit-accessReferences
For more information about aide, see the aide(1) and aide.conf(5) man pages.
For more information about auditd, see the auditd(8), auditd.conf(5), auditctl(8), and audit.rules(7), and ausearch(8) man pages.
