This post will be a high level overview of how to easily block traffic coming from SubstratumNode v0.4.1. Since this version of SubstratumNode is still technically in beta, I won’t be going into detail about how to reproduce each step. However, if you have a basic understanding of Unix command line, spinning up a VPS, and firewalls, you’ll be able to identify, log, and block SubstratumNode IP addresses as well.

Here are the steps.

  1. Set up a decentralized network of nodes.
  2. Set up a destination server that supports IP logging.
  3. Use cURL to ping the destination server from SubstratumNode.
  4. Set up a WAF in front of the destination server. Cloudflare works fine.
  5. Block the logged SubstratumNode IP with the WAF.

Set Up SubstratumNode

In order to set up a decentralized network of nodes, I created four DigitalOcean servers in Singapore, London, Toronto, and NYC.

Next, I ran through the following steps on all four servers.

  1. Run adduser sub to create a new user.
  2. Run usermod -aG sudo sub to give root privileges to sub.
  3. Download SubstratumNode binaries with wget https://s3.us-east-2.amazonaws.com/substratum-website-downloads/v0.4.1/SubstratumNode-v0.4.1-Linux64-binary.zip
  4. Unzip the binary package with unzip SubstratumNode-v0.4.1-Linux64-binary.zip

Next, I changed each server’s DNS to localhost with sudo ./dns_utility subvert. I decided to use the Singapore server as my bootstrap node with the other three servers acting as standard Substratum nodes. To do this, I used the following commands. Please note the value for --bootstrap_from is the unique identifier for the Singapore bootstrap node and was obtained after executing SubstratumNode.

Singapore – 128.199.75.62

sudo ./SubstratumNode --dns_servers 1.1.1.1 --ip 128.199.75.62 --node_type bootstrap --port_count 6 --log_level debug

London – 46.101.13.17

sudo ./SubstratumNode --dns_servers 1.1.1.1 --ip 46.101.13.17 --port_count 6 --bootstrap_from xXF/eofURHfbxSPO6hj1UIMjkHsjb4+T28ytlJt4eZY:128.199.75.62:41154,40624,44932,45945,47272,50194 --log_level debug

Toronto – 178.128.224.230

sudo ./SubstratumNode --dns_servers 1.1.1.1 --ip 178.128.224.230 --port_count 6 --bootstrap_from xXF/eofURHfbxSPO6hj1UIMjkHsjb4+T28ytlJt4eZY:128.199.75.62:41154,40624,44932,45945,47272,50194 --log_level debug

NYC – 142.93.3.202

sudo ./SubstratumNode  _servers 1.1.1.1 --ip 142.93.3.202 --port_count 6 --bootstrap_from xXF/eofURHfbxSPO6hj1UIMjkHsjb4+T28ytlJt4eZY:128.199.75.62:41154,40624,44932,45945,47272,50194 --log_level debug

Here’s what it looks like when all four nodes are running. Please note the Terminal window for the NYC node has an extra tab which will be used to make requests to my destination server (https://brianli.com).

Set Up a Destination Server with IP Logging

For this experiment, the server I use to host BrianLi.com has IP logging. Another option would be to spin up another DigitalOcean server with a LAMP or LEMP stack — Apache and NGINX both have server logs.

Use cURL to Ping the Destination Server

Next, I executed the following command on the NYC (142.93.3.202) server.

curl -I https://brianli.com

SubstratumNode then routed this request through the network of nodes, and I received the following HTTP/1.1 200 response on the NYC server.

This is what the request on my destination server log looked like.

As you can see, the destination server saw the request coming from 46.101.13.17, the IP address of the London server. This tells us two things.

  1. SubstratumNode does in fact route data through nodes.
  2. The IP address of the original node is shielded.

Use a WAF to Block SubstratumNode Traffic

Next, I used Cloudflare, which acts as a reverse proxy, caching layer, and web application firewall (WAF) for BrianLi.com, to block the London server (46.101.13.17). I used the NYC server once again, but this time I executed the following command to download the favicon on my website.

wget https://brianli.com/favicon.ico

As you can see, the request failed (403) after blocking the IP with Cloudflare.

The Cloudflare log shows that the request to favicon.ico was blocked.

Can This be Used to Censor the Network?

So, what this experiment demonstrate?

  1. SubstratumNode is capable of routing traffic through nodes.
  2. If you set up an origin node and control the destination server, you can easily log exit node IPs by simply sending cURL requests through the Substratum network.

What are the consequences of this?

  1. Substratum’s self-healing is expected to be able to find alternate routes to the destination server in case one is blocked. By setting up a cron job to routinely ping a destination server that you control, it’s possible to take advantage of the self-healing feature to log all node IPs on the network.
  2. A pro-censorship government can block these IPs or use them to identify citizens who are running nodes to bypass censorship. ISPs issuing dynamic IP addresses doesn’t really matter. The parties that would be interested in preventing people from using SubstratumNode are more than capable of time-stamping IP logs and cross-referencing them to dynamic IP assignments to telecom customers.
  3. In China, citizens have been arrested for running VPN services. SubstratumNode’s traffic serving mode is essentially identical to a VPN forwarding traffic as a service.

Once again, the experiment above was performed with SubstratumNode v0.4.1. The production version of SubstratumNode is expected to bring features such as monetization, self-healing, and encryption. Don’t be fooled though, the encryption that the team has spoken only has to do with the actual data transmission between nodes, and it will not “encrypt the IP address” — whatever that means. Finally, this method of IP identification is not SubstratumNode’s only potential flaw. Others have discussed the possibility of harvesting the IP address of the next-hop node via the CLI’s debug mode and blocking the IP address of the server that keeps a master list of node IPs (if such a server were to exist).