Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All
     

    Related Documentation

     

    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 1: 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.

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

    Table 1: 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

     

    Published: 2014-06-27