In a few Web sites, if we type the Web site name, (like www.someurl.com) it will automatically load the page www.someurl.com/index.aspx. This is because of the setting of the “Default Document” feature of IIS. In this post we are going to discuss this feature of IIS.

1. Open IIS, type the command “inetmgr” in Run window.
   
2. Select “Default Document” and click.
   
3. In the feature view, we can see some type of Document orderly kept.
4. The top most had the highest priority and the last one had the least priority.

As per the above figure, the document “Default.htm” had the highest priority and the file “Default.aspx” had the lowest priority. This means whenever the user types a url (like www.someurl.com), then IIS looks for any one of the files that exist in the above order on that Virtual Directory. If it finds any one of the files, it will load that page.

IIS also allows, adds/removes the custom default document per Web site. For example, if we specify a page (say home.htm) as the default document which does not exist in the website, then IIS will look into that website and alert the user as shown below, which explicitly states that each time we type the url, IIS will look in that order.

As per the alert, it is advisable to move the default document at the top level, which will increase the performance in the sense IIS can avoid going further down in the list.

In this post, i will show you how to configuring ASP.NET and IIS request length for post data. One of the most infuriating things about IIS configuration in general is how the Request length is configured in IIS and ASP.NET. There are several places that control how much content you can send to the server and over the years this setting has changed in a number of ways. The places where it's configured is not super obvious and they can be fluid because some of these features are optionally installed IIS features.

So here are the two main places where the request length is set in IIS and ASP.NET:

• IIS Request Filtering

• HttpRuntime maxRequestLength

Let's start with the IIS level setting, which is also a relatively new setting. It's based around the Request Filtering module in IIS which is an optional IIS component, but that is a required component if you have ASP.NET installed on your server (at least in the latest versions). If you have ASP.NET enabled in IIS the Request Filtering module is also enabled and the following settings apply.

If you don't use ASP.NET you can still install Request Filtering, but it's an optional component. So if you only use ISAPI or CGI scripts and no ASP.NET content Request Filtering may not be enabled in which case the following settings cannot be set and aren't required. Since most people do run ASP.NET at least for some sites, for all intents and purposes we can assume that the Request Filtering module is installed on IIS.

So to configure the posted content size you can use the following web.config based configuration settings:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
     <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="500000000"  />
      </requestFiltering>
    </security> 
   </system.webServer>
</configuration>

The maxAllowedContentLength determines the size of the POST buffer allowed in bytes. Above I've set the value to 500megs.

Or you can do the same thing in the IIS Management console using Request Filtering option in the IIS options:

As is usually the case you can apply the filtering at all levels of the IIS hierarchy – Machine, Site and Virtual/Application. Using web.config as shown above sets the settings at the Application level.

Because these are IIS settings, the value controls the IIS upload settings so they are applied against any and all requests that are fired against IIS, including ASP.NET, ASP, ISAPI extensions, CGI/FASTCGI executables, IISNodeJs requests and so on.

ASP.NET traditionally has had its own httpRuntime element in the <system.web> section that control ASP.NET runtime settings one of which is the maxRequestLength. This setting controls the ASP.NET pipeline's acceptance of file uploads and it needs to be configured in addition to the Request Filtering settings described above.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web>
    <httpRuntime maxRequestLength="500000000" executionTimeout="120" />
  </system.web>
</configuration>

You can also use the IIS Management Console and the Configuration Manager option, to view all of the options on the httpRuntime element:

What's interesting is that the settings you see here widely mirror the settings in the Request Filtering section, and they are not inherited. It's your responsibility to make sure the settings are set correctly in both places. I recommend that you take a minute and go through the values you care about and set them correctly in both places.

The above describes ASP.NET settings. If you're using another framework, like WCF you may end up with yet another different set of settings on the WCF bindings and Endpoints. Just be aware of the framework you're using and that it too might have specific filters to restrict request size.

HostForLIFE.eu IIS 8 Hosting

HostForLIFE.eu revolutionized hosting with Plesk Control Panel, a Web-based interface that provides customers with 24x7 access to their server and site configuration tools. Plesk completes requests in seconds. It is included free with each hosting account. Renowned for its comprehensive functionality - beyond other hosting control panels - and ease of use, Plesk Control Panel is available only to HostForLIFE's customers. They offer a highly redundant, carrier-class architecture, designed around the needs of shared hosting customers.

You have just finished installing IIS on your Windows OS. You’re probably thinking that you can delve into the web development world and forget all about the underlying web server. After all, IIS is a Microsoft product so it should install with the right default configuration settings, right? That is far from true with IIS.

In this article, I will provide 8 tips that you can use to secure your IIS installation.

Move the Inetpub folder to a different drive

The Inetpub folder is the default location for your web content, IIS logs and so on. By default IIS 7 and upwards install the Inetpub folder in the system drive. It’s good practice to move the Inetpub folder to a different partition so that the web content is separate from the operating system. This folder can be moved after IIS installation is completed.

Install the appropriate IIS modules

IIS includes more than 30 modules  – you should only install the ones which are needed by your web applications. Disable any modules that are not required, to minimize the capacity of potential attacks. Periodically review the modules that are installed and enabled and remove any that are no longer required. You can use IIS Manager to list all the modules that are enabled.

• Open IIS Manager
• Select the name of the machine to view the modules for the whole machine, or change to the specific web site to view the modules enabled for the selected site
• Double click on ‘Modules’
• To disable a module, click on the module from the list and select ‘Remove’ from the Actions pane
• Confirm the removal by pressing Yes

Disable the OPTIONS method

The OPTIONS method provides a list of methods that are supported by the web server. Although this might seem beneficial, it also provides useful information to an attacker. This will provide information to an attacker at the reconnaissance stage of this attack. Therefore it’s recommended to disable the OPTIONS method completely. This can be done by denying the OPTIONS verb from the HTTP Verb request filtering rules in IIS.

• Open IIS Manager
• Select the name of the machine to configure this globally (or change to the specific web site for which you need to configure this)
• Double click on ‘Request Filtering’
• Change to the HTTP Verbs tab
• From the Actions pane, select ‘Deny Verb’
• Insert ‘OPTIONS’ in the Verb, and press OK to save changes

Enable Dynamic IP Restrictions

The Dynamic IP Restrictions module helps blocks access to IP addresses that exceed a specified number of requests and thus helps prevent Denial of Service (DoS) attacks. This module will inspect the IP address of each request sent to the web server and will filter these requests in order to temporarily deny IP addresses that follow a particular attack pattern. The Dynamic IP Restrictions module can be configured to block IP addresses after a number of concurrent requests or by blocking IP addresses that perform a number of requests over a period of time. Depending on your IIS version you will need to enable either the ‘IP Security’ feature or the “IP and Domain Restrictions”  as explained in this Microsoft article.

This will include the ‘IP Address and Domain Restrictions module in the IIS Manager, from where dynamic IP restrictions can be set.

• Open IIS Manager
• Select the name of the machine to configure this globally (or change to the specific web site for which you need to configure this)
• Double click on ‘IP Address and Domain Restrictions’
• From the Actions pane, select ‘Edit Dynamic Restriction Settings’
• Modify and set the dynamic IP restriction settings as needed and press OK to save changes

Enable and Configure Request Filtering Rules

It is also a good idea to restrict the types of HTTP requests that are processed by IIS. Setting up exclusions and rules can prevent potentially harmful requests from passing through to the server, since IIS can block these requests on the basis of the request filtering rules defined. For example, a rule can be set to filter traffic for SQL Injection attempts. Whilst SQL Injection vulnerabilities should be fixed at source, filtering for SQL Injection attacks is a useful mitigation. This can be set from the Rules tab found in the Request Filtering page in IIS Manager.

• Open IIS Manager
• Select the name of the machine to configure this globally (or change to the specific web site for which you need to configure this)
• Double click on ‘Request Filtering’
• Change to the Rules tab
• From the Actions pane, select ‘Add Filtering Rule’Set the required rules, and press OK to save changes

The rule set in the below screenshot would instruct IIS to check for the provided strings in requests for .asp and .aspx pages. IIS will then block the request if any of these strings are found.

You can also filter requests that contain things like high-bit characters or double escape characters. This and other similar filtering options are explained at http://technet.microsoft.com/en-us/library/hh831621.aspx

Enable logging

Configuring IIS logging will cause IIS to log various information from HTTP requests received by the server. This will come in handy and can give a better understanding of issues that might have occurred on your website when things go wrong. It’s the place where you will start the troubleshooting process in such situations.

The server’s logs can also be continuously or periodically monitored in order to review the server’s performance and provide optimizations if needed. This can be automated using various server monitoring tools. Make sure to keep a backup of the logs. Microsoft also provide Log Parser, which is a tool that can be used to query and retrieve specific data from IIS logs. Additionally, log consolidation tools prove useful for consolidating and archiving data from logs in a more meaningful way.

IIS logging can be enabled and configured from IIS Manager > select the machine name or the specific site you want to configure > Logging. Since these log files might grow quite large, it would be a good idea to start a new file periodically.

Use the Security Configuration Wizard (SCW) and the Security Compliance Manager (SCM)

Both of these Microsoft tools can be used to test your IIS security. The Security Configuration Wizard (SCW) runs different checks and provides advice and recommendations on how to boost your server’s security. The Security Compliance Manager (SCM) tool performs security tests on your server and compares server configurations to predefined templates as per industry best practices and security guide recommendations.

Updates

Finally, ensure that you keep up to date with the latest updates and security patches. It is interesting how often this basic security requirement is missed. The majority of hacks affecting the web server occur on unpatched servers. This just demonstrates how important it is to always keep your IIS web server up to date.

It sounds like it should be trivial: Create a WCF web library and host it in IIS. Surely lots of people need to do this, and it will be easy in a fairly modern version of Visual Studio like 2012? Previously I have created this article about how to host WCF Service in IIS 8, however I will explain more details in this article.

Whatever the reason, I hope this page will offer a useful step-by-step guide to set up a WCF Service Library project to be run from its development folder on Windows 8.0 or Windows 2012, IIS 8.0 – and I have been using VS 2012 and .Net Framework 4.5 as the target.  Also, before I begin, and something of a spoiler alert; you may prefer to publish your website to a specific location, and host it in IIS from there, rather than try and host it from your development folder.  This option is covered after the walk-through below.

Please Make Sure that You Have Integrated your ASP.NET with IIS

The easiest way to check this is to create a minimalistic web application (e.g. ASP.NET MVC with “No Authentication”) and try to host it in IIS (see configuration steps below). If something is missing, make sure that:

• “Internet Information Services” and “Word Wide Web Services” are enabled in the “Turn Windows Features on or off” dialog.
• If IIS is up and running, but the ASP.NET integration is missing (you can check the ISAPI filters in IIS Manager), you should run “%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –i” and hope for the best (maybe restart the machine afterwards).

Take a look at WCF Service

I assume that you have created WCF service called “WCF Service Application”. Hosting this application in IIS means that you create a virtual directory in IIS, where you link the root folder of your project to a URL. You also need to specify an app pool to be used, which should match to the .NET framework you target (e.g. “.NET v4.5”).

If you have configured your.svc files within the specified URL, you should see a page with some positive messages and links to the WSDL contracts. If you see this, then stop reading, you are done.

However, you can receive an error page, “HTTP Error 404.17 – Not Found”, “The requested content appears to be script and will not be served by the static file handler.”. This most probably means that your IIS is not configured to host WCF services (this seems to be the default).

With .NET 3.5, you had to run the “ServiceModelReg.exe” tool, but this doesn’t seem to be necessary anymore for .NET 4.0+ (“aspnet_regiis” does this already). If you look into the details of the IIS settings, you can see some references to WCF.

The only thing you have to do is to enable “HTTP Activation” in the “Turn Windows Features on or off” dialog under the “WCF Services” node. With this, you basically enable the creation of WCF service instances to serve requests coming through HTTP.

Then, please test it again and you wont see any error message anymore.

I hope this article will help you a lot.

Today post will cover about one of IIS 8 new feature. It is called Application Initialization module. Activating it allows you to enable the following capabilities:

• Starting a worker process without waiting for a request (AlwaysRunning)
• Load the application without waiting for a request (preloadEnabled)
• Show a loading page while the application is starting

To enable these features

1. Set the startMode on the application pool  to AlwaysRunning.

    <system.applicationHost>    
     <applicationPools>      
      <add name="DefaultAppPool" autoStart="true" startMode="AlwaysRunning" />    
     </applicationPools>  
    </system.applicationHost> 

2. Set preloadEnabled to true on the web application.

    <system.applicationHost>    
     <sites>      
      <site name="Default Web Site" id="1">        
       <application path="/">          
        <virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />        
       </application>        
       <application name="AppInit" applicationPool="DefaultAppPool" preloadEnabled="true">          
        <virtualDirectory path="/AppInit" physicalPath="c:\inetpub\wwwroot\appinit" />       
        </application>      
      </site>    
     </sites>  
    </system.applicationHost> 

Changing the startMode to AlwaysRunning will start the application pool and initialize your application the moment your IIS server is (re)started. So users that visit your site don’t have to wait because the worker process is already started.

By setting preloadEnabled to true, it starts loading the application within that worker process without waiting for a request.

Server Name Indication (SNI) is an extension to the TLS protocol that includes the hostname during the handshaking process. This allows for a web server to host multiple SSL-enabled web sites using one IP address. Prior to IIS 8, it was not possible to use this capability in IIS.

Configuration

SNI is enabled in IIS by default. To use this capability, simply provide the appropriate hostname in the configuration of the HTTPS binding for a site.

Each HTTPS binding that you would like to use SNI with should have the host name provided. All bindings should have the option for "Require Server Name Identification" checked except fot the site you would like to act as the "default" HTTPS site. Just as is the case with HTTP bindings, this is the site that will be used when a client does not provide a host header as part of the request. If you do not have at least one HTTPS binding with the option unchecked, IIS Manager will issue a warning informaing you of that fact.

Compatability

Before using SNI with IIS 8, you should be aware of the client requirements for this to work properly. Specifically, the TLS library used by an application must support SNI and the application must pass the hostname to the TLS library when making requests. The following web browsers support SNI:

• Internet Exmplorer 7 or later running on Windows Vista or later
• Google Chrome (6.0 or later requird if running on Windows XP, 5.0.342.1 or later if running on OS X 10.5.7 or later)
• Mozilla Firefox 2.0 or later
• Safari 3.0 or later (Vista or later and OS X 10.5.6 or later)
• MobileSafari running on iOS 4.0 or later
• Opera 8.0 or later

Hello all, sometimes I find in forum that people complain about Error 404.3 – Not Found. I decided to write the post about this issue and hope it will solve your problem.

Hmm… I assume that you have installed Windows Server 2012. When you upload your files, try to browse your site, you see this error:

One of the issues might be :

It complaints about missing handler mappings for the created web site. this is obvious when you look at it closely as follows

Go to the Desired web application listed under "Default web site" under IIS 8 and open "handler mappings"

Here most of the handler mappings are not listed. As a remedy to this click "Revert to Parent" and you will see the all handler mappings are inherited from the parent node.

This might solve the 404.3 error that you get