Systematic process to ban malicious nodes

Github issue: https://github.com/nanocurrency/nano-node/issues/2238

Although every component of the Nano protocol is designed to maximize efficiency by using the least amount of resources possible, in order to protect nodes against specialized Denial of Service (DoS) attacks, a process should be established to systematically ban malicious nodes (peers).

In this context, a malicious node is any node that sends junk data, such as:

  • Invalid packets (messages which cannot be deserialized)
  • Invalid blocks and votes (difficulty below threshold, invalid signature)
  • Blocks that cannot fit the ledger
  • Bad bootstrap requests and responses
  • Duplicate data, requests

Existing approaches [1] use a system to continuously score peers and disconnect them once a threshold is reached.

One of the open questions is how long to block peers, and if it should only be done locally by each node.

[1] https://en.bitcoin.it/wiki/Weaknesses#Might_be_a_problem

5 Likes

Another problem is how to handle IPv6, specifically how large of IP blocks to ban there. Banning individual IPv6 addresses does next to nothing for most residential networks, but banning a subnet may also ban adjacent cloud servers. Perhaps a gradually adjusting subnet size ban could be used.

2 Likes

Is it reasonable to block a peer that is propagating transactions at an abnormally high rate?
Presumably the spammer has to publish from their own nodes if they want to accomplish very high transaction volumes.
You may immediately run into issues of some secondary propagating nodes being blocked too, but I wonder if this could be minimised.

My opinion is no, it is not reasonable to block a peer that is propagating at an abnormally high rate. The indicators of malicious nodes that @Dotcom mentions are just that, interpreted in no other way than malicious. Spamming, while it can be malicious, is using the network as designed. We have POW difficult to combat spam.

In that vein, however, I am highly skeptical of any blocking/banning of nodes regardless of data sent. First, the filters in place to get junk out early should be efficient. And second, it becomes a cat and mouse game that only complicates the network.

The Nano network should operate on Zero trust. Assume any inbound node traffic is malicious ... filter and move along smartly.

Note: if there are metrics proving network impacts from malicious (not spam) behaviors, would love to see

3 Likes

One thing to be careful of with ban rules is spoofed traffic. You don't want to block legitimate services/nodes because a bad actor forged some info, and you don't want the Nano network to be the one DDoSing (reflection) someone because the nodes started trying to communicate with a spoofed IP. You also have to be careful about blacklisting IPs long-term because of shared infrastructure (AWS, GCP, Azure, etc). The reference Bitcoin implementation might be a good start though (24 hours)

3 Likes

Regarding blocking by IP. Can a node have some other type of identification? Like an extra ID that require 6h of PoW computation, ie. expensive to create but only done one time per node. Then block by that ID if it misbehaves.

5 Likes

Interesting thought!

Wouldn't the existing Nano address be enough already? If that gets blocked from being a representative (or from broadcasting blocks) for bad activity, the owner would have to create a new address and then they'd have 0 voting weight.

The bigger issue imo is defining the block triggers and the block time (ha!). We really want to avoid triggers that can be spoofed by bad actors to get legitimate representatives blocked

That is also interesting. Reset their weight would be very effective against certain attacks but sounds a bit dangerous as you say. However, it would take them a second to set up a new account. I think a really heavy PoW makes sense somewhere.

I guess it depends on what our goals are. If it's just to penalize bad PRs so that they can't rebroadcast bad blocks, using their current Nano address as the identifier might be enough. If it's to stop all nodes from being able to send junk packets that slow down the network then you'd have to up the PoW requirements as you say

1 Like

The PoW required to start a representative node is an interesting idea that could be worth exploring further imo. Adding PoW for peer connections has also been thrown out at times.

Another malicious act worth penalizing against could be sustained voting or peering with the same representative account from different IP addresses - this might fall under the duplicate data point in the original post.

1 Like