Testing the Locks: Validating Security in a Linux Environment

Is your security worth its salt? Try this assessment strategy to find out.

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.

1. Think Globally, Act Locally

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.

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix