Redagować

Udostępnij przez

Reverse Proxy - Rule Template

by Ruslan Yakushev

Rule templates are used to provide a simple way of creating one or more rewrite rules for a certain scenario. URL Rewrite Module 2 includes several rule templates for some common usage scenarios. In addition to that URL Rewrite Module UI provides a framework for plugging in custom rule templates. This walkthrough will guide you through how to use "Reverse Proxy" rule template that is included with URL rewrite module. To learn more about configuring reverse proxy with IIS URL Rewrite Module and IIS Application Request Routing refer to Reverse Proxy with URL Rewrite v2 and Application Request Routing.

Prerequisites

This walkthrough requires the following prerequisites:

  • IIS 7 or above with ASP.NET role service enabled;
  • URL Rewrite Module 2.0 installed;
  • IIS Application Request Routing installed.

Creating the Example Web Site

For simplicity, the reverse-proxy scenario you will work with in this walkthrough will be implemented on a single server, with the IIS "Default Web Site" acting as a reverse-proxy site and content application hosted in separate IIS web sites on the same server.

To create the example content Web site:

  1. Create a folder called "contentsite" in the following folder:

    %SystemDrive%\inetpub\ folder.

  2. Create an IIS web site called "contentsite" that point to the corresponding folder under %SystemDrive%\inetpub\. Use port 8081 for the site.
    You can use the following commands to create the sites:

    %windir%\System32\inetsrv\appcmd.exe add site /name:"contentsite" /bindings:http/*:8081: /physicalPath:"%SystemDrive%\inetpub\contentsite

  3. Create a file named default.aspx in the following folder:

    %SystemDrive%\inetpub\contentsite

  4. Copy the following ASP.NET markup, paste it into the file, and save the file as default.aspx:

    <%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Reverse Proxy Test Application</title>
</head>
<body>
    <h1>Reverse Proxy Test Page</h1>
    <p>Requested URL path is <%= Request.ServerVariables["SCRIPT_NAME"] %></p>
    <p><a href="http://<%= Request.ServerVariables["HTTP_HOST"] + Request.ServerVariables["SCRIPT_NAME"] %>">Here</a> is the link to this page.</p>
</body>
</html>

  5. To make sure that the site is working correctly, open a Web browse and request the following URLs:

    http://localhost:8081/default.aspx

Generate Inbound and Outbound Rules by Using Reverse Proxy Template

The "Reverse Proxy" rule template can be used to generate inbound rewrite rule that is used to proxy the HTTP requests to another server. Optionally the template can also create an outbound rewrite rule that can fix the host names in the links URLs inside of HTML responses. In the example case described in this walkthrough the proxy server host name is localhost and the content server's host name is localhost:8081. The web application on the content server generates a link in HTML response that uses an internal host name, e.g. http://localhost:8081/default.aspx. The outbound rule fixes this link to use the proxy's host name, e.g. http://localhost/default.aspx.

To create the rules by using the rule template follow these steps:

  1. In the IIS Manager select the "Default Web Site" in the tree view on left hand side.
  2. Open the URL Rewrite feature view.
  3. In the URL Rewrite feature view, select "Add Rule(s)..." action and then select "Reverse Proxy" template:
    Screenshot of the Add Rules dialog box displaying the rule template options. Reverse Proxy is highlighted.
  4. In the "Add Reverse Proxy Rules" dialog enter the following:
    Server name or IP address where HTTP requests will be forwarded: localhost:8081
    Check the "Rewrite the domain names of the links in HTTP responses" check box and enter:
    From: localhost:8081
    To: localhost
    Screenshot of the Add Reverse Proxy Rules dialog box.
  5. Click OK. Both the inbound and outbound rules will be created:
    Screenshot of the I I S Manager displaying the U R L Rewrite page.

Testing the Reverse Proxy

To test that the rewrite rules generated by the rule template work correctly open a web browser and make a request to http://localhost/default.aspx. IIS "Default Web Site" will receive this request and will route it to http://localhost:8081/default.aspx in accordance to the inbound rewrite rule. When the HTTP response is returned from the contentsite web site, the outbound rewrite rule modifies the link URL inside of the HTML to rewrite the host name from localhost:8081 to localhost:

Screenshot of a browser window displaying a Reverse Proxy Test Page.

Using ARR Reverse Proxy for Tomcat Servlets

To add defense in depth when hosting Tomcat servlets behind an IIS + ARR reverse proxy, use URL Rewrite rules to mitigate path traversal attacks. These attacks often exploit discrepancies in how Tomcat handles path parameters within URL segments, e.g. "/..;a=b/" as described in Apache Tomcat Security Considerations.

Why this matters

Tomcat interprets semicolon-based path parameters differently than IIS, which can lead to unexpected traversal behavior. Blocking or normalizing such patterns before the ARR module handles them helps prevent exploitation.

If your goal is simply to block requests containing traversal attempts (such as "/..;a=b/"), use either wildcard or regular expression syntax.

Wildcard rule example

<rule name="BlockDotDotWildcard" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
    <match url="*/..;*/*" />
    <action type="CustomResponse" statusCode="404" statusReason="Not Found" statusDescription="" />
</rule>

RegEx rule example

<rule name="BlockDotDotRegEx" stopProcessing="true">
    <match url="\/\.\.;.*\/" />
    <action type="CustomResponse" statusCode="404" statusReason="Not Found" statusDescription="" />
</rule>

Important notes

  • Test thoroughly in your end-to-end environment. You may need additional rules for encoded or double-encoded patterns (e.g., %252F..%253Bfoo%252F).
  • Rule order matters: Ensure blocking rules run before ARR proxy-related rules.
  • Performance trade-off: RegEx offers flexibility but incurs higher overhead.

Advanced scenario: URL renormalization

If you want to strip path parameters and re-normalize the URL so all URL Rewrite rules apply to the normalized URL, you need a redirect round trip. For example: Input: /abc/..;boo/xyz/ Redirected to: /abc/../xyz/ → normalized to /xyz/ → re-evaluated by rewrite rules.

Example rule

<rule name="RenormalizeURL_SSL" stopProcessing="true">
    <match url="^([^;]*)(;[^/]*)(/.*)$" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{HTTPS}" pattern="ON" />
    </conditions>
    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}{R:3}" redirectType="Found" />
</rule>
<rule name="RenormalizeURL" stopProcessing="true">
    <match url="^([^;]*)(;[^/]*)(/.*)$" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{HTTPS}" pattern="OFF" />
    </conditions>
    <action type="Redirect" url="http://{HTTP_HOST}/{R:1}{R:3}" redirectType="Found" />
</rule>

When RegEx gets too complex

For highly complex cases, consider writing a custom URL Rewrite Provider.

Summary

In this walkthrough, you learned how to use the "Reverse Proxy" rule template to generate rewrite rules that implement a simple reverse proxy configuration in IIS. Use this rule template as a starting point to generate the base rules. You can adjust or modify these rules later to address the specific routing and rewriting requirements for your web application.

  • Last updated on