Managing Remote Access to Your Intranet
Ramon J. Hontanon As systems and network administrators strive to fortify the perimeter defense around their intranets, the need to provide remote access looms over their heads. The traveling sales force needs to access their email; the evergrowing ranks of telecommuters demand real-time access to their files on the corporate server; the new overseas subsidiary wants the latest product baseline for a customer demo. But, what's a diligent network administrator to do? With the explosion of the Internet, focus has shifted away from direct remote access (via phone lines and dial-in servers) toward virtual private networks (VPN) and secure intranet access. Today's administrators seek to use the Internet as a non-trusted medium that can be used to link private corporate networks with some degree of transparency. Corporations also want to harness the ubiquitous nature of the 'Net by allowing roving users to remotely tap into the corporate resources. As a result, the dividing line between private and public access is becoming increasingly blurry, and it's up to the administrator to draw a clear distinction between the two. Clearly, the pressure is on to provide convenient remote access, while ensuring that overall network security is not compromised. The good news is that secure remote access to the corporate network does not have to be awkward, or even costly. A good security policy, enforced by a robust set of security mechanisms, will ensure safe and convenient access to the most sensitive of intranets. No amount of security software and hardware, however, will guarantee a bullet-proof defense, unless a good security policy is outlined, implemented, and enforced. Access rights must be defined and granted to the appropriate users; sensitive data must be identified and properly labeled. Physical security cannot be neglected. Even the most stringent access control systems can be easily bypassed by an unlocked computer room door, a system console left unattended, or a printed list of passwords left on the systems administrator's desk. Once the security policy has been defined, you're ready to survey the tools and mechanisms available to provide secure remote access to the enterprise computing resources. While there is a wide array of commercial solutions available (especially in the VPN arena), the public domain also offers some good alternatives. It is often helpful to classify security tools by the ISO layer where the service is provided, and in this article I will present freely available tools that operate at the Network, Transport, and Application layers, along with a discussion of S/KEY, a cryptography-based authentication mechanism. Network Layer Security SunScreen SKIP By encrypting traffic at the IP layer, Sun Microsystems' SunScreen SKIP effectively establishes a secure VPN between the client and the server, where both authentication and confidentiality are guaranteed end-to-end. This scheme ranks high in both flexibility and transparency, because there is no need to modify clients to use the secure channel. The Simple Key-management for Internet Protocol (SKIP) was proposed in 1994 (by Sun Microsystems' Ashar Aziz and Whitfield Diffie) and immediately placed in the public domain in an effort to establish an open standard for managing cryptographic keys. SKIP aims to address one of the most prevalent challenges facing cryptography today: how to distribute secret keys in a secure, but efficient manner. While public key technology is widely used for encrypting email messages and large text documents, real-time encryption of network traffic is carried out almost exclusively using secret key cryptography. When a SKIP client wishes to establish a secure network connection with a remote SKIP server, they first need to agree on a shared "secret" that will be used to encrypt all subsequent traffic. While it is possible for both parties to mutually agree on a good long-term shared secret, the longer this secret is in use, the higher the likelihood that it will be compromised. In an effort to minimize this risk, SKIP provides the ability to dynamically negotiate a "short-term" shared secret, using both parties' public keys for authenticating one another. Note that SKIP's only requirement is that both parties' public keys be certified by a commonly trusted authority. The SunScreen SKIP software can generate keys of 512, 1024, and 2048 bits in length. Longer keys ensure stronger confidentiality and authentication, but due to current export regulations, only the 512 and 1024-bit versions are exportable outside the United States and Canada. SunScreen SKIP is available for both Solaris 2.X and Microsoft Windows (95 and NT), and its main advantage over other security solutions is its transparency. Because it works at the IP layer, there is no need to replace, or even modify the current remote access applications. Advantages Disadvantages Open standard New technology Transparency Authentication introduces overhead Application independence in the TCP/IP stack Transport Layer Security SOCKS5 Originally designed by David and Michelle Koblas, the SOCKS protocol is a generic proxy mechanism for Internet connection management and security. A typical SOCKS firewall installation includes a SOCKS proxy server and a set of clients that have been modified to contact the proxy before requesting services from the network. Recently approved by the IETF as an Internet Standard (RFC 1928), SOCKS is quickly becoming the proxy protocol of choice by security vendors. Both Netscape and Microsoft support SOCKS in their latest Web browsers. The current SOCKS v.5 implementation by NEC-USA is freely available, and includes both UNIX and Windows NT versions of the SOCKS5 proxy server. It also includes a SOCKS5 library and a set of modified clients, complete with source code. There is also a very useful utility called "SocksCap", that effectively "SOCKSifies" existing Windows95 network applications so they can be run unmodified. SocksCap can be easily loaded onto corporate laptops for transparent, authenticated access to the intranet via the SOCKS5 proxy server. By using a SOCKS5 proxy server on a dual-homed machine, administrators can set up a single point of entry to their intranet without having to provide direct IP connectivity to the Internet. Remote clients must contact the SOCKS5 proxy server in order to gain access to the corporate resources. Once the SOCKS5 server has received a request for access, it can consult the access control list and grant or deny the request based on the client's IP address, the type of service requested (e.g., telnet, WWW, SMTP), and even the username making the request. SOCKS5 gives the network manager the ability to implement more fine-grained access policies than those at the network level, where access can only be enforced according to the requester's IP address. SOCKS5 supports authentication based on source and destination IP address, TCP port, username/password combination (RFC1929) as well as the Generic Security Service Application Programming Interface (GSS-API, RFC1961), which also supports message integrity and confidentiality. In addition to its security features, SOCKS5 provides a valuable tool for network administration, monitoring, logging, and usage analysis of network connections. Access control lists can be modified dynamically, and extensive connection logging can be used for intrusion detection, performance management, and capacity planning. Another useful feature of SOCKS5 proxy servers is that they can be easily configured to masquerade internal addresses from the public Internet, which effectively eliminates the need to obtain official IP addresses for intranet hosts. This comes especially handy at a time when legitimate IPv4 addresses seem to be in extremely short supply.
Advantages Disadvantages Open systems Need to modify existing network standard protocol applications IP Address masquerading Subject to IP spoofing attacks TCP Wrappers For each network service offered by a UNIX host, there is a corresponding daemon process that listens for incoming connections on a specific "well known" TCP port (e.g., port 23 for telnet, and 21 for ftp). Once the network administrator has decided to offer a specific service, any host can connect to the server on that TCP port, which poses a clear security threat. TCP Wrappers, (created by Wietse Venema, at Eindhoven University of Technology, The Netherlands) provides an extra layer of security that network administrators can use to control access to specific TCP services. The operation of TCP Wrappers is based on the concept of a "generic" TCP server, known as tcpd, which intercepts all incoming requests normally bound toward the UNIX inetd master daemon. Once the tcpd wrapper has verified the requester's IP address against its access control list, the request is forwarded to the appropriate daemon (e.g., telnetd, ftpd), and the wrapper quietly steps out of the picture. As an example, TCP Wrappers would make it trivial to configure the corporate UNIX server to grant SMTP access to all remote hosts, while restricting telnet access to your telecommuters only and granting ftp-only access to your overseas subsidiaries. That way, they can grab the latest product baseline without gaining access to any other corporate services. TCP Wrappers maintains detailed logs of both successful and unsuccessful connection attempts, including IP address, TCP port, and request time. This can be a valuable tool in hunting down would-be intruders before they gain access to the intranet.
Advantages Disadvantages Easy installation and Does not handle UDP traffic configuration Subject to IP spoofing attacks Extensive connection logging Application Layer Security TIS Firewall Toolkit (fwtk) Trusted Information Systems (TIS) offers a set of publicly available security utilities that can be used to build a custom firewall solution on a UNIX platform. The kit includes an authentication server (authd), several application-specific proxy servers (telnet, ftp, rlogin), as well as smap, an SMTP security wrapper. Each of these components can be installed in isolation, and, in fact, no effort is made to provide a total "turnkey" firewall solution. For this reason, the TIS firewall toolkit often requires more UNIX and security expertise than other security products presented here. One of the most peculiar, and potentially useful components of the TIS-fwtk is the smap utility. Most corporate networks allow incoming SMTP connections to their mail servers, but it is well known that the UNIX sendmail daemon presents a security threat, stemming from the fact that it must be executed as root (in privileged mode). The smap daemon runs under the ownership of a non-privileged user, and its only role is to accept email messages on behalf of the sendmail process. These messages are placed in a temporary spool directory, where they will remain until smapd collects them, and forwards them to sendmail for processing and delivery. By avoiding a direct connection between outside users and the sendmail daemon, smap can help keep sendmail vulnerabilities in check, while still allowing unrestricted SMTP connections from the public Internet.
Advantages Disadvantages Easily customizable UNIX support only Source code available Not a "turnkey" solution The UNIX "r" Commands The often infamous UNIX "r" commands (rlogin, rcp, rsh, rdist) are the epitome of remote access convenience. After all, what could be easier than using a simple rcp command to move a file across hosts, with no need to step through a whole ftp session? By using host-based authentication, the "r" commands allow users to carry their access rights across different hosts, just as long as the two hosts "trust" each other. In reality, these commands pose a security threat, due to the "transitive trust" problem. Consider a network where host A and host B trust each other. Host A also trusts C. By the power of transitive trust, a user on host C will be able to gain access to host B without a password, even though host B does not explicitly trust host C. In light of this potential problem, it is common wisdom to simply disable "r" commands on corporate servers accessible from the Internet. In the next section, I present a secure alternative to these commands.
Advantages Disadvantages Convenient access to files "Transitive trust" security threat on other hosts Subject to IP spoofing SSH As mentioned in the previous section, the convenience of UNIX "r" commands comes at a price. With no way to verify the authenticity of the requester's IP address, remote shell commands pose a threat that most network administrators can live without, that is, unless the remote shell command comes with a convincing dose of authentication and confidentiality. The Secure Shell (SSH), created by Finland's Tatu Ylonen, relies on the concept of public key cryptography, a proven mechanism already exploited by applications like PGP and SunScreen SKIP. In fact, SSH operates using the same concept that drives the SKIP protocol. Both client and server authenticate each other by encrypting a message with each other's public key and by verifying that the other party can decrypt it using their corresponding private keys. Once they have verified each other's identities, both parties exchange a secret session key, which used to encrypt all traffic exchanges for the remainder of the shell session. The SSH package comes complete with a secure replacement for rlogin (slogin) as well as a secure rcp (scp). In its current version, SSH supports the DES, Triple-DES, IDEA, and "blowfish" secret key algorithms for encryption, as well as the Rivest-Shamir-Adleman (RSA) public key algorithm for authentication.
Advantages Disadvantages Provides authentication and confidentiality Need to use modified "r" clients Key management can be arduous Good compromise ofsecurity and convenience APOP The Post Office Protocol v.3 (POP3) as defined in RFC1725 is currently the Internet standard for fetching electronic mail from a remote mailbox. Since it is not feasible for all hosts to have permanent connections to the Internet, the POP protocol allows mail clients on personal computers to "fetch" email messages from remote, well-connected servers where their email is stored until they're ready to retrieve it. Corporate POP servers are typically made accessible from the Internet to allow "road warriors" to receive their email from their laptops. While POP3 is a convenient service, it also harbors a very serious security hazard in that the username and password used to authenticate the POP3 user travel over the network in the clear. Thus, by using very simple "sniffing" tools, an attacker could obtain the remote user's password and use it for unauthorized entry to many other services. But, hidden deep inside RFC1725 lies the solution to this problem. The APOP command is an extension to the POP3 command set, which allows the user to encrypt her password before sending it to the POP3 server. APOP's operation is very straightforward: when a POP3 server supports the APOP extension, it displays a timestamp on its banner greeting. The client then takes this timestamp, augments the password, and computes a cryptographic "message digest" using the MD5 algorithm (RFC1321). The client then offers the resulting digest to the server for authentication. The POP3 server carries out the same operation, and compares the result to the digest obtained from the client. If the two match, the client is granted POP3 access. The following sample exchange illustrates the APOP login sequence:
Server:
Client:
Server:
In this instance, user "rwarrior" computes an MD5 digest "sdf0osdf08sdf09sd8f" using the timestamp "199.434534" along with her assigned password. The server authenticates the digest, and grants the user access to her mailbox. By using cryptography, the APOP command ensures that the POP3 authentication exchange is kept confidential, and protects the password from packet-sniffing attacks. This is of vital importance to organizations in which a single username/password combination can be used to gain access to all the other services available on the intranet. According to RFC1725, implementation of the APOP extension is not mandatory. However, newer versions of popular mail packages like Pegasus and Eudora (and the Qpopper POP3 server) are already supporting it. Note that for a POP3 server to support APOP, it must store a clear-text version of all the user passwords. Needless to say, network administrators should go to great lengths to ensure that these passwords are not compromised.
Advantages Disadvantages Internet standard Not widely supported Easy to implement Server needs to store clear-text passwords
Cryptographic Authentication S/KEY Password-based schemes are the most popular way of authenticating user identity before granting or denying access to secure resources. Users are required to provide a password for accessing remote hosts, downloading files, checking mail, and even logging on to their own desktop systems. But every time users type their password, they are compromising security by exposing their password to network sniffers, trojan horses, or even casual eavesdropping attacks. To minimize the exposure of user passwords, Bellcore's Leslie Lamport developed the S/Key system. By exploiting the concept of "one-time passwords," S/Key allows the user to generate a list of passwords that can be used to access intranet resources from the Internet. S/Key uses the MD4 message digest cryptograpy algorithm to encrypt a random "seed" value into a short string of characters that can be used a a one-time password. Successive invocations of S/Key generate additional passwords that can be stored in a laptop and used for remote access later. The strength of S/Key lies in the fact that the next password is cryptographically related to the current password, but cannot be derived from it. This means that even if a password is successfully captured by an attacker, the next password in the list cannot be easily deducted from it. Unlike other cryptography-based password systems, S/Key is implemented entirely on software and is freely available from the public domain. Putting It All Together Using the tools presented in this article, it is possible to implement a remote access policy that will permit convenient access to the corporate intranet while protecting its resources from both unauthorized access and malicious attacks. The key to a secure access policy lies in both its design and its day-to-day enforcement. A good design should include a multi-layer approach to security. Although it may seem sufficient to implement a network-based scheme, such as SunScreen SKIP, it is often necessary to also implement transport layer (SOCKS, TCP-Wrappers) and application layer (SSH, APOP) schemes. Security threats exist at every layer, and although a good network layer defense may protect your intranet against most types of attacks, a determined intruder may exploit the weaknesses of the transport, or the application layers instead. It is important to prioritize the intranet services offered to the public Internet and evaluate the convenience versus security tradeoff for each. If a decision is made to offer a service for remote access, it is best to adopt a "least privilege" approach, in which access rights are denied to everyone by default, and only awarded to authorized users on an individual basis. Although no one approach will guarantee that your network assets are completely secure, a well-designed, and carefully implemented security policy will go a long way toward minimizing the frequency and severity of network attacks. Finally, don't forget to conduct periodic reviews and self-audits of your remote access security policy. Availability SunScreen SKIP: http://www.sun.com/security/skip SOCKS5: http://www.socks.nec.com TCP-Wrappers: ftp://ftp.win.tue.nl/pub/security TIS Firewall Toolkit: http://www.tis.com/prodserv/fwtk SSH: http://www.cs.hut.fi/ssh Eudora-APOP: ftp://ftp.qualcomm.com/eudora S/Key: http://yak.net/skey About the Author
Ramon J. Hontanon is a network security engineer at Predictive Systems' Mid-Atlantic region, located in Herndon, VA. He specializes in security and performance management of large enterprise networks. He can be reached at ramon.hontanon@predictive.com.
|