Block a client with an IP address blacklisted

In a previous article, we explained how to pass as a header attribute the blacklists to which an IP belongs thanks to the capabilities of the Cloudflare Workers. In this article, the traffic never was redirected in the event of a malicious IP address, delegating that responsibility to the developers checking the content of the HTTP header. This is valid for those who have full control over the server-side code, but for those who only use WordPress or Drupal tools they could not use the script.

Unlike the other script, this one will return an HTTP 403 error if the IP address is among the ones stored in Apility.io, not allowing that client to progress on our website with the malicious IP address.

 

Apility API and Cloudflare to the rescue

Cloudflare already offers WAF and Page filter capabilities. In this example, we are going to implement an extra security layer in front of our website to block traffic coming from malicious (and suspicious) IP addresses. Thanks to the quarantine capabilities of Apility.io is also possible to block access to our pages from a specific IP address, one or several continents, one or several countries, and one or several Internet Service Providers.

You can have a look at this articles in our blog to know more about how we do it with other technologies: How to create custom security filters to your pages,  block malicious users trying to register using anonymous VPN like TOR, anonymous proxies and so on.

The next example will show how to:

  1. Intercept all requests
  2. Extract the remote client IP address from the cf-connecting-ip
  3. Perform an HTTP request to Apility API badip
  4. If the request returns an HTTP 200 OK, it means that the IP address of the client is in a blacklist. So, the client is redirected to HTTP 403 FORBIDDEN error page.
  5. If the request returns an HTTP 404 NOT FOUND, it means that the IP address of the client is not inside any blacklist. So, the client can continue with the previous requests as usual.

Hence, when a request is made to the website where the Worker has a route configured, the Worker will figure out if the IP is malicious and will branch to an error page if the IP address is malicious, or will continue to the website if the IP is clean.!

Enable Cloudflare Workers

Workers is a paid feature, so developers have to enter the billing details first, and enable the Workers feature:

Cloudflare enable Workers Apility.io

Once enabled, we have to open the Launch Editor where developers can code and test the Workers:

Cloudflare Workers launch workers Apility

The Editor is a Web Application where developers can code, test and preview the Workers. They can also configure the routes. A route is a URL to intercept. A Worker is like a man-in-the-middle: it sits between the browser of the remote clients and the origin server. Then, the route controls what resources at the origin server will be handled.

Coding the Worker

Now go and paste in the Script window the code you can find in this gist. Don’t forget to replace the APILITYIO_API_KEY with your API KEY in Apility.io!

Note: You can register for free and obtain your API KEY!

The code is very simple, but it’s worth to have a look at the Cloudflare Workers documentation and the Service Workers API to understand how they work.

To test this Worker, I have added it this route https://apidocs.apility.io. This subdomain redirects to our well-known API documentation pages.

Now open, a browser and point to https://apidocs.apility.io. If your IP address is clean, it will automatically redirect to https://apility.io/apidocs where you can read our API documentation.

But now, I’m going to repeat this test using TorBrowser. TorBrowser is a Firefox-based browser to use the TOR network. This is what happens when I open https://apidocs.apility.io with TorBrowser.

TorBrowser-Apility-Cloudflare

The IP 46.165.230.5 looks very busy as a suspicious address.

Blocking access by IP address, country, continent or service provider

It’s possible to implement advanced WAF-like features fine-tuning the Apility.io features. Apility.io has more than 100 blacklists and some of them are more sensitive than others. A developer can disable the blacklists that can be too broad and focus on blacklists that are more focused on your interest. For example:

To select the right blacklists, open Blacklists in the menu at the right-hand side and choose the lists under the IP address tab.

Apility.io choose ethereum blacklists from the dashboard

Thanks to the quarantine features, a developer can ban a group of IP addresses, countries, continents or service providers.

Let’s say that a developer wants to block access to his website from all countries except North American countries. With quarantine features, you can do it with different approaches, but the easiest one would be to quarantine all IP addresses from all continents except North America. To do it, access the QUARANTINE option at the black menu at the left side of the screen. To add a Continent to the Management Dashboard goto Quarantine > Continents and enter the Continent to ban and its Time to Live in this form:

Apility quarantine ban all continents except north america

Enter all continents except North America. If you want to ban permanently the continents, then leave the TTL box empty, but if you want to set an expiration time, then enter in the TTL box the number of seconds the ban will live.

Now you can open again the https://apidocs.apility.io and if you are in North America, but if you are in Europe like me, my IP will be banned:

Apility quarantine ban all north american users

The IP is a perfectly clean address from Telefónica Spain: https://apility.io/search/79.156.255.155

Do you have cool ideas of Apility.io and Workers? Let us know in the comments section!