markwilson.it

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.
  • Software restriction policies to limit the applications which users can run.

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).