Tutorials

IIS Server Hardening – Banner Grabbing Prevention Techniques

IIS (Internet Information Server) is one of the most powerful web servers from Microsoft that is used to host your Web application. IIS has it’s own Process Engine to handle the request. So, when a request comes from client to server, IIS takes that request and process it and send response back to clients.

Internet Information Services (IIS) 7 and later provide a request-processing architecture which includes:

  • The Windows Process Activation Service (WAS), which enables sites to use protocols other than HTTP and HTTPS.
  • A Web server engine that can be customized by adding or removing modules.
  • Integrated request-processing pipelines from IIS and The Official Microsoft ASP.NET Site.

Typically we have 3 response headers which many people want to remove for security reason.

  1. Server – Specifies web server version.
  2. X-Powered-By – Indicates that the website is “powered by ASP.NET.”
  3. X-AspNet-Version – Specifies the version of ASP.NET used.

Along with we also have to add some more security headers like:

  1. X-Frame-Options – Provides click jacking protection.
  2. X-xss-protection – To enable the cross-site scripting (XSS) filters.
  3. Strict-Transport-Security – Which restricts web browsers to access web servers solely over HTTPS.
  4. X-content-type – Prevents Internet Explorer and Google Chrome from sniffing a response away from the declared content-type.
  5. Content-security-policy – Prevent attacks such as Cross Site Scripting (XSS) and other code injection attacks.

You can even scan your website headers from below options –

a) Keycdn Tool – Online Scanner
b) SecruityHeaders.io
c) Firebug Firefox Addon (Most Popular and Stable Addon)
d) Chrome Dev Tools (Press F12 for this)

1) Disable X-ASPNET-VERSION –

For security purposes, it may be desirable to disable the X-ASPNET-VERSION HTTP Header. This can be disabled by editing the web.config file which is located in your root directory.

Just after the <system.web> tag, Add the below code:

<httpRuntime enableVersionHeader=”false” />

2) DISABLE SERVER VERSION –

To prevent this server information from being displayed, you can either implement URLScan or URLREWRITE utility that is available at the Microsoft security Web site.

a) With URLSCAN 3.1 –

UrlScan is a security tool that restricts the types of HTTP requests that IIS will process. By blocking specific HTTP requests, the UrlScan tool helps to prevent potentially harmful requests from reaching applications on the server.

Download Link – https://www.iis.net/downloads/microsoft/urlscan

Now to hide the server version info, you need to first stop the IISAdmin Service and then locate the file “Urlscan.ini” which is located in %systemroot%\System32\Inetsrv\Urlscan directory.

Edit the above said Urlscan.ini file and locate the following entry:

RemoveServerHeader=0

Modify this entry as follows:

RemoveServerHeader=1

Save the file and restart the World Wide Web Publishing service and all of the other services that were stopped when the IISAdmin service was stopped.

UrlScan 3.1 can be configured to filter HTTP querystring values and other HTTP headers to mitigate SQL injection attacks while the root cause is being fixed in the application.

b) With URLRewrite 2.1

IIS URL Rewrite utility enables Web administrators to create powerful rules to implement URLs that are easier for users to remember and easier for search engines to find.

By using rule templates, rewrite maps, .NET providers, and other functionality integrated into IIS Manager, Web administrators can easily set up rules to define URL rewriting behavior based on HTTP headers, HTTP response or request headers, IIS server variables, and even complex programmatic rules.

Download Link – https://www.iis.net/downloads/microsoft/url-rewrite

You can use the following URL Rewrite Outbound rule:

<rewrite>
<outboundRules rewriteBeforeCache=”true”>
<rule name=”Remove Server header”>
<match serverVariable=”RESPONSE_Server” pattern=”.+” />
<action type=”Rewrite” value=”” />
</rule>
</outboundRules>
</rewrite>

This is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third party applications, may require the Server header, so you may need to remove this rule for those applications.

If you want to put your custom value as server attribute then you can edit the below code as:

<action type=”Rewrite” value=”YEAHHUB Servers Ltd.” />

3) Remove X-Powered-By Header

By default IIS tells the world it’s powered by ASP.NET, by placing an X-Powered-By header. This response header can easily be removed with a customHeaders setting in web.config, placed in the <system.webServer> node:

<httpProtocol>
<customHeaders>
<remove name=”X-Powered-By” />
</customHeaders>
</httpProtocol>

And for Specially Azure based servers, you can have the following code to remove the server info and x-powered-by headers:

<security>
<requestFiltering removeServerHeader =”true” />
</security>

4) Disable HTTP Methods

At several points as a web server/site administrators, we will be required to disable certain HTTP methods like CONNECT, PUT, DELETE, OPTIONS, TRACE, DEBUG etc from the web and app servers we support.

The most common reason to disable these HTTP methods is due to some security best practice.

For IIS Servers, you can easily disable all above HTTP Methods by placing the following code in your web.config file enclosing in <system.webServer> node.

<security>
<requestFiltering>
<verbs allowUnlisted=”true”>
<add verb=”OPTIONS” allowed=”false” />
<add verb=”DELETE” allowed=”false” />
<add verb=”TRACE” allowed=”false” />
<add verb=”PUT” allowed=”false” />
<add verb=”DEBUG” allowed=”false” />
</verbs>
</requestFiltering>
</security>

5) Enable Custom Error Pages (400,404,500 etc)

The customErrors element can be defined at any level in the application file hierarchy. The following configuration example demonstrates how to specify the error handling pages to use for an ASP.NET application.

<system.web>
<customErrors mode=”On” defaultRedirect=”error.htm”>
<error statusCode=”403″ redirect=”error.htm” />
<error statusCode=”404″ redirect=”error.htm” />
<error statusCode=”500″ redirect=”error.htm” />
</customErrors>
</system.web>

Create a simple error.htm file in same directory and put any legitimate content which you want to show for above said error codes i.e. 403,404 and 500.

Furthermore, you can also put the below code to prevent all tracing errors:

<system.webServer>
<httpErrors errorMode=”Custom” existingResponse=”Auto” defaultResponseMode=”File” >
<remove statusCode=”404″/>
<error statusCode=”404″ path=”error.htm” />
</httpErrors>
</system.webServer>

There are basically three error modes in which an ASP.NET application can work:

1) Off Mode
2) On Mode
3) RemoteOnly Mode

By default, the mode value is set to “RemoteOnly”.

  1. Off Mode – When the error attribute is set to “Off”, ASP.NET uses its default error page for both local and remote users in case of an error.
  2. On Mode – In case of “On” Mode, ASP.NET uses user-defined custom error page instead of its default error page for both local and remote users. If a custom error page is not specified, ASP.NET shows the error page describing how to enable remote viewing of errors.
  3. RemoteOnly – ASP.NET error page is shown only to local users. Remote requests will first check the configuration settings for the custom error page or finally show an IIS error.

6) Adding Custom Security Headers

By adding below security headers will provides you an extra layer of security to your web application.

<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name=”X-Frame-Options” value=”DENY” />
<add name=”x-xss-protection” value=”1; mode=block” />
<add name=”strict-transport-security” value=”1; mode=max-age=31536000; includeSubDomains; preload” />
<add name=”x-content-type” value=”nosniff” />
<add name=”X-Content-Type-Options” value=”nosniff” />
<remove name=”ETag”/>
<add name=”ETag” value=”None”/>
</customHeaders>
<redirectHeaders>
<clear />
</redirectHeaders>
</httpProtocol>

As you can see HTTP security headers can help harden the security of your website and in most scenarios there is no reason not to use them. If you don’t control access to your own web servers we recommend reaching out to your web host administrator and let them know.

DO NOT DIRECTLY COPY PASTE THE EXACT CODE, SOMETIMES YOU’ll SEE THE DOUBLE QUOTE in this format (” ”) but it should be like this (” “).

Yeahhub.com
Step by step hacking tutorials about wireless cracking, kali linux, metasploit, ethical hacking, seo tips and tricks, malware analysis and scanning.
http://www.yeahhub.com/

Leave a Reply

Your email address will not be published. Required fields are marked *

7 + 16 =