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.

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.

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

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:

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 )

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.

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.tldp.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.

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:

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
# chmod 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.

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.

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.

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.

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).

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.

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, 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.

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:

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.

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.

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.

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.

The binary form of TCP wrappers is used to “wrap” around network applications started from the Internet superdaemon inetd. In this case, the applications are configured in the /etc/inetd.conf file. The superdaemon starts the correct network application upon client connection to a specified port. The following is an excerpt from an /etc/inetd.conf file before TCP wrappers are added:

ftp     stream    tcp    nowait    root    /usr/bin/in.ftpd     in.ftpd -l -a
telnet  stream    tcp    nowait    root    /usr/bin/in.telnetd    in.telnetd

shell   stream    tcp    nowait   root    /usr/bin/in.rshd    in.rshd
talk     dgram    udp    wait     root    /usr/bin/in.talkd   in.talkd
pop-3   stream    tcp    nowait   root    /usr/bin/ipop3d     ipop3d
auth    stream    tcp     nowait   nobody    /usr/bin/in.identd    in.identd -l -e -o

Next we see the same file, with the added protection of TCP wrappers:

ftp    stream    tcp    nowait    root    /usr/sbin/tcpd    in.ftpd -l -a
telnet stream    tcp    nowait    root    /usr/sbin/tcpd    in.telnetd

shell  stream    tcp    nowait    root    /usr/sbin/tcpd    in.rshd
talk    dgram    udp    wait      root    /usr/sbin/tcpd    in.talkd
pop-3  stream    tcp    nowait    root    /usr/sbin/tcpd    ipop3d
auth   stream    tcp    nowait    nobody  /usr/sbin/tcpd    in.identd -l -e -o

TCP wrappers added two important benefits to the network services: security and improved logging. However, our TCP wrapper configuration is not yet complete. The files that define the denied and allowed hosts (/etc/hosts.deny and /etc/hosts.allow ) need to be created. The simplest configuration that provides useful security is as follows (/etc/hosts.deny is shown):

ALL:ALL

This file denies access from all hosts (the second ALL) to all services on our server (the first ALL). Who can use the machine? To define permissions, use /etc/hosts.allow:

ALL: 127.0.0.1 LOCAL
in.telnetd: [email protected]
sshd: manager.example.edu
in.ftpd: .example.edu 10.10.10.
in.pop3d: .com .org .net EXCEPT msn.com

You can even set TCP wrappers to alert you in real time when connections from particular ports occur. The old TCP wrapper manpages provide the following example (/etc/hosts.deny):

in.tftpd: ALL: (/some/where/safe_finger -l @%h | 
           /usr/ucb/mail -s %d-%h root) &

or even:

sshd 
  : [email protected] ALL@calph ALL@insti 
  : spawn (safe_finger -l @%h | mail -s 'SSHED FROM INTERNET %d-%c!!' anton) & 
  : ALLOW

The last example shows an alternative format for the hosts.allow file in which the action (allow or deny) is specified on a per-command-line basis, rather than a per-file basis.

One potential weakness with this setup is that it can subject you to email flooding—even to the point of disk overflow. Chapter 12 addresses this issue in the section on Unix denial-of-service attacks.

The libwrap.so system library provides the same functionality as a tcpd wrapper. If you have access to the application source code, you can streamline the access control process and incorporate access control file checking by the library. However, this requires significant changes to the application code base. This method is used in OpenSSH and in sendmail. If compiled with the libwrap.so library, the application itself will check the configuration files (/etc/hosts.allow and /etc/hosts.deny) to determine whether to allow or deny access. An example implementation is to control spam.

In addition, the inetd daemon has been rewritten to become xinetd, with advanced access control features. xinetd is used by some popular Linux distributions, including Red Hat. xinetd is controlled by its configuration file (usually /etc/xinetd.conf) or sometimes via a configuration directory containing service-specific files. The configuration files below (similar to those used by Red Hat Linux) use a global configuration file and directory.

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID DURATION
        log_on_failure          = HOST RECORD USERID 
}
includedir /etc/xinetd.d

This configuration file shows service defaults and logging defaults, and it refers to the configuration directory for details (/etc/xinetd.d). The file also provides some protection from resource exhaustion by limiting the number of child processes (FTP, email, or other network programs) started by xinetd.

The following example entry configures the popular File Transfer Protocol (FTP) implementation written by Washington University (WU-FTPD). This file lists protocol options similar to inetd.conf (such as type of service), server arguments, priority (keyword nice), and system-logging options, but it also lists options for more granular access control.

service ftp
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a -i -o
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
}

The above file can contain the following access control options:

xinetd provides improvements to the classic inetd for enhanced flexibility and granularity in access controls. Unfortunately, it is standard on Linux only, and therefore you must compile and deploy it on other Unix flavors.

BIND (Berkeley Internet Name Domain) DNS daemon software provides domain name resolution services for the majority of Internet hosts. Historically, BIND has passed through some major revisions (Versions 4, 8, and 9). While early versions had no network access controls due to their origin in the small and trusted Internet of the 1970s and 1980s, modern versions have an advanced granular access control facility.

General BIND configuration is a complex subject. In this section, we focus on the access control features to illustrate possible solutions for this problem.

The BIND configuration file is located in the /etc directory and is usually called /etc/named.conf. In this file, the administrator can specify which machines or domains can query the server for DNS information (keyword allow-query), which can update the DNS zone status change (keyword allow-notify), and which can perform DNS zone transfers (keyword allow-transfer). Using the above keywords, the DNS daemon can be shielded from malicious attempts to update information or to map an organization’s network (using complete DNS zone transfers).

The DNS daemon has a history of security bugs, and access control will help to increase your confidence in this mission-critical software.

sendmail can be compiled with TCP wrapper support. In addition, sendmail can use one of several built-in access control facilities. It’s important to have reliable access controls for sendmail, since the SMTP protocol can be abused in many ways.

The purpose of sendmail access controls is to restrict mail-sending capability to authorized users only. The SMTP protocol currently used to send mail lacks a standard accepted authentication method. While some proposals exist (see RFC 2554 and RFC 2222), vendor support is lacking. As a result, network access control is the only solution.

As in the case of the BIND daemon, sendmail configuration is not for the weak of heart. The main sendmail configuration file (/etc/sendmail.cf) presents a confusing mess of regular expressions and unfriendly options. In fact, an additional directory is usually allocated (/etc/mail) to hold additional configuration files, including those used for access control. While simpler methods of configuring sendmail exist (such as by using the m4 macros for common options in sendmail.mc and then converting to sendmail.cf automatically), they are still less than intuitive.

sendmail can refer to an access database (not to be confused with a Microsoft Access database) in order to determine the privileges of the connected host. The connection can be refused if /etc/mail/access contains a REJECT keyword for the connected host or for the entire domain. Hosts can also be granted additional privileges, such as the ability to RELAY mail (i.e., send email to a third party). Such configuration files might look like:

evilhacker.org    REJECT
.edu        RELAY

To make matters worse, the sendmail daemon does not check the /etc/mail/access file, but rather checks the binary database version of it. To convert the file from its plain-text human-editable form to the form readable by sendmail, execute the following command:

makemap hash /etc/mail/access < /etc/mail/access

Overall, compiling sendmail with TCP wrappers might be easier than sorting out the intricacies of the proprietary access control facilities of your software.

A commercial Secure Shell daemon, as well as the free OpenSSH, can be compiled with TCP wrappers. The SSH daemon also has a built-in access control. Both major versions of Secure Shell can be configured to block connections from specific hosts or even users.

The commercial SSH configuration file (usually /etc/sshd/sshd_config or /etc/sshd2/sshd2_config) can contain keywords such as AllowUsers (DenyUsers) or AllowHosts (DenyHosts). The keywords work as follows: the configuration file can only contain one of the “Allow” or “Deny” keywords. If, for example, AllowHosts is present, all the hosts not explicitly mentioned in the AllowHosts directive are denied. On the other hand, if DenyHosts is in the configuration file, all the other hosts will be allowed to access the server.

Here’s a sample directive:

AllowHosts      localhost, example.edu

In the case of commercial SSH2, you can use built-in regular expression syntax to create fairly complicated rules for host access. For example, the configuration setting:

AllowHosts      go..example...*

allows only specific hosts to access the server.

The most popular web server in the world is the open source Apache web server by the Apache Software Foundation. While web servers are primarily used to provide public access to resources over the Web, the need for access control often arises. In this section, we describe some of the ways of restricting access to web resources using Apache controls.

Apache has two main types of access control: username/password-based (basic or digest authentication) and host-based authentication.

The simplest form of access control is host or domain restriction. Various Apache configuration files (such as the main configuration file, usually located in /etc/httpd and called httpd.conf) can contain directives to limit accesses from various hosts and domains. “Allow from” and “Deny from” are used for this purpose. Both can appear within the same file. To avoid confusion, the recommended method is to configure one directive with the target of “all” and use the second directive to grant or take away privileges.

An example of such a configuration is as follows:

Order Deny, Allow
Deny from all
Allow from goodbox.example.org example.edu

These lines allow access only to a certain web resource (such as a directory on a web server) from a single machine (“goodbox”) within example.org and from the entire example.edu domain.

On the other hand, if certain “bad” hosts should be disallowed to access web resources, the following configuration may be used:

Order Allow, Deny
Allow from all
Deny from badbox.example.org

In this case, the machine “badbox” from the domain example.org is not allowed to access the pages.

More advanced access controls make use of usernames and passwords. These are well covered in the existing literature and on the Apache web server web site (http://httpd.apache.org/docs/howto/auth.html).

Network attacks through eavesdropping are as common as ever. While telnet has lost a lot of ground as the Unix remote access protocol of choice, it is not yet dead. Secure Shell has made a lot of progress since its inception in the mid-1990s, but it has not become as ubiquitous as the encrypted web protocol HTTPS (SSL or TLS-based).

A sniffer is a part of every cracker’s rootkit. Successful attackers leave hidden sniffers to collect unencrypted telnet, FTP, and POP3 passwords. Fortunately, protection against such network eavesdropping is trivial using encryption. However, as with many other security measures, it is often easier said than done. For example, replacing telnet with SSH on a large network is a process with many challenges, not the least of which is user compliance. While it might seem that typing “ssh hostname.example.edu” is simpler than “telnet hostname.example.edu”, the three saved keystrokes might take a long time to actually implement in a large environment of users accustomed to unsafe computing habits. Unix vendors who do not include or enable Secure Shell exacerbate the difficulty. All Linux distributions are shipped with SSH ready for operation, but some commercial Unix vendors are lagging behind.

In this section, we look at protection from sniffers using freely available open source tools. Table 11-3 shows a list of common protocols used in Unix networking and their vulnerability to sniffing.

A cursory glance at this list is startling. All classic Unix protocols are vulnerable to sniffing. What is available to protect Unix networks from sniffers? Encryption comes to the rescue. The Secure Sockets Layer (SSL) protects web connections, various authentication schemes (KPOP, APOP) shield email passwords, and SSH replaces telnet and FTP. SSL wrappers and SSH can be used to tunnel almost any TCP-based network protocol. X11 connections can be protected by SSH as well. Next, we consider SSH in more detail.

SSH is one of the most flexible network security measures available today. It can be used to secure many network operations, such as remote access, email sending and retrieval, X Windows traffic, and web connections. SSH was promoted as a replacement for Unix telnet and rlogin/rsh remote-access protocols (which use plain-text communications vulnerable to sniffing and traffic analysis), but it now reaches far beyond Unix remote access.

SSH consists of client software, server software, and a protocol for their interaction. The interaction protocol includes authentication, key exchange, encryption, passphrase caching, as well as other components.

Currently, there are two major versions of the SSH protocol in use. SSH Version 1 has more supported platforms and probably even more users. However, SSH1 is known to have security problems (which will be described later), so you should avoid it. Significant differences between Versions 1 and 2 arise in their respective session-encryption protocols. SSH1 supports DES, 3DES, IDEA, and Blowfish, while SSH2 uses 3DES, Blowfish, Twofish, CAST128, and RC4. For authentication algorithms, SSH1 utilizes RSA, while SSH2 relies on the open-standard DSA. There are also other major implementation differences that cause these two protocol versions to be incompatible. However, OpenSSH (the open source version of the protocol) implements both protocols in one piece of software.

SSH uses several authentication options: regular passwords, RSA (for SSH1) or DSA (for SSH2) cryptographic keys for host or user authentication, and host or user trust files (such as the hosts.equiv and .rhosts that gave r-commands a bad name and were dropped in SSH2). Plug-in modules with other authentication methods, such as RSA SecurID card, Kerberos, or one-time passwords, can be used as well. Secure Shell can also compress all data for faster access on slow links.

There are several popular implementations of the SSH protocol. The most famous are SSH, by SSH Communications Security, and OpenSSH, by the OpenBSD development team. Many Linux distributions ship with SSH configured to run at startup. All you need are a valid user account and login.

Let’s review how SSH can be used to secure other plain-text protocols. Suppose you have a POP3 (or IMAP) email server from which you read your messages. You are already aware that whenever you connect to a server to read email, your exposed username and password are transmitted in plain text over the Internet. Fortunately, SSH allows you to set up your mail client (such as the infamous Outlook Express, which spread the email worms of recent years) to connect only to the local machine. In this case, no information is leaked to the outside network. All the connections between your computer and the server are encrypted with Secure Shell.

The process is as follows: the SSH client software first establishes a regular connection to an SSH daemon running on the server machine. Next, it requests a connection to a required server port (port 110, in the case of POP3) from a remote machine. Then the SSH client starts to listen on the local client port. As a result, the tunnel from a local machine email port to a remote machine email port is set.

Password-less authentication is also of great value for POP3 tunneling, since you won’t have to enter the password every time the email program wants to check for new email on the server.

On a Unix client, perform the following:

$ssh -f -L 1100:localhost:110 [email protected] 

This command establishes a secure tunnel. Now, point your email client to retrieve mail from “localhost”, port 1100 (instead of “pop3.mail.server.com”, port 110). A higher-numbered port is used to avoid the need for root privileges. Usually, the email program has a configuration section that provides a space to enter incoming and outgoing mail servers. When using tunneling, your incoming mail server will be set to “localhost” or an IP address of 127.0.0.1. The -f option causes the ssh to fork in the background.

If you want to prevent anyone from eavesdropping on your outgoing email traffic on its way to a remote machine, do the same for an SMTP connection:

$ssh -f -L 25:smtp.mail.server.com:25 [email protected]

Although no passwords are transmitted in the case of SMTP, it still might be useful to tunnel SMTP mail by sending the connection over Secure Shell (as shown above).

Tunneling FTP is a bit more complicated, since FTP uses two pairs of TCP ports with dynamic allocation of port numbers. However, you can still implement it by using passive mode FTP and forwarding the data (port 20) and command (port 21) channels separately. scp (part of Secure Shell) can be used to provide the same functionality.

SSH uses a public key encryption scheme to authenticate users and hosts. To make use of this public key encryption, a user should create a key pair for authentication. The public key is then uploaded to the SSH server, and the private key is kept on the user’s client machine.

To create a key pair in Unix/Linux, perform the following steps:

From the very beginnings of SSH, the protocol was designed for secure file transfer as well as remote access. Since SSH was developed as a replacement for the Unix r-commands, the remote copy command (rcp) was replaced by secure copy (scp). scp can be used to copy files from one machine running SSH to another.

To use SSH for secure file copying on Unix/Linux, execute the following command:

$ scp [email protected]:~/data.tar . 

This command copies the data.tar file located in the home directory of the user “rusername” on the machine “server.example.com” to the current directory on the local machine (indicated by a trailing dot). If you have not set up public key authentication, you will be prompted for a password:

$scp /tmp/data.tar [email protected]:~/

The default remote directory is your home directory, so “~” is redundant. It is shown for demonstration purposes only. Also, the trailing slash is required for some SSH versions. This command copies the data.tar file from the /tmp directory on the current machine to the home directory of the user “rusername” on the machine “server.example.com”. If you have not set up a public key authentication, you will be prompted for a password. You can also specify multiple filenames, as long as your last entry on the command line is a directory (indicated by a slash).

Learning to use Secure Shell is a good investment of your time, since it is vital to maintaining a secure network.

Packet-filtering firewalls work by restricting the free flow of network traffic according to predefined rules to allow or deny TCP/IP packets. iptables are an example of packet-filtering firewalls with some stateful features and some content-inspection features. iptables provide a set of rules (organized into groups called chains) that handle incoming and outgoing network traffic.

Linux firewalling code has come a long way since ipfwadm was introduced in kernel 1.2. Recent changes in Linux firewalling code include the netfilter architecture, which was introduced in kernel 2.4. netfilter/iptables are a reimplementation of Linux’s firewalling code that remains fully backward compatible, due to the use of ipchains and ipfwadm loadable kernel modules. iptables offer the benefits of stateful firewalls: i.e., the firewall has a memory of each connection that passes through. This mode is essential for effective configuration of FTP (especially active FTP) and DNS, as well as many other network services. In the case of DNS, the firewall keeps track of the requests and only allows responses to those requests, not other DNS packets. iptables can also filter packets based on any combination of TCP flags and based on MAC (i.e., hardware) addresses. In addition, iptables help block some DoS attacks by using rate limiting for user-defined packet types.

Below is a simple setup for a home firewall, inspired by the “Iptables HOWTO” document. The comment lines (marked with the “#” symbol) within the script provide explanation:

#!/bin/bash
#cleanup - remove all rules that were active before we run the script
iptables -F
iptables -X
#new chain to block incoming
iptables -N allinput

#NOW WE ALLOW SOME TRAFFIC
#packets returning to connections initiated from inside are accepted
iptables -A allinput -m state --state ESTABLISHED,RELATED -j ACCEPT

#allow ssh incoming for management - we allow secure shell for remote server management
iptables -A allinput --source 10.11.12.13 --protocol tcp --destination-port 22  -j 
ACCEPT

#this machine serves as a system log server - thus we allow UDP for systlog
iptables -A allinput --source 10.11.12.0/24 --protocol udp --destination-port 514  -j 
ACCEPT

#allow X Windows connection for remote GUI
iptables -A allinput --source 10.11.12.13 --protocol tcp --destination-port 6000  -j 
ACCEPT

#web server is public - but we do not like some people from 168 subnet (so they are 
 denied)
iptables -A allinput --source ! 168.10.11.12 --protocol tcp  --destination-port 80 -j 
ACCEPT

#allow incoming from 127.0.0.1 BUT only if the interface is local (not the Ethernet card)
iptables -A allinput --source 127.0.0.1 -i lo -j ACCEPT

#DENY - all the rest are denied QUIETLY (with no reject message)
iptables -A allinput -j DROP

#these important lines control the flow of packets that enter our machine from outside
#we send them to our control chain 
iptables -A INPUT -j allinput
iptables -A FORWARD -j allinput

#test - display the rules that were enforeced
iptables -nL

Running the code produces the following output:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
allinput   all  --  0.0.0.0/0            0.0.0.0/0          

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
allinput   all  --  0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain allinput (2 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
ACCEPT     tcp  --  10.11.12.13          0.0.0.0/0          tcp dpt:22 
ACCEPT     udp  --  10.11.12.0/24        0.0.0.0/0          udp dpt:514 
ACCEPT     tcp  --  10.11.12.13          0.0.0.0/0          tcp dpt:6000 
ACCEPT     tcp  -- !168.10.11.12         0.0.0.0/0          tcp dpt:80 
ACCEPT     all  --  127.0.0.1            0.0.0.0/0          
DROP       all  --  0.0.0.0/0            0.0.0.0/0

While a simpler setup is possible, this one is easier to manage, since you can always see what is allowed, from where and on which port/protocol. It also makes the default deny policy more visible.

Detailed iptables configuration is complicated. The standard Unix reference (the manpage) gives information on options, and online guides (such as those located at http://www.netfilter.org) provide more than enough information about the internal structure of iptables (user-space and kernel code) and proposed usage.

The example setup is very restricted. As the comments above point out, we only accepted the connection for a limited number of services. The rest are silently dropped. The remote attackers will not even be able to fingerprint the OS remotely using tools such as nmap, since all packets from hosts other than those allowed are dropped. As a result, our Linux machine is now well protected from network attacks.