This site uses advanced css techniques
Almost everybody running a small office wants some kind of remote access: check email, fetch a document, look up a phone number, or run a line-of-business application. It could be just a quick visit to the system while in a hotel on the road, or it could be getting work done while home with the kids on a day off from school.
Unfortunately, there are as many variants on remote-access as there are reasons to want it, and these choices, and choices-within-choices, are often entirely bewildering even to experienced IT staff.
Faced with these requests from multiple customers, we decided to research the field and enumerate the choices available, and (especially) the pros and cons of each. Not all environments are the same, and though we believe some choices are head and shoulders above the others, one must nevertheless weigh the tradeoffs for oneself given the particular circumstances of the given installation.
We're explicitly targeting the small-business space (as noted in the Assumptions), because not only is the corporate space so much larger, but also because we simply have no experience with it. We suspect that many of the points apply universally, but enterprises with thousands of users are different from companies with just a few.
It's our goal for this Tech Tip to be a comprehensive survey of the available remote-access mechanisms, as well as a fair presentation of the pros and cons involved.
It's simply not plausible to think that we can write the definitive paper on remote access for every circumstance, so we have to make some assumptions to narrow the scope of our inquiry. Though many of these notes apply anywhere, we believe that by limiting ourselves to the small office running Windows Small Business Server 2003, we'll hit users most in need of this information.
Most access mechanisms present their own particular set of tradeoffs, but there are some common themes which occur again and again. Here we'd like to elaborate on some of those concerns in some detail.
Since access to email is by far the most common request, and because there are email-only mechanisms, we're putting these in a separate section. By using a limited access mechanism, which doesn't provide more intrusive entry into the network, we can reduce the attack surface of the provided service.
The standard protocols POP (port 110/tcp) and IMAP (port 143/tcp) are mature, quite stable and supported everywhere by all email clients.
|Pro||Works with essentially any email client, including on non-Windows platforms|
|Pro||IMAP can include shared public folders to provide access to shared documents without the use of a VPN.|
|Pro||If DNS is set up properly inside and outside, the same profile works everywhere for roaming users without changing anything.|
|Con||We don't get full-strength Outlook/Exchange integration, including calendaring and shared contacts. However, many mail clients do provide LDAP Directory support for access to the address book.|
|Con||It's really easy to set up insecure connections.|
|Pro||Protocols are well known, and easy to administer in firewalls.|
|Con||Easy target for brute-force password guessing from the outside.|
|Con||Requires a computer configured for this email account; it can't generally be used conveniently from unplanned locations while on the road.|
|Pro||Exchange can control which users can get email this way.|
With this mechanism, SBS exposes the internal Exchange protocol over HTTPS via the webserver, and Outlook thinks it's actually inside the network with full access to everything. It uses the same MAPI connection as the internal client uses, and one is hard-pressed to find any difference in behavior.
This mechanism has been incredibly popular for secure, functional, remote email. It's new with Outlook/Exchange 2003.
|Pro||Full-strength Exchange support using the same Outlook client as used inside the office.|
|Pro||Uses https; fully encrypted|
|Pro||This has been wildly popular.|
|Con||Only supported on Outlook 2003; not Outlook Express, not other email clients, not older Outlook|
|Pro||SBS2003 includes Outlook 2003 software and one client access licence for each SBS CAL; no need to purchase an Office license just toget Outlook 2003.|
|Con||Requires a computer configured for this email account; it can't generally be used from unplanned locations whle on the road.|
|Con||Exchange doesn't seem to offer control over which users can get email this way|
|Con||Because this uses real Outlook, this may not be suitable for laptop devices which might be stolen while containing sensitive data (such as locally-stored attachments).|
OWA is the browser-based Outlook-alike provided by Microsoft Exchange, and it's been available for some years with ever-increasing quality. When visiting the OWA URL on the SBS server (via HTTPS) and presenting login credentials, it brings up a web page which looks and behaves remarkably like the traditional Outlook client.
It supports email, contacts, calendaring - everything which Outlook does, all from any IE browser which allows ActiveX. There are some inherent incompatibilities due to limitations of what can be supported in a browser application, but Microsoft has done a pretty amazing job recreating the look and feel.
|Con||OWA is probably a highly visible target for attackers.|
|Con||It's not quite the same as Outlook.|
|Pro||It works anywhere with essentially no setup, even on machines which you've not been on before while on the road.|
|Con||Because it works so well from anywhere, it can be used from insecure locations, such as an Internet café, where malware (a keylogger) can steal the login information. As the corporate administrator has no way to enforce a "no insecure locations" policy, OWA may not be suitable for users who cannot be trusted to follow security policies.|
|Pro||It's easy to configure with secure transport (https only).|
|Con||Internet Explorer is the only supported browser: the others may work to some degree or other, but it's not considered a bug if it fails to work properly in (say) Firebox or Safari.|
|Con||Provides access to server-based resources only; no desktop-local access. Many users have personal .PST files with email archives and contacts, but these are not visible through OWA.|
|Pro||Exchange can control which users can get email this way.|
|Con||Requires Microsoft Exchange Server; other mailservers such as MDaemon (and many others) won't use it. But most alternate mailservers provide their own web-based email.|
For many users, email-only access is sufficient, but others require more access to the inside network. Whether it's to grab something from one's own desktop, to manage the servers, or to run an internal line-of-business application, there are numerous mechanisms for remote access beyond email.
This does not include, however, the more low-level IP access provided by Virtual Private Networks; that's saved for a later section.
The Remote Desktop Protocol (RDP) is a pcAnywhere-like mechanism for taking over the screen of a remote system, and it's done very well. It can optimize its behavior depending on the quality of the network link, omitting some aspects of the experience (say, the background image) when the network connection is not fast enough.
Generally speaking, the RDP port (3389/tcp) is blocked at the corporate firewall to forestall outsiders, but some have been known to open it up with a pinhole in the rules to allow remote access.
This makes nearly all security-conscious administrators nervous unless the rules can limit access to known-trusted IP address ranges, but even so this is an unnerving prospect.
|Pro||Probably the best network performance of all the remote access|
|Con||Unless the remote user has a fixed IP, firewall can't restrict who gets in; this presents an enormous security risk. Most responsible security administrators hate this idea.|
|Pro||By default, the connection negotiates the highest level of encryption supported by both ends, and for XP and SBS2003, this is High security mode, though it's possible to select less security by turning some knobs. With Group Policy, one can enable enforcement of high security, refusing to allow connections with less.|
|Con||XP desktops only allow one user at a time, so a remote user may kick off one sitting at the console.|
|Pro||RDP supports remote printing; while working on the office desktop from home, one can print through the session to the printer at home. Likewise with audio.|
|Pro||Active Directory has extensive support for per-user permit/deny access to terminal services|
|Con||Installations with many desktops needing remote access have to either allocate a lot of external IPs, or do lots of port mapping in the firewall behind just a few IPs. This is very cumbersome to administer and support.|
SharePoint is Microsoft's web-based collaboration system, and it's a very popular way to organize company documents, discussion lists, tasks, calendering, etc. It's based on IIS and SQL Server, and it integrates directly into the suite of Office tools.
We'll note that SharePoint is worth considering even without the remote-access component: the collaboration facilities are very powerful when adopted by an enterprise, and it's quite straightforward to administer even without heavy-duty IT staff. Just the ability to apply version control to Word/Excel documents is enough to justify the use of this portal tool. SharePoint Services are included in the SBS client access licenses, but are available at extra cost for Server 2003 platforms.
|Pro||Works from anywhere that IE is available with no setup required; great for using while on the road.|
|Pro||For enterprises which actively revolve around SharePoint, this may provide enough access to the collaborative workspace without setting up even higher level IP access|
|Con||Highly visible target for attackers|
The products all require installation of an explicit component on both the host being managed, and on each client which will exercise remote-control abilities.
|Pro||pcAnywhere has a long history of stability and compatibility.|
|Con||Requires licensing both the host and remote parts (in the ballpark of $100 each)|
|Con||Requires installation, activation, and maintenance of a substantial component on the remote client.|
|Pro||Provides the ability to shadow an existing session; this is wildly popular for providing tech support so the technician can jump on a user's desktop directly and see the error or fix the problem.|
This section is incomplete, because we have very limited experience with these other than as a client receiving remote technical support.
In the support scenario, the support-ee visits a central website and performs a one-time installation of a local component (usually an ActiveX control), then joins the session already set up by the support technician.
With appropriate permissions, the desktop can be shared back to the support tech's computer where s/he can take over the keyboard and mouse, transfer files, or whatever else is required to service the support-ee.
It's a great way to get one-time support without the need for the client receiving support having to set up a lot of stuff in advance, though the support organization usually needs to open an account in advance. These usually have per-minute or per-usage charges.
These programs are also gaining popularity for remote access to a person's unattended home or office computer while on the road. At a remote site, the user can hit the central website, present credentials, then take over the controlled PC as if he were sitting at the office directly.
Unlike the ad hoc technical support scenario, where the user in front of the PC being controlled explicitly grants permission (usually twice: once to connect to the desktop, a second time to allow the support technician to "drive" the keyboard and mouse), these uses are unattended.
A somewhat different component is installed on the unattended PC, and it "phones home" periodically to the central server where it awaits a rendesvous with a roaming user wishing to join the session.
|Pro||Very easy client setup for one-time use|
|Con||Typically requires per-use or per-minute charges, and can get costly when used a lot.|
|Pro||Better support than Remote Desktop for multiple monitors on the controlled PC (at least with GoToMyPC); it seems they've figured something out which RDP hasn't yet.|
|Con||The unattended monitored PC has to "phone home" a lot to the central server, and this is reportedly fairly chatty, as well as with unknown security implications that make some people nervous.|
This is an underused feature which is gaining popularity: It's essentially an authenticated RDP proxied through the SBS webserver. The remote user hits an https:// URL on the web server, which immediately demands access credentials. After login, the user is given the choice of machines to connect to, and an Remote Desktop session starts. The target machine again prompts for its own local credentials.
It uses an ActiveX control, which makes a "real" connection to port 4125/tcp (which must be open through the firewall). This is an encrypted RDP connection, which is received by the webserver and proxies to the target system.
As an added security protection, this port is not generally open to accept connections, only listening when it has a specific request for a connection generated via the web interface. It rejects 4125/tcp connection attempts from other than the IP address which requested it, and it's not listening during any other time. This is a very clever, very secure mechanism.
|Pro||Provides secure, remote access to internal desktop via Remote Desktop|
|Pro||Leaves nearly nothing behind on the client after disconnect (e.g., credentials, or other sensitive data)|
|Pro||Heavily secured TCP connection management|
|Pro||Active Directory controls who has access to this facility via the Remote Web Workplace Users group.|
|Con||Not very useful for laptop users on the road who have no "base station" inside the enterprise, though this might be addressed by having one or more standalone XP machines dedicated for these users.|
|Pro||Provides an application-specific tunnel only, not general IP connectivity to the internal network (like a VPN would) which would allow badware to get inside.|
|Con||Requires Internet Explorer to launch and maintain a desktop session (no Firefox, Opera, etc.).|
|Con||No ability to shadow a session: RWW can't be used to provide remote assistance (though it's not clear whether this can be somehow leveraged into the Remote Assistance facility).|
|Con||All RWW users can select from all visible desktops (though they still need credentials to actually login, as well as requiring the right to connect in the first place). This means that one cannot escape thinking about permissions in a domain-wide manner.|
|Con||Seems to require installation of an ActiveX component on the client machine, which has problem problematic in some circumstances (such as a non-admin user). This seems like a minor, one-time inconvenience.|
|Con||RWW doesn't seem to support multiple-monitor desktops (it provides access to just one unified screen), and users have reported their desktop icons moved around after using RWW.|
We don't know anything about this, but will fill it in here once we learn more.
This section was saved for last, because it presents the biggest challenges in terms of tradeoffs, and even in understanding just what's involved.
A Virtual Private Network is what amounts to a software Ethernet cable: a special software "tunnel" is created which carries traffic from one system or network to another, and it's done in a secure manner. By allowing a home user to access corporate resources through the tunnel, access can be granted outside the view of attackers. More information on the background of VPNs can be found on Wikipedia.
VPNs present a special dilemma of remote access: the same power which allows remote users to access nearly everything also provides the power for bad things to happen. Site-to-site VPNs which effectively extend the enterprise IP space to the home greatly increase the attack surface on the enterprise: why try to break into the fortress directly when you can sneak in quietly via the out-building connected by an underground passageway?
There are three common security issues involving VPNs which provide unrestricted routing of IP traffic between the two endpoints (in order of increasing concern):
Most modern VPN solutions address this in a number of ways, including NAT and/or firewalling the VPN connection, and running the machine's default gateway through the tunnel. Both of these involve substantial tradeoffs of security, functionality, and manageability.
We believe that the most intrusive tradeoff is pointing the default gateway through the tunnel: in this scheme, the VPN effectively becomes the internet line for the home PC, and all external access — whether to the corporate office or to the internet at large — goes through the VPN.
In this manner, the corporate firewall has an opportunity to inspect all the traffic coming or going, and may be able to apply content filtering and to enforce other policies. Workers may not be permitted to visit any random site on the internet while on company time, or at least connected to the company network.
Not surprisingly, offsetting the security benefits of this approach are some substantial limitations: unless the corporate network has excellent, high-bandwidth internet connectivity, the home user is going to see very poor performance when accessing non-corporate resources.
Traffic destined to the corporate network can't help but go through the tunnel, but when all the other traffic goes there too, it has to go through the corporate internet circuit twice.
A user requesting a web page from (say) www.unixwiz.net does so with the standard web request, but the small request packet is routed through the VPN tunnel to the firewall/gateway device. It sees that the traffic is destined for the outside world so turns right around and sends it back down the T1 to the website, where a reply is generated by that site.
The reply goes not to the home user, but to the firewall, which again turns the traffic around back through the internet circuit to the user at the other end of the VPN tunnel.
The main factor influencing the performance is the slower of the corporate internet's upload/download speed. For most business-grade circuits such as a T1, the speeds are the same in both directions, but DSL or cable circuits almost always have asymmetric bandwidth, with much slower upstream speeds than download.
There are other complications with the default-gateway approach, so our feeling is that it's not worth the trouble except for limited applications.
Now we'll touch on the various flavors of VPNs available, though in this space there is tremendous variety where vendors go to substantial lengths to differentiate themselves from one another.
Important - when considering the pros and cons of a VPN solution, it's always based on the presumption that this level of access is actually required. When one can use more restricted access (such as email only, or RDP/RWW), this should be considered first.
In this configuration, the end machines themselves are not building the VPN, but intermediate hardware devices do. Our experience has been using SonicWall units at the corporate office, with small Netopia units in the home.
This is clearly the most powerful, but also the most dangerous.
|Pro||By default, provides the least restrictions on IP traffic between the two networks.|
|Con||By default, provides the least restrictions on IP traffic between the two networks.|
|Con||Probably the most costly solution; the home router is amortized over only one user.|
|Pro||More suitable and cost effective for branch offices where multiple users are at the remote location.|
|Con||Provides essentially no audit trail to activities done from the home network.|
|Con||Compromise of even one machine at the home location (say, the computer in the teenager's bedroom) can compromise the entire corporate network.|
|Pro||VPN link security maintained by IT staff, not the user.|
|Pro||Nothing to install, configure, or maintain on the home PC or on the servers.|
|Con||Entirely unsuitable for on-the-road use.|
Here we remove the hardware router from the previous case and replace it with a software component on the user's machine.
|Con||Costs less than hardware, but still nonzero $ per user.|
|Pro||Link security maintained by IT staff through policies.|
|Con||Requires installation of client software on the remote user's machine, and the disturbance of the network stack can introduce compatibility problems with some applications.|
|Con||Accessing multiple unrelated systems at the same time might be impossible because the VPNs.|
|Pro||Ideally suited for laptops on the road.|
A special case of the previous item, this uses the built-in VPN client found in all Windows systems. Using the PPTP (Point-to-Point Tunneling Protocol) service on the SBS system, a user on a home PC can create a VPN with justa few clicks.
|Pro||Remarkably easy setup via the Client Connection Manager link on the SBS server: this may be within the ability of IT staff to walk a sales person through this over the phone.|
|Pro||Outstanding integration with the entire Windows system, including DNS.|
|Con||It's still a VPN with an IP path inside the network.|
|Pro||Great choice for on the road.|
We hope this paper will help the SBS user revisit remote-access needs with a new light on previously-unknown options.
Our two favorite technologies here are Remote Web Workplace and Exchange's RPC over HTTP: they both provide a great mix of utility and security, and each does an outstanding job addressing its particular problem.
Surveying the this space has been much more work than we expected, because we kept finding more categories, and more programs in each category (and each variant had its own twists). We're sure we've missed plenty, and we welcome feedback on them.
Special thanks to the Microsoft Security MVP Community for providing very useful feedback on this paper.
Published: 2006/08/01 (Blogged)