rsh, rlogin, and rcp allow remote shell sessions and file transfers using some combination of username/password and source-IP-address authentication. But authentication data is passed in the clear and IP addresses can be spoofed, so these applications are not suitable for DMZ use. If you need their functionality, use Secure Shell (SSH), which was specifically designed as a replacement for the r-services. SSH is covered in detail in Chapter 4.
Comment out the lines corresponding to any "r-commands" in /etc/inetd.conf. inetd:
The Internet Daemon is a handy way to use a single process (i.e., inetd) to listen on multiple ports and invoke the services on whose behalf it’s listening as needed. On a bastion host, however, most of your important services should be invoked as persistent daemons: an FTP server, for example, really has no reason not to run FTPD processes all the time.
Furthermore, most of the services enabled by default in inetd.conf are unnecessary, insecure, or both. If you must use inetd, edit /etc/inetd.conf to disable all services you don’t need (or never heard of!). Many of the rpc services I warned against earlier are started in inetd.conf. linuxconfd
While there aren’t any known exploitable bugs in the current version of linuxconf (a system administration tool that can be accessed remotely), its presence is a dead giveaway that you’re running Linux (and probably either Red Hat or Mandrake): CERT reports that this service is commonly scanned for and may be used by attackers to identify systems with other vulnerabilities (CERT Current Scanning Activity page 07/08/2002, http://www.cert.org/current/scanning.html). sendmail
Many people think that sendmail, which is enabled by default on most versions of Unix, should run continuously as a daemon, even on hosts that send email only to themselves (e.g., administrative messages such as crontab output sent to root by the crontab daemon). This is not so: sendmail (or postfix, qmail, etc.) should be run as a daemon only on servers that must receive mail from other hosts. (On other servers, run sendmail to send mail only as needed; you can also execute sendmail -q as a cron job to attempt delivery of queued messages periodically.) Sendmail is usually started in /etc/rc.d/rc2.d or /etc/rc.d/rc3.d.
Telnet, FTP, and POP
These three protocols have one unfortunate characteristic in common: they require users to enter a username and password, which are sent in clear text over the network. Telnet and FTP are easily replaced with ssh and its file-transfer utilities scp and sftp; email can either be automatically forwarded to a different host, left on the DMZ host and read through a ssh session, or downloaded via POP using a "local forward" to ssh (i.e., piped through an encrypted Secure Shell session). All three of these services are usually invoked by inetd.
Remember, one of our operating assumptions in the DMZ is that hosts therein are much more likely to be compromised than internal hosts. When installing software, you should maintain a strict policy of "that which isn’t necessary may be used against me." Furthermore, consider not only whether you need a given application but also whether the host on which you’re about to install it is truly the best place to run it (see "Division of Labor Between Servers," earlier in this chapter).
3.1.1.2 Disabling services without uninstalling them
Perhaps there are certain software packages you want installed but don’t need right away. Or perhaps other things you’re running depend on a given package that has a nonessential daemon you wish to disable. If you run Red Hat or one of its derivatives (Mandrake, Yellow Dog, etc.), you should use chkconfig to manage startup services. chkconfig is a simple tool (Example 3-2).
[mick@woofgang mick]# chkconfig --help
chkconfig version 1.2.16 - Copyright (C) 1997-2000 Red Hat, Inc. This may be freely redistributed under the terms of the GNU Public License.
usage: chkconfig --list [name] chkconfig --add <name> chkconfig --del <name>
chkconfig [--level <levels>] <name> <on|off|reset>) To list all the startup services on my Red Hat system, I simply enter chkconfig --list. For each script in /etc/rc.d, chkconfig will list that script’s startup status (on or off) at each runlevel. The output of Example 3-3 has been truncated for readability:
Example 3-3. Listing all startup scripts’ configuration [root@woofgang root]# chkconfig --list
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off linuxconf 0:off 1:off 2:on 3:off 4:off 5:off 6:off (etc.)
To disable linuxconf in runlevel 2, I’d execute the commands shown in Example 3-4. Example 3-4. Disabling a service with chkconfig
[root@woofgang root]# chkconfig --level 2 linuxconf off [root@woofgang root]# chkconfig --list linuxconf
linuxconf 0:off 1:off 2:off 3:off 4:off 5:off 6:off (The second command, chkconfig --list linuxconf, is optional but useful in showing the results of the first.)
On SuSE systems, edit the startup script itself (the one in /etc/init.d), and then run the command insserv (no flags or arguments necessary) to change automatically the symbolic links that determine the runlevels in which it’s started. Each SuSE startup script begins with a header, comprised of comment lines, which dictate how init should treat it (Example 3-5).
Example 3-5. A SuSE INIT INFO header # /etc/init.d/lpd
#
### BEGIN INIT INFO # Provides: lpd
# Required-Start: network route syslog named # Required-Stop: network route syslog
# Default-Start: 2 3 5 # Default-Stop:
# Description: print spooling service ### END INIT INFO
For our purposes, the relevant settings are Default-Start, which lists the runlevels in which the script should be started, and Default-Stop, which lists the runlevels in which the script should be stopped. Actually, since any script started in runlevel 2, 3, or 5 is automatically stopped when that runlevel is exited, Default-Stop is often left empty.
Any time you change a startup script’s INIT INFO header on a SuSE system, you must then run the command insserv to tell SuSE to change the start/stop links accordingly (in /etc/init.d’s "rc" subdirectories). insserv is run without arguments or flags.
For more information about the SuSE’s particular version of the System V init-script system, see SuSE’s init.d(7) manpage.
On all other Linux distributions, you can disable a service simply by deleting or renaming its links in the appropriate runlevel directories under /etc/rc.d/. For example, if you’re configuring a web server that doesn’t
need to be its own DNS server, you probably want to disable BIND. The easiest way to do this without deleting anything is by renaming all links to /etc/init.d/ (Example 3-6).
Example 3-6. Disabling a startup script by renaming its symbolic links [root@woofgang root]# mv /etc/rc.d/rc2.d/S30named /etc/rc.d/rc2.d/disabled_S30named
[root@woofgang root]# mv /etc/rc.d/rc3.d/S30named /etc/rc.d/rc3.d/disabled_S30named
[root@woofgang root]# mv /etc/rc.d/rc5.d/S30named /etc/rc.d/rc5.d/disabled_S30named
(Note that your named startup script may have a different name and exist in different or additional subdirectories of /etc/rc.d.)
3.1.2 Keeping Software Up to Date
It isn’t enough to weed out unnecessary software: all software that remains, including both the operating system itself and "user-space" applications, must be kept up to date. This is a more subtle problem than you might think, since many Linux distributions offer updates on both a package-by-package basis (e.g., the Red Hat Errata web site) and in the form of new distribution revisions (e.g., new CD-ROM sets).
What, then, constitutes "up to date"? Does it mean you must immediately upgrade your entire system every time your distribution of choice releases a new set of CD-ROMs? Or is it okay simply to check the distribution’s web page every six months or so? In my opinion, neither is a good approach. (Not that these are the only two choices; they represent extremes.)
3.1.2.1 Distribution (global) updates versus per-package updates
The good news is that it’s seldom necessary to upgrade a system completely just because the distribution on which it’s based has undergone an incremental revision (e.g., 7.2 7.3). The bad news is that updates to individual packages should probably be applied muchmore frequently than that: if you have one or more Internet-connected systems, I strongly recommend you subscribe to your distribution’s security-
announcement mailing list and apply each relevant security patch as soon as it’s announced.
Remember, the people who announce "new" security vulnerabilities as a public service are not always the first to discover them. The prudent assumption for any such vulnerability is that the "bad guys" already know about it and are ready to exploit it if they find it on your systems.
Therefore, I repeat: the only way to minimize your exposure to well-known vulnerabilities is to do the following:
• Subscribe to your distribution’s security-announcement mailing list • Apply each security patch immediately after receiving notice of it • If no patch is available for an application with widely exploited
vulnerabilities, disable that application until a patch is released.
A "global" revision to an entire Linux distribution is not a security event in itself. Linux distributions are revised to add new software packages, reflect new functionality, and provide bug fixes. Security is hopefully enhanced too, but not necessarily. Thus, while there are various reasons to upgrade to a higher numbered revision of your Linux distribution (stability, new features, etc.), doing so won’t magically make your system more secure.
In general, it’s good practice to stick with a given distribution version for as long as its vendor continues to provide package updates for it, and otherwise to upgrade to a newer (global) version only if it has really compelling new features. In any Linux distribution, an older but still supported version with all current patches applied is usually at least as secure as the newest version with patches and probably more secure than the new version without patches.
In fact, don’t assume that the CD-ROM set you just received in the mail directly from SuSE, for example, has no known bugs or security issues just because it’s new. You should upgrade even a brand-new operating system (or at least check its distributor’s web site for available updates) immediately after installing it.
I do not advocate the practice of checking for vulnerabilities only periodically and not worrying about them in the interim: while better than never checking, this strategy is simply not proactive enough. Prospective attackers won’t do you the courtesy of waiting after your quarterly upgrade session before striking. (If they do, then they know an awful lot about your system and will probably get in anyhow!)
Therefore, I strongly recommend you get into the habit of applying security-related patches and upgrades in an ad-hoc manner — i.e., apply each new patch as soon as it's announced.