As far as including it in the build, perhaps someday, but not by RTM. Deliving out of band, as we call it internally, helps agility as we can get more content and services to you that way. When it's bundled with the OS, there is an extermely high load
that accompanies it which is as it should be for a core OS service.
I agree with you on this.
No way the web files should be on C: (or your system drive). And IIS does not prompt you. A long time ago in a land far away, well not so far actually, IIS 4 used to nicely ask you where you wanted to install the default website.
Along came Windows 2000 and the new law of the land was "make it easy to install - as few prompts as possilble". And it was so. There are indeed very few prompts during the install compared to installing NT4.
To compensate, you can direct the installation to any drive using an automated install which is far easier than it sounds. There are nuermous articles on this (SYSOCMGR and IIS).
Additionally, moving the default website is very simple and takes just a minute.
All that said, I would still like a prompt.
As far as other web applicaitons using "The Default Website" or website number 1, depending on what they look for, this is true of many applicaiotns and is why I recommend keeping it around, but disabling it. The teams inside Microsoft that write the installers
are the ones responbile for how much flexibility there is in this. I've seen the issue of where to install an web applicaiton handled very well and very poorly both inside and outside of Microsoft. For better or for worse, Microsoft operates like colection
of start ups. So if the Squiggy team wants to makes their web app install in "The Default Website", the mechanics of that is up to them - same as it is for you.
For developers, they want this to be easy and reliable so they make assumptions there will be a Website number 1, and generally there is.
"In IIS7, the ASP.NET request processing pipeline overlays the IIS pipeline directly, essentially providing a wrapper over it instead of plugging into it.
A request arriving for any content type is processed by IIS, with both native IIS modules and ASP.NET modules being able to provide request processing in all stages. This enables services provided by ASP.NET modules like Forms Authentication or Output Cache
to be used for requests to ASP pages, PHP pages, static files, and so on.
The ability to plug in directly into the server pipeline allows ASP.NET modules to replace, run before, or run after any IIS functionality. This enables, for example, a custom ASP.NET basic authentication module written to use the Membership service and
SQL Server user database to replace the built in IIS basic authentication feature that works only with Windows accounts.
In addition, the expanded ASP.NET APIs take advantage of direct integration to enable more request processing tasks. For example, ASP.NET modules can modify request headers before other components process the request, inserting an Accept-Language header
before ASP applications execute in order to force localized content to be sent back to the client based on user preference."
When you add a service after a service pack, you do not need to reapply the service pack. This has been true since Window 2000.
It is also true that if you apply a service pack, then uninstall and reinstall a service, in this case IIS, you do not need to reapply the service pack. However, you may need reapply hotfixes.
To answer the question of how can you tell, you can always run Windows Update or Microsoft Security Baseline Analyzer to report on the updates you need.
While Windows Update, Security Analyzer, WUS, and other improvements have made patching eaiser, there is still a lot of work to do and is no substitute for releasing rock sold products that don't need much in terms of patching. IIS 6 is a big step in the right
directioon and we're working very hard to ensure that IIS 7 meets or exceeds that.
Thanks for you reply. I really like this conversation.
I am tempted to ask what you would consider "real" numbers, but any numbers or claims I make are going to be critizied as being non-objective. That's why I invite you to do the research and come to your own conclusions. Check Secunia.net. Check Securityfocus.
Check anywhere you like. Objectively compare IIS 6 and Windows 2003 to any OS+Web Server released at that time and see what the data says. That's all I'm saying here.
As for Roger, he writes a security column for Infoworld, is an author for Windows IT Pro Magazine, and teachs hardening and security classes (Ultimate Hacking) for Foundstone and SANs. Knows a bit about the topic.
I'd love to interview anyone you think would be important to listen to as an admin (or dev). If you tell me who you would like, I'll try to get them on record and posted to C9.
What you've found is an internet caching service, not a traceback to a Microsoft.com server. Microsoft.com uses out of the box IIS 6, 64 bit servers. Same stuff you can use. Ditto for Myspace.com and many other high volume, high availability sites. -brett
And Writing Secure Code by Michael Howard
"Just say no to parent paths. If you remove the requirement for parent paths in your application, anyone attempting to access a resource by using parent paths is, by definition, an attacker!"
Yup, i was around. Of course the basics would have prevented code red such as applying existing patches or disabling extensions you aren't using. I didn't cover that info in the podcast since this was not about administration as much as much as what to
tell developers. I can assure it was not rehearsed.
So what I would like to know is what you would like to have heard in this? In other words, what would you say to developers are the top things the should know to write secure code for web applications?
Very interesting. Thanks for posting the interview. In the interview, I invite people to do the research and make their own conslusions. The whole point is to update people's pereception of judging IIS 6 based on track record for IIS 5, not to claim
that IIS is more secure than Apache or that Apache is insecure.