IIS loves to inform the world that the web site runs on IIS, it does so using the Server response header as shown beneath. During this article I’ll show you how you can rewrite and eliminate unwanted response headers in IIS, as a result of we don’t need to provide hackers a lot of info concerning our servers.

The response of a standard HTTP HEAD appearance such as:
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Server: Microsoft-IIS/8.0
X-UA-Compatible: IE=Edge,chrome=1
Date: Thu, 04 Dec 2014 10:05:34 GMT
Connection: close

And right listed below IIS shows the version info by using the Server response header. As using the ETag header, you are able to rewrite and empty this Server response header along with an IIS URL Rewrite outboundRule:
<rewrite>           
  <outboundRules rewriteBeforeCache="true">
    <rule name="Remove Server header">
      <match serverVariable="RESPONSE_Server" pattern=".+" />
      <action type="Rewrite" value="" />
    </rule>
  </outboundRules>
</rewrite>

The outboundRule looks for Server inside the output response stream and rewrites the value along with nothing. The end result is an empty Server response header line:
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Server:
X-UA-Compatible: IE=Edge,chrome=1
Date: Thu, 04 Dec 2014 10:06:08 GMT
Connection: close

Rewrite Server : Microsoft-IIS/8. 0 with your personal information
The enjoyable section of rewriting response headers is that you may show your own string, for instance giving in an value inside the Rewrite action, which message is displayed:
<action type="Rewrite" value="europeanwindowshosting" />

HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Server: Saotn Server Software systems, LTD.
X-UA-Compatible: IE=Edge,chrome=1
Date: Thu, 04 Dec 2014 11:19:16 GMT
Connection: close

Eliminate X-Powered-By header in IIS utilizing customHeaders
By default IIS tells the world it’s powered by ASP. NET, by putting an X-Powered-By header:
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Server:
X-Powered-By: ASP.NET
X-UA-Compatible: IE=Edge,chrome=1
Date: Thu, 04 Dec 2014 10:07:37 GMT
Connection: close

This response header could be removed having a customHeaders setting in web. config, placed inside the node:
<httpProtocol>
  <customHeaders>
    <remove name="X-Powered-By" />
  </customHeaders>
</httpProtocol>

Currently the X-Powered-By header is removed from the response header output:
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Server:
X-UA-Compatible: IE=Edge,chrome=1
Date: Thu, 04 Dec 2014 10:10:02 GMT
Connection: close

X-AspNet-Version HTTP header
The X-AspNet-Version HTTP Header broadcasts to the world what version of ASP.NET has been used. Add the listed content inside node with your application’s web. config file:
<httpRuntime enableVersionHeader="false" />

Eliminate HTTP headers in global.asax
ASP.NET programmers can also eliminate or change server HTTP response headers through a global.asax file With your global.asax.cs add this :
protected void Application_PreSendRequestHeaders()
{
  // Response.Headers.Remove("Server");
 Response.Headers.Set("Server","My httpd server");
  Response.Headers.Remove("X-AspNet-Version");
  Response.Headers.Remove("X-AspNetMvc-Version");
}

When IIS 7 was released the FTP service were totally redesigned from the bottom up along with security on your mind. This was a welcome change indeed from IIS 6. Along with supporting FTP more than SSL it introduced FTP User Isolation.

Multiple users on a similar FTP website could possibly be separated no matter that file path they had been becoming logged into without risk of somebody traversing up parent paths with other user folders.

The FTP Authorization guidelines cause it to be simple to determine multiple users or perhaps local groups to get access to the FTP server. The user isolation is achieved by making a virtual directory referred to as LocalUser then selecting User name directory (disable global virtual directories). The LocalUser virtual directory ought to purpose towards the FTP root directory then you build a separate virtual directory for every FTP user that points to their destination path.

Along with FTP User Isolation configured your users can never have the ability to transfer up as much as a parent path beyond their individual root directory. Even if a user were able to accurately guess the username and virtual path of another FTP account upon the server they won't have the ability to achieve it. Because of the confines from the isolation the FTP session can not notice anything upon the server. In the illustration down below I login along with local account ftpuser2 and plan to change the path to/ftpuser1 but that path doesn't exist and hence isn't accessible to my user.

Conclusion
IIS 8 on Windows Server 2012 provides the foremost secure FTP service of any IIS version to day. You've multiple layers of FTP security accessible by leveraging FTP Logon Attempt Restrictions, FTP Over SSL, and FTP User Isolation. Your FTP server will certainly be nicely protected using these built-in modules. Along with internet security there isn't any ‘patch’ for complacence. A lot of security is usually much better so implement it when it’s readily accessible for you.