15.5 Secure Remote Access and Content Updating

only for RuBoard - do not distribute or recompile

Once you have your web server up and running, securely logged and monitored, you will next be faced with a troubling real-world question: how will your users update the web server's content?

In the early days of the World Wide Web, most content was created live on web servers by programmers and developers using Unix text editors such as emacs and vi. These days most content is created on desktop PCs and Macs and then uploaded to the web server. This upload is fundamentally a file transfer operation. Unfortunately, a holdover of the U.S. government's two-decade war on cryptography is that the Internet's most common file transfer protocol, FTP, sends usernames and passwords without first encrypting them. This makes the protocol vulnerable to password sniffing.

15.5.1 The Risk of Password Sniffing

Password sniffing is a significant security risk on the Internet today. Passwords sent without encryption can be intercepted by a network monitor program and conveyed to attackers. Stolen passwords can be used to rewrite web pages and break into other Internet accounts. When the stolen passwords belong to system administrators with additional security privileges, even more serious mayhem can be wrought.

Unfortunately, usernames and passwords sent unencrypted over the Internet remain one of the most common ways of authenticating users on the network today. Plaintext passwords are widely used by many Internet protocols, including remote login (Telnet/rlogin), file transfer (FTP), remote email reading (POP3/IMAP), and web access (HTTP).

15.5.2 Using Encryption to Protect Against Sniffing

The only general way to defeat password sniffing is to avoid using plaintext usernames and reusable passwords, or employ encryption. There are three likely alternatives:

Use a token-based authentication system: Examples are the SecurID system from Security Dynamics (see Figure 15-3) or the SecureNet Key from Digital Pathways. These tokens are actually small hand-held computers that allow you to use a different password every time you log into the remote site. As the eavesdroppers do not posses the token, they cannot access your account at a later time.

Figure 15-3. Security Dynamics' SecurID card (reprinted with permission)

Use a nonreusable password system: An example is S/Key. With S/Key, users are given printouts with a list of hundreds of passwords. Each time they use a password, they cross it out, and use the next one (see Figure 15-4).

Figure 15-4. S/Key uses nonreusable passwords

Use a system that relies on encryption: Doing so prevents the sending of your password in the clear over the network. These systems include Kerberos, Secure Shell (ssh), Secure Copy (scp), and Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Encryption schemes can be used with conventional reusable passwords, with nonreusable passwords such as S/Key for additional protection, or with a public key digital signature certificate system.

Windows NT file sharing uses a one-way hash for sending encrypted passwords over a local area network, but these passwords can be "cracked" using a suitable program. Be careful; by default, Windows NT and 2000 operate in a "compatibility" mode which allows legacy Windows for Workgroups and Windows 95 systems to connect without using encryption. And even when "encryption" is enabled on a Windows system, the Microsoft file sharing protocol only encrypts passwords: usernames and the contents of files are still sent in the clear. What's more, since authentication only takes place at the beginning of the TCP/IP session, NT file share connections can be hijacked once a session has been authenticated. Overall, Windows NT file sharing offers more security than plaintext protocols such as FTP, but less security than protocols such as scp.

Cryptographic techniques have the advantage of encrypting all information transmitted between the two network computers. They also protect ongoing connections from session hijacking, which occurs when an attacker seizes control of a network session after a legitimate user has authenticated. Unfortunately, encryption schemes require that you have specially modified versions of both the Internet servers and clients for each protocol that you wish to protect. There are also interoperability concerns because of encryption restrictions by various governments and proprietary incompatibilities.

Encryption can be staged at one or more levels:

Application level: In the most specific cases, applications can be written or retrofitted for secured transfer. Because the encryption and authentication are typically negotiated in the application's client/server handshake, sessions are limited to individual protocols or services.
Transport/network level: Encryption at the transport layer (e.g., TCP/IP) or network layer (e.g., IP), on the other hand, can often be applied to a variety of services. Potentially, the encryption will be transparent to the application; system network services can substitute encrypted transport for nonencrypted transport without affecting the application. SSL and TLS are examples of transport-level encryption standards.
Network level: Virtual private networks (VPNs) are typically built upon standards for network-level encryption and authentication. The IPSec proposal is quickly becoming the de facto VPN standard (see RFCs 1825 through 1829). Note that the degree of encryption available to you depends on where the secured session is conducted; government restrictions limit the extent of cryptographic methods.

We strongly recommend the use of encryption to protect all administrative Telnet and file transfer sessions between a web server and an administrative workstation. If possible, encryption should be used to protect all Telnet and file transfer sessions.

15.5.3 Secure Content Updating

Most organizations create their web documents on a different computer from their web server and then transfer those documents to the server when they are completed. It is therefore important for these organizations to have a technique for securely gaining access to their web servers to update these files.

In the best circumstances, the web server will be secured behind its own network interface on the company firewall. This will place the server logically "outside," yet still afford it protection from the firewall. You can then cut an outbound channel extending from the internal LAN through the firewall and out to the server for updates. (We show this configuration in Chapter 2.)

Secure update access is a little trickier when the web server is situated remotely. A few of the tools mentioned here have built-in security features. These should be supplemented with address-based filtering or challenge/response mechanisms, if possible. However, the safest way to provide unfettered remote update access is through an encrypted, authenticated VPN connection; access will be secured, and traffic will be protected from packet sniffing.

Here are a few possible server update methods:

Copy the files using the scpcryptographic protocol or a file synchronization system over ssh.
Manually copy the files one at a time or directory-by-directory using FTP.
Copy them using a Unix-specific protocol, such as rcp or rdist.
Have the web server access the files from a file server using a network file transfer protocol such as Network File System (NFS).
For NT-based web servers, allow SMB (NetBIOS) file sharing across the firewall or even (with great care) across the Internet.
Perform a physical transfer using tape or removable disk.

All of these techniques have advantages and disadvantages.

scp/ssh

The scp (secure copy) program is one of the most secure ways that you can use to update files on a remote server. The scp program is a part of the Secure Shell (ssh) distribution. It encrypts all file transfers and can optionally use public key certificates for authentication. Using encryption eliminates the possibility of password sniffing. The program is available for Windows, Mac OS, and Unix. scp can even recursively copy whole directories.

One problem with scp is that it will transfer files from your desktop to the remote server, but it will not delete files from the remote server when they are no longer needed. If you want synchronization, rather than replication, you may wish to consider one of the file synchronization programs that are now available for Unix shown in Table 15-2. All of these programs can use ssh as their underlying transport, which provides for encryption and reliable authentication

Table 15-2. Synchronization programs for Unix and Windows that use ssh as the transport layer
Program	Platforms	Comments
rdist, rdist6	Unix	Allows for "distfiles" that will copy the same content to multiple machines at the same time. A fast approach.
rsync	Unix	Offers more control than rdist. Has a clever update system for transferring log files.
unison	Unix, Windows	Allows for two-way synchronization between multiple computers. File deletion is handled through the use of metainformation stored with each ynchronization set.
Interarchy	Mac OS	A full-fledged FTP client that can transfer files to or from the Mac using FTP or HTTP. It has commands to transfer whole hierarchies and to mirror hierarchies. At Version 5, Interarchy has an "ftp disk" option that will create a local mirror of a remote FTP hierarchy: you update the local copy, and Interarchy mirrors the copy on the remote site.

Using SSH and FTP Together

The FTP protocol uses two ports on the server: port 21 for the control connection and (usually) port 20 for the data connection. The portion of the connection that you need to be concerned with is what flows to port 21, because that is the stream that includes your password.

One way to configure ssh to support FTP is to set the local ssh client to relay local connections to port 21 on to your web server machine's port 21. Then configure your local FTP client to use "passive" FTP mode when transferring files, and open your FTP connection to host localhost (IP 127.0.0.1) (not to the actual web server host!).

What will happen is that your FTP control communication will flow directly to your local port 21 without going across the net. ssh will encrypt the traffic and pass it to the remote web server. The web server will open a data port (not port 20), and return the number and IP address of the port over the encrypted link. Your client then connects directly to the web server host to perform the transfer. This approach protects your password and username, but does not incur the overhead of encrypting all the data flowing back and forth.

FTP

The advantage of the FTP protocol is that there are a wide number of FTP clients available for computers running nearly every operating system including OS/2, Windows, Mac OS, and Unix. Thus, if you rely on FTP to update files, many people will be able to update them. On the other hand, most FTP servers have provision only for simple username and password authentication. As previously noted, passwords sent in the clear over the Internet can easily be sniffed. It is possible, however, to employ stronger authentication systems with FTP, such as S/Key or the SecureID card. The FTP control channel can also be tunneled over ssh (see the sidebar).

Unix rcp or rdist

Using a Unix-specific protocol such as rcp or rdist has the advantage that many of these protocols have already been modified to allow for increased security. If you are going to use rcp or rdist, you might wish to use a version that uses the Kerberos protocol for authentication. The rdist program can also be run over ssh, as described previously. Using encryption eliminates the possibility of password sniffing. Unfortunately, you will need to use specially adapted clients with these servers.

Another advantage of rcp is that you can use a .rhost file, which allows you to perform authentication based on IP addresses. Although this approach makes your computer vulnerable to IP spoofing an attack that happens when one computer sends out IP packets that claim to be from another the risk of password sniffing is considerably greater. There is only one widely publicized case in which IP spoofing was used to break into a computer, while there are literally thousands of recorded instances in which password sniffers were used by crackers to break into systems. Furthermore, you can configure your network's routers to automatically reject incoming IP packets that claim to be from your internal network, greatly improving your site's resistance to IP spoofing attacks. (Of course, this doesn't help you if the web server is out on the Internet.)

NFS

Using a distributed filesystem such as NFS to provide content to your web server is an intriguing idea. You can have the web server mount the NFS filesystem read-only. The NFS server should likewise export the filesystem read-only, and it should only export the filesystem that contains web server files. An advantage of this system is that it gives you an easy way to update the web server's content without actually logging in to the web server. Another advantage is that you can have multiple web servers access the same NFS filesystem.

The primary disadvantage of using a read-only NFS filesystem to provide files to your web server is that there can be significant performance penalties using NFS. You can minimize this impact by using a web cache between the web server and the rest of the Internet, or by using an ultra-high-performance NFS appliance server. The speed of NFS is also not a factor for web pages that are programmatically generated: the overhead of the CGI scripts far outweighs the overhead of NFS.

SMB

Providing for Windows file sharing (SMB) traffic to NT-based web servers will let you take advantage of web tools that depend on shares. The trick is to make sure that necessary ports (137/TCP, 138/UDP, and 139/TCP) are invisible to anyone else on the Internet. You can ensure that this is the case with address filtering and appropriate spoof-checking, or by conducting traffic within a VPN tunnel. The danger with this approach is that you expose more than you intended: printing, access to default shares, and other logon and system registry information become visible, too.

Whether or not you plan to connect to a remote NT-based web server with Windows file sharing, there are a few precautions you should take before wheeling the web server out past the moat:

Disable guest logins altogether. Guest logins are enabled by default on NT Workstation and may be enabled by an administrator on the Server version. Likewise, toss out any extra logins that you don't absolutely need.
Disable administrative logins from the network, if possible. If you must administer the server remotely, then change the name of the "Administrator" account to something else, so that it will be more difficult for an attacker to guess. You can use IP filters to further reduce the chance that an attacker will gain access to your remote administration system.^[13]

^[13] Because the remote machine may not be available to participate in WINS (and it certainly won't be answering broadcasts), you may need to make an entry in lmhosts on local clients or on local WINS servers.

Physical transfer

Transferring the files using physical media is very attractive for some installations. No network-capable services are required, and thus none are vulnerable. On the down side, such transfers require physical access to both the server and the development system for each installed change.

15.5.4 Dialup Modems

In this age of Internet access, it's easy to forget that modems still offer attackers a back door. Many organizations have modems that allow relatively unrestricted access to their networks, servers, and workstations. Modems can be installed to allow remote access and power-cycling of equipment in the event that a primary Internet connection fails. Given the opportunity, many employees will set up modems on their desktop computers with programs like Carbon Copy or pcANYWHERE, so that they can access their computers while working at home. Finally, many building and environmental systems, including elevators, HVAC equipment, and even pay phones are equipped with dialup modems for remote control.

There is nothing inherently secure about a dialup modem that requires callers to enter a username and a password before access is granted. The problem is that many dialup modems do not require even this most basic of remote authentication protocols. As we noted earlier about Pete Shipley's survey of modems, approximately 2% of the ones he found did not have passwords in place.

Organizations should establish policies as to whether or not employees and system operators can set up their own dialup modems. The policy should state who has the authority to set up dialup modems, how they should be secured, and whether or not the phone numbers need to be centrally reported.

Once a policy is in place, organizations should perform routine telephone scans to verify compliance with their policy. Several telephone scanners are now available, including:

PhoneSweep by Sandstorm Enterprises: The first commercial telephone scanner. Developed in part by Simson Garfinkel, PhoneSweep is a high-speed scanner that can dial with up to 16 phone lines at a time. It has an expert system that can recognize more than 300 kinds of remote access systems. Information is available at http://www.sandstorm.net/.
TeleSweep by Securelogix: A telephone scanner that has a feature set that is similar to PhoneSweep's. Information can be found at http://www.securelogix.com/.
THL-SCAN: A DOS-based scanner developed primarily for the computer underground.
Toneloc: Another DOS-based program that can scan up to an entire telephone exchange with a single modem. Toneloc's features were designed for the computer underground, but it is widely used by computer consultants and organizations.

For organizations that require the highest degree of security, several companies now sell telephone firewalls. (Firewalls are described in the next section.) These systems sit between an organization's PBX and the outside world and monitor both incoming and outgoing telephone calls for the telltale signs of fax or modem communications. If a fax or modem tone is detected originating or terminating at an unauthorized line, the telephone firewall automatically terminates the call. One of the most widely used telephone firewalls is TeleWall by Securelogix.

only for RuBoard - do not distribute or recompile

15.5 Secure Remote Access and Content Updating