In this chapter, common known weaknesses and important configuration techniques of common subsystems will be discussed. You cannot live without some of these services, such as Sendmail and DNS. Others are inherently insecure, and must not be used outside a secure and controlled environment, if security is to be maintained.
The topics covered in this chapter include:
● "NFS, mountd, and portmap" ● "Sendmail"
● "Telnet" ● "FTP"
● "The rsh, rcp, rexec, and rlogin Services" ● "DNS (named, a.k.a. BIND)"
● "POP and IMAP Servers" ● "Doing the Samba"
● "Stop Squid from Inking Out Their Trail" ● "The syslogd Service"
● "The print Service (lpd)" ● "The ident Service" ● "INND and News"
Book: Real World Linux® Security: Intrusion Prevention, Detection, and Recovery Section: Chapter 4. Common Break-Ins by Subsystem
4.1 NFS, mountd, and portmap
Danger Level
NFS stands for Network File System. It allows a client system to "ount" a NFS server system's remote file systems as if they were directly on the client system. Samba and AppleTalk are more recently created similar facilities. NFS is a powerful capability. Unfortunately, there have been numerous severe security problems, some of them unsolvable without incompatible protocol changes. Because of this, it is recommended that it not be used at all except on private secure networks, protected from insecure networks, such as the Internet.
Please review "Turn Off NFS, mountd, and portmap" and "Switch NFS to Run Over TCP", where many of the problems have been covered in-depth. So what are the problems and under what conditions can they be worked around?
1. UDP is insecure because it can be spoofed easily. This can be resolved by protecting the network of NFS systems (servers and clients) from unsecured networks via a properly configured firewall and ensuring that only trusted systems running secure operating systems can attach to the network. This firewall will need to know which IP addresses belong on which interfaces and reject packets received on a different interface than that of the "real" system with said IP address. If the routing system is running Linux (with at least a 2.2 kernel), a firewall is not even necessary as the kernel offers Source Address Verification. This feature enables the kernel to block packets with spoofed source addresses coming in from the wrong interface. It is very easy to set up and is explained in "Blocking IP Spoofing".
2. All systems on this network need to be secured against untrustworthy people having root access. This is to prevent crackers that have physical or network access to your Linux and UNIX boxes simply spoofing from an "inside" system. For Windows and Macs, similar password protection is needed, though protection against physical access to them by the untrustworthy will increase security. This is due to their having a different
security model than Linux. (Many people consider many closed source operating systems significantly less secure than Linux.)
3. Systems need to be protected against a rogue booting his own operating system off floppy, CD-ROM, or obtaining single-user mode booting off disk. This is discussed starting in "Booting an Intruder's Floppy or CD-ROM". Because of NFS's design, the
NFS server will be compromised in addition to the box booted.
4. Understand that NFS was created at a time when all computers were big and expensive, only trusted SysAdmins had root access, and systems were kept in locked rooms with very limited access. Anyone with root access can alter her client box to obtain any NFS access offered to any client on the network by a given NFS server. This is done simply by altering the client system's IP address and using su to gain the privileges of
whichever account is offered access by the NFS server.
Even if the NFS server does not grant root access to clients, an "ordinary" account will be plenty powerful if the account has access to critical data, such as the account for http, an important application, or an account that has access to program sources, confidential documents, Web pages, databases, etc.
On some distributions, such as Red Hat, the standard installation causes
Apache to run with the permissions of the nobody account. This account also defaults to be the unprivileged NFS account, usually used when a client
system's root account or nonmatching account issues an NFS request. A nonmatching account is an account (UID) on the client system that has no equivalent UID in the server system's /etc/passwd file.
This means that an unprivileged account on a client system would have full access to the very privileged Apache Web server account. To avoid any risk of this, it should be considered mandatory that Apache (httpd) not run with the permissions of nobody, nor should any of its files be owned by nobody. Apache must not run as root either.
5. Ensure that unprotected systems cannot get packets to your NFS server, mountd,
portmap (or NFS clients) that could be spoofed. This means using IP Chains,
preferably on a firewall, or Source Address Verification to block port 2049 (NFS) and port 111 (portmap) for both UDP and TCP from untrusted networks and untrusted systems.
6. Use suitable options when mounting a NFS file system. The most important ones are as follows: The tcp option will cause NFS to use TCP instead of UDP. TCP is much harder to spoof, due to the three-way handshaking using random numbers. The nosuid
options will cause the Linux kernel to ignore any set-UID or set-GID bits on files. The
noexec option will prevent the execution of any programs on the file system.
7. Use the options available in /etc/exports entries to increase security. In particular, the ro option to make a file system Read/Only that does not need to be writable and the
noaccess option to block access to a subtree are helpful. Do not disable
Even with root_squash, if a non-root user can alter a program that root later invokes, that user will "own" the machine.
Use squash_uids=0-15,20 to squash UIDs 0-15 and 20. This means that if a rem ote user claims to be UID 13, treat him as if he was the nobody account onthe server system. This account is presumed to own no files and thus is allowed only whatever access is granted worldwide. If appropriate, use all_squash to treat all users as
nobody. Another possibility is to use map_static=/etc/nfs/nervous.map to use a list that maps remote UIDs into appropriate local UIDs. A typical nervous.map
file would look like this:
#ID Client Server Comments
uid 0-99 - # Squash UIDs
uid 100-999 1000 # Map 100-999 to 1000-1999 gid 0-99 - # Squash GIDs
Book: Real World Linux® Security: Intrusion Prevention, Detection, and Recovery Section: Chapter 4. Common Break-Ins by Subsystem
4.2 Sendmail
Danger Level
Almost every Linux shop runs Sendmail and allows any system in the world to connect to it. It needs root access to open its privileged port (TCP port 25) and to enable all its features. Next to the kernel, and, possibly X, Sendmail may be the most complex component of Linux and you could spend a lifetime learning about it. It will be assumed that your systems have been upgraded to Sendmail 8.10 or higher and that you have applied the suggestions that were discussed in "Upgrade sendmail" and "Fortify Sendmail to Resist DoS Attacks". We will proceed from there.
Although Sendmail 8.9.3 and above are considered secure at present, between that version and 8.10, the configuration file format changed dramatically. Rather than requiring
SysAdmins to be an expert on the challenging sendmail.cf format, this change allows editing the less challenging sendmail.mc file for routine configuration changes. There are other improvements too.
If your version of Sendmail is older than 8.9.3, there are known buffer overflow exploits and spam relay exploits that you are vulnerable to, so you will want to upgrade immediately. See "Upgrade sendmail" for the details on upgrading Sendmail. A variety of problems and solutions related to Sendmail will be discussed here. There are other freeware alternatives to Sendmail, such as postfix
and qmail. Many people consider these to be easier to use and more secure than Sendmail. Now that Eric Allman, Sendmail's creator, has founded the well-capitalized Sendmail, Inc., there has been good support and new features for Sendmail. The postfix program is recommended by many security experts as a more secure mailer than Sendmail. It was developed by Wietse Venema, one of the most regarded Linux developers, at IBM's TJ Watson Research Laboratory, one of the world's best research labs.
I have fond memories of the Watson Lab, because this was where I first learned to program, in APL on the mighty IBM 360/90. I also got to play with high voltage, high vacuum, and low temperatures there.
The postfix program was designed from the ground up with security in mind and using the "Rings of Security" model to minimize single points of security failure. One of the techniques employed is the use of separate cooperating processes to interact with the Internet, to receive locally originated mail, and to deliver mail locally. The processes interacting with the Internet do not have the authority