|
|
12.3 Primary Unix Network ServicesThis section describes selected network services that are usually provided as part of the standard Unix network package, focusing on the major security implications of each of these services. Every network service carries both known and unknown security risks. Some services have relatively small known risks, while others have substantial ones. And with every network service there is the possibility that a security flaw in the protocol or the server will be discovered at some point in the future. Thus, a conservative security policy would remove every service for which there is no demonstrated need. If you think that the risk of a service outweighs its benefit, then you can disable the service simply by placing a hash mark (#) at the beginning of the lines in the /etc/rc* file(s) or /etc/inetd.conf file that cause the server program to be executed. This will comment out those lines. Of course, if you turn off a needed service, people who wish to use it are likely to complain! Remember, too, that disabling a service does not prevent people on your computer from initiating outbound network connections to other computers running that same service.[14]
Most versions of the inetd program do not take notice of any changes to their configurations until they are restarted or sent a HUP (-1) signal. Changes in the startup files do not take effect until you change the run level or restart your system. Thus, if you disable a service, the change may not cause a currently running invocation of the server to terminate—you may need to take some other action before you can verify that you have properly disabled the service. We recommend that you save a copy of any configuration files before you begin to edit them. That way, if you make a mistake or if something doesn't work as expected, you can roll back to an earlier version of the files to determine what happened. You might consider using the RCS or CVS revision-control systems to manage these files. These systems allow you to put date stamps and comments on each set of changes for future reference. Such markings may also be useful for comparison purposes if you believe that the files have been changed by an intruder, although this isn't a particularly strong form of protection. For those services that you are determined to enable, take advantage of any logging facilities they offer. See Chapter 21 for more information about logging. 12.3.1 echo and chargen (TCP and UDP Ports 7 and 19)echo and chargen are two services that were designed for development and testing of IP networks and implementations. The echo service accepts connections on TCP port 7 or individual datagrams on UDP port 7 and echoes back everything that it receives to the sender. The chargen (character generator) service accepts TCP connections and UDP datagrams on port 19 and sends back a character pattern. For example: r2# telnet localhost 19 | more Connection refused Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. !"#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg !"#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh "#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi #$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij $%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk %&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl &'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm '( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn Although these services are useful for some kinds of testing, they should not be enabled on any computer that is connected to the public Internet. That's because it is possible to use these services, especially the UDP variants, to launch stunningly effective denial-of-service attacks. The attacks can be targeted against the computers that are running the services or against third-party computers. 12.3.2 systat (TCP Port 11)The systat service is designed to provide status information about your computer to other computers on the network. Many sites used to configure their /etc/inetd.conf file so that connections to TCP port 11 were answered with the output of the who or w command. You can determine whether your system is still configured in this manner with the telnet command: unix% telnet media.mit.edu 11 Trying 18.85.0.2... Connected to media.mit.edu. Escape character is '^]'. lieber ttyp0 Aug 12 19:01 (liebernardo.medi) cahn ttyp1 Aug 13 14:47 (remedios:0.0) foner ttyp2 Aug 11 16:25 (18.85.3.35:0.2) jrs ttyp3 Aug 13 17:12 (pu.media.mit.edu) ereidell ttyp4 Aug 14 08:47 (ISAAC.MIT.EDU) felice ttyp5 Aug 14 09:40 (gaudy.media.mit.) das ttyp6 Aug 10 19:00 (18.85.4.207:0.0) ... Although providing this information is certainly a friendly thing to do, usernames, login times, and origination hosts can be used to target specific attacks against your system. We therefore recommend against running this service. To disable the service, simply comment or remove the line beginning with the word "systat" from your /etc/inetd.conf file. You can also verify that the service has been disabled by using the telnet command: unix% telnet media.mit.edu 11 Trying 18.85.0.2... Connection refused. unix% 12.3.3 FTP: File Transfer Protocol (TCP Ports 20 and 21)The File Transfer Protocol (FTP) allows you to transfer complete files between systems. Its Unix implementation consists of two programs: ftp is the most common client program; ftpd (sometimes named in.ftpd) is the server. TCP port 21 is used for sending commands; port 20 is occasionally used for the data stream, although it is more common for the client and server to mutually negotiate a set of port numbers greater than 1024. There are several security issues with FTP:
Because of the security and management problems with FTP, many sites no longer use it. Instead, they use HTTP for downloading files anonymously and either authenticated HTTPS (HTTP over SSL) or sftp or scp (parts of the Secure Shell system) for transferring files where user authentication is first required.[15]
12.3.3.1 Anonymous FTPThe default mode for FTP is to access an individual account to transfer files. In this mode, a user accesses a particular account and then enters its password. The FTP service then allows the user to specify files to transfer to and from the remote machine. Those files must be accessible to the user on both ends of the connection. FTP can be set up for anonymous access, which allows people on the network who do not have an account on your machine to deposit or retrieve files from a special directory. Many institutions use anonymous FTP as a low-cost method to distribute software and databases to the public. To use anonymous FTP, simply specify ftp[16] as your username and your real identity—your email address—as the password:
% ftp athena-dist.mit.edu
Connected to AENEAS.MIT.EDU.
220 aeneas FTP server (Version 4.136 Mon Oct 31 23:18:38 EST 1988) ready.
Name (athena-dist.mit.edu:fred): ftp
331 Guest login ok, send ident as password.
password: Rachel@ora.com
230 Guest login ok, access restrictions apply.
ftp>
Many Internet FTP sites require that you specify an email address as your "password." Some of these systems verify that the email address looks like a valid email address, but none of them verify that the email address you type is actually your email address. 12.3.3.2 FTP active modeThe FTP protocol supports two modes of operations, active (often called normal) and passive. These modes determine whether the FTP server or the client initiates the TCP connections that are used to send information from the server to the host. Active mode is the default. In active mode, a client requesting a file provides the server with an IP address and a port number of where that file should be sent. Normally, the IP address and port correspond to a socket on which the client is listening, but this need not be the case. The server then opens a TCP connection to the requested host and port and sends the file, as illustrated in Figure 12-1. Figure 12-1. Active-mode FTP connection Active mode is unfortunate for many reasons:
Because of the problems that FTP active mode has with firewalls, many FTP implementations now default to passive mode, which is discussed in the next section. 12.3.3.3 FTP passive modeUnder normal circumstances, the FTP server initiates the data connection back to the FTP client. Many FTP servers and clients support an alternative mode of operation called passive mode. In passive mode, the FTP client initiates the connection that the server uses to send data back to the client. (Passive mode is shown in Figure 12-2.) Passive mode is desirable, because it simplifies the task of building a firewall: the firewall simply allows internal connections to pass through to the outside world, but it does not need to allow outside connections to come back in. Not all FTP clients support passive mode, but many do, including the FTP clients that are built in to most popular web browsers. If your software does not yet include it, you should upgrade to software that does. Figure 12-2. Passive-mode FTP connection 12.3.3.4 Setting up an FTP serverIf you wish to provide FTP service, you have two primary choices regarding your FTP server:
Some of these FTP daemons are started by the inetd daemon while others are started up at system boot time. Others have their own daemon that is designed to be started at boot time. In general, if you use a third-party FTP daemon, you will need to consult its documentation to determine how it should be started up. Most FTP servers can either run directly or through a wrapper such as TCP Wrappers. Our discussion of FTP services in the following sections applies to the original Berkeley Unix ftpd server. Many of the FTP servers mentioned in the list implement some or all of the security mechanisms; several of the other servers have additional security options worth studying in their documentation. 12.3.3.5 Restricting FTP with the standard Berkeley FTP serverThere are many Unix accounts that do not need to be able to transfer files using FTP. Typically, this category includes all accounts that do not belong to actual human beings (such as root) and possibly others. The confusingly named /etc/ftpusers file contains a list of the accounts that are not allowed to use FTP to transfer files. For example: # cat /etc/ftpusers root uucp news bin ingres nobody daemon In this example, we specifically block access to the root, uucp, news, bin, and other accounts so that attackers on the Internet will not be able to attempt to log in to these accounts using the FTP program. Blocking system accounts in this manner also prevents the system administrator from transferring files to these accounts using FTP, which is a risk because the passwords can be intercepted with a packet sniffer. As a further security measure, most versions of FTP will not allow a user to transfer files if the account's shell, as given in the /etc/passwd file of the system, is not also listed in the /etc/shells file.[18] This is to prevent users who have had accounts disabled or who are using restricted shells from using FTP. Before relying on this feature, you should test it with your own server to ensure that it works correctly.
12.3.3.6 Setting up anonymous FTP with the standard Unix FTP serverSetting up anonymous FTP on a server is relatively easy, but you must do it correctly because you are potentially giving access to your system to everybody on the network. To set up anonymous FTP, you must create a special account with the name ftp. For example: ftp:*:400:400:Anonymous FTP:/var/spool/ftp:/bin/false Files that are available by anonymous FTP will be placed in the ftp home directory. You should therefore make the home directory be in a special place, such as /var/spool/ftp. When it is used for anonymous FTP, ftpd uses the chroot( ) function call to change the root of the perceived filesystem to the home directory of the ftp account. For this reason, you must set up that account's home directory as a mini-filesystem. Three directories go into this mini-filesystem:
Be sure to place copies of the actual files (or hard links to them) in the mini-filesystem, rather than using symbolic links pointing to other places on your system. Because the ftpd program uses the chroot ( ) system call, symbolic links may not behave properly with anonymous FTP. In general, symbolic links to inside your chroot area will work, and they are commonly used on anonymous FTP sites. However, any symbolic link that points outside the chroot area or is an absolute symbolic link will not work. You can do all of the operations we've discussed above by executing the following commands as the superuser. We assume that you've already created ~ftp. # mkdir ~ftp/bin ~ftp/etc ~ftp/pub Create needed directories. Set up ~ftp/bin: # cp /bin/ls ~ftp/bin Make a copy of the ls program. # chown root ~ftp/bin/ls Make sure root owns the program. # chmod 111 ~ftp/bin/ls Make sure ls can't be changed. # chmod 111 ~ftp/bin Make directory execute-only. # chown root ~ftp/bin Make sure root owns the directory. Set up ~ftp/etc: # cat-passwd awk -F: '{printf "%s:*:%s:%s::\n",$1,$2,$3}' > ~ftp/etc/passwd
Make a copy of /etc/passwd with
all passwords changed to asterisks.
# awk -F: '{printf "%s::%s:%s\n",$1,$3,$4}' /etc/group > ~ftp/etc/group
Make a copy of /etc/group.
# chmod 444 ~ftp/etc/* Make sure files in etc are not writable.
# chmod 111 ~ftp/etc Make directory execute-only.
# chown root ~ftp/etc Make sure root owns the directory.
Set up ~ftp/pub:[20]
# chown root.wheel ~ftp/pub Make sure root owns the directory. # chmod 555 ~ftp/pub Make directory writable by nobody (see warning). And finally, secure the ~ftp directory: # chmod 555 ~ftp # chown root ~ftp Many ftp servers work fine if the only entries in the passwd file are for root and ftp, and the only entry in the group file is for group ftp. The only side effect is that files left in the ftp directories will show numeric owners and groups when clients do a directory listing. The advantage to having a trimmed file is that even if outsiders do obtain a copy of the file, they will not be able to gain any clues as to your system's user population. The disadvantage is that the dir command will not show symbolic usernames. Some systems require you to install dynamic libraries and even device files to make the FTP server's file list command work. This is somewhat problematic, as the more complicated it is to set up an anonymous FTP server, the greater the chances are that you will make a mistake. For this reason, many second-generation FTP servers have built-in implementations for the FTP dir command and, as a result, it is considerably simpler to set up these servers for anonymous and chroot( )ed access. In general, the fewer files accessed in the anonymous FTP area, the harder the system will be to compromise.
You should also set up a mail alias for the ftp user so that mail sent to ftp is delivered to one of your system administrators.
12.3.3.7 Allowing only FTP accessSometimes, you may wish to give people permission to FTP files to and from your computer, but you may not want to give them permission to actually log in. One simple way to accomplish this goal is to set up the person's account with a special shell, such as /bin/ftponly. Follow these directions:[22]
12.3.4 SSH: The Secure Shell (TCP Port 22)Originally developed by Tatu Ylonen, SSH (the Secure Shell) is a cryptographically enabled protocol for remote login, file copying, and TCP connection tunneling (perhaps better known as port forwarding by SSH users). Although originally implemented solely by Tatu Ylonen's ssh command-line Unix utility, today the SSH protocol is implemented by dozens of programs on many platforms. The two most popular Unix implementations are Ylonen's original SSH, and OpenSSH, developed by the OpenBSD Project. Commercial clients and servers are also available.
There are two versions of the SSH protocol. Although both protocols allow the symmetric cipher to be negotiated, SSH Version 1 relies on the RSA public key encryption algorithm for authentication and initial key exchange. SSH Version 2 has extended the protocol by allowing for both the RSA and the DSA public key encryption algorithms and has corrected several flaws in the SSH1 protocol. Version 2 is therefore recommended. Behavior of the SSH server is determined by the sshd_config file, which can be in the /etc/, /etc/ssh, /usr/local/etc, or /usr/local/etc/ssh directories. The behavior of the SSH client is likewise controlled by the file ssh_config. Systems that have been running SSH for extended periods of time tend to have multiple SSH configuration files in multiple locations, as different releases of the software have changed the location where the configuration file resides. If you have SSH installed on your system, you should be sure that there is only one sshd_config file and one ssh_config file. If there are multiple files, there is a chance that you will make important security-related modifications to the wrong file. Because this is a very important file from a security perspective, you will probably want to track changes to it using an appropriate source code control system, such as RCS or CVS. 12.3.4.1 Host authentication with SSHEvery host that runs an SSH server is supposed to have its own unique RSA public and private key pair, called the SSH HostKey. Version 2 servers have a second public key pair called the HostDSAKey that uses the DSA encryption algorithm. Most SSH startup scripts will automatically create this key the first time that the server is run if the key does not already exist. The size of the RSA key is determined by the ServerKeyBits variable in the sshd_config file. When an SSH client connects to the server, the server provides its public key. This key serves two purposes. First, the client uses this key to encrypt information that is sent back to the server during the authentication phase. Second, the public key is used by the server to establish its identity. Each time a client connects to the server, the server provides the same public key to the client; the client is thus able to determine, each time it connects to the server, that it is communicating with the same server as it was on previous occasions. For example, the first time you connect to a new server with SSH, you might see a message that looks like this: % ssh k1.net
The authenticity of host 'k1.net (204.17.195.90)' can't be established.
RSA1 key fingerprint is 01:1d:e0:19:72:20:9e:6c:81:36:20:87:02:1c:7a:aa.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'k1.net' (RSA1) to the list of known hosts.
simsong@k1.net's password: no54password
Last login: Fri Jul 26 17:05:04 2002 from sdsl-64-7-15-235
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California.
All rights reserved.
FreeBSD 4.4-STABLE (KING1) #3: Sun Dec 30 22:47:59 EST 2001
UNAUTHORIZED USE OF THIS SYSTEM IS PROHIBITED AND MAY BE PROSECUTED
TO THE FULL EXTENT OF THE LAW. IF YOU ARE NOT AN AUTHORIZED USER, LOG
OFF NOW!
BY USING THIS COMPUTER, YOU IMPLICITLY GIVE CONSENT TO BE MONITORED BY
K1.NET AND LAW ENFORCEMENT AGENCIES.
[simsong@king1 ~] 301 %
(We couldn't resist showing you a good login banner while we were at it; see the discussion of banners in Chapter 10.) When the user types yes, the host and its HostKey are added to the user's ~/.ssh/known_hosts file. This file is used both for authenticating remote hosts when they are servers and verifying the identity of users on those remote hosts attempting to SSH into the current host. Here is the file, by the way: % cat .ssh/known_hosts nitroba.com 1024 35 1221279801154411047137592780814914240404071816269386780586932489285347521546124117334 7072000249547792523281132073298893235325626460107271167220564024129338624392067682243 1031349991570643961150703034229390489100811195468563413901808940705090204157836601269 074879528767596794520295502327033979623422605015530523 k1.net 1024 35 1717108657502938468089901929560853045921804378401153006150018098780333649932986316689 5489594546067426463746514797728944186038454047514021440966626196421332883322967452080 2945453703996092707501281813463111467013984910036252588169600476313982544037218325442 275801292413736097002222827453938912602640839717646689 % The first key was already present; the second key is the key for k1.net, which was added by the SSH example. On successive connections to the server, no mention is made of the host key: % ssh k1.net
simsong@k1.net's password: no54password
Last login: Fri Jul 26 17:05:04 2002 from sdsl-64-7-15-235
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California.
All rights reserved.
FreeBSD 4.4-STABLE (KING1) #3: Sun Dec 30 22:47:59 EST 2001
...
But if the host key changes, you might see a message like this: % ssh k1.net @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is 01:1d:e0:19:72:20:9e:6c:81:36:20:87:02:1c:7a:aa. Please contact your system administrator. Add correct host key in /usr/home/simsong/.ssh/known_hosts to get rid of this message. Offending key in /usr/home/simsong/.ssh/known_hosts:2 RSA1 host key for k1.net has changed and you have requested strict checking. [simsong@king1 ~] 199 % The host key protects against two kinds of attacks:
The HostKey is a good idea. Unfortunately, HostKeys seem to change on a fairly regular basis—sometimes whenever a new operating system is installed, or when a new SSH installation inadvertently creates a new host key rather than preserving the old one. Therefore, if the HostKey of a server that you communicate with changes, you shouldn't assume that the server has been compromised or that a man-in-the-middle attack is taking place. But you might want to look into why the key was changed. 12.3.4.2 Client authentication with SSHThe SSH server runs as the superuser. When a client connects to the SSH server, the client provides the username of the account that it wishes to use. It then provides a suitable authentication credential to prove that it is entitled to the account. If the server is satisfied by the client's credentials, it changes its UID to the user's UID, starts up a copy of the user's shell, and logs in the user. SSH offers a variety of methods for authenticating clients to the server's operating system:
Some or all of these authentication modes can be controlled through commands in the sshd_config file. Table 12-5 contains a sampling of commands implemented by the OpenSSH server. 12.3.5 Telnet (TCP Port 23)Telnet is a service designed to allow you to log onto a remote computer on the Internet. Telnet gives you a "virtual terminal" on the remote computer. The Unix version of Telnet is implemented with the telnet client and telnetd server programs. The client program is quite flexible: in addition to contacting the appropriate servers, the client can be used to open a connection to any TCP/IP-based server that uses a text-based protocol. To use telnet, type the name of the command followed by the name of the computer to which you wish to connect. When you get the prompt, simply log in as if you had called your computer using a modem connected via a hardwired terminal: % telnet prose
Trying...
Connected to prose
Escape character is '^]'
4.3 BSD Unix (prose.cambridge.ma.us)
login: nancy
password: T wrink
The Telnet protocol poses significant risks to its users. The username, password, and all other session data are transmitted over the network without encryption. On many kinds of networks, such as Ethernet, the packets sent between computers are actually delivered to every computer on the physical piece of wire. The computers on the network are programmed to respond only to the packets that are intended for them. But it is possible to program a computer to force it to listen to and record every packet transmitted. Special programs can capture the first hundred characters (or more) sent in both directions on a Telnet connection and thereby capture your username and password. (Wireless networks pose an even worse risk!) Packet sniffing is more than a danger on your local area network because the Telnet session packets are vulnerable throughout their journey. In recent years, there have been many cases of Internet Service Providers who have had a single computer on their internal network compromised; every Telnet connection passing through that ISP had its password captured as a result. The best ways to defeat packet sniffing are through the use of one-time passwords and encryption. A second danger of Telnet is that an attacker can sometimes (especially on older versions of Unix without adequate sequence number randomization) take control of a Telnet session that is in progress using a technique called session hijacking . For example, after you log in using your password, the attacker can seize control of the session and type whatever commands he wishes. The only way to eliminate the possibility of Telnet hijacking is through the use of encryption. Because of the risk of packet sniffing, logging into your computer with Telnet poses a significantly greater security risk than dialing into a computer system using a modem over the public-switched telephone network.
12.3.6 SMTP: Simple Mail Transfer Protocol (TCP Port 25)The Simple Mail Transfer Protocol (SMTP) is an Internet standard for transferring electronic mail between computers. Unix systems implement the SMTP protocol with programs or systems called Message Transfer Agents (MTAs). MTAs usually implement both the client and server sides of the SMTP protocol, although this is not a requirement. It is possible for a user to send email directly using an MTA, but it can be awkward. Instead, users more often employ programs called Message User Agents (MUAs) to send, download, and read their email. Popular MUAs include Eudora, GNU Emacs, MacOS Mail, and Microsoft Outlook. Optimized for interacting with users, rather than for dealing with the vagaries of Internet email, these programs are configured for interacting with a single MTA, and simply dump all of their outgoing email to the designated "SMTP server." Traditionally, Unix systems used the program sendmail as an MTA, although today there are many alternatives, including:
All of these mailers can perform the following functions:
Each of these mail systems has a complex set of configuration files and accessory programs, and each has security risks and advantages. All of them can be run securely, and all of them can be run in a manner that compromises your system's security.
Because of their importance and position on the network, email systems have become an important location for implementing additional security features. For example:
There are a number of security issues arising with SMTP and MTAs that we'll explore in the following sections. These include:
12.3.6.1 Configuration filessendmail uses several configuration files to control its operation, including sendmail.cf, the master configuration file, and .forward files in each user's home directory. Many sendmail configuration files are maintained as text files but compiled into database files; for example, the aliases file is often compiled into aliases.dir and aliases.pag (or a single aliases.db file). Modern versions of sendmail check ownership of all configuration files and directories that contain configuration files, as well as directories where messages are spooled. If a directory of questionable permission is found, sendmail will report an error, such as:[24]
WARNING: writable directory /etc/mail WARNING: writable directory /usr/spool/mqueue 12.3.6.2 Security concerns with SMTP banners and commandsSMTP is a text-based, asynchronous protocol that has been in use since 1983; previous versions of SMTP and MTP were in used in the 1970s.[25] While the protocol itself is quite simple, the functions that an MTA needs to invoke on the host computer to properly satisfy the requirements of the protocol can be quite complex. For this reason, SMTP implementations have been a cause of many security vulnerabilities.
SMTP is also an evolving protocol. In recent years the protocol has been enhanced with mechanisms for sender authentication and encryption. Other functions remain in the protocol but are now largely blocked because of security concerns. When an SMTP server receives a connection, it sends a banner to the SMTP client. Traditionally, this banner included the name and version of the MTA implementing the SMTP server. You can see what banner your SMTP server sends to clients by testing it using the telnet command. For example: % telnet localhost smtp Connected to localhost. Escape character is '^]'. 220 ex.com ESMTP Sendmail 8.11.6/8.11.6 ready at Sat, 20 Jul 02 10:54:29 -0400 EDT In general, it is not good practice for your server to reveal its identity in this fashion. Certain servers have well-known security flaws. By providing its version numbers to all SMTP clients, this server makes it easier for an attacker to scan for vulnerable servers. These banners can usually be changed; consult your SMTP server's documentation. The SMTP protocol has a "help" command that causes the server to display an informative message. Sometimes help messages can contain version numbers as well. For example: % telnet localhost smtp Connected to localhost. Escape character is '^]'. 220 ex.com ESMTP Sendmail at Sat, 20 Jul 2002 10:55:57 -0400 (EDT) help 214-This is Sendmail version 8.11.6 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN 214-For more info use "HELP <topic>". 214-To report bugs in the implementation send email to 214- sendmail-bugs@sendmail.org. 214-For local information send email to Postmaster at your site. 214 End of HELP info Besides leaking information about your MTA version, the SMTP protocol can leak significant information regarding the names and email addresses of users at your organization. Historically, this information has been used most often by individuals and organizations sending bulk email. Thus, you may wish to disable any SMTP commands that leak email addresses. Table 12-6 lists some SMTP commands that have historically had security concerns. You should determine whether you wish to implement these commands at your site; security-conscious sites should implement none of them. You should then periodically test your SMTP servers to determine how they behave when presented with these commands. For example: % telnet localhost smtp Connected to localhost. Escape character is '^]'. 220 rnitroba.com ESMTP Postfix wiz 502 Error: command not implemented debug 502 Error: command not implemented expn simsong@nitroba.com 502 Error: command not implemented vrfy simsong@nitroba.com 252 <simsong@nitroba.com> vrfy nosuchaddress@nitroba.com 252 <nosuchaddress@nitroba.com> help 502 Error: command not implemented 221 Bye Connection closed by foreign host.
Each MTA has its own system for configuring which SMTP commands are implemented. With sendmail, the specific commands are controlled with options that are placed in the file sendmail.cf. This file is usually built from a much shorter sendmail.mc file written in the m4 macro language. Example 12-4 shows a typical sendmail.mc file with several features enabled; this file generates a sendmail.cf file of about 1,500 lines. Example 12-4. A typical sendmail.mc fileVERSIONID(`$Id: ch12.xml,v 1.5 2003/04/09 21:35:32 becki Exp $')
OSTYPE(linux)dnl
DOMAIN(generic)dnl
TRUST_AUTH_MECH(`CRAM-MD5')dnl
FEATURE(`access_db')dnl
FEATURE(`smrsh')dnl
FEATURE('nouucp',`reject')dnl
define(`confSMTP_LOGIN_MSG',`$j smtp service; $b')dnl
define(`confPRIVACY_FLAGS',`goaway,restrictmailq')dnl
MAILER(smtp)dnl
MAILER(local)dnl
MAILER(procmail)dnl
The confSMTP_LOGIN_MSG definition shows how the SMTP banner can be changed to display only the hostname ($j) and the current time ($b). The confPRIVACY_FLAGS definition specifies options that control information leakage; a list of some options that you might wish to use are contained in Table 12-7.
If you are using sendmail and the system responds to the WIZ command with anything other than an error, then you should upgrade to the most recent version of sendmail available. 12.3.6.3 SMTP relaying and bulk email (a.k.a. spam)By design, SMTP servers accept email from the Internet and deliver the mail to its intended destination. When the email is destined for a local mailbox, the mail should be delivered. When the mail is destined for another host, the mail is relayed. Relaying is an integral part of the SMTP protocol and vital to the proper functioning of Internet email. A large organization might have hundreds of individual users with desktop computers that wish to be able to send mail. Managing hundreds of MTAs can be a very hard task; that task can be made manageable if each computer is configured to send outgoing email messages to a single computer, which then relays the messages to the rest of the Internet as appropriate. Relaying can also improve the reliability of receiving Internet messages: many domains will designate secondary mail servers that can receive their mail if the primary mail server is down. This allows for all of the mail to be spooled in a single location and to be delivered in an orderly fashion when the computer comes back up. Unfortunately, SMTP relaying has been exploited by individuals and organizations that send large amounts of bulk electronic mail (sometimes known as spam). These so-called spammers have programs that will connect to another organization's SMTP server and send a single message that has dozens or even hundreds of recipients. Following the design of the protocol, the victim organization's SMTP server will then methodically copy the message and deliver it to each of the recipients, whether they want it or not. To make matters worse, many of the addresses on the spammer's list may no longer be valid. These undeliverable messages frequently end up in the mailbox of the system administrator. Because of abuse by spammers, modern MTAs have provisions designed to prevent or severely restrict the use of the SMTP server for sending third-party email. Here is a typical set of rules:
The configuration technique is different for each MTA. postfix, for example, is configured with a set of "trusted" networks using the mynetworks variable and a mydestination variables; both are set in the file main.cf. 12.3.6.4 Overflowing system mailboxesThe Unix operating system uses accounts without corresponding real users to perform many system functions. Examples of these accounts include uucp, news, and root. Unfortunately, the mail system will happily receive email for these "users." Email delivered to one of these accounts normally goes only to a mail file. There, it resides in your /var/spool/mail directory until it is finally read. On some systems, there is mail waiting for users with the names news or ingres that is more than five years old. Is this a problem? Absolutely:
You can avoid the problem of phantom mail by creating mail aliases for all of your system, nonuser accounts. To make things easy for future system administrators, you should put these aliases at the beginning of your aliases file. For example: # # System aliases # root: debby Postmaster: root usenet: root news: root agent: root sybase: root MAILER-DAEMON: postmaster abuse: postmaster All Internet hosts that run email servers must define a postmaster alias, and mail sent to the postmaster should be promptly read by a human being. Defining an abuse alias is also good practice; if one of your users should send spam through your server, recipients will often expect to be able to report it to this alias. System mailboxes can also be configured so that their messages are gatewayed to locally-managed newsgroups or web pages. Such configuration has the advantage of providing for access by multiple individuals, archiving, and searching. 12.3.6.5 Delivery to programsMail does not have to be delivered to a mailbox; it can also be delivered to a program. One such program is the vacation program, which sends out a polite message telling the sender of the mail that the recipient is on vacation and is not able to respond to messages immediately. Many mailing list programs, such as majordomo and mailman, also work by having the received mail sent to a program, rather than to a mailbox. Because programs that receive mail messages frequently run as a privileged user, they can be a source of security vulnerabilities. These programs potentially receive unrestricted input, so their authors must take extra precautions to validate arguments. Here are some specific recommendations for configuring your email system with respect to mail delivery to programs:
12.3.6.6 Overall security of Berkeley sendmail versus other MTAsEric Allman's sendmail mail system has a long history of security problems. This is not so surprising considering the span of years it has been in use. The first version of sendmail was written as a student project at a time when the Internet was very different from what it is today. When sendmail was originally written, Windows did not exist, uucp over phone lines was the most common form of email transport, the World Wide Web did not exist, there was no commercial use of the network allowed, Ethernets had a maximum speed of 10 Mbps, and the IP-reachable network had a few hundred thousand machines, at most. Some of the problems with sendmail weren't even possible to conceive of when it was written! Be that as it may, there have been dozens of major flaws discovered and publicized in sendmail over the last 20 years. In the 1990s there were so many problems with the program that many security professionals (including us) recommended against using the program. In recent years, sendmail's security has been significantly improved based on a top-to-bottom review and rewrite. Should you use sendmail today? There are many factors that should go into the answering this question:
In the late 1990s many of the sendmail security problems were systematically corrected. Today, sendmail appears to be a reasonably stable and secure email system that enjoys enduring popularity. Only one author of this book is willing to run sendmail on any of his systems, but you may be better off using it if you are familiar with sendmail and you are not familiar with the other systems. As a standard practice in security, if you are familiar with something and can find good documentation and support for it, you are often better off using it than switching to something new in which there is a large learning curve and the potential for dangerous mistakes. 12.3.7 TACACS and TACACS+ (UDP Port 49)TACACS (the Terminal Access Controller Access Control Server) protocol was developed by Cisco and is used to authenticate logins to terminal servers. TACACS defines a set of packet types that can be sent from the terminal server to an authentication server. The LOGIN packet is a query indicating that a user wishes to log into the terminal server. The TACACS server examines the username and password that are present in the LOGIN packet and sends back an ANSWER packet that either accepts the login or rejects it. Additional information, such as assigned IP addresses, can be provided as well. Passwords are not encrypted with TACACS and are thus susceptible to packet sniffing. TACACS+ modifies the TACACS protocol by adding support for encryption. Encryption is performed with a symmetric algorithm using a shared key between the TACACS+ client and server. Although TACACS and TACACS+ are still widely used, many organizations are migrating away from them to RADIUS and LDAP. 12.3.8 Domain Name System (DNS) (TCP and UDP Port 53)The Domain Name System (DNS) is a distributed database that is used so that computers may determine IP addresses from hostnames, determine where to deliver mail within an organization, and determine a hostname from an IP address. The process of using this distributed system is called resolving. When DNS looks up a hostname (or other information), the computer performing the lookup contacts one or more nameservers seeking records that match the hostname that is currently being resolved.[27] One or more nameserver records can be returned in response to a name lookup. Table 12-8 lists some of the kinds of records that are supported.
For example, using DNS, a computer on the Internet might look up the name www.cs.purdue.edu and receive an A record indicating that the computer's IP address is 128.10.19.20. An MX query about the address cs.purdue.edu might return a record indicating that mail for that address should actually be delivered to the machine newman.cs.purdue.edu. You can have multiple MX records, sorted by priority, for robustness; if the first host is unavailable, the program attempting to deliver your electronic mail will try the second, and then the third. Of course, a program trying to deliver email would then have to resolve each of the MX hostnames to determine that computer's IP address. DNS also makes provision for mapping IP addresses back to hostnames. This reverse translation is accomplished with a special domain called IN-ADDR.ARPA, which is populated primarily by PTR records. In this example, attempting to resolve the address 20.19.10.128.IN-ADDR.ARPA would return a PTR record pointing to the hostname, which is lucan.cs.purdue.edu (the CNAME of www.cs.purdue.edu). Besides individual hostname resolutions, DNS also provides a system for downloading a copy of the entire database from a nameserver. This process is called a zone transfer , and this is the process that secondary servers use to obtain a copy of the primary server's database. DNS communicates over both UDP and TCP. Because UDP is a quick, packet-based protocol that allows for limited data transfer, it is typically used for the actual process of hostname resolution. TCP, meanwhile, is most commonly used for transactions that require large, reliable, and sustained data transfer—that is, zone transfers. However, individual queries can be made over TCP as well. 12.3.8.1 DNS zone transfersZone transfers can be a security risk, as they potentially give outsiders a complete list of all of an organization's computers connected to the internal network. Many sites choose to allow UDP DNS packets through their firewalls and routers but explicitly block DNS zone transfers originating at external sites. This design is a compromise between safety and usability: it allows outsiders to determine the IP addresses of each internal computer, but only if the computer's name is already known. You can block zone transfers with a router that can screen packets by blocking incoming TCP connections on port 53.[28] Modern versions of the BIND nameserver implement an allow-transfers directive that allows you to specify the IP addresses of hosts that are allowed to perform zone transfers. This option is useful if you wish to allow zone transfers to a secondary nameserver that is not within your organization, but you don't want to allow zone transfers to anyone else.
For example, this portion of a named.conf file allows zone transfers from the server's IP address 64.1.2.3 to secondary servers located at 18.4.4.4 and 19.3.2.1. (The addresses 127.0.0.1 and 64.1.2.3 allow transfers to be made to the local machine, which is useful for debugging.) options {
directory "/etc/namedb";
transfer-source 64.1.2.3;
allow-transfer {
127.0.0.1;
64.1.2.3;
18.4.4.4;
19.3.2.1;
};
notify yes;
};
12.3.8.2 DNS nameserver attacksBecause many Unix applications use hostnames as the basis for access control lists, an attacker who can gain control of your DNS nameserver or corrupt its contents can use it to break into your systems. There are three fundamental ways that an attacker can cause a nameserver to serve incorrect information:
12.3.8.3 DNSSECDNSSEC (RFC 2535 and 3130) is an extension of DNS that provides for the creation of a DNS-based Public Key Infrastructure (PKI) and the use of this infrastructure in the signing of DNS responses. DNSSEC is an interesting protocol. Proponents have argued convincingly that the use of DNSSEC provides an easy way to bootstrap a global PKI that is not dependent upon certificates sold at high prices by centralized certificate authorities. Unfortunately, because of its populist nature and the fact that nobody really makes money when DNSSEC servers are deployed, there has been very little interest in deploying DNSSEC on a widespread scale. 12.3.8.4 DNS best practicesYou can minimize the possibility of an attacker's modifying or subverting your nameserver by following these recommendations:
You can further protect yourself from nameserver attacks by using IP addresses in your access control lists, rather than by using hostnames. Unfortunately, raw IP addresses can be somewhat harder to manage, as IP addresses can change more frequently than hostnames. Furthermore some programs do not allow the use of IP addresses instead of hostnames. 12.3.9 BOOTP: Bootstrap Protocol, and DHCP: Dynamic Host Configuration Protocol (UDP Ports 67 and 68)The Bootstrap Protocol (BOOTP) and the Dynamic Host Configuration Protocol (DHCP) are designed to dynamically configure devices on a local area network. These protocols are typically used to assign IP addresses to workstations, laptops, and network appliance devices. BOOTP is the original variant of this protocol and dates back to the 1980s. DHCP extended the BOOTP protocol by allowing clients to be assigned leases on specific IP addresses for a certain period of time, and by allowing the delivery of arbitrary name/value pairs to the client as part of the protocol. It dates back to the 1990s and is now widely used. Clients that are configured to use BOOTP transmit a broadcast BOOTREQUEST when they start up. This packet is received by a computer that is running a BOOTP server. The server examines the Ethernet MAC address of the computer making the request, constructs an appropriate response, and sends it in a BOOTREPLY packet. DHCP transactions involve four steps:
Although DHCP can be used to deliver a wide array of information, it is typically used for assigning a host IP address, the IP address of a gateway, one or two DNS servers, and a default domain that the client should use. Because there is no server authentication with DHCP, any DHCP server on the network can answer any DHCP request. A common problem at organizations that use DHCP is that a person who has a copy of Windows 2000 or Windows XP will inadvertently enable the built-in DHCP server. Once this server is enabled, it will invariably send out DHCPOFFER and DHCPACK packets that contain errorneous information. A sufficiently skilled attacker can easily disable or spy on desktops by setting up a rogue DHCP server that provides the wrong IP addresses for nameservers or gateways. If you must use dynamic IP assignment, exercising vigilance—and regularly scanning your network for rogue or accidental DHCP servers—may be your best defense. 12.3.10 TFTP: Trivial File Transfer Protocol (UDP Port 69)The Trivial File Transfer Protocol (TFTP) is a UDP-based file transfer program that provides no security. There is a set of files that the TFTP program is allowed to transmit from your computer, and the program will transmit them to anybody on the Internet who asks for them. One of the main uses of TFTP is to allow workstations to boot over the network; the TFTP protocol is simple enough to be programmed into a small read-only memory chip and is used to download a bootable OS image from a server. Although the TFTP protocol itself has no security, there are two ways that security has been added to tftpd, the TFTP daemon:
You can test your version of tftpd for this restriction with the following sequence: % tftp localhost tftp> get /etc/passwd /tmp/passwd Error code 1: File not found tftp> quit % If the tftp client downloads a copy of your /etc/passwd file, then you have a problem. You should disable the TFTP service immediately. 12.3.11 finger (TCP Port 79)The finger program has three uses:
finger provides a simple, easy-to-use system for making personal information (such as telephone numbers) available to other people. Novice users are often surprised, however, that information that is available on their local machine is also available to anyone on any network to which their local machine is connected. Thus, users should be cautioned to think twice about the information they store using the chfn command, and in their files printed by finger. Likewise, finger makes it easy for intruders to get a list of the users on your system, which dramatically increases the intruders' chances of breaking into your system.[29]
12.3.11.1 The .plan and .project filesMost versions of the Unix finger program display the contents of the .plan and .project files in a person's home directory when that person is "fingered." On older versions of Unix, the finger daemon ran as root. As a result, an intrepid user could read the contents of any file on the system by making her .plan a symbolic link to that file, and then running finger against her own account. One easy way that you can check for this problem is to create a .plan file and change its file mode to 000. Then run finger against your own account. If you see the contents of your .plan file, then your version of fingerd is unsecure and should be replaced or disabled. 12.3.11.2 Disabling fingerThe finger system reveals information that could be used as the basis for a social-engineering attack. For example, an attacker could "finger" a user on the system, determine his name and office number, then call up the system operator and say "Hi, this is Jack Smith. I work in office E15, but I'm at home today. I've forgotten my password; could you please change my password to foo*bar so that I can log on?"[30]
Many system administrators choose to disable the finger system. There are three ways that you can do this:
12.3.12 HTTP, HTTPS: HyperText Transfer Protocol (TCP Ports 80, 443)The HyperText Transfer Protocol is the protocol that is used to request and receive documents from servers on the World Wide Web. Access to the Web has been a driving force behind the growth of the Internet, and many sites that have Internet connectivity are pressured to provide both client applications and web servers for their users. HTTP servers typically listen on port 80; HTTPS servers, which implement secure HTTP by using SSL/TLS, typically listen on port 443. One of the reasons for the success of HTTP is its simplicity. When a client contacts a web server, the client requests a filename to which the server responds with a MIME document formatted in either plain ASCII or HTML (HyperText Markup Language). The document is then displayed.[31]
Web browsers can implement as much (or as little) of HTML as they wish; the documents displayed will still be viewable. HTML documents can have embedded tags for images (which are separately retrieved) and for hypertext links to other documents. The servers are configured so that a specified directory on the system (for example, /usr/local/etc/httpd/htdocs) corresponds with the root directory of the web client (for example, http://www.ora.com/). In many cases, servers are configured so that users can publish HTML documents in a specified subdirectory of their home directories. Because there are many specific security considerations when setting up a web server and using a web client, we have written an entire book on the subject. For further information, consult Web Security, Privacy & Commerce (O'Reilly). 12.3.13 POP, POPS: Post Office Protocol, and IMAP, IMAPS: Internet Message Access Protocol (TCP Ports 109, 110, 143, 993, 995)The Post Office Protocol (POP) is a system that provides users on client machines a way to retrieve their electronic mail from a server. POP Version 3 (also called POP3) allows users to access individual mail messages, set limits on the maximum length of the message that the client wishes to retrieve, and leave mail on the server until the message has been explicitly deleted. POP runs on ports 109 and 110. The POP protocol can be run over SSL/TLS, in which case it is typically called POPS and runs on port 995. The Internet Message Access Protocol (IMAP) performs a similar function, although this protocol allows the client to manage mail messages in multiple mailboxes. IMAP runs on port 143. The IMAP protocol can be run over SSL/TLS, in which case it is typically called IMAPS and runs on port 993. Both POP and IMAP require that users authenticate themselves before they can access their mail. With POP there are several ways to authenticate:
IMAP has an integral authentication system that can use Kerberos, GSSAPI (RFC 1508), or S/Key one-time passwords for authentication. It can also be tunneled over TLS. Note that both your mail server and your mail client must support the authentication system that you wish to use. For example, early Eudora email clients supported only traditional passwords, but later versions include support for both APOP and Kerberos. Outlook Express 5.0 doesn't support Kerberos but does support POP over TLS. 12.3.14 Sun RPC's portmapper (UDP and TCP Ports 111)The portmapper program is used as part of Sun Microsystems' Remote Procedure Call (RPC) system to dynamically assign the TCP and UDP ports used for remote procedure calls. portmapper is thus similar to the inetd daemon, in that it mediates communications between network clients and network servers. Solaris systems are supplied with a version called rpcbind, while most BSD and Linux systems use a reimplementation of portmapper written by Wietse Venema. The RPC portmapper is primarily used by Sun's Network Filesystem. If you wish to use NFS, then you need to run a portmapper. (See Chapter 15 for details.) There is a long history of security flaws with Sun's portmapper. As a result, many security-conscious Solaris sites have replaced Sun's portmapper with Venema's because it allows for finer-grained access control and logging. On the other hand, many of the problems with Sun's portmapper have now been addressed, so you shouldn't be too worried if you don't replace Sun's code. See Chapter 13 for detailed information on RPC. Many sites further restrict access to their portmappers by setting their firewalls to block packets on port 111. 12.3.15 Identification Protocol (TCP Port 113)The Identification Protocol (RFC 1413)—commonly called ident, but sometimes called auth—provides a mechanism to query remote systems for the username that corresponds to a particular TCP connection. Although many protocols provide for the transmission of a username, the Identification Protocol is unique in that the username is provided by the remote operating system itself, rather than by a TCP client or server that is involved in the actual connection. The information is thus constructed and delivered out of band and may be more reliable. For example, if the user albert on computer K1 attempts to open an SSH connection to computer J1 as the user bruce, the SSH server will attempt to log the user into the bruce account. However, the SSH server on J1 can make a request of the computer K1 for the username that was responsible for initiating the connection. Even though albert provided the username bruce to his SSH client, the computer K1 will respond with the username albert to J1's Identification Protocol query (if K1's software is so enabled). Some Unix systems still use the ident daemon to offer this service. Other systems use a built-in server for the Identification Protocol that is part of the Unix inetd daemon. The Identification Protocol can be very useful if you run a timesharing environment with large numbers of Unix users on the same machine. If a remote site reports that one of your users is attempting to break into their system, you can ask the remote site to check their logs. If that remote site initiated Identification Protocol requests for each break-in attempt, you will be provided with the name of the account that was involved in these attempts. Some sites believe that the ident daemon reveals too much information about local users. The ident daemon has an option by which it will respond with user numbers rather than usernames. The theory is that user numbers do not violate the privacy of users and, if the remote site administrator asks politely, they can always be translated back to usernames. The daemon can also be configured to respond with an encrypted string containing the user and connection information as well as the date and time. This encrypted string can later be decrypted if it becomes necessary to investigate an abuse report.[33]
12.3.16 NNTP: Network News Transport Protocol (TCP Port 119)The Network News Transport Protocol (NNTP) is used by many large sites to transport Usenet Netnews articles between news servers. The protocol also allows users on distributed workstations to read news and post messages to the Usenet. There are many servers that implement NNTP, including DNews, WebNews, Diablo, INN, Cyclone NewsRouter, and others. NNTP servers should be configured with an access control list (ACL) that determines which computers are allowed to use which features and access which newsgroups. The ACLs specify which hosts your server will exchange news with and which clients within your organization are allowed to read and post messages. Many organizations have a mix of confidential and nonconfidential information on their news servers; you should use the ACL rules to assure that confidential information does not leave your organization. A compromised NNTP server can represent a serious security threat:
Because many of the information feeds that were once available only over Usenet are now available by mailing list or over the Web, many organizations have decided to discontinue the operation of their NNTP servers. There are other hazards involved in running Netnews:
We recommend caution if you decide to bring a Usenet feed into your organization without a strong business need. 12.3.17 NTP: Network Time Protocol (UDP Port 123)There is an old proverb that a person with two clocks doesn't know what time it is. That proverb assumes that the clocks are not running NTP. The Network Time Protocol (NTP) is a set of protocols that can be used to synchronize the clocks on multiple computers, taking into account issues such as network delay and the fact that different computers are closer (in a network sense) to absolute time standards than other computers. When properly deployed, NTP can be used to synchronize the clocks on large numbers of computers to within a fraction of a second of each other. Clock synchronization is very important:
Fortunately, time synchronization is not only possible, it is easy. The major industrialized governments of the world have agreed on an absolute time standard called International Atomic Time, or TAI. UTC (formerly GMT) is determined relative to the TAI, with the addition of a leap second every few years to bring them back in sync. In the United States, the TAI and the UTC are maintained by the National Institute for Standards and Technology (NIST), and UTC is provided by radio and over the Internet. (See also the sidebar, Telling Time.) With NTP, the system's clock is usually first set when the computer boots using the ntpdate command. After the time is set, the computer runs the ntpd daemon. This daemon constantly monitors the computer's time and exchanges timing information with several other computers. Using some sophisticated algorithms, the daemon then adjusts the computer's clock as necessary. To use NTP properly, you should have a plan for how the correct time is brought into and distributed throughout your network. Ideally, you should have two or three central time servers within your organization. These time servers receive the UTC time signal directly from a special radio, obtain the time from GPS satellites, or receive a time signal from an external network source. The servers then peer with each other—if one server drifts, the data from the others can be used to correct it. Finally, other computers within your organization can receive a time signal from these servers.
The NTP protocol provides for a rich number of configuration options, including the broadcasting of a time signal on local area networks. Consult the NTP documentation for further information regarding configuration. Three primary security concerns arise when using NTP:
12.3.17.1 Sudden changes in timeMany problems can arise if a system's clock is suddenly changed:
For these reasons, the ntpd daemon never adjusts the computer's clock forward by more than a second and never adjusts it backward at all. (Instead of moving the clock backward, it will simply slow the system clock if the system is running too fast.) The ntpd daemon is thus compatible with BSD's higher security levels, at which even the superuser is prevented from making significant changes to the system time.[37]
12.3.17.2 An NTP exampleHere is a sample NTP configuration file that implements many of the requirements we've discussed: # File: ntp.conf server ntp2.usno.navy.mil server time.mit.edu server 18.26.0.36 # ntp-0.lcs.mit.edu server 18.24.10.177 # ntp-1.lcs.mit.edu server 18.111.0.2 # ntp-2.lcs.mit.edu server 18.26.4.10 # ntp-3.lcs.mit.edu peer 192.168.1.2 peer 192.168.1.3 #----- Security # By default, don't let anyone do anything. restrict default notrust nomodify ignore # Trust our sources for time, but not reconfig. restrict 192.5.41.209 nomodify # ntp2.usno.navy.mil restrict 18.72.0.144 nomodify # time.mit.edu restrict 18.26.0.36 nomodify restrict 18.24.10.177 nomodify restrict 18.111.0.2 nomodify restrict 18.26.4.10 nomodify # Local time servers restrict 192.168.1.0 mask 255.255.255.0 nomodify # Trust ourselves for modifications. restrict 127.0.0.1 # Ourselves logfile /var/log/ntp.log logconfig clockall peerall sysall syncall #----- Drift history # Save drift information in a file so NTP converges more quickly # the next time it runs. driftfile /etc/ntp.drift This configuration file takes time service from the U.S. Navy and from five servers at MIT. It peers with two other computers on the local area network. The server can respond to commands that originate on the local host, but no other hosts. Security is based entirely on IP addresses. (In high-security environments, NTP can handle shared secret keys.) 12.3.18 SNMP: Simple Network Management Protocol (UDP Ports 161 and 162)The Simple Network Management Protocol (SNMP) is a protocol designed to allow the remote management of devices on your network. To be managed with SNMP, a device must be able to send and receive UDP packets over a network. SNMP allows for two types of management messages:
SNMP can be of great value to attackers. With carefully constructed SNMP messages, an attacker can learn the internal structure of your network, change your network configuration, and even shut down your operations. Although some SNMP systems include provisions for password-based security, others don't. SNMP Version 2.0 was intended to include better security features, but the proposals never made it past the experimental stage. SNMP Version 3.0 includes standards for improved authentication but is not widely deployed. Each site must therefore judge the value of each particular SNMP service and weigh the value against the risk. If you don't plan to use SNMP, be sure that it's not installed, or at least not enabled, on your Unix system. In 2002, several vulnerabilities were discovered in SNMP implementations that were in wide use (see http://www.cert.org/advisories/CA-2002-03.html for CERT's report). If you must use SNMP, here are some important steps to take:
12.3.19 rexec (TCP Port 512)The remote execution daemon /usr/sbin/rexecd allows users to execute commands on other computers without having to log into them. The client opens up a connection and transmits a message that specifies the username, the password, and the name of the command to execute. As rexecd does not use the trusted host mechanism, it can be issued from any host on the network. However, because rexecd requires that the password be transmitted without encryption over the network, it is susceptible to the same password snooping as telnet. Unlike login and telnet, rexecd provides different error messages for invalid usernames and invalid passwords. If the username that the client program provides is invalid, rexecd returns the error message "Login incorrect." If the username is correct and the password is wrong, however, rexecd returns the error message "Password incorrect." Because of this flaw, an attacker can use rexecd to probe your system for the names of valid accounts and then target those accounts for password-guessing attacks. Unless you have a specific reason for using this service, we strongly recommend that you disable rexec in /etc/inetd.conf. SSH is a better solution. 12.3.20 rlogin and rsh (TCP Ports 513 and 514)The rlogin and rlogind programs provide remote terminal service that is similar to telnet. rlogin is the client program, and rlogind is the server. There are two important differences between rlogin and telnet:
rsh/rshd are similar to rlogin/rlogind, except that instead of logging in the user, they simply allow the user to run a single command on the remote system. rsh is the client program, while rshd is the server. If used from a trusted host or trusted user, rsh/rshd will run the command without requiring a password. Otherwise, a password will be prompted for and, if the password is correct, the program will be run. 12.3.20.1 Trusted hosts and usersTrusted host is a term that was invented by the people who developed the Berkeley Unix networking software. If one host trusts another host, then any user who has the same username on both hosts can log in from the trusted host to the other computer without typing a password. Trusted hosts are specified with entries in the file /etc/hosts.equiv or in an individual user's ~/.rhosts file (discussed later). Trusted users are like trusted hosts, except they are users, not hosts. If you designate a user on another computer as a trusted user for your account, then that user can log into your account without typing a password. A user can trust users on other hosts by creating an entry for each (host/user) pair in the user's file ~/.rhosts. This notion of trust was developed in a small, closed networked environment, and in that environment it had a lot of advantages. Trust allowed a user to provide a password once, the first time he signed on, and then use any other machine in the cluster without having to provide a password a second time. If one user sometimes used the network to log into an account at another organization, then that user could set up the accounts to trust each other, thus speeding up the process of jumping between the two organizations. But trust is also dangerous because there are numerous ways that it can be compromised, especially on today's Internet:
Even worse, a non-Unix system can exploit the trust mechanism by sending packets originating from low-numbered ports structured according to the protocols. Thus, shutting down a system and booting something else in its place, such as a Windows box with custom software, may allow the system to be exploited.
12.3.20.2 Specifying trusted hosts with /etc/hosts.equiv and ~/.rhostsThe /etc/hosts.equiv file contains a list of trusted hosts for your computer. Each line of the file lists a different host. Any hostname listed in hosts.equiv is considered completely trusted; a user who connects with rlogin or rsh from that host will be allowed to log in or execute a command from a local account with the same username without typing a password—with the exception of the root user. The file is scanned from beginning to end, and the scanning stops after the first match. If you have Sun's NIS (or use another system that supports netgroups), you can also extend or remove trust from entire groups of machines. When using Sun's NIS (described in Chapter 14), a line of the form +@hostgroup makes all of the hosts in the network group hostgroup trusted; likewise, a line that has the form -@anotherhostgroup makes all of the hosts in the network group anotherhostgroup specifically not trusted.[38]
Consider this example file: gold.acs.com silver.acs.com platinum.acs.com -@metals +@gasses This file makes your computer trust the computers gold, silver, and platinum in the acs.com domain. Furthermore, your computer will trust all of the machines in the gasses netgroup, except for the hosts that are also in the metals netgroup. After scanning the hosts.equiv file, the rlogind and rshd programs scan the user's home directory for a file called .rhosts. A user's .rhosts file allows each user to build a set of trusted hosts applicable only to that user. For example, suppose that the ~keith/.rhosts file on the math.harvard.edu computer contains the lines: prose.cambridge.ma.us garp.mit.edu With this .rhosts file, a user named keith on prose or on garp can rlogin into keith's account on math without typing a password. A user's .rhosts file can also contain hostname/username pairs extending trust to other usernames. For example, suppose that keith's .rhosts file also contains the line: hydra.gatech.edu lenny In this case, the user named lenny at the host hydra could log into keith's account without providing a password. Because of the obvious risks posted by .rhosts files, many system administrators have chosen to disallow them entirely. There are various approaches to doing this:
12.3.20.3 /etc/hosts.lpd fileOne lasting vestige of the trusted-hosts mechanism is that the Unix lpd system allows only trusted hosts to print on local printers. This restriction presents a security problem because you may wish to let some computers use your printer without making them equivalent hosts. To allow this lesser amount of trust, lpd considers two files: /etc/hosts.equiv and /etc/hosts.lpd. By placing a hostname in the file /etc/hosts.lpd, you let that host use your printers without making it an equivalent host. For example, if you want to let the machines dearth and black use your computer's printer, you can insert their names in /etc/hosts.lpd: % cat /etc/hosts.lpd dearth black % The hosts.lpd file has the same format as the hosts.equiv file. Thus, to allow any computer on the Internet to print on your printer, you could use the following entry: % cat /etc/hosts.lpd + % We do not recommend that you do this, however! 12.3.21 RIP Routed: Routing Internet Protocol (UDP Port 520)The RIP routing protocol is used by Internet gateways to exchange information about new networks and gateways. Several Unix servers have been written to implement this protocol, including routed, gated, and zebra. There are two versions of the RIP protocol. RIPv1 has no security. If your routing daemon is configured to use this protocol, it will happily honor a packet from another computer on the network that says, in effect, "I am the best gateway to get anywhere; send all of your packets to me." Clearly, this trust presents even inexperienced attackers with a simple way to confound your network. Even worse, it gives sophisticated attackers a way to eavesdrop on all of your communications. RIPv2 adds security to the protocol in the form of a shared key. If the routing update is not signed with the shared key, it is not honored. For computers on a network that have a single gateway, there is no reason to run a routing protocol; use static routes instead. If dynamic updates are required, run a DHCP server. 12.3.22 The X Window System (TCP Ports 6000-6063)X is a popular network-based window system that allows many programs to share a single graphical display. X-based programs display their output in windows, which can be either on the same computer on which the program is running or on any other computer on the network. Each graphical device that runs X is controlled by a special program called the X Window Server. Other programs, called X clients, connect to the X Window Server over the network and tell it what to display. Two popular X clients are xterm (the X terminal emulator) and xclock (which displays an analog or digital clock on the screen). 12.3.22.1 /etc/logindevpermMultiuser workstations provide a challenge for X security. On early implementations of X, the logical devices for the keyboard, screen, and sound devices were world-readable and world-writable. This availability caused security problems because it meant that anybody could read the contents of the user's screen or keyboard, or could listen to the microphone in his office. Some versions of Unix have a special file that is used to solve this problem. For example, the file—called /etc/security/console.perms under Red Hat Linux, and /etc/logindevperm under Solaris—specifies a list of devices that should have their owner changed to the account that has logged into the Unix workstation. This approach is similar to the way that /bin/login changes the ownership of tty devices to the person who has logged in using a serial device. Here is a portion of the Solaris /etc/logindevperm file. Under Solaris, the file is read by the /bin/ttymon program. When a person logs onto the device that is listed in the first field, the program sets the device listed in the third field to the UID of the user that has logged in. The mode of the device is set to the value contained in the second field: /dev/console 0600 /dev/mouse:/dev/kbd /dev/console 0600 /dev/sound/* # audio devices /dev/console 0600 /dev/fbs/* # frame buffers /dev/console 0600 /dev/rtvc0 # nachos capture device 0 /dev/console 0400 /dev/rtvcctl0 # nachos control device 0 12.3.22.2 X securityThe X Window System has a simple security model: all or nothing. The X security mechanisms are used to determine whether a client can connect to the X Window Server. After a client successfully connects, that client can exercise complete control over the display. X clients can take over the mouse or the keyboard, send keystrokes to other applications, or even kill the windows associated with other clients. This capability allows considerable flexibility in the creation of new clients. Unfortunately, it also creates a rich opportunity for Trojan horse programs: the multiuser tank war game that you are running in a corner of your screen may actually be covertly monitoring all of the email messages that you type on your keyboard, or may be making a copy of every password that you type. The simplest way for an X client program to monitor your keystrokes is to overlay the entire screen with a transparent, invisible window. Such a program records keystrokes, saves them for later use, and forwards each event to the appropriate subwindows so that the user can't tell if she is being monitored. Release X11R4 introduced a "secure" feature on the xterm command that grabs the input from the keyboard and mouse in such a way that no transparent overlay can intercept the input. The xterm window changes color to show that this is in effect. The option is usually on a pop-up menu that is selected by holding down both the Ctrl key and the left mouse button. This is a partial fix, but it is not complete. Rather than develop a system that uses access control lists and multiple levels of privilege, X instead developed increasingly sophisticated mechanisms for granting or denying this all-or-nothing control. These are listed in Table 12-9.
12.3.22.3 The xhost facilityX maintains a host access control list of all hosts that are allowed to access the X server. The host list is maintained via the xhost command. The host list is always active, no matter what other forms of authentication are used. Thus, you should fully understand the xhost facility and the potential problems that it can create. The xhost command lets users view and change the current list of xhosted hosts. Typing xhost by itself displays a list of the current hosts that may connect to your X Window Server: % xhost prose.cambridge.ma.us next.cambridge.ma.us % You can add a host to the xhost list by supplying a plus sign followed by the host's name on the command line after the xhost command. You can remove a host from the xhost list by supplying its name preceded by a hyphen: % xhost +idr.cambridge.ma.us idr.cambridge.ma.us being added to access control list % xhost next.cambridge.ma.us prose.cambridge.ma.us idr.cambridge.ma.us % xhost -next.cambridge.ma.us next.cambridge.ma.us being removed from access control list % xhost prose.cambridge.ma.us idr.cambridge.ma.us If you xhost a computer, any user on that computer can connect to your X server and issue commands. If a client connects to your X Window Server, removing that host from your xhost list will not terminate the connection. The change will simply prevent future access from that host. If you are using SUN-DES-1 authentication, you can use the xhost command to specify the network principals (users) who are allowed to connect to your X server. The xhost command distinguishes principals from usernames because principals contain an at sign (@). For example, to allow the network principal debby@ora to access your server, you could type: prose% xhost debby@ora If you are using MIT-KERBEROS-5 authentication, you can use the xhost command to specify the Kerberos users who are allowed to connect to your server. Kerberos usernames must be preceded by the string krb5:. For example, if you want to allow the Kerberos user alice to access your server, you would use the command: prose% xhost krb5:alice The file /etc/X0.hosts contains a default list of xhost hosts for X display 0. This file contains a list of lines that determine the default host access to the X display. The format is the same as the xhost command. If a hostname appears by itself or is preceded by a plus sign, that host is allowed. If a hostname appears preceded by a minus sign, that host is denied. If a plus sign appears on a line by itself, access control is disabled. For example, this file allows default access to X display 0 for the hosts oreo and nutterbutter: % cat /etc/X0.hosts - +oreo +nutterbutter If you have more than one display, you can create files /etc/X1.hosts, /etc/X2.hosts, and so forth. 12.3.22.4 Using Xauthority magic cookiesNormally, the Xauthority facility is automatically invoked when you use the xdm display manager. However, you can also enable it manually if you start the X server yourself. To start, you should preload your .Xauthority file with an appropriate key for your display. If you have the Kerberos or Sun Secure RPC mechanisms available, you should use those. Otherwise, you need to create a "magic cookie" for your current session. This cookie should be a random value that is not predictable to an attacker. (The script given in Chapter 19 can be used for this.) You should generate your "cookie" and store it in your .Xauthority file (normally, $HOME/.Xauthority): $ typeset -RZ28 key=$(randbits -n 14)
$ EXPORT XAUTHORITY=${XAUTHORITY:=$HOME/.Xauthority}
$ umask 077
$ rm -f $XAUTHORITY
$ cp /dev/null $XAUTHORITY
$ chmod 600 $XAUTHORITY
$ xauth add $HOSTNAME:$displ . $key
$ xauth add $HOSTNAME/unix:$displ . $key
$ xauth add localhost:$displ . $key
$ unset key
Next, when you start your X server, do so with the -auth option: $ xinit -- -auth $XAUTHORITY All your local client programs will now consult the .Xauthority file to identify the correct "magic cookie" and then send it to the server. If you want to run a program from another machine to display on this one, you will need to export the "cookies" to the other machine. If your home directory is exported with NFS, the file should already be available—you simply need to set the XAUTHORITY environment variable to the pathname of the .Xauthority file (or whatever else you've named it). Otherwise, you can do something similar to: $ xauth extract - $DISPLAY | ssh otherhost xauth merge - Keep in mind that the "magic cookies" in this scheme can be read from your account or found by anyone reading network packets if you're using MIT-MAGIC-COOKIE-1. However, this method is considerably safer than using the xhosts mechanism, and you should use it instead of xhosts when feasible.
12.3.22.5 Tunneling X with SSHOne of the best ways that you can significantly increase the security of X is by tunneling servers on remote X displays to your local display using SSH. Doing this is quite easy: simply log into the remote system with SSH, then start up an X client. When you log into the remote system, SSH can set up an X tunnel and open up a socket on the remote system. Your DISPLAY variable will be set up to use the socket. To use X tunnels, the SSH server must be configured to allow them and the SSH client must request them. For the OpenSSH server, X tunnels are allowed by adding this line to sshd_config: X11Forwarding yes For the OpenSSH client, an X tunnel is requested by giving the -X command-line option or including "ForwardX11 yes" in the ssh_config file. SSH provides a more secure way to use X clients from remote systems. However, if you use X tunneling, be careful: if your remote shell times out or otherwise exits, all of the clients using the tunnel will be killed. 12.3.23 RPC rpc.rexd (TCP Port 512)The rpc.rexd service is a Sun RPC server that allows for remote program execution. Using rpc.rexd, any user who can execute RPC commands on your machine can run arbitrary shell commands. The rpc.rexd daemon is usually started from the /etc/inetd.conf file with the following line: # We are being stupid and running the rexd server without secure RPC: # rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd rpc.rexd As the comment indicates, you should not run the rexd server. We make this warning because running rexd without secure RPC basically leaves your computer wide open, which is why Sun distributes its /etc/inetd.conf file with rexd commented out: # The rexd server provides only minimal # authentication and is often not run. # #rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd rpc.rexd We think that vendors should remove the rexd line from the /etc/inetd.conf file altogether. It would be even better if they didn't install rexd at all. 12.3.24 Communicating with MUDs, Internet Relay Chat (IRC), and Instant MessagingMultiuser Dungeons or Dimensions (MUDs) are text-based virtual world servers that allow many people over a network to interact in the same virtual environment. Most MUDs are recreational, although some MUDs have been created to allow scientists and other professionals to interact. Internet Relay Chat (IRC) is the Citizen's Band radio of the Internet. IRC permits real-time communication between many different people on different computers. Messages can be automatically forwarded from system to system. Instant Messaging (IM) protocols provide for real-time communications between two or more people. Although some IM systems use HTTP as their transport protocol, most use proprietary protocols. AOL Instant Messager, Yahoo! Messenger, and ICQ are three popular Instant Messaging systems. While MUDs, IRC and IM can be useful and entertaining, these systems can also have profound security implications:
 |
|
|
