Knowledgebase
False Positives handling
Posted by Yarden Loumer on 03 January 2012 06:43 PM

dd

 

1. Track down a False-Positive:

When a user is getting blocked he will receive the following error page by default:

1

 

2. Searching for the False-Positive event using the Reference ID:

When troubleshooting a false positive, you will need to search for the event that caused dotDefender to block the request:

 

To search for an event:

  • Click the Search icon 2 in the Log Viewer. The Search window appears.

3

 

 

  • Select Reference ID, and enter the Reference ID you received in the Error Page.
  • Click search and see the event details. These details can help you understand what made dotDefender block the request.

4

 

  • In order to better understand the event's details, find the following definitions:
8888


3. Set up a custom rule under the false positive category:

You can create new rules for dotDefender by using regular expressions to match the patterns that were identified in the false positive event mentioned above under the problematic category. Please notice you can also create the rule under the category "Custom Rules" which is the first category inspected.  The following instructions explain how to create a rule to allow incoming HTTP requests to the server.

 

To add a new rule:

 

  • Click User Defined Request rules in the problematic category. The User-Defined Rules list appears in the right pane:

55

 

  • Click Add New Rule. The New Rule wizard appears:

6

  • Type a description for the rule. Click Next. The Rule Type windows appears:

7

  • This is where you have to determine what kind of rule you would like to add in order to solve the false positive.

For example :

3.1 White-List IP:

      if the user that is getting blocked as an Administrator that needs to perform work on the server, you should choose "search in remote address" and enter the IP of the administrator in order to white-list his IP that you found in the False-Positive event details.

      Rationale: The blocked user (Administrator) usually uses a KNOWN and PERMANENT IP address. Thus, dotDefender shouldn't be blocking requests from this trustworthy user.

To search in Client Remote Address:

  • In the Create pattern window, in the Pattern to Search field, enter a regular expression for which dotDefender looks in the HTTP request. For further information, see Regular Expressions.

8

  • From the Take action drop-down list, select: Allow request (Whitelist): dotDefender allows requests containing the pattern.
  • (Optional) Select the Write to Log checkbox if you want the events matching the rule to be logged.
  • Click Next to continue. The Scope of Search window appears:

9

  • Select one of the following:

¨       Apply to all pages: dotDefender applies the search to all HTTP pages.

¨       Apply to specific URI: dotDefender applies the search to a specific URI. Enter the URI field.

¨       Apply to all pages except this URI: dotDefender applies the search to all HTTP pages, excluding the specified URI.

 

  • Click Next. The Completing the New Rule Wizard window appears:

10

  • Review the summary of the new rule. Click Finish. The new rule appears in the list of User-Defined Rules:

111

  • Click 12 to apply the changes. The following window appears:

13

  • Click Close.

 

3.2 White-List URI

      If regular visitors of the site are getting blocked under a specific URL, you should choose "search in URI" and enter the relative URL of the False-Positive event found earlier.

      A good example for this scenario is websites that host Blogs/Forums, where Visitors are able to perform free writing in text areas.

      Rationale: The legitimate inputs of the visitors sometimes seem like attacks while in fact they are not. The concept is to find the common denominator (in this case - URI) of the legitimate requests that are getting blocked and allow them.

To search in URI:

  • Select one of the following:

¨ Apply to all pages: dotDefender applies the search to all HTTP pages.

¨ Apply to specific URI: dotDefender applies the search to a specific URI. Enter the URI field.

¨ Apply to all pages except this URI: dotDefender applies the search to all HTTP pages, excluding the specified URI.

  • From the Take action drop-down list, select Allow request (Whitelist)
  •  (Optional) Select the Write to Log checkbox if you want the events matching the rule to be logged.
  • Click Next. The Completing the New Rule Wizard window appears:

14

  • Review the summary of the new rule. Click Finish. The new rule appears in the list of User-Defined Rules:

1111

  • Click  12to apply the changes. The following window appears:

13

  • Click Close.

3.3  Searching in other fields of the requests:

 

In addition to the two examples given above, it is possible to set the criteria of the rule for other fields and parameters of the request as well:

 

¨       Searching in Commonly Attacked Fields of HTTP Requests - Click Next to continue. The Create pattern window appears. Continue with Searching in Commonly Attacked Fields of HTTP Requests.

¨       Searching in User-Agent header – Search for pattern in the User-Agent client software identifier field. Click Next to continue. The Create pattern window appears. You can use this option in case you know that a specific software is getting blocked and you would like to White-list it.

¨       Searching in Custom Fields of HTTP Requests - Click Next to continue. The Custom Fields window appears. Continue with Searching in Custom fields of HTTP Requests. This is an advanced option and it enables you to search in ANY custom fields.

¨       Searching in custom parameters of XML/SOAP - Click Next to continue. The Custom Fields window appears. Continue with Searching in Custom Parameters of XML/SOAP.

 

3.4  Creating exception for specific URL:

  If the user that is getting blocked at specific URI by the specific category, and you wish to allow such requests at this URI you should create an exception for the rule.  On Configuration window, expand the needed site, then expand "Patterns", expand "the relevant category, and click on "Best practices".

Find the relevant type, and click on a little icon on the end of the line, to edit it. Enter the URL (enter the relative URI, for example /blogs/contact-us.asp). In the next field, choose "allow" and OK. From now on such requests won’t be blocked on this URI.

2222

Don’t forget to click 12apply the changes.

 

                        Thank you!
(3 vote(s))
This article was helpful
This article was not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below. This is required to prevent automated registrations and form submissions.

Help Desk Software by Kayako fusion