11.5 Unix Hardening

 <  Day Day Up  >  

Is Unix secure?

The question is unanswerable. You might as well ask, "Is Windows secure?" The real question is, "Can Unix be made relatively secure by applying a clearly defined sequence of steps that always produces the same result and can be automated and applied to existing systems?" The answer to this is definitely "Yes." But can a typical network administrator, without formal security training, achieve such security? The answer to this question is "Yes" as well, but it does take a measure of perseverance .

Unfortunately , every time you acquire a Unix system it will have to be "made secure," since vendors chronically neglect to integrate tight security when they ship their systems. The reason is simple: security does not sell (at least, not yet), whereas bells and whistles do. Experience with Microsoft shows that features sell. Security, on the other hand, rarely sells, even in times when it is brought to people's attention by catastrophic accidents and other events. In addition, very few users call vendors asking how to turn off a specific feature, rather than how to enable it. Thus, shipping a system with everything "on" was the default choice of many Unix vendors for years . And few people, even Unix users, actually make a conscious effort to secure their systems. Thus, until recently vendors have simply sold what most customers wanted. Even if a preponderance of customers suddenly starts to demand security, system hardening will still be needed. Various installations have vastly different security requirements, even though they all use the same Unix system from the same vendor. As a result, the amount of system and application hardening that you should apply to a given system will vary.

Unix can be made secure. Years of history have proven this to be true. To what degree can Unix be made secure? For an objective (if somewhat debatable) classification of security rating, we turn to the traditional "Orange Book." Note that the original TCSEC [5] requirements have evolved into the Common Criteria. The old TCSEC ratings went from A1 (the most secure) to B3, B2, B1, C2, C1, and D (the least secure). For example, versions of Unix-like systems (such as those made by Wang Government Services) are known to achieve a B3 rating. Most commercially used systems are at either a D or a C2. Few of the commonly used products ever attain a B1 rating. Thus, Unix can be made very secure, but it takes work. The tightest security is only possible by writing most of the system code from scratch using a verified security design. Such systems are beyond the scope of this book; we instead focus on common installations.

[5] Trusted Computer System Evaluation Criteria is an old (1985) document defining standards for computer system security, published by the National Computer Security Center.

The Common Criteria definitions of security are generally not used in business. Nevertheless, traditional Unix can be made secure for many business purposes. For example, Unix-based web servers are known to operate in hostile environments for years with no compromise. What makes those machines stay alive ? Expensive firewalls and intrusion prevention systems? No ”their longevity is achieved through a hardened system and a few common-sense security practices.

Ensconced within firewalls and screening routers, organizations sometimes choose to create what has been described as a "hard shell with a soft chewy center." This means that once the protected perimeter (such as the firewall) is breached, the system is ripe for the picking by intruders ”the opposite of "defense in depth." This strategy holds only until a compromise occurs, since the internal systems are usually easy to violate . Hardening comes to the rescue. If a network perimeter is breached, hardened systems have a much higher chance of surviving an attack. Hardening the system, or configuring and upgrading the system in order to increase its security level and to make it harder to penetrate , is considered the last line of defense.

Imagine you have deployed a system for remote shell access by untrusted users. (If you say it should never be done, you haven't been to a major university lately.) In this case, network access controls are useless and administrative controls are weakened (it's difficult to fire somebody for violating a policy in this situation). Hardening is the only security measure on which you can rely.

Hardening is required because various operating system components and application software have bugs that undermine the security of your system. Moreover, many people believe that software will always have bugs. Bugs make systems exploitable by malicious hackers and insiders. Another reason to harden your systems is in order to correct insecure defaults shipped by system vendors. Hardening minimizes the number of points at which an attacker can enter a system and discourages application exploits.

11.5.1 Hardening Areas

Every Unix system and application has areas that can and must be hardened before the computer is connected to a network. We say network and not the Internet, since insiders from the local area network (LAN) can initiate attacks as well. Checking installed software

Before we start to harden, we have to first limit the amount of software installed on the Unix system, with a particular focus on network-aware software such as network daemons. It is a good idea to lock down a system with the minimum necessary features installed. The principle is simple: just uninstall what you or your users do not use.

It is understandable that some users might be tempted to just install everything and then use whatever they want. Please fight this urge, since it can put your system at risk from random scanning by malicious hackers. Even though you might not have anything valuable on the system, your machine could be used as a base for launching hacking attempts, password cracking efforts, or denial-of-service (DoS) attacks.

Let's start with network services. If you do not use the X Window system (for example, on a web or email server), remove all X- related software. The detailed uninstallation procedure varies greatly between Unix vendors. For example, Red Hat Linux and several other Linux vendors use the RPM (Red Hat Package Manager) system, which allows easy software removal. Solaris uses another packaging tool that also enables clean installs and removals. Patching the system

With any luck, your system vendor has taken some steps to make your systems secure by providing critical security updates. Go to your Unix vendor's web site and look for update packages for your OS version. Upgrade to the latest software version available from your vendor. It's wise to take this step after an initial system installation from CD-ROMs or other media. However, the process becomes infinitely more useful if it's repeated frequently: new bugs are discovered daily, and vendors usually make patches available on their web sites (some faster than others). If your vendor has any sort of automated patch notification system, sign up for it. Doing so reduces the cost of keeping informed about security developments.

Sometimes updates break the functionality of existing applications. Try all vendor updates on a test system before applying them to your production systems.

Table 11-2 lists the web sites of some popular Unix vendors.

Table 11-2. Some Unix vendors' web sites

Unix version


Web site

Solaris, SunOS









Red Hat Linux

Red Hat











Tru64 Unix





http://www.sgi.com Filesystem permissions

Now, let's maximize the efficiency of the most basic Unix security control: filesystem permissions . Many Unix vendors ship systems with excessive permissions on many files and directories. Infamous examples include logfiles writable for everyone and an /etc/shadow file (which contains encrypted passwords likely vulnerable to brute force attacks) readable for everyone. Both of these examples have actually occurred in the past. The Unix filesystem is a complicated structure, and knowing correct permissions is not trivial. This particular task is better left for a hardening script.

While it is unusual for modern Unix installations to be deployed with major filesystem permission blunders, it makes sense to check several important places. This is especially true if you are hardening a running system that was installed a long time ago by other admins. Consider the following:

  1. No file in /etc and /usr should be writable for everyone.

  2. Logfiles in /var/log or /var/adm should not be readable for everyone.

  3. /tmp should have proper permissions (discussed below). Also, check /var/tmp and /usr/tmp , which are sometimes used for the same purpose.

  4. Look for files to which anybody on the system can write using the following:

     find / -perm -2 ! -type l -ls 

    Evaluate whether these loose permissions are really justified.

Another important issue in hardening filesystems is handling Set User ID (SUID) and Set Group ID (SGID) binaries. Many of the programs that are shipped with the SUID bit and are owned by the root user contain bugs that can lead to a root-level compromise in various attacks (e.g., buffer overflows, as described in Chapter 5). Even programs that are not SUID "root" but rather SGID "mail" or "man" groups can be abused, leading to system compromise (such as reading root mail).

To locate all SUID binaries, issue the following command:

 find / -type f \( -perm -04000 -o -perm -02000 \) 

This produces a list of all SUID binaries on the system. For example:

 find / -type f \( -perm -04000 -o -perm -02000 \) 

For platforms other than Linux (those not running the GNU version of find), another option, -print , needs to be added at the end. Now, evaluate the list and remove the SUID bit from selected files by giving the command chmod a-s filename . For example:

 #  ls -l  /tmp/bash  -rwsr-sr-x    1 root     root       512540 Jan 23 23:55 /tmp/bash #  chmod a-s /tmp/bash  #  ls -l  /tmp/bash  -rwxr-xr-x    1 root     root       512540 Jan 23 23:55 /tmp/bash 

Since a typical system has many SUID and SGID programs, the task of determining the location of the SUID/SGID bit might be difficult. It is easier if you do not install excessive software (recommended above). Many Unix hardening tools automate the task by using their own criteria for SUID and SGID bit removal.

The temporary directory (usually /tmp ) on Unix systems is another well-known source of risk. Many programs need write permission for the /tmp directory. Typical /tmp permissions may look as follows :

 drwxrwxrwt    4 root     root         1024 Dec 28 00:03 tmp 

These permissions can be tightened; however, doing so might break some functionality. For example, X Windows does function without a writable /tmp . Some people recommend not eliminating a global /tmp directory; rather, they prefer user-specific tmp directories in the home directories. Many applications read the name of the temporary directory from the environment variable TMPDIR, while others, mostly old programs, unfortunately will try to use /tmp no matter what. Login security

System login security is a primary bastion protecting your Unix system. How do you make it more defensible? Everyone has to enter a password for console login, but how secure are those passwords? If your Unix variant permits it, you should set rules for minimum password complexity and expiration period. In addition, a few Unix systems provide a facility to record password history, in order to prevent users from alternating between two passwords.

There is no standard way to enforce password complexity. There are several /bin/passwd (the program used to change users' passwords) replacement programs that check passwords against a database of known bad passwords, such as dictionary words, usernames, or some modification of them. For some Unix versions, there are system libraries ”such as cracklib ”that /bin/passwd calls to verify the strength of chosen passwords. This step is very important: if your passwords are well encrypted but your users tend to use such infamous passwords as "password", "root", or someone's first name, your security is nonexistent.

To keep a password history, use a third-party tool such as npasswd, which is the excellent replacement for the standard Unix passwd command. npasswd adds many security enhancements, including complexity checks, dictionary checks, and password history support.

As we discussed previously, shadow passwords are standard on most modern Unix systems. If you use an older system and for some reason cannot upgrade, convert your regular world-readable /etc/passwds file to a shadowed version, if your Unix supports it. Shadow Password Suite can convert regular Unix passwords to shadow format. Install the software using your vendor-supplied version. Shadow Password Suite replaces many important system files (such as login, passwd, newgrp, chfn, chsh, and id); thus, using the vendor-approved version is best. Next, the pwconv command converts the /etc/passwd file and creates /etc/shadow for all existing user accounts. In Linux, you might want to make use of some of the excellent documentation available online, such as the "Linux Shadow Password HOWTO." All Linux HOWTOs are posted at http://www.linuxdoc.org. In order to further increase your defenses, MD5- hashed passwords are recommended. We covered the advantages of MD5 passwords previously in this chapter. If your system supports MD5 passwords, you should convert to this format.

Your system might come preinstalled with more system accounts than you could ever use. You have regular user accounts belonging to humans , a root account with administrative privileges, and several system accounts (news, nobody, sync, and many others), which vary for different Unix flavors. Removing these system accounts serves the same purpose as removing extra software: it reduces the number of entry points and makes it easier to harden the system. User security

After you have made passwords more difficult to access (by shadowing them) and to crack (by enabling MD5 passwords), it is time to clamp down on your users. This might sound cruel , but that's part of the fun of being a Unix administrator, and has been for decades. In addition, according to cybercrime statistics from the Computer Security Institute and Federal Bureau of Investigation CSI/FBI Cybercrime Survey, insiders ”such as your legitimate users, contractors, or people who simply have access to the computer equipment ”commit most successful computer crimes. Securing your system from your own users is actually more important than securing against outside network intruders. The idea is to follow a "need-to-know" or "need-to-do" principle. For example, if ordinary users are not supposed to perform system administrator duties (hopefully they are not), they should not be able to run the su command. A vendor often implements this policy by creating a special "wheel" group of users who can access system administration commands. If it is not implemented on your system, the following directions show you how to do it:

  1. Create a group called "wheel" by adding it to the /etc/group file (follow the format of the file).

  2. Add trusted users to the group by further editing the /etc/group file.

  3. Find the binaries you want accessible only to members of the group: /bin/su is the main candidate.

  4. Execute the following commands:

     #  /bin/chgrp wheel /bin/su  #  /bin/chmod 4750 /bin/su  
  5. Check the resulting permissions on /bin/su by issuing an ls -l command. You should see the following:

     -rwsr-x---    1 root     wheel       14184 Jul 12  2000 su 

No users apart from those listed in /etc/group as members of "wheel" will be able to change their user IDs or to become the superuser (root). If they attempt to execute the su command, they will see something to the effect of the following:

 bash: /bin/su: Permission denied 

Linux also allows you to restrict the properties of user processes and files by size and other attributes, using Pluggable Authentication Module (PAM) resource limits. The standard Unix method for restricting resources is a quota facility. It is implemented somewhat differently in various Unix flavors, but the basic functionality is the same. Two limits for filesystem usage are imposed upon the user: a hard limit and a soft limit. If the user exceeds the soft limit, he is issued a warning; if he exceeds the hard limit, the disk write is blocked. In addition, a quota facility can impose limits upon the number of files. In order to enable quotas, you have to mount the partition with quota support. On Solaris, this is achieved by adding "rq" to the mount options (usually located in the /etc/fstab or /etc/vfstab configuration file), while on Linux the option is "quota". An excerpt from the Solaris /etc/vfstab file with quota support is shown below:

 #device         device          mount           FS      fsck    mount   mount #to mount       to fsck         point           type    pass    at boot options /dev/vx/dsk/Hme1   /dev/vx/rdsk/Hme1  /export/home1   ufs 3   yes  logging,rq /dev/vx/dsk/Hme2   /dev/vx/rdsk/Hme2  /export/home2   ufs 3   yes  logging,rq 

There is one more trick to make user behavior safer. We do not want users performing passwordless authentication for their Secure Shell access, unless authorized. Passwordless authentication seems more secure, but it represents a severe security hole if a hacker compromises the account (and gains access to many other systems without a password, as in the long-gone days of rsh and rlogin). Of course, it is possible to set the local password, locking the private key, but this step introduces the same password problem. Often, a system administrator locks an account by changing the password string to "*" or some other string that does not correspond to any unencrypted password. The admin thinks that the user is then not able to log in, either from the console or remotely. However, nothing is further from the truth. Using SSH, a user can allow RSA key authenticated logins. By default, the Secure Shell daemon does not check the password file at all. Thus, the user gains backdoor access to the system without installing any new software; meanwhile, the administrator thinks the user has been locked out of the system. To prevent this from happening, remove the user's ability to create certain files. Depending upon the SSH version, the commands are as follows:

 #  cd ~user  #  cd .ssh  #  touch authorized_keys  #  chown root.root authorized_keys  # c  hmod 000 authorized_keys  

or in the case of SSH2:

 #  cd ~user  #  cd .ssh2  #  touch authorization  #  chown root.root authorization  #  chmod 000 authorization  

This prevents the user from setting up passwordless SSH access. Note that we are not locking the account, but rather preventing the use of passwordless SSH. We cover Secure Shell attacks in greater depth later in this chapter. Physical security

What if an attacker has access to your system console? That's impossible ”you have a secure environment, protected by access cards, armed guards , and alarms ”or so it seems. What about that sketchy junior system administrator you just hired without a background check? Or the shifty new janitor with a 100-MB Zip disk in his pocket, ready to copy your secret data? As we described in the previous section, attackers are often insiders. It is often said that all bets are off if the attacker has access to your hardware, since she can just clone the entire system for further analysis. Although this is strictly correct, you can make local attacks more difficult and complicated.

If you are using a system based on an Intel x86 processor, it usually has a BIOS password to lock the BIOS settings. This option helps prevent the attacker from booting with her own boot media, such as a DOS floppy with tools for your Linux system or a Linux disk for your BSD system. Admittedly, this protection is not absolute: if an attacker already has some level of access to your system, she can erase the BIOS password. Sun Solaris SPARC hardware also has a ROM password protection similar to that of an Intel-based BIOS. On the other hand, recovering from a lost BIOS password might be painful (and in rare cases might even involve sending the system to the manufacturer). Some Unix variants (such as Linux and Solaris) allow you to set the boot password to prevent unauthorized booting.

As always, adding depth to your defenses is the goal. For instance, if your system boot loader (such as Linux's LILO) allows for password-protecting the boot sequence, set this up as well. It prevents the attacker from modifying the system boot sequence. Network security

Unix network defense is covered separately, since it is a large realm with many implications. Briefly , however, be sure to strengthen Unix network access controls during system hardening. TCP wrappers, discussed earlier, can help protect compatible services. While implementing TCP wrapper protection, inspect the Internet superserver configuration file ( /etc/inetd.conf ) for services that are not used. (See above for more details on this file format.) Only those programs you actually use should be present and listening to the network. Ideally, a host-based firewall similar to Windows's personal firewall programs should guard the stack. Many Unix variants, such as Linux, BSD, and Solaris, have built-in packet filtering that can be used for this purpose. Daemon security

Now that you have hardened Unix itself, consider application hardening. We cannot cover all possible Unix applications in this book; we can't even cover all the hardening tips for major network programs. For example, securing Apache is beyond the scope of this book, since the software is very flexible and complicated.

In general, if you cannot remove an application completely, you have to tighten it down. Network daemons such as BIND (DNS), sendmail (email), httpd (web server), IMAP, or a POP3 server are a portcullis into your Unix kingdom. We briefly review some basic Unix daemon-hardening tips.


Do not spend time hardening telnet; instead, remove it. Secure Shell provides an excellent replacement for telnet, with more features (including file transfer support) and dramatically increased security. Although " kerberized " (i.e., authenticated through a Kerberos system), telnet is not vulnerable to sniffing; unlike SSH, it requires deploying and maintaining the complete Kerberos infrastructure.


FTP is a risk primarily due to its use of plain-text passwords and file contents transmitted over the Net; if you can do without it, remove it and use Secure Copy (part of Secure Shell) instead. If you have to use FTP, TCP wrappers can control access, as described previously. If your version of Unix uses /etc/inetd.conf , it should include a line similar to the following:

 ftpd stream tcp    nowait root    /usr/sbin/tcpd    in.ftpd 

This makes your system check the /etc/ hosts .allow and /etc/hosts.deny files before allowing logins via FTP.

Anonymous FTP is a risk, since you cannot assign accountability to users. Allowing write access to your disk to anonymous users is a grave risk and should be avoided at all costs. Try connecting to your system via FTP using the username "anonymous" or "ftp" with any password: if it works, you have anonymous FTP. Disable it by consulting your FTP daemon's configuration files. There is no standard FTP daemon; thus, the details are left for the reader to investigate. If you have many FTP users on your system, consider using an /etc/ftpusers file. Only usernames added to the file are allowed logins via FTP.


Apache (http://www.apache.org) is the most widely known web server in the world. If you use Unix for serving web pages, most likely you use Apache. (It also runs flawlessly on Windows and is gaining market share on that platform.) Securing Apache is a large project, due to its complexity and its modular structure. However, the defaults are usually good enough for sites that do not have stringent requirements. Also, remember that most Unix web servers are compromised via some third-party software (such as a CGI script), rather than a bug in a web server itself. Carefully inspect all CGI scripts and other executable content that you place on your web server.


Bastille (a hardening script for Linux) suggests using the DNS daemon in a chroot environment. That means the daemon runs in its own virtual filesystem compartment . A Unix DNS server most likely uses BIND software to handle DNS. BIND has a vast code base and a terrible security history, including the notoriety of being the most widely exploited service in 1999. Thus, relegating BIND to a chroot jail makes sense. The configuration is ubiquitous. In addition, another important step is to stop information from leaking through BIND. Disable DNS zone transfers to unauthorized parties, since they can disclose your network structure to attackers.


Securing mail servers is another vast field. The most commonly used Unix mail server is sendmail. It has had a long history of security problems (unlike qmail), but it has stabilized. More importantly, sendmail needs to be secured from spam, or unsolicited commercial email could be sent through your server. sendmail should deny mail relaying ”i.e., sending email from third parties to others not inside your organization via your mail server. In order to increase your security level even more, sendmail can be compiled with TCP wrapper support. In this case, you can completely block access to your mail server from certain hosts or domains. sendmail is also a source of information leaks: an attacker can use SMTP commands such as EXPN and VRFY to map your existing users. Remove these commands in your configuration files using the following configuration option in your sendmail.cf file:

 O PrivacyOptions=noexpn,novrfy 


Secure Shell communication is secure from eavesdropping, but the daemon itself might be providing a hole into your network. All versions of SSH (SSH1, SSH2, and openSSH) have a checkered security history. Run SSH with TCP wrappers (the support is usually compiled in via a libwrap library) or use its own access control facility (implemented in a file such as /etc/ssh/sshd_config ). Several SSH features are dangerous and should be disabled. Nowadays, they are usually off by default, but checking never hurts: make sure there are no root logins, no null passwords, and no rsh fallback. For more information on Secure Shell, look at Section 11.7. System logging and accounting

Improving logging and system accounting does not make your system harder to attack, but it makes security accidents easier to investigate. Unix logging and BSD-style accounting were described earlier in this chapter. While performing system hardening, you should confirm that logging is enabled. This is done by checking that the /etc/syslog.conf file exists and that it contains sensible information. Also, check to make sure the syslog daemon is running. To perform the last check, issue the following commands for Linux:

 %  ps -ax  grep syslog  350 ?        S     41:47 syslogd -m 0 

Issue these commands for Solaris:

 %  ps -el  grep syslog  8 S  0   497  1  0  41 20 7551cea8  475 7210eab2 ?      11:22 syslogd 

If they produce output similar to that shown above, the syslog daemon is indeed running. Also, saving logs to a remote server is highly recommended for security. In Linux, that requires changing the syslog configuration by enabling remote log reception (using the command-line option -r ).

11.5.2 Automated Hardening via Scripts

Several scripts and programs exist to harden Unix systems. These scripts range from simple post-installation checks to full-blown programs with graphic interfaces that verify and secure many aspects of your system. Here, we discuss several of the popular tools for Unix (namely, Linux and Solaris). Linux Bastille

Bastille is a program to harden Red Hat and Mandrake Linux, with support for Debian, SuSE, TurboLinux, and HP-UX in various stages of development. Bastille is designed to not only comprehensively secure the Linux system but also to educate the administrator on many issues that may arise during the operation of a Linux server, such as daemon security and network access controls. The project coordinators combined their own Linux expertise with many other security information sources. Originally, Bastille was designed to run only on a freshly installed system, but it was later upgraded to handle systems with changes to the default configuration files. To use the program, download the RPM packages (for Red Hat or Mandrake) or source code (for other supported systems) from http://www.bastille-linux.org and install them. Then run the program as root, answer the questions asked by the GUI, and reboot your computer. Figure 11-1 shows a Bastille screen.

Figure 11-1. An example Bastille screen

As you can see on the left, there are areas of system hardening that Bastille handles. They include filesystem permissions, user account security, system boot security, tool disabling, PAM configuration (a Linux-specific security mechanism described later), system logging, and other features. On the right, there are user controls for enabling specific security enhancements. In addition, Bastille can enable a host-based firewall on your machine to further protect it from network attacks.

Bastille is included in Mandrake and there's a plan to include it in the standard Red Hat distribution at the time of this writing. With vendor support, Bastille might become a standard Linux hardening tool, used by a wide audience of Linux server and desktop users.

Internally, Bastille is a set of Perl scripts that use the Perl Tk (a popular graphical toolkit) interface to create a GUI for the X Window system. The Perl scripts parse various Linux configuration files and then implement changes as approved by the user. This architecture allows users to write Bastille modules to implement custom security improvements. Kernel-level hardening

If you have access to your Unix source code, you have the ability to make your system much more secure. In an extreme scenario, you could even replace the entire operating system with another one using a verified security design (although it would no longer be called Unix, due to its different architecture). A more realistic approach is to tweak the system kernel (the most important component of any Unix system) and system utilities to produce more stringent, refined, and flexible security controls. Thus, in kernel-level hardening we increase the security of a standard Unix system by making slight (or sometimes more drastic) adjustments to the system kernel.

Unix was born as an open system based on universal standards and not chained to a single vendor. In fact, even though your flavor might not be released under an open source license (like Linux, FreeBSD, OpenBSD, or NetBSD), getting access to the source code might be possible under a special license agreement, as is the case with Solaris. However, it is much more likely that users of open source systems will perform kernel hardening, because these systems have better kernel documentation, more active development cycles, and superior support for tricky programming issues. (To verify this, simply join a kernel development mailing list and ask a question.) We focus on Linux kernel hardening in this section.

The simplest kernel hardening procedure is disabling support for modular kernels . To begin with, most modern Unix systems run a modular kernel. That is, a user is allowed to insert specially written programs (called kernel modules) into the running kernel and have them execute in kernel space. These modules usually handle new hardware or support filesystems and other tasks . However, malicious and stealth kernel modules are becoming the tool of choice for attackers trying to retain access to a hacked system. After an attacker gains access, he might choose to install a rootkit (usually a set of Trojaned programs that allow backdoor access to the system, as described in Chapter 10). However, system administrators using integrity-checking tools such as Tripwire or chkrootkit can sometimes discover rootkits (unless they use more advanced kernel-hiding techniques). Thus, to hide from an integrity check, malicious hackers might choose a kernel-level rootkit that completely bypasses a standard filesystem-checking routine. The answer to this is to compile the Unix kernel with no module support. In this case, all the hardware drivers will be compiled into one monolithic kernel. This significantly complicates attempts to attack by kernel code insertion, but it also complicates system administration, since all major hardware changes will require kernel recompilation. Unfortunately, as with many security controls, it can still be bypassed. Pitbull

Pitbull, by Argus Systems (http://www.argus-systems.com), makes a commercial security patch (called the Secure Application Environment) for Linux, Solaris, and AIX. It allows for the compartmentalization of applications, adds granular domain-based access control (DBAC) to standard Unix, and limits the havoc that root can wreak upon the system. Pitbull is implemented as a set of kernel modules and system utilities. Openwall kernel patch

The Openwall security patch is a well-known enhancement for Linux kernel Versions 2.0 and 2.2. While not providing any drastic security improvements or new capabilities, it helps to solve several of the important security flaws inherent to Linux. The Openwall patch offers the following features:

Nonexecutable user stack area

Makes running buffer overflow exploits more difficult. Only the more advanced exploits work under this protection. Such a feature has long existed on Solaris.

Secured /tmp

Several attacks (see Chapter 9) work by creating a symbolic link to an existing but unwritable file (such as /etc/passwd ) and then abusing some SUID root program into writing to the file. The secured /tmp feature stops such attacks. It also prevents users from creating hard links to files they do not own.

Restricted writes into untrusted FIFOs (named pipes)

Makes certain data spoofing attacks more difficult.

Secure /proc

Prevents users from gleaning information on processes that they do not own.

Special handling of default files descriptors for SUID binaries

Helps prevent some attacks against the data handled by SUID programs.

In addition, there are several security improvements related to process memory space handling, such as deallocating shared memory segments not associated with any process. However, the patch breaks some functionality in applications such as databases. It should be deployed with great care and only after testing on similar machines. LIDS

If you are really serious about system hardening, deploy the Linux Intrusion Detection System (LIDS). LIDS has a somewhat misleading name, since its focus is on the prevention rather than the detection of system problems and intrusions. LIDS is a patch to a standard Linux kernel source that provides mandatory access control (MAC) support for Linux. MAC is more secure than the standard Unix discretionary access control (DAC); it allows for more fine-grained protection and protects files from the owner and superuser. In fact, the superuser loses a large portion of its powers on a MAC-based system. LIDS protects and hides files and processes and grants access privileges on an individual basis (unlike standard Unix permissions). In addition, it has a built-in kernel port scan detector. "Secure Unix"

Many efforts have attempted to use the name "secure Unix." We'll briefly mention several Unix variants that incorporate increased security based on various models, or that perform some of the hardening measures we have described. NSA Secure Linux is one attempt to add capabilities and MAC support to the Linux kernel. The main purpose of the project is to make Linux usable in an environment where multilevel security is required. OpenBSD's focus is code audit and secure defaults that lead to a secure system right after installation. TrustedBSD is a combination of the FreeBSD code base with several formal security enhancements. Trusted Solaris is Sun's secure version of their standard Solaris Unix; it is rated above B1 on the TCSEC criteria. HP Vault is a similar effort by Sun's competitor, Hewlett-Packard, based on HP-UX. Immunix by WireX is another approach to secure Unix. In Immunix, the company chose to recompile the entire Red Hat Linux distribution using a special compiler in order to protect against buffer overflow attacks, format string attacks, and others. It also implements many hardening measures similar to those described in this chapter. Encrypted filesystems

Many of the security safeguards we described previously fail if an attacker has full access to your machine for an extended period. Is there a way to harden your system so that it resists even the ultimate attack ”i.e., the theft of the hard drive? It is possible: using the encrypted filesystem, you can protect the data on your machine from such attacks. Swap space may also be encrypted.

Encrypted filesystems have not made it into standard Unix, mostly due to various government restrictions on cryptography. However, there are many third-party tools for Unix that provide filesystem-level encryption or even a full steganographic (information-hiding) filesystem.

The oldest Unix encrypted filesystem is CFS. It was written in 1996 and is compatible with several Unix flavors (AIX, HP-UX, IRIX, Linux, Solaris, and Ultrix). The features of CFS include DES encryption of all files on the disk. It works by creating a virtual NFS server, which is accessed by the user.

Overall, encrypted filesystems have not found wide use. Encryption on that level incurs measurable performance implications, and few people seem to need the added security. Also, there is a risk of losing data if the encryption key is not available. Another aspect that hinders the wide use of such filesystems is the lack of a single "favorite" one.

 <  Day Day Up  >  

Security Warrior
Security Warrior
ISBN: 0596005458
EAN: 2147483647
Year: 2004
Pages: 211

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net