Put different services on different hosts whenever possible. The more roles a single host plays, the more applications you will need to run on it, and therefore the greater the odds that that particular machine will be compromised.
For example, if a DMZ network contains a web server running Apache, an FTP server running wuftpd, and an SMTP gateway running postfix, a new vulnerability in wuftpd will directly threaten the FTP server, but only indirectly threaten the other two systems. (If compromised, the FTP server may be used to attack them, but the attacker won’t be able to capitalize on the same vulnerability she exploited on the FTP server).
If that DMZ contains a single host running all three services, the wuftpd vulnerability will, if exploited, directly impact not only FTP functionality, but also World Wide Web services and Internet email relaying.
If you must combine roles on a single system, aim for consistency.For example, have one host support public WWW services along with public FTP services, since both are used for anonymous filesharing, and have another host provide DNS and SMTP since both are "infrastructure" services. A little division of labor is better than none.
In any case, I strongly recommend against using your firewall as anything but a firewall.
If you don’t know what a given command or package does, the simplest way to find out is via a man lookup. All manpages begin with a synopsis of the described command’s function. I regularly use manpage lookups both to identify unfamiliar programs and to refresh my memory on things I don’t use but have a vague recollection of being necessary.
If there’s no manpage for the command/package (or you don’t know the name of any command associated with the package), try apropos <string> for a list of related manpages. If that fails, your package manager should, at the very least, be able to tell you what other packages, if any, depend on it. Even if this doesn’t tell you what the package does, it may tell you whether it’s necessary.
For example, in reviewing the packages on my Red Hat system, suppose I see libglade installed but am not sure I need it. As it happens, there’s no manpage for libglade, but I can ask rpm whether any other packages depend on it (Example 3-1).
Example 3-1. Using man, apropos, and rpm to identify a package [mick@woofgang]$ man libglade
No manual entry for libglade
[mick@woofgang]$ apropos libglade libglade: nothing appropriate
[mick@woofgang]$ rpm -q --whatrequires libglade memprof-0.3.0-8
rep-gtk-gnome-0.13-3
Aha...libglade is part of GNOME. If the system in question is a server, it probably doesn’t need the X Window System at all, let alone a fancy frontend like GNOME, so I can safely uninstall libglade (along with the rest of GNOME).
SuSE also has the rpm command, so Example 3-1 is equally applicable to it. Alternatively, you can invoke yast, navigate to Package Management Change/Create Configuration, flag libglade for deletion, and press F5 to see a list of any dependencies that will be affected if you delete libglade.
Under Debian, dpkg has no simple means of tracing dependencies, but dselect handles them with aplomb. When you select a package for deletion (by marking it with a minus sign), dselect automatically lists the packages that depend on it, conveniently marking them for deletion too. To undo your original deletion flag, type "X"; to continue (accepting dselect’s suggested additional package deletions), hit RETURN.
3.1.1.1 Commonly unnecessary packages
I highly recommend you not install the X Window System on publicly accessible servers. Server applications (Apache, ProFTPD, and Sendmail, to name a few) almost never require X; it’s extremely doubtful that your bastion hosts really need X for their core functions. If a server is to run "headless" (without a monitor and thus administered remotely), then it certainly doesn’t need a full X installation with GNOME, KDE, etc., and probably doesn’t need even a minimal one.
During Linux installation, deselecting X Window packages, especially the base packages, will return errors concerning "failed dependencies." You may be surprised at just how many applications make up a typical X installation. In all likelihood, you can safely deselect all of these applications, in addition to X itself. When in doubt, identify and install the package as described previously (and as much X as it needs — skip the fancy window managers) only if you're positive you need it. If things don't work properly as a result of omitting a questionable package, you can always install the omitted packages later.
Besides the X Window System and its associated window managers and applications, another entire category of applications inappropriate for Internet-connected systems is the software-development
environment. To many Linux users, it feels strange to install Linux without also installing GCC, GNU Make, and at least enough other development tools with which to compile a kernel. But if you can build things on an Internet-connected server, so may a successful attacker.
One of the first things any accomplished system cracker does upon compromising a system is to build a "rootkit," a set of standard Unix utilities such as ls, ps, netstat, and top, which appear to behave just like the system's native utilities. Rootkit utilities, however, are designed not to show directories, files, and
connections related to the attacker's activities, making it much easier for said activities to go unnoticed. A working development environment on the target system makes it much easier for the attacker to build a rootkit that's optimized for your system.
Of course, the attacker can still upload his own compiler or precompiled binaries of his rootkit tools. Hopefully, you're running Tripwire or some other system-integrity-checker, which will alert you to changes in important system files (see Chapter 11). Still, trusted internal systems, not exposed public systems, should be used for developing and building applications; the danger of making your bastion host "soft and chewy on the inside" (easy to abuse if compromised) is far greater than any convenience you'll gain from doing your builds on it.
Similarly, there's one more type of application I recommend keeping off of your bastion hosts: network monitoring and scanning tools. This is should be obvious, but tcpdump, nmap, nessus, and other tools we commonly use to validate system/network security have tremendous potential for misuse.
As with development tools, security-scanning tools are infinitely more useful to illegitimate users in this context than they are to you. If you want to scan the hosts in your DMZ network periodically (which is a useful way to "check your work"), invest a few hundred dollars in a used laptop system, which you can connect to and disconnect from the DMZ as needed.
While any unneeded service should be either deleted or disabled, the following deserve particular attention: rpc services
Sun’s Remote Procedure Control protocol (which is included nowadays on virtually all flavors of Unix) lets you centralize user accounts across multiple systems, mount remote volumes, and execute remote commands. But RPC isn’t a very secure protocol, and you shouldn’t be running these types of services on a DMZ hosts anyhow.
Disable (rename) the nfsd and nfsclientd scripts in all subdirectories of /etc/rc.d in which they appear.
Local processes sometimes require the RPC " portmapper," a.k.a. rpcbind. Disable this with care, and try re-enabling it if other things stop working, unless those things are all X-related. (You shouldn’t be running X on any publicly available server.)