Ask Us About... Security, July 2001

by Joel Scambray

July 2001

My previous column inspired some follow-up questions, which I will treat in this month's installment of Ask Us About Security (AUAS).

On This Page

IIS Hotfixes Are Now Cumulative
Security Templates are Cumulative, Too
Domain Controller Not Found Error When Setting Up ACLs
Windows XP Security: Separating Hype from Reality

IIS Hotfixes Are Now Cumulative

In last month's column, I discussed several changes made to the Microsoft security hotfix technologies. As one editor of my column and one reader pointed out in an e-mail to me, I forgot to address one important change: beginning with MS01-026, all Internet Information Services (IIS) hotfixes will be cumulative. In other words, they will contain all hotfixes relevant to the version of IIS in question and will install them along with the current one. Therefore, if you install a hotfix for IIS starting with MS01-026 or later, you will be getting all previous security patches.

Microsoft did this because of the relatively small number of DLLs that comprise IIS. Since IIS hotfixes generally replace one or more of these DLLs, it was logical to simply check that all DLLs were updated with each hotfix. That way, if you keep up with IIS hotfixes going forward, you can always be assured of having the most updated IIS security.

Of course, the obvious caveats apply. If your applications have known issues with a previous hotfix, you are going to get it with the newest fixes, like it or not. Generally, IIS hotfixes have proved benign from a compatibility standpoint, so this should not be an issue for most shops.

One other thing to consider is that since all IIS DLLs are checked by cumulative hotfixes, these DLLs must be available during application of the hotfix. If an IIS DLL is not available, they will not be updated. For example, for those customers that have disabled WebDAV on their IIS 5.0 servers, they will have to temporarily re-enable it while applying hotfixes to ensure that the WebDAV DLL (httpext.dll) gets updated. If you are using IIS 4.0, you should ensure that the correct installation order has been followed before installing this or any security patch.

Security Templates are Cumulative, Too

Q: I had a question regarding your March 2001 column. My research on templates indicates that templates should be applied in order, from the lowest level of security, to the highest level that you desire, as higher security templates do not apply security measures applied in earlier scripts. Is this true?

A: This is incorrect. Security templates are cumulative in the sense that the more stringent security templates apply all of the setting necessary to lock Microsoft Windows NT® and Microsoft Windows® 2000 down to the specified level. For example, the Hisecws template can be applied by itself, without having to apply any of the less-stringent security templates first. If you want to back off of a security template, apply the "setup security" template, which turns everything back to out-of-the-box default security settings.

Again, I recommend that each of the settings specified in these templates be understood before applying them willy-nilly. The templates supplied with Windows 2000 may be too rigid, or not rigid enough for you applications. At least, though, you can be rest assured that you do not need to apply them in order—they stand all by themselves.

Domain Controller Not Found Error When Setting Up ACLs

Q: I have a two-way trust relationship between two Windows 2000 domains in separate forests. When I try to add users from the one domain to local groups, or give them access to files or directories, I receive an error "Cannot find domain controller." What causes this?

A: Windows 2000 introduces a new domain controller discovery mechanism than what was used with Windows NT 4. Windows 2000 uses the Domain Naming System (DNS) to find the IP addresses of the domain controllers. In order to find a domain controller in a particular domain or forest, a client queries DNS for the appropriate service location (SRV) and address (A) resource records. These DNS resource records provide the names and IP addresses of the domain controllers.

What is probably happening here is that these service location records were never created dynamically during or after the creation of the DNS zone. You'll need to go back and manually add the appropriate records to the DNS for each domain on an authoritative DNS server. The list of records that should be registered by a domain controller is stored in the %SystemRoot%\System32\Config\Netlogon.dns file on the domain controller. The article DNS Requirements for Deploying Active Directory has more information on other potential issues related to DNS resolution issues like this.

Windows XP Security: Separating Hype from Reality

Q: I did a security check on my home computer system, which is connected via broadband cable modem to the Internet. The test said I need a 'firewall' as I have currently have no security protection. How can I put this on my computer? I am on Windows ME client behind a system running Windows 2000 as the network gateway.

A: Get Windows XP! Windows XP comes with an integrated Internet Connection Firewall (ICF) and Internet Connection Sharing (ICS). I've been evaluating Windows XP ICF/ICS with some colleagues lately, and we find it to be quite robust from a security perspective, and easy to use (if you turn it on. It is not enabled by default!). A couple of points to remember are that ICF will currently not allow you to specify network access control rules based on remote computer IP address, and that it does not allow specification of outbound access control rules.

OK, you probably can't wait until October 2001 for the official release of Windows XP, so here's some personal firewalls to tide you over in the meantime. As I have said in past columns, I am a fan of Black Ice Defender. Another popular personal firewall is Zone Alarm.

More advanced users who are running Windows 2000 should also consider 1058600227IPSec filters, which I treated in a past column.

On a semi-related note, a programmer named Steve Gibson recently published a paper deriding Windows XP for implementing obscure networking functionality called "raw sockets" that makes it easier to spoof Internet Protocol (IP) addresses than with previous version of Windows. Gibson builds on this otherwise benign factoid to build a case that "Windows XP will be the Denial of Service Exploitation Tool of Choice for Hackers Everywhere" (Denial of Service in all caps, bright red font on Gibson's page). I hesitate to give this sensationalistic article any more play than it has already received, but I feel strongly that Gibson's portrayal misses several key points, and dramatically misleads his audience about the impact of this feature.

Let's start with the main point made in the Microsoft official response to Gibson's paper. Assuming that a powerful piece of software was connected to the Internet, and it fell into the hands of vandals, bad things would result. I'm not sure if printing "Denial of Service" in bright red letters will change this fact. Ultimately, it only serves to alarm consumers who care little for the difference between a socket and a packet anyway.

Secondly, current versions of Windows provide the ability to spoof packets. I have used tools that perform address spoofing frequently on Windows NT and Windows 2000 in my work. I'm not sure why this paper singles out Windows XP as different.

Furthermore, many other operating systems have implemented raw sockets for years. The fact is, given sufficient privileges on any software operating system, forging of network packets is theoretically impossible to prevent. I would hope that most Internet users would have a serious problem with mandatory disabling of such flexibility as a condition of connecting to the network.

One final point not made in the Microsoft response is the importance of egress filtering by Internet Service Providers (ISPs), which Gibson belatedly addressed in an addition to his first post of the article. Egress filtering is the blocking of communications with forged source addresses at network entry points. If ISPs implemented egress filtering consistently, spoofed packets could never enter the network. Since Distributed Denial of service attacks claimed their first high-profile victims in February of 2000, most savvy network security folk have agreed that proper egress filtering at ISP routers would practically eradicate the problems that Gibson decries.

Having watched Windows security for years now, I find it amusing that anyone would criticize an attempt to promote compatibility with existing programming standards. Isn't that what the Internet is all about anyway?

See You Next Month!

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets and Solutions from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.