Steve Riley on Security : configuration

Questions about virtualization and security?

Steve Riley — Fri, 09 Jan 2009 20:46:50 GMT

Yesterday, Donnie Hamlett, a Microsoft core infrastructure optimization specialist, gave a webcast and played a video of my TechEd presentation on virtualization and security. Some of the viewers had questions, and I offered to Donnie that they could come to my blog to post them. I’ll extend that offer to all of my readers—if you’ve got a question about this topic, ask away, and I’ll answer here. Thanks!

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.

Internet Explorer security levels compared

Steve Riley — Wed, 17 Sep 2008 03:19:36 GMT

A pretty good question came across the newsgroups the other day. Someone was asking what are the differences between IE's "medium" and "medium-high" security settings. I did some digging, and found only this on MSDN: About URL security zone templates. No wonder it's difficult to find -- the terminology is different, and the table is organized by URL actions, not by the text in the dialog.

Someone on the IE security team forwarded me a document that had additional details. So here, for your enjoyment, is a chart listing the default settings for each security level. To answer the newsgroup poster, "medium" and "medium-high" aren't the same.

About the formatting: to get it to fit within the width of the blog's text section, I've made some abbreviations.

Column headings

Entries

H	High	D	Disable
MH	Medium-high	E	Enable
M	Medium	P	Prompt
ML	Medium-low
L	Low

In a few cases, the table shows a number rather than D or E or P; below the table is a description of each such entry.

At the very bottom of this post I've included the settings from the privacy tab, too.

Note: these settings reflect those for Internet Explorer 7 on Vista SP1. Please see the MDSN link above for differences between IE 6 and IE 7.

.NET Framework

	H	MH	M	ML	L
Loose XAML	D	E	E	E	E
XAML browser applications	D	E	E	E	E
XPS documents	D	E	E	E	E

.NET Framework-reliant components

	H	MH	M	ML	L
Permissions for components with manifests	D	1	1	1	1
Run components not signed with Authenticode	D	E	E	E	E
Run components signed with Authenticode	D	E	E	E	E

1 = High safety

ActiveX controls and plug-ins

	H	MH	M	ML	L
Allow previously unused ActiveX controls to run without prompt	D	D	E	E	E
Allow scriptlets	D	D	D	E	E
Automatic prompting for ActiveX controls	D	D	D	E	E
Binary and script behaviors	D	E	E	E	E
Display video and animation on a Web page that doesn't use an external media player	D	D	D	D	D
Download signed ActiveX controls	D	P	P	P	E
Download unsigned ActiveX controls	D	D	D	D	P
Initialize and script ActiveX controls not marked as safe for scripting	D	D	D	D	P
Run ActiveX controls and plug-ins	D	E	E	E	E
Script ActiveX controls marked as safe for scripting	D	E	E	E	E

Downloads

	H	MH	M	ML	L
Automatic prompting for file downloads	D	E	E	E	E
File download	D	E	E	E	E
Font download	P	E	E	E	E

Enable .NET Framework setup

	H	MH	M	ML	L
Enable .NET Framework setup	D	E	E	E	E

Miscellaneous

	H	MH	M	ML	L
Access data sources across domains	D	D	D	P	E
Allow META REFRESH	D	E	E	E	E
Allow scripting of Internet Explorer Web browser control	D	D	D	E	E
Allow script-initiated windows without size or position constraints	D	D	D	E	E
Allow web pages to use restricted protocols for active content	D	P	P	P	P
Allow web sites to open windows without address or status bars	D	D	D	E	E
Display mixed content	P	P	P	P	P
Don't prompt for client certificate selection when no certificates or only one certificate exists	D	D	D	E	E
Drag and drop or copy and paste files	P	E	E	E	E
Include local directory path when uploading files to a server	D	E	E	E	E
Installation of desktop items	D	P	P	P	E
Launching applications and unsafe files	D	P	P	E	E
Launching programs and files in an IFRAME	D	P	P	P	E
Navigate sub-frames across different domains	D	D	D	E	E
Open files based on content, not file extension	D	E	E	E	E
Software channel permissions	1	2	2	2	3
Submit non-encrypted form data	P	E	E	E	E
Use phishing filter	E	E	E	D	D
Use pop-up blocker	E	E	E	D	D
Userdata persistence	D	E	E	E	E
Web sites in less privileged content zone can navigate into this zone	D	E	E	E	P

     1 = Prohibit downloads from software update channels
     2 = Cache content downloaded from software update channels
     3 = Automatically install software updates

Scripting

	H	MH	M	ML	L
Active scripting	D	E	E	E	E
Allow programmatic clipboard access	D	P	P	P	E
Allow status bar updates via script	D	D	D	E	E
Allow Web sites to prompt for information using scripted windows	D	D	E	E	E
Scripting of Java applets	D	E	E	E	E

User authentication

	H	MH	M	ML	L
Logon	1	2	2	2	3

     1 = Prompt the user for name and password
     2 = Automatic logon only in intranet zone
     3 = Automatic logon with current user name and password

Privacy settings (on the "Privacy" tab)

	H	MH	M	ML	L
Allow persistent cookies	D	E	E	E	E
Allow per-session cookies	D	E	E	E	E
Allow third-party persistent cookies	D	P	P	E	E
Allow third-party session cookies	D	E	E	E	E

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

Changing the SSL cipher order in Internet Explorer 7 on Windows Vista

Steve Riley — Wed, 07 Nov 2007 08:37:47 GMT

Recently, the question of using AES for SSL has come up in the newsgroups and at some conferences. When IE makes an HTTPS connection to a web server, it offers a list of cipher supported cipher suites. The server then selects the first one from the list that it can match. The default order that IE follows is this:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

When you study the list, you'll see that IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. Why? If longer bit lengths are more secure, shouldn't they be listed first?

Remember, encryption is the thing that buys you time against Immutable Law #3. But performing encryption itself takes time. So when choosing an algorithm and a bit length, one important consideration is to ask yourself this question: "How long do I need for my secrets to remain secret?"

We configure IE to use shorter bit lengths -- but never shorter than 128 bits, except for the last two that use no encryption -- because it gives you better performance than the longer bit lengths. In almost all cases, a 128-bit key is more than sufficient to protect the information you're exchanging over HTTPS.

However, if you require something longer, and want to change the default, you can. Here's how.

Open your group policy editor by entering gpedit.msc at a command prompt.
Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
There's only one item here: SSL Cipher Suite Order. Open it.
Select Enabled.
Now here's where you need to tread carefully. You'll see that the list is the same as above, but rather than formatted nicely with carriage returns, they're simply separated with commas. The first item in the list is:
TLS_RSA_WITH_AES_128_CBC_SHA
And the second item is:
TLS_RSA_WITH_AES_256_CBC_SHA
Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128.
Feel free to change other orders, too, but keep your changes within algorithm types.
OK your way out, close the group policy editor, and reboot.

Most of you probably won't need to do this -- I haven't. But for those who have regulatory requirements for using 256-bit AES, follow these steps and you'll be compliant.

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.

BitLocker command line interface

Steve Riley — Sun, 26 Nov 2006 07:39:00 GMT

Last week at TechEd Europe I showed the BitLocker command-line interface. At other TechEds I've mentioned it but didn't show it. The CLI provides full control over BitLocker, including enabling it on any NTFS volume on the system (the Control Panel UI displays only the volume containing the operating system).

To run it:

Open an elevated command prompt
Change to %WINDIR%\System32
Enter cscript manage-bde.wsf

For the curious, "bde" expands to "BitLocker drive encryption."

With no parameters, the output is:

Description:
    Configures BitLocker Drive Encryption on disk volumes.

Parameter List:
    -status     Provides information about BitLocker-capable volumes.
    -on         Encrypts the volume and turns BitLocker protection on.
    -off        Decrypts the volume and turns BitLocker protection off.
    -pause      Pauses encryption or decryption.
    -resume     Resumes encryption or decryption.
    -lock       Prevents access to BitLocker-encrypted data.
    -unlock     Allows access to BitLocker-encrypted data.
    -autounlock Manages automatic unlocking of data volumes.
    -protectors Manages protection methods for the encryption key.
    -tpm        Configures the computer's Trusted Platform Module (TPM).
    -ForceRecovery or -fr
                Forces a BitLocker-protected OS to recover on restarts.
    -ComputerName or -cn
                Runs on another computer. Examples: "ComputerX", "127.0.0.1"
    -? or /?    Displays brief help. Example: "-ParameterSet -?"
    -Help or -h Displays complete help. Example: "-ParameterSet -h"
Examples:
    manage-bde -status
    manage-bde -on C: -RecoveryPassword -RecoveryKey F:\
    manage-bde -unlock E: -RecoveryKey F:\84E151C1...7A62067A512.bek

Enjoy!

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

Configure your router to block DOS attempts

Steve Riley — Mon, 10 Jul 2006 23:27:00 GMT

Some time ago I had a discussion with a friend. He disagreed with my recommendations on how to configure a border router and the firewall behind it. I claimed that in the border router between you and your ISP, configure the six rules to block most denial of service traffic; in the firewall, configure additional packet filtering and content inspection. He claimed that it's better to repeat the router rules in the firewall, and if possible repeat the firewall rules in the router.

This struck me as disingenuous: "Why do the same work twice?" I asked. "It's defense in depth," came the expected reply. "If a bad guy gets through the router, maybe the firewall will stop him."

No, it isn't defense in depth. Defense in depth is about doing the correct things at all layers, and only things that are appropriate for each layer. When defense in depth degenerates into duplication of effort, the resulting security posture becomes more brittle and, arguably, less secure.

There are three kinds of vulnerabilities:

Code: an error in the software that you fix with a patch
Configuration: an error a human made while setting something up
Circumvention: an error in a security policy that encourages people to look for ways to get around the policy

By far, the most commonly occuring type (according to some research from CERT) is the second: configuration vulnerabilities. Given that it's far more likely for me to make a mistake in my rules than for the code in the router or firewall to be buggy, it's far more likely for a bad guy to break in through my error-ridden rules than for him to break in through a code vulnerability in either device.

Complexity is the enemy of security. Simplicity always wins. Therefore, to keep a network simple (and more secure), ensure that your defense in depth measures are tuned and specific for each layer, not merely duplicates of something you've taken care of at another layer.

Blocking DOS attacks

Now, back to the title of this post. In a border router, you should have six rules that will block almost all denial of service attacks. Remember the attack against the Internet in February 2000? Mafiaboy, the 17-year-old Canadian script kiddie, brought down 11 sites using 75 computers in 52 countries to send 10,700 messages in 10 seconds, causing an estimated $1.7 billion in damages. (Canadian police discovered him from his boasting in chat rooms. In 2001 he pled guilty to 56 charges and was sentenced to two years in a juvenile detention center).

Why did Yahoo, Buy.com, eBay, CNN, Amazon.com, ZDNet, ETrade, Dell, and Excite all succumb to the attack? Because they lacked one or more of these six important rules. MSN and Microsoft were targeted, but because our routers have these rules, we escaped the attack. The rules:

Block all inbound traffic where the source address is from your internal networks. Why in the world would there be traffic on the outside that originates from the inside? This is a sign that someone is spoofing you.
Block all outbound traffic where the source address isn't from your internal networks. This is the inverse of #1: there's never any reason for your network to emit traffic that's sourced from some other network. Somone on the inside is spoofing someone else (we have a term for such people: employee).
Block all inbound and outbound traffic where the source or destination addresses are from the private address ranges. Defined in RFC1918, these addresses are for use in internal networks; ISPs agree not to route such traffic. Of course, ISPs make configuration mistakes, too; I've seen traffic with these addresses on the Internet. So don't trust that your ISP is perfect, block the stuff yourself. And remember to include the Windows automatic private IP addressing block. The ranges, then, are: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16.
Block all source-routed packets. Way back in 1970, when "routers" were Unix computers running a routing deamon, they weren't all that reliable. So IP includes a provision for the headers of a packet to indicate the route the packet should take from its source to its destination. Source-routing was necessary then, but it's completely unnecessary today: routers are some of the most reliable gear around. Source-routed traffic is the sign of an attack: drop it all.
Block all broadcast packets, including directed broadcasts. Broadcasts are useful inside a network, but have pretty much zero utility between networks, so don't let the stuff in (or out). And good old smurf attacks, still seen as a form of revenge in IRC, rely on directed broadcasts. [Thanks to Michael Dragone for suggesting this additional rule.]
Block all packet fragments. Fragrouter is an old but wonderful tool, imminently useful for evading network intrusion detection. With it, an attacker can create packet fragments -- TCP or UDP packets missing the TCP or UDP header -- and, for example, map out your firewall policy and prod for holes and mistakes in your configuration. With one notable exception, fragments are generally not created, so there's no reason to permit them into your network. What's the exception? IPsec -- or, more precisely, IKE authentication in IPsec. During the authentication sequence, IKE performs six round trips between the peers. As the peers negotiate a protection suite and exchange keys, IKE generates fragments: very rarely will the key fit in a single packet. So if you're allowing IPsec between the Internet and something behind your border router, you'll need to skip this final rule.

There you go. Program these six rules in your border router (and consider dropping whatever else you've got there now) and you, too, can tell the likes of Mafiaboy to go pound sand. Oh, and guess what? By being more secure yourself, you directly affect -- negatively -- the security posture of your neighbors and competitors! Did you ever think that a router configuration could become strategic competitive advantage? :)

Should your ISA Server be in your domain? Film at 11!

Steve Riley — Thu, 22 Jun 2006 02:21:00 GMT

So it would seem that a statement I made during TechEd US last week in Boston has mildly stirred a bit of controversy -- no surprise there, I guess, heh. One of my presentations gave an overview of what's new in ISA Server 2006 (download your copy of the release candidate or try it out in some virtual labs). An important new feature is expanded support for additional authentication methods on web listeners and web publishing rules. You can now select LDAP, SecureID, and other one-time password mechanisms, and finally make real use of client certificates through support for Service4User2Proxy in Windows Server 2003 Kerberos.

I made the statement that this additional flexibility makes it easier to build your ISA Server standalone -- rather than domain-joined -- and still enjoy the improved security benefits of authentication delegation. Tom Schinder, our beloved ISA Server MVP, prolific author, and host of the fine www.isaserver.org community site, attended the presentation. It was my apparent preference for standalone servers that Tom disagrees with -- and he wrote about it in a whitepaper on his site.

I have enormous respect for Tom. ISA Server's popularity and success is due in large part to his unflagging dedication and support. He's an entertaining writer, from whom you can not only learn something new but enjoy yourself while doing it. Plus, he advocates improved security that addresses modern threats and rails against the old guard unwilling to give up their stone knives and bearskins.

In this particular case, though, either Tom misunderstood my point or I misstated my point -- it doesn't really matter which. My preference is that, indeed, your ISA Servers should belong to your account domains. In his paper, Tom puts forth some very well-reasoned arguments for doing this -- arguments for which there is very little room to disagree. I don't believe I ever said "the ISA Server should never be a domain member" during the presentation, but honestly I don't remember now.

Yet there's a certain reality among many of the customers I work with, a reality that simply won't abide any firewall having access to account information. This reality is exactly the kind of fossilized thinking that Tom (and I) become so disgusted with. The fact is, ISA Server is one of the strongest, most resilient firewalls on the market. In the seven years since ISA Server 2000 was released, only ten security bulletins were issued for it, and of those, only three are marked critical. In the three years since ISA Server 2004 was released, zero security bulletins have been issued. ISA Server is some of the best code Microsoft has ever created. I have yet to learn of customers experiencing attacks that compromise either an ISA Server or a network protected by one.

Still, all this evidence isn't enough to convince the old guard. Very rarely do we see ISA Server replacing older, less capable firewalls in an organization. What we do see is a slow (too slow) migration toward using ISA Server in the DMZ, configured to publish resources in the internal network. And it is the intrusion of, yes, a Microsoft firewall into the realm of the "networking guys" that requires a delicate dance even still today. I've been advocating this architecture since 2002; you'd think these days we wouldn't even have to discuss DMZs as anything other than the paleo-networking artifacts they are, huh? (And I used to be one of those "networking guys.")

ISA Server's ability to remain standalone while still enabling authentication delegation solves two rather intractable problems: it protects internal web servers from attack while simultaneously existing in a configuration that the networking guys will grudgingly allow. Tom's excellent arguments in favor of domain membership reveal the deployment scenarios probably more common in his consulting work: using ISA Server as a forward proxy. The customers I have conversations with typically use that DMZ-located ISA Server only for reverse proxy. So it's from that viewpoint that I talk about standalone ISA Servers during presentations at conferences.

Tom, you and I are approaching the problem from different experiences, that's all. We are in violent agreement here, and that's a good thing. :)

When security breaks things

Steve Riley — Tue, 08 Nov 2005 21:05:00 GMT

Now that the furor has waned, I want to comment on MS05-051. For those of you who don't memorize bulletin numbers (I am part of that set; Susan Bradley, for example, isn't, hehe), this is the security update that fixed a number of vulnerabilities found in MSDTC and COM+; it replaced five other updates dating back to 2003. On Windows 2000 it also disables MSDTC TIP beause this functionality generally isn't needed.

Shortly after we released the bulletin, some customers began experiencing problems. The media got wind of this, and in typical fashion blasted Microsoft for "yet another broken patch." KB909444 describes typical symptoms (see the end of this post for resources). Sure enough, we've intentionally made life more difficult for you yet again. We just love doing that, I tell ya!

Um, no. That's a silly accusation, reflective of immature thought. Look: would any organization purposefully do things to drive its customers away? Ok, I guess I wasn't thinking about airlines here, but that's another matter. Microsoft strives to make it easier for you to bring technology to improve your business, not to get in the way. Security bulletins are part of helping you keep your business running.

Security guidance is another part. And for some time now, we've been recommending a particular thing about guidance: don't change the defalt ACLs on the operating system's files and registry entries. The default permissions on Windows XP and Windows Server 2003 are a whole lot tighter than they were on Windows 2000. While it was necessary to make several modifications on that older operating system, current operating systems don't require any modifications, despite what several well-meaning third-party security guides might claim. KB885409 discusses many issues surrounding questionable guidance; make sure you consult this before you implement the recommendations of any guidance.

What happened specifically with MS05-051? Some security guides recommend changing the default ACLs throughout the %WINDIR% folder. These modifications affect the security changes implemented in the MS05-051 update. If you left the ACLs alone, then the MS05-051 update operates properly on your computer. But if you made changes, and put more restrictive permissions on %WINDIR%\registration, then the update appears to break the system because it actually can't function properly now. KB909444 describes the symptoms, the problem, and the resolution: restore the default permissions on that folder.

Better, restore (if you can) the default permissions on the entire %WINDIR% tree and seriously rethink the guidance. Consider this bit from KB885409, written over a year ago in August 2004:

Microsoft Windows XP and Microsoft Windows Server 2003 have considerably tightened system permissions.... Because of these changes to the core operating system of Windows XP and of Windows Server 2003, extensive changes to file permissions on the root of the operating system are no longer required.

Additional ACL changes may invalidate all or most of the application compatibility testing that is performed by Microsoft. Frequently, changes such as these have not undergone the in-depth testing that Microsoft has performed on other settings. Support cases and field experience has shown that ACL edits change the fundamental behavior of the operating system, frequently in unintended ways. These changes affect application compatibility and stability and reduce functionality, both in terms of performance and capability.

Because of these changes, we do not recommend that you modify file system ACLs on files that are included with the operating system on production systems. We recommend that you evaluate any additional ACL changes against a known threat to understand any potential advantages the changes may lend to a specific configuration. For these reasons, our guides make only very minimal ACL changes and only to Windows 2000. For Windows 2000, several minor changes are required. These changes are described in the Windows 2000 Security Hardening Guide.

Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs ACL changes, or you apply the system defaults, you cannot roll back the original ACLs....

To help you remove the worst results of such file and registry permissions, Microsoft will provide commercially reasonable efforts in line with your support contract. However, currently, you cannot roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting your hard disk drive and by reinstalling the operating system.

For example, modifications to registry ACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the ACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can only guarantee that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.

Reformatting and rebuilding your production server is the ultimate destabilizing activity! (Also commonly known as an RGE: a resume-generating event.) There's no substitute for testing updates yourself, on your own systems (virtualization is your friend here). We test all updates thoroughly, including on systems configured according to our own published security guidance. But there's no way we can test all permutations of all third-party guides. Resist the urge to tweak every security setting just because it's there. Sometimes the defaults are good enough, and in the case of the file system and the registry, good enough really is exactly what you need.

The bulletin
Vulnerabilities in MSDTC and COM+ could allow remote code execution
http://www.microsoft.com/technet/security/bulletin/ms05-051.mspx
http://support.microsoft.com/kb/902400

The problems
Systems that have changed the default access control list permissions on the %WINDIR%\registration directory my experience various problems after you install the Microsoft security bulletin MS05-051 for COM+ and MSDTC
http://support.microsoft.com/kb/909444

What you shouldn't be doing
Security configuration guidance support: "File system and registry access control list modifications"
http://support.microsoft.com/kb/885409/#XSLTH4173121122120121120120

Other stuff you shouldn't be doing
Client, service, and program incompatibilities that might occur when you modify security settings and user rights assignments
http://support.microsoft.com/kb/823659

Re-enabling TIP
How to configure MSDTC transaction Internet protocol functionality after you install security update 902400
http://support.microsoft.com/kb/908620

Securing Terminal Services over the Internet

Steve Riley — Tue, 28 Jun 2005 19:54:00 GMT

In my presentation on remote access at TechEd, I gave three scenarios:

web-based access to internal resources, published with ISA Server
"desktop over the Internet" using Terminal Services and the remote desktop web connection
full IP-based virtual private networks with L2TP+IPsec

In the discussion on TS over the Internet, I failed to mention a very important bit. There is no mechanism built into RDP to authenticate the server to the client. This creates an opportunity to conduct a man-in-the-middle attack. Tools now exist to do exactly this.

In Windows Server 2003, you can configure TS to use TLS for server authentication and data encryption. This is extremely important for anyone running TS over the Internet. See KB 895433 for the step-by-step details.

Bug in the book: Appendix C, hosts file

Steve Riley — Tue, 28 Jun 2005 19:49:00 GMT

Somehow this escaped our notice during the proof phase, but the hosts file that's printed in the book (and burned on the CD-ROM) is completely bogus. It actually blocks a number of very good sites that have anti-spyware software and even blocks MVPS.org, the place where you can get a real spyware/adware blocking hosts file.

So please ignore the file in the book, and our apologies to anyone we might have offended. Instead, get the regularly-updated spam and ad blocking hosts file from MVPS. You'll be happy you did!

New column -- Using IPsec for network protection

Steve Riley — Thu, 10 Feb 2005 20:59:00 GMT

I'm now writing semi-regular articles for TechNet. These are part of the security management series, and they're also linked from the security newsletter.

The first column is a two-parter about IPsec. Part 1 describes the technology: how it operates, its various modes and methods, a bit on IKE, and how it works over NAT.

http://www.microsoft.com/technet/community/columns/secmgmt/sm121504.mspx

Part 2 illustrates three excellent scenarios that you can apply IPsec to today: stopping worms, protecting servers, and isolating domains -- a very cool approach for requiring domain membership of all your computers. Get rid of the rogues!

http://www.microsoft.com/technet/community/columns/secmgmt/sm0105.mspx

Security newsletter

If you haven't already, I urge you to sign up for the security newsletter. Hundreds of thousands of subscribers -- many of whom might be your competitors (LOL) -- already benefit from the tips, tricks, updates, guidance, and news we publish every month. So sign up today! My columns are always linked from here, too.

http://www.microsoft.com/technet/security/secnews/default.mspx