Difference between revisions of "SEC520/labs/Lab 7"
Line 2: | Line 2: | ||
<h2> <span class="mw-headline">Introduction</span></h2> | <h2> <span class="mw-headline">Introduction</span></h2> | ||
<dl><dd><ul><li>In the previous lab, we learned how to make our | <dl><dd><ul><li>In the previous lab, we learned how to make our | ||
− | Linux server less vulnerable by setting a grub password, preventing unneccessary services from running, tunnelling with SSH, and using PAM modules for setting authentication rules when running user applications. Although this is useful, vulnerability can exist when running the few essential services. | + | Linux server less vulnerable by setting a grub password, preventing unneccessary services from running, tunnelling with SSH, and using PAM modules for setting authentication rules when running user applications. Although this is useful, vulnerability can exist when running the few essential services. |
</li></ul> | </li></ul> | ||
</dd></dl> | </dd></dl> | ||
<dl><dd><ul><li>In this lab, students will be learning about | <dl><dd><ul><li>In this lab, students will be learning about | ||
− | "Authorization" within the <b>AAA</b> Protocol, to limit the resources or | + | "Authorization" within the <b>AAA</b> Protocol, to limit the resources or |
− | applications that the system users are permitted to access. First, | + | applications that the system users are permitted to access. First, |
− | students will use <b>ACLs</b> (Access Control Lists) to further define | + | students will use <b>ACLs</b> (Access Control Lists) to further define |
− | authorization to groups of users within the organization. | + | authorization to groups of users within the organization. |
</li></ul> | </li></ul> | ||
</dd></dl> | </dd></dl> | ||
<dl><dd><ul><li>Students will then learn how to install, configure and | <dl><dd><ul><li>Students will then learn how to install, configure and | ||
− | run <b>SELinux</b> which provides limitations of which users are <u>entitled</u> to | + | run <b>SELinux</b> which provides limitations of which users are <u>entitled</u> to |
− | run processes within the server. Students will then learn how to limit | + | run processes within the server. Students will then learn how to limit |
− | <u>regular</u> or "elevated" user access to regular programs or utilities (administrative) by editing the <b>Sudoer's file</b>. | + | <u>regular</u> or "elevated" user access to regular programs or utilities (administrative) by editing the <b>Sudoer's file</b>. |
</li></ul> | </li></ul> | ||
</dd></dl> | </dd></dl> | ||
Line 24: | Line 24: | ||
<h2> <span class="mw-headline">Objectives</span></h2> | <h2> <span class="mw-headline">Objectives</span></h2> | ||
<ol><li>Limit user access to files within defined groups using <b>Access Control Lists</b>. | <ol><li>Limit user access to files within defined groups using <b>Access Control Lists</b>. | ||
− | </li><li>Install, configure, and run <b>SELinux</b> which is used to enforce <u>entitled</u> users access to running processes. | + | </li><li>Install, configure, and run <b>SELinux</b> which is used to enforce <u>entitled</u> users access to running processes. |
− | </li><li>Configure the <b>sudoer's file</b> in order to allow other users access to linux commands that are only considered for administrators. | + | </li><li>Configure the <b>sudoer's file</b> in order to allow other users access to linux commands that are only considered for administrators. |
− | </li><li>Control which user(s) can run <b>cron jobs</b> in order to run commands or programs on a scheduled basis. | + | </li><li>Control which user(s) can run <b>cron jobs</b> in order to run commands or programs on a scheduled basis. |
</li></ol> | </li></ol> | ||
<p><br> | <p><br> | ||
Line 32: | Line 32: | ||
<h2> <span class="mw-headline">Required Materials (Bring to All Labs)</span></h2> | <h2> <span class="mw-headline">Required Materials (Bring to All Labs)</span></h2> | ||
<ul> | <ul> | ||
− | <li> <b>SATA Hard Disk</b> (in removable disk tray). | + | <li> <b>SATA Hard Disk</b> (in removable disk tray). |
− | </li><li> <b>Lab Logbook (Lab5 Reference Sheet)</b> (to make notes and observations). | + | </li><li> <b>Lab Logbook (Lab5 Reference Sheet)</b> (to make notes and observations). |
− | </li></ul> | + | </li></ul> |
− | <p><br> | + | <p><br> |
− | </p> | + | </p> |
− | <h2> <span class="mw-headline">Prerequisites</span></h2> | + | <h2> <span class="mw-headline">Prerequisites</span></h2> |
− | <ul><li> [https://wiki.cdot.senecacollege.ca/wiki/SEC520/labs/Lab_6 SEC520 Lab 6] | + | <ul><li> [https://wiki.cdot.senecacollege.ca/wiki/SEC520/labs/Lab_6 SEC520 Lab 6] |
− | </li></ul> | + | </li></ul> |
− | <p><br> | + | <p><br> |
− | </p> | + | </p> |
− | <h2> <span class="mw-headline">Online Tools and References</span></h2> | + | <h2> <span class="mw-headline">Online Tools and References</span></h2> |
+ | |||
+ | <ul> | ||
+ | <li>[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL ACLs]</li>[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL | ||
+ | ]<li>[http://hackinglinux.blogspot.ca/2007/05/selinux-tutorial.html SELinux]</li> | ||
+ | <!--DEAD LINK<li>[http://www.syntaxtechnology.com/2009/06/sudo-tutorial/ Sudo]</li>--> | ||
+ | <li>[http://cs.senecac.on.ca/%7Efac/ops435/2008_dev/ops435_w11_l1.pdf Cron Jobs]</li> | ||
+ | </ul> | ||
+ | |||
+ | <p><br> | ||
+ | </p> | ||
+ | <h2> <span class="mw-headline">Course Notes</span></h2> | ||
+ | <ul> | ||
+ | <li>[http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.odp odp] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.pdf pdf] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.ppt ppt] (Slides: Linux System Hardening - part 2)</li> | ||
+ | <!--DEAD LINK<li>[http://lcweb.senecac.on.ca:2063/0596003919 Linux Security Cookbook (E-book)] (Chapter 5)</li>--> | ||
+ | <!--DEAD LINK<li>[http://lcweb.senecac.on.ca:2063/0131963694?uicode=seneca Linux By Example (E-book)] (Chapter x)</li>--> | ||
+ | </ul> | ||
+ | |||
+ | <p><br> | ||
+ | </p> | ||
+ | <h1> <span class="mw-headline">Performing Lab 7</span></h1> | ||
+ | <h2> <span class="mw-headline">Task #1: ACLs</span></h2> | ||
+ | <br> | ||
+ | In this section, students will learn how to use <b>ACLs</b> (Access Control Lists) to "finely-tune" group access to directories and files, and differentiate between setting permissions via ACL and setting permissions using the chmod command. | ||
+ | <br><br> | ||
+ | |||
+ | INSTRUCTIONS: | ||
+ | <br> | ||
+ | |||
+ | <ol> | ||
+ | <li>Boot-up your Kali Linux (host) and your <b>Hardened Linux VM</b> on your hard disk pack.</li> | ||
+ | <li>Log into your user account that has administrative priviledges (this should have been performed during installation process in lab4).</li> | ||
+ | <li>Open a shell terminal, and create the following directory: <b>~/share</b></li> | ||
+ | <li>Set passthrough permissions for your home directory, and set permissions to allow same group members access and view the contents of the <b>share</b> directory. Use the <b>ls -ld</b> command to confirm the set permissions for these directories.</li> | ||
+ | <li>Use the <b>groupadd</b> command to create a new group name called <b>project</b> </li> | ||
+ | <li>Use the <b>usermod</b> command to add the three users (created in lab4) to the group called <b>project</b>. View the contents of the <b>/etc/group</b> file to confirm that the users have been added to the <i>project</i> group.</li> | ||
+ | <li>Use the touch command to create an empty file in the share directory called <b>~/share/project.txt</b> </li> | ||
+ | <li>Use the <b>chgrp</b> command to have the file <b>project.txt</b> belong to the <b>project</b> group. Use the <b>ls -l</b> command to confirm that the <i>project.txt</i> file now belongs to the <i>project</i> group.</li> | ||
+ | <li>Set permissions for same group members to <u>view</u> and <u>modify</u> contents of the file <b>~/share/project.txt</b> and confirm that the permissions have been correctly set for that file.</li> | ||
+ | <li>Switch (i.e. su) to one of the users (added to the <i>project</i> group), and confirm that they can access and modify the file: <b>~/share/project.txt</b></li> | ||
+ | <li>Repeat the above step for the second user (belonging to the <i>project</i> group).</li> | ||
+ | <li>Why can you allow the first user to both <u>read</u> and <u>modify</u> the project.txt file, but you can't only allow the second user to only read the project.txt file without editing permissions? Answer in your lab log-book.</li> | ||
+ | |||
+ | |||
+ | <br> | ||
+ | {{Admon/important|ACL Package|An <b>ACL</b> or <b>Access Control List</b> is a system that sets permissions to specific objects, as oppposed to general directories and files. This allows more flexibility when granting read, read & write permissions for different users for the same file or directory.<br /><br />|}} | ||
+ | <br> | ||
+ | |||
+ | <li value="13">Switch (su) back to your administration account.</li> | ||
+ | <li>Issue the following command: <b>rpm -qi acl</b> to confirm that the <b>acl</b> application has been installed in your system. If it is not present, make certain to install that application.</li> | ||
+ | <li>In order to use <b>ACLs</b>, you need to edit the <b>/etc/fstab</b> file to mount all disk filesystems with the <b>acl option</b><br />(Refer to the following link for an example: [http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL Mounting With ACL Option]).</li> | ||
+ | <li>Issue the command: <b>mount -o remount /</b> <br />in order to remount your file system (as opposed to rebooting).</li> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
<br> | <br> | ||
+ | {{Admon/important|Missing acl option in listed Mounts|Usually, it is a good idea to confirm that the <b>acl</b> option is present from the remount by viewing either the <b>/etc/fstab</b> or <b>/etc/mtab</b> files. If you are using Fedora17, it may not appear, although it is active. This may be attributed to a bug...<br /><br />|}} | ||
+ | <br /> | ||
− | + | <li value="17">View the Youtube video (or other online resources) on how to use ACLs: [http://www.youtube.com/watch?v=6piQXXHTmqk Video]</li> | |
− | + | <li>Set same group members for group name <b>project</b> to only <u>view</u> the contents of the file <b>~/share/project.txt</b></li> | |
− | + | <li>Use the <b>setfacl</b> command to allow only <u>one</u> of the users to both <u>view</u> and <u>modify</u> the file <b>~/share/project.txt</b><br /><br >For example, if the username is <b>user1</b>, then issue the command:<br /><br /><b>setfacl -m u:user1:rw share/project.txt</b><br /><br /></li> | |
− | + | <li>Use the <b>getfacl</b> to confirm the permissions for the file: <b>~/share/project.txt</b></li> | |
− | + | <li>Switch (su) to your account that you used the <b>setfacl</b> command to provide read/write permissions. Can you make editing changes to <i>project.txt</i>?</li> | |
− | + | <li>Now switch (su) to another account. Can you make editing changes to <i>project.txt</i>? Why?.</li> | |
− | + | <li>Record your results in your lab log-book.</li> | |
− | + | <li>Proceed to Task #2</li> | |
− | |||
− | |||
− | |||
− | |||
− | |||
</ol> | </ol> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
<p><b>Answer the Task #1 observations / questions in your lab log book.</b> | <p><b>Answer the Task #1 observations / questions in your lab log book.</b> | ||
</p> | </p> | ||
Line 114: | Line 114: | ||
<p><br><br/> | <p><br><br/> | ||
− | + | ||
− | INSTRUCTIONS: | + | INSTRUCTIONS: |
− | {{Admon/important|SELinux Package|Confirm that the <b>SELinux</b> package is installed on your Linux VM.|}} | + | {{Admon/important|SELinux Package|Confirm that the <b>SELinux</b> package is installed on your Linux VM.|}} |
− | <br /> | + | <br /> |
− | </p><ol> | + | </p><ol> |
− | + | <li>Familiarize yourself with the system-config-securitylevel tool | |
− | (SELinux tab) and these SELinux commands (and SELinux-modified | + | (SELinux tab) and these SELinux commands (and SELinux-modified |
− | commands):<ul style="font-family:courier,monospace;"><li>getenforce, setenforce</li><li>getsebool, setsebool</li><li>chcon</li><li>restorecon</li><li>ls -Z, ps -Z, id</li><li>gnome-system-monitor</li><li>system-config-securitylevel<br><br></li></ul></li> | + | commands):<ul style="font-family:courier,monospace;"><li>getenforce, setenforce</li><li>getsebool, setsebool</li><li>chcon</li><li>restorecon</li><li>ls -Z, ps -Z, id</li><li>gnome-system-monitor</li><li>system-config-securitylevel<br><br></li></ul></li> |
− | + | <li>Ensure that your SELinux system is in <b>enforcing</b> mode.</li> | |
− | + | <li>Configure Apache to permit the use of <b>$HOME/public_html</b> directories by editing the <b>httpd.conf</b> file:<ul><li>Comment out the <b>UserDir Disable</b> directive.</li><li>Uncomment the <b>UserDir public_html</b> directive.</li><li>Uncomment the directory container for <b>/home/*/public_html</b> and configure it permit the execution of CGI scripts.</li><li>Uncomment the directive <b>add_handler cgi-script .cgi</b><br><br></li></ul></li> | |
− | + | <li>Restart Apache. Do not use apachectl -- use the <b>service</b> command.</li> | |
− | + | <li>Create <b>~/public_html/index.html</b></li> | |
− | + | <li>Attempt to access the content you created in step 5 using a browser. It should fail.</li> | |
− | + | <li>Review the latest avc messages in <b>/var/log/messages</b> and compare | |
− | them to the Apache error log. Record your finding in your lab log-book.</li> | + | them to the Apache error log. Record your finding in your lab log-book.</li> |
− | + | <li>Put SELinux in <b>Permissive</b> mode.</li> | |
− | + | <li>Attempt to access the content you created in step 5 using a | |
− | browser. It should succeed. (If not, your <b>httpd.conf</b> file or permissions | + | browser. It should succeed. (If not, your <b>httpd.conf</b> file or permissions |
− | + | are incorrect - fix them).</li> | |
− | + | <li>Put SELinux back into <b>Enforcing</b> mode.</li> | |
− | + | <li>Using the man page for <b>httpd_selinux</b>, determine what is required to | |
− | + | make <b>~/public_html/index.html</b> accessible while SELinux is in Enforcing | |
− | mode. Test it and make sure it works.</li> | + | mode. Test it and make sure it works.</li> |
− | + | <li>Create the following Bash shell script (called <b>test.bash</b>):<br><pre style="font-family:courier,monosplace;"> #!/bin/bash | |
− | + | echo "Content-type: text/plain" | |
− | + | echo | |
− | + | cal -y</pre></li> | |
− | + | <li>Test your script through a web browser.</li> | |
− | + | <li>Create the following testing CGI script (called <b>test.cgi</b>):<br><pre style="font-family:courier,monosplace;"> #!/bin/bash | |
− | + | echo "Content-type: text/plain" | |
− | + | echo | |
− | + | echo "Attempting to show the contents of ~/.bash_profile:" | |
− | + | cat ~/.bash_profile | |
− | + | if [ $? -eq 0 ] | |
− | + | then | |
− | + | echo "Success." | |
− | + | else | |
− | + | echo "Failure." | |
− | + | fi</pre></li> | |
− | + | <li>Run this script via the web browser in both <b>Permissive</b> and | |
− | <b>Enforcing</b> modes. Observe the difference in output. What is the reason | + | <b>Enforcing</b> modes. Observe the difference in output. What is the reason |
− | for the difference?</li> | + | for the difference?</li> |
− | + | <li>Record your findings in your lab log-book.</li> | |
− | <li>Proceed to Task #3</li> | + | <li>Proceed to Task #3</li> |
− | + | </ol> | |
<p><b>Answer Task #2 observations / questions in your lab log book.</b> | <p><b>Answer Task #2 observations / questions in your lab log book.</b> | ||
− | </p><p><br> | + | </p><p><br> |
</p> | </p> | ||
Line 167: | Line 167: | ||
<h2> <span class="mw-headline">Task #3: Sudo</span></h2> | <h2> <span class="mw-headline">Task #3: Sudo</span></h2> | ||
<br> | <br> | ||
− | <i>"Sudo (switchuser/superuser do) allows a system administrator to give | + | <i>"Sudo (switchuser/superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell."</i> |
− | certain users (or groups of users) the ability to run some (or all) | ||
− | commands as root while logging all commands and arguments. Sudo operates | ||
− | |||
<br><br> | <br><br> | ||
INSTRUCTIONS: | INSTRUCTIONS: | ||
<ol> | <ol> | ||
− | + | <li>READ the man page on <b>sudo</b> and <b>visudo</b>. Most modern versions of Linux have sudo default installed.</li> | |
− | + | <li>Open sudoers using <b>visudo</b>.</li> | |
− | + | <li>We will be <b>setting up logging information</b> as well as allowing the <b>third user to issue certain administrative commands</b>. With the setup below, this lab is making reference to username: <b>user3</b> (replace this with the actual username of the third user). Make the following changes to the <b>sudoer's file</b>, adding information that appears in <b>bold</b>:<br><br><pre style="font-family:courier,monospace;"># sudoers file. | |
− | # | + | # |
− | # This file MUST be edited with the 'visudo' command as root. | + | # This file MUST be edited with the 'visudo' command as root. |
− | # | + | # |
− | # See the sudoers man page for the details on how to write a sudoers file. | + | # See the sudoers man page for the details on how to write a sudoers file. |
− | # | + | # |
− | + | ||
− | # Host alias specification | + | # Host alias specification |
− | Host_Alias MYHOST=localhost | + | Host_Alias MYHOST=localhost |
− | # User alias specification | + | # User alias specification |
− | + | ||
− | <b>User_Alias USER3=user3 | + | <b>User_Alias USER3=user3 |
− | # Cmnd alias specification | + | # Cmnd alias specification |
− | Cmnd_Alias NETWORK=/sbin/ifconfig</b> | + | Cmnd_Alias NETWORK=/sbin/ifconfig</b> |
− | + | ||
− | Note: you NEED the ABSOLUTE path to the command you put in there. | + | Note: you NEED the ABSOLUTE path to the command you put in there. |
− | + | ||
− | # User privilege specification | + | # User privilege specification |
− | root ALL=(ALL) ALL | + | root ALL=(ALL) ALL |
− | <b>user3 ALL=NETWORK</b> | + | <b>user3 ALL=NETWORK</b> |
+ | |||
+ | # Defaults Specification | ||
+ | <b>Defaults syslog=local1</b> | ||
+ | |||
+ | </pre></li> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
<br> | <br> | ||
{{Admon/caution|Watch Syntax in Sudoers File|The sudoers file should | {{Admon/caution|Watch Syntax in Sudoers File|The sudoers file should | ||
Line 209: | Line 206: | ||
file|}} | file|}} | ||
<br> | <br> | ||
− | + | ||
− | + | <li value="4">Save and exit the visudo editing session. Check and return to editing session if any errors are created.</li> | |
− | + | <li>Edit the file <b>/etc/rsyslog.conf</b> and add the following line to the bottom of this file (for logging purposes):<br /><br /><pre style="font-family:courier,monospace;"> | |
− | local1.* /var/adm/sudo.log</pre><br /></li> | + | local1.* /var/adm/sudo.log</pre><br /></li> |
− | + | <li>Save your editing changes.</li> | |
− | + | <li>Switch (su) as the third user (eg. in our demonstration: <b>user3</b>).</li> | |
− | + | <li>Experiment with the sudo capabilities assigned to the third user by issuing the command: <b>sudo /sbin/ifconfig eth0</b> (You'll have to supply the user password). For the purpose of this lab, the command does not have to work - don't worry about error messages.</li> | |
− | + | <li>Return to the administrator account.</li> | |
− | + | <li>Check the <b>/var/adm/sudo.log</b> file. What does it show ?</li> | |
− | + | ||
<br> | <br> | ||
− | {{Admon/caution|No Entries in /var/adm/sudo.log File|If you do not see any entries in the < | + | {{Admon/caution|No Entries in /var/adm/sudo.log File|If you do not see any entries in the <b>/var/adm/sudo.log</b> file, then shutdown, and then restart your Hardened Linux VM, and <u>repeat</u> <b>steps 7 to 10</b>. |
|}} | |}} | ||
<br> | <br> | ||
− | + | ||
− | + | <li value="11">Switch (su) to a different user (other than your third user), and try to issue the <b>sudo /sbin/ifconfig eth0</b> command. What happenned?</li> | |
− | + | <li>Switch (su) to the administrator's account, and view the contents of <b>/var/adm/sudo.log</b>. What do you notice?</li> | |
− | + | <li>Edit the sudoers file and add the following line (where hostname is your VM machine):<pre style="font-family:courier,monospace;">USER3 localhost.localdomain= NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm | |
− | </pre> | + | </pre> |
− | <br> | + | <br> |
− | + | </li><li>While in edit mode, add <b>USER1</b> as an alias for user1, and add the <b>kill</b> command to the <b>Cmnd_Aliases</b> line for <b>user1</b>. Each line should appear similar to this:<pre style="font-family:courier,monospace;"> | |
− | User_Alias USER1=user1 | + | User_Alias USER1=user1 |
− | USER1 localhost.localdomain= PASSWD: /bin/kill</pre></li> | + | USER1 localhost.localdomain= PASSWD: /bin/kill</pre></li> |
− | + | <li>Save changes to the sudoer's file and exit.</li> | |
− | + | <li>Switch (su) as the third user and attempt to kill a process. Where you prompted to enter a password? Then switch (su) as the first user (eg. <b>user1</b>) and attempt to kill another process. Where you prompted to enter a password? </li> | |
− | + | <li>Switch (su) to the third user, and execute the following command: <b>sudo -l</b>. What did this command do?</li> | |
− | |||
<br> | <br> | ||
{{Admon/important|Vulnerability with Sudo (vi)|There is no easy way to prevent a user from gaining a root shell if that user has access to commands allowing shell escapes. If users have sudo <b>ALL</b>, there is nothing to prevent them from creating their own program that gives them a root shell regardless of any '!' | {{Admon/important|Vulnerability with Sudo (vi)|There is no easy way to prevent a user from gaining a root shell if that user has access to commands allowing shell escapes. If users have sudo <b>ALL</b>, there is nothing to prevent them from creating their own program that gives them a root shell regardless of any '!' | ||
elements in the user specification. | elements in the user specification. | ||
<br><br> | <br><br> | ||
− | Running shell scripts via sudo can expose the same kernel bugs that make | + | Running shell scripts via sudo can expose the same kernel bugs that make setuid shell scripts unsafe on some operating systems (if your OS supports the <b>/dev/fd</b> directory, setuid shell scripts are generally safe). |
− | |||
− | supports the <b>/dev/fd</b> directory, setuid shell scripts are generally | ||
− | safe). | ||
<br><br> | <br><br> | ||
(From sudo man page)|}} | (From sudo man page)|}} | ||
<br> | <br> | ||
− | + | <li value="18">Grant <b>vi</b> privileges to the third user. Switch (su) as the third user and issue the command: <b>sudo vi</b>. Press : to go to the <b>last line mode</b> in your vi text editor, and issue the command:<br><br> | |
− | + | <b>!id</b><br><br></li> | |
− | + | <li>What was the id of the third user and what what sort of implications does this create in terms of system security?</li> | |
− | <b>!id</b><br><br></li> | + | <li>Record your findings in your lab log-book.</li> |
− | + | <li>Proceed to Task #4.</li> | |
− | |||
− | |||
</ol> | </ol> | ||
<p><b>Answer Task #3 observations / questions in your lab log book.</b> | <p><b>Answer Task #3 observations / questions in your lab log book.</b> | ||
− | </p><p><br> | + | </p><p><br> |
</p> | </p> | ||
Line 271: | Line 262: | ||
INSTRUCTIONS: | INSTRUCTIONS: | ||
<ol> | <ol> | ||
− | + | <li>Switch to the super-user, and issue the following command: <br /><b>crontab -u user1 -e</b><br /></li> | |
− | + | <li>Add the following contents into the first user's <b>crontab</b> file:<br><br><pre style="font-family:courier,monospace;"> * * * * * 'uptime >> ~/uptime.txt' | |
− | + | </pre></li> | |
− | + | <li>Save and exit your crontab editing session.</li> | |
− | + | <li>Edit the <b>/etc/crontab.allow</b> file to include the first user. If the file does not exist, simply create it, or check with the Linux distribution for instructions to use the crontab.allow file.</li> | |
− | + | <li>Login to the first user and see if your cron job is working.</li> | |
− | + | <li>Login to the second user (created in lab4) to see if that account can create a cron job. Where you successful? Why?</li> | |
− | + | <li>Try to list at least 3 types of Bash Shell scripts that a Linux system administrator can limit to specific users. Record your findings in your lab log-book.</li> | |
− | + | <li>Perform another software update (either graphically or using the <b>yum</b> or <b>apt-get</b> commands). Verify that the software upgrades are up-to-date.</li> | |
− | + | <li>Switch your Linux server from graphical mode (eg run level 5) to default mode (eg run level 3). <b>Note:</b> The procedure has changed in newer Linux system (using <b>sysd</b>). Refer to the following link to learn how to set your Fedora17 system to text-based mode: [http://zenit.senecac.on.ca/wiki/index.php/Init_vs_systemd Init vs Systemd]</li> | |
− | + | <li>Perform a scan from your Kali Linux (host) machine to hopefully see a more hardened system with less running services.</li> | |
− | + | <li>Proceed to "Completing The Lab".</li> | |
</ol> | </ol> | ||
<p><b>Answer Task #4 observations / questions in your lab log book.</b> | <p><b>Answer Task #4 observations / questions in your lab log book.</b> | ||
− | </p><p><br> | + | </p><p><br> |
</p> | </p> | ||
Line 294: | Line 285: | ||
</p> | </p> | ||
<ol> | <ol> | ||
− | + | <li>Compare ACLs by demonstrating running services via <b>user1</b> and <b>user2</b>.</li> | |
− | + | <li>Verify SELinux is running in <b>Enforcing</b> mode.</li> | |
− | + | <li>Display contents of <b>sudoer's file (for user1)</b>.</li> | |
− | + | <li>Verification of running <b>crob job</b>.</li> | |
− | + | <li>Linux system in <b>text-based mode</b> (i.e. run level 3 for your <b>Hardened Linux</b> system).</li> | |
− | + | <li>Completed Lab 7 notes.</li> | |
</ol> | </ol> | ||
<p><br> | <p><br> | ||
Line 306: | Line 297: | ||
<ol> | <ol> | ||
− | + | <li>What does the term <b>ACL</b> stand for?</li> | |
− | + | <li>Compare and contrast the features of ACLs for Windows (using NTFS) and Linux.</li> | |
− | + | <li>What is the purpose of <b>ACLs</b>?</li> | |
− | + | <li>What is the purpose of <b>SELinux</b>.</li> | |
− | + | <li>List the various modes of <b>SELinux</b>.</li> | |
− | + | <li>Briefly list the steps to allow the regular user called <b>msaul</b> to run administrative commands.</li> | |
− | + | <li>Briefly explain how to setup the sudoer's file to have the user <b>ctyler</b> only run the administrative command: <b>visudo</b></li> | |
− | + | <li>Briefly list the steps to allow <b>user1</b> to run a <b>cron job</b> called <b>cleanup.bash</b></li> | |
− | + | <li>Write a Linux command to perform a software update.</li> | |
− | + | <li>Write a Linux command to set the Linux server to text-based mode.</li> | |
− | + | <li>Why is it recommended to run a Linux server in text-based mode?</li> | |
</ol> | </ol> |
Revision as of 10:08, 1 February 2018
Contents
Linux System Hardening (part 2)
Introduction
- In the previous lab, we learned how to make our Linux server less vulnerable by setting a grub password, preventing unneccessary services from running, tunnelling with SSH, and using PAM modules for setting authentication rules when running user applications. Although this is useful, vulnerability can exist when running the few essential services.
- In this lab, students will be learning about "Authorization" within the AAA Protocol, to limit the resources or applications that the system users are permitted to access. First, students will use ACLs (Access Control Lists) to further define authorization to groups of users within the organization.
- Students will then learn how to install, configure and run SELinux which provides limitations of which users are entitled to run processes within the server. Students will then learn how to limit regular or "elevated" user access to regular programs or utilities (administrative) by editing the Sudoer's file.
- Finally, students will complete the "lock down" of the computer system by learning how to limit the running of scheduled processes (cron jobs), perform software upgrades, and to turn-off X-windows on a Linux server.
Objectives
- Limit user access to files within defined groups using Access Control Lists.
- Install, configure, and run SELinux which is used to enforce entitled users access to running processes.
- Configure the sudoer's file in order to allow other users access to linux commands that are only considered for administrators.
- Control which user(s) can run cron jobs in order to run commands or programs on a scheduled basis.
Required Materials (Bring to All Labs)
- SATA Hard Disk (in removable disk tray).
- Lab Logbook (Lab5 Reference Sheet) (to make notes and observations).
Prerequisites
Online Tools and References
Course Notes
Performing Lab 7
Task #1: ACLs
In this section, students will learn how to use ACLs (Access Control Lists) to "finely-tune" group access to directories and files, and differentiate between setting permissions via ACL and setting permissions using the chmod command.
INSTRUCTIONS:
- Boot-up your Kali Linux (host) and your Hardened Linux VM on your hard disk pack.
- Log into your user account that has administrative priviledges (this should have been performed during installation process in lab4).
- Open a shell terminal, and create the following directory: ~/share
- Set passthrough permissions for your home directory, and set permissions to allow same group members access and view the contents of the share directory. Use the ls -ld command to confirm the set permissions for these directories.
- Use the groupadd command to create a new group name called project
- Use the usermod command to add the three users (created in lab4) to the group called project. View the contents of the /etc/group file to confirm that the users have been added to the project group.
- Use the touch command to create an empty file in the share directory called ~/share/project.txt
- Use the chgrp command to have the file project.txt belong to the project group. Use the ls -l command to confirm that the project.txt file now belongs to the project group.
- Set permissions for same group members to view and modify contents of the file ~/share/project.txt and confirm that the permissions have been correctly set for that file.
- Switch (i.e. su) to one of the users (added to the project group), and confirm that they can access and modify the file: ~/share/project.txt
- Repeat the above step for the second user (belonging to the project group).
- Why can you allow the first user to both read and modify the project.txt file, but you can't only allow the second user to only read the project.txt file without editing permissions? Answer in your lab log-book.
- Switch (su) back to your administration account.
- Issue the following command: rpm -qi acl to confirm that the acl application has been installed in your system. If it is not present, make certain to install that application.
- In order to use ACLs, you need to edit the /etc/fstab file to mount all disk filesystems with the acl option
(Refer to the following link for an example: Mounting With ACL Option). - Issue the command: mount -o remount /
in order to remount your file system (as opposed to rebooting). - View the Youtube video (or other online resources) on how to use ACLs: Video
- Set same group members for group name project to only view the contents of the file ~/share/project.txt
- Use the setfacl command to allow only one of the users to both view and modify the file ~/share/project.txt
For example, if the username is user1, then issue the command:
setfacl -m u:user1:rw share/project.txt - Use the getfacl to confirm the permissions for the file: ~/share/project.txt
- Switch (su) to your account that you used the setfacl command to provide read/write permissions. Can you make editing changes to project.txt?
- Now switch (su) to another account. Can you make editing changes to project.txt? Why?.
- Record your results in your lab log-book.
- Proceed to Task #2
Answer the Task #1 observations / questions in your lab log book.
Task #2: SELinux
INSTRUCTIONS:
- Familiarize yourself with the system-config-securitylevel tool
(SELinux tab) and these SELinux commands (and SELinux-modified
commands):
- getenforce, setenforce
- getsebool, setsebool
- chcon
- restorecon
- ls -Z, ps -Z, id
- gnome-system-monitor
- system-config-securitylevel
- Ensure that your SELinux system is in enforcing mode.
- Configure Apache to permit the use of $HOME/public_html directories by editing the httpd.conf file:
- Comment out the UserDir Disable directive.
- Uncomment the UserDir public_html directive.
- Uncomment the directory container for /home/*/public_html and configure it permit the execution of CGI scripts.
- Uncomment the directive add_handler cgi-script .cgi
- Restart Apache. Do not use apachectl -- use the service command.
- Create ~/public_html/index.html
- Attempt to access the content you created in step 5 using a browser. It should fail.
- Review the latest avc messages in /var/log/messages and compare them to the Apache error log. Record your finding in your lab log-book.
- Put SELinux in Permissive mode.
- Attempt to access the content you created in step 5 using a browser. It should succeed. (If not, your httpd.conf file or permissions are incorrect - fix them).
- Put SELinux back into Enforcing mode.
- Using the man page for httpd_selinux, determine what is required to make ~/public_html/index.html accessible while SELinux is in Enforcing mode. Test it and make sure it works.
- Create the following Bash shell script (called test.bash):
#!/bin/bash echo "Content-type: text/plain" echo cal -y
- Test your script through a web browser.
- Create the following testing CGI script (called test.cgi):
#!/bin/bash echo "Content-type: text/plain" echo echo "Attempting to show the contents of ~/.bash_profile:" cat ~/.bash_profile if [ $? -eq 0 ] then echo "Success." else echo "Failure." fi
- Run this script via the web browser in both Permissive and Enforcing modes. Observe the difference in output. What is the reason for the difference?
- Record your findings in your lab log-book.
- Proceed to Task #3
Answer Task #2 observations / questions in your lab log book.
Task #3: Sudo
"Sudo (switchuser/superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell."
INSTRUCTIONS:
- READ the man page on sudo and visudo. Most modern versions of Linux have sudo default installed.
- Open sudoers using visudo.
- We will be setting up logging information as well as allowing the third user to issue certain administrative commands. With the setup below, this lab is making reference to username: user3 (replace this with the actual username of the third user). Make the following changes to the sudoer's file, adding information that appears in bold:
# sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification Host_Alias MYHOST=localhost # User alias specification <b>User_Alias USER3=user3 # Cmnd alias specification Cmnd_Alias NETWORK=/sbin/ifconfig</b> Note: you NEED the ABSOLUTE path to the command you put in there. # User privilege specification root ALL=(ALL) ALL <b>user3 ALL=NETWORK</b> # Defaults Specification <b>Defaults syslog=local1</b>
- Save and exit the visudo editing session. Check and return to editing session if any errors are created.
- Edit the file /etc/rsyslog.conf and add the following line to the bottom of this file (for logging purposes):
local1.* /var/adm/sudo.log
- Save your editing changes.
- Switch (su) as the third user (eg. in our demonstration: user3).
- Experiment with the sudo capabilities assigned to the third user by issuing the command: sudo /sbin/ifconfig eth0 (You'll have to supply the user password). For the purpose of this lab, the command does not have to work - don't worry about error messages.
- Return to the administrator account.
- Check the /var/adm/sudo.log file. What does it show ?
- Switch (su) to a different user (other than your third user), and try to issue the sudo /sbin/ifconfig eth0 command. What happenned?
- Switch (su) to the administrator's account, and view the contents of /var/adm/sudo.log. What do you notice?
- Edit the sudoers file and add the following line (where hostname is your VM machine):
USER3 localhost.localdomain= NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm
- While in edit mode, add USER1 as an alias for user1, and add the kill command to the Cmnd_Aliases line for user1. Each line should appear similar to this:
User_Alias USER1=user1 USER1 localhost.localdomain= PASSWD: /bin/kill
- Save changes to the sudoer's file and exit.
- Switch (su) as the third user and attempt to kill a process. Where you prompted to enter a password? Then switch (su) as the first user (eg. user1) and attempt to kill another process. Where you prompted to enter a password?
- Switch (su) to the third user, and execute the following command: sudo -l. What did this command do?
- Grant vi privileges to the third user. Switch (su) as the third user and issue the command: sudo vi. Press : to go to the last line mode in your vi text editor, and issue the command:
!id - What was the id of the third user and what what sort of implications does this create in terms of system security?
- Record your findings in your lab log-book.
- Proceed to Task #4.
Answer Task #3 observations / questions in your lab log book.
Task #4: Cron Jobs & Turning off XWindows
This last section involves "tweaks" to harden your Linux system from less obvious vulnerabilities. First, you will learn as the adiminstrator
to limit cron jobs (i.e. scheduled tasks) that can be run by users. Finally, you will change from run level 5 (Xwindows) to level 3 (text-based) to make your system less vulnerable to attacks.
INSTRUCTIONS:
- Switch to the super-user, and issue the following command:
crontab -u user1 -e - Add the following contents into the first user's crontab file:
* * * * * 'uptime >> ~/uptime.txt'
- Save and exit your crontab editing session.
- Edit the /etc/crontab.allow file to include the first user. If the file does not exist, simply create it, or check with the Linux distribution for instructions to use the crontab.allow file.
- Login to the first user and see if your cron job is working.
- Login to the second user (created in lab4) to see if that account can create a cron job. Where you successful? Why?
- Try to list at least 3 types of Bash Shell scripts that a Linux system administrator can limit to specific users. Record your findings in your lab log-book.
- Perform another software update (either graphically or using the yum or apt-get commands). Verify that the software upgrades are up-to-date.
- Switch your Linux server from graphical mode (eg run level 5) to default mode (eg run level 3). Note: The procedure has changed in newer Linux system (using sysd). Refer to the following link to learn how to set your Fedora17 system to text-based mode: Init vs Systemd
- Perform a scan from your Kali Linux (host) machine to hopefully see a more hardened system with less running services.
- Proceed to "Completing The Lab".
Answer Task #4 observations / questions in your lab log book.
Completing the Lab
Arrange evidence for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:
- Compare ACLs by demonstrating running services via user1 and user2.
- Verify SELinux is running in Enforcing mode.
- Display contents of sudoer's file (for user1).
- Verification of running crob job.
- Linux system in text-based mode (i.e. run level 3 for your Hardened Linux system).
- Completed Lab 7 notes.
Preparing for Quizzes
- What does the term ACL stand for?
- Compare and contrast the features of ACLs for Windows (using NTFS) and Linux.
- What is the purpose of ACLs?
- What is the purpose of SELinux.
- List the various modes of SELinux.
- Briefly list the steps to allow the regular user called msaul to run administrative commands.
- Briefly explain how to setup the sudoer's file to have the user ctyler only run the administrative command: visudo
- Briefly list the steps to allow user1 to run a cron job called cleanup.bash
- Write a Linux command to perform a software update.
- Write a Linux command to set the Linux server to text-based mode.
- Why is it recommended to run a Linux server in text-based mode?