I'm having a strange problem with my Windows 2000 IIS webserver that I run for my department on my company's intranet.  At least once and sometimes twice a day, it effectively shuts down and starts responding to every HTTP request with a 403.9 error (too many users).

I'm actually running three different IIS servers on three PC's, all on the same subnet, with IP addresses obtained using DHCP.  By looking at the logs, I've tracked down the problem to some weird interaction between the three IIS PC's and the DHCP server, but I don't know what's causing it.  It seems that the three IIS PC's and the DHCP server are making HTTP requests to each other for the "default.ida" file, and once that happens, that request and every subsequent request receives a 403.9 error, until the PC is rebooted or IIS is stopped and restarted.  Then things cruise along fine for a while, but overnight or perhaps later in the afternoon, another request for "default.ida" pops up and the 403 errors start again.  I know of no reason that the PC should be making HTTP requests to each other.  Also, there is no way the number of users is actually exceeding the limit, and the logs confirm this.  Rather, the problem seems to be somehow related to an interaction between servers.

Has anyone seen anything like this or have any idea what might be causing it?

Paul is correct.  Never, ever, put a server on DHCP.

I wish I could get a static IP address for my servers.  Unfortunately my IT department has a policy against static IP addresses and won't budge.  They are the kind of IT department that is great about telling you "no" but won't work with you to devise an alternative solution.  So I am left to run a webserver without IT's help because my department needs it whether the corporate IT supports it or not.

I can't get anywhere with searches for "default.ida" on either Google or TechNet.  The searches just go off and never come back with results.

I completely agree,  except in certain cases.
Lets say You are using AD + Dynamic updates.
Having servers like printservers, departmental webservers, stuff like that would be handy to have setup for dhcp. But for a webserver/mailserver/dnsserver/fileserver no it's not wise to have it DHCP.

Now  for your default.ida problem.  That sounds like an IIS virus to me.  You might want to check with your security department.

In your log files you might see something similar to      "216.91.122.205 - - [10/Jun/2003:08:13:29 -0500] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a  HTTP/1.0" 404 277
"

No clue how to solve the problem, but have you tried running apache instead?

Quite sorry to say I can be of no more help.  Your IT department is a joke, though.

I would immediately run a virus scan on it.

O comn guys, DHCP isn't ALWAYS a bad idea on a server.

Just as long as you have reservations setup and you know your DHCP server works correctly. [:D]

What version of Windows 2000? If Win 2000 Professional, you are only allowed 10 connections to IIS (port 80/web).  Now, keep in mind HTTP clients using keep-alive will keep connections open to the server, each client may have a couple connections open.  This can eat up your connections pretty fast, and then you will start to get the error you described.  If you go into your IIS Application settings you can uncheck the box that says "Use Keep-alive" or something like that.  Now, if you're using Win 2000 Server, I don't know, you're screwed!! haha j/k.  In that case, you should actually be able to edit the field that says "Max connections" which is set at 10 and uneditable in Win 2000 Pro.

Just a guess but…. You have never heard of something called "code red" have you? [:D]


Still scratching my head over the DHCP assigned server addies~

Requests to execute /default.ida are the signature of Code Red and similar worm attacks.  I run a bunch of Web servers for an educational software company.  We filter those out in a load-balancing box before they hit our live HTTP servers, but on our QA system that does not have that filtering we see that kind of request and many others coming in from all over the world all the time.  You really need to take some security measures, and here is one good way to get a leg up on it:

See [url]http://www.ciac.org/ciac/bulletins/l-117.shtml[/url] for information about Code Red.

Get your servers cleaned up IF there's anything wrong with them, then run the Microsoft IIS Lockdown Tool (see [url]http://www.microsoft.com/downloads/details.aspx?FamilyID=dde9efc0-bb30-47eb-9a61-fd755d23cdec&DisplayLang=en[/url] ) - This will fix some bad default configuration settings in IIS and install a freebie security tool, an ISAPI filter called URLScan, which by default will send requests for default.ida and many other potential nasties to the bit bucket.  You should also use any other means at your disposal to block requests of that nature.  Do you have a person dedicated to TCP/IP and IIS security?  You should.

I've got URLScan 2.5, a free upgrade.  Follow the docs and the links and you'll find it easily.  Depending on what kind of applications you are running you may need to tweak its configuration file to make everything work.

Also extremely important:  Make sure you are up to date on ALL the latest critical updates and patches.  There are new threats being discovered (mostly by Microsoft) just about every week, and if you don't do the patches you will get hit sooner or later.  Get up on Service Pack 3, Internet Explorer 6 (yes, even on your servers), and all critical updates.

DO THIS NOW!

Looks like it was the Code Red worm.  Thanks all of you for your help.  I'm working on fixing it now.

Glad to hear you have a handle on it.  There are a lot of other similar vulnerabilities and more keep getting found all the time.

I'm spending the next couple of work days making sure all my servers are properly patched and secured.  It's a lot of work.