Building Scalable Remote Access by Mike Fratto  Security Issues It is important when planning a remote-access solution to keep your organization's security policy in mind. Modems and remote-access servers are a back door into your network. Protecting that backdoor is important, but if security is too tight, your users won't be able to get work done and making changes will be extremely difficult. Of course, you'll want to limit the unauthorized access to your network and one of the most effective ways of ensuring that is to make the login process as simple and straightforward as possible. You don't want your users to maintain several userid/password pairs because they will eventually end up written down, tucked in a drawer or under a blotter. Likewise, forcing the general user population to change their passwords periodically is equally problemati c because the passwords will start to get written down after the third or fourth change. For users who require access to security areas, on the other hand, this forced-change policy makes sense and comes with the job. You'll also have several levels of remote access users where security is concerned. General users may simply need to access e-mail and local files, while network administrators may have to access sensitive data, authenticate to secure servers, and perform other critical tasks. Finding and applying the appropriate level of security for each is a difficult task. Some of the important pieces of the security puzzle are: Authentication Unfortunately, there are few straightforward provisions for providing user authentication on the network via remote access. All remote-access servers provide some user authentication, account administration, and auditing features, but for large installations, you're not likely to want to mirror your user lists across multiple devices. Furthermore, authentication against most directory services is limited to simple login access; after that the user can try to access any network device he or she can see. Out-Boun d In-bound security is only half the issue with remote access; if there are modems on the network, chances are they can be used to dial out. Many remote-access devices offer comm port redirectors that logically connect a network modem to a comm port on the client. If you plan on providing dial-out services, be sure that you have fairly strong reporting and security mechanisms in place to track usage for departmental billing and to ensure the dial-out isn't being abused. Secure Users If you have sensitive network data going across your remote access system or you will have system administrators dialing in, you'll want to look at remote-access servers that implement a token passing security scheme. A one-time password is generated by a small credit card-size device the user carries. It is perhaps one of the most secure ways to grant high-level access across insecure links. User Management For more robust authentication and user management, look to an authentication server such as TACACS or RADIUS. These servers proxy authentication requests between the remote-access server and the user database. The advantage to using the TACACS or RADIUS servers for remote-access authentication is, with a greater degree of control, you can configure the access properties for users from a centrally managed user database, rather than replicating user databases. (For a detailed discussion of TACACS and RADIUS see Plugging Holes with Remote Authentication , by Dan Backman and Christopher Smith, December 15, 1996, page 112) You have to consider not only security at the access point, but also session security as well. It does you little good to have a secure login procedure only to pass business data in the clear. Proprietary applications provide some encrypted sessions, but in general network traffic travels over the wire in the clear. Two security schemes are being developed to address the need for a general purpose encryption method: Distributed Computing Environment (DCE) and virtual private networks (VPN). Both of these protocols are relatively young and require a large amount of support to implement. But if you have a low aversion to risk and the talent in-house to step out on the edge, either one of these solutions may be viable for a cross-platform secure remote-access solution. DCE provides a single sign-on user scheme to devices and services on the network. It is intended to be cross-platform, and for the most part you can find DCE servers for nearly every NOS. However, to enjoy the benefits of encrypted sessions, your applications have to be Kerberos aware. Currently the list of Kerberos aware applications is relatively small, but growing. Since DCE is an Open System Foundation project, it is becoming more widely supported. Keep in mind tha t the DCE clients use quite a bit of resources while running. Virtual private networks promise to provide a more robust and generic method of encrypting sessions by creating an encrypted IP session between a client and host where all traffic is encrypted. VPN doesn't provide any user management, rather it is a protocol for exchanging data and making a WAN appear to users and network devices to be on the same subnet. Of course, VPNs are proprietary at the time of this writing and until IPSec of IPv6 is finalized, don't look for any real interoperability between vendors. Updated January 17, 1997 Print This Page E-mail this URL