Lab 05 Software Hardening - NETS1028
Lab 05 Software Hardening - NETS1028
Lab 05 Software Hardening - NETS1028
This lab is intended to give you a taste of hardening software in Linux. It is neither an exhaustive list of
recommendations or even a list of things that apply to all systems. It is simply meant to give you practice in
changing software settings and testing those changes.
Grading
This lab counts for marks. You will be creating a single PDF file to submit to Blackboard for this lab. For the
questions, include the question and your response. For the screenshots, you only need to include enough in
your screenshots to show your bash prompt, the command you ran, and the output that demonstrates what
you did or that the command works. For the roundcube web page screenshot, you only need to show the login
succeeded as there is no email in the account.
2. Before exiting your current bash session, start a second terminal window and ensure you can still use
sudo
3. Does debsums complain about your modified sudo program? How about dpkg with the verify option?
- submission question!
debsums sudo | grep /usr/bin/sudo
sudo dpkg --verify sudo
4. Use the list option of dpkg-statoverride to view all programs with overrides on your system -
screenshot!
dpkg-statoverride --list
Apparmor
1. Run aa-status to see what the current state of apparmor is on your VM
sudo aa-status
2. Try the aa-unconfined utility to see what processes are running that have tcp or udp ports and their
apparmor status
sudo aa-unconfined
3. Review the list of profiles contained in the Ubuntu 20.04 apparmor-profiles package
4. Are there profiles in that package for the /etc/apparmor.d directory which would confine software that
is running unconfined on your system now? - submission question!
5. Try using the –paranoid option for aa-unconfined to see if there are processes which could be
confined by the apparmor-profiles package which aa-unconfined did not show without that option
sudo aa-unconfined --paranoid
6. Review the content of the apprmor profile for the tcpdump network snooping program
cat /etc/apparmor.d/usr.sbin.tcpdump
7. Using the apparmor man page, can you determine the kinds of limitations that are placed on that
program by that profile? - submission question!
sudo configuration
Digital Ocena’s tips page for sudo privileges is a helpful helpful resource when looking for how to edit sudo
permissions.
1. Modify your sudo executable to be accessible for execution by any user, so that we can use the
sudoers file to control access instead
sudo dpkg-statoverride --update --add root sudo 4555 /usr/bin/sudo
2. Modify your /etc/sudoers file to limit the dennis account so that they can only use root sudo to edit
their own domain zone file (/etc/bind/db.simpson22725.mytld) and reload named using
the rndc reload command
visudo
3. In a second ssh session, login as user dennis (password is dennis) and verify that user dennis can
use sudo to edit their zone file and to run rndc reload but cannot use sudo to run another
command like bash
dennis$ sudo vi /etc/bind/db.simpson22725.mytld
dennis$ sudo rndc reload
dennis$ sudo bash
BIND improvements
1. Following the information given in Chapter 6 of the Bind9 Administrator’s Reference Manual
(ARM), secure your bind service by:
• adding the bogusnets acl as shown in the ARM (in /etc/bind/named.conf.options)
• setting up the allow-query, allow-recursion, and blackhole directives as shown in the ARM (in
/etc/bind/named.conf.options)
• allowing queries from anywhere for the zones being served by the server (in named.conf.local)
2. Verify your DNS service reloads the new configuration properly - screenshot!
sudo rndc reload
3. Verify your own DNS lookups still work and show the content of your named.conf files that were
changed - screenshot!
nslookup www.simpson22725.mytld
cat /etc/bind/named.conf.local /etc/bind/named.conf.options
4. In a terminal or powershell window on your host laptop/computer, run nslookup
www.simpson22725.mytld ip-of-your-vm to verify your domain service is still available
to non-local clients - screenshot!
Known vulnerabilities
1. Is your VM susceptible to the bash shell shock vulnerability? Show what you did to check. -
submission question!
2. Is your VM susceptible to the heartbleed vulnerability? Show what you did to check. - submission
question!