i-Planet's RemotePassage
The network manager's job, which is fundamentally to provide access to corporate information and computing resources, is typically confounded by Internet-based applications and services. Users want to be able to access their data (so they can do their jobs effectively), and administrators want users to be able to access information effectively, but at the same time, these resources must be protected from outsiders who would put the company at risk.
Most administrators address this conundrum by implementing a general purpose firewall. By blocking all incoming traffic from the Internet, administrators are able to secure the network, although unfortunately the users that have a legitimate need for that data are also crippled in the process.
i-Planet's RemotePassage access server solves this dilemma effectively and gracefully. Instead of providing a general purpose firewall that blocks all incoming traffic, RemotePassage uses authentication to determine who is able to access the resources on the network. Rather than expose all of the internal resources to the outside world, RemotePassage opens the network selectively, to users who have a legitimate need for the information.
Authenticated Access is the Key
The RemotePassage server keeps a single public web server port open to the outside world that any user on the Internet can connect to. Users who can reliably authenticate themselves to the RemotePassage server (using S/KEY challenge-response authentication) are then granted access to the private network. All other users are denied any access whatsoever.
The cornerstone of the authentication process is the use of one-time S/KEY passwords, generated by the user as needed. Then, when the user connects to the public server, they provide their account name, PIN, and a one-time password to the server to establish their credentials. The user must then provide their system username and password before gaining access to the network resources.
One of the weaker areas of this process is the use of an insecure web server for the authentication process itself. Users connecting to the RemotePassage server provide their S/KEY username, PIN and one-time password over a clear HTTP session, which compromises half of the S/KEY security model. By using non-encrypted HTTP, it is easy for anybody with a protocol analyzer to sniff the userís S/KEY account and PIN; all thatís needed at that point is one of the predefined, one-time passwords, which are typically printed out by their users. We were very disappointed that the authentication process did not use SSL to encrypt the authentication process, as this would prevent the easy detection of the S/KEY usernames and PINs, preserving the S/KEY security model.
Integrated Access to Corporate Filesystems
RemotePassage also provides a web-based proxy for filesystems on the local network. As shown in Figure 1, remote users are able to connect to shared filesystems on UNIX, Windows and NetWare servers, from within the SSL-encrypted browser session. Because this SSL session runs on a random port that is determined by RemotePassage after authentication has occurred, bandits cannot simply connect to this SSL session and access your internal filesystems without first authenticating to the server.
Once a user has selected the filesystem they wish to access, a Java applet is launched that allows them to browse the directories and files on that filesystem. Users can recursively search a directory tree for a specific file, or they can double-click on a file to download it, or they can use RemotePassageís integrated SMTP server to mail the file to another user (without having to download the file into their local mail client first). Other functions include the ability to upload a file to the server, or to compress a file using RemotePassageís CPU (without having to download the uncompressed file first).
In reality, the support for "UNIX" filesystems is simply an FTP client, and does not provide access to UNIX-based NFS servers on the network. The FTP client is pretty good, although we were unable to connect to the FTP server running on our test IntranetWare server, nor were we able to connect to our Windows 95 client system using WRQís Reflection FTP server. Although the system is only meant to support UNIX-based FTP servers, we think this is too fine a restriction for such a broad protocol. We would rather see support for NFS servers in general, with the added support for a broad base of FTP servers as well.
The Windows/LAN Manager networking agent uses an SMB client, which allowed us to connect to shared resources on Windows 95, Windows NT and Linux-based SAMBA servers without difficulty. The SMB client only supports NetBIOS-over-TCP/IP servers however, and does not provide connectivity to NetBEUI-based workstations, although this is probably not much of a concern outside smaller networks.
The third major component of the filesystem access service is an integrated NetWare client that can be used to redirect file I/O between the Java-based file manager and the NetWare servers on the internal network. Once we had connected to a NetWare volume from the Java applet, we found that the application could not display long filenames on the NetWare servers. Even though we had the LONG.NAM and NFS.NAM namespaces loaded on our NetWare volumes, the client would only display them in DOS 8.3 format. Long filenames are supported on the FTP and SMB clients, and we expected to see them here as well.
Even though there are many areas we would like to see improved upon, overall the product gives us secure and authenticated access to our internal network resources cleanly and easily, simply by using a Java-aware web browser. We donít need to configure NetWare/IP on our LAN, nor open our NFS, SMB or NetWare/IP servers to the firewall, but can instead simply use the same web browser. We also liked having the ability to proxy our mail and internal web servers through the RemotePassage server, without also exposing those ports to the outside world. Overall, this product earns very high marks on both these points.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 1997 Eric A. Hall.