How Do You Ensure Accuracy?

  • RBLTracker Help

RBLTracker relies on data provided by third parties; whether it’s the RBL providers themselves, or Google and Yandex (for Safe Browsing data), or the data provided through the Facebook Threat Exchange. As such, we are somewhat subject to the accuracy of this data.

But there are few key things that RBLTracker does to reduce false positives, and make the results as reliable as possible:

List Validation

RBL and URIBL providers are regularly monitored and evaluated for both performance and accuracy. If a specific provider is found to regularly return inconsistent data, or false positives, we’ll remove the RBL/URIBL from our standard checks.

Customers can of course still use these lists if they wish, via the Custom RBL option in the RBLTracker portal.

Diverse Monitoring Locations

rbltracker_network_map

Monitoring is performed from several geographically diverse location (currently we use 11 different IP sources, but we add to the list regularly), to ensure that no single point will be rate-limited or blocked, causing false positives in the results.

This in incredibly important, as RBLTracker is currently (as of Q1 2016) processing around 450,000 checks per day.

False-Positive Mitigation

RBLTracker has implemented a “best 4 out of 5” logic when monitoring hosts. This logic is used both when a host changes from not listed to listed (listing), as well as from listed to not listed (de-listing).

The logic works like this:

  1. If the host IS NOT currently listed, but the new check returns LISTED, then we start the best of 5 logic, requiring 4/5 unique listed results to say it’s listed. If we don’t get at least 4/5, then the host will NOT be considered listed.
  2. If the host IS currently listed, and the new check returns LISTED, then the one result is enough to keep the host listed.
  3. If the host IS NOT currently listed, and the new check returns NOT LISTED, the one check is enough to keep it not listed (on an individual RBL or URIBL).
  4. If the host IS currently listed, and the new check returns NOT LISTED, then we start the same logic, except we need no more than 1/5 listed results to say it’s not listed on this specific RBL or URIBL anymore. If we get more than 1/5 unique results, then the host remains LISTED.

In our exhaustive testing, we’ve found that this logic dramatically reduces the number of false positive notifications, or “flapping” events, where hosts go back and forth between a listed and not listed state, on each check.

Tagged: