On P2P, VPN, and DDOS — When a P2P service, such as a Blockchain, gets attacked by DDOS


While the nature of P2P networks is such that each participant should run a node to support the network, achieving that is quite complex as it requires participants to install specific software on their computers and keep them running.

In many cases outside access to the P2P network is granted through gateways. Let’s think about the Bitcoin P2P network, the nodes that support it, and the Bitcoin users. 99% of Bitcoin users are not running a Bitcoin node: they rely on 3rd parties to do so.

The wallets that Bitcoin users install in their mobiles connect to the P2P network only to broadcast transactions, yet they query the blockchain (for example to know an account balance) using a centralised API on a server. The same is valid for web wallets that while many do broadcast transactions directly to the P2P network, have a single point of entry (the web page where they are opened), and a centralised centralised API on a server to query data. Having a local node removes the need for the user to rely on a centralized API (which is a vulnerable point that an attacker can target).

Gateway entry points (for example well known servers that offer API access or UI interfaces) are easy to attack as the target is precise and easy to locate (via domain name and IP address). A solution for DDOS attacks to gateway entry points is a service such as CloudFlare.

Attacks on large P2P networks are difficult, as nodes in the network keep appearing and disappearing, and they are in many different geo locations and network locations, and thus it would be too expensive to attack all of them at once.

New P2P services, and in the specific new Blockchains, rely on few nodes and are an easy target for attacks. Defending a new P2P service, where all the nodes are exposed, is not a simple task due to the nature of the P2P network.

What is a DDoS?

A DDoS Attack (Distributed Denial of Service Attack) uses many computers distributed around the whole world, most often part of what is known as “botnet” (hacked servers and IoT devices remotely controlled by a hacker), sending unanimously a flood of requests to a target server that will then stop working as it is overloaded by thousands of requests. What cause the server to stop working are both a network congestion (making the target server hard to be reached from the Internet), and processing exhaustion if the requests require particular computational power (queries to a database, etc).

P2P basics

NOTE: I will refer to nodes either as nodes, servers, or peers. They are the same thing.

A P2P network works in a simple, yet efficient, manner. First of all we must understand that a P2P network is decentralised. This means that there is no “central” server to coordinate the full network. Each node is left alone to figure out who is in the network.

Nodes achieve this by reaching to a few core nodes (a list of known peers in their config file), or by simply searching in the network for server responding to P2P requests at the assigned port. Once they connect to one of this nodes they announce themselves (share their IP address), and ask for the list of the peers (nodes) known to the server they just connected to. Doing this each node enrich the list of possible other nodes in the network they can connect to, while keeping the list clean (what nodes are online, which ones are offline and since how long, etc).

Nodes keep a sort of reputation score for each other node in the network, and share this reputation scoreboard with the other nodes. When a node misbehave (broadcast wrong data, don’t respond in time, etc) and many of the other nodes agree that that particular node can’t be trusted, it is put on a blacklist for a certain amount of time. If it doesn’t fix its issue (update data, send out correct info) it gets banned for longer periods of time.

What are a P2P split and a Blockchain Fork?

As the P2P network is decentralised and there isn’t a set amount of nodes to define it, it can be split in more networks each self sufficient. Let’s think an absurd scenario where a P2P network has nodes all over USA and Europe, but there is a single fiber optic cable that connects Europe with the USA. A crazy scuba diver cuts this cable and disconnects the USA from Europe.

The nodes in the USA will simply think that the nodes in Europe are off, the nodes in Europe will simply think that the nodes in the USA went off, and each “sub” group will continue thinking they are the only full network existing, while we will have two separate networks in existence. As if there were two parallel universes where two separate realities existed. This is a P2P split. What happens when the P2P that splits is one for a Blockchain?

As Blockchains keeps piling up blocks, one connected to the previous one, in case of a P2P split the blocks piled in each of the resulting two networks will depends on the events taking place in the respective network, and thus be different one from the other.

This means that, if the above scenario is applied to the Bitcoin network, if I had 10 BTC before the split of the network, and I spend 1 BTC in the European network once the original global network is split in two, my balance in the USA network remains 10, while in the European networks goes to 9.

Yet if the fiber optic cable gets fixed in time and the two networks reconnect to become again just one, the nodes that were in the smaller part of the split will restore themselves to mirror what the majority of the nodes say is the truth. If, for example, there were more nodes in the USA than in Europe, the transaction of 1 BTC spent in Europe is erased, and my balance goes back to 10 everywhere. Still, if the split remains active for too long (node software has a maximum amount of blocks to look back at to restore a fork), there may be no more restoring of the minority nodes to match the majority, and thus the blockchain forks with P2P nodes in the USA blacklisting European nodes, and vice-versa.

Forks can take place also without network split, simply if a group of nodes start saying things the rest of the nodes do not like, for example due to a node server software update, with a change in the protocol (see what did happen between Bitcoin and its fork Bitcoin Cash). Another way for forks to take place is when some of the nodes of a Blockchain end up in a VPN…

When a small P2P network is attacked with a DDOS

Let suppose that there is a new Blockchain with few nodes, all controlled by a single person or company, with a web wallet that can be accessed at a specific URL, a mobile wallet that uses a specific server APIs for both broadcasting transactions and querying blockchain data, and another mobile wallet that broadcast transactions to the P2P network directly, but read Blockchain info from a server API.

The nodes are connected via P2P network, each advertising their IP addresses to the others, and thus making the list of IP addresses of the all network publicly known.

An attacker has several options, and so has the maintainer of the network:

  1. Attacker: DDOS attack to the web wallet
  2. Maintainer: put the web wallet behind a service such as CloudFlare to keep the web server IP address secret, making sure the web wallet is not hosted together with a node, else the server IP is also available in the P2P list, thus giving the attacker a way to bypass CloudFlare and take the server down.
  3. Attacker: DDOS attack the API server
  4. Maintainer: if the API server is reached on port 80 or other ports available on services such as CloudFlare, and the software using the API doesn’t do many subsequent requests, then use a service such as CloudFlare for the API server, making sure the API server is not hosted together with a node, else the server IP is also available in the P2P list, thus giving the attacker a way to bypass CloudFlare and take the server down.
  5. Attacker: DDOS attack the P2P network (all the servers, as they are few)
  6. Maintainer: Put the few servers in the P2P network behind a VPN (a Virtual Private Network — a network not accessible from the web). This has some negative consequences: the mobile wallet that broadcast transactions in the P2P network can’t reach it from the open internet, the web wallet that connects to the P2P can’t see the network as well, other nodes ran by users will not access the P2P network (possibly causing a fork, if there are more than 3 constantly online). Only mobile app and web wallet that use the API for both broadcasting transactions and querying the blockchain will work, yet creating a centralised system (who believe that there is a blockchain behind that URL?)

Why does leaving some nodes in a VPN and routing P2P requests via gateway servers to the rest of the public network doesn’t work?

Simply because the nodes in the VPN will announce themselves to the network with their private network IP address, and once the rest of the network can’t reach them they will be blacklisted causing a split, and then a fork.

Why has nobody ever managed to DDOS the Bitcoin blockchain?

As explained at the beginning of this document it would be too expensive and ineffective. The high number of nodes deployed under many different OS, each protected in different ways, makes an attack very complex and very expensive. Exchanges, web wallets, and other centralised services around the Bitcoin Blockchain have been victims of attacks tho.

What is the suggested solution?

The ideal solution is to keep the blockchain open, protect the centralised points appropriately (API and web wallet behind CloudFlare) and invest in growing the community of user running their own nodes (a few hundred nodes being the goal), and making them access the blockchain through their own nodes rather than a centralised web wallet.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.