-
Medium/Average (~15 mins)
-
Understand how to use the Advanced Intrusion Detection Environment (AIDE)
-
Install AIDE on your Server A (servera) system
-
Initialize a baseline scan to capture the current state
-
Modify permissions and content on a select file
-
Run a scan to identify drift from the baseline
-
Set audit watches to capture who, when, and how
AIDE maintains a database that captures the state of critical system configuration files at a point in time, allowing for subsequent analysis to identify drift from a desired state. AIDE is able to determine what changes were made to a system, but is not able to determine who made the change, when the change occurred, and what command was used to make the change. For that, you use auditd and ausearch, which are installed and enabled by default.
AIDE and audit watches are complementary security tools that can help you harden your environment. AIDE allows you to configure files and directories that you want to watch, and audit watches allow you to determine the who, when, and how related to a particular change. These can be fine-tuned over time to include scans of custom files and directories as well as watches over the files and directories you deem most critical. More information can be found in the Red Hat Enterprise Linux Security Guide.
-
If you are not already there, log in to the workstation bastion host as lab-user from your desktop system (replacing
GUIDwith your lab-provided GUID and using r3dh4t1! as the password):[localhost ~]$ ssh [email protected]
-
Log in to the servera.example.com host as root:
[lab-user@workstation-GUID ~]$ ssh [email protected]
NoteAIDE is part of the base repository that comes standard with Red Hat® Enterprise Linux® (RHEL), but it is not installed by default.
-
As root, install the AIDE package:
[root@servera ~]# yum search aide [root@servera ~]# yum install aide.x86_64
-
After AIDE is installed, review the configuration file located at:
[root@servera ~]# less /etc/aide.conf (Type q to exit less)
A review of this file shows you the directories and files that are scanned by default and provide a list of what is checked (for example, permissions and checksums).
TipYou can also refer to the man page as follows:
[root@servera ~]# man aide
Organizations often create a locked-down standard operating build for provisioning a server. This includes configuration of the operating system and other software packages.
-
After the server is provisioned, or after you have made configuration changes to an existing server, initiate an AIDE scan as follows:
[root@servera ~]# aide --init
The previous step takes a few minutes, so you may want to read ahead as you wait.
-
Look for output similar to the following to see that the process is complete:
Start timestamp: 2019-04-09 20:16:40 -0400 (AIDE 0.16) AIDE initialized database at /var/lib/aide/aide.db.new.gz
-
Rename or copy the database file by removing
new.from the generated filename as shown here, to complete the initialization:[root@servera ~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
You now have a baseline scan derived from the rules set up in
/etc/aide.conf. Note that you used the--initparameter (or-i) to initialize the baseline. In subsequent scans, you use--check(or-C) to check for changes. -
Run a check:
[root@servera ~]# aide --check
-
Examine the output and note that this scan does not disclose any deviations from the baseline:
Start timestamp: 2019-04-09 20:21:31 -0400 (AIDE 0.16) AIDE found NO differences between database and filesystem. Looks okay!!
-
Review the
/etc/aide.conffile and look for entries related to SSH:[root@servera ~]# vi /etc/aide.conf
-
Type the command :200 to go to line 200 and expect to see these two lines in the results:
/etc/ssh/sshd_config$ LSPP /etc/ssh/ssh_config$ LSPP
This means that AIDE is monitoring these two files and is looking specifically for changes to content based on the
sha256andsha512hashes. -
Find the definition for LSPP, by typing the command :81 to go to line 81, and expect to see these two lines:
# Just do sha256 and sha512 hashes LSPP = FIPSR+sha512
-
Examine the default rules beginning at line 26, by typing :26, and note the included parameters.
-
Type :q to exit vi, and then alter the permissions of the
/etc/ssh/sshd_configfile:[root@servera ~]# chmod 0644 /etc/ssh/sshd_config
-
Open the
/etc/ssh/sshd_configfile for editing so that you can alter its contents:[root@servera ~]# vi /etc/ssh/sshd_config
-
Jump to the end of the file by typing Shift+G.
-
Type the letter O to add a line to the end of the file, and append
UseDNS noto the end of the/etc/ssh/sshd_configfile. -
Press esc and type :wq! to save and exit.
When you run AIDE, you expect it to note the change of the permissions and identify a change in the checksum of the file.
-
Run a new scan and confirm:
[root@servera ~]# aide --check
-
Examine your output, which is similar to the following, and note that AIDE scanned your files and found differences:
[root@servera ~]# aide --check Start timestamp: 2019-04-09 20:53:34 -0400 (AIDE 0.16) AIDE found differences between database and filesystem!!
Summary: Total number of entries: 34527 Added entries: 0 Removed entries: 0 Changed entries: 1
Permission and content changes were made to the
/ssh/sshd_configfile.You can see which permissions were specifically changed. You can also see changes to other attributes such as user, group, or file type. As for content, you can see only that the checksum changes. You need to recover a previous version of the file to determine the exact content change. What you cannot tell is the identity of the user who made this change, or what time and how that change was made. For that, you must set audit watches.
-
To revert the changes you made in this section, which is necessary before proceeding to the next exercise, begin by resetting the permissions of
/etc/sshd_configback to0600:[root@servera ~]# chmod 0600 /etc/ssh/sshd_config
-
Open the file for editing so that you can remove the
UseDNS nofrom the end of the file:[root@servera ~]# vi /etc/ssh/sshd_config
-
In vi, jump to the end of the
/etc/ssh/sshd_configfile by typing Shift+G. -
Delete the last line that you added previously by pressing
ddon the last line,UseDNS no. -
Press :wq! to save and exit.
-
Verify that you reverted your changes correctly:
[root@servera ~]# aide --check
Expect to see a change in the timestamps (
mtime,ctime, etc.) but not to the content. -
(Optional) Run steps to eliminate the changes resulting from alteration of the timestamps for the next part of the lab.
The auditd daemon is installed and enabled by default in Red Hat Enterprise Linux. Log files reside at /var/log/audit/audit.log based on the configuration in /etc/audit/auditd.conf and the watches in /etc/audit/rules.d/audit.rules. Audit watches can be set dynamically for the duration of the runtime, or permanently by adding a file to the /etc/audit/rules.d/ directory.
In this section, you first enable a dynamic rule using the command line and check a specific file for permissions and attribute changes. You do this with the auditctl command.
A full list of watch parameters can be found by reviewing the man page.
-
Set a watch and establish a key for the
/etc/shadowfile:[root@servera ~]# auditctl -w /etc/shadow -pa -k shadow_key
-windicates that you are watching the/etc/shadowfile.-paindicates permissions and attributes are what you are watching.-kindicates that you created a key that you can use to search the audit log. -
Check for active watches:
[root@servera ~]# auditctl -l -w /etc/shadow -p a -k shadow_key
-
Reinitialize the database to account for the timestamp change in the
/etc/sshd_conffile from the previous step:[root@servera ~]# aide --init [root@servera ~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz [root@servera ~]# aide --check
-
Change the permission on the
/etc/shadowfile and run a scan:[root@servera ~] chmod 0666 /etc/shadow [root@servera ~]# aide --check
-
Look for the entry in the audit log in your output that is similar to this:
Start timestamp: 2019-04-09 21:20:27 -0400 (AIDE 0.16) AIDE found differences between database and filesystem!! Summary: Total number of entries: 34527 Added entries: 0 Removed entries: 0 Changed entries: 1 --------------------------------------------------- Changed entries: --------------------------------------------------- f = p.. .c...A.. : /etc/shadow --------------------------------------------------- Detailed information about changes: --------------------------------------------------- File: /etc/shadow Perm : ---------- | -rw-r--r-- Ctime : 2019-02-19 13:04:22 -0500 | 2019-04-09 21:20:22 -0400 ACL : A: user::--- | A: user::rw- A: group::--- | A: group::r-- A: other::--- | A: other::r-- --------------------------------------------------- The attributes of the (uncompressed) database(s): --------------------------------------------------- /var/lib/aide/aide.db.gz MD5 : L99C1z9U5hDXrVJkdxv8qg== SHA1 : 0qQnLmKrq8DPjoZGxV/9jBgopDE= RMD160 : YtlqppsIO4aGROFfZaiGYI0/GJQ= TIGER : mKlEijHuVsItkmycKWdZpCTGI4srEYAs SHA256 : VfDDweNBApFyGYrI+Ev7pvNQyGV6W5Kn 9syeJ5HvKWs= SHA512 : Kpi9byRr3Z9FJ7hCoP1eTSt8Ds1EGTYG ByiZuCGZpnz96xowEG3jxib/SqSRDnxI PB+ag/UbrRa6X1z4GB1iDQ== End timestamp: 2019-04-09 21:20:39 -0400 (run time: 0m 12s)Note in the output that the permissions on the
/etc/shadow filechanged. Because you set an audit watch on this file, you can now search for the key in the audit log by using theausearchcommand that comes withauditd. -
Search for the
shadow_keykey that you created above:[root@servera ~]$ ausearch -i -k shadow_key
-
Examine the entry returned in the
audit.log:type=CONFIG_CHANGE msg=audit(04/09/2019 21:18:44.578:127) : auid=root ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=add_rule key=shadow_key list=exit res=yes type=PROCTITLE msg=audit(04/09/2019 21:20:22.554:128) : proctitle=chmod 0644 /etc/shadow type=PATH msg=audit(04/09/2019 21:20:22.554:128) : item=0 name=/etc/shadow inode=4736901 dev=fd:00 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(04/09/2019 21:20:22.554:128) : cwd=/var/lib/aide type=SYSCALL msg=audit(04/09/2019 21:20:22.554:128) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xffffff9c a1=0x55a68921f670 a2=0644 a3=0xfff items=1 ppid=1656 pid=2685 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=chmod exe=/usr/bin/chmod subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=shadow_key
-
While there are many attributes in the log entry, find the five that are of particular interest:
msg-auditis the timestamp.nameis the object acted upon.auidis the login ID of the user who made the change (student).uidis the login ID of the user who ran the command (root).keyis the search key that you set up earlier.
If you decide you want to keep this watch, you must make it permanent. You do this by placing a watch in the /etc/audit/rules.d/audit.rules file. You insert the command in the file as you typed it on the command line, but you remove the term auditctl.
-
Open the file
/etc/audit/rules.d/audit.rulesfor editing:[root@servera ~]$ vi /etc/audit/rules.d/audit.rules
-
In vi, move down a line and type the letter o to begin a new line below the cursor and insert the following text:
-w /etc/shadow -pa -k shadow_key
-
Press Esc, and then save and exit by pressing :wq!.
-
When the service restarts, run
auditctl -lto verify that your rule has survived.NoteYour
auditdis configured to manually start and stop, so you must reboot the server to see this change. If you want to configure a watch, but do not want to reboot your server, create a dynamic rule as you have in this lab, and then update theaudit.rulesfile so that the rule becomes permanent. -
If you want to reboot your server to verify that your rule has survived, run the following:
[root@servera ~]$ reboot [lab-user@workstation-GUID ~]$ ssh [email protected] [root@servera ~]$ auditctl -l -w /etc/shadow -pa -k shadow_key
|
Warning
|
A server reboot in the lab environment can take some time. |