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

    Autoresponse Overview

    An autoresponse is composed of a set of rules which define the conditions under which a counter response should be automatically created and activated for a specific session or profile. 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 incident.

    Figure 1: Autoresponse

    Autoresponse

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

    Description

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

    If your web-application uses supported 3rd party applications (like Joomla, Wordpress, etc.), this processor will analyze and act on malicious traffic that intends to exploit them. For more information on which 3rd party tools are supported, refer to the AutoResponse documentation in Security Monitor.

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

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

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

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

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

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

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

    This autoresponse 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.

    This autoresponse 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.

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

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

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

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

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

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

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

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

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

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

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

    This autoresponse 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.

    This autoresponse 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.

    This autoresponse rule sends out an alert any time a new incident is observed. The severity of the alert will equal the complexity of the incident.

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

    Published: 2013-11-20