There are three initial questions most users have when evaluating LinkDeny and their anti-leeching and access control policies:

  1. What is my security policy for anti-leeching or access control?
  2. How do I configure LinkDeny to enforce my security policy?
  3. How can I tell if LinkDeny is working?

What is my security policy for anti-leeching or access control?

Is someone stealing your images? Have you identified patterns that mean a user is hacking your Web site or application? How can you control access to a particular section or the site or redirect traffic based on user data like length of session, IP address, country, HTTP header or user agent, for example?

If you are facing these types of issues, LinkDeny is the IIS security solution for you. Before you can begin to deny links, you have to formulate a security policy that LinkDeny can enforce, and you will generally need to know three things:

  1. The resource(s) you want to protect: You can guard access to your particular Web content by URL (by directory/file level) or by MIME type.


  2. The type of threat(s) you want to protect against: Defend your resources by Allowing or Denying a request based on the attacker's referring site, user agent (browser, proxy, bot, etc.), IP address (one IP, multiple IPs, or geographic areas by IP association), by requiring a specific type of HTTP request, or by the duration of the user's session.


  3. What action to take once a threat is discovered: Once denied, you can log the attack or force a Web redirection, replace the response with a new file or image, or misdirect with a cryptic HTTP 404 File Not Found error message.

If you would like more help on this topic, please review Your Security Policies and LinkDeny Rules in the documentation.


How do I configure LinkDeny to enforce my security policy?

Once you have a clear security policy in mind, you are ready to configure your LinkDeny rules on IIS.

Sometimes, you will find that more general rules for blocking countries or groups of known sites already exist in the LinkDeny templates. Make sure to check the templates (click the Template button on the Rules tab of the LinkDeny Settings Manager) to see if there is a template that matches up to one or more of the policies you want to enforce on the server.

If a template does not fit the policy you have in mind, you will need to create your own custom LinkDeny rule. To do so, just click the Add button on the Rules tab of the Settings Manager, and then fill in the fields on the Add/Edit LinkDeny Rule dialog that comes up:

The fields on this dialog represent the various components of a LinkDeny rule -- components that allow for great flexibility and layers of protection for your Web site or application. Here is an overview of each rule component and how they work together:

  • Rule Name: Your custom name for the rule. Be descriptive for easier management in the future.
  • Rule Selector: This is a reference to the file(s) you want to protect, in the form of their URL path or MIME type (wildcards and Regular Expressions can be used as well as exact matches, for maximum control over what to protect with a particular rule).
  • Rule Type: Is this an ALLOW BY rule (meaning that when a test finds a match the request "passes" the test) or a DENY BY rule (meaning that when a test finds a match the request "fails" that test)?
  • Tests: These tests govern how you will identify incoming attacks to act on. You can set up single or multiple tests within one rule based upon the attacker's referring site, user agent, IP address (or geographic region), by requiring a specific type of HTTP request, or by the duration of the user's session.
  • Action Taken on Denial: This is what LinkDeny will do with requests that fail to pass the tests you have created, with LinkDeny responses in HTTP ranging from logging to redirection, file remapping, or a terse HTTP 404 error to misdirect and deny access to the attacker.

Using the Add/Edit LinkDeny Rule dialog, Create rules that cover all conditions that you describe in your security policy, making sure to Apply your changes in the Setting Manager as you create them. These new rules will now be loaded in the main Rules tab of the Settings Manager. If you would like more help on this topic, please review The Grammar of a LinkDeny Rule and Using the Settings Manager in the documentation.


How can I tell if LinkDeny is working?

After you have crafted a security policy and have set up the LinkDeny rules, you will need to test those rules to make sure that they have the intended effect on your Web site and to make sure that you are not unintentionally blocking legitimate visitors to your Web site or application with LinkDeny. To do this, we recommend using LinkDeny's built-in rule testing functionality, in conjunction with a free HTTP request tool such as Microsoft's Wfetch or the Mozilla/Firefox extensions refspoof and TamperData.

Testing LinkDeny Rules with Built-in Testing Functionality

Every rule can tested from within LinkDeny as it is created. When creating or editing a rule in the Add/Edit LinkDeny Rule dialog, double click on any test in the Rule Type and Tests section (or highlight the test a click Edit Details). This brings up the Test Details dialog, on the bottom of which you will notice a button labeled Test >>. Click this button to expand the dialog, exposing a section called Test for Match. Here you can enter a value related to the type of test you are checking (a URL for a referer test, an IP for Custom IP or Geographic IP test, etc.) to see if LinkDeny would find a match for that value in the test you are checking. Here is an example of the Referer Test Details dialog, expanded for local testing:

Once you have created a number of different rules, you can also use the main Testing tab to build a complete HTTP request and see whether LinkDeny would deny that request and, if so, which of your rules would have triggered the denial:

Testing LinkDeny Rules with a HTTP request tool

Even though LinkDeny has its own testing facilities built in, it is always a good idea to independently verify that any Web server component is working as advertised, and the best way to do that is by using a third-party HTTP request tool. Microsoft's complimentary Wfetch utility is an easy-to-use, stand-alone tool, but any tool that allows you to manipulate the HTTP headers sent in a Web request (and to see the HTTP details of the response from the Web server) will work perfectly. For the example below, we use Wfetch.

For this example, we have set up a test site in IIS, accessed at the URL http://localhost. In LinkDeny, we have set up a simple rule and called it "Referer Test for Localhost Site". Because it uses the MIME wildcard Selector "image/*", this rule is going to examine requests to all of our images on the Web site. Our Allow-By Rule contains just one Test -- a Referer Test that tries to match the HTTP Referer header in the request against the wildcard expression *localhost* to determine if the request originated from a page on this site, and is therefore legitimate. Since this is an Allow-By rule, if the request fails to match this test, LinkDeny is going to take the specified Action of sending a 404 response. Here is a screenshot of this rule mocked up in LinkDeny:

Still with us? If not, take a look at the five bolded items in the previous paragraph, and then try relating them back to the five components of a LinkDeny rule, as discussed in the previous section. Still lost? If so, please try taking a deeper look by following the links to the product documentation provided at the end of that section. You can also contact Port80 Software Support for some free help on getting started with LinkDeny.

Now, we are going to make a test request to the Web site. This will be an example of what a request might look like if it originated from a crude page-scraping script that was leeching images from another server. When legitimate users are browsing a site, their browsers will place in the Referer header the URL of the page they are on, when requesting the supporting files for that page, such as an image (in this example, a legitimate user's request would contain a Referer header with the value http://localhost).

Below, we instead use Wfetch to send a request for an image, http://localhost/tester/images/S_logo.gif, where that request contains a very minimal set of headers and, in particular, no Referer header at all. Since our LinkDeny rule is only allowing requests to files of image/* MIME type when those requests have "localhost" in the Referer header, it blocks this request with a 404 message, as expected:

Now, we will request the image again, this time adding a proper Referer header, the way a browser would when loading the image from an image tag in a page. However, the value in our Referer header is going to be "foo.com" -- which is what would happen if some page at foo.com were linking to ("leeching") an image from the localhost site. Adding the Referer header is easy in Wfetch, using the "Advanced Request: Add Headers" option in the upper-right corner of the screen -- just be sure to add "\r\n" at the end of the header line, to tell Wfetch to send the newline (CR/LF) sequence that marks the end of every header. Again, we get LinkDeny to block the request with a 404 response, as expected:

Finally, we use Wfetch to create a request similar to what a browser would send when, on behalf of a legitimate user, it requests a supporting image file from an image reference found on a page on your site -- in this case a request containing "localhost" in the Referer header.

Since Wfetch is showing us the HTTP-layer details it did not load the actual image (which was a logo for a site), but as you can see it did receive the binary data for the image it was sent, based on the URL http://localhost/tester/images/S_logo.gif, meaning that this request, unlike the two previous ones, "passed" our LinkDeny Allow-By rule.

To summarize, two illegitimate requests (one from a page-scraper script and one from another site trying to leech our image) were denied by our rule. Meanwhile, the one legitimate request, made by an actual user of our site, was allowed to retrieve the image, just as it normally would have. Bad Guys 0 for 2, Good Guys 1 for 1. Success!

This is but one small example of the myriad ways in which LinkDeny can be used for IIS ant-leeching and access control. Please let us know where Port80 Software can help with your specific security policies and LinkDeny!