Unit 8 Lab - Configuration Drift and Remediation
Info
If you are unable to finish the lab in the ProLUG lab environment we ask you reboot the machine from the command line so that other students will have the intended environment.
Required Materials
- Putty or other connection tool Lab Server
- Root or sudo command access
- STIG Viewer 2.18 (download from https://public.cyber.mil/stigs/downloads/ )
Downloads
The lab has been provided below. The document(s) can be transposed to
the desired format so long as the content is preserved. For example, the .txt
could be transposed to a .md file.
Lab 🧪
These labs focus on configuration drift tracking and remediation.
Operational Activities
-
Check your stig viewer and go to RHEL 9 stigs.
-
Set a filter for “change management”.
- How many STIGs do you see?
-
Review the wording, what is meant by a robust change management process?
- Do you think this can be applied in just one STIG? Why or why not?
- What type of control is being implemented with change management in these STIGS?
- Is it different across the STIGs or all the same?
Monitoring configuration drift with Aide
-
Go into the sandbox lab: https://killercoda.com/playgrounds/scenario/ubuntu
-
Install aide and watch the installation happen.
- What is being put in the path
/etc/aide/aide.conf.d/?- How many files are in there?
- What is being put in the path
-
Check your version of aide
-
Read the man page (first page).
- What does aide try to do, and how does it do it?
-
What is the configuration of cron found in
/etc/cron.daily/dailyaidecheck?- What does this attempt to do?
- What checks are there before execution?
- Read the man for
capsh, what is it used for?
-
Set up aide according to the default configuration
-
Set the database up properly
-
Test aide by making files in a tracked directory
Using Ansible to fix drift
-
Complete the lab here: https://killercoda.com/het-tanis/course/Ansible-Labs/16-Ansible-Web-Server-Env-Deploy
-
When you finish ensure that you see broken output for 8081, as required.
-
One of the dev teams figured out they could modify the
testandqaenvironments because a previous engineer left them in the sudoers file. You can address that separately with the security team, but for now you need to get those environments back to working. Run your original deployment command to see if it sets mhe environment back properly.
-
Did this force the system back into a working configuration?
- If it worked, would it always work, or would they (the systems) need to be manually intervened?
- What is your test? (hint:
curlthe ports8080,8081, and8082from previous commands)
- Could this cause potential problems in the environment?
- If so, is that problem based on technology or operational practices? Why?
Digging Deeper challenge (not required for finishing lab)
- Complete this lab: https://killercoda.com/het-tanis/course/Ansible-Labs/19-Ansible-csv-report
- Can you think about how you’d use this to verify that a system was stamped
according to your build process?
- You may have to tie it in with something like this lab and add some variables to your custom facts files, maybe the date of deployment: https://killercoda.com/het-tanis/course/Ansible-Labs/12-Ansible-System-Facts-Grouping
- Can you think about how you’d use this to verify that a system was stamped
according to your build process?
Info
Be sure to reboot the lab machine from the command line when you are done.


