The quick and easy way to create an SSL VPN

A few weeks back, I mentioned to one of my colleagues that I was looking to find a secure method of getting into my home network from wherever I happen to be and he recommended his friend’s SSL VPN product – SSL-Explorer.

I should also add that the aforementioned colleague has since taken a position with 3SP, the creators of SSL-Explorer (good luck Chris), but I have no such conflicts of interest – I’m simply writing about a product that’s I’ve found to be very useful.

According to 3SP:

“SSL-Explorer is the world’s first open-source, browser-based SSL VPN solution. This unique remote access solution provides users and businesses alike with a means of securely accessing network resources from outside the network perimeter using only a standard web browser.”

The community edition of SSL-Explorer is an open source product licensed under the GNU general public license (GPL) and the enterprise edition builds on this to provide additional functionality for organisations who require enhanced features and dedicated commercial support.

I used a (remarkably) similar product from Neoteris a few years back; however that required a dedicated appliance server and was a commercial product. There’s also the OpenSSL project but, despite earlier versions of SSL-Explorer requiring compilation using Apache Ant, the installer I used (v0.2.8_01) required no such effort and I was amazed at how quickly I was able to install SSL-Explorer onto a standard Windows server (I could also have used a Linux box). Furthermore, despite not yet being a version 1 product (and using Java, which I’m not a fan of), SSL-Explorer seems to be remarkably stable.

Through SSL-Explorer, I can provide users with access to file shares (read-only or read-write – and the product only enumerates those folders for which the user has access), reverse proxy to internal web servers (including single sign-on to Outlook Web Access) and access internal servers (using RDP or VNC – other modules are also available). Some features require an agent to be loaded on the fly but the SSL-Explorer product is still a clientless VPN (all interaction is within a web browser). Management is via a web interface and self-signed certificates can be used (for those of us who don’t have the budget to buy third party certificates).

I still have some issues with the remote desktop functionality from behind my employer’s proxy server; however I suspect that is related to the ISA Server configuration in use – SSL-Explorer is working perfectly from other networks. I also operate using a single NATted IP address, so if I want to forward all HTTPS traffic from my firewall to the SSL-Explorer server then I can’t do the same for any other web servers that I might like to expose to the Internet directly (at least not on the same port).

Of course, there are other solutions that may better suit an organisation’s network or security policies; however for many smaller companies and private individuals, SSL-Explorer could be the perfect solution to remote access – it’s definitely worth a look.

Remotely controlling Mac OS X using VNC

I frequently control my Windows computers remotely from other Windows, Linux or Mac OS X computers using a remote desktop protocol (RDP) client; however there is no RDP server built into Mac OS X (not surprisingly, as RDP is a Microsoft protocol) and Apple’s remote control product (Apple Remote Desktop) is a little pricey for a network with only one Mac!

All is not lost though, as I’ve found that I can use VNC Viewer (Free Edition 4.1.1 for X) on my Linux (Fedora core 5) box to remotely control my Mac (OS X 10.4.8) – I could probably use a Windows VNC client too but I haven’t tried yet.

All that is required on the Mac side is to enable Apple Remote Desktop in the System Preferences (Sharing, Access Privileges, VNC viewers may control screen with password) and to set an appropriate password but, initially, I was having problems whereby the VNC Viewer refused to connect and returned the following error:

Unknown message type

It seems that the solution is to set the colour level connection option to use full colour (all available colours) – once this was set I was able to connect to the Mac and control it remotely.

Wireless security and secure remote access

Last night, I attended Steve Lamb‘s Microsoft TechNet UK briefing on wireless security and secure remote access. I won’t repeat the entire content here, because Steve has an article in the November/December issue of Microsoft TechNet magazine, entitled improve your web security with encryption and firewall technologies, which, when combined with Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article, just about covers the content of the event. Having said that, there were a few more snippets that came out during the presentation, which I’ve plagiarised (and extended) in the rest of this post…

Wireless Security

Anyone who needs to secure a Wireless network at home should check out Steve Lamb’s blogcast on securing a wireless router and Windows XP and, although I’ve already linked it above, I’ll repeat that Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article is also worth a read. Further information is also available on the Microsoft website.

Some additional notes that I took during Steve’s presentation were that:

  • Wireless network keys can be stored on a USB token.
  • Wired equivalent privacy (WEP) is often considered insecure but consider the name – the equivalency part indicates that it offers the same level of security as a wired network. Yes, it can be broken into, but so can a wired network with public access to the building). Wi-Fi Protected Access (WPA) (or preferably WPA2) is better and dynamic WEP is a half-way house, but whatever security is employed, the wireless network still needs to be easy to use.
  • There are sites on the ‘net that will show you how to break a wireless (or other) connection (if you think it’s irresponsible of me to link that site, you could also find it using a search engine, so I figure that it’s better that the methods are well known, than only being known by the bad guys).
  • Contrary to popular belief, there is no point in securing the SSID for a network as it is transmitted unencrypted (even on a network secured with WPA or WPA2). Ditto for media access control (MAC) addresses, which are easily spoofed.
  • Even WPA doesn’t do anything to prevent a denial of service (DoS) attack and WPA2 (802.11i) doesn’t stop all DoS attacks.
  • 802.1x is port-based authentication and applies equally to both wired and wireless networks. It does have weaknesses, including that it will only authenticate the initial connection. In a wireless configuration, man-in-the-middle (MitM) attacks can be guarded against by requiring the WAP to identify itself using certificates (using a group policy object).
  • WEP requires Windows XP. WPA requires Windows XP SP1, WPA2 requires Windows XP SP2 and a hotfix (see Microsoft knowledge base article 893357).
  • The Windows 2000 Internet authentication service (IAS) can be used as the RADIUS server component in a secure wireless deployment; however Windows Server 2003 supports auto-enrolment (which when used for computer and user certificates will make life much easier).
  • Windows XP will (by default) allow access to its nearest access point, even if it is not secure.

Very importantly – if (like I did), you think that your wireless network (e.g. at home) doesn’t need to be secured because there’s no data of value to be had and anyway, you have bandwidth to spare which you don’t mind your neighbours using, consider the implications of someone using your wireless network to access the Internet and perform illegal activities, which your ISP can trace back to you via your IP address. Having thought about that, I’ll be buying a new wireless access point very soon.

Secure Remote Access

Microsoft are positioning virtual private networking (VPN) technology as no longer the best solution for providing corporate remote access and I tend to agree. The idea of giving an untrusted computer an IP address from the internal network fills me with fear (unless some quarantining is in place). VPNs “blur” the network edge and anyway, do remote users need full network access? I’ve often accidentally printed a document in the office whilst working at home and then had to ask a colleague to retrieve and dispose of it for me (wasting paper, printer resources and somebody else’s time). Some solutions will use VLAN technology to limit the network access for VPN users – there are other methods too, especially when considering that 90% of VPN users only really want to read their e-mail. For example, Outlook Web Access, whilst having improved it’s interface capabilities dramatically with each new release, is still not really a great solution for access from outside the corporate firewall (it’s good for allowing users to access mail without setting up a MAPI profile, but is heavily reliant on ActiveX controls, which may not be allowed in an Internet cafe, and is also a risk if the remote client has a keylogger installed) – full client Outlook using HTTPS over RPC on a notebook/tablet PC is a far better option – totally transparent from an end user perspective (although still a problem if access is required if an e-mail links back to internal resources to retrieve a document).

Steve Lamb’s TechNet magazine article (and my previous post on securing the network using Microsoft ISA Server 2004) elaborate on the need for application layer firewalling rather than blindly allowing HTTP and HTTPS traffic through the firewalls. Other measures employed include pre-authentication and URL scanning.

SSL VPNs are another method of providing remote access (even though they are not really VPNs, but are actually just remote desktops in a browser). Windows Terminal Services can provide basic SSL VPN functionality, which can also be extended with products from Citrix.

Operating over the remote desktop protocol (RDP), which is based on the International Telecommunications Union (ITU) T.120 protocol family and is therefore independent of network and transport protocols, these solutions use compression and caching to reduce bandwidth requirements and support network load balancing. Windows Server 2003 brings a number of terminal services enhancements (over Windows 2000) including:

  • Connection to the console session (in remote administration mode).
  • Control of RDP options via group policy.
  • WMI provider for scripted terminal services configuration.
  • ADSI provider for access to per-user terminal services profiles.
  • Improvements to the terminal server manager MMC snap-in (reduced automatic server enumeration).
  • Ability to limit users to a single session.
  • Improved security:
    • Remote Desktop Users security group (which can be used in place of the Everyone group to fine tune access control.
    • 128-bit RC4 encryption.

Securing terminal services comes back to the well-known principle of defence in depth:

  • A physically secure terminal services server.
  • A secure operating system configuration.
  • A secure terminal services configuration.
  • Network path security.
  • Using the registry to fine-tune control over terminal server sessions (probably overkill, but using group policy to control access is a similar principle).

Using the remote desktop web connection ActiveX control, terminal services can be provided across the web (and optionally secured using HTTPS). The initial client contact is to http(s)://servername/tsweb/ and the ActiveX control is downloaded over HTTP (TCP port 80) or HTTPS (TCP port 443). Once the browser has the ActiveX control installed, the user can connect to the terminal server over TCP port 3389.

If full VPN access is still required (and hopefully the methods above will avoid the requirement for this), then VPN server placement must be carefully considered. Running an encrypted PPTP or L2TP+IPSec VPN connection through a standard packet filtering firewall effectively bypasses the firewall as the VPN port will be open on internal and external firewalls and the traffic inside the connection will not be inspected.

Most network administrators will be alarmed if you propose the installation of ISA Server as the corporate firewall even though ISA Server 2004 has now achieved common criteria evaluation assurance level 4+. ISA Server 2004 is a perfectly good firewall (assuming that the underlying Windows platform is also well-managed), but it will probably be easier to justify to network administrators by using ISA as an additional server in the DMZ, or as the inner firewall (between the DMZ and the internal network). This way, the encrypted connection can be terminated at the ISA server and the firewall can inspect the inbound traffic.

Finally, if a VPN connection must be used to extend the corporate network to remote clients, then network quarantine controls should also be put in place. Full network access protection (NAP) is expected with the next version of Windows Server (codenamed Longhorn) but even now, Windows Server 2003 SP1 routing and remote access service (RRAS) allows for the provision of network access quarantine control for remote clients. The current Microsoft implementation involves using the connection manager administration kit (CMAK) to construct a custom RRAS client which includes a number of post-connection actions. Until these are passed, then vendor-specific options remain in place which prevent the remote VPN client from accessing the network. Unfortunately it is also possible for a technically able user to spoof the message which allows the vendor-specific attributes to be removed, but in reality this is a small risk. Microsoft’s NAP and Cisco’s network access control (NAC) will make this far more effective, extending the scope of control to include wired and wireless clients (as well as VPN clients).

Windows XP SP2 RDP client now available for legacy versions of Windows

Microsoft have released an updated Remote Desktop Connection (formerly Terminal Services) client for Windows 95, Windows 98, Windows ME, Windows NT 4.0 or Windows 2000. This is the same version as is included with Windows XP service pack 2 (v6.0.2600.0).

MsTsc.Server errors with TSAC ActiveX control

I haven’t used the Terminal Services Web Client for a few years and when I installed it on a Windows 2000 server with the latest updates applied I received an “Object doesn’t support this property or method: ‘MsTsc.Server'” error.

After a bit of research I found that the problem dates back to some security updates from 2002 (for further details, see the Remote Networking Development website and/or Microsoft knowledge base article 328002 and/or Microsoft security bulletins MS02-046 and MS02-047). Downloading the latest Remote Desktop Web Connection fixed the problem and my servers are now available from wherever I happen to be.

Connecting to a server’s console session using RDP

One of my colleagues introduced me to a switch I had mot previously encountered for connecting to the console session on a server using the Microsoft Terminal Services/Remote Desktop Connection (RDP) client. Although not presented by the GUI interface, the mstsc command includes the /console switch. For the full command syntax, type mstsc /? or refer to the Microsoft Windows Server 2003 product documentation.