Rules to manually ban misbehaving peers

[.anto.]

It happened once that a peer chocked the eth0 interface of my full node, because I forgot to add the hashlimit rule on my iptables to limit the outgoing traffic per peer to 1 Mbps. That peer kept continuously downloading blocks from my full node for more than 10 GB within an hour. That made even SSH session to my full node very slow. Everything went fine after I manually banned that peer.

Last week, I found a peer got banned by my script because of it kept downloading blocks for up to 6 GB within an hour. The ban score of the peers increased by 1 if they keep continuously downloading blocks up to 1 GB every 10 minutes. My script bans a peer that has a ban score more than 5 or continuously downloading up to 6 GB within a hour.

Perhaps I need to tighten the ban criteria, but I am afraid that I will ban legitimate peers. However, when I observe the behaviour of the bitcoin-qt on my PC in which my full node is its prefer peer,  it only downloads a few hundreds MB within an hour even after I didn't launch it for a week. So it does not keep downloading all blocks that it needs from my full node the whole time, as it also downloads some blocks from its other outgoing peers.

Do any of you know why peers keep continuously downloading blocks like that? Are they legitimate peers?

What are actually the criteria of illegitimate peers applied in bitcoin software, apart from the strange versions that they advertise and anything related to the obvious like that?

Thanks a lot in advance.

[1714824853]

1714824853

[.anto.]

Last week, I found a peer got banned by my script because of it kept downloading blocks for up to 6 GB within an hour. The ban score of the peers increased by 1 if they keep continuously downloading blocks up to 1 GB every 10 minutes. My script bans a peer that has a ban score more than 5 or continuously downloading up to 6 GB within a hour.

In case you are wondering how could this happen, last week I set more relax hashlimit rule on my iptables to observe the behaviour of my full node's peers. I saw there were a lot more packets being dropped by my iptables than accepted. So I set the outgoing traffic per peer to 16 Mbps (--hashlimit-upto 2000kb/s). At the moment, I have the hashlimit-upto set to 250kb/s (2 Mbps), so the maximum traffic for each peers in an hour when they are continuously downloading blocks will only be about 900 MB.

I kept playing with the hashlimit rule as I am not sure what is the best setting for both protecting my full node and satisfying legitimate peers. With the current setting, the legitimate peers which have 100 Mbps link (like my bitcoin-qt), will have to wait a lot longer time to download the blocks they need.

[achow101]

Why do you think those peers are malicious? The blockchain is over 150 GB. Those peers are probably syncing the blockchain.

Bitcoin Core does not think those peers are malicious, otherwise it would have disconnected and banned them itself. It has its own ban criteria which is much more than just bandwidth usage and strange versions (the version isn't even a criteria). This criteria includes things like receiving invalid blocks and transactions, receiving a lot of malformed messages, etc. Downloading a lot of blocks is not evidence of malicious behavior.

[.anto.]

Why do you think those peers are malicious? The blockchain is over 150 GB. Those peers are probably syncing the blockchain.

Well... I am not sure myself, that is why I asked the question.

Unfortunately that happens very rare, not even once a month I got a peer which is continuously downloading blocks in the order above 10 GB within an hour. So I cannot make any good conclusion.

What I notice is that, normal peers do not behave like that. And I don't usually manually ban peers with version above 0.15.x and services=0x40d.

[darosior]

Hi,

You might want to consider using the `-maxuploadtarget` option. From the wiki :

Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit (default: 0)

[.anto.]

You might want to consider using the `-maxuploadtarget` option. From the wiki :

Thanks for your suggestion but maxuploadtarget only helps people with limited traffic quota. It helps to maintain the traffic quota below the figure set by the ISP. It will not help us preventing our network interface from being saturated on uplink by the peers with much higher downlink bandwidth capabilities, e.g. in Gbps level.

How about 80:20 rule (or sometimes called Parreto rules)? It's good option for managing bandwidth.

Obviously 80% goes to your full nodes and you need to measure maximum/average bandwidth first.

I have already tried to implement that 80:20 rule before with tc HTB qdisc, so 80% bitcoin traffic and 20% other traffic. But since I have only 100 Mbps on uplink, that makes me have only 80 Mbps for bitcoin traffic. As soon as a peer with much higher downlink capability occupies the whole bandwidth, my full node could not serve the requests from other peers.

I could indeed add more classes on the HTB for each peer. But my traffic shaper will become more complex as the peers can very dynamically come and go anytime. So I think I will stick with a simple hashlimit on my iptable to limit the uplink traffic to 2 Mbps per IP:port pair of the peers. From what I observed, a peer some times have multiple connections with the same IP address to my full node.

As of my writing, there is a peer which has been downloading blocks from my full node for more than 3 hours.

Its status when it was downloading the blocks for about 30 minutes is as below (that peer is the first one on the list).



And about 2.5 hours later, it was still downloading up to about 2.8 GB as below



As it seems to provide full service (services = 0x40d) and it looks like legitimate /Satoshi:0.17.1/, I let it keep downloading blocks as it is harmless anyway to other peers as it can only download with the speed below 2 Mbps (thanks to iptables hashlimit) as shown on some parts of iftop output below.

Code:

    => 216.21.162.208:35166                                                                         1.98Mb  1.95Mb  1.85Mb
   => 150.109.74.119:39375                                                                         20.5Kb  4.09Kb  2.59Kb
   => 84.26.108.54:8333                                                                               0b   3.71Kb  3.22Kb
   => 88.25.100.45:63935                                                                           14.1Kb  3.17Kb  1.67Kb
   => 185.25.224.202:8333                                                                          8.45Kb  3.16Kb  2.79Kb
   => 88.99.186.25:50854                                                                           11.0Kb  2.62Kb  2.11Kb
   => [2a01:4f8:141:4d7::2]:8333                                                                   2.16Kb  2.45Kb  1.96Kb
   => [2a03:b0c0:2:d0::4bc:2001]:38160                                                             10.7Kb  2.34Kb  1.81Kb
   => [2a01:4f8:10a:37ee::2]:25424                                                                 10.7Kb  2.30Kb  1.71Kb
   => 158.109.79.23:55301                                                                          10.4Kb  2.23Kb  1.66Kb
   => 188.166.69.73:45169                                                                          10.4Kb  2.23Kb  1.72Kb
   => 129.13.88.177:59646                                                                          10.4Kb  2.23Kb  1.66Kb
   => [2a04:3544:1000:1510:b08f:6fff:fe1b:3007]:55612                                              10.7Kb  2.15Kb  1.76Kb
   => [2a00:1398:4:2a00::a5]:42533                                                                 10.7Kb  2.15Kb  1.73Kb
   => [2a00:1398:4:2a01::78]:35724                                                                 10.7Kb  2.15Kb  1.71Kb
   => [2a00:1398:4:2a01::77]:44310                                                                 10.7Kb  2.15Kb  1.63Kb
   => 150.109.74.119:45717                                                                         10.4Kb  2.09Kb  2.10Kb
   => 23.92.36.2:56913                                                                             10.4Kb  2.09Kb  1.67Kb
   => 94.237.44.67:48927                                                                           10.4Kb  2.09Kb  1.66Kb
   => 129.13.252.36:55358                                                                          10.4Kb  2.09Kb  1.66Kb
   => 88.99.167.186:14287                                                                          10.4Kb  2.09Kb  1.59Kb
   => 162.218.65.27:53265                                                                          10.4Kb  2.09Kb  1.59Kb
   => 129.13.88.175:58702                                                                          10.4Kb  2.09Kb  1.59Kb
   => 188.65.213.21:49201                                                                          10.4Kb  2.09Kb  1.59Kb
   => 162.218.65.53:13354                                                                          10.4Kb  2.09Kb  1.59Kb
   => 162.218.65.236:10183                                                                         10.4Kb  2.09Kb  1.59Kb
   => 183.205.191.79:22241                                                                         6.82Kb  1.84Kb  1.18Kb
   => [2001:41d0:2:af72::1]:8333                                                                   1.50Kb  1.75Kb  1.21Kb
   => 185.53.156.255:50501                                                                         6.16Kb  1.58Kb  1.66Kb
   => 13.209.125.83:8333                                                                            208b   1.36Kb  1.39Kb
   => [2a02:8388:2282:f900:e29d:31ff:fe26:2628]:50256                                              2.59Kb  1.29Kb  2.01Kb
   => 162.209.88.174:8333                                                                          1.82Kb  1.26Kb  1.63Kb
   => 47.6.34.160:8333                                                                             1.13Kb  1.24Kb  1.33Kb
   => 94.237.44.67:35799                                                                           3.49Kb  1.02Kb   524b
   => 158.109.79.23:61545                                                                             0b   0.98Kb   500b
   => 80.110.127.178:9282                                                                          1.05Kb   943b    854b
   => 84.73.200.108:8333                                                                            804b    526b   1.68Kb
   => 185.220.101.66:39843                                                                         2.23Kb   520b   2.15Kb
   => 59.110.8.18:34358                                                                             864b    173b     86b
   => 59.110.8.18:33241                                                                               0b    173b     86b
   => 59.110.8.18:58310                                                                               0b      0b     86b
   => 129.13.88.178:43591                                                                             0b      0b      0b
   => 129.13.72.197:43591                                                                             0b      0b      0b

[.anto.]

Why do you think those peers are malicious? The blockchain is over 150 GB. Those peers are probably syncing the blockchain.

Bitcoin Core does not think those peers are malicious, otherwise it would have disconnected and banned them itself. It has its own ban criteria which is much more than just bandwidth usage and strange versions (the version isn't even a criteria). This criteria includes things like receiving invalid blocks and transactions, receiving a lot of malformed messages, etc. Downloading a lot of blocks is not evidence of malicious behavior.

Are you sure that the version is not a criteria being used by bitcoind to automatically ban the peer?

What do you think about a node which was banned by mine this morning shown below?

The list of banned peers on my node with that particular node being highlighted.




The detail of that node on https://bitnodes.earn.com/ with the version being highlighted.

[gmaxwell]

The behaviour you are describing is the perfectly normal behaviour of a new node coming online.

No, the version string is not used to ban peers, in fact taking any programmatic action on it is expressly specified as "strongly unrecommended and extremely bad form."

Your version string example is probably some brain damaged scamcoin client which failed to change the port and protocol magic and it probably got banned for sending invalid blocks.