To block TOR traffic or any anonymity service out there is not an easy decision. Any product manager of online services faces this dilemma sooner or later: let users onboard in my service as simple as possible so they can test my product or harden the conditions for registration and therefore drive away potential customers. Nowadays the general trend is to not request more data than necessary to test the service, and once users are convinced that they want to become customers, the service requests additional information such as billing information and payment methods.

However, this idyllic setting is not what most of SaaS providers face on a daily basis. The Internet allows very high levels of anonymity for everyone, but there is always a subset of users who do not want to pay for a service making use of this anonymity.

TOR traffic and serverless/microservice architectures

Most of the traditional firewalling solutions out there block access based on the source IP. As result, if the IP of the Exit TOR relay is in any firewall blacklist the client will not be allowed to access the destination IP of the service.

This all or nothing approach makes that some legit users cannot use a microservice at extent. Using TOR is not bad in itself, but using TOR to register in a SaaS solution with fake data and fraudulent payment methods is bad.

Hence a more friendly approach would be letting users register from non-anonymous networks, but let clients connect and use the service without restrictions. Just fence the key parts of your services. REST API can return in milliseconds if an IP is an active exit TOR node for you to decide what to do next. The list of TOR nodes updates every 60 minutes, so there is always a fresh list of TOR node exit IP.

The Bad IP list

In  we collect several lists of suspicious IP from different sources. You can browse those lists here. One of them is the TOR exit node lists.This list is built every 60 minutes querying the TOR network about the status of their nodes, there is no middle-man building it.

How to make a request

We just need to pass in the URL the IP to query in the Now all requests must be through a secure connection. The IP used was a valid TOR exit node when this post was written (mid-August 2016).

Adding the header “Content-Type: application/json” will return the full list names with the IP included.

The response

If you make a request to our API querying for any IP, the service will return several possible responses:

  • 404 – Not found: And this is good because it means the IP was not found in any list. The IP looks good.
  • 200 – OK: And this is not good because it means the IP was found in some lists. The IP is suspicious and not very reputable.
  • 429 – Too many requests: You have run out of quota. The daily quota is reset every day. Please consider upgrading to a paid plan to have a larger quota.

If we add the “Content-Type: application/json” header then we will also obtain the following information:

What is the fastest option?

Therefore testing the response HTTP code is the fastest way to check the reputation of the source IP. In case of a 200-OK response, your code should handle the IP as ‘malicious’. A 404-NOT FOUND is a good IP.

Finally, adding the “Content-Type: application/json” header you can fine tune what lists are more malicious than others in your code. Beta testers can configure in the dashboard what lists should be handled as malicious.

And now, go and check our developer documentation and start using our services.