DOS validator nodes of blockchain to block external connections

Attack was documented in the in the github repo: https://github.com/hyperledger/indy-node/security/advisories/GHSA-x996-7qh9-7ff7 # Attack: The attacker sends 500 read requests to each node and opens a new one when holding 500 parallel connections. Every user is able to send read requests since it's a public readable registry so setting up an allowlist like it's done with the nodes' port for the consensus does not work here. To increase the efficiency: the custom read request is increased with more bytes (random header or json values) the bandwidth of the sender machine is limited Requirements on the attacker side: Indy-VDR: comment out the timeouts. Using another tool to send the requests could be even more efficient VM: attack can be performed from one or multiple VMs limited connection: using TC to limit the bandwidth (value depends on the amount of connections) Sample Implementation We set up a VON-Network and added the firewall rules. The VM had 32 CPUs and 64 GB RAM # Result: there is no damage to the blockchain, only an unreachable network as long as the attack is going on . Other clients are not able to send read or write requests to the nodes. In the "best case" their requests will go through but with a response time of multiple seconds, see: Not available [image: image.png] Not available [image: image.png] # Counteractions: blacklisting actors: It does not matter what is in the body since the firewall rule acts in front of indy that is processing the information. To avoid big requests the firewall could set a limit of the request size, but this could also block valid requests. Scaling via the observer-pattern: Right now the amount of nodes is limited so blocking 25*500 connections is very easy. When adding nodes in front of the validators to prevent accessing from the internet the validators are save, but then all the observers are under attack Scalability: Giving the VMs more CPU and RAM to increase the parallel connections amount can help in first run, but the DoS attack can be performed as a DDos. An attacker does not have to DoS the network 24/7, but can scale up the VMs on demand to attack a specific network. The setup is done in about 2 minutes automatically. In our test we used 500 as the limit. Maybe there is some kind of algorithm for the node administrators to calculate the limit based on their CPU. But in this case the attacker can also increase his ressources. ## Impact An attacker can max out the number of client connections allowed by the ledger, leaving the ledger unable to be used for its intended purpose. However, the ledger content will not be impacted and the ledger will resume servicing client requests after the conclusion of the attack.