Steve Riley on Security : networking

Ethernet and WiFi and Bluetooth, oh my!

Steve Riley — Thu, 16 Oct 2008 00:16:48 GMT

Customers have long requested a way to configure a computer to automatically disable its wireless NIC when its Ethernet is in use. Many third-party utilities can do this for you, but neither XP nor Vista have a built-in way to accomplish this, nor will Windows 7. Although having both NICs enabled first appears to cause a security issue, in reality that would be true only if both of the following were also true:

The user is logged on as a local administrator
The user, or some code the user runs, enables IP routing

By default, all forms of IP routing (including NIC bridging) are disabled. Only local administrators (or group policy) can enable them. So the risk, actually, is minimal.

If you have a stroll through group policy, you'll discover this setting: "Prohibit installation and configuration of Network Bridge on your DNS domain network" (more here, here). This setting allows you turn a computer into a router that bridges two networks. The bridging works only when one of the interfaces is in the same DNS namespace it was in when the bridge setting was enabled, and it works only when the Windows firewall is disabled on both interfaces (never a good idea). Additionally, regardless of the group policy setting, the function doesn’t even appear as an option when the user is logged in as a non-admin. The group policy setting simply removes the option from people who are local admins of their computers. So here's a way you can remove the ability even for local admins to enable routing.

However, let me admit that I wish we did have a way to implement your request, but for an entirely different reason: IP address preservation. Consider what happens when I'm on my own corpnet in my office. I put my laptop in its dock, which is connected to the Ethernet. I never bother disabling my wireless (I'm lazy). So whenever I'm in my office I'm taking up two IP addresses: one on the Ethernet and one on the wireless. Such wasteful profligacy, I know! (Note this isn’t a problem for any Bluetooth adapter, which always uses APIPA in its default configuration; I can’t imagine a scenario where you’d want Bluetooth to use DHCP.)

If you agree with me that this is something we should address post Windows 7, not for "security" reasons but as a good general networking practice of being conservative with address allocation, please speak up. Now's the time for your input.

[OT rant] Are there any home WiFi routers that DON'T SUCK?

Steve Riley — Sat, 23 Aug 2008 03:12:38 GMT

Warning: rant ahead, and names named.

When I'm not traveling, I like to work from home some days rather than endure the trek from Seattle to Redmond (although it's much better now that our own employee transit service has expanded into my neighborhood -- the existence of which is sad commentary on the availability and reliability of Seattle's public transit companies).

This means, of course, that I need fast and stable network connections. Comcast with their PowerBoost is working very well for me. But I just can't find a decent wireless router at all. My Lenovo T61p (with Intel 4965abgn adapter) just won't stay connected to my D-Link DIR-628 and IT'S DRIVING ME CRAZY! (Yes, I've tried various driver versions, from both Lenovo and Intel.)

My house is in an area with a lot of wireless activity -- sometimes I can see nine or ten SSIDs. I'm running draft N on 2.4GHz (which occupies two non-adjacent channels, currently 1 and 4), and I suspect the problem is collision interference. I could shift the router to 5.2GHz, which I probably would help, but then the rest of the computers in my house won't connect. Why, you ask? Well get this: the DIR-628 is part of D-Link's RangeBooster N family. So I stayed in the family and got two DWA-542 adapters for the desktop computers. Yet they only do 2.4GHz! Silly me, I assumed that being in the same family means full support of the router's capabilities.

I'm very tempted to replace my router again -- and I'm thinking that the best option is to get one with dual radios. That way I can move my T61p to 5.2GHz and replace the desktop adapters, while still having single-channel 802.11b/g on 2.4GHz for the Wii and my PlayStation Portable.

Now my request: tell me about your experience with home routers. What do you really like, and why? What should I buy?

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.

Microsoft IPsec diagnostic tool

Steve Riley — Fri, 01 Feb 2008 14:39:04 GMT

IPsec is a wonderful technology for identifying computers and securing the exchange of data between them. I've written and spoken extensively about in the past. It is, however, a bit of a challenge to configure, especially if you're newly learning about it. Microsoft recently released a diagnostic tool to help you create and test your policies. It checks for common network problems on host machines and suggests repair commands. It collects IPsec policy information on systems and parses IPsec logs to deduce why a failure might have happened. Beyond IPsec, it offers trace collection for VPN, NAP client, Windows Firewall, Group policy updates, Wireless, and System events. The tool's diagnostic report derives its conclusions from the system logs collected by the tool during its analysis phase, which are sufficient to diagnose any network related issue. For further assistance, you can share the logs with network administrators or Microsoft support.

Get the tool here: http://www.microsoft.com/downloads/details.aspx?FamilyID=1d4c292c-7998-42e4-8786-789c7b457881&displaylang=en

It works on these versions of Windows:

Windows Server 2003 Service Pack 1
Windows Server 2003 Service Pack 2
Windows Server 2003 Service Pack 2 x64 Edition
Windows Server 2008
Windows Vista Business
Windows Vista Business 64-bit edition
Windows Vista Enterprise
Windows Vista Enterprise 64-bit edition
Windows Vista Ultimate
Windows XP 64-bit; Windows XP Home Edition
Windows XP Professional Edition
Windows XP Service Pack 1
Windows XP Service Pack 2

Myth vs. reality: Wireless SSIDs

Steve Riley — Tue, 16 Oct 2007 10:08:58 GMT

Do you ever wonder sometimes how it is that some ideas just won't die? Like the thought that not broadcasting your wireless network's SSID will somehow make you more secure? This is a myth that needs to be forcibly dragged out behind the woodshed, strangled until it wheezes its last labored breath, then shot several times for good measure.

Folks, there are fundamental differences between names, which are public claims of identities, and authenticators, which are secrets used to prove identities, and I've written extensively about this before. An SSID is a network name, not -- I repeat, not -- a password. A wireless network has an SSID to distinguish it from other wireless networks in the vicinity. The SSID was never designed to be hidden, and therefore won't provide your network with any kind of protection if you try to hide it. It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID. And, even if you think your SSID is hidden, it really isn't. Let me explain.

All 802.11 wireless networks, regardless of the kind of operating system or encryption you might use, also emit unencrypted frames at times. One kind of unencrypted frame is an association frame. This is what a client computer, or "supplicant" in the 802.11 protocol vernacular, emits when it wants to join a wireless network. Contained within the frame, in clear text of course (since the frame is unencrypted), is the SSID of the network the supplicant wants to join.

Both Windows XP and Vista work best when your access points broadcast their SSIDs. XP really doesn't behave well at all with nonbroadcasting SSIDs. Vista has some added smarts to improve this a bit. Normally, Vista continually sends probe requests for nonbroadcasting networks. These probes are similar to unencrypted 802.11 association frames, and will generate clear-text responses from the access points if a nonbroadcasting network is present. You can reduce, but not entirely eliminate, these probes by configuring the wireless client to probe only for automatically-connected nonbroadcasting networks.

Both these behaviors make it very easy for an attacker to discover your SSID. The bad guy, perhaps a contractor or a guest in your facility, could run one of many wireless sniffer programs and simply capture the hundreds of association frames or probes that litter your air. No amount of "hiding" configured in your access points can prevent this kind of traffic interception.

So there you have it, simple SSID discovery. The old axiom remains true: security by obscurity is no security at all. Hiding an SSID will not hide a wireless network, so ignore any such advice -- and it's amazing how often I continue to see this. By the way, also ignore any advice that says to use MAC address filtering. It's amazingly trivial to spoof the MAC address of an allowed supplicant -- simply sniff the traffic, look at the MAC addresses, and use the neat little SMAC utility to change your MAC to one that's permitted.

Nonbroadcasting networks are not secure networks. The right way to secure a wireless network is to use protocols that are designed specifically to address wireless network threats. If you're still using WEP, either static or dynamic, I encourage you to move to WPA2 as soon as possible. For those of you at home running XP and have kept it updated, or if you're running Vista, then, you simply need to enable WPA2. We've got some additional guidance for home/small offices and for enterprise networks with certificate services or without. If you have hardware that's more than two years old and you can't upgrade it, check to see whether it supports WPA (an interim specification released before WPA2 was ratified). Both WPA and WPA2 are built on sound cryptographic principles, they're proven in the field, and they'll keep the bad guys out -- even when you're broadcasting your SSID to the world.

Enabling Secure Anywhere Access in a Connected World

Steve Riley — Tue, 06 Feb 2007 23:47:00 GMT

A few times each year, Bill Gates or Steve Ballmer publish an executive memo. The first memo was Bill's essay on trustworthy computing, in July 2002. Today Bill has a new memo, one that is very important for all of us who strive to achieve a balance between being secure and, well, getting work done.

Some of my favorite points from the memo:

[It] is no longer a question of the power of our devices and the speed of our connections. The real issue today is security. Ultimately, anywhere access depends on whether we can create and share information without fear that it will be compromised, stolen, or exploited.
No company is immune to the danger. Malware targets products from virtually every software vendor. Every business is vulnerable to the risks that come with unauthorized access to corporate information.
...striking the right balance is extremely difficult. Easy access speeds communications but increases the danger that confidential information will be exposed. Stringent security measures reduce risk, but can make it too difficult for employees to access information or communicate with customers and partners and too complex for IT professionals to deploy and manage solutions.
...new technologies for managing the way people and information move between corporate networks and the Internet are essential. In the face of a rapidly evolving threat landscape, the firewall...is no longer adequate.

Several times in the memo Bill mentions the importance of policy. Most of you have probably heard me speak of similar ideas. Policy-based security allows us to finally divorce information protection from the mechanism used to transmit that information. This is essential because the ubiquitousness of mobile computing demands it. Regardless of where information is stored, how it is transmitted, policies that apply to the information will move everywhere with it. We will no longer be constrained by the topologies of any particular network, because the network will lose its role in managing access to information and revert to the single thing it does best: move bits around as fast as possible.

Curious about the ways Windows talks to the Internet? Here's your answer.

Steve Riley — Thu, 21 Dec 2006 02:32:00 GMT

I was browsing through the Microsoft download pages today -- yeah, even we employees occasionally find little nuggets interspersed among the usual updates and such. I noticed a pair of whitepapers that will answer a common question I hear from many of you in emails and at conferences. You'll want to keep these handy.

Using Windows: Controlling Communication with the Internet

Windows Vista and the Windows XP include a variety of technologies that communicate with the Internet to provide increased ease of use and functionality. Browser and e-mail technologies are obvious examples, but there are also technologies such as automatic updating that help users obtain the latest software and product information, including bug fixes and security patches. These technologies provide many benefits, but they also involve communication with Internet sites, which administrators might want to control.

These white papers for Windows Vista and Windows XP with Service Pack 2 provide information on the communication that flows between operating system features and sites on the Internet. The white papers also describe steps to take to limit, control, or prevent that communication in an organization with many users. The white papers are designed to assist you in planning strategies for deploying and maintaining these Windows operating systems in a way that helps to provide an appropriate level of security and privacy for your organization’s networked assets.

Windows Vista vs. hotels

Steve Riley — Wed, 22 Nov 2006 00:08:00 GMT

At many TechEds this year I've presented information about the new TCP/IP stack in Windows Vista. One of the important advances is its automatic performance tuning. With some of the early pre-release builds of Windows Vista, people were reporting problems with public Internet connections, most notably in hotels. Some of the routers used in hotels don't properly implement the specifications for receive window tuning; the symptom looks like failed DNS requests when trying to browse the Web.

We made some changes to the stack and to Internet Explorer to detect non-conforming gateways and adjust accordingly. And indeed, I've seen the problem pretty much disappear. However, the gateway in a hotel I visited in South Africa still exhibited the problem, and when I disabled the auto-tuning Windows could finally connect.

I suspect that most of you won't encounter this using the RTM build. If, however, on rare occasion you do, here is the command you can issue to disable automatic tuning:

netsh interface tcp set global autotuninglevel=disabled

You can abbreviate netsh commands to the first three letters like this:

netsh int tcp set glo aut=dis

Be sure to re-enable the setting when you aren't on the hotel's network:

netsh interface tcp set global autotuninglevel=normal

Or, using the shortened method:

netsh int tcp set glo aut=nor