The activity policy of the access protection service
Activity policy concept
The Integra activity policy operates by checking the available information for each request received by the platform. If a check is positive, than the matched rule results is triggered. In most of the cases, this leads to automatically adding the request origination IP to the platforms block list. All access is denied to the IPs in the block list and a custom error message is presented instead.
To manage the conditions which will cause an IP to be inserted into the blocked list, you need to setup or create new activity policy rules. There rules divided in three major types. These rules are applied with priority in the following order:
IP requests count
With this rule you can set a threshold on the number of resource requests allowed from a certain IP for each 60 second period. If the requests exceed this threshold, the IP will be blocked for the predefined period of time. Have in mind that per default, all web resource requests are counted. In one web page there could be 20 or 30 web resource requests for css files, images, scripts and etc. You can fine-tune this by applying a RegEx pattern. In this case, only the requests that have URL matching this pattern will be counted.
With this rule you can block IPs that generate requests which results unhandled exceptions. Such IP could be scanning for software hacks, back-doors or all kinds of vulnerabilities. In this case, if the system is updated or the security of the webserver is set correctly, the .Net framework generates an exception error with specific message and description. You can match this exception details (the exception message, stack trace and inner exception) by RegEx pattern, and if positive the IP that perform the request will be blocked for a certain amount of time
IP request details queue
The last and most comprehensive rule type is actually a fully customizable queue, which will be checked until the first positive match. You can create unlimited number of rules in this queue and match all the request details:
- request origination IP - the exact address of the IP that initiated the request
- the requested URL - what was the internet address of the requested web page
- request origination hostname - if the IP address also has a hostname (label) assigned, it can be matched too
- request user-agent - you can also match the client software name that initiate the connection, by its network name
- request referrer - sometimes the browsers also provide to the server the information which was the previously visited URL
- honepot response - you can check the request IP against the HoneyPot Project knowledge base. This is the biggest web community for tracking online freud and abuse. To use this rule pattern match target you need to set the HoneyPot integration settings.
Key elements of the rules
- rule expiration - each rule will be applied until it exceeds its expiration date. Once expired the rule will be still stored, but no longer forced.
- block period - the period for which the IP should be in the block list. The IP block expiration date is calculated as the last date of matching the rule, plus the block period. This means the expiration date will be constantly prolonged, if the IP keeps matching a rule for blocking it
- error message - The platform will respond to all requests from blocked IPs with "403 Forbidden" error code and a human readable message, which you can set in this field.
- rule target - What element of the request should be matched with the RegEx pattern
- regex pattern - a standard Regular expression pattern that will be matched against the rule target. If the match is successful the rule results will be triggered
- rule result - rules, whether on successful pattern match, the IP should be added to the block list (blacklist) or the rule queue execution should be terminated (whitelist)
Last edited by Boz Zashev on 29 Sep 2010 | Rev. 5 |
This page is public
Filed under: Global settings