Establish metrics and a process to ban malicious nodes

[Srayman]

If a node starts interacting with the network in malicious ways there should be a mechanism by which other nodes automatically block it from the network. Could be permanently or for a period of time. Bitcoin does something similar by banning "misbehaving" nodes. See the following https://github.com/bitcoin/bitcoin/blob/52b9797119d5ee20b255efc68931ac7e158e325d/src/net_processing.cpp#L964

Could something similar be implemented in nano to track metrics like invalid blocks, headers, etc to score a node for how many times it has communicated in a way that would be considered either malicious or unwanted to the network to prevent it from causing additional problems later.

[qwahzi]

I wonder how many of Bitcoin's other client protections could also be adapted to Nano?

Sending lots of data to a node may make it so busy it cannot process normal Bitcoin transactions. Bitcoin has some denial-of-service prevention built-in, but is likely still vulnerable to more sophisticated denial-of-service attacks.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

• Does not forward orphan transactions/blocks

• Does not forward double-spend transactions

• Does not forward the same block, transaction or alert twice to the same peer.

• Continuous rate-limit of free transactions to mitigate 'penny-flooding'

• Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.

• Bans IP addresses that misbehave for a time lapse (24 hours default)

• Limits the number of stored orphan transactions (10000 by default)

• Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)

• Limits the number of stored signatures in the signature cache (50000 signatures by default)

• Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.

• Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.

• In orphan/signature caches, when removing an item, evicts a random entry.

• Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker that result in exponential complexity.

• Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.

• In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.

• In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.

• In GUI: Limits URI length to prevent a DoS against the QR-Code dialog

• Considers non-standard signature scripts with size greater than 500 bytes.

• Considers non-standard signature scripts that contain operations that are not PUSHs.

• Does not forward nor process non-standard transactions

These are protocol rules built to prevent DoS:

• Restricts the block size to 1 megabyte.

• Restricts the maximum number of signature checks a transaction input may request

• Limits the size of each script (up to 10000 bytes)

• Limits the size of each value pushed while evaluating a a script (up to 520 bytes)

• Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional > operation.

• Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)

• Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)

• Limits the number of signature checks a block may request (up to 20000 checks)

These are the Satoshi client protections added in version 0.8.0:

• Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).

• Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.

• When processing a transaction, before fetching transaction inputs from disk to memory, the client checks that all the inputs are unspent (protects from the Continuous Hard Disk Seek/Read Activity (https://bitcointalk.org/> index.php?topic=144122.0) DoS attack)

Satoshi client does not directly limit peer bandwidth nor CPU usage.

https://en.bitcoin.it/wiki/Weaknesses#Might_be_a_problem

[zhyatt]

Adding in the forum discussion around this for additional context: https://forum.nano.org/t/systematic-process-to-ban-malicious-nodes/109. We are looking to do some research and prep work around this during the V21 development period and possibly include some malicious node handling in V22+. If any additional research has already been done, please provide details here or in the forum discussion to help guide efforts.

[qwahzi]

For future readers:

In our pursuit of increasing DoS resistance, we're drafting a peer rating system. This system will identify and manage peers that display irregular behaviours, such as sending improperly signed messages or excessively flooding the network. While the specifics are still under consideration, this measure aims to maintain network health by potentially limiting or temporarily isolating such non-compliant peers.

https://nano.org/en/blog/progress-toward-achieving-commercial-grade--49e975d8

[ATXMJ]

In addition to the above discussion, could a local rep blacklist defined by each node (not through consensus) be a relatively simple decentralized mechanism for "forking" adversarial reps from the network? This list could be made publicly viewable to allow for community services to monitor which reps are being blacklisted by others as a way to monitor for potential adversarial rep behavior.

This would all be in addition to, or as a holdover until, any other automated peer rating/blacklisting system can be devised.

Would love to hear general thoughts or concerns on this concept.

[dsiganos]

Yes, that feature should exist really. The trouble is currently no reliable to identify a node but we could at least have a blacklist of ip addresses. In the past, when we identified IP addresses that were malicious, we blocked their IP addresses at the operating system level but having a such a list at the node config level would make things easier to coordinate.

[ATXMJ]

The trouble is currently no reliable to identify a node but we could at least have a blacklist of ip addresses.

Would a local blacklist allowing blocking of either/both IP & rep address not be a reasonable short-term solution?

I'm aware that the adversarial rep could just change addresses and/or IP, but it would at least create some friction for continued malicious behavior, with minimal effort needed from honest rep admins.

[dsiganos]

Issue for blacklisting IP addresses:
#4366