3 Years and 3 months

davcox — Fri, 21 Jul 2006 18:44:00 GMT

Windows Server 2003 and IIS6 released in March of 2003. Last week, we released a patch for asp.dll to fix our first vulnerability in over 3 years!

It was kind of a sad day for the team (but one that we knew would come), because after IIS5, we committed as a team to never let IIS be an primary attack vector for the Windows platform. And so far we've been able to keep that commitment. Hopefully it'll be another 3 years before we release another one! :) So it was also a happy day in that 3 years is a really long time (these days) for your product to be really "unbreakable". :)

I had the duty of testing the patch before it was released to make sure the vulnerability was indeed fixed. Ulad did a great job of doing a very thorough analysis of the code and a thorough fix to the issue. Given that we hadn't shipped a release like this in 3 years we did have a couple hicups, you might have seen or experienced this issue:

http://news.com.com/Microsoft+irons+out+security+patch/2100-1002_3-6096179.html?tag=newsmap

That issue was mostly due to the "detectoid" logic that WU uses to say if the patch is needed or not; the patch itself was fine (so no work was required on the IIS side) although I spent a long night here last week to help them pinpoint the issue.

Also, we were unable to get the right logic to restart w3svc prior to updating the asp.dll binary, but there is an easy workaround for that. Next time, (if there is a next time) we'll be sure to get that logic correct.

As the MSRC bulletin says, this vulnerability requires the attacker to place asp content on the machine (so for example hosting scenarios). Once the maliciously formed page is requested, the attacker would be able to run arbitrary code. So it's certainly an important patch to install. There is extremely little risk in installling this patch given the nature of the code change and the testing that we did on this patch.

Anyway, I'm glad to be back blogging, I had some permissions and user account problems blocking me.

Perf counter behavior changes in IIS6

alowe — Fri, 17 Mar 2006 21:41:00 GMT

I thought I'd really just share some information I collected while testing perf counters during the IIS6 days. The big changes were primarily to address the architecture and new process model that HTTP.sys and IIS provided and also to help our scalability situation. Much of the counter behavior was already documented in the resource kit, but I thought I'd add my own flavor to this, since I helped the UE people write the docs and I think they did a great job given the difficult challenge it is to write about something as you learn it. So this blog basically covers two items; it covers counters that have new behavior and then some registry keys you can set if you really need to scale out your server for tens of thousands of sites (rare).

Counters that have updated behavior

Bytes Per Second and Total Bytes counters

In IIS5, these counters gave you the Bytes per Second:

"BYTES_SENT_COUNTER",

"BYTES_RECEIVED_COUNTER",

"BYTES_TOTAL_COUNTER"

In IIS6, they give you Bytes Total (Total sent, total received, total sent+received)

These counters are new in IIS6 and will return the Bytes per Second values:

"BYTES_SENT_PER_SEC",

"BYTES_RECEIVED_PER_SEC",

"BYTES_TOTAL_PER_SEC"

This brings the PDH counters in line with SNMP counters that had already existed.

IIS 6.0 counts Current Non/AnonymousUsers as Current Requests; IIS5 equates users with connections.

This means that you’re going to notice much smaller CurrentAnonymousUsers count in IIS6 (and consequently a lower MaxAnonymousUser). The same is true for NonAnonymousUser counters. But actually it is just more accurate. CurrentUsers are now the # of current in-flight requests (the # of requests currently being worked on by the server). CurrentConnections is a better counter to monitor for scalabilty and availability metrics (its behavior is unchanged). This number will of course be much higher than the number of users for sites that support keep-alive connections.

It’s important to remember that in IIS6 each request (not connection) is logically a user.

In IIS 6.0 the Kernel Mode Cache causes some new behavior in counters.

You may notice that these counters no longer increment when files are only being served out of the Kernel-Mode cache.

Total Files Sent

Total Files Transfered

Instead, Web Service Cache\Kernel: URI Cache Hits will be incremented.

Total Anonymous Users and related Anonymous User counters will be updated during cache hits. Be aware that the Kernel mode cache does not cache requests that are authenticated so the NonAnonymousUser related counters are exactly the same as before.

New general counter behavior

Several new registry keys exist to help IIS scale to many more sites:

The registry keys all exist under this node:

HKLM\SYSTEM\CurrentControlSet\Services\w3svc\Performance\

Here are some typical settings that we used in our testing (no warranties expressed or implied):

"FreshTimeForCounters",1,"REG_DWORD"

"CheckCountersEveryNMiliseconds",250,"REG_DWORD"

"NumberOfTimesToCheckCounters",8,"REG_DWORD"

These registry keys allows IIS to “check” on the counters less often. As you add more sites to IIS, each site will be “asked” for counters which can be quite time consuming. The idea here is that you want to increase the Miliseconds and FreshTime to a higher number when you have higher sites. You'll know you might want to do this if you have a lot of extremely idle sites (on the order of more than 10 thousand), but the w3wp's are using up a lot of processor time. Be careful here, most people won't need to mess with these registry keys.

Dave's Blog : IIS6

3 Years and 3 months

Perf counter behavior changes in IIS6