12.3 Primary Unix Network Services
This 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.
Security of Configuration Files and Home DirectoriesIt is very important for the configuration files that control your network services to be properly protected. If they are not, a user of your system could modify the files. Depending on which network service file is modified, this could result in denial of service, loss of privacy, or complete compromise of the system. For example, if your site runs sendmail (discussed later in this chapter) and has a world-writable aliases file, a user could modify the file so that a copy of every email message that you receive is sent to another address. Alternatively, an attacker could set up an alias to run a program; when email is sent to that alias address, the program will be run as a privileged user. Likewise, if an attacker can change the contents of a user's .forward file, the attacker can redirect a user's mail. It is not sufficient to assure the security of the individual configuration files: you need to assure the security of the directory containing the configuration files, and all of the directories that contain that directory, all the way back to the system's root directory. In general, none of these directories should be world- or group-writable, and they should all be owned by the superuser. (The notable exception to this rule is the home directories of users who have per-user configuration files; these home directories must be owned by the user, not by root.) |
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]
[14] However, blocking packets for a service using a host-based firewall can be used to block access to a service running on either a local machine or a remote machine, with the caveat that the service won't be blocked if it is running on a port other than the one that you specify. One particularly common siutation in which blocking outbound access can be useful is when an ISP wants all outgoing mail from its clients to be relayed by the ISP's SMTP server (to make it easier for the ISP to detect spammers). By installing a firewall on its network that blocks packets destined to port 25 on any host other than the ISP's SMTP server, the ISP can prevent its clients from running their own SMTP servers and relaying Internet mail.
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:
When you use FTP to contact a remote machine, the remote computer requires that you log in by providing your username and password; FTP logins are usually recorded on the remote machine in the /usr/adm/wtmp file. Because the passwords typed to FTP are transmitted unencrypted over the network, they can be intercepted (as with the telnet and rexec commands) by an attacker with a packet sniffer.
Because of its use of arbitrary ports, active FTP doesn't mix well with packet-filtering firewalls on the FTP server.
FTP is a powerful protocol with more than 50 commands. FTP allows the remote user to change working directories, list directories, and even send site-specific commands to the remote system. Because of this richness, there are many opportunities for implementation flaws that could produce security vulnerabilities.
Even without implementation flaws, many sites do not wish to give FTP users the ability to switch directories and explore the FTP server's filesystem. To minimize this problem, some FTP servers have provisions for restricting the user's access using the chroot( ) system call.
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]
[15] For sites that need to provide FTP connectivity, there are a few products that provide wrappers that can be installed on client and server hosts to transparently encrypt the password or the entire connection. SafeTP (http://safetp.cs.berkeley.edu) is one example.
12.3.3.1 Anonymous FTP
The 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:
[16] Some older servers require that you specify "anonymous" for anonymous FTP; most servers accept either username.
% 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 mode
The 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:
Active mode complicates the construction of firewalls because the firewall must anticipate the connection from the FTP server back to the FTP client program and permit that connection through the firewall.[17]
[17] Firewalls that employ stateful inspection can usually do this by allowing data connections to individual ports based on its understanding of the state?that the connection is related to an existing FTP control connection.
If the firewall employs Network Address Translation (NAT), the firewall must monitor the contents of the FTP control channel and rewrite it so that the IP address sent to the remote IP server is the external IP address, and not the internal, translated IP address.
Active mode can be used to attack a site and make it look as if the attack is coming from the FTP server, rather than from the attacker. This is called an FTP bounce attack, and it was documented in CERT Advisory CA-1997-27 (http://www.cert.org/advisories/CA-1997-27.html). A bounce attack can also be used to direct an FTP server to attack computers on a network that is not accessible to the attacker but is accessible to the FTP server.
To prevent an FTP bounce attack, your FTP server must be configured so that it will open only TCP connections to the host from which the FTP control channel originates. This "fix" violates the FTP RFC, but it is not clear that the ability to initiate third-party FTP transfers should have been put in the RFC in the first place.
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 mode
Under 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 server
If you wish to provide FTP service, you have two primary choices regarding your FTP server:
You can use the standard Unix ftpd that comes with your system. Depending on your Unix vendor, this version may or may not be secure. Over the years, many security problems have been found with versions of ftpd. Some vendors have been quick to implement the necessary bug fixes; others have not.
You can use an alternative FTP server. There are many to choose from these days, including:
- bftpd
-
A fast and small FTP server written by Max-Wilhelm Bruker.
- Muddleftpd
-
An FTP daemon that is billed as being "simple to set up, fast, secure, and reasonably lightweight."
- NcFTPD
-
A commercial FTP server optimized for anonymous FTP access that does not start additional child processes for incoming connections.
- oftpd
-
An FTP server described as being "as secure as an anonymous FTP server can possibly be!" because it runs (mostly) as non-root and runs within its own chroot( ) environment.
- ProFTPD
-
A highly configurable, GPL-licensed FTP server.
- PureFTPd
-
Designed to be a simple and secure FTP server.
- twoftpd
-
Another FTP server that "strives to be simple, secure, and efficient." The two in "twoftpd" comes from the fact that there are two parts to the server?a frontend that does authentication and does no file transfer, and a backend that does file transfer but does no authentication. The back end runs in a chroot( ) environment.
- wu-ftpd
-
An FTP server originally written at Washington University in Saint Louis. The wuftpd server has many useful options that allow you to create different categories of FTP users, set limits on the number of simultaneous file transfers, and save network bandwidth (by automatically compressing and archiving files as they are transferred).
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 server
There 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.
[18] Note that /etc/shells is also used by chsh as a list of allowable shells to change to.
12.3.3.6 Setting up anonymous FTP with the standard Unix FTP server
Setting 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:
- bin
-
This directory holds a copy of the /bin/ls program, which ftpd uses to list files. If your system uses dynamic linking and shared libraries, you must either install programs that are statically linked or install the dynamic libraries in the appropriate directory (e.g., /var/spool/ftp/lib).
- etc
-
This directory holds a version of the /etc/passwd and (optionally) /etc/group files, which are put there so the /bin/ls command will print usernames and groupnames when it lists files. Replace the encrypted passwords in these files with asterisks. Some security-conscious sites may wish to delete some or all account names from the passwd file. The only account name that needs to be present is ftp. (Actually, if neither file exists, most FTP servers will still work normally.)[19]
[19] Some FTP administrators have been known to create bogus password and group files, with random character strings in the password field. We have heard stories of miscreants who thought they found a badly-configured FTP service, downloaded these files, and then burned weeks of CPU time trying to crack the "passwords." At least a few sites have actual accounts and passwords in these files; however, these are passwords to "jails" that are carefully crafted to look like real accounts, but that are used to gather information about potential intruders. We don't recommend this approach for the average user, but we do find it amusing to note.
- pub
-
This directory, short for "public," holds the files that are actually made available for anonymous FTP transfer. You can have as many subdirectories as you wish in the pub directory.
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]
[20] You may wish to use a permission of 1777 instead, if you wish to allow anonymous drop-off into the ~ftp/pub directory. But see the sidebar entitled "Don't Be Warezed!" first.
# 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.
Don't Be Warezed!Years ago, organizations that ran FTP servers would routinely create an "open" directory on their servers so that users on the network could leave files for users of the system. Unfortunately, software and music pirates and purveyors of pornography soon started using those directories as repositories for illegally copied programs, files of stolen passwords, and nasty pictures. Collectively, such contraband is known as warez. Today, if you have a directory on an anonymous FTP server that is writable by the FTP user, the odds are quite high that it eventually will be discovered and used in this manner. If this happens, you may be contributing to large-scale software or media theft; you will also find that your Internet connection's bandwidth is quickly filled up, making it unusable for practically anything else. Of course, some sites still wish to create "depository" directories on their FTP servers so that users on the network can leave files for users of their system. The correct way to do so is to create a depository that is carefully controlled and automatically emptied:
Alternatively, you can set up an email account that can accept large attachments, or create a small web application that allows users to upload files of a given size. Be sure to test your handiwork, and good luck! |
[21] If you are using the wu archive server, you can configure it in such a way that uploaded files are uploaded in mode 004, so they cannot be downloaded by another client. This provides better protection than simply making the directory unreadable, as it prevents people from uploading files and then telling their friends the exact filename to download (before your script can move the file). If you are writing your own server, this is a good idea to include in your code.
12.3.3.7 Allowing only FTP access
Sometimes, 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]
[22] If you are using wuftpd, note that there is a feature which allows a similar configuration.
Create a shell script /bin/ftponly, which prints a polite error message if the user attempts to log into his account. Here is an example:
#!/bin/sh /bin/cat << XX You may use FTP to put files on this computer, but you may not use this account to login. -The Management XX /usr/bin/sleep 10
Create your user account with /bin/ftponly as its shell:
kelly:Mqu3lQJ41kf/E:502:20:Jim Kelly:/Users/kelly:/bin/ftponly
Finally, add the file /bin/ftponly to the file /etc/shells:[23]
[23] On AIX, shells must be added to the /etc/security/login.cfg file.
# List of acceptable shells for chsh/passwd -s # Ftpd will not allow users to connect who do not have one of # these shells # /bin/sh /bin/csh /bin/ftponly
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.
Isolated Services Offer Additional SecurityTwo of the oldest principles of security are minimization and separation of function. You can use these two principles to have a more secure FTP server (and a more secure web server, too). You do this by configuring a separate, standalone machine as your server. Don't put any user accounts on it. Remove all the commands and libraries that aren't needed. If you have the source to build the kernel, build it with only the options needed to support your server. Then load the server with additional security software alarms and logging. If the server has no other services running, then those services can't be points of attack. If there are no user accounts on your machine, there is no way to break into them. And if the software and kernel have been minimized, that reduces the chances of a future bug being discovered that gives away the system. As a side effect, you might find that you can get a lot out of an older machine?without all those other services and users, you don't use as much disk of CPU, and the unused resources can thus remain available for use by your server! You can buy a perfectly serviceable, somewhat older computer for a few hundred dollars in the U.S. You may even have one sitting in storage because it wasn't fast enough to run the latest bloated software release that management wanted installed. The cost will be minimal, but the protection gained will be well worth it. |
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 SSH
Every 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:
It assures that you are connecting to the correct host. If the host you intend to connect to has changed its IP address or has a new DNS name (or if somebody has attacked your DNS system and it is handing out the wrong IP addresses), the SSH client will note that the new host has a different HostKey from the older address and you will, presumably, not provide your password.
It assures that you will have an encrypted connection directly to the remote server, and that no intermediate machine is engaging in a man-in-the-middle attack. For a successful man-in-the-middle attack to take place, an attacker would need to provide his own public key?a public key to which he presumably had the matching private key. (An attacker mounting a man-in-the-middle attack would not provide the HostKey of the server under attack because if he did, he would be unable to decrypt the resulting communications.)
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 SSH
The 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:
Clients can provide a valid password for the account on the remote server.
Clients can prove their identities using public key cryptography if the client presents a public key that is in the file ~/.ssh/authorized_keys and can decrypt information that is encrypted with that public key.
Clients can provide a username and come from a host that is listed in the user's ~/.rhosts or ~/.shosts file. The host must be a host that is listed in the user's ~/.ssh/known_hosts file.
Clients can provide a username and come from "trusted hosts" listed in the /etc/hosts.equiv or /etc/ssh/shosts.equiv file. The hosts can be authenticated solely on the basis of DNS, in which case this authentication system is equivalent to the authentication system used by the Berkeley "r" commands (rsh, rcp, and rlogin). The host can also be authenticated using its SSH host key if the public key is stored in the file /etc/ssh_known_hosts on the server's computer.
Clients can authenticate using Kerberos.
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.
|
Command |
Meaning |
|---|---|
|
HostKey filename |
Specifies the location of the host's RSA key. |
|
HostDsaKey filename |
Specifies the location of the host's DSA key. |
|
ServerKeyBits nnn |
Specifies the number of bits in the server's RSA key. Longer keys offer more security but increase the amount of time required to log in to the remote hosts. In 2002, a typical compromise between speed and security was 768 bits; by 2004, a better value might be 1,024 bits or even 2,048 bits. |
|
PermitRootLogin [yes|no] |
Specifies whether or not the superuser should be allowed to log into the system using SSH. Unless you have a specific reason to allow the superuser to log in remotely (for example, so that a script can be automatically run as root from a remote machine), this value should be no. |
|
IgnoreRhosts [yes|no] |
If yes, users may not specify trusted hosts in their ~/.rhosts and ~/.shosts files. |
|
RhostsAuthentication [yes|no] |
If yes, use the trusted host mechanism to allow remote authentications. Applies only to SSH1. Not recommended. |
|
RHostsRSAAuthentication [yes|no] |
If yes, use the trusted host mechanism for hosts in rhosts files with keys in /etc/ssh_known_hosts. Applies only to SSH1. |
|
HostbasedAuthentication [yes|no] |
If yes, use the trusted host mechanism for hosts in rhosts files with keys in /etc/ssh_known_hosts. Applies only to SSH2. |
|
RSAauthentication [yes|no] |
Allows users to authenticate using a personal RSA public key. Applies only to SSH1. |
|
PubkeyAuthentication [yes|no] |
Allows users to authenticate using a personal RSA or DSA public key. Applies only to SSH2. |
|
PasswordAuthentication [yes|no] |
Allows users to authenticate using a password. |
|
ChallengeResponseAuthentication [yes|no] |
Allows users to authenticate using a system-defined challenge/response protocol like S/Key or Kerberos. This feature requires operating system support. |
|
PermitEmptyPasswords [yes|no] |
If no, then accounts without passwords may not be accessed using SSH. |
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:
- exim
-
A popular MTA developed at the University of Cambridge. Because it is distributed under the GPL, exim is the default mailer on many Linux systems. exim is designed to be scalable, secure, and easy to configure.
- postfix
-
A full-featured Internet email system for Unix developed by Wietse Venema as a drop-in replacement for sendmail. postfix was designed to be a secure mailer capable of high throughput. Unlike sendmail, the postfix system is implemented with many small programs, each of which is designed to perform a specific task. postfix is used by many ISPs.
- qmail
-
A full-featured Internet email system for Unix developed by Dan Bernstein. Like postfix, qmail was designed as a secure MTA capable of high throughput. If you use qmail, we recommend that you replace inetd with Bernstein's tcpserver program.
- sendmail
-
Written by Eric Allman, the first Unix mail system to implement Internet standard mail protocols. This program was distributed as part of the original Berkeley 4.2 Unix distribution and since that time has been distributed with the vast majority of Unix distributions since. By many accounts, sendmail remains the most widely used mailer on the Internet today. Because of its long history, sendmail has undergone numerous revisions.
All of these mailers can perform the following functions:
Deliver mail to individual user mailboxes or to files.
Implement a list of aliases that specify rewriting rules for email addresses. Aliases can also be used to create simple mailing lists. Aliases are traditionally located in the aliases file, usually in the /usr/lib, /etc, /etc/mail, or /etc/sendmail directories. Some Unix mailers can also use aliases that are stored in databases.
Determine if an email message should be sent to another machine, and automatically send it to that machine using SMTP.
Pipe mail messages to programs as standard input.
Provide a command-line utility for sending email. This program, traditionally called sendmail, is used primarily by scripts and programs to send email.
Allow individual users to set up an alias for their accounts by placing a file with the name .forward in their home directories.
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:
Many viruses for Windows-based computers propagate by sending themselves to other Windows users via email. By automatically scanning all email messages for known viruses and dropping messages that contain viruses, it is possible to protect users of Microsoft operating systems from some hostile programs that might otherwise compromise their computer systems.
Many individuals who send out unwanted email, otherwise known as spam, do so using "throw-away" accounts that they purchase on a "trial" basis from ISPs. By limiting the number of email messages that a user can send to 500 or 1,000 per day, ISPs and other organizations can effectively prevent their users from enga
