Response Overview

To view existing response rules, and to add your own counter response, navigate to Configuration > Responses in the Web UI.

A counter response is composed of a set of rules which define the conditions under which a response should be automatically created and activated for a specific session or profile. To turn on the counter response service, navigate to Configuration > Services > Counter Response Service and enable the appropriate responses.

It is possible to have as many rules as needed to protect the system. However, the more rules, the longer it will take to determine if a new incident matches an event condition. In addition, the more conditions in the rule, the longer the rule will take to evaluate if the event condition matches a new malicious incident.

Figure 73: Responses

Responses

Note: You can view the default responses for each rule by clicking read more at the bottom of the entry's description in the Web UI.

Under Actions, you have the ability to create a new response rule by cloning an existing one. Click View/Clone to view the current response in a new window. In the View Autoresponse window, click Clone to New Rule. A copy of the selected response is created. You can edit this copy to create a new one.

Note: To create your own response, click the Add Autoresponse button at the top of the window. (Creating responses from scratch is an advanced task. Refer to the product’s API documentation for configuration details.)

Figure 74: Autoresponse - Clone to New Rule

Autoresponse - Clone to New Rule

Figure 75: Cloned Autoresponse , Ready to Edit

Cloned Autoresponse , Ready to Edit

The following table describes the default responses.

Table 43: Response Descriptions

Default Response

Description

Session Management

This response rule triggers if the user attempts to manipulate the WebApp Secure session tracking cookie.

Application Vulnerability Processor

If your web-application uses supported third party applications (like Joomla, Wordpress, and so on.), this processor will analyze and act on malicious traffic that intends to exploit them. For more information on which third party tools are supported, refer to the Response documentation in Web UI.

Login Processor

This rule triggers on incidents that are generally triggered by abusive and suspicious activity targeted at the websites authentication system.

Access Policy Processor

This response rule triggers if the user attempts to exploit the fake service exposed by this processor.

ETag Beacon Processor

This response rule triggers if a user attempts to manipulate the WebApp Secure cached based tracking token.

Basic Authentication Processor

This response rule triggers when the user attempts to exploit the fake .htaccess file exposed by this processor.

Robots Processor

This response triggers when the user or malicious spider uses the information in the robots.txt file for illegitimate purposes.

Hidden Input Form Processor

This response rule triggers when the user modifies a hidden form input parameter.

Cookie Processor

This response rule triggers when the user attempts to manipulate the value of a cookie.

AJAX Processor

This response rule triggers when the user interacts with a fake AJAX function injected into the web application. If the user reverse engineers the code and manually invokes its behavior, such as would happen with an automated script or spider, the rule will fire. If the user actually invokes the Javascript function, the rule will fire.

Header Processor

This response rule triggers when the user has unusual headers or header data which a normal browser or well developed spider would not supply. If the user excludes required headers such as Host and UserAgent, manipulates their user agent header, overflows headers beyond RFC standards will cause this rule to activate.

Hidden Link Processor

This response rule triggers when a spider or malicious user attempts to identify unreferenced resources in a fake directory.

Query Parameter Processor

This response rule triggers when a user manipulates the fake query parameter injected by the system more than 3 times.

Method Processor

This response rule triggers when a user or spider sends a request with a malicious HTTP method such as TRACE.

Error Processor

This response rule triggers when a user attempts to find unreferenced resources by guessing file names.

File Processor

This response rule triggers when a user attempts to find sensitive files by guessing file names or changing parts of valid file names.

Warning Processor

This response rule triggers when a user attempts to automate the dismissal of the warning response.

Cookie Protection Processor

This response rule triggers when a user attempts to modify the web application session cookie.

Captcha Processor

This response rule triggers when a user attempts to find a way to bypass the captcha response without solving the captcha.

CSRF Processor

This response rule triggers if a user attempts to manipulate the CSRF protection introduced by the system, potentially to find a filter evasion vulnerability.

Custom Authentication Processor

This response rule triggers if a user attempts to exploit the authentication mechanism offered by the system.

Client Beacon Processor

This response rule triggers when the user attempts to tamper with the client side tracking logic.

New and Modified Profiles

This response rule sends out an alert any time a new profile is created, or a profile elevates its threat level. The severity of the alert will equal the threat of the new or elevated profile that triggered the alert.

Returning Profile

This response rule sends out an alert any time a profile returns on a subsequent day. For example, a new hacker is observed on Monday, if the hacker is only active for 1 hour on Monday, but returns on Tuesday to continue, this rule will issue an alert. The severity of the alert will equal the threat level of the profile.

New Incident

This response rule sends out an alert any time a malicious incident is observed. The severity of the alert will equal the complexity of the incident. Note that non-malicious incidents are excluded by default. Setting your alert contact level to "informational" or "suspicious" will only have an effect when dealing with custom response rules where you manually set these severity levels.

New Response

This response rule sends out an alert any time a new counter response is activated. The severity of the alert will always equal 1.

Related Documentation