I can't find the article right now, but I saw a detailed article about how someone secured an IIS server against all past, present, and future security holes in IIS. The idea was simple, the implementation not quite so.

What they did is put up a reverse proxy in front of it which did very strict validations of what it would allow to be proxied. If they didn't know why a request should be allowed through, or if the request matched certain parameters for a buffer overflow, it was blocked. There was no way from the internet to directly access the IIS server.

It was a lot of work, but their reason for doing it is that they had a web application which didn't successfully port to a newer version of IIS, which they didn't have the luxury to rewrite immediately, which they couldn't just discontinue, and which they needed to have secured against bugs in the old IIS. So they analyzed the application, and produced their reverse proxy.

Cheers,
Ben

PS The admins in this case were uncommonly competent. Not surprisingly, they considered this secure version of IIS to be a stopgap measure, and they planned to rewrite it for Apache when they got time. :-)