| Now that we have examined many different aspects of VPN integration, let's tie all the VPN concepts together by reviewing a case study. By analyzing a real-world situation, you will gain a much better understanding of the importance of VPN integration issues. We start with a list of requirements and business needs, and then we describe and critique various potential VPN architectures. This gives you some great examples of how to evaluate the strengths and weaknesses of a VPN design. Case Study: Home Users and Multiple Applications A network engineer at your organization has designed a VPN architecture. The purpose of the VPN is to provide limited access to a few corporate applications from employees' home computers. The expectation is that the solution will be used for occasional access primarily on nights and weekends. The user community for this VPN has been fairly well defined, as follows: Approximately 500 remote users exist, who will have an estimated maximum of 50 concurrent connections. Users will access the VPN from their personal computers only, not from corporate computers. The majority of the users will connect to the Internet through broadband access or other high-speed methods, with the remainder using dial-up.
Management has determined which applications and resources must be accessible through the VPN, as follows: The corporate intranet server, which includes many static web pages, as well as several web-based applications. The web pages and some of the applications do not utilize sensitive data, but a few of the applications contain information on personnel and operations that must remain confidential. Microsoft Exchange email, which is accessed through a Microsoft Outlook interface. All users have received training on Microsoft Outlook; therefore, management has mandated that Outlook is the only permitted email client. Because many emails between internal employees contain sensitive, unencrypted data, it is vital that the content of these emails does not pass across the Internet in plain-text format. Also, it is desirable that end users not be able to easily download and store corporate emails on their home computers, primarily for data retention and liability reasons. The corporate mainframe, to which users connect using TN3270 emulation. Only a small percentage of the remote users need mainframe access; however, the data that they will be accessing is sensitive.
Now that we have reviewed the user community characteristics and the business requirements, let's look at a few designs that attempt to meet these needs. Terminal Server Using a terminal server for VPN-like services has some advantages: Because users need secure access to a variety of applicationsMicrosoft Outlook, plus multiple web-based and mainframe-based applicationsa terminal server would provide a single method of accessing all these resources, without requiring changes to the resources. Because all application components are available through the terminal server, users do not need to install business applications, such as mainframe terminal emulators or email clients, on their home computers. A few terminal servers could meet the needs of 50 concurrent users during peak times and provide redundancy in case a single terminal server became unavailable. External users would only directly connect to the terminal server. The terminal server would then initiate its own connections to other hosts as needed.
However, the terminal serverbased design does have some disadvantages: Because users' home computers are being used, the chosen terminal server would need to have clients for several different operating system types and versions. In most cases, the users would have to install terminal server client programs on their home computers, which could require major technical support resources, not to mention the possibility of significant software licensing expenditures. Performance for these users, who are primarily connected to the Internet through dial-up connections, is likely to be sluggish at best and unacceptably slow at worst. Because the screen graphics are transmitted from the server to the client, users with slow network connectivity are likely to become frustrated at times with the performance. Network communications may not be protected adequately if the terminal server permits the usage of weak encryption protocols and too-small encryption key lengths.
Although a terminal server could be used to create a VPN-like solution, some significant issues are associated with it. Let's look at another likely option: an IPSec-based VPN. IPSec An IPSec-based design has several positive features: One IPSec-enabled firewall, or a dedicated IPSec concentrator, should have no problem handling 50 concurrent VPN sessions. External users would be directly connecting to the IPSec-enabled server. Decrypted traffic would then be passed from that host to other hosts. This allows direct connections to internal hosts through the VPN only; therefore, non-VPN users cannot make such connections. Compared to a terminal server solution, performance for IPSec users should be much better over slow connections.
However, IPSec also has some definite disadvantages: As with the terminal server solution, multiple issues are possible with users' home computers. Although many or most of the client hosts may already have IPSec clients installed, the clients still need to be configured on all of the hosts. This is not a trivial undertaking. Users need to have access to the client interfaces for all applications they use. The web-based applications should be easy because virtually every computer has a web browser installed, but the other applications will be considerably more difficult. If users can utilize OWA instead of the full Microsoft Outlook client, they will not need to install Microsoft Outlook on their home computers. However, OWA only has some of Microsoft Outlook's functionality, so more information is required before making a decision. Finally, the users who need mainframe access will have no choice but to install and configure terminal emulator software.
Microsoft Outlook Email Security Over the years, many vulnerabilities in the Microsoft Outlook email client have been well publicized. Countless viruses have taken advantage of these vulnerabilities, sometimes with disastrous results. An alternative to using the full Outlook email program is deploying OWA instead. You can think of OWA as "Outlook Lite." It provides the core Outlook functionality, yet it is a separate program that is completely web based. Therefore, the vulnerabilities that Outlook has generally do not apply to OWA, although it has vulnerabilities of its own. Viruses for Outlook are usually targeted at the full client and not at OWA. Another, less obvious advantage exists for using OWA instead of Outlook for remote users. I used to work at a company that had stringent data-retention policies. All email was automatically deleted from corporate systems after a certain number of days. Also, employees were forbidden by corporate policy from downloading email or any other corporate data to noncorporate workstations. If users were permitted to connect to corporate Exchange servers using the full Outlook client, they would have been downloading emails to their personal computers' hard drives. By using OWA, they were able to retrieve their emails, but because OWA is web based, there was no easy way to download the emails onto their workstations. OWA was helpful to us in supporting corporate data-retention requirements. |
From a purely technical perspective, IPSec is an elegant, robust, and efficient VPN method that definitely meets the needs and requirements as outlined at the beginning of the case study. However, when you consider the potential user and support-related issues, an IPSec-based design might be resource intensive to deploy and maintain. If one of your goals is to minimize user interaction and technical support costs, you might want to consider an alternative VPN method, such as SSL. SSL-Enabled Applications It is obvious that SSL could be used to provide encryption for the web applications and pages on the corporate intranet server. And as previously mentioned, Microsoft's OWA is available to provide a web-based interface to Outlook. OWA traffic can easily be encrypted using SSL because it is based on HTTP. But what about the mainframe access? Well, a little research on the Internet turned up dozens of Java-based TN3270 emulators, several of which have SSL support built in. You can set up a dedicated server that acts as an SSL-enabled TN3270 proxy; users connect to it and are forced to authenticate themselves before then being connected through the proxy to the mainframe. As we did with the first two designs, let's look at the advantages and disadvantages of relying on SSL-enabled applications: The cost of SSL-enabling a server is low, especially when compared with the cost of deploying a terminal server or a VPN concentrator. The performance of the applications should be goodcertainly much better than with a terminal server. To provide sufficient encryption, a small number of users may need to upgrade their web browsers to versions that use 128-bit encryption. Besides a few browser updates, no other installations or configuration should be necessary, with the exception of the small group of users who require mainframe access. Limited resources will be needed to assist them with downloading and configuring the chosen TN3270 emulator. Various changes would need to be made to the required resources. The corporate intranet server would need to be SSL-enabled. More significantly, OWA would need to be deployed, which can be a major project. The TN3270 proxy would also need to be set up, requiring a significant effort. External users would be directly connecting to the intranet and OWA servers. One potential workaround for this is the implementation of a reverse proxy server, which would add at least some degree of separation between external users and internal resources.
The most important unanswered issue at this point is how to authenticate users. If we are allowing users to connect to the intranet server and other resources using SSL, how are we authenticating them? One possibility is to issue digital certificates to all home-based users and then activate checks for SSL client-side certificates, but that might be complex and difficult to support. However, after a user has been authenticated to a particular server through a client-side certificate, the user can run multiple applications on that particular server, if you have configured the server to permit that. This solution provides SSL-based authentication while being relatively convenient for users. Case Study Conclusion Of the three options we have reviewed (terminal server, IPSec, and SSL), which is the best? Although all three can provide the required functionality and meet the identified needs, each has serious weaknesses that must be carefully considered. The best method in this case really depends on what the organization's security policies are, how much risk the organization is willing to incur, and how much money and time it is willing to spend on deploying and maintaining a solution. Unfortunately, there is no "magic answer" as to which method is clearly the right choice. |
