*** UPDATE 03/04/2012 ***
I’ve recently had a couple of interesting comments relating to this post and felt its worth updating my blog to make you aware of the impact of changing the settings I discuss below.
Firstly it is worth mentioning that the initial reason for blogging on this was due to a clients penetration test highlighting this security vulnerability and therefore it is still a valid consideration however the impact of making this change means that you will break SharePoint search and therefore thanks to Anthony Casillas and Iain Wyatt’s comments I have highlighted this as part of the post below.
*** UPDATE END ***
Here is a guide to remove IIS server header Server: Microsoft-IIS/6.0 from IIS to stop your browser detecting the web server SharePoint is running on. This can be particularly useful if you are externally publishing SharePoint or other IIS .NET applications and want to reduce the information to your backend servers information.
Background
Without additional configuration you can identify what platform IIS is running on using a simple tool to view the http headers.
If you download and install a tool such as ieHTTPHeaders from here. From Internet Explorer enable the tool from ‘Tools->Display ieHTTPHeaders’. Load the homepage of SharePoint and you will notice that amongst the many headers and requests you will notice something similar to the below:
Server: Microsoft-IIS/6.0
MicrosoftSharePointTeamServices: 12.0.0.6318
X-Powered-By: ASP.NET
How to remove these from IIS
NOTE: Before editing any settings to allow search to function it is required that you configure the default zone with these headers untouched and modify extended (AAM) SharePoint sites.
The last two lines can simply be removed from IIS by editing the properties of the web site under the custom HTTP headers section as shown below, noting this is IIS 6 but the same applies to IIS 7.
To remove the header Server: Microsoft-IIS/6.0 from IIS this requires a little more config!
Firstly you need to download URLScan (at the time of writing this is version 3.1) from Microsoft here. This is basically an ISAPI filter that needs to be applied to the website you wish to remove the headers from, making sure that if you have extended a SharePoint web app you assign the ISAPI filter to the correct one (i.e. the one created for external access).
Install URLScan, then from the same web app select ISAPI Filters tab and select add navigating to C:\windows\system32\inetsrv\urlscan and add urlscan.dll (IIS 7 may do this for you).
Then edit the urlscan.ini line
RemoveServerHeader=1 ; If 1, remove the 'Server' header from
; response. The default is 0.
Save the file and check the HTTP headers using ieHTTPHeaders and you should now not see the these headers when loading pages.
Feel free to leave a comment if you have any thoughts.
3 comments:
I know this is an old blog, but hopefully this will bring visibilty to those inquiring about this IIS Response Header..
It will absolutely break your SharePoint crawling and not index items in library and lists..
This header lets our SharePoint gatherer know it is SharePoint and will then allow it to use the sitedata.asmx web service to enumerate through the sites to get ACL's, Lists & Libraries and Items in those lists & libraries. If you want to reduce the surface attack, it would be recommened to create your Default AAM Zone with NTLM and leave those headers in place so that Sharepoint can properly crawl content, but then to extend and map another IIS site into another AAM zone to place into your public facing site..
Thanks,
Anthony Casillas [MSFT]
We encountered this as well. i.e. search was broken by removing the headers. We found that even if you specify the content source as a SharePoint site, when the crawler hits the site if the SharePoint header is missing then it reverts to a standard Website crawl and the metadata is not indexed. However the gotcha is that if you remove the header and there was existing metadata against that page already in the index it will remain in the index. It is only when the index is reset that you lose the metadata.
Anthony / Iain, thanks for the comments. I have modified my blog to make anyone aware of considering this to take into account the impact this has and further consideration and advice needed before commmiting this change as I know Iain spent many an hour trying to resolve this with the assistance of MS.
Thanks again for the cotributions avoiding others from experiencing this issue.
Paul
Post a Comment