|
COMMAND IIS SYSTEMS AFFECTED IIS4 PROBLEM Dougal Campbell found following. He was recently trying to figure out how to set separate authentication realms for two different directories under the same vhost with IIS4. He eventually found an answer. See news://msnews.microsoft.com/<uPrCxZm0$GA.267@cppssbbsa04> but in the process Dougal noticed something that no one likes. When IIS4 (and we presume previous versions, and probably IIS5 as well) responds to a client trying to access an area protected by Basic authentication, and the client specifies HTTP 1.0, and if no Realm has been defined (as by the method above), it can return an internal address. This information could potentionally be used by crackers to locate other local hosts. For example, in our situation, our IIS server resides behind a firewall, which uses NAT. The internal address is 192.168.42.2 (not really, but for the purpose of this example it is), but external hosts see the NAT address of 209.192.88.2. Normally, nobody outside should know anything about the 192.168.42.x address space used internally. But, observe: dougal:~> telnet 209.192.88.2 80 Trying 209.192.88.2... Connected to 209.192.88.2. Escape character is '^]'. HEAD /secure/test/ HTTP/1.0[CRLF] [CRLF] HTTP/1.1 401 Access Denied WWW-Authenticate: Basic realm="192.168.42.2" Content-Length: 644 Content-Type: text/html Connection closed by foreign host. IIS has just given up a bit of internal information. SOLUTION Setting a realm string for the root level of the server (then setting separate realms for subdirs as needed) fixes things: cd c:\winnt\system32\inetsrv\adminsamples net stop w3svc cscript adsutil.vbs set w3svc/realm "ACME Corp" net start w3svc FYI, when the client uses HTTP 1.1, they are forced to provide a Host header, and IIS uses that value as the default realm, if one has not been set in the MetaBase..