Difference between revisions of "SEC520/labs/Lab 6"

From CDOT Wiki
Jump to: navigation, search
(Created page with "<h1> <span class="mw-headline">Linux System Hardening (Part 1)</span></h1> <a name="Introduction" id="Introduction"></a><h2> <span class="mw-headline">Introduction</span></h2>...")
 
m (Protected "SEC520/labs/Lab 6": OER transfer ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
<h1> <span class="mw-headline">Linux System Hardening (Part 1)</span></h1>
 
<h1> <span class="mw-headline">Linux System Hardening (Part 1)</span></h1>
<a name="Introduction" id="Introduction"></a><h2> <span class="mw-headline">Introduction</span></h2>
+
<h2> <span class="mw-headline">Introduction</span></h2>
 
<dl><dd><ul><li>In this lab, students will learn how to make their Linux servers less vulnerable to attacks (i.e. <b>hardening</b> the Linux system). First, students will prevent users from booting into <b>run level 1 (super-user mode)</b> by creating a <b>grub boot password</b>.
 
<dl><dd><ul><li>In this lab, students will learn how to make their Linux servers less vulnerable to attacks (i.e. <b>hardening</b> the Linux system). First, students will prevent users from booting into <b>run level 1 (super-user mode)</b> by creating a <b>grub boot password</b>.
 
</li></ul>
 
</li></ul>
Line 8: Line 8:
 
</dd></dl>
 
</dd></dl>
 
<dl><dd><ul><li>Students will then <b>configure SSH</b> to  
 
<dl><dd><ul><li>Students will then <b>configure SSH</b> to  
provide a safe "tunnel" for data to prevent from hacking, and to change  
+
provide a safe "tunnel" for data to prevent from hacking, and to change  
the port number to help to confuse (discourage) hackers.
+
the port number to help to confuse (discourage) hackers.
 
</li></ul>
 
</li></ul>
 
</dd></dl>
 
</dd></dl>
 
<dl><dd><ul><li>Finally, students will use <b>PAM</b>  
 
<dl><dd><ul><li>Finally, students will use <b>PAM</b>  
(Plugable Authentication Modules) to further protect running  
+
(Plugable Authentication Modules) to further protect running  
applications in their VMs.
+
applications in their VMs.
 
</li></ul>
 
</li></ul>
 
</dd></dl>
 
</dd></dl>
 
<br><br>
 
<br><br>
<a name="Objectives" id="Objectives"></a><h2> <span class="mw-headline">Objectives</span></h2>
+
<h2> <span class="mw-headline">Objectives</span></h2>
 
<ol><li>Setup a <b>grub boot</b> password to prevent users from gaining access to super-user mode during Linux system bootup.
 
<ol><li>Setup a <b>grub boot</b> password to prevent users from gaining access to super-user mode during Linux system bootup.
</li><li><b>Close unnecessary running ports</b> (services) to make server(s) less vulnerable to attack.
+
</li><li><b>Close unnecessary running ports</b> (services) to make server(s) less vulnerable to attack.
</li><li>Use <b>SSH tunnelling</b> to protect data from being picked up by hackers.
+
</li><li>Use <b>SSH tunnelling</b> to protect data from being picked up by hackers.
</li><li>Use <b>PAM</b> to provide authentication for APIs (application programming interfaces).
+
</li><li>Use <b>PAM</b> to provide authentication for APIs (application programming interfaces).
 
</li></ol>
 
</li></ol>
 
<p><br>
 
<p><br>
 
</p>
 
</p>
<a name="Required_Materials_.28Bring_to_All_Labs.29" id="Required_Materials_.28Bring_to_All_Labs.29"></a><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 (Lab4 Reference Sheet)</b> (to make notes and observations).
+
</li><li> <b>Lab Logbook (Lab4 Reference Sheet)</b> (to make notes and observations).
</li></ul>
+
</li></ul>
<p><br>
+
<p><br>
</p>
+
</p>
<a name="Prerequisites" id="Prerequisites"></a><h2> <span class="mw-headline">Prerequisites</span></h2>
+
<h2> <span class="mw-headline">Prerequisites</span></h2>
<ul><li> <a href="https://scs.senecac.on.ca/%7Efac/sec520/labs/SEC520_Lab_5.html">SEC520 Lab 5</a>
+
<ul><li> [https://wiki.cdot.senecacollege.ca/wiki/SEC520/labs/Lab_5 SEC520 Lab 5]
</li></ul>
+
</li></ul>
<p><br>
+
<p><br>
</p>
+
</p>
<a name="Linux_Command_Online_Reference" id="Linux_Command_Online_Reference"></a><h2> <span class="mw-headline">Online Tools and References</span></h2>
+
<h2> <span class="mw-headline">Online Tools and References</span></h2>
 
+
<ul>
+
<ul>
<li><a href="http://www.linuxhowtos.org/Network/netstat.htm" target="_new">netstat</a></li><a href="" target="_new">
+
<li>[http://www.linuxhowtos.org/Network/netstat.htm netstat]</li>  
</a><li><a href="http://www.hscripts.com/tutorials/linux-services/index.php">service</a> <b>or</b> <a href="http://www.linux.com/learn/tutorials/527639-managing-services-on-linux-with-systemd">systemctl</a> (on <u>newer</u> Linux distributions)</li>
+
<li>[http://www.hscripts.com/tutorials/linux-services/index.php service] <b>or</b> [http://www.linux.com/learn/tutorials/527639-managing-services-on-linux-with-systemd systemctl] (on <u>newer</u> Linux distributions)</li>
<li><a href="http://www.ibm.com/developerworks/linux/library/l-pam/index.html" target="_new">PAM</a></li>
+
<li>[http://www.ibm.com/developerworks/linux/library/l-pam/index.html PAM]</li>
<li><a href="http://tommi.org/2008/08/automaticly-blacklisting-password-attempts/" target="_blank">Automatically Blacklist Password Attempts</a></li>
+
<!--DEAD LINK<li>[http://tommi.org/2008/08/automaticly-blacklisting-password-attempts/ Automatically Blacklist Password Attempts]</li>-->
<li><a href="http://www.techcuriosity.com/resources/linux/advanced_file_permissions_in_linux.php" target="_blank">Advanced File Permissions</a></li>
+
<li>[http://www.techcuriosity.com/resources/linux/advanced_file_permissions_in_linux.php Advanced File Permissions]</li>
<li><a href="http://www.cyberciti.biz/tips/howot-install-ubuntu-linux-ssh-server.html" target="_new">SSH</a></li>
+
<li>[http://www.cyberciti.biz/tips/howot-install-ubuntu-linux-ssh-server.html SSH]</li>
<li><a href="http://linuxmanpages.com/" target="_new">Online Linux Manpages</a></li>
+
<!--DEAD LINK<li>[http://linuxmanpages.com/ Online Linux Manpages]</li>-->
</ul>
+
</ul>
 
+
<p><br>
+
<p><br>
</p>
+
</p>
<a name="Resources_on_the_web" id="Resources_on_the_web"></a><h2> <span class="mw-headline">Course Notes</span></h2>
+
<h2> <span class="mw-headline">Course Notes</span></h2>
<ul>
+
<ul>
<li><a href="http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w3_l1.odp">odp</a> | <a href="http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w3_l1.pdf">pdf</a> | <a href="http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w3_l1.ppt">ppt</a> (Slides: Linux Hardening - part 1)</li>
+
<li>[http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w3_l1.odp odp] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w3_l1.pdf pdf] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w3_l1.ppt ppt] (Slides: Linux Hardening - part 1)</li>
<li><a href="http://www.linuxdoc.org/HOWTO/User-Authentication-HOWTO/x115.html" target="_new">Why Use PAM?</a></li>
+
<!--DEAD LINK<li>[http://www.linuxdoc.org/HOWTO/User-Authentication-HOWTO/x115.html Why Use PAM?]</li>-->
<li><a href="http://www.ibm.com/developerworks/linux/library/l-pam/index.html" target="_new">Understanding and Configuring PAM</a></li>
+
<li>[http://www.ibm.com/developerworks/linux/library/l-pam/index.html Understanding and Configuring PAM]</li>
<li><a href="http://lcweb.senecac.on.ca:2063/0596003919" target="_new">Linux Security Cookbook (E-book)</a> (Chapter 4)</li>
+
<!--<li>[http://lcweb.senecac.on.ca:2063/0596003919 Linux Security Cookbook (E-book)] (Chapter 4)</li>-->
</ul>
+
</ul>
 
+
<a name="Performing_Lab_2" id="Performing_Lab_2"></a><h1> <span class="mw-headline">Performing Lab 6</span></h1>
+
<h1> <span class="mw-headline">Performing Lab 6</span></h1>
<p><br>
+
<p><br>
</p>
+
</p>
<a name="Task1" id="Investigation_1:_How_to_Perform_a_Fedora_DVD_Install_on_Your_Removable_Hard_Drive"></a><h2> <span class="mw-headline">Task #1:  Locking Down Bootup / Performing System Updates</span></h2>
+
<h2> <span class="mw-headline">Task #1:  Locking Down Bootup / Performing System Updates</span></h2>
<br />
+
<br />
<div class="messagebox" style="background-color: #f9f6b7; border: 1px solid #c4c295; color: black; padding: 5px; margin: 1ex 0; min-height: 35px; padding-left: 45px;">
+
{{Admon/tip|Locking Down the Server's BIOS|The system adminstrator should prevent the server's BIOS from booting from removable drives, and setup a BIOS password to limit access to editing the server's BIOS. Since you are using the college's computers, you are not able to lock down the BIOS, but it is worth mentioning when you are securing computers in the future.
<div style="float: left; margin-left: -40px;"><a href="/wiki/index.php/File:Important.png" class="image" title="Important.png"><img alt="" src="35px-Idea.png" width="35" height="35" border="0" /></a></div>
+
|}}
<div><b>Locking Down the Server's BIOS</b><br />The system adminstrator should prevent the server's BIOS from booting from removable drives, and setup a BIOS password to limit access to editing the server's BIOS. Since you are using the college's computers, you are not able to lock down the BIOS, but it is worth mentioning when you are securing computers in the future.
+
<br>
</div>
+
This section will demonstrate how easy it is for a regular users to gain
</div>
+
<b>root</b> user access to a newly-booted Linux system. As a safe-guard,
<br>
+
the student will learn how to set a <b>grub password</b> to make the computer
This section will demonstrate how easy it is for a regular users to gain
+
system less vulnerable.
<b>root</b> user access to a newly-booted Linux system. As a safe-guard,
+
<br /><br />
the student will learn how to set a <b>grub password</b> to make the computer
+
{{Admon/important|Vulnerabilities During Boot-up: Single User Mode|Although great attention is paid to securing a Linux system in terms of running services, upgrades, and setting passwords, very little attention can be paid to the boot-up process.<br /><br />The system administrator should configure the BIOS of their Linux servers to <b>prevent bootng from removeable media</b>, and assign a <b>boot password</b> to limit access to edit the Linux server's BIOS settings.<br /><br />In addition (by default) the <b>Grub Boot Loader</b> allows anyone with access to the computer at boot time to set the <b>runlevel, or change the boot parameters</b>, which can allow them to influence the <b><i>init</i></b> process and which kernel image is loaded. Anyone with access to the boot prompt can therefore bypass security controls and control which software is loaded. For example, rebooting to <b>runlevel </b> (known as <b>single user mode</b>), gives the user root priveleges without the need for a password!
system less vulnerable.
+
|}}
<br /><br />
+
<br>
<div class="messagebox" style="background-color: #f9f6b7; border: 1px solid #c4c295; color: black; padding: 5px; margin: 1ex 0; min-height: 35px; padding-left: 45px;">
+
INSTRUCTIONS:
<div style="float: left; margin-left: -40px;"><a href="https://scs.senecac.on.ca/wiki/index.php/File:Important.png" class="image" title="Important.png"><img alt="" src="SEC520_Lab_1_files/35px-Important.png" height="35" border="0" width="35"></a></div>
+
<div><b>Vulnerabilities During Boot-up: Single User Mode</b><br>Although great attention is paid to securing a Linux system in terms of running services, upgrades, and setting passwords, very little attention can be paid to the boot-up process.<br /><br />The system administrator should configure the BIOS of their Linux servers to <b>prevent bootng from removeable media</b>, and assign a <b>boot password</b> to limit access to edit the Linux server's BIOS settings.<br /><br />In addition (by default) the <b>Grub Boot Loader</b> allows anyone with access to the computer at boot time to set the <b>runlevel, or change the boot parameters</b>, which can allow them to influence the <b><i>init</i></b> process and which kernel image is loaded. Anyone with access to the boot prompt can therefore bypass security controls and control which software is loaded. For example, rebooting to <b>runlevel </b> (known as <b>single user mode</b>), gives the user root priveleges without the need for a password!</b>
+
<ol>
</div>
+
<li>Boot your BrackTrack (host) system.</li>
</div>
+
<li>Open the VirtualBox manager window.</li>
<br>
+
<li>Prior to running your Vulnerable Linux VM, read the following link on how to enter into <b>single-user</b> mode:<br /><br />[http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-rescuemode-booting-single.html How to Enter Single User Mode (Fedora17 - also applies to Fedora Core 5)].<br /><br /></li>
INSTRUCTIONS:
+
<li>Boot the Vulnerable Linux VM, press any key, then press the key <b>a</b> to append the word <b>single</b> at the end of the boot command.</li>
 
+
<li>After boot-up is complete, you should notice you are logged in as <b>root</b> (you can issue <b>whoami</b> to confirm.</li>
<ol>
+
<li>Navigate throughout the file system. Check the unpriviledged users in the <b>/home</b> directory.</li>
    <li>Boot your BrackTrack (host) system.</li>
+
<li>What are the consequences by NOT locking down the grub password? Record your observations in your lab log-book.</li>
    <li>Open the VirtualBox manager window.</b>
+
<li>Issue the <b>shutdown -h</b> or <b>halt</b> command to shutdown your Vulnerable Linux VM.
    <li>Prior to running your Vulnerable Linux VM, read the following link on how to enter into <b>single-user</b> mode:<br /><br /><a href="http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-rescuemode-booting-single.html" target="_new">How to Enter Single User Mode (Fedora17 - also applies to Fedora Core 5)</a>.<br /><br /></li>
+
    <li>Boot the Vulnerable Linux VM, press any key, then press the key <b>a</b> to append the word <b>single</b> at the end of the boot command.</li>
+
<br />
    <li>After boot-up is complete, you should notice you are logged in as <b>root</b> (you can issue <b>whoami</b> to confirm.</li>
+
{{Admon/important|Installing a More Recent Linux Distribution|
    <li>Navigate throughout the file system. Check the unpriviledged users in the <b>/home</b> directory.</li>
+
One disadvantage of using <b>Fedora Core 5</b> is that this version is very old, and is no longer supported in terms of its software repositories (software, security patches, etc.). <br /><br />
    <li>What are the consequences by NOT locking down the grub password? Record your observations in your lab log-book.</li>  
+
Therefore, we will be creating another Linux VM (called <b>Hardened Linux</b> using the Fedora17 install image file that you should have downloaded to your Kali Linux (host) at the end of lab3.
    <li>Issue the <b>shutdown -h</b> or <b>halt</b> command to shutdown your Vulnerable Linux VM.</b>
+
|}}
</ol>
+
<br />
<br />
+
<div class="messagebox" style="background-color: #f9f6b7; border: 1px solid #c4c295; color: black; padding: 5px; margin: 1ex 0; min-height: 35px; padding-left: 45px;">
+
<li value="9">Launch the <b>Oracle VM VirtualBox</b> application, click on the <b>New</b> button, and click on <b>Next</b> to proceed.</li>
<div style="float: left; margin-left: -40px;"><a href="/wiki/index.php/File:Important.png" class="image" title="Important.png"><img alt="" src="35px-Important.png" width="35" height="35" border="0" /></a></div>
+
<li>Enter the name <b>Hardened Linux </b>for your VM name. Make certain that the OS Type is <b>Linux</b>, and the Version is <b>Fedora</b>, and then click on <b>Next</b> to proceed.</li>
<div><b>Installing a More Recent Linux Distribution</b><br />
+
<li>Accept the defaults (like you did in lab1, including <b>768 MB</b> RAM and set <b>10GB</b> for the VM's Hard Disk Size), and eventually click <b>Finish</b> to complete the VM setup.<br /><br /></li>
One disadvantage of using <b>Fedora Core 5</b> is that this version is very old, and is no longer supported in terms of its software repositories (software, security patches, etc.). <br /><br />
+
<li>Prior to starting your <b>Hardened Linux</b> VM, you will setup a <b>virtual disk</b> in order to boot from your saved <i>Fedora17 install image</i>.<br />Complete the following steps to prepare for installation:<br /><br /><ol type="a">
Therefore, we will be creating another Linux VM (called <b>Hardened Linux</b> using the Fedora17 install image file that you should have downloaded to your Kali Linux (host) at the end of lab3.
+
<li>Right-click on the VM called <b>Hardened Linux</b> in the VirtualBox application window, and select <b>Settings</b>.</li>
</div>
+
<li>Select <b>Network</b> and set to <b>Host-Only</b> adaptor.</li>
</div>
+
<li>Select <b>Storage</b> tab on the left-side of the application window.</li>
<br />
+
<li>Click on <b>IDE Controller</b> near the top of the <b>Storage Tree</b> window, click on the green plus sign to <b>add a new CD/DVD drive</b>. You will be required to specify the location of that Fedora install image (i.e. <b>Choose Disk</b>). The installation process should start (you may need to wait and ignore system errors). Make default install selections as you did with the previous
<ol>
+
Linux installation. When completed, save your settings.</li>
    <li value="9">Launch the <b>Oracle VM VirtualBox</b> application, click on the <b>New</b> button, and click on <b>Next</b> to proceed.</li>
+
<li>After you have changed your settings, double-click on <b>Hardened Linux</b> to start the installation process.<br /><br /></li>
    <li>Enter the name <b>Hardened Linux </b>for your VM name. Make certain that the OS Type is <b>Linux</b>, and the Version is <b>Fedora</b>, and then click on <b>Next</b> to proceed.</li>
+
<li>Make the following selections during the installation process:
    <li>Accept the defaults (like you did in lab1, including <b>768 MB</b> RAM and set <b>10GB</b> for the VM's Hard Disk Size), and eventually click <b>Finish</b> to complete the VM setup.<br /><br /></li>
+
<ul>
    <li>Prior to starting your <b>Hardened Linux</b> VM, you will setup a <b>virtual disk</b> in order to boot from your saved <i>Fedora17 install image</i>.<br />Complete the following steps to prepare for installation:<br /><br /><ol type="a">
+
<li>In addition to the defaults, add the <b>Fedora F17</b> and <b>Fedora F17 - Updates</b> repository.</li>
      <li>Right-click on the VM called <b>Hardened Linux</b> in the VirtualBox application window, and select <b>Settings</b>.</li>
+
<li>Select <b>Create a Grub Boot Password</b> near the end of the installation in the Grub Boot section; Otherwise, accept similar defaults like you did in lab1.<br /><br /><b>NOTE:</b> If you were unable to set the Grub password during the installation procedure, then as an option, you may search the Internet for a method to manually set the password after the installation process...<br /><br /></li>
      <li>Select <b>Network</b> and set to <b>Host-Only</b> adaptor.</li>
+
</ul>
      <li>Select <b>Storage</b> tab on the left-side of the application window.</li>
+
</li>
      <li>Click on <b>IDE Controller</b> near the top of the <b>Storage Tree</b> window, click on the green plus sign to <b>add a new CD/DVD drive</b>. You will be required to specify the location of that Fedora install image (i.e. <b>Choose Disk</b>). The installation process should start (you may need to wait and ignore system errors). Make default install selections as you did with the previous
+
<li>After the installation is complete, shutdown the system, go into <b>Settings</b> and remove the virtual CD/DVD drive that links to your <b>Fedora17 image file</b>. Boot your <b>Hardened Linux</b> VM and try to enter <b>single-user</b> mode. Were you successful?<br />Record your findings in your lab log-book.</li>
Linux installation. When completed, save your settings.</li>
+
</ol>
      <li>After you have changed your settings, double-click on <b>Hardened Linux</b> to start the installation process.<br /><br /></li>
+
<li>When booting your Hardened Linux system for the first time, fill out a regular user account, and <b>add to administrator's group</b>.</li>
      <li>Make the following selections during the installation process:
+
<li>Finally, perform an update on your system by issuing: <b>yum update</b>.</li>
          <ul>
+
            <li>In addition to the defaults, add the <b>Fedora F17</b> and <b>Fedora F17 - Updates</b> repository.</li>
+
<br />
            <li>Select <b>Create a Grub Boot Password</b> near the end of the installation in the Grub Boot section; Otherwise, accept similar defaults like you did in lab1.<br /><br /><b>NOTE:</b> If you were unable to set the Grub password during the installation procedure, then as an option, you may search the Internet for a method to manually set the password after the installation process...<br /><br /></li>
+
      </ul>
+
{{Admon/important|Periodic Updates &amp; Upgrades|
      </li>
+
It is important as a system administrator to periodically and consistently <b>update/upgrade the operating system and applications</b> to help harden the operating system from vulnerabilities.
    <li>After the installation is complete, shutdown the system, go into <b>Settings</b> and remove the virtual CD/DVD drive that links to your <b>Fedora17 image file</b>. Boot your <b>Hardened Linux</b> VM and try to enter <b>single-user</b> mode. Were you successful?<br />Record your findings in your lab log-book.</li>
+
<br /><br />
    <li>When booting your Hardened Linux system for the first time, fill out a regular user account, and <b>add to administrator's group</b>.</li>
+
It is also important to perform <b>operating system upgrades</b> when officially released (stable) editions become available. Failing to perform upgrades to an operating system can eventually make operating systems obsolete and unsupported by the development community. Usually a Linux distribution provides time-lines regarding support (eg. <b>LTS: Long Term Support</b>).
    <li>Finally, perform an update on your system by issuing: <b>yum update</b>.</li>
+
|}}
</ol>
+
<br />
+
<br />
 
+
<div class="messagebox" style="background-color: #f9f6b7; border: 1px solid #c4c295; color: black; padding: 5px; margin: 1ex 0; min-height: 35px; padding-left: 45px;">
+
<li value="15">Record your observations in your lab log-book.</li>
<div style="float: left; margin-left: -40px;"><a href="/wiki/index.php/File:Important.png" class="image" title="Important.png"><img alt="" src="35px-Important.png" width="35" height="35" border="0" /></a></div>
+
<li>Proceed to Task #2.</li>
<div><b>Periodic Updates &amp; Upgrades</b><br />
+
</ol>
It is important as a system administrator to periodically and consistently <b>update/upgrade the operating system and applications</b> to help harden the operating system from vulnerabilities.
+
<br /><br />
+
<p><b>Answer the Task #1 observations / questions in your lab log book.</b>
It is also important to perform <b>operating system upgrades</b> when officially released (stable) editions become available. Failing to perform upgrades to an operating system can eventually make operating systems obsolete and unsupported by the development community. Usually a Linux distribution provides time-lines regarding support (eg. <b>LTS: Long Term Support</b>).
+
</p>
</div>
+
<p><br>
</div>
+
</p>
 
+
<br />
+
<ol>
+
    <li value="15">Record your observations in your lab log-book.</li>
+
<h2> <span class="mw-headline">Task #2: Closing Unnecessary Ports / Using SSH</span></h2>
    <li>Proceed to Task #2.</li>
+
<br>
</ol>
+
In this section, you will either close or prevent unnecessary ports (services) from running and <b>mask some running services</b> (such as SSH) in order to make your Linux system less vulnerable.
 
+
<br><br>
<p><b>Answer the Task #1 observations / questions in your lab log book.</b>
+
INSTRUCTIONS:
</p>
+
<p><br>
+
<ol>
</p>
+
<li>Tighten up your Hardened Linux VM to expose the <b>smallest possible number of services</b> running on your Linux system.</li>
 
+
<li>Verify that the minimum number of (essential) services are running on your Linux system.</li>
 
+
<li>Use the <b>Nessus</b> application and <b>Metasploit</b> framework to confirm that there are no vulnerable services running on your Hardened Linux VM.</li>
 
+
<li>Discuss with another classmate  which software is <u>not</u> required to be installed. What is the minimum software configuration that
<a name="Task2" id="Investigation_1:_How_to_Perform_a_Fedora_DVD_Install_on_Your_Removable_Hard_Drive"></a><h2> <span class="mw-headline">Task #2: Closing Unnecessary Ports / Using SSH</span></h2>
+
will work? Try to list at least 10 applications in your lab log-book. </li>
<br>
+
<li>With a classmate, discuss the information visible to users logged in to your system and whether the disclosure of that information presents any real security risk. For example, is it ok for users to view the information in <b>/proc</b>? or in <b>/etc</b>?<br /><br /></li>
In this section, you will either close or prevent unnecessary ports (services) from running and <b>mask some running services</b> (such as SSH) in order to make your Linux system less vulnerable.
+
<li>Refer to the following link to OPS235 Lab 7 (SSH): [http://zenit.senecac.on.ca/wiki/index.php/OPS235_Lab_7#Investigation_1:_How_do_you_enable_the_sshd_service. SSH Configuration]<br />(Note: newer versions of Fedora Linux use <b>systemctl</b> instead of the <b>system</b> command).</li>
<br><br>
+
<li>Configure SSH to run for a different port number.</li>
INSTRUCTIONS:
+
<li>Use SSH to run the <b>gedit</b> command command from your Linux VM, but displayed on your host.</li>
 
+
<li>Have your group members view the open ports on your VM, and see if they can access this running port.</li>
<ol>
+
<li>How does this technique make your Linux server less vulnerable?</li>
<li>Tighten up your Hardened Linux VM to expose the <b>smallest possible number of services</b> running on your Linux system.</li>
+
<li>Proceed to Task #3.</li>
<li>Verify that the minimum number of (essential) services are running on your Linux system.</li>
+
</ol>
<li>Use the <b>Nessus</b> application and <b>Metasploit</b> framework to confirm that there are no vulnerable services running on your Hardened Linux VM.</li>
+
<p><b>Answer the Task #2 observations / questions in your lab log book.</b>
<li>Discuss with another classmate  which software is <u>not</u> required to be installed. What is the minimum software configuration that  
+
</p>
will work? Try to list at least 10 applications in your lab log-book. </li>
+
<br><br>
<li>With a classmate, discuss the information visible to users logged in to your system and whether the disclosure of that information presents any real security risk. For example, is it ok for users to view the information in <b>/proc</b>? or in <b>/etc</b>?<br /><br /></li>
+
<h2> <span class="mw-headline">Task #3: Using PAM</span></h2>
<li>Refer to the following link to OPS235 Lab 7 (SSH): <a href="http://zenit.senecac.on.ca/wiki/index.php/OPS235_Lab_7#Investigation_1:_How_do_you_enable_the_sshd_service." target="_new">SSH Configuration</a><br />(Note: newer versions of Fedora Linux use <b>systemctl</b> instead of the <b>system</b> command).</li>
+
<br>
<li>Configure SSH to run for a different port number.</li>
+
Fedora uses the Linux <b>Pluggable Authentication Modules (PAM)</b> system to perform <b>authentication (and some related activities, such as account environment initialization)</b>. As the name suggests, PAM is modular and permits various modules to be plugged in or removed at the system administrator's discretion.
<li>Use SSH to run the <b>gedit</b> command command from your Linux VM, but displayed on your host.</li>
+
<br><br>
<li>Have your group members view the open ports on your VM, and see if they can access this running port.</li>
+
INSTRUCTIONS:
<li>How does this technique make your Linux server less vulnerable?</li>
+
<ol>
<li>Proceed to Task #3.</li>
+
<li>Ensure that your Hardened Linux VM (i.e. Fedora17) system is running, and log-in as a user with administration priviledges.</li>
</ol>
+
<li>Open a shell terminal in your Hardened Linux VM, and change to the directory <b>/etc/pam.d</b> and review the names of the existing files. What do you think these represent in terms of hardening this system? Record your answer in your lab log-book. Locate the file that contains the PAM configuration for <b>system-config-network</b>.</li>
<p><b>Answer the Task #2 observations / questions in your lab log book.</b>
+
<li>Access the <b>PAM System Administrator's Guide</b> in a web-browser (file pathname: <b>/usr/share/doc/pam-1.1.5/html/Linux-PAM_SAG.html</b></li>
</p>
+
<li>Make a brief list of line options for the <b>system-config-network</b> PAM configuration file, and record in your lab log-book.</li>
<br><br>
+
<li>How could you change this PAM configuration file so that a user logged in on the console would not need to enter the root password? (read the manual or perform a NetSearch to get the answer). Record your answer in your lab log-book.<br><br></li>
<a name="Task3" d="Investigation_2:_How_many_file_packages_and_files_are_installed_on_the_system.3F"></a><h2> <span class="mw-headline">Task #3: Using PAM</span></h2>
+
</ol>
<br>
+
{{Admon/tip|Pam ABL|<b>Pam ABL stands</b> for <b>Pam Auto Blacklist Module</b>. This module allows for the blacklisting of hosts (users) that repeatedly attempt to connect / authenticate with your server.<br><br>|}}
Fedora uses the Linux <b>Pluggable Authentication Modules (PAM)</b> system to perform <b>authentication (and some related activities, such as account environment initialization)</b>. As the name suggests, PAM is modular and permits various modules to be plugged in or removed at the system administrator's discretion.
+
<br><br>
+
<br>
INSTRUCTIONS:
+
<ol>
+
<li>Ensure that your Hardened Linux VM (i.e. Fedora17) system is running, and log-in as a user with administration priviledges.</li>
+
<li>Open a shell terminal in your Hardened Linux VM, and change to the directory <b>/etc/pam.d</b> and review the names of the existing files. What do you think these represent in terms of hardening this system? Record your answer in your lab log-book. Locate the file that contains the PAM configuration for <b>system-config-network</b>.</li>
+
<ol>
<li>Access the <b>PAM System Administrator's Guide</b> in a web-browser (file pathname: <b>/usr/share/doc/pam-1.1.5/html/Linux-PAM_SAG.html</b></li>
+
<li value="15">Install the <b>pam_abl</b> package by issuing the following command: <b>yum install pam_abl</b>.</li>
<li>Make a brief list of line options for the <b>system-config-network</b> PAM configuration file, and record in your lab log-book.</li>
+
<li>Research on the Internet how to edit the pam_abl configuration file. Documentation for pam_abl (web-browser) is available by using the file pathname:<br /><b>/usr/share/doc/pam_abl-0.2.3/pam_abl.html</b></li>
<li>How could you change this PAM configuration file so that a user logged in on the console would not need to enter the root password? (read the manual or perform a NetSearch to get the answer). Record your answer in your lab log-book.<br><br></li>
+
<li>Configure the file <b>/etc/security/pam_abl.conf</b> to use the <b>pam_time</b> module to permit remote ssh access only during the daytime.</li>
</ol>
+
<li>Configure your system <b>to deny access for 1 day</b> to any user or host who has <u><b>5</b> invalid password attempts in an hour</u>, or <u><b>12</b> invalid password attempts in a day</u> using the <b>pam_abl</b> module.<br /><!--DEAD LINK<br />Here is a approximate example: [http://tommi.org/2008/08/automaticly-blacklisting-password-attempts/ Automatically Blacklist Password Attempts]<br />--><br /></li>
<div class="messagebox" style="background-color: #f9f6b7; border: 1px solid #c4c295; color: black; padding: 5px; margin: 1ex 0; min-height: 35px; padding-left: 45px;">
+
<li>Create a group named <b>development</b>.</li>
<div style="float: left; margin-left: -40px;"><a href="https://scs.senecac.on.ca/wiki/index.php/File:Important.png" class="image" title="Important.png"><img alt="" src="SEC520_Lab_1_files/35px-Idea.png" height="35" border="0" width="35"></a></div>
+
<li>Create the directory <b>/var/devel1</b> and <b>/var/devel2</b> and make them accessible to all users. Set the SGID permission bit on <b>/var/devel2</b> and make that directory owned by the group called <i>development</i>.<br /><br />Here is a link to setting SGID permissions: [http://www.techcuriosity.com/resources/linux/advanced_file_permissions_in_linux.php Advanced File Permissions]<br /><br /></li>
<div><b>Pam ABL</b><br><b>Pam ABL stands</b> for <b>Pam Auto Blacklist Module</b>. This module allows for the blacklisting of hosts (users) that repeatedly attempt to connect / authenticate with your server.<br><br></div>
+
<li>Create <b>three regular users</b>. Ensure that two users are in the <i>development</i> group and that the third user is not.</li>
</div>
+
<li>Have each user create a file in <b>/var/devel1</b> and <b>/var/devel2</b>.</li>
 
+
<li>Record the user and group permission for each file.</li>
<br>
+
<li>Attempt to access each of the six files using each user's account  
 
+
by reading and then appending (two separate operations). What succeeds  
 
+
and what fails? Why?</li>
 
+
<li>What would the development users have to do to make their files in <b>/var/devel1</b> accessible to each other?</li>
<ol>
+
<li>Why is Fedora set up so that each user has their own group and the default umask is <b>0002</b>?</li>
<li value="15">Install the <b>pam_abl</b> package by issuing the following command: <b>yum install pam_abl</b>.</li>
+
<li>Record your findings in your lab log-book.</li>
<li>Research on the Internet how to edit the pam_abl configuration file. Documentation for pam_abl (web-browser) is available by using the file pathname:<br /><b>/usr/share/doc/pam_abl-0.2.3/pam_abl.html</b></li>
+
<li>Proceed to "Completing The Lab".</li>
<li>Configure the file <b>/etc/security/pam_abl.conf</b> to use the <b>pam_time</b> module to permit remote ssh access only during the daytime.</li>
+
</ol>
<li>Configure your system <b>to deny access for 1 day</b> to any user or host who has <u><b>5</b> invalid password attempts in an hour</u>, or <u><b>12</b> invalid password attempts in a day</u> using the <b>pam_abl</b> module.<br /><br />Here is a approximate example: <a href="http://tommi.org/2008/08/automaticly-blacklisting-password-attempts/" target="_blank">Automatically Blacklist Password Attempts</a><br /><br /></li>
+
<li>Create a group named <b>development</b>.</li>
+
<p><b>Answer Task #3 observations / questions in your lab log book.</b>
<li>Create the directory <b>/var/devel1</b> and <b>/var/devel2</b> and make them accessible to all users. Set the SGID permission bit on <b>/var/devel2</b> and make that directory owned by the group called <i>development</i>.<br /><br />Here is a link to setting SGID permissions: <a href="http://www.techcuriosity.com/resources/linux/advanced_file_permissions_in_linux.php" target="_blank">Advanced File Permissions</a><br /><br /></li>
+
</p><p><br>
<li>Create <b>three regular users</b>. Ensure that two users are in the <i>development</i> group and that the third user is not.</li>
+
</p>
<li>Have each user create a file in <b>/var/devel1</b> and <b>/var/devel2</b>.</li>
+
<li>Record the user and group permission for each file.</li>
+
<li>Attempt to access each of the six files using each user's account  
+
by reading and then appending (two separate operations). What succeeds  
+
<h1> <span class="mw-headline"> Completing the Lab </span></h1>
and what fails? Why?</li>
+
<p><b>Arrange evidence for each of these items on your screen, then ask  
<li>What would the development users have to do to make their files in <b>/var/devel1</b> accessible to each other?</li>
+
your instructor to review them and sign off on the lab's completion:</b>
<li>Why is Fedora set up so that each user has their own group and the default umask is <b>0002</b>?</li>
+
</p>
<li>Record your findings in your lab log-book.</li>
+
<ol>
<li>Proceed to "Completing The Lab".</li>
+
<li>All unneccessary services <b>turned-off</b>.</li>
</ol>
+
<li>SSH run on a <b>different port</b>.</li>
 
+
<li>Proof of <b>PAM</b> used to control access to directories. </li>
<p><b>Answer Task #3 observations / questions in your lab log book.</b>
+
<li>Completed Lab 6 notes.</li>
</p><p><br>
+
</ol>
</p>
+
<p><br>
 
+
</p>
 
+
<h1> <span class="mw-headline"> Preparing for Quizzes </span></h1>
 
+
<a name="Completing_the_Lab" id="Completing_the_Lab"></a><h1> <span class="mw-headline"> Completing the Lab </span></h1>
+
<ol>
<p><b>Arrange evidence for each of these items on your screen, then ask  
+
<li>Briefly explain how to access the root account (in run-level 1) from an unprotected Linux system upon boot-up.</li>
your instructor to review them and sign off on the lab's completion:</b>
+
<li>List the steps to setup a <b>grub password</b> to protect a Linux system upon boot-up.</li>
</p>
+
<li>Explain the consequences of running unneccesary services on a server.</li>
<ol>
+
<li>List the steps to stop a running service, and describe 2 unique methods of confirming that  a service is no longer running on the server?</li>
<li>All unneccessary services <b>turned-off</b>.</li>
+
<li>What is the purpose of using SSH for tunnelling while using a different port number?</li>
<li>SSH run on a <b>different port</b>.</li>
+
<li>What does <b>PAM</b> stand for? What is the purpose of the <i>PAM</i> modules?</li>
<li>Proof of <b>PAM</b> used to control access to directories. </li>
+
<li>What is the purpose of the <b>pam_abl</b> modules?</li>
<li>Completed Lab 6 notes.</li>
+
</ol>
</ol>
 
<p><br>
 
</p>
 
<a name="Preparing_for_Quizzes" id="Preparing_for_Quizzes"></a><h1> <span class="mw-headline"> Preparing for Quizzes </span></h1>
 
 
 
<ol>
 
<li>Briefly explain how to access the root account (in run-level 1) from an unprotected Linux system upon boot-up.</li>
 
<li>List the steps to setup a <b>grub password</b> to protect a Linux system upon boot-up.</li>
 
<li>Explain the consequences of running unneccesary services on a server.</li>
 
<li>List the steps to stop a running service, and describe 2 unique methods of confirming that  a service is no longer running on the server?</li>
 
<li>What is the purpose of using SSH for tunnelling while using a different port number?</li>
 
<li>What does <b>PAM</b> stand for? What is the purpose of the <i>PAM</i> modules?</li>
 
<li>What is the purpose of the <b>pam_abl</b> modules?</li>
 
</ol>
 

Latest revision as of 15:00, 21 July 2023

Linux System Hardening (Part 1)

Introduction

  • In this lab, students will learn how to make their Linux servers less vulnerable to attacks (i.e. hardening the Linux system). First, students will prevent users from booting into run level 1 (super-user mode) by creating a grub boot password.
  • Students will also identify and close unneccesary ports (running services) on their Linux and Windows Virtual Machines in order to make those servers less vulnerable to attacks.
  • Students will then configure SSH to provide a safe "tunnel" for data to prevent from hacking, and to change the port number to help to confuse (discourage) hackers.
  • Finally, students will use PAM (Plugable Authentication Modules) to further protect running applications in their VMs.



Objectives

  1. Setup a grub boot password to prevent users from gaining access to super-user mode during Linux system bootup.
  2. Close unnecessary running ports (services) to make server(s) less vulnerable to attack.
  3. Use SSH tunnelling to protect data from being picked up by hackers.
  4. Use PAM to provide authentication for APIs (application programming interfaces).


Required Materials (Bring to All Labs)

  • SATA Hard Disk (in removable disk tray).
  • Lab Logbook (Lab4 Reference Sheet) (to make notes and observations).


Prerequisites


Online Tools and References


Course Notes

Performing Lab 6


Task #1: Locking Down Bootup / Performing System Updates


Idea.png
Locking Down the Server's BIOS
The system adminstrator should prevent the server's BIOS from booting from removable drives, and setup a BIOS password to limit access to editing the server's BIOS. Since you are using the college's computers, you are not able to lock down the BIOS, but it is worth mentioning when you are securing computers in the future.


This section will demonstrate how easy it is for a regular users to gain root user access to a newly-booted Linux system. As a safe-guard, the student will learn how to set a grub password to make the computer system less vulnerable.

Important.png
Vulnerabilities During Boot-up: Single User Mode
Although great attention is paid to securing a Linux system in terms of running services, upgrades, and setting passwords, very little attention can be paid to the boot-up process.

The system administrator should configure the BIOS of their Linux servers to prevent bootng from removeable media, and assign a boot password to limit access to edit the Linux server's BIOS settings.

In addition (by default) the Grub Boot Loader allows anyone with access to the computer at boot time to set the runlevel, or change the boot parameters, which can allow them to influence the init process and which kernel image is loaded. Anyone with access to the boot prompt can therefore bypass security controls and control which software is loaded. For example, rebooting to runlevel (known as single user mode), gives the user root priveleges without the need for a password!


INSTRUCTIONS:

  1. Boot your BrackTrack (host) system.
  2. Open the VirtualBox manager window.
  3. Prior to running your Vulnerable Linux VM, read the following link on how to enter into single-user mode:

    How to Enter Single User Mode (Fedora17 - also applies to Fedora Core 5).

  4. Boot the Vulnerable Linux VM, press any key, then press the key a to append the word single at the end of the boot command.
  5. After boot-up is complete, you should notice you are logged in as root (you can issue whoami to confirm.
  6. Navigate throughout the file system. Check the unpriviledged users in the /home directory.
  7. What are the consequences by NOT locking down the grub password? Record your observations in your lab log-book.
  8. Issue the shutdown -h or halt command to shutdown your Vulnerable Linux VM.
    Important.png
    Installing a More Recent Linux Distribution

    One disadvantage of using Fedora Core 5 is that this version is very old, and is no longer supported in terms of its software repositories (software, security patches, etc.).

    Therefore, we will be creating another Linux VM (called Hardened Linux using the Fedora17 install image file that you should have downloaded to your Kali Linux (host) at the end of lab3.


  9. Launch the Oracle VM VirtualBox application, click on the New button, and click on Next to proceed.
  10. Enter the name Hardened Linux for your VM name. Make certain that the OS Type is Linux, and the Version is Fedora, and then click on Next to proceed.
  11. Accept the defaults (like you did in lab1, including 768 MB RAM and set 10GB for the VM's Hard Disk Size), and eventually click Finish to complete the VM setup.

  12. Prior to starting your Hardened Linux VM, you will setup a virtual disk in order to boot from your saved Fedora17 install image.
    Complete the following steps to prepare for installation:

    1. Right-click on the VM called Hardened Linux in the VirtualBox application window, and select Settings.
    2. Select Network and set to Host-Only adaptor.
    3. Select Storage tab on the left-side of the application window.
    4. Click on IDE Controller near the top of the Storage Tree window, click on the green plus sign to add a new CD/DVD drive. You will be required to specify the location of that Fedora install image (i.e. Choose Disk). The installation process should start (you may need to wait and ignore system errors). Make default install selections as you did with the previous Linux installation. When completed, save your settings.
    5. After you have changed your settings, double-click on Hardened Linux to start the installation process.

    6. Make the following selections during the installation process:
      • In addition to the defaults, add the Fedora F17 and Fedora F17 - Updates repository.
      • Select Create a Grub Boot Password near the end of the installation in the Grub Boot section; Otherwise, accept similar defaults like you did in lab1.

        NOTE: If you were unable to set the Grub password during the installation procedure, then as an option, you may search the Internet for a method to manually set the password after the installation process...

    7. After the installation is complete, shutdown the system, go into Settings and remove the virtual CD/DVD drive that links to your Fedora17 image file. Boot your Hardened Linux VM and try to enter single-user mode. Were you successful?
      Record your findings in your lab log-book.
  13. When booting your Hardened Linux system for the first time, fill out a regular user account, and add to administrator's group.
  14. Finally, perform an update on your system by issuing: yum update.

  15. Important.png
    Periodic Updates & Upgrades

    It is important as a system administrator to periodically and consistently update/upgrade the operating system and applications to help harden the operating system from vulnerabilities.

    It is also important to perform operating system upgrades when officially released (stable) editions become available. Failing to perform upgrades to an operating system can eventually make operating systems obsolete and unsupported by the development community. Usually a Linux distribution provides time-lines regarding support (eg. LTS: Long Term Support).


  16. Record your observations in your lab log-book.
  17. Proceed to Task #2.

Answer the Task #1 observations / questions in your lab log book.



Task #2: Closing Unnecessary Ports / Using SSH


In this section, you will either close or prevent unnecessary ports (services) from running and mask some running services (such as SSH) in order to make your Linux system less vulnerable.

INSTRUCTIONS:

  1. Tighten up your Hardened Linux VM to expose the smallest possible number of services running on your Linux system.
  2. Verify that the minimum number of (essential) services are running on your Linux system.
  3. Use the Nessus application and Metasploit framework to confirm that there are no vulnerable services running on your Hardened Linux VM.
  4. Discuss with another classmate which software is not required to be installed. What is the minimum software configuration that will work? Try to list at least 10 applications in your lab log-book.
  5. With a classmate, discuss the information visible to users logged in to your system and whether the disclosure of that information presents any real security risk. For example, is it ok for users to view the information in /proc? or in /etc?

  6. Refer to the following link to OPS235 Lab 7 (SSH): SSH Configuration
    (Note: newer versions of Fedora Linux use systemctl instead of the system command).
  7. Configure SSH to run for a different port number.
  8. Use SSH to run the gedit command command from your Linux VM, but displayed on your host.
  9. Have your group members view the open ports on your VM, and see if they can access this running port.
  10. How does this technique make your Linux server less vulnerable?
  11. Proceed to Task #3.

Answer the Task #2 observations / questions in your lab log book.



Task #3: Using PAM


Fedora uses the Linux Pluggable Authentication Modules (PAM) system to perform authentication (and some related activities, such as account environment initialization). As the name suggests, PAM is modular and permits various modules to be plugged in or removed at the system administrator's discretion.

INSTRUCTIONS:

  1. Ensure that your Hardened Linux VM (i.e. Fedora17) system is running, and log-in as a user with administration priviledges.
  2. Open a shell terminal in your Hardened Linux VM, and change to the directory /etc/pam.d and review the names of the existing files. What do you think these represent in terms of hardening this system? Record your answer in your lab log-book. Locate the file that contains the PAM configuration for system-config-network.
  3. Access the PAM System Administrator's Guide in a web-browser (file pathname: /usr/share/doc/pam-1.1.5/html/Linux-PAM_SAG.html
  4. Make a brief list of line options for the system-config-network PAM configuration file, and record in your lab log-book.
  5. How could you change this PAM configuration file so that a user logged in on the console would not need to enter the root password? (read the manual or perform a NetSearch to get the answer). Record your answer in your lab log-book.

Idea.png
Pam ABL
Pam ABL stands for Pam Auto Blacklist Module. This module allows for the blacklisting of hosts (users) that repeatedly attempt to connect / authenticate with your server.



  1. Install the pam_abl package by issuing the following command: yum install pam_abl.
  2. Research on the Internet how to edit the pam_abl configuration file. Documentation for pam_abl (web-browser) is available by using the file pathname:
    /usr/share/doc/pam_abl-0.2.3/pam_abl.html
  3. Configure the file /etc/security/pam_abl.conf to use the pam_time module to permit remote ssh access only during the daytime.
  4. Configure your system to deny access for 1 day to any user or host who has 5 invalid password attempts in an hour, or 12 invalid password attempts in a day using the pam_abl module.

  5. Create a group named development.
  6. Create the directory /var/devel1 and /var/devel2 and make them accessible to all users. Set the SGID permission bit on /var/devel2 and make that directory owned by the group called development.

    Here is a link to setting SGID permissions: Advanced File Permissions

  7. Create three regular users. Ensure that two users are in the development group and that the third user is not.
  8. Have each user create a file in /var/devel1 and /var/devel2.
  9. Record the user and group permission for each file.
  10. Attempt to access each of the six files using each user's account by reading and then appending (two separate operations). What succeeds and what fails? Why?
  11. What would the development users have to do to make their files in /var/devel1 accessible to each other?
  12. Why is Fedora set up so that each user has their own group and the default umask is 0002?
  13. Record your findings in your lab log-book.
  14. Proceed to "Completing The Lab".

Answer Task #3 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:

  1. All unneccessary services turned-off.
  2. SSH run on a different port.
  3. Proof of PAM used to control access to directories.
  4. Completed Lab 6 notes.


Preparing for Quizzes

  1. Briefly explain how to access the root account (in run-level 1) from an unprotected Linux system upon boot-up.
  2. List the steps to setup a grub password to protect a Linux system upon boot-up.
  3. Explain the consequences of running unneccesary services on a server.
  4. List the steps to stop a running service, and describe 2 unique methods of confirming that a service is no longer running on the server?
  5. What is the purpose of using SSH for tunnelling while using a different port number?
  6. What does PAM stand for? What is the purpose of the PAM modules?
  7. What is the purpose of the pam_abl modules?