Install Software Securely | Hardening Linux

For the majority of servers you administer, you will find that you may need additional software that is not provided on the installation disks. Finding software that you can trust is always a problem, especially when dealing with noncommercial software. With commercial software, there is the perception that you have some assurance that the software is safe and free from malicious code. This perception is somewhat based on corporate accountability that you get from having a company behind the software that can be held responsible for problems. The open source and free software community is often seen as a rogue element, but this is not entirely appropriate.

Open source software offers some advantages over its closed source counterparts primarily because of the availability of the core components of the software. Software is comprised of hundreds, thousands, or even millions of lines of instructions for the computer. When all of these lines are put together and run on the computer, they do something, change something, or produce output on the computer. Open source software distributes the complete internals of the software with the associated binaries. This means that the lines of instructions that form the program are widely available for peer review.

The ability to review the software allows you to make configuration changes to suit your needs, but more importantly it allows anyone to review the code for malicious or undesirable activities. Having the source code available doesn t guarantee that the software will be free from Trojan horses or other malware, but it does add one more safety net, especially on large, popular programs such as Apache or Snort where there is constant peer review. You shouldn t take the availability of the source code as a guarantee that the software is free from malware, though, as the source code and the compiled version may differ . For the best security, a competent programmer should review the code for any anomalies and then you should compile the software yourself on a trusted machine. This is not always feasible , so we will discuss other options throughout this section.

Closed source software does not provide the internal code or instructions that comprise the program itself. Closed source software is usually associated with commercial applications although not all commercial applications are closed source nor is all open source software noncommercial. Software with a company behind it does provide some accountability for the software, but you have to trust the integrity and coding practices of the company that created the software.

Commercial/closed source software is often distributed by the company that created the software, so we will only discuss open source software throughout this chapter.

Install Trusted Software from Vendors

When looking for software, one option is to obtain the software from the vendor. SUSE provides a large amount of software with the CDs provided in the installation disks allowing you to pull almost any type of software you want directly from the CD, while Red Hat provides a more convenient online installation option. Using the vendor-specific tools, with vendor-approved sources, you ensure that your system configuration remains in a supported state. This is an important consideration when determining what software to install and cannot be emphasized enough. If you have a production server that is crucial to your organization s objectives, and you have a support contract, you must weigh the advantages of voiding your support contract and the need for the new software.

Install Software with SUSE-Specific Tools

SUSE provides a software installation module with the YaST program that allows you to install software from the thousands of programs available on the distribution CD at any time while checking for dependencies. To start a graphical interface for installing software, type the following:

 /sbin/yast2 --install

At this point the install and remove software screen will appear as shown in Figure 4-10.

Figure 4-10: SUSE package manager

You have the option of selecting software provided with the distribution at this point with automatic dependency checking. The problem with this approach is that you will need to update your software immediately as discussed in Chapter 13, as your software may have patches available.

The next step in installing the software you need is to find the software. In Figure 4-10, you will see a Filter drop-down box. You can filter by

Selections (the default) Groups of software separated by preconfigured groups
Package groups Groups of software separated by type of software
Search Look for software by name or other advanced functions

These tools have very robust dependency checking and conflict resolution tools built into them, providing a much needed respite to the dependency nightmares that Linux administrators had to face in the past. Let s take a package grouping to show how to install a package using YaST2. A user needs to install Nmap onto the security server that is running SLES8. Use the search filter and type nmap and you will see the screen shown in Figure 4-11.

Figure 4-11: YaST2 search for Nmap

Select the checkbox next to the package name listing and click Accept in the bottom right corner. At this point you will be prompted for the first (and possibly only) CD to insert for the installation to continue, as shown in Figure 4-12.

Figure 4-12: YaST2 CD prompt

After the CD prompt, post-installation configuration scripts are run and the software install is complete. After you have installed the software, you will need to run YaST Online Update as discussed in Chapter 13 to use the latest, patched versions of the software.

Install Software with Red Hat “Specific Tools

Red Hat s up2date tool is an excellent example of a multipurpose installation and patching tool all in one. As with SUSE s tools, all dependencies will be resolved and the software will install seamlessly. The up2date tools does have one advantage over SUSE s installation program in that you do not have to initially patch your software after install to get the latest revision of the software. You are downloading directly from Red Hat s server and the package you download is the latest version available from Red Hat. To use Red Hat s installation tools, you will first need to determine the package name of the software. You can do this using the --show-all option, which shows all packages available for installation from the machine s Red Hat Network Channels. Use the command like this:

 up2date --show-all

After determining the name of the package you want to install, you only need to type the up2date command with the package name following. For Nmap, you would type

 up2date nmap

This gives you the latest, patched version of the software available directly from Red Hat.

Install Software from Trusted Sources

You may find one day that the distributions do not provide some functionality that you require. This can be a predicament in regard to future support as discussed earlier, but sometimes you have to install the software for business reasons. If you do take this path , always test your software on a nonproduction machine that is an exact duplicate of the server that the software is installed on. Run the new package in the test environment for as long as possible and try to emulate the load and processes on the server to determine if there will be any conflicts with other processes or programs. This is an important phase because you are treading on dangerous ground as your support contract may not be available after the software install. The fewer surprises that you encounter, the better. Any problems that arise during the test will not affect production services if careful planning is conducted before implementation.

Find Reputable Sources of Packages

There are many places on the Internet that provide software for use on your systems, but as with everything on the Internet, caveat emptor. There are a few well-established sites that provide RPMs or source packages for installation that are trustworthy. One thing to remember when downloading this software is that the software is made available on a public web site that may be trustworthy, but these sites only offer what the programmers make available. If the programmer of the project inserts malicious code into the software, the site that offers the download may not know about it until someone in the Linux community has reviewed the code. Also note that just because a project is well established and very popular, do not take for granted that the software is trustworthy, unless you receive it from your distribution vendor (who does a code review on software it releases). Here are some of the more popular sites for downloading new software (in rpm and source code format).

http://www. sourceforge .net/
http://www. freshmeat .net/
http://www. rpmfind .net/
http://www.rpmseek.com/
http://rpm. pbone .net/
Project s homepage (use your favorite search engine and search for the project name and the homepage keyword)

These sites usually offer great search capabilities as well as extended information on the rpm and packages you are looking for, allowing you to find alternatives to the packages you searched for. If you decide to use non-vendor released software on your system, you must consider the fact that the rigorous quality control processes that are conducted on the packages by the vendor might be absent from the package you are downloading. Developers not associated with a distribution often do not have the resources to test the quality and stability of the software they create. When downloading new software, always test it on a nonproduction machine to determine its stability on your platform, especially if it is non-vendor released.

Use MD5 to Determine Package Integrity

After you have located the files you want to download, you will want some assurance that the file you download is the same one that the project maintainer published. A common way to do this is for the software publisher to create an MD5 checksum to create a signature of sorts for the file. The MD5 algorithm is described in RFC 1321, which is available at http://www.ietf.org/rfc/rfc1321.txt. It takes the input provided and creates a 128-bit fingerprint of the input that is mathematically unlikely to match another input. Even if only one portion of the input is changed, the MD5 signature will be altered , making it very obvious that the file has changed. More and more security conscious software developers in the Linux community are providing MD5 signatures of their software, so try to locate the MD5 on the web site or FTP server. Some sites will post it on the same page as the download links, such as Tripwire.org s open source version. At http://www.tripwire.org/downloads/ you will notice signatures for the differing files, with the MD5 signature for tripwire-2.3-47.bin.tar.gz being d3d1d35ee10b59a0176ca6f754825ca1. Some sites will have an md5 extension on a file in the FTP or download directory, such as Snort has at http://www.snort.org/dl/. In this instance, you would view the MD5 file (for snort-2.1.2.tar.gz the MD5 file is snort-2.1.2.tar.gz.md5) and see that the MD5 for that file is f01ae080f1571fd3e8d282dcae51f528. There is no standard location for the md5sums, but most software developers will put it on the download page in some format.

Now that you know what the MD5 is, you can test it to make sure the files you downloaded are the same ones that the author made available. To do this you run a command called md5sum , which is available on most major distributions.

To determine if the file is the same as what is listed on the web site, download the file and then run the md5sum command with the filename as an argument. Let s take a hypothetical program called exampleprogram (filename exampleprogram.0.0.1.tar.gz). We find the MD5 signature on the exampleprogram project homepage in a file called exampleprogram.0.0.1.md5 to determine the signature of the file.

 md5sum exampleprogram.0.0.1.tar.gz

Figure 4-13 shows the contents of the exampleprogram.0.0.1.tar.gz.md5 file and then the results of the md5sum command against the file, showing the files match.

Figure 4-13: md5sum output

To show the dependability of MD5 signatures, we will take the exampleprogram.0.0.1.tar.gz file and untar and ungzip it. We will then add a very small file called badfile that contains one line of text to represent a Trojan horse program. Then the file will be tarred up and gzipped with the same filename. We can then run md5su m to see if the file s MD5 signature will change. Figure 4-14 shows the results of this exercise.

Figure 4-14: MD5 verification

You will notice that we double-check the output of the original file, which has an MD5 signature of df7b941c970b3a526332ba97b39f8c24, but after our small modification, we have a completely different md5sum of ce6a8633ac74a90d7ebc5fbbcd776eb5. Remember that this only verifies the md5sum against a listed md5sum (on a web page or in the file). If the web site had been compromised and an attacker changed the file and the MD5 shown, you would only be verifying a bad file. This is unlikely, but you must consider the source of the file.

Use GPG to Determine Package Integrity

More and more software developers in the open source community are utilizing gpg keys to digitally sign their keys.

Note	GPG (or Gnu Privacy Guard) is a free, GPL version of PGP. More information is available in Chapter 7 and at http://www.gnupg.org/.

To use the developer s keys to determine file validity, you will need to find the developer s public key, which is usually available on the download web site. For instance, Snort provides a public key link from their download site at http://www.snort.org/dl/. You will see a link in the text All official snort releases are signed with this pgp key. When you go to http://www.snort.org/public-key.html you will see the public key. Public keys will be enclosed in

 -----BEGIN PGP PUBLIC KEY BLOCK-----

and

 -----END PGP PUBLIC KEY BLOCK-----

A typical key looks like the following:

 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBECCsukRBAC7pgIt5oDsSCTcDwxNI7/ZF/gN1bja5wbBQoqybCvi2mbCFzWK yZNjTGPT2BCac6UO1Rf1c3b87hA1l11u4mvX62iglt/4EUu7slpYHJNOhnQqvBlD CMfM9epx+mQNjtoWS2IqO1Llj9gXsxdiW/c5CHc4A1sO3UOfsd8KMKARowCg0j2h bx4pezgOxswKEtZleNAM4bED/iZ+druCQa3KwjId+QgM9d2WYBbpfhiThcxtFl7p Ary09eZh5Cf92Az0vgom6QUfcEQ8Rl+c0rx3S0mADqbvJlJwsNs4sBx/P2m609NU yt5eRO2t5JGK5C8jQ5X6XLp4ImNQf6N7+J16l73m/5OC1r40ZG2Sn+Ap9ocmNRRR H+GUBACDG6BgY1Ojxu2OYYNaAnviNG+mE4PCGkZKn2bkf4xc8CZPNrjuhAEDLbK5 70w1o8sJOnI2bq4jOBWXxHuEVjMKW1xIn7y+aYO+Wj6wq7JmbXuopEehewNTdRxa MpfaceqVlhTcKdXYqm5FfvbwZUCscehI+6dN//fz8ro1wKM7c7QMRXhhbXBsZSBV c2VyiFkEExECABkFAkCCsukECwcDAgMVAgMDFgIBAh4BAheAAAoJEHAkFaQblXYi FE0An1y/BjkHktIvUitpWQi+eyUzUUixAKCa+DS0JIL29EUhSqHlnCTEdtSpL7kB DQRAgrLtEAQAr3/oUE2KpZEvTQ23Z0M1N06NAYJk7XCiutlK08+Xn//EzsOyCKJu tHj5gS+6tuVJ6BDOhOR7NxFOAgVCH53SFI0kwNXNoLLaFoF+UFmCocV/KhaaZCpg CwIKUnSd7F8hrTQsEsvxnb/UZNssjq4xhEVCnkFOZMH7E62S4ePFPX8AAwcEAI47 5SvRYL/jUOuDK9vpvChwMgOPI4cAZ0YteVRHaeErgLQjDOMgy6Lx/JgCb6KNmF5A Z9ZQ6g/7dPMKAa9+zUhX/xznn7F2HUYb3eguz20rM7g/APZbKQwdTsPwRGNKS/wm SasoVore2haVU6RJ/hkIaWAZZi0DgMF4RerpaZWfiEYEGBECAAYFAkCCsu0ACgkQ cCQVpBuVdiJONwCgr+NkvZub+/fpSnkxCeFXrgfTt6sAmgJHoJkIwAVY0VdJZaTS aH5mu6MB =WK8J -----END PGP PUBLIC KEY BLOCK-----

You will need to copy everything (including the two lines stating BEGIN and END) and put them into a file, which in our case is named exampleprogram.key. After you have done this, you can import the key using

 gpg --import  keyfile name

We pasted everything between and including

 -----BEGIN PGP PUBLIC KEY BLOCK-----

and

 -----END PGP PUBLIC KEY BLOCK-----

into a file called exampleprogram.key, so you would run the command like this:

 gpg --import exampleprogram.key

The results of this command are shown in Figure 4-15.

Figure 4-15: GPG import key

After you have imported the key, you need to locate the pgp signature file (usually with an .asc extension) and download that file in addition to the package files. You will need to download the signature file with the same versioning numbers as the file you are checking against. To verify the validity of the file you will run the following command:

 gpg --verify  signature_file.asc

For our exampleprogram.0.0.1 download, you would run the command

 gpg --verify exampleprogram.0.0.1.tar.gz.asc

This command returns the output shown in Figure 4-16 if the file is valid.

Figure 4-16: GPG good signature

The output of a bad signature would show Bad signature on the second line, in which case the file should not be installed. A bad signature means that the validity of the package cannot be verified and should not be trusted.

Note	Another way to check the validity of your file is to use rpm --checksig , although this is not the preferred method due to the added complexity of using the command.

Install Software with RPM

After you have verified the integrity of the software you downloaded, you need to install it. Most Linux software will have an available RPM package available. When using precompiled RPMs you are trusting the source of the RPM to not insert any malicious code into the package. There are a few ways to install RPM packages depending upon your needs. The available options for installation are shown in Table 4-1.

Table 4-1: RPM Options
Option	Description
-i (or --install )	Install an RPM
-U (or --upgrade )	Upgrade an RPM (will install the RPM whether or not there is a previous version on the machine)
-F (or --freshen )	Freshens an RPM (will only install if the package already existed on the machine)
-v	Provides easier to read output
-h	Shows hash marks indicating the progress of the installation

A common method for installing RPM packages is to use the -Uvh option, which shows the following:

 [root@linux2 root]# rpm -Uvh example-0.0.1.i386.rpm Preparing...              ########################################### [100%] 1:example                 ########################################### [100%]

Install Software from Source

Possibly the safest way to acquire software, but the most difficult to manage, would be to compile the source code yourself. This is if you have a competent programmer review the software for malicious entries or poor coding. Don t assume that just because the source is available, it has been reviewed by outside programmers. Many think that just because the source code to software is available, the software is automatically safe to use. Generally this is true, especially with more popular projects, but apathy is the enemy of security. In the majority of instances where you need to compile software, you need to have a compiler (such as gcc ) installed, which is generally not included in a default install. This is because a compiler can create a major security risk on a system. By installing a compiler on a production system, you have given an attacker a tool that will allow them to create custom-built programs for attacking systems as well as making it easier to get other malicious programs compiled and installed. Never install a compiler on a production system if it can be avoided. This is why you should have a test server and ideally a nonproduction machine for compiling programs.

With that said, you may find yourself needing to compile programs that you download for installation. There are many different ways to do this, but the majority of programs you download will be in in tar.gz format. To untar and ungzip those files, type

 tar -xzvf package_name

You now need to descend into the directory that the file created; you will generally find a file called README or INSTALL. Any special instructions pertaining to the program as well as any special installation instructions will be documented there. The next step generally pertains to all packages requiring compilation. These are the steps you must take (commands are run in the directory created by the tar command):

 ./configure make make install

At this point your program should be installed and ready to use.

One more note on installing software securely. Try to install the software as the user who requires the program or a non-root user. Some software requires that you install

it as the root user. Using a non-root user to install prevents any malicious software installation scripts from installing with root permissions, possibly creating major vulnerabilities. If you install software scripts as a non-root user, the script could only damage the system with the permissions of the user installing, which will prevent major damage as non-root users don t have full access rights to the system.