<p>This specific <a href="https://arxiv.org/abs/2108.00815v2" rel="nofollow noreferrer">DDoS vulnerability was exploited in 2021</a>, which lead to <a href="https://github.com/bitcoin/bitcoin/pull/22387" rel="nofollow noreferrer">an emergency patch</a>.  PR #22387 is how Bitcoin prevents DDoS, clients running a version older than v22 may still be used to amplify attacks.</p>

CC BY-SA 4.0
2022-07-30T18:02:45.607Z
The causal relationship was more complicated than that: It wasn't an emergency fix against an ongoing attack. The spam only started several days after #22387 was opened, so the patch might have provoked the attack, or maybe it was just coincidence. Also note that AddrMan is designed to be able to cope with spam, even without rate limiting, so it didn't really cause much chaos - most node operators didn't notice the spam at all.
Lightlike
CC BY-SA 4.0
2022-08-01T12:08:16.533Z
@Lightlike The operator was never the victim, and of course, the operator should not be concerned with such attacks.  Suggesting that the node is the victim means that you are missing the point entirely.
Rook
CC BY-SA 4.0
2022-08-01T12:10:08.787Z
@Lightlike also, really?? Bitcoin knowingly propagates known HTTPD's that make their way into an ADDR message? This is underpants on head level crazy.
Rook
CC BY-SA 4.0
2022-08-01T19:20:20.513Z
I was refererring to the spam from 2021 where unknown people spammed the network with randomly distributed IP addresses, presumably with the goal of atttacking the bitcoin network. I was not talking about the scenario you describe in your OP. And of course node operators need to be concerned with such attacks, either because it might affect their ability to find peers, or because they run out of memory, which happened to an alternative implementation. (https://bitcointalk.org/index.php?topic=5348856.msg57469495).
Lightlike
CC BY-SA 4.0
2022-07-29T17:30:28.163Z
2022-07-29T17:30:28.163Z
Rook
<p>For a long time, there was a restriction to strongly prefer connecting to addresses with port 8333. This restriction was recently removed in <a href="https://github.com/bitcoin/bitcoin/pull/23542" rel="nofollow noreferrer">PR 23542</a> and <a href="https://github.com/bitcoin/bitcoin/pull/23306" rel="nofollow noreferrer">PR 23306</a>, although a <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/p2p-bad-ports.md" rel="nofollow noreferrer">list</a> of &quot;bad ports&quot; was introduced that bitcoin core nodes would still avoid to connect to.</p>
<p>If you send an address to a node, it will often save it in the new table of the AddrMan database (if there is no collision with an existing one), but it won't automatically connect to it. That might happen at some later point when they have less than the default 10 outbound connections and therefore need more, or when they make a periodic <a href="https://bitcoin.stackexchange.com/questions/112247/what-is-a-feeler-connection-when-is-it-used">feeler</a> connection. But since addresses are gossiped over the bitcoin network all the time, they will know about thousands of potential peers, so they would connect to a specific address of the victim only with a low probability.</p>
<p>So even if you send a victim's address to all bitcoin nodes, that doesn't mean that they would receive so many connections that it would qualify as a DoS attack.
There has been a rough calculation in <a href="https://github.com/bitcoin/bitcoin/issues/5150#issuecomment-853888909" rel="nofollow noreferrer">this post</a> by vasild, which comes to the conclusion that even in the unrealistic scenario where nodes made new connections all the time, the number of connection attempts the victim would receive would be ~2 per second.
In reality, it should be much less because nodes don't make connections all the time - the victim might get the occasional connection attempt from a bitcoin node, but nothing that would qualify as a DDoS attack.</p>
<p>Also note that your <a href="https://github.com/bitcoin/bitcoin/blob/207a22877330709e4462e6092c265ab55c8653ac/src/addrman.cpp#L396" rel="nofollow noreferrer">verification link</a> from the OP is part  of the <code>AddrMan::Unserialize()</code> function, only used to load saved addresses from the peers.dat file at startup, the function in AddrMan that is executed when receiving addresses from peers is <code>AddrMan::Add()</code>.</p>

CC BY-SA 4.0
2022-07-27T22:34:38.387Z
ah thanks for the details, I am new to the codebase.  Wait... So does the client forward unvalidated addrs?  Also, seeing as i don't see a test case for this I don't see how anyone could know it is "10 connections."  Every nasty bug in prod has an excuse.
Rook
CC BY-SA 4.0
2022-07-27T23:37:24.140Z
Yes, it does forward them (otherwise it would be very hard for nodes new the network to find incoming peers), although with some anti-spam restrictions. There actually was an addr spam attack last year, see this paper by Grundmann et al.: https://arxiv.org/abs/2108.00815v2

The fact that a bitcoin node makes 10 outgoing connections per default (8 full outbound + 2 block-relay-only) is documented in many places, see e.g. https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md
Lightlike
CC BY-SA 4.0
2022-07-29T17:14:50.663Z
Oh cool, my concern was that it was never tested because the design team thought it wasn't exploitable.   Forwarding dead nodes and connecting to 80/443 and not rejecting cross-protocol is a bug, this can and should be fixed.  If it is known to be an HTTPD - then don't forward it.
Rook
CC BY-SA 4.0
2022-07-27T20:36:29.037Z
2022-07-27T22:31:19.797Z
2022-07-27T22:31:19.797Z
Lightlike
<p>If I am not mistaken the mainline bitcoind will accept unsolicited  <code>addr</code> messages, and upon receiving this message - the struct is deserialized, and then <a href="https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L396" rel="nofollow noreferrer">verify each address from the unsolicited sender</a>.  The <code>addr</code> struct allows for up to 1,000 arbitrary <code>addresses:port</code> tuples and there isn't a port restriction... so what exactly is preventing an attacker from flooding the 100k or so Bitciond nodes with the address to some target web servers on 80 and 443?</p>
<p>...To make things more abusable, the client <a href="https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L73-L74" rel="nofollow noreferrer">knowingly accepts information drafted in the future</a>, and will <a href="https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L33-L34" rel="nofollow noreferrer">retry three times</a> regardless of the error - even on a protocol mismatch. This means that flooding a control-plane service like sshd or a vpn or even an entire IP range of services could cause a lot of problems for a target entity with a large network footprint.</p>
<p>A similar issue to this was exploited on the <a href="https://www.iiis.org/cds2009/cd2009sci/SCI2009/PapersPdf/S167TT.pdf" rel="nofollow noreferrer">DC++ network</a>.</p>

<security><network><protocol><attack><p2p>
How does bitcoin prevent DDoS amplification via the `addr` p2p message type?
Rook
# How does bitcoin prevent DDoS amplification via the `addr` p2p message type?

(Asked by: username_0 on 2022-07-27)

If I am not mistaken the mainline bitcoind will accept unsolicited `addr` messages, and upon receiving this message - the struct is deserialized, and then [verify each address from the unsolicited sender](https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L396). The `addr` struct allows for up to 1,000 arbitrary `addresses:port` tuples and there isn't a port restriction... so what exactly is preventing an attacker from flooding the 100k or so Bitciond nodes with the address to some target web servers on 80 and 443?

...To make things more abusable, the client [knowingly accepts information drafted in the future](https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L73-L74), and will [retry three times](https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L33-L34) regardless of the error - even on a protocol mismatch. This means that flooding a control-plane service like sshd or a vpn or even an entire IP range of services could cause a lot of problems for a target entity with a large network footprint.

A similar issue to this was exploited on the [DC++ network](https://www.iiis.org/cds2009/cd2009sci/SCI2009/PapersPdf/S167TT.pdf).

**Tags:** security, network, protocol, attack, p2p


---

## 2 answers

### Answer by username_1 on 2022-07-27. Score: 7 | Accepted answer

For a long time, there was a restriction to strongly prefer connecting to addresses with port 8333. This restriction was recently removed in [PR 23542](https://github.com/bitcoin/bitcoin/pull/23542) and [PR 23306](https://github.com/bitcoin/bitcoin/pull/23306), although a [list](https://github.com/bitcoin/bitcoin/blob/master/doc/p2p-bad-ports.md) of "bad ports" was introduced that bitcoin core nodes would still avoid to connect to.

If you send an address to a node, it will often save it in the new table of the AddrMan database (if there is no collision with an existing one), but it won't automatically connect to it. That might happen at some later point when they have less than the default 10 outbound connections and therefore need more, or when they make a periodic [feeler](https://bitcoin.stackexchange.com/questions/112247/what-is-a-feeler-connection-when-is-it-used) connection. But since addresses are gossiped over the bitcoin network all the time, they will know about thousands of potential peers, so they would connect to a specific address of the victim only with a low probability.

So even if you send a victim's address to all bitcoin nodes, that doesn't mean that they would receive so many connections that it would qualify as a DoS attack.
There has been a rough calculation in [this post](https://github.com/bitcoin/bitcoin/issues/5150#issuecomment-853888909) by vasild, which comes to the conclusion that even in the unrealistic scenario where nodes made new connections all the time, the number of connection attempts the victim would receive would be ~2 per second.
In reality, it should be much less because nodes don't make connections all the time - the victim might get the occasional connection attempt from a bitcoin node, but nothing that would qualify as a DDoS attack.

Also note that your [verification link](https://github.com/bitcoin/bitcoin/blob/207a22877330709e4462e6092c265ab55c8653ac/src/addrman.cpp#L396) from the OP is part of the `AddrMan::Unserialize()` function, only used to load saved addresses from the peers.dat file at startup, the function in AddrMan that is executed when receiving addresses from peers is `AddrMan::Add()`.

> **Comments:**
> **username_0**: ah thanks for the details, I am new to the codebase.  Wait... So does the client forward unvalidated addrs?  Also, seeing as i don't see a test case for this I don't see how anyone could know it is "10 connections."  Every nasty bug in prod has an excuse.  
> **username_1**: Yes, it does forward them (otherwise it would be very hard for nodes new the network to find incoming peers), although with some anti-spam restrictions. There actually was an addr spam attack last year, see this paper by Grundmann et al.: https://arxiv.org/abs/2108.00815v2  The fact that a bitcoin node makes 10 outgoing connections per default (8 full outbound + 2 block-relay-only) is documented in many places, see e.g. https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md  
> **username_0**: Oh cool, my concern was that it was never tested because the design team thought it wasn't exploitable.   Forwarding dead nodes and connecting to 80/443 and not rejecting cross-protocol is a bug, this can and should be fixed.  If it is known to be an HTTPD - then don't forward it.  

---

### Answer by username_0 on 2022-07-29. Score: 1

This specific [DDoS vulnerability was exploited in 2021](https://arxiv.org/abs/2108.00815v2), which lead to [an emergency patch](https://github.com/bitcoin/bitcoin/pull/22387). PR #22387 is how Bitcoin prevents DDoS, clients running a version older than v22 may still be used to amplify attacks.

> **Comments:**
> **username_1**: The causal relationship was more complicated than that: It wasn't an emergency fix against an ongoing attack. The spam only started several days after #22387 was opened, so the patch might have provoked the attack, or maybe it was just coincidence. Also note that AddrMan is designed to be able to cope with spam, even without rate limiting, so it didn't really cause much chaos - most node operators didn't notice the spam at all.  
> **username_0**: @username_1 The operator was never the victim, and of course, the operator should not be concerned with such attacks.  Suggesting that the node is the victim means that you are missing the point entirely.  
> **username_0**: @username_1 also, really?? Bitcoin knowingly propagates known HTTPD's that make their way into an ADDR message? This is underpants on head level crazy.  
> **username_1**: I was refererring to the spam from 2021 where unknown people spammed the network with randomly distributed IP addresses, presumably with the goal of atttacking the bitcoin network. I was not talking about the scenario you describe in your OP. And of course node operators need to be concerned with such attacks, either because it might affect their ability to find peers, or because they run out of memory, which happened to an alternative implementation. (https://bitcointalk.org/index.php?topic=5348856.msg57469495).  

---

