Testing the Locks: Validating Security in a Linux Environment

Many of you think you have a secure environment. You follow best practices. You check your logs regularly. Then, something gets through and although it may not wreak havoc, you wonder how it happened. A lot of shops practice passive security by putting security measures in place and assuming they work based on logs, dashboards or other output. This practice is inadequate for today's security landscape. Administrators must take an active approach to security to combat threats effectively. Active security can be as simple as verifying a password policy or as complex as running a full-blown penetration test. Whatever approach you choose, it always is a good idea to test the locks periodically with a security assessment to make sure they work. The locks are items such as the operating systems, network, applications and most important, security policies that exist in your environment. With regular security assessments, you can gain confidence that your security measures are keeping the bad guys out.

This article covers a security assessment in four parts. The sections are organized in reverse order of what an actual attack might look like. By the fourth section, I bring everything together and explain how such an attack might occur. I recommended that before proceeding with any of the following tests, you get the approval of upper management or the owner of the network and/or systems you will be testing. To minimize further any risk to a production network/system, the following tests should be performed after production hours if possible.

To assist in this assessment, I use a prebuilt VMware virtual machine (VM) with the BackTrack distribution on it (available from remote-exploit.org). BackTrack is a comprehensive security auditing and testing platform with many tools preconfigured and ready to use upon the first boot. All the scripts and applications presented here should be run as root. Only the custom script in the first section should be run locally on a target machine. All other tools should be run from the BackTrack VM.

Let's begin by checking the locks at the local level. The included script (Listing 1) profiles basic settings to identify and weed out common misconfigurations. It is by no means a catchall to validate all of your security measures. The script has been tested on Red Hat- and Debian-based systems, and as such, output may vary from system to system. You also may need to customize the script for your own systems to ensure functionality. All output is placed in the /tmp/seccheck/hostname directory, where hostname is your locally defined hostname.

#!/bin/bash

mycompname=$(hostname)
mydir=/tmp/seccheck/$mycompname
myoutput=$mydir/secoutput.txt
mkdir -p $mydir

sl()
{
  SECTION=$1
  echo >> $myoutput
  echo **********$SECTION********** >> $myoutput
  echo >> $myoutput
}

echo ^^^^^^^^^^ START OF OUTPUT ^^^^^^^^^^ > $myoutput

echo -n Is this a Red Hat \(r\) or a Debian based system \(d\)?
read REPLY

case "$REPLY" in
  'r')
    yum list updates > $mydir/patchcheck.txt
    sl "Service Runlevels";chkconfig --list >> $myoutput
    sl "Auth Messages";cat /var/log/secure|grep failure >> $myoutput
    ;;
  'd')
    apt-get update
    apt-get -qs upgrade > $mydir/patchcheck.txt
    sl "Startup Services";ls -l /etc/rc2.d >> $myoutput
    sl "Auth Messages";cat /var/log/auth.log|grep failure >> $myoutput
    ;;
esac

sl "lastb Results";lastb >> $myoutput
sl "inetd check"; file -f /etc/inetd.conf && \
    echo "Are you using inetd? You should be using xinetd instead." \
        >> $myoutput
sl "xinetd Services";ls -l /etc/xinetd.d >> $myoutput
sl "hosts.allow";cat /etc/hosts.allow |grep -v "#" >> $myoutput
sl "hosts.deny";cat /etc/hosts.deny |grep -v "#"  >> $myoutput
sl "iptables output";iptables --list >> $myoutput
sl "SUID Files";find / -perm -4000 -print >> $myoutput
sl "SGID Folders";find / -perm -2000 -print >> $myoutput
sl "SUDoers";cat /etc/sudoers|grep "="|grep -v "#" >> $myoutput

echo -n "Do you want to capture Password Files"
echo -n " for an offline Password Check (y or n?)"?
read REPLY2

if [ $REPLY2 = "y" ]; then
     cp /etc/passwd /tmp/seccheck/$mycompname
     cp /etc/shadow /tmp/seccheck/$mycompname
     echo Your Password and Shadow folders have been copied to
/tmp/secheck/$mycompname
else exit
fi

echo vvvvvvvvvv END OF OUTPUT vvvvvvvvvv >> $myoutput

Rather than go line by line, let's look at the output of the script. The first prompt identifies the base distribution and checks for needed patches and then outputs this information to /tmp/seccheck/hostname/patchcheck.txt. After patch-checking, the main output file is created as /tmp/seccheck/hostname/secoutput.txt. The first section of this file lists the local services that run at startup. With this information, you can view and disable any unnecessary services. This section is followed by a listing of failed authentication messages along with the results of the lastb command (Figure 1). From these two sections, you quickly can determine whether the machine has been accessed by an unauthorized user.

Figure 1. Some Output from the Local Script

Next, the script checks whether the inetd dæmon is in use. Most modern distributions no longer use the inetd super server, but some legacy systems still do. If possible, you should convert those servers/services to xinetd. xinetd-enabled services are listed in the section that follows. Both super-servers can provide host-based access control to specific services using TCP Wrappers. The access controls for TCP Wrappers are stored in the hosts.allow and hosts.deny files. The contents of these files are output after the xinetd section. If you use TCP Wrappers, there should be an entry in your hosts.deny that reads ALL:ALL to deny hosts that aren't allowed access explicitly. Local firewall (if used) rules are listed next.

Next, the script lists any SUID/SGID files and directories found on the machine. These files should be identified and their access verified, as they often are taken advantage of by rootkits. After that, the script concatenates a listing of the /etc/sudoers file. Users and groups found in the sudoers file can run as a super user (root) or any other user defined in the file. You should take stock of these users and verify they need sudo access.

Other good utilities/commands that could be added to this script, but have been omitted due to space considerations, are ps, top, mount, route, history, find / -perm 777 and testparm (Samba). If you use SELinux, you can run the getsebool -a command for confirmation of policy enforcement.

At the end of the script, you are prompted to copy the machine's local password and shadow files to the /tmp/seccheck directory, so you can transport them to the VM and perform a brute-force crack using John the Ripper later. After the script has completed, copy or burn the /tmp/seccheck directory to removable media for analysis on the BackTrack VM. Boot the VM, and log in with root and use “toor” as the password. After logging in, type startx to launch KDE. Copy the seccheck folder containing the password and shadow files from the removable media to the VM.

With the files local to the VM, let's run a brute-force password crack to test our password policies. Brute-forcing can be time consuming. You can speed the operation with the use of word lists, some of which are available from the john Web site. To start the crack with a basic brute-force, open a terminal on the VM and run the following command:

/usr/local/john/unshadow /pathtopasswdfile/passwd 
 ↪/pathtoshadowfile/shadow > password.txt  

This command combines the two files into the password.txt into a traditional UNIX-style password file. Next, run the following command from the terminal in your VM:

john password.txt

Figure 2. Hashes and Their Plain-Text Passwords Cracked by john on BackTrack

john will output its results to the terminal and also write to /usr/local/john/john.pot (Figure 2). One really nice feature of john is the ability to restart a terminated crack. If you need to terminate john for any reason, use Ctrl-C to end it. To resume it, type:

john --restore

Within a few minutes, you should see any simple passwords displayed. More complex passwords will take longer, based on various factors, such as complexity, system performance and the use of word lists.

Regardless of when you run john, you should review the secoutput.txt file thoroughly, document its findings and remedy any that fall short of our defined security policies.