* [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets
@ 2021-07-12 23:33 Ali Sherief
2021-07-13 0:54 ` Pieter Wuille
0 siblings, 1 reply; 2+ messages in thread
From: Ali Sherief @ 2021-07-12 23:33 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0
So according to this, somebody is spamming the bitcoin network with addr message pointing to invalid addresses and ports, which bloats the peers.dat and corresponding structure in memory.
Since peers.dat uses a custom record type which I don't know how to parse, I wasn't able to check specifics of IP addresses listed in there, but I believe I have a workaround to prevent this kind of thing from happening. Exactly how easy or difficult it will be to implement this change I don't know.
- Change the AddrDb updating functionality so that it does not add nodes that are unreachable. Not unreachable by timeout, but "connection refused" kind of errors.
Such addresses can either be stored in a new, separate database-like file such as "ignore.dat", or they can be augmented in the peers.dat file under a new entry type (I'm not sure if this is even possible). In both cases the invalid nodes can be immediately flushed from memory to avoid processing them.
-- This is only done the first time the node is seen in the wild. To avoid blocking nodes which happened to go offline, the check won't be made if it's already in the buckets. So it won't clean up an attack like this (meaning peers.dat files have to be recreated to fix this) but it will prevent another in the future.
- In order to facilitate other nodes discovering blocked nodes, a new ZMQ message can be made that sends the node's list of ignored addresses. Since I haven't used ZMQ much I don't know the specifics of how to do this.
- Introduce a new file or command-line/config option called "ignorelist" or something with a list of subnets that will *not* be read into the AddrDB buckets in any case.
It will work differently from the banlist, whose primary job is to block peers that send invalid messages, not peers that are not, and cannot, be unreachable in the first place.
- Ali Sherief
[-- Attachment #2: Type: text/html, Size: 2408 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets
2021-07-12 23:33 [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets Ali Sherief
@ 2021-07-13 0:54 ` Pieter Wuille
0 siblings, 0 replies; 2+ messages in thread
From: Pieter Wuille @ 2021-07-13 0:54 UTC (permalink / raw)
To: Ali Sherief, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
> This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0
>
> So according to this, somebody is spamming the bitcoin network with addr message pointing to invalid addresses and ports, which bloats the peers.dat and corresponding structure in memory.
The peers.dat file and the structure in memory have a fixed size, so those are not a problem.
> Since peers.dat uses a custom record type which I don't know how to parse, I wasn't able to check specifics of IP addresses listed in there, but I believe I have a workaround to prevent this kind of thing from happening. Exactly how easy or difficult it will be to implement this change I don't know.
The "addrman" database is organized into 1024 buckets with "new" addresses (which we haven't tried to connect to), and 256 buckets with "tried" addresses (which we have connected to ourselves). Each bucket consists of 64 positions, and each of those can hold 1 address. Along with the addresses we remember where we originally heard about them (which IP).
Each group of source IPs (/16s etc) selects a subset of just 64 buckets (salted using a host-specific secret key), and inserts the newly received IPs in a position in a bucket in one of those, if certain criteria are met (the position was empty, or it held an IP address that also occurs elsewhere in the table already). This limits the impact an attacker can have, because they cannot under any circumstances affect IPs in buckets outside of the 64 their group maps to.
This database structure is a design from 2012, which was significantly improved following recommendations in the Eclipse Attacks paper (https://cs-people.bu.edu/heilman/eclipse/).
> - Change the AddrDb updating functionality so that it does not add nodes that are unreachable. Not unreachable by timeout, but "connection refused" kind of errors.
In a way we have that; there are separate tables in peers.dat for new and tried addresses. I don't think it's feasible to not add untried addresses at all, as our ability to create connections is far too low to try everything we receive. But I think the existing structure should reasonably protect against spam (in terms of database poisoning; there is certainly a processing cost to it).
Cheers,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 2967 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-07-13 1:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-12 23:33 [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets Ali Sherief
2021-07-13 0:54 ` Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox