Support

Hello,

thank you for suggesting it. I'll report it to Nicholas and let's see if that's something we can add as feature.

It is unlikely we will implement it because of the VERY low rate limits. You get 1,000 checks per day with a free key. Beyond that you receive an HTTP 429 error. Even in their top tier subscription you only get 50,000 requests per day.

This poses many problems for an implementation.

First, it's an HTTP API which means that for every request to your site you need to make a request to their API. This is slow since their API server is not on the same local network as you are. The API response time is comparable to the time it takes for your own site to render a page. This will have a detrimental impact on page load times, therefore your site will sink in search engine results.

Caching the results is both complicated and problematic. The complicated part doesn't worry me, even though it does come with a further performance impact on your page load. What worries me is that their API doesn't return an expiration time. So, how long do you cache a result for? 1 hour? 1 day? 1 month? Forever?

Even caching is not a solution for most sites. Because of the very low rate limits we have to assume that any failure in the API is an implicit allow for the IP address being queried. Considering that the API limits are extremely low even in their top tier subscriptions this may very well lead into a false of security. That is to say, your rate limit may be consumed very early within the day checking legitimate traffic. By the time an attacker comes you may not be able to query for their IP, letting them access your site anyway. 

What you probably had in mind was scraping their banned IP list and somehow integrating into the IP blacklist in Admin Tools. This is even more problematic. First, they explicitly warn you against doing that, meaning that they will detect it, stop it and blacklist your server's IP address. So not only you get no protection, your own server is now in the naughty list which affects everyone else sharing the same IP with you, which in turn will likely get your hosting account suspended (hosts pay a premium price for IP addresses; burning them like that is highly frowned upon and does get you kicked out in a heartbeat).

Even of that wasn't the case, the problem remains that the blocked IPs do not have an expiration time or even a good indication of whether they are a low, medium or high probability blocking target. That is to say, you'd end up blocking a hell of a lot more legitimate traffic than you'd actually want to.

Finally, I have concerns about their self-reporting model of suspicious IPs. The way they tell you to configure Fail2Ban and other tools means that any moderately suspicious traffic — even false positives — are reported as votes to ban an IP address. Considering the lack of good information about whether an IP address is a high probability ban target or not (you only get the total number of reports and the last time it was reported, which says sod all) I am not entirely convinced that it's a useful dataset.

To me it looks like someone is trying to make a hell of a lot of money off a low quality dataset. Basically, you pay a lot to get restricted access to security theatre. That's the worst combination I can think of.

I'd strongly recommend using the Project HoneyPot integration instead. First of all, they use a DNS API which is fast and cached automatically on your server's local DNS resolver. Second, they provide good quality information about the probability that an IP really needs to be blocked and why. Third, they have no API limits. Fourth, they only collect results through a very specific method which is guaranteed to weed out spammers/attackers without relying on self-reporting that can be gamed or flooded with low quality results. Overall it looks like a sensible approach to security, unlike AbuseIPDB.