Download Linux Hardening: Partitioning, BIOS Protection, and SYN Cookies and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
ECE4112 Final Laboratory
Lab12: Hardening Linux
**Group Number: ___________________________ Member Names: ___________________________
Date Assigned: Date Due: Last Edited: Lab Authored by: Matthew Bowman (gtg763m) Michael Sanders (gtg616r) Stanca Laura Silaghi (gtg853f)** Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due.
Goal: This lab will introduce you to basic steps in hardening the security of a Linux
distribution. Securing and hardening Linux distributions is an extensive subject. We aimed to provide you with a primer on some of the important issues in hardening a distribution.
Summary: This lab consists of 3 sections. The first section teaches you about partitions
on the hard drive vs partitions in memory. The second section shows you how to minimize the risks of getting compromised through physical access by protecting the BIOS and the loaders. Finally, the last section discusses SYN attacks and how to prevent them at kernel level without using a firewall.
Lab Scenario: This lab requires the use of the Gentoo 2006.0 Virtual Machine. You
will need to create this VM from the disk provided by the TA as you have done with the other virtual machines in previous labs. The login pair for this machine is “root/password”. Do not forget to assign this new VM one of your spare IP addresses. Refer to lab 1 if you forgot how to do this.
Background: As you probably already know, Linux is the operating system of choice
in security environments. The reason behind this is that Unix based OS’s are highly customizable and configurable. In addition, the open source nature of this OS makes Linux flexible and dynamic. When a bug or security threat is discovered, the entire world weighs in on providing a solution. For many of you, Linux equates to a black terminal controlled by confusing commands. This Lab, and this class, is not for those people. If you are not familiar with simple unix commands such as ls, ps, ifconfig, read the below Linux tutorial before you try to work on this
lab. The Gentoo portal link provides a quick overview of the actual distribution you will be working on, namely Gentoo. Gentoo is one of the most user-friendly and powerful distributions out there, it is used by millions of people and the number is growing, so before you approach it with fear, just give it a chance. [Gentoo Portal]-http://www.gentoo.org/ [Gentoo Review]-http://linuxreviews.org/gentoo/ [Linux Basics]- http://www.freeos.com/articles/4414/ [Linux Overview] -http://www.linux.com/article.pl?sid=02/03/09/
Section 2 – Access Control
2.1 Password Protecting the BIOS
The idea here is simple: if someone can alter the boot order of your computer’s devices, then they can break into your system. This is easily done by changing the boot order to boot from the floppy drive, or the CD Rom, and using a system restoration disk, or live CD, to change or delete your password. In the case of the live CD, it may not even be necessary to alter the password. Some Knoppix distributions allow a user to boot from the live CD and mount the existing file system on the hard drive once the Knoppix environment has been loaded. In this scenario, an attacker can steal or alter sensitive information without damaging the existing environment on the hard drive and alerting the user that they have been victimized. The simplest way to protect your system from this type of attack is to enable the password option in your BIOS. This will require any user to enter the password before they are allowed access to alter your BIOS settings (hint: INCLUDING THE BOOT ORDER!). This is a common security option found in many BIOS versions and one of the simplest ways to add another layer of security to your system. Along these same lines, you can also create a boot password. This will require users to enter a password before the computer will even begin the boot process. The password is set from inside the BIOS. The option for setting the boot password is usually in the same general area of the BIOS where you set the BIOS password. Just remember to use good password selection procedures when choosing your boot and BIOS passwords. You can protect your system with a hundred passwords, but it won’t be any more secure if they’re all “1234”! Now reboot the VMWare and when you see the BIOS logo press F2. Next: Security tab Set Supervision Password Enter. Enter the password “password” in each field and press Enter after each entry. Next press Enter again to continue. Now navigate to the Exit tab and press Enter twice to Exit and save your changes. The machine will now reboot. When you see the BIOS logo press F2 once again. You should now see that it is password protected. Take a screenshot of the BIOS password prompt from VMWare and attach it to your answer sheet. Screenshot#1: Bios Password Prompt
2.2 Password Protecting the Boot Loader Linux distributions use a utility known as a boot loader to load the kernel and boot the system. The two main boot loaders used by Linux are GRUB , short for GR and U nified B oot loader, and LILO , short for LI nux LO ader. Like many other Linux utilities, these can be executed with command line options. The security nightmare that this creates is the case where the boot loader is passed a command line option to open a single user shell. This can give the user the ability to execute commands under root permissions. A simple way to prevent this is to create a password for the boot loader that must be entered in order for a user to execute the boot loader with command line options. Different boot loaders have support for different types of passwords. For example, GRUB allows the use of MD encrypted passwords, while LILO is only able to support passwords in clear text form.
2.2.1 Grub Boot Loader
You can set an MD5 encrypted password for GRUB using the following steps: Open a simple GRUB shell: $> grub Generate an MD5 encrypted password: grub> md5crypt Password: ******* Encrypted: $1$sEOFN1$dalP1fzlFCHD4saxlnNzM/ grub> Copy the encrypted password, including the trailing ‘/’ or ‘.’ if it is present. Exit the grub shell. Open the GRUB configuration file, found at /boot/grub/menu.lst in your favorite text editor. Scroll down to the section you want to password protect and add the following line: password –-md5 $1$sEOFN1$dalP1fzlFCHD4saxlnNzM/ The GRUB configuration file will look something like this when you have added this line to the file:
Linux bootable partition config begins
title Linux (on /dev/hda6) root (hd0,5) kernel /boot/vmlinuz root=/dev/hda6 ro vga=
Section 3 – TCP/IP Stack Hardening
3.1 SYN Cookies and SYN Attack
SYN flood attacks take advantage of the half-open TCP connections that are created when one host sends a SYN packet to another host. Each time a host sends a SYN packet to another host the receiving host opens a TCP connection, replies with a SYN/ACK packet, and waits for the originating host to send an ACK packet to complete the three-way handshake. If the ACK packet never arrives from the originating host, then the receiving host is left with a half-open connection until a timeout occurs and the connection is closed. In a SYN flood attack, a large number (usually in the hundreds of thousands or even millions) of SYN packets are sent to the target host. This results in a large number of half-open connections being created on the target host that are never ACK’ed by the attacking host. This will cause the resources of the target host to greatly diminish and in some cases be used up entirely. This type of attack can be prevented by using a SYN cookie to keep track of SYN requests from remote hosts. This method is carried out as follows:
- The originating host sends a SYN packet to a remote host to set up a TCP connection.
- The receiving host stores the connection information in a file referred to as a SYN cookie.
- The receiving host sends the SYN cookie back to the originating host in the SYN/ACK packet.
- The originating host returns the SYN cookie in the ACK packet.
- The receiving host retrieves the SYN cookie and uses the information it contains to set up the TCP connection. By using this method, the three-way handshake of the TCP connection can be completed without a half-open connection being created on the receiving host. The benefit of using this method should be obvious. In a SYN flood attack, the attacker is simply trying to flood the bandwidth of a target host by bombarding it with SYN packets and causing it to open up a large number of half-open connections. Since the attacker is only concerned with sending SYN packets, it is highly unlikely that they will care about the SYN/ACK packets that are returned. As a result, the SYN/ACK packets are never ACK’ed by the attacker and no connections are ever created on the target host. The bandwidth of the target host remains unharmed, and the attacker is rendered powerless. (For a SYN flood attack anyway) *****REBOOT THE VIRTUAL MACHINE*** FROM THE LILO BOOT LOADER MENU SELECT THE HARDENED KERNEL ***DON’T FORGET TO SET YOUR IP*****
Then start apache and follow the directions below:
/etc/init.d/apache2 start
cd /opt/datapool
./datapool.sh –p 80 –x –d 127.0.0.1 –l T3 –r synful
Now on your RedHat WS 4.0 Host machine, open a web browser and navigate to your Gentoo’s IP address (http://gentoo.ip.goes.here/). Screenshot #3: Take a screenshot of your web browser timing out Cancel the DoS attack by datapool by pressing CTRL+C. Now we are going to do the same thing, however, this time utilize TCP SYN cookies in the kernel. Type the following::
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Run the same DoS attack as before. Now try again to open the web browser pointing to your Gentoo IP address. Screenshot #4: Take a screenshot of your web browser displaying the default Apache page
General Questions How long did it take you to complete this lab? Was it an appropriate length lab? What corrections and or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make corrections/suggestions. Note that part of your lab grade is what improvements you make to this lab. You may want to consider the topics below for section additions:
- Crypto Loop-back devices
- Gentoo Security Patches
- PAX
- Pam Wheel & Restricting su access to shared & system accounts For Appendixes you might want to consider the topics below:
- Bastille
- OpenWall
- SE Linux
- Any other topics that involve preventing attacks at the kernel level as opposed to network or application layer.
Turn-in Checklist
- Filled in Answer sheet.
- 4 Screenshots
- Laboratory improvements in detail.
