Content-location http header errors divulged DMZ/internal IP address

I've had an external security audit recently done and I'm having some trouble with one of the items they cited as a security concern.  It is for an Exchange 2003 OWA server, here is what they wrote:

Content-location http header” errors divulged DMZ/internal IP address for device with external address  Auditor recommends configuring the web servers to not disclose specific information.

I looked this up and found this KB Article:

I already have all service packs applied so I entered the command as directed with the following variables:
cscript adsutil.vbs set w3svc/1/SetHostName exchange

This broke something in DNS and I couldn't load the page at all.  Fortunately I had backed up the metabase right before so was able to do a full restore.  Unfortunately none of the icons on the page would load which turned out to be an authentication problem but I was able to correct that.

Obviously making that change caused some kind of DNS problem but I'm not sure what variable I should replace "exchange" with in order to both fix the problem and allow OWA to continue operating.  Any advice would be appreciated.
First LastAsked:
Who is Participating?
RovastarConnect With a Mentor Commented:
So the external vulerability testers have displayed to you the internal IP of your server? Not just spectalated that this might be the case (they just run a test see you are using IIS6 and say you are vulernable to x, y, z without any checking)

There are a few way to get to a web site

host header is one e.g.
Ip address is another

In IIS many sites can be served from 1 IP address via many host headers.

If you enter the IP address directly (this is not widley seen or recommened - hence best practice) of your external server IP address it may be possible to view your internal IP address.

If entering your external IP say doesn't return any page at all (the http.sys blocks it because IIS says that no website exists and no page is returned) then there is no vulernability.


Do you currently want to display your website to your users via an IP address like
Hopefully you do not and it is via a domian name. That is what I am presuming.

If you don't want to ever serve content from an IP address then in IIS set this so you never respond to an IP address and the client has to enter a valid host header (domain name).

Select each website --> Properties --> Web site tab --> Click Advanced and for make sure that the host header is not left blank. If it is blank it menas that you do not have to specfic a host header or in other word you can just enter the IP address.

Hope that helps.
Does this actually recreated an issue or is this an automateed report by an "auditor" using old data?

Anyway I worked with a OWASP leading pen tester for a few days solely to try and reproduce this problem as we had time and week just to look at a IIS 6 configuration with no code...

The conclusion is that if the server is setup correctly it is not a problem and cannot be reproducable.

Really all you have to do was not respond to IP address and make it so you have to respond *only* to a host header.

Generally it is best practice to have host headers for a site and only reply to host headers anyway. So if you do this best practice this is not reproducable.

It gets stopped in the http.sys and that does not process the request to IIS and therefore the internal IP adreess is never recorded.
First LastAuthor Commented:
This particular item was cited several times, we have an external vulnerability assessment done twice yearly.  It came up again last month and I've been asked to take care of it permanently.  When you say "if the server is setup correctly' I'm not sure what you mean.  You also wrote that it is best practice to have host headers for a site and only reply to host headers...I'm not sure what that means either, can you elaborate?

The vulnerability exists, it does show up on the current EVA and I'm looking for ways to prevent the disclosure of the internal IP.  I believe the answer is to use the "UseHostName True" variable in the link I posted but I want to be sure it won't break DNS again.
First LastAuthor Commented:
Excellent, I will check on this info over the weekend and post back the results on Monday, thank you for the help!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.