Rules to manually ban misbehaving peers

gmaxwell

staff

Activity: 4284

Merit: 8808

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.

.anto.

full member

Activity: 179

Merit: 131

Quote from: achow101 on February 25, 2019, 10:12:22 AM

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.

.anto.

full member

Activity: 179

Merit: 131

Quote from: darosior on February 25, 2019, 11:13:03 AM

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.

Quote from: ?? on ??

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

darosior

sr. member

Activity: 279

Merit: 435

Hi,

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

Quote

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

.anto.

full member

Activity: 179

Merit: 131

Quote from: achow101 on February 25, 2019, 10:12:22 AM

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

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.

full member

Activity: 179

Merit: 131

Quote from: .anto. on February 25, 2019, 07:56:39 AM

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.

.anto.

full member

Activity: 179

Merit: 131

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.

Topic: Rules to manually ban misbehaving peers (Read 376 times)