Download Linux System Hardening: Understanding Linux Kernel and OS Vulnerabilities and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
Linux Kernel Hardening
Group # _________ Member Names: __________________________ __________________________ Date Assigned : Date Due : Last Edited : Lab authored by Justin Whitehead and Francisco Robles
Lab Goal
This lab will introduce you to Linux kernel and OS hardening.
Summary
In this lab you will be looking at several different ways intruders can hack your system, some already seen, and gather information about the file system, and then implement kernel level patches that raise the security level. We will reconsider stack attacks, investigate information gathered from /proc, SUID, Nmap, and compare results obtained through Ethereal.
Equipment
Students will need to sign out another drive(2 GB minimum) with the lab TA, and also sign out RedHat 8.0 installation CDs.
Background and Theory
Adapted from Sans.org (http://www.sans.org/rr/whitepapers/linux/1294.php): Like any other operating system, application level security flaws leave Linux vulnerable to a variety of malicious attacks. Over the years, many tools and techniques have been developed to “harden” Linux hosts in an attempt to mitigate the risk posed by buggy software. Removing or disabling unnecessary services and daemons, properly configuring services and changing vendor defaults, applying the appropriate security and bug patches, setting up backups, and configuring monitoring tools are all essential steps in building a secure system. Once an operating system has been set up and placed in production, daily monitoring of vendor notices and security forums is necessary to ensure that software is kept current with the latest security issues. Unfortunately, this method of administration is entirely reactionary and leaves hosts susceptible to compromise before vulnerabilities are publicly announced and fixes have been distributed. While many systems are compromised due to lack of proper maintenance (ie. patches not applied when they are made available), there is a strong need for methods to further reduce the risks associated with flawed software.
Keeping systems up to date with vendor patches will prevent the casual attacker from gaining access to a system, but will not always keep out an attacker that is targeting a system. In general, the initial goal of an attacker attempting to gain access to a Linux host (or any other UNIX variant) is to gain control of the superuser (aka. root) account. The traditional superuser account has unrestricted access to all components of the system. In most cases, there is little to no monitoring or auditing of actions taken by the superuser. Even when configured, an attacker with superuser privileges has the ability to disable these services, or cover their tracks by modifying log files. Once an attacker has control of the superuser account, even the most novice attacker will likely install rootkits and kernel modules that will allow them to continue to use the system for nefarious purposes without being easily noticed. Methods to prevent or mitigate the risk posed by a successful attack are generally applied on either the application level or the operating system level. A standard way to mitigate risk on the application level is by granting it the least amount of privilege required to perform its duties. While most applications do not need to run as a privileged user, there are some system level applications which require superuser privileges to perform certain tasks. In the past, many attacks against applications such as the Apache web server, the Berkeley Internet Name Domain (BIND) server, and the Sendmail mail server led to full system compromise as they required superuser privileges to function. In the 2.4 kernel series, enhancements to the kernel capabilities system makes it possible for applications to execute initially as root and then drop superuser privileges to run as a regular user. These enhancements are quite beneficial to overall system security, and today, most Linux distributions configure applications such as Apache, BIND, and Sendmail to run as unprivileged users by default. The millions of lines of source code that comprise the applications used on today's Linux systems make it nearly impossible to fully audit each application and remove all potential vulnerabilities. While still a critical component of a defense in-depth strategy, hardening techniques at the application level are typically inadequate as a means in protecting the rest of the system from flaws in the applications. Regardless of the time spent hardening applications, a vulnerability exploited in one application will often lead to a full system compromise. As the dependency upon network connectivity increases, the need to look at lower level methods for preventing successful attacks becomes apparent. [1] http://www.sans.org/rr/whitepapers/linux/1294.php
about running processes on the system. Indeed, most of the information is available to use through UNIX commands. Not only information about running processes can be gathered, but also information about the running kernel. Note that not all of the kernel files will be present in your system. It depends on the running kernel, kernel configuration and loaded modules. Important files are given below: /proc/cpuinfo – information about the CPU (model, cpu family etc.) /proc/devices – available devices /proc/interrupts – interrupt usage /proc/iomem – memory map (version 2.4) /proc/ioports – I/O (Input/Output) port usage /proc/kmsg – kernel messages /proc/meminfo – memory info /proc/modules – list of loaded modules /proc/mounts – list of mounted file systems /proc/net – network information (see below) /proc/sys – change the parameters within the kernel /proc/version – kernel and system version As mentioned above, you can use the command lsmod to view the list of loaded modules, which is equal to cat /proc/modules. /proc/net A variety of network information and data is available in the /proc/net directory. The more useful files available in the /proc/net sub-directory (short explanation how to use them) are given below: /proc/net/dev – information about the configured network interfaces. This file can be used by network administrators to view the status of the network. /proc/net/[tcp,udp,raw] – those three files shows information about open network sockets. The information is exported by the kernel. Note that those files are relevant for IPv4 only. /proc/net/route – routing table; available using the command route.
/tmp security The /tmp directory on a Linux system is used by many programs. It is used to create and manipulate temporary files that a program may need. Any program can write to /tmp which creates a few problems in securing the system. The most common /tmp exploit would simply be filling up the /tmp directory with so many files that it fills the file system. /tmp race A race condition is what happens when multiple processes access and manipulate one data file. There is a time frame between accessing and opening a file that a hacker can replace the file allowing manipulation of the program by the new file. Unsafe program code can allow a hacker to gain root priviledges on a system through winning a “race”. Beating the program to opening the file. A race can also occur when multiple programs access the same tmp file. If the program does not lock the file it is working on, other programs can access it and change it. If the file exists as a dangling symlink, its target will be created. This allows for arbitrary files to be created anywhere on a system. Race conditions can also lead to root access. improper use of the the function calls access(), chown(), chgrp(), chmod(), mktemp(), tempnam(), tmpfile(), and tmpnam() are the normal causes of a race condition. [2] http://corky.net/2600/computers/race-condition.shtml GRsecurity addresses these issues with symlink and hardlink restrictions to prevent /tmp races.Bastille handles /tmp security by creating safe tmp directories for each process accessing the tmp directory. SUID Set-User ID is a permissions system in unix. It allows users to run processes that have the priviledges of the owner of the process, which doesn’t have to be the person running the process. An example of an SUID program is “passwd” setting a user password is something someone with root permission has, but users want to be able to change their passwords on their own, so passwd is set to allow the user to do that. SUID can be fairly dangerous as exploiting SUID-root programs can lead to root access. Bastille linux allows you to deny access to SUID programs, you can specify which ones or let bastille block some of the most dangerous known ones. TCP Sequence Numbers A popular security patch is one that randomizes initial sequence numbers. Adding more randomness in the TCP stack will help prevent IP spoofing and session hi-jacking. We have already gone over IP spoofing and session hijacking in previous labs so you should be familiar with this. What randomizing Initial sequence numbers does is prevent spoofing programs from guessing, or finding out what the initial sequence number for the TCP handshake is thus preventing the session from being hijacked. GRSecurity adds a level of randomness to the TCP stack through sequence and port numbers.
1.0.3 Adding a user You will need to add some Users in order to test out some of the security patches features. Do the following in a terminal: #adduser user #passwd user Enter password: password 1.1 Pre-Hardening Tests We will be gathering data about the network settings of our system. We will also be running some exploits and recording the results of some shell commands. 1.1.1 NMap We will use nmap to see what ports are open on this machine. To start nmap, type # nmapfe & (The & sign makes it run in the background so you’re free to use the terminal.) Use nmap to scan your machine by entering in its host IP address for example 57.35.6.x+4. Select a SYN Stealth Scan using TCP&ICMP. Leave OS detection checked. Select scan. Save your results to a file to be turned in (Attachment #1) 1.1.2 Ethereal We want to capture some TCP packet data in order to compare it to randomized data later so lets open up ethereal. Go to the capture menu and select start. Now run a few ftp and telnet sessions. You may run them by using the following
telnet 127.0.0.
This will open a telnet connection to this system. You will also want to generate some ftp data:
ftp 127.0.0.
After you have captured a few sessions save your log to disk to be turned in, (Attachment #2)
1.1.3 Stack Attack For this exercise, we will reconsider the exploits of the Buffer Overflow lab, specifically the source file exploit1.c. Remember that we repeatedly copy the memory address of this code, overflowing the memory stack and overwriting the return address to our buffer location. Get the exploit1.c file from the lab directory and copy it to your home directory. Then run the following: gcc –o exploit1 exploit1.c ./exploit You should now have a shell
exit
Take a screen shot of the results of running the exploit (Screen Shot #1) 1.1.4 /proc The /proc directory contains sub-directories in it, which contain information about the system. All the sub-directories are read-only, since they are used to gather system information. The first class of sub-directories is “Process Specific”. As the name implies, they are used to gather information on specific processes. Each running process has a sub-directory under /proc, which is named after the PID (Process ID). Login as the user you created so that we can do equal comparisons later:
su user
We will now see what kind of information we can get from /proc.
ps –aux | grep “syslog”
or
ps –aux | grep “sshd”
You see that the second number from the left is the process id. Move into that directory:
cd /proc/PID
Q1.1.4 Through the ls and cat commands, what information can you gather about the machine and the running processes? Type exit to return to root. 1.1.5 SUID SUID programs can be used to gain root access. We want to know what SUID programs are running on this system so lets run a command to list them.
find / -user root –perm -4000 –print
2.0 grsecurity
Grsecurity is a suite of patches (distributed as a single patch file) for the Linux kernel that are an attempt to improve the security of a Linux system through detection, prevention, and containment strategies. 2.1 grsecurity Installation Standard installation requires you to use a non-tampered version of the kernel from www.kernel.org, patch it from www.grsecurity.net, and then configure the features that you wish to use, but an rpm is provided for a cleaner and much quick solution.
rpm –ivh kernel-2.4.22-0.2-rh9.i386.rpm
Here are some of the options that can be configured: · Buffer Overflow Protection: This enables or disables the various mechanisms for preventing execution of stack overflows. · Access Control Lists: This turns on or off the ACL system within grsecurity. · Filesystem protections: Protection for filesystems and additional chroot jail protection is in this section. · Kernel auditing: This turns on or off the kernel auditing functions. · Executable protections: This contains a grab bag of functions to protect running processes against certain types of intrusion. It includes features such as randomization of process IDs, fork bomb protection, and trusted path execution. · Network protections: Similar in functionality to the executable protections, this includes features such as randomization of IP IDs, TCP source ports (which normally start at 1024 and increment from there), and TTLs. · Sysctl support: This enables grsecurity's options to be turned on and off at boot time without having to recompile the kernel. · Miscellaneous enhancements: Currently, the only option in this section is to enforce BSD style naming of coredumps. Now let’s reboot from the new kernel, which you will see at the boot screen:
reboot
2.2 grsecurity Tests With grsecurity enabled, we are going to do the same exercises as before. 2.2.1 Stack Attack Now we’ll try the stack attack exploit again. Recompile it, then run the following:
gcc –o exploit1 exploit1.c
./exploit
Are you able to still perform this exploit? Can you think of a way around this? 2.2.2 /proc Login as the user you created:
su user
Again examine the /proc directory using similar commands:
ps –aux | grep “syslog”
or
ps –aux | grep “sshd”
Q2.2.2 What do you notice that is different with grsecurity installed?
3.0 Bastille-Linux
We will now install Bastille Linux. Bastille Linux is a OS hardening tool that has a graphical user interface. It contains many useful scripts and setting to automate the securing of your system. 3.0.1 Installation You can get the installation file at: www.bastillelinux.org First, be sure that you reboot back into your original image, as we don’t want grsecuirty and Bastille installed on the same image. Next, copy the following files from the lab directory to your home directory. Bastille-2.1.6-1.0.noarch.rpm – this is the main Bastille binary. http://prdownloads.sourceforge.net/bastille-linux/Bastille-2.1.6-1.0.noarch.rpm? download perl-Tk-800.023-9mdk.i (http://www.bastille-linux.org/perl-Tk-800.023-9mdk.i586.rpm) pwlib-1.3.3-5.i386.rpm (http://www.bastille-linux.org/pwlib-1.3.3-5.i386.rpm)
Read the description in the window. Using this version of xinetd will deny all connection attempts to important services like telnet, ftp, pop,imap, finger, and others. Using this along with a firewall will reduce the chances of people getting into your system through these insecure services. Select the yes option and hit ok, it will then step you through a number of screens about services you want to disable. Read the descriptions of why you should disable each service and answer yes and hit ok after reading the description. The program will step you through the following services: · Telnet. · FTP · Authorized Use – this will leave a message when users log in about the authorized use of the system, might be helpful in deterring crackers. It will ask you who should be in charge of the system also. 3.0.6 Disable User Tools Allowing users access to gcc can be dangerous. If a cracker compromises a system he can then compile and run his own tools right on your system, disabling gcc will stop some of these attacks. Select yes and hit ok. 3.0.7 ConfigureMiscPAM Read the description of this option. It does two things. Sets the number of core files to zero. This prevents attackers from filling up your file system with core files, which can be quite large. It also only allows individual users 150 processes each. This prevents Denial of service attacks where users are assigned certain services and attackers are attacking it. Hit yes and answer OK. It will also let you disable mounting CDROMS for users and only allow specified users to log into the console. 3.0.8 Logging This option lets you enable extra logging. It also lets you log to a remote site which is useful if your site is compromised and the attacker destroys the logs. Extra logs cannot hurt your system. You will be able to access some of the extra logs by hitting alt-F7 and alt-F8. Going through the menus it allows you top specify the IP of a remote log host and enter some other options. Miscellaneous Daemons This menu is useful for disabling Daemons that are not necessary for the running of your system(apmd is used for laptops!) Use the following answers for each screen. Apmd: yes GPM: no
3.0.9 Sendmail Your system does not always have to be running sendmail to send and receive email. This script will disable sendmail’s daemon mode and set up a script to run it every few minutes, to process outgoing mail, most programs will also run it during their execution. Select yes on this and hit ok. 3.0.10 Apache You can set up the apache webserver to only allow the user on the machine to access the webserver. This is good for people doing web development and people who want to serve html files through apache only to local users. Hit yes for the first options and no for all the other options. 3.0.11 Printing We want our users to be able to print so hit no at every screen. 3.0.12 TMPDIR Many programs use the /tmp directory in dangerous ways. Your tmp directory can fill up your file system if it is not monitored closely. This script sets TMP and TMPDIR for individual programs to different folders with specific quotas and sizes. It also has measures to prevent tmp racing which was discussed earlier. 3.0.13 Firewall Bastille comes with an automatic firewalls generation script, this may be helpful if you don’t want to configure your firewall manually, and it also has a lot of useful scripts in it for creating filters. It will step you through a number of screens. We will configure a basic firewall with some added options:
- Do you need the advanced networking options? No
- DNS Servers: just hit OK
- Public Interfaces: Note the interfaces and hit ok
- TCP services to audit: Note services OK
- UDP services to audit: Note services OK
- ICMP – ok
- TCP Service names or port numbers to allow on public interfaces: We only really want ssh so type in ssh or 22 in the blank and hit OK.
- UDP service names….:OK Force Passive Mode: No
- TCP Services to block: note the ports and hit OK.
- UDP Services to block: note the ports and hit OK
- ICMP allowed Types: the defaults will allow you to ping and traceroute other systems, leave these alone and hit OK.
- Enable source address verification? Hit yes and hit ok. This will verify IP addresses to avoid spoofing.
It didn’t work now, did it? Now try mounting a CDROM
mount /mnt/cdrom
Take a screen shot of all of the previous applications Screenshot #2. We also enabled apache to only work for a local host. Check the functioning of this by going to http://localhost, then go to another machine and try to access the website: http:// 57.35.6.x and see what happens. You should get a file not found on the localhost, but an access denied from the other computer. Questions: 3.1 Some of these options seem easily done by a knowledgeable sys admin, what are the advantages of having a program that does these things automatically? 3.2 Bastille gives an excellent explanation of why you should implement certain security measures, choose one of the measures we didn’t configure and configure it, explain what it does and why you would want to do that. 3.3 Compare and contrast Bastille and the GRsecurity patch. Which one is more secure and why? Which one was more effective? Post Hardening Tests This section will be very similar to the prehardening section but with a few differences, so please read carefully. 4.0.1 NMap We will use nmap to see what ports are open on this machine. To start nmap, type: # nmapfe & (The & sign makes it run in the background so you’re free to use the terminal.) Use nmap to scan your machine by entering in its host IP address for example 57.35.6.x+4. Select a SYN Stealth Scan using TCP&ICMP. Leave OS detection checked. Select scan. Save your results to a file to be turned in (Attachment #4)
4.0.2 Ethereal We want to capture some TCP packet data in order to compare it to randomized data later so lets open up ethereal. Since we disabled ftp and telnet we are going to use SSH to generate TCP packets. Type this into the console and type in the password.
Type in some commands and disconnect. Repeat this process a few times to get a good amount of initial sequence numbers. After you have captured a few sessions save your log to disk to be turned in as (Attachment #5) 4.0.3 Stack Attack For this exercise, we will reconsider the exploits of the Buffer Overflow lab, specifically the source file exploit1.c. Remember that we repeatedly copy the memory address of this code, overflowing the memory stack and overwriting the return address to our buffer location. Again use the exploit1.c file from the lab directory. Then run the following: gcc –o exploit1 exploit1.c ./exploit You should not get a shell. Take a screen shot of the results of running the exploit (Screen Shot #3) 4.0.4 /proc Login as the user you created:
su user
Again examine the /proc directory using similar commands:
ps –aux | grep “syslog”
or
ps –aux | grep “sshd”
Group Number: _________ Member Names: ___________________ _______________________
Answer Sheet
1.1.4. Through the ls and cat commands, what information can you gather about the machine and the running processes? 2.2.1. Are you able to still perform this exploit? Can you think of a way around this? 2.2.2. What do you notice that is different with grsecurity installed? 3.1. Some of these options seem easily done by a knowledgeable sys admin, what are the advantages of having a program that does these things automatically?
