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

7 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

6 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.

6 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

That can broke mobile light-wallet, which will be unable to connect due to an high PoW. Futhermore, light-wallet are more likely to be consider "malicious" since can't reply most of the request and can duplicate the request.

I'm talking about "light-wallet" that don't uses RPC and talk directly with nodes.

1 Like

I don’t think the intent would be to ban these types. It would be more geared towards preventing excess spam or ddos type requests. So light accounts should be accounted for in any implementation. There’s no way to know if a node will pass on information that is sent to it.

One way could be to have different types of nodes or protocols for light, full node, voting node etc so that they are treating differently and a node could provide details when they connect, like if it’s a light node for example.

I didn't say that they are aiming to ban "light nodes" (nodes that observe the network, but not stores the data and don't participates the consensus). What I'm saying is that a light wallet is more susceptible to be recognised as a malicious node. If so, asking for PoW to unban comes a real problem.

Let's break down some of the topics which consider a node malicious:

  • Invalid packets (messages which cannot be deserialised)
    Since Nano is open-source, it must recognise that third-party developer may implement more types of packets/messages. For example, say that have made one light-wallet with one custom message such as "generate_work_req", to a light-wallet connect to others which may generate the work. Or maybe I have one custom message like "check_update_req" to see if there's any update on the network... My nodes can parse that new type of message, but NF doesn't. So, because of that, I'm malicious? If there's some message type like "I don't understand it", then it's sent when the node can't parse the block, seems ok to ban them. But, well, it seems too much for the Nano Protocol. Otherwise, have a proper field to specify the protocol-extension field or implementation-vendor.

  • Invalid blocks and votes (difficulty below threshold, invalid signature)
    A light-wallet are more likely to send invalid PoW, since it doesn't track everything and doesn't know the "network saturation" and (with a lot of effort) that node can also ignore any difficulty update. Sending invalid packets.

  • Bad bootstrap requests and responses
    A light-wallet doesn't bootstrap. It may request some blocks in particular or data of particular accounts (which is bootstrap-calls). It's not similar to the standard bootstrap and can lead to consider that as malicious if there's a lot of accounts, blocks to verify and request. Also, a light-wallet can't reply to any bootstrap request (remember: "request and responses"). Have some field for "light-wallet" doesn't prevent malicious nodes from declaring themselves as "light-wallets".

  • Duplicate data, requests
    A light-wallet may need to request the same data continuously, and not every node needs to retrieve data in real-time. In the end, we can repeatedly ask the same thing, over and over again.

So, banning is an issue, but the big problem comes with we need a "6h of PoW computation" for unban.

2 Likes