Red Hat Security: Linux in Physical, Virtual, and Cloud

From workstation, log in to servera as student. No password is required.

[student@workstation ~]$ ssh student@servera
Last login: Thu Jul 19 23:45:42 2018 from workstation.lab.example.com
[student@servera ~]$

Use sudo -i to change to the root user. Use student as the password.

[student@servera ~]$ sudo -i
[sudo] password for student: student
[root@servera ~]#

Use a text editor to modify /etc/aide.conf. Add selection lines to make AIDE use the CONTENT_EX group definition to monitor for any change to the /etc/shadow and /etc/passwd files. Delete the other selection lines in the configuration file.

[root@servera ~]# vim /etc/aide.conf

The last few lines of modified /etc/aide.conf file looks similar to the following:

...output omitted...
# Extended content + file type + access.
CONTENT_EX = sha256+ftype+p+u+g+n+acl+selinux+xattrs

# Some files get updated automatically, so the inode/ctime/mtime
# change
# but we want to know when the data inside them changes.
DATAONLY =  p+n+u+g+s+acl+selinux+xattrs+sha256

# Next decide what directories/files you want in the database. Aide
# uses a first match system. Put file specific instructions before
# generic
# matches. e.g. Put file matches before directories.

/etc/passwd     CONTENT_EX
/etc/shadow     CONTENT_EX

Use the aide --init command to initialize the AIDE database with the results of a baseline scan.

[root@servera ~]# aide --init

AIDE, version 0.15.1

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

Rename the new AIDE database file, /var/lib/aide/aide.db.new.gz, to /var/lib/aide/aide.db.gz so that AIDE uses the newly generated file as the current database.

[root@servera ~]# mv /var/lib/aide/aide.db.new.gz \
> /var/lib/aide/aide.db.gz

Run the aide --check command to determine the current status of the machine's file systems.

[root@servera ~]# aide --check

AIDE, version 0.15.1

### All files match AIDE database. Looks okay!

AIDE reports that there have been no changes to the files and directories it monitors. This makes sense, because you have not changed any files or directories since initializing the AIDE database.

AIDE will report that a file has changed, but not what or who changed it. You can add Audit rules to monitor your files so that when AIDE reports a change, you can look in the audit log to determine what or who might have caused that change.

Use the auditctl command to add a persistent Linux Audit watch rule to generate audit log entries whenever there is an attempt to read, write, execute, or change an attribute of the /etc/shadow file. Use shadow_watch as the filter key on the audit rule.

[root@servera ~]# echo "-w /etc/shadow \
> -p rwxa -k shadow_watch" >> /etc/audit/rules.d/audit.rules
[root@servera ~]# augenrules --load
...output omitted...

The augenrules --load command brings the newly added Audit rules into effect.

Use the auditctl -l command to list the Linux Audit rules and verify that the newly added audit rule is currently in effect.

[root@servera ~]# auditctl -l
-w /etc/shadow -p rwxa -k shadow_watch

Change the student password to redhat. This causes a change to the /etc/shadow file.

[root@servera ~]# passwd student
Changing password for user student.
New password: redhat
BAD PASSWORD: The password is shorter than 8 characters
Retype new password: redhat
passwd: all authentication tokens updated successfully.

Run the aide --check command to check the status of the machine's file systems.

[root@servera ~]# aide --check
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2018-07-20 14:46:53

Summary:
  Total number of files:  6
  Added files:            0
  Removed files:          0
  Changed files:          1


---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /etc/shadow

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------


File: /etc/shadow
SHA256   : Lvq+jrfjZzFg77krDaTUwcB85LB9LZJX , FxQh5cRZeFuFKvzbvA2iXWwWoesaVCji

The output of the command should report that the SHA256 checksum (and therefore the content) of the /etc/shadow file has changed.

To further investigate the change to /etc/shadow that AIDE reported, use ausearch to search the audit log. You can use the shadow_watch key used by your watch rule to filter for the events relevant to /etc/shadow. You can also use the -i option to convert numbers for UIDs and time stamps into names and more human-readable text.

The following output includes an example of one audit event that could be displayed.

[root@servera ~]# ausearch -i -f /etc/shadow -k shadow_watch
...output omitted...
----
type=PROCTITLE msg=audit(07/20/2018 14:30:08.319:631) : proctitle=passwd student
type=PATH msg=audit(07/20/2018 14:30:08.319:631) : item=0 name=/etc/shadow inode=288181 dev=fc:01 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(07/20/2018 14:30:08.319:631) :  cwd=/root
type=SYSCALL msg=audit(07/20/2018 14:30:08.319:631) : arch=x86_64 syscall=open success=yes exit=5 a0=0x7f7659b2323c a1=O_RDONLY a2=0x1 a3=0x7f7661aeec8c items=1 ppid=1710 pid=30271 auid=student uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=15 comm=passwd exe=/usr/bin/passwd subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=shadow_watch
----
...output omitted...

The output of ausearch should find a number of audit events, such as the one in the preceding output. Each event is separated by four dashes in the output, and the event number should appear in the output after the final colon in the time stamp (the msg field in each audit record). This is audit event 631.

This event consists of four records: PROCTITLE, PATH, CWD, and SYSCALL.

This is not the audit event that caused the change to /etc/shadow, because it opens the file read-only. However, it may be part of the sequence of audit events that led to the change. You need to look further at the output to find the correct event.

Further down in the output of ausearch, there should be an event that occurred at almost the same time, which looks similar to the following output:

...output omitted...
----
type=PROCTITLE msg=audit(07/20/2018 14:30:08.341:633) : proctitle=passwd student
type=PATH msg=audit(07/20/2018 14:30:08.341:633) : item=4 name=/etc/shadow inode=33578439 dev=fc:01 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=CREATE
type=PATH msg=audit(07/20/2018 14:30:08.341:633) : item=3 name=/etc/shadow inode=288181 dev=fc:01 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=DELETE
type=PATH msg=audit(07/20/2018 14:30:08.341:633) : item=2 name=/etc/nshadow inode=33578439 dev=fc:01 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=DELETE
type=PATH msg=audit(07/20/2018 14:30:08.341:633) : item=1 name=/etc/ inode=33554497 dev=fc:01 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=PATH msg=audit(07/20/2018 14:30:08.341:633) : item=0 name=/etc/ inode=33554497 dev=fc:01 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=CWD msg=audit(07/20/2018 14:30:08.341:633) :  cwd=/root
type=SYSCALL msg=audit(07/20/2018 14:30:08.341:633) : arch=x86_64 syscall=rename success=yes exit=0 a0=0x7f251f5bb332 a1=0x7f251f5bb2bc a2=0x7f25213a57b8 a3=0x0 items=5 ppid=1710 pid=30271 auid=student uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=15 comm=passwd exe=/usr/bin/passwd subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=shadow_watch

This is audit event 633. Its SYSCALL record indicates that a rename(2) syscall was successfully executed at 14:30:08 on July 20, 2018. It was executed by user root, who originally logged in as user student, by running the /usr/bin/passwd executable on the pts/0 terminal. The PID reported for the process by this record matches the PID of the process that caused the audit event in the previous step of this exercise, so both events were probably caused by the same executing program.

The PROCTITLE record indicates that this was done as part of a passwd student command.

The PATH records indicate that the old /etc/shadow file using inode 288181 was deleted (item 3). Likewise, inode 33578439 was renamed from /etc/nshadow to /etc/shadow (items 2 and 4).

That is the normal way passwd operates. It creates a temporary /etc/nshadow file containing the changes and then copies it over the old shadow password file.

This is the event that changed the /etc/shadow file.

Log out from the servera system completely.

[root@servera ~]# logout
[student@servera ~]$ logout
[student@workstation ~]$