SEC520/labs/Lab 6

From CDOT Wiki
Revision as of 09:07, 1 February 2018 by Nathan.misener (talk | contribs) (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>...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Linux System Hardening (Part 1)

<a name="Introduction" id="Introduction"></a>

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.



<a name="Objectives" id="Objectives"></a>

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).


<a name="Required_Materials_.28Bring_to_All_Labs.29" id="Required_Materials_.28Bring_to_All_Labs.29"></a>

Required Materials (Bring to All Labs)

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


<a name="Prerequisites" id="Prerequisites"></a>

Prerequisites


<a name="Linux_Command_Online_Reference" id="Linux_Command_Online_Reference"></a>

Online Tools and References


<a name="Resources_on_the_web" id="Resources_on_the_web"></a>

Course Notes

<a name="Performing_Lab_2" id="Performing_Lab_2"></a>

Performing Lab 6


<a name="Task1" id="Investigation_1:_How_to_Perform_a_Fedora_DVD_Install_on_Your_Removable_Hard_Drive"></a>

Task #1: Locking Down Bootup / Performing System Updates


<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>
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.

<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>
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!</b>


INSTRUCTIONS:

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

    <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>.

  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.</b> </ol>
    <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>
    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.


    1. Launch the Oracle VM VirtualBox application, click on the New button, and click on Next to proceed.
    2. 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.
    3. 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.

    4. 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.
      8. When booting your Hardened Linux system for the first time, fill out a regular user account, and add to administrator's group.
      9. Finally, perform an update on your system by issuing: yum update.


      <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>
      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).


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

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



      <a name="Task2" id="Investigation_1:_How_to_Perform_a_Fedora_DVD_Install_on_Your_Removable_Hard_Drive"></a>

      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): <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>
        (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.



      <a name="Task3" d="Investigation_2:_How_many_file_packages_and_files_are_installed_on_the_system.3F"></a>

      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.

      <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>
      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.

        Here is a approximate example: <a href="http://tommi.org/2008/08/automaticly-blacklisting-password-attempts/" target="_blank">Automatically Blacklist Password Attempts</a>

      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: <a href="http://www.techcuriosity.com/resources/linux/advanced_file_permissions_in_linux.php" target="_blank">Advanced File Permissions</a>

      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.



      <a name="Completing_the_Lab" id="Completing_the_Lab"></a>

      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.


      <a name="Preparing_for_Quizzes" id="Preparing_for_Quizzes"></a>

      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?
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=SEC520/labs/Lab_6&oldid=131226"