Then, Consider Your Remote Access Needs

You can choose between three basic kinds of remote access: browser-based access to Web resources, remote control of sessions, and full IP virtual private networks. Consider the needs of all your usersyou might find yourself deploying all three.

Much of what we discuss here also applies for other users of your environment, toocustomer applications that run over the Web and business partner requirements for connections to your network. Don't limit your thinking to employee remote access, although to ease discussion that's the language we use throughout this section.

Web Access

Web access to internal resources is amazingly popular because it satisfies the "access from anywhere " requirement. A quick e-mail check at the airport before boarding the plane for a relaxing and rejuvenating 12- hour intercontinental junket could very well mean the difference between a big fat bonus check or a soul-crushing pink slip. As HTTP becomes the universal transport, HTML/XML become the universal languages, ^[13] and the browser becomes the universal display device, the allure of anywhere-access indeed grows strong. As much as it might upset the protocol purists in the crowd , there's no going back.

^[13] Esperanto has no chance against HTML/XML. Should you be inclined to disagree , we refer you to "The Esperanto flamewar FAQ" (http://www.nenie.org/eo/eo-flame-faq.txt).

In Chapter 5, we spent some time discussing the risks of access from anywherekeystroke loggers and unmanaged and insecure PCs. There are usability concerns, too. For example, many customers were unwilling to deploy Outlook Web Access (OWA) from Exchange 2000 Server because of an interesting threat that, honestly, had never occurred to us. It turns out that many people would approach a kiosk, comfortably settle into the chair , log on to OWA, read a few e- mails , and then just get up and walk away without closing the browser! Shocking, we know, but apparently a huge risk. That's why OWA in Exchange Server 2003 provides a form-based logon. Now you get a browser cookie, and so long as you keep interacting with your mail, your cookie gets updated. The cookie expires after 15 minutes, so when 15 minutes of inactivity passes , any future activity simply returns to the logon page. The other risk with OWA 2000 is that opened attachments would remain in the kiosk's browser cache. OWA 2003 allows you to control attachment behavior, permitting access on corporate machines and denying access on noncorporate (public) machines.

Protecting Web-Based Services

As you consider which users to include in your "access-from-anywhere" policy (and it could very well be your entire organization, it usually happens this way) and which applications you'll make available, consider things such as security, usability, and authentication. Never make Web-based services directly available on the Internet! Always place your Web servers behind "reverse" application proxies that can protect the Web servers from attack.

Attacks against Web servers usually involve malformed URLs or malformed HTTP. They're also always anonymous (if an attacker can log in, you've got another problem). So in evaluating how to better protect Web servers, it becomes obvious that the typical designplacing them in a DMZ with only a packet-filtering firewall for protectionis no longer sufficient. Proper Web server security should address the threats of malformed URLs, malformed HTTP, and anonymous access.

WARNING: Potential Bias Ahead

At this point, we know some of you must be thinking "Oh no, here comes the part about a Microsoft firewall! Why would I use anything from Microsoft to protect my Microsoft servers?" Remember, you're reading a book called Protect Your Windows Network written by two employees of Microsoft (which probably confirms any bias you think we might have, eh?). It's true that you can do what we're describing here with any competent application-layer proxy. It's also true that ISA Server 2004 is one of the better application layer proxy firewalls on the market. The previous version, ISA Server 2000, has survived for four years so far with only five discovered vulnerabilities (two denials of service, one cross-site scripting attack that allowed no privilege escalation, a DNS spoofing vulnerability, and a buffer overflow in the H.323 filter). Plenty of customer evidence supports the assertion that the product is strong and reliable.

Take all those application servers in your DMZ and move them to your corporate network. For one thing, it'll make authentication easier: you don't need to open your inside firewall for everything Active Directory requires for authentication because now the Web server and the domain controllers are on the same network. Then, in the DMZ, place an ISA Server. ISA Server becomes the bastion host, terminating all incoming requests , decrypting the SSL if necessary, authenticating the user , inspecting the URL, inspecting the HTTP, and only forwarding the traffic if it meets everything you've defined in the policy. ISA Server permits the request only if the URL and the HTTP make sense for the service you're publishingtwo real threats are now eliminated.

The third threat, anonymous access, is interesting. If you can require "pre-authentication" to something else before you allow traffic to reach the actual Web server, you've eliminated many kinds of attacks that don't exploit malformed URLs or HTTP. ISA Server supports "authentication delegation" where it's ISA Server, not the Web server, that queries the user for credentials. ISA Server verifies the credentials against a domain controller and terminates the session if the verification fails.

With ISA Server 2000 you either had to join it to the account domain or to a separate forest that trusted the account domain. ISA Server 2004 gives you more choices because it supports RADIUS for authentication delegation; a standalone non-domain-joined ISA Server 2004 takes the incoming basic or forms-based credentials, converts them to RADIUS, queries a RADIUS server, and then discards or allows the request as appropriate.

This diagram shows a typical DMZ deployment of ISA Server. Rather than endure the disrupting effort of replacing the firewalls you've already got, you can incrementally enjoy added protection by following the model we show here.

Figure 7-1. ISA Server in the DMZ publishing resources in the corporate network.

Remote Control

Remote control is kind of a middle ground between Web-based access and full IP VPN. For many customers, there is a need for some employees to access more than a few Web servers or to access services that can't be converted to the Web, but for these employees full IP VPN isn't possible because, again, there's a business need for access from anywhere or to use a computer that can run a remote control client but can't be a full IP VPN client.

The easiest thing to set up is Terminal Server over the Internet. A while back, some flaws were found in RDP (the Terminal Server protocol), one involving keystroke and checksum vulnerabilities that could lead to successful password sniffing (but only using computers on the same subnet as the Terminal Server computer), the other involving a denial of service; both were patched through updates and service packs . If you choose to run Terminal Server over the Internet, it's imperative that you have strong password policies at least, or, better, use two-factor authentication: Terminal Server works well with smart cards. Remember that there isn't (yet, anyway) a version of RDP that runs over HTTP, so your users require the Terminal Services client on older machines or can use the remote desktop client on Windows XP. ^[14] And we risk stating the obvious: Make sure you've configured the connection to use high encryption so that you get 128-bit RC4 in both directions. Low encryption uses 40-bit RC4 for client-to-server traffic only (return traffic is clear text); medium encrypts both directions but still uses only 40-bit RC4.

^[14] The TS Web client still uses RDP for communicating with the Terminal Server, just inside an ActiveX control that displays in a browser window. The Web interface uses HTTP only for selecting the particular Terminal Server to connect to and for downloading the control. See "How TSWeb/TSAC/Remote desktop Web connection client works" (http:// blogs .msdn.com/tristank/archive/2004/03/18/91806.aspx).

There's a new thing out, something that gives us great pause: SSL VPNs. What a terrible name: this is what happens when you let marketing people pick the name of your product. They aren't VPNs at all: there's no machine configuration check, no quarantine capability, no remote IP address assignment. We loathe this term so much that instead we use "desktop-over-HTTPS" because that's what it really is. (Some of these products have even extended the name "SSL VPN" to replace the well- understood notion of ordinary Web applications running on HTTPS. Some advice: carefully read the details about SSL VPNs so that you can be completely sure what these products are really doing.)

Most of these productswhether software based or hardware basedaspire to replace VPNs with their " superior " approach of using HTTPS to deliver a desktop session to a user. Thing is, it's never quite as simple as that: they all require installing an additional client piece, usually delivered as a Java applet or an ActiveX control, to fully support the experience. HTTP and HTML, although pretty mature and powerful, just don't have the ability to completely emulate the full desktop experience. ^[15] The marketing for desktop-over-HTTPS products is heavily slanted toward making you believe that they give you a true access from anywhere experience; in reality, they'll leave you disappointed with the promise because public computers and kiosks rarely allow downloading and installing additional software. In browsing the Web site of one popular desktop-over-HTTPS vendor, it took nearly an hour to learn that the client software is delivered as an ActiveX control. This information is usually buried very deep and almost impossible to discover.

Full IP VPNs

To be considered a VPN, the technology must perform at least two functions: authenticate the end user and assign the remote node an IP address routable on the local network. A VPN is virtual because it rides atop some other real network; it's private because the communications between the client node and the VPN server are encrypted.

Microsoft's inclusion of PPTP in Windows NT 4.0 Server raised the awareness of VPNs in the minds of many organizations. It became pretty easy to deploy remote access VPNs because the software was now included in Windows servers and clients . PPTP version 1 used a modified form of RC-4 encryption and MS-CHAP authentication; flaws were discovered in both and although exploit code became available, there were few compromises. PPTP version 2 changed two things: it improved the RC-4 implementation and switched to MS-CHAPv2 authentication, which rotates keys periodically and performs mutual authentication. Both changes eliminated the discovered flaws, but didn't eliminate the requirement of having good strong passwords (because the password is the basis for forming the encryption key).

PPTP's ability to work over NAT helped it become enormously popular, especially for small and medium customers. Even some very large customers deployed PPTP VPNs to tens of thousands of clients; Microsoft itself still uses PPTP as a backup protocol when L2TP+IPsec won't work from a client for one reason or another. True story: One of us was once in a debate with a customer over PPTP versus L2TP+IPsec. The customer refused to use PPTP, claiming that it was so easy to break they could do it themselvesthen went on to acknowledge that most of their employees lived behind home NAT routers. IPSec NAT traversal hadn't been invented yet, so the customer was in a bind. I issued a challenge. Under the supervision of a disinterested third party, we created a one-page plaintext document in Notepad. We delivered the document over a PPTP VPN that some employees captured and would then attempt to crack, thus proving their "we can break it ourselves " claim. We agreed upon a two-week time limit; the loser buys the winner dinner. Eventually they gave up; your humble author had one of the finest meals he's ever enjoyed! Fact is, other than a vulnerability discovered in late 2002 that resulted in the potential to conduct denial of service attacks, PPTP version 2 has remained strong.

Nevertheless, despite its widespread use and multiplatform availability, PPTP never progressed beyond informational status: ^[16] IPsec's status as an Internet standard was very attractive. After all, it offers a much stronger encryption mechanism that isn't reliant on passwords and does a much better job of managing keys, so why not use it? Thing is, IPsec was never envisioned as a VPN protocol. Remember the two requirements necessary to be a VPN: user authentication and IP address assignment. By itself, IPsec can do neither of these.

^[16] "Point-to-point tunneling protocol" (ftp://ftp.rfc-editor.org/in-notes/rfc2637.txt).

A couple attempts were made to add such capability to IPsec: XAuth was a proposed extension to IKE that could perform a kind of user authentication; mode-config was a draft extension to IKE for assigning IP addresses, DNS servers, and such. XAuth was dropped because of a number of flaws discovered in its implementation; ^[17] at around the same time, people began to realize that there already exists a protocol that can take care of the VPN needs: L2TP.

^[17] See "Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets" by John Pliam (http://www.ima.umn.edu/~pliam/xauth/) for a discussion.

L2TP, defined in RFC 2661 in August 1999, is a combination of the good stuff from PPTP and the more effective form of layer-two tunneling Cisco developed in their protocol called L2F (layer-two forwarding). L2TP enjoys proposed standard status, which is about as good as one often gets these days and means that conforming products are generally interoperable. L2TP is a pure tunneling protocol: it establishes a tunnel between two peers, authenticates the user to the remote access server, and assigns the remote node a local address. L2TP, however, has no security because it specifies no encryption.

Enter IPsec. IPsec is perfect for encrypting the traffic between two peers; in fact, such requirement is exactly what IPsec transport mode is designed for. In 1999, Cisco and Microsoft combined IPsec with L2TP to develop the first remote access VPN protocol to achieve proposed standard status, which was granted in November 2001 and documented in RFC 3193. L2TP builds the tunnel; IPsec transport mode then authenticates the two computers to each other and encrypts the L2TP tunnel. On the wire you see an IPsec transport mode security association, inside is the L2TP tunnel. The really cool thing here is that you get two forms of authentication: L2TP authenticates the human sitting at the remote computer, IPsec authenticates the computer to the server and the server to the computer. It's essentially impossible to conduct man-in-the-middle attacks here. And L2TP+IPsec is still the only remote access VPN protocol recognized by IETF.

Windows 2000 Server includes a full VPN server that supports both PPTP and L2TP+IPsec. Windows 2000 Professional includes a VPN client supporting the same protocols. Server also includes the Connection Manager Administration Kit, with which you can build custom VPN connections including names of VPN servers, telephone numbers for RAS dial-up locations (if you still use such things), and pre- and post-connect script actions. Yet, despite L2TP+IPsec's improvement over PPTP, we never saw much deployment. NAT was the big blocker.

For a long time NAT and IPsec just didn't get on well together. We talk more about this in Chapter 10, "Preventing Rogue Access Inside the Network," so we won't repeat it here. One of the important design goals of Windows Server 2003 was to eliminate this final blocker, which has happened : it's now possible to deploy L2TP+IPsec VPNs even if NAT is present, and we've seen an increase in deployment because of this new ability.

Despite these improvements, remote access VPNs still pose a risk to your network. You're extending your perimeter to a computer that, at least while the computer is away, is not completely under your control. Or to someone's home computer that is totally out of your control. How can you determine whether the computer meets certain minimum security requirements? You don't want this computer to launch attacks against other computers in the LAN over the VPN.

VPN quarantine, which we are big believers in, can help you here. Rather than simply allowing any client computer to join the VPN unhindered, a quarantine function can isolate the computer, inspect it for conformance to whatever policy you define (is a firewall running? Is the virus scanner running? Is it up-to-date? Are the latest service pack and patches installed?), and permit the connection only if the inspection passes. Windows Server 2003 includes a basic VPN quarantine function that has proven to be enormously popular with customers. We discuss quarantine in more detail in Chapter 10.

Where Do I Put My VPN Servers?

There is debate surrounding the best location for a VPN server. You have three choices: behind the firewall, outside the firewall, or alongside the firewall. Let's examine each, but first mention here, just so it's handy, which ports and protocols the two VPN types use:

PPTP

Port 1723/tcp for the session establishment

IP protocol 47 (generic routing encapsulation, GRE) to carry the traffic

L2TP+IPsec

Port 1701/udp for the tunnel establishment, user authentication, and address assignment

IP protocol 50 for IPsec ESP transport mode encryption of the L2TP tunnel

Behind the firewall is often where people initially think a VPN server should go. After all, the firewall is the edge of the network, right? It should see all traffic coming in before anything else does. What is VPN traffic, though? It's encrypted. This means that you'd need to open the firewall for the appropriate ports and protocols and allow an encrypted session to pass through to the VPN server. What good, then, is that firewall really doing?

Ah, it protects the VPN server, you say. After all, if it's RRAS running on Windows, it's riddled with vulnerabilities, right? Actually, when a server is running RRAS, it's already very well protected from attack. RRAS applies low-level packet filters to the interface that perform exactly the same thing as the firewall would: They drop everything coming in unless it's inside the VPN session. So if an attacker tried to launch, say, an RPC attack against the server, it'll simply fail: no RPC traffic can get into the box.

Figure 7-2 shows a conceptual view of the IP stack in Windows.

Figure 7-2. Conceptual view of the Windows IP stack.

Now Figure 7-3 shows the stack with RRAS running and the filters enabled.

Figure 7-3. The stack with RRAS filters enabled.

These filters are so low in the IP stack that there's nothing for an attacker to exploit. RRAS boxes are strong and can sufficiently protect themselves .

Ok, so then outside the firewall seems the next logical choice. VPN traffic arrives at the server, is decapsulated and decrypted, and then forwardedto the firewall. It's up to the firewall to pass the traffic on to the internal network. But what kinds of traffic will users be generating inside their VPN sessions? Exactly the same kinds of traffic they'd be generating when they're locally-attached to the LAN. In other words, probably just about anything and everything. In your firewall you'd need either a very large set of rules permitting many kinds of traffic from the firewall to any destination inside the local network, or a simple single "allow all" rule from the VPN server to the entire local network. Again, what good is the firewall doing here?

Unless you have a need to inspect all traffic between VPN clients and the internal network, the best place to locate your VPN server is alongside your firewall. Because RRAS can protect itself and because you probably aren't doing internal inspection in your network, placing your VPN server alongside your firewall is logical and helps keep your network design simpler. Yes, it does violate an old "best practice" that there should be only one way in and out of a network. But review the list at the beginning of the chapter: there are so many ways in and out of a network these days that the best practice makes little sense, especially when it increases complexity without increasing security.

Securing VPN Clients

Although full IP VPN gives your users the most flexibility, it presents you with the most risk. A remote client is a member of two networks: whatever ISP he or she is connected to (by extension that means the entire Internet) and your corporate network. Unless you configure the VPN client correctly, that client could become a major source of pain for you.

By default, the VPN client software in Windows changes the computer's default gateway after a successful connection. The gateway is now the IP address of the server's end of the VPN tunnel. (This is not the actual IP address of the Internet- facing NIC on the server; it's the first IP address from the pool of addresses you use for clients.) All traffic from the client flows to the VPN server, regardless of whether the destination is some resource on your network or a site someplace on the Internet. This makes sense for local traffic but creates choices for how you should handle nonlocal traffic. You can:

Decapsulate it at the VPN and route it to your firewall for delivery.
Enable NAT on your RRAS server and "reflect" it back to the Internet.
Configure clients for split tunneling.

The first choice works only if you've located your VPN server behind your firewall. And there's no real configuration here; because the VPN server's default gateway points to the Internet, nonlocal traffic routes right out your network. But if you've placed it outside or alongside the firewall, there's no route from the VPN server to the firewall so you won't have that option.

The second choice is interesting and works no matter where you've placed your VPN server. When you enable NAT on the VPN server, it can act as an Internet gateway for remote clientsbut only if you configure it correctly. In its default configuration, RRAS can't properly handle routing non-local traffic back to the Internet if you're using private IP addresses in your address pool. Even though the RRAS server actually treats clients as external and tries to route nonlocal traffic back to the Internet, it breaks under private IP addresses because the Internet won't route them.

If you know RRAS, you know of this interface named "Internal." This interface is the server side of all VPN tunnels, where all of the client VPN tunnels terminate. This is a virtual interface, not a real NIC, and shouldn't be confused with the server's internal interfacethe real NIC facing your local network. If you configure "Internal" as a NAT private interface, incoming VPN connections are treated as private and can go through the NAT processor to access the Internet. In Windows Server 2003, you can do this in the RRAS user interface, but in Windows 2000 "Internal" isn't exposed in the NAT UI, so instead you must enter a command-line statement:

 netsh routing ip nat add interface internal private

After you run this and refresh the RRAS UI you'll see "internal" added to NAT as a private interface. Now when VPN clients send traffic that's nonlocal, RRAS "reflects" it back to the Internet through NAT. Using this trick is the ideal way for remote users to access the Internet when you set up your VPN server in the recommended location, alongside your firewall.

Please avoid the third choice, split tunneling, at all costs. ^[18] Here you modify the VPN client's behavior so that it doesn't change the computer's default gateway; instead, you add several static routes to the computer so that all traffic for the various subnets on the local network routes through the VPN and all nonlocal traffic routes directly to the ISP. Sounds simple and elegant, but it's fraught with danger. A split-tunneled computer is literally connected to two networks simultaneously : one of which is very hostile , the other only slightly less so. ^[19] Split-tunneled remote computers are strong attractors of attack because they provide easy ways to get into corporate networksand this becomes possible regardless of where you locate your VPN server.

^[18] We learned recently that a very popular competing VPN product requires all clients to use split tunneling if they want to access the Internet while also accessing local resources. That is astoundingly stupid, especially considering this manufacturer's public interest in security.

^[19] This is intended to be a joke, but it's closer to the truth than we really prefer to imagine for some customers we've worked for.

We've seen some people figure this out on their own and configure their computers for split tunneling. They do this because they're unaware of the risks and happen to be running as local administrators, which is required for changing routing tables. On other occasions we've seen custom code or Connection Manager scripts configure split tunneling after connection. If your users don't run as local administrators, then you don't need to worry about split-tunneling configurations. If your users do run as local administrators, you can prevent split tunneling by using Windows Server 2003 RRAS, VPN quarantine, and a CMAK script: Windows Server 2003's CMAK can block changes to the routing table even by local administrators; VPN quarantine can ensure that users connect only through the CMAK "connectoid" rather than by creating their own VPN connections.

One other thing that's important for remote clients is this: every single client should be running a firewall, on both the real and virtual interfaces. Remember, even when you aren't split tunneling you're still connected to two networks. It's absolutely critical to protect the client from attacks originating on the Internet using a host-based firewall like the one included in Windows XP Service Pack 2. We also like to protect the VPN interface, too. In Chapter 10, we discuss the importance of client firewallsto protect each computer in a LAN from the rest of the LAN. It's no different here: when the client connects to the VPN, it connects to the LAN; it deserves the same protection as local clients and should run the firewall on the VPN interface as well.