Tag Archives: IIS

Server-side workaround for BEAST SSL vulnerability on IIS

Posted on by

Recently, a vulnerability in the CBC cipher suite used in the SSL and TLS protocols was discovered that could allow an attacker to gain access to encrypted information. While the attack is not easily implemented, it will show up on compliance audits and auditors don’t like that. Fortunately, there is a server-side fix for Server 2008 and above that can be easily implemented without breaking compatibility with clients.

More information about the attack and workarounds can be found here: http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx.

The workaround is to enable TLS 1.1 and/or 1.2 on servers that support it, and prioritize cipher suites so RC4 takes precedence over CBC. Server 2008 R2 and above supports TLS 1.1 and 1.2 – you can enable those protocols by following the instructions in KB 2588513. You’ll also want to change the priority of cipher suites on all Server 2008 and above systems using group policy (either a local group policy object for a single server, or by modifying domain policy in an AD environment).

1. Open Group Policy Editor (locally, Start>Run>gpedit.msc).
2. Browse to Computer Configuration>Administrative Templates>Network>SSL Configuration Settings.
3. Modify SSL Cipher Suite Order: set it as enabled, and enter a comma delimited list of cipher suites. I recommend the following:

TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,SSL_CK_DES_64_CBC_WITH_MD5

4. Reboot the server for the setting to take effect.

Maintain protocol in URL Rewrite Rules

Posted on by

The URL Rewrite 2.0 module for IIS7+ is a very powerful tool for manipulating requests to an IIS server. We use it quite heavily with Application Request Routing load balancers in our environment. The combination allows us to perform L7 load balancing of requests. One of the great features of ARR is the ability to perform SSL offloading, which effectively terminates the SSL connection at the ARR node. Accomplishing this is quite simple – you create your rule and use HTTP:// as the scheme to route to the appropriate server farm. However, there are times when you will want to pass through the protocol to the backend servers.

There are a few ways to accomplish this. First, you could create two rules with a condition tracking the HTTPS server variable and route appropriately. However, this doubles the number of rules to maintain. Second, you could use a condition on the CACHE_URL variable and a back reference in the rewritten URL. The problem there is that you then need to match all of the conditions which could be a problem if your rule depends on a logical “or” match for conditions. Lastly, my preference involves using a rewrite map on the HTTPS server variable.

The idea is that we create a rewrite map named MapProtocol that contains two key value pairs – ON = https and OFF = http (I also prefer to set the default value for the rewrite map to http in the off chance the HTTPS variable does not contain a value). Then, we use that rewrite map in the Action url against the HTTPS server variable. The rule will look something like this:

<rule name="ARR Maintain protcol" enabled="true" stopProcessing="true">
  <match url=".*" />
    <conditions>
      <add input="{LOCAL_ADDR}" pattern="10\.1\.1\.10" />
    </conditions>
  <action type="Rewrite" url="{MapProtocol:{HTTPS}}://Webfarm1/{R:0}" />
</rule>
 
<rewriteMap name="MapProtocol" defaultValue="http">
  <add key="ON" value="https" />
  <add key="OFF" value="http" />
</rewriteMap>

Using IIS Debug Diagnostics to troubleshoot Worker Process CPU usage in II6

Posted on by

Failed request tracing in IIS7 can help track down many performance issues with websites, but we still have a broad customer base on IIS6. Troubleshooting performance issues in IIS6 has been quite difficult until Microsoft released a set of tools that gave greater insight into analyzing a stack trace.

The IIS Debug Diagnostics Tool can help track down CPU and memory issues from a worker process. Microsoft has a nice kb article that goes over the basics as well: http://support.microsoft.com/kb/919791.

1. Install the IIS Debug Diagnostics locally on the system.

2. Open the Debug Diagnostics Tool under Start > Programs > IIS Diagnostics > Debug Diagnostics Tool > Debug Diagnostics Tool.

3. Click Tools > Options And Settings > Performance Log tab. Select the Enable Performance Counter Data Logging option. Click OK.

4. Use task manager to find the PID of the worker process.

5. Select the Processes tab and find the process in the list.

6. Right-click on the process and select Create Full Userdump. This will take a few minutes and a box will pop-up giving you the path to the dump file.

7. Select the Advanced Analysis tab and click the Add Data Files button. Browse to the dump file that was jump created and click OK.

8. Select Crash/Hang Analyzers from the Available Analysis Scripts box for CPU Performance and crash analysis. Click Start Analysis.

After a few minutes, a report should be generated containing stack trace information as well as information about any requests executing for longer than 90 seconds. Note that the memory dump with use a few hundred megabytes of space, so be sure to install the tool on a drive with sufficient debugging space. Also, if the box is under heavy load, you can create the user dump on the system, copy the file to your workstation, and perform the analysis locally.

IIS6: 404 Error serving content with .com in URL

Posted on by

We ran into an issue today where a customer was having problems serving content from a folder named “example.com”. IIS6 was simply returning a 404 error. I immediately suspected something like URLScan but I eventually found it was due to the execute permissions configured on the parent virtual directory. When the customer configured the virtual directory, they set the execute permissions to “Scripts and executables”. This means that IIS will try to run any cgi compliant executables (.com and .exe files by default) in the virtual directory. In order to run the application, the executable also needs to be authorized in Web Service Extensions.

However, in this case, the URL simply contained “example.com” in the URL: http://server/example.com/images/image1.jpg and we were not trying to run an application. IIS was seeing the “example.com” in the URL and assuming it was a cgi executable and attempting to run the application. However, the file “example.com” did not exist and was therefore returning a 404 error. To correct the issue, we simply set the execute permissions to “None” since the customer was attempting to serve static content, though you can also use “Scripts only”.

The key to this is that there does not need to be a specifc mapping for executables. IIS 6 will attempt to run any executable if the vdir is configured with “Scripts and executables” permissions.