Directly connect to your corpnet with IPsec and IPv6

Steve Riley — Wed, 25 Jun 2008 23:55:00 GMT

Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

Windows Vista Enterprise or Ultimate editions (those with Business edition and Software Assurance can upgrade to Enterprise)
That are domain-joined
Users run as non-admin
Group policy applies numerous settings
UAC is enabled
BitLocker is configured to protect confidential information stored offline
The Windows Firewall is enabled
NAP is used for checking health
Forefront Client Security for keeping malware off the box
Smart cards for strong authentication of users
IPsec is required for connection authentication and traffic encryption
IPv6 is required for worldwide Internet connectivity
A DNS suffix search list represents the data center name space
Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Remote Access Quarantine (TechNet Magazine article)

Steve Riley — Wed, 01 Mar 2006 02:58:00 GMT

http://www.microsoft.com/technet/technetmag/issues/2006/03/SecurityWatch/default.aspx

In those good old easy-to-manage pre-mobility days, personal computers presented few actual threats to a network. Sure, there was the occasional virus you’d get from a borrowed floppy disk, but the rate, or at least the speed, of infection was pretty low—limited substantially by the low bandwidth and high latency of "sneakernet" technology. In those days, computers were bulky behemoths that squatted on desks and never moved. They were secure because the network was secure, if there was one at all.

Alas, those halcyon days are behind us now, relegated to the dustbin of history. And indeed they should be. Mobile computers are wonderful! We can work, well, just about anywhere, slay monsters anywhere, play solitaire anywhere. The true advance, of course, was the combination of mobility and a network connection. Got 10 minutes? Haul out the laptop and check that e-mail. Who needs an office anymore?

Of course, Murphy never gets to rest. It seems that with every technological advance (that’s a euphemism for "another way your employer squeezes more work out of you"), there’s a dark side. Connected mobility’s dark side is the ease with which unscrupulous people can wreak havoc across an entire network.

Armed with a portable computer that’s routinely connected to multiple public networks, out-of-date machines operated by people with an "I don’t really care" attitude are the most dangerous thing I can envision. And when "I don’t really care" then wants to connect back to his corporate network, need I really describe the resulting carnage? Indeed, this exact scenario is arguably one of the fastest-growing infection vectors imaginable.

Steve Riley on Security : VPN

Directly connect to your corpnet with IPsec and IPv6

Remote Access Quarantine (TechNet Magazine article)