 |  | | |
| ||||||
 |  |  |  | | ||||||
 | ||||||||||
 |  | choose a product: | | |
 | | LinkDeny Docs LinkDeny allows you to granularly control access to your Web site content and to protect your site from hotlinking, leeching or bandwidth theft of valued Web site content.
| | 
| | |
| |  Installation Installing LinkDeny is very simple. Once you have downloaded the installer executable from the Port80 Web site, double click on the file to begin the LinkDeny setup program. The LinkDeny setup program will guide you through the steps necessary to complete the installation. You will be asked to accept the license agreement and to choose an installation destination. The default installation location is C:\Program Files\Port80\LinkDeny. Files Installed by LinkDeny LinkDeny installs the following files in the following default locations: In C:\%SystemRoot%\System32\inetsrv\
Your Security Policies and LinkDeny Rules LinkDeny is rules-based security software for protecting online resources. To use the software, employ the LinkDeny Settings Manager to create LinkDeny rules that reflect your desired security policies. Thus, before jumping in and starting to create LinkDeny rules, it is a good idea to pause and think about what security policies you want LinkDeny to enforce. To create a good security policy, you generally need to know three things:
A good way to come up with a list of the security policies you want LinkDeny to enforce would therefore be to create a simple document with three columns, one for each logical part of a given policy. After going through such an exercise, for instance, you might have come up with the following two policies:
Your own list of security policies will probably be longer than this, but it should have a similar form, so that you can be clear about what you are trying to accomplish. Of course, it helps in building such a list to have an idea of the kinds of things LinkDeny can do. We will cover that in a preliminary way here, then in more detail in the next section:
Before you get started creating and enabling LinkDeny rules on your server, however, you will want to have a clear understanding of how a LinkDeny rule is put together. This will help you translate your desired security policies into the appropriate LinkDeny rules in the easiest and most efficient way. The Grammar of a LinkDeny Rule A single LinkDeny rule is a powerful security tool. It is also a logical unit, composed of the following parts:
Rule-Name This is just a friendly name for the rule. It can be anything, but you should always try to use something descriptive of what the rule is trying to do, to make it easy to manage your LinkDeny rules in the future. In test cases and templates, we tried to name our LinkDeny rules to match the desired intent of security policy for a specific LinkDeny rule. Selector This is the part of a LinkDeny rule that answers the question, "What resource(s) should this LinkDeny rule protect?" If the requested resource matches the Selector, the rule will be evaluated for that resource, otherwise not. This is what allows you to have different rules (and thus different policies) for different resources. LinkDeny Selectors are made up of three parts: A Selector-Type, a Match-Type and a Match-String. The Selector-Type lets you choose whether to compare the Selector against the request's URL path or its MIME type (To find out how to view all the MIME types registered in IIS, click here). The Match-Type gives you three options for how to do the comparison between the Selector and the request (you can choose an exact match, a wildcard match, or a Regular Expression match). And the Match-String is the actual string of characters that is compared against the request. As you can see, the complete Selector gives you a great deal of flexibility in deciding the rule's scope -- how widely or narrowly a given rule will apply. For example, imagine six LinkDeny rules with the following six Selector match-strings:
/images/* would apply to all files in the directory called "images" located in the site's root directory (and all files in sub-directories of /images), while the exact match URL path Selector match-string /images/foo.jpg would apply only to the file "foo.jpg" in that same directory. If you wanted the rule to apply only to files in the /images/ directory and not any files in sub-directories of /images/, you would need to use a Regular Expression Selector match-string, such as /images/[^\/]*. This specifies only URL paths with no further slashes after "/images/", meaning only files. In the same vein, the wildcard MIME Selector match-string image/* would apply to all image content in the site, while the exact match MIME Selector match-string image/png would only apply to images of PNG type. However, if you wanted to protect only PNG and GIF files, but not other image content, you could use the Regular Expression Selector match-string image/(png|gif). Putting all of these example Selectors together, suppose we had a request for a jpeg image called bar.jpg, living in the root directory of the site. Which of our Selectors (hence which of our rules) would apply to this request?:
Rule-Type Once we know (thanks to the Selector) that a requested resource should be protected by this rule, the next question a LinkDeny rule has to answer is, "What specific threats should this LinkDeny rule protect this particular resource against?" The first part of the answer comes from the Rule-Type. The Rule-Type has a specific question of its own to answer: "How will these threats be identified -- directly, or indirectly?" A LinkDeny rule can be one of two types: A Deny Rule or an Allow Rule. A Deny Rule directly identifies specific threats so that they can be handled by LinkDeny. An Allow Rule, on the other hand, identifies legitimate requests for a resource. This means that it identifies threats not directly but indirectly, by a process of elimination. It is important to keep in mind that the Tests that make up the heart of a LinkDeny rule (each rule contains one or more tests -- see below) will have different purposes, depending on the Rule-Type. This can be a little tricky to understand, so it's worth going over in some detail: When you choose a Deny Rule-Type, that rule's tests are used to single out requests that need to be acted on by LinkDeny. Think of medical tests that screen for a variety of diseases. In this case, since the tests are looking for something bad, a request can only "pass" if there is no match between the request and any of that rule's tests. The requests that "fail" -- that need to be acted on by LinkDeny -- are those that matched at least one of the rule's tests. When an Allow Rule-Type is chosen, on the other hand, the tests are used to pick out requests that can safely be permitted access without any action by LinkDeny. Think of a qualifying exam. In this case, since the rule is looking for a minimal set of desirable characteristics, a request can only "pass" if there is a match between it and all of the rule's tests. Here, the requests that "fail" -- that need to be acted on by LinkDeny -- are those that failed to match at least one test. Notice that both types of rule err on the side of security -- of stopping threats. Thus, for both Rule-Types, if there are multiple tests in a rule, a request has to "pass" them all to get through. The two Rule-Types just implement this pro-security bias in different (converse) ways. The difference lies in the meaning of a "match" between a test and a request: An Allow Rule-Type treats a match as a "pass," while a Deny Rule-Type treats a match as a "fail." Tests The second part of the answer to the question of what threats a LinkDeny rule should protect against is provided by one or more tests applied to all requests for a protected resource (a resource that matches the rule's Selector). These tests are the heart of a LinkDeny rule because they are how LinkDeny identifies certain requests as threats to the resources it is supposed to protect -- threats it must intercept and act upon. There are five kinds of tests to choose from, and we will look at each one in detail in a moment: Referer, User-Agent, IP Address, HTTP Request Conformance and Time Limit. A LinkDeny rule can use just one single test, or a combination of several. Keep in mind that the Rule-Type will affect how test results (matches or non-matches) are interpreted, and how multiple tests are treated: A Deny Rule will identify a request as a threat if it matches any of the tests that make up the rule; an Allow Rule will identify a request as a threat if it fails to match any of the tests that make up the rule. Referer Test The referer test allows you to test for the presence of a specific URL or set of URLs in a request's HTTP Referer header. Since requests for the objects that are required by a page (e.g., images, JavaScript, CSS) will have that page's URL in the Referer header, the Referer test provides a convenient way to differentiate between requests local to the site and attempts to "leech" (make unauthorized use of) such objects from outside the site. A simple test, for example, might be to allow requests for your images only when the Referer URL starts with your own site's domain name -- thereby denying all requests for your images made from other sites that try linking directly to them. To implement this, you might use an Allow By type rule with a Referer test that checks the HTTP Referer header against a wildcard expression such as http://www.mysite.com/* (exact matches and Regular Expression matches are also available). The Referer test can also be a useful way to limit the "entry points" to your site, by allowing only a limited number of pages to be requested from other domains. Finally, using a Deny By Rule-Type, you could exclude certain referers that are known or suspected by you to be linking to your content in an unauthorized or illegitimate way.User-Agent Test The User-Agent test is similar to the Referer test in that it tests a request by looking at the value of a particular HTTP header. In this test, however, the header is User-Agent, and it customarily contains the user agent string that identifies the browser, proxy server, or other software that is making the request. User-Agent tests can be used to restrict certain content to certain browsers and even to direct certain browsers or bots to specialized content (a well-known Web development task called "browser detection"). As with the Referer test, the match can be exact, wildcard based or Regular Expression based. A simple example would be the wildcard expression *MSIE 7.* which would single out Internet Explorer version 7.0 (along with any subsequent minor version upgrades). A good list of user agent strings is available at http://en.wikipedia.org/wiki/User_agent.IP Address Tests There are really two types of IP Address test: Custom IP and Geographic IP. With the Custom IP version of the test, you can allow or deny any IP address or range of IP addresses. Obviously, this can be a very handy way to reinforce the security of an extranet application, among other uses. The Geographic IP version of the IP Address test lets you test not against hard-coded IPs, but rather all the IPs that are associated with a given country or group of countries. This feature of LinkDeny is preconfigured with numerous useful country and regional groups (e.g., Top Countries with High Risk for Phishing Attacks). Here again, these tests can used both to restrict access to certain users and also to direct specific users to specialized content.HTTP Request Conformance Test This test is primarily useful for the control of unfriendly bots, crawlers and scripts. It does this by allowing you to build a sort of profile of the types of requests you want to allow (if using an Allow Rule-Type) or deny (if using a Deny Rule-Type). This profile can be based on the values contained in the HTTP request line (i.e., the HTTP Method and/or the HTTP Version) and/or the presence of specific HTTP headers. For instance, you might use an Allow rule that requires the request to be either a GET, HEAD or POST, to use HTTP 1.1 exclusively, and to contain (non-empty) Accept, Accept-Encoding, Accept-Language, Connection, Host and User-Agent headers (or any custom HTTP header names associated with your particular Web application).Time Limit Test This test is designed to provide an additional layer of security when seeking to prevent things like leeching or unauthorized cross-linking. Referer and other headers and even client IPs can be spoofed, thereby disguising illegitimate requests as legitimate ones. To combat this, LinkDeny also allows you to protect resources by requiring them to be requested with a temporary, user-unique access key. Because the access key is time limited, it cannot be hijacked and later reused in unauthorized ways. Effectively, this forces legitimate users to establish a LinkDeny session in order to access the protected resources. This session requirement can only be fulfilled by receiving one of the user-unique, time-limited access keys from LinkDeny and then passing that same key back when requesting additional resources. When you set up a Time Limit test, you have the option of requiring that the temporary, user-unique access key be transmitted in a session cookie, or in the URL paths, or (for extra security) in both. There are a number of special considerations to keep in mind when using the Time Limit test:
Action The final part of a LinkDeny rule is the Action. When the Selector has identified a resource to protect, and when the Tests have identified a particular request as a threat to that resource, then the Action comes into play to answer the final question, "What should be done about this particular threat?" When a request for a protected resource has been identified as a threat to that resource, LinkDeny will execute one of the following four actions for that request: Log Only Threats to protected resources are logged, but no other action is taken against them. This mode is very useful when testing for vulnerabilities and/or testing the impact of new rules. By setting up a rule and monitoring the events logged by that rule, you can confirm (or disconfirm) the presence of suspected threats (e.g., are my images being leeched?) and avoid misidentifying legitimate requests as threats and thereby blocking desirable traffic (by weeding out false positives). Redirect to URL This option is useful when you want to send users who fall outside of the intended audience for a given resource to some alternative resource, or to a context-specific message informing them why they are not permitted to access the originally-requested resource. A note of caution: When using this option, take care not to create infinite loops by redirecting requests to an alternative resource that is protected by the same rule. This is normally an easy error to avoid, but it can crop up in unexpected ways, as when a request is bounced between several protected resources, covered by several different rules, only to wind up being redirected back to resources protected by the original rule. The safest policy is always to redirect to a resource that is not itself covered by any rules (i.e., to which no Selector applies). And of course you should always test your complete rule set fully before deploying it to production, or updating it once in production. Replace with File This action affords the option of replacing a protected resource with an alternative one, but without redirecting the user. Instead of a redirect (which depends on a browser or other user agent to fetch the target file -- and will mean performance penalty on the browser side to request the redirected URL), the Replace with File option simply transparently serves the target file in place of the requested one. This is especially useful for example if you want to serve alternative images in place of protected ones to preserve a page layout while denying access to some of its content -- or when you are concerned with the speed of the replacement (itself a "redirection") on the browser side. You can also use this option to deliver a customized error page in place of a protected one, without changing the URL the user sees in the browser. Send 404 Error Sometimes the most desirable action is to block a request in the most efficient manner possible, while disclosing the least information possible to whomever or whatever made that request. This is often the wisest policy for the most serious security threats, for example, because it prevents someone probing your defenses from learning anything useful about them. The Send 404 Error action accomplishes this by sending a terse, uninformative 404 error message in place of the protected resource. This message is designed to disclose the least information possible about the protected resource, and any related resources (especially to scripts and bots), and to do so at the lowest cost in bandwidth and server resources (itself a useful counter-measure to error-generating Denial of Service attacks). Think of it as your bare-bones, maximum-security choice among the Action options. Combining Two or More Rules To implement a complete set of security policies, you will probably need to use several LinkDeny rules in conjunction, including potentially some rules whose Selectors overlap (meaning that two or more rules could apply to the same request). This raises the question of how LinkDeny handles the evaluation of multiple rules. When using multiple LinkDeny rules in conjunction, there are two main things to keep in mind:
Using the Settings Manager The Settings Manager can be launched from the Port80/LinkDeny program group in the Start menu, or directly by running LinkDeny.exe. The Settings Manager controls the operation of LinkDeny for any Web site (virtual server) provisioned on the computer. On the left side of the Settings Manager is a list of all the Web sites (virtual servers) that are available on the computer. Use this list to select the Web site whose settings you want to change. 
Configuration Options The LinkDeny Settings Manager consists of a Web Sites list to select which sites to configure and a series of tabs where the configuration controls are located for various areas of LinkDeny functionality. These tabs are where LinkDeny is configured for each Web site. Changes made on a tab apply only to the highlighted Web sites. After making any changes on these tabs, you must press either the "Apply" or the "OK" button on the Settings Manager in order for the changes to take effect. The functional areas represented by the various tabs include: 1. Rules Tab  The Rules Tab displays the LinkDeny rules for the selected site(s). When creating LinkDeny rules, you can start to create a new rule by clicking on the "Add..." button, or you may add a rule from a template by clicking on the "Template..." button. To edit an existing rule, select the rule you would like to edit and click on the "Edit..." button. If you select multiple rules and click on the "Edit..." button, you will be prompted to edit each rule in succession. To remove a rule from the list, select the rule and click on the "Remove" button. The order of the rules is important if there is any overlap of protected content between two or more rules with different actions taken, and more specific rules that overlap should be ordered above less specific/general rules on the Rules tab to avoid one rule negating the effect of another. You can change the order of the rules by selecting a rule and using the arrow buttons to move the rule up and down in the list. Add/Edit Rule Dialog 2. Time Limiting TabWhen you add or edit a rule, the following dialog appears:  Rule Name The Rule Name is a way to easily describe or name the rule so that the user can easily identify the particular rule from the main rule list on the Rules tab. Rule Selector The Rule Selector section allows the administrator to select the content in the Web site that they would like to protect. The first drop down is the Selector-Type, the second drop down is the Match-Type, and the third drop down is the Match-String. Rule Type and Tests Selector-Type The Selector-Type has two values: "By Path" or "By Mime". When "By Path" is selected, the Match-String is a URL path that describes the content this rule is protecting (e.g. /images/*). When the Selector-Type is "By Mime", the Match-String is a MIME type that describes the content this rule is protecting (e.g. images/*, text/css, or application/x-javascript -- for more information on MIME types, click here). Match Type The Match-Type describes what method LinkDeny will use to match the Match-String with incoming HTTP requests. When "Use Exact Match" is selected, the HTTP request must match exactly (ignoring case) the Match-String. For example, if the Match-String is going to be /images/logo.gif, then this rule will only be active for requests for logo.gif in the images directory off of the root of the site. When "Use Wildcard Match" is selected, the Match-String can contain two wildcard characters: * matches any 0 or more characters, and ? matches any one character. For example, if the Selector-Type was "By Mime" and the Match-Type was "Use Wildcard Match" and the Match-String was image/*, the rule would be active for GIF images (image/gif), JPG images (image/jpeg), PNG images (images/png), etc. When "Use Regular Expression Match" is selected, the Match-String is treated as a Regular Expression (for more information on regular expressions, click here). The Rule Type (sometimes referred to as "Rule-Type") has two possible values: Action Taken on Denial
There are 6 types of "tests" or criteria to help describe whether a HTTP request is allowed or denied:
Referer Test The Referer Test allows the administrator to maintain a list of allowed/denied Referer: HTTP header values. You can test a particular referer by entering it in the test text box, available on the Add/Edit dialog. It will test the entered value against the current list of Referer values above. User Agent Test The User Agent Test allows the administrator to maintain a list of allowed/denied User-Agent: HTTP header values. You can test a particular User Agent by entering it in the test text box. It will test the entered value against the current list of User Agent values above (for more information on user agent strings, click here). Custom IP Test The Custom IP Test allows the administrator to maintain a list of allowed/denied IP Addresses or IP Address ranges. You can test a particular IP Address by entering it in the test box. It will test the entered IP Address against the current list of Custom IP Test values above.  Geographic IP Test The Geographic IP Test allows the administrator to maintain a list of allowed/denied countries or groups of countries and their associated IP addresses. You can add specific countries by clicking on the "Add..." button or you can add pre-defined groups by clicking on the "Add Group..." button. You can test a particular geographic location's IP address by entering it in the test box. It will test the entered value against the current list of geographic locations and their related IP addresses above.  HTTP Request Conformance Test The HTTP Request Conformance Test allows the administrator to allow or deny requests based on the content of an HTTP request. When selecting "Request must contain all of the values below", HTTP requests must satisfy all of the request parts specified in the list for the HTTP Request Conformance to have a match. When selecting "Request only needs to contain one of the values below", HTTP requests match the HTTP Request Conformance tests when the first request part is found. When adding a HTTP header to the list, there is an additional option to allow empty header values. When specifying request verbs, use a comma delimited list (e.g. GET,HEAD,POST). When specifying an HTTP version, the administrator can use wildcard values (e.g. HTTP/1.*). You can test an HTTP request by entering it in the test box. It will test the entered request against the current list of request parts above.  Time Limit Test The Time Limit Test allows the administrator to put time limited access keys on the selected content. There are two types of time limiting options available in LinkDeny: Cookie Time Limits and URL Time Limits. When the Cookie Time Limit is enabled, LinkDeny will set a cookie on outbound HTTP responses for text/html, text/css, and application/x-javascript content. When the client subsequently sends HTTP requests the supporting objects, they will include the encrypted Access Key. When the URL Time Limit is enabled, the administrator or site developer needs to modify source code URLs to include the LinkDeny-configured URL Flag, followed by the 20 character LinkDeny-configured URL Mask, and then the URL path for the file (see Time Limiting Tab). For example, with a URL Flag with the value of "protected" and a URL Mask with the value of "P80-LINKDENY-URLMASK", any links to: http://mysite.com/myimages/logo.jpgshould be changed in your source code to: http://mysite.com/protected/P80-LINKDENY-URLMASK/myimages/logo.jpgLinkDeny will then modify URLs that contain the URL Flag (in this case "/protected") during outbound HTTP responses and update them with the appropriate Access Key. So, in your source code: <img src="/protected/P80-LINKDENY-URLMASK/myimages/logo.jpg">would be modified such that the client would then see something like this: <img src="/protected/C1EBAA32DF321808A923/myimages/logo.jpg">This URL would then be valid for the time specified in the Time Limiting Tab. After the Access Key expires, the URL will no longer access the resource, and any requests will be denied.  Action Taken on Denial defines what LinkDeny does for requests that match the current rule. There are 4 options:
The Time Limiting Tab allows the administrator to control the advanced settings for Time Limit feature of LinkDeny.  Cookie Name 3. Logging Tab (and Log Files)This is the name of the cookie that LinkDeny uses when Cookie Time Limiting is enabled. URL Flag This is what tells LinkDeny which URLs in outbound HTTP responses should be modified to include the encrypted Access Key. URL Mask This is the 20 character mask that is a place holder in the site content/source code's URLs to be protected for the encrypted Access Key. Access Key Time Limit This is the amount of time for which Access Keys are valid, whether the Access Key is included in a cookie or in a URL. Private Key The Private Key is used to compute the encrypted Access Key. In a server farm environment with mirrored content, all machines must have the same Private Key in order for the Access Keys to work on all of the servers. The Logging Tab allows you to enable/disable LinkDeny-specific request logging for the selected sites. When logging is enabled, LinkDeny will log information about denied requests in a log file in the specified logging directory for a particular site/virtual server.  With LinkDeny logging enabled for a site, you will be able to retrieve log files for later analysis. As you can see from the screenshot above, you have control over where each log file for each site is stored. To review a log file for a site, open the appropriate directory and view the log files, .txt documents, within Notepad or another editor. The log file for a site is organized in tabs for each request made to the site. The codes for both LinkDeny Errors and Actions Taken that are logged will be displayed in a set of tabs as well -- please use the tables below to identify LinkDeny Errors and Actions Taken in a log file:
A future version of LinkDeny will provide a standalone Log Viewer GUI interface. 4. Test Tab The Test Tab allows you to enter requests and test them against the current set of rules. When the request you have entered matches a rule, the rule name will be displayed at the bottom of the tab. If the request matches a rule, but does not match the criteria for that rule, the request status is "Allowed". If the request matches a rule and is denied, the request status will say "Denied" and the reason (e.g. which criteria) will be displayed.  Configuration and Data Files Rules.ld Files for Scripted LinkDeny Rule Management LinkDeny allows admins and developers to script their own LinkDeny rules by relying on XML management files named rules.ld. An example of this file is located by default in C:\Program Files\Port80\LinkDeny\data, and each Web site/virtual server with LinkDeny enabled will also have a site-specific rules.ld file located in its Web site root directory. Changes made in the Settings Manager for rules will be stored here for each site, and any changes made to this file for a particular site will be reflected in the Settings Manager UI once saved. You can edit each XML file with Notepad, another editor, or with an XML parser to make programmatic changes to LinkDeny rules by site, then upload the revised XML files to the Web root for the particular site to apply changed settings to LinkDeny. As with all setting changes, it is recommended that you test new rules settings in a testing environment before deployment in production Web servers. For security purposes, direct HTTP requests to the rules.ld file (http://[hostname]/rules.ld) will result in an automatic 404 response from LinkDeny to avoid public exposure of your LinkDeny rules settings. Templates.ld File for Scripted LinkDeny Templates Management LinkDeny allows admins and developers to script their own LinkDeny templates by relying on a single XML management file named templates.ld, located by default in C:\Program Files\Port80\LinkDeny\data. Within the Settings Manager's Rules tab, you can apply templates to a site or group sites, but you cannot add or delete new template entries from within the Settings Manager. To add or remove templates that will be available as options to every site/virtual server, you can edit the templates.ld file with Notepad, another editor, or with an XML parser. Save the revised templates.ld file to the same directory (by default C:\Program Files\Port80\LinkDeny\data) to apply changed templates settings to LinkDeny sites. As with all setting changes, it is recommended that you test new template settings in a testing environment before deployment in production Web servers. GeoIP.dat File for IP Address and Geographic Data (For Included "GeoLite Country" Database) LinkDeny provides an easy-to-update process for managing the data used for Custom IP Address and Geographic IP Address rule tests. We rely on the "GeoLite Country" database from Port80 Software partner MaxMind for the IP address and geographic/regional mapping data used in LinkDeny -- the data used for IP address identification is 97% accurate and will be updated every few months (see next section for details). The data is persisted within LinkDeny in a file named GeoIP.dat, located by default in C:\Program Files\Port80\LinkDeny\data. You will not be able to review the IP address and geographic region data within this file directly, but this file is required so that LinkDeny can create IP address associations for anti-leeching and access control rules. Updates to the GeoIP.dat File (For Included "GeoLite Country" Database) Port80 Software will provide periodic complimentary updates of the "GeoLite Country" data file, GeoIP.dat, with updated IP address information free of charge. You will receive e-mail alerts when a new GeoIP.dat file is ready for download, usually about every two months. To download the file, please log in to the My Port80 Web site and check for updates on the Software page (look for the main LinkDeny GeoIP.dat Updates section of the page). To load a new GeoIP.dat file, simply download the new file from the site and then replace the current one in the correct directory on the server (C:\Program Files\Port80\LinkDeny\data by default). Upgrading to the "GeoIP Country" Database While not required to use LinkDeny by default, there is an optional upgrade to the included, 97% accurate "GeoLite Country" IP address database that LinkDeny relies on for Custom IP Address and Geographic IP Address rule tests. Port80 Software partner MaxMind also offers the "GeoIP Country" database -- with this paid upgrade, the data used for IP address identification is 99% accurate, and updates are available every week. The "GeoIP Country" database is currently priced at $50 for a site license only (per MaxMind, all machines within organization) with an optional monthly $12 fee for the weekly, downloadable data updates. To purchase the "GeoIP Country" database upgrade, please visit Port80 Software partner MaxMind's site. When ordering the "GeoIP Country" database upgrade for LinkDeny from MaxMind's site, make sure to select either the "Downloadable Database" Site License (for a one-time upgrade) or the Site License with Updates product offerings on the "GeoIP Country" page. Proceed and complete your order at MaxMind's site. To install "GeoIP Country" database upgrade within an installed version of LinkDeny, download the new database from MaxMind's site after purchasing the database upgrade. You will want to download the latest in the GeoIP-106 series of files, which should end with a .dat file extension (for example, GeoIP-106_20070123.dat). Note: do not download the GeoIP-108 series of files, as these are in .csv format and are not compatible with LinkDeny. After downloading the file, navigate to the C:\Program Files\Port80\LinkDeny\data directory (by default) on the server with LinkDeny installed. Make a backup copy of your included "GeoLite Country" GeoIP.dat (just rename it to GeoIP.dat.BAK) to make sure you can roll back if there is an issue with the upgrade. Rename the new "GeoIP Country" file to GeoIP.dat and save it in the C:\Program Files\Port80\LinkDeny\data directory (by default). Close the LinkDeny Settings Manager (if open), restart IIS, and test any IP Address-related rules in LinkDeny. You will now be using the "GeoIP Country" database for LinkDeny anti-leeching and access control. If you subscribe to the weekly updates for the "GeoIP Country" database, repeat the process of downloading from MaxMind's site, renaming and saving the file in the correct directory, and then restarting IIS to apply your updates to the "GeoIP Country" database. System Requirements LinkDeny is compatible with the following:
Port80 Software Technical Support support@port80software.com www.port80software.com/support 888.4PORT80 (888.476.7880) toll free 858.268.7960 phone 858.268.7760 fax | | |
 | |||||
 | |||||
|
| ||||
