Merge pull request 'net: cap inbound connections per address' (#60) from net-per-ip-connlimit into main

2 files changed, 46 insertions, 0 deletions

diff --git a/src/net.cpp b/src/net.cpp
index 3660735..4603d2d 100644
--- a/src/net.cpp
+++ b/src/net.cpp
@@ -1622,12 +1622,41 @@ void ThreadSocketHandler2(void* parg)
                 unsigned int nNodes = 0;
                 CRITICAL_BLOCK(cs_vNodes)
                     nNodes = (unsigned int)vNodes.size();
+                // Also count how many connections this one address already
+                // holds. A single IP that keeps opening sockets -- a broken
+                // node or a deliberate connection-exhaustion flood -- must not
+                // be able to take the whole table, which is what starved the
+                // relays.
+                //
+                // Loopback is exempt. Onion peers reach a managed-Tor node
+                // through its local hidden-service listener, so every one of
+                // them accepts as 127.0.0.1; capping loopback would cap all
+                // inbound onion peers as a single group, which is the opposite
+                // of where the network is headed. The global MAX_CONNECTIONS
+                // still bounds the total, and the direct-IP flood this defends
+                // against never arrives over loopback. (Per-onion-identity
+                // limiting, once a peer's identity is known past accept(), is
+                // the right tool for onion and is left for later.)
+                bool fLoopback = (addr.GetByte(3) == 127);
+                unsigned int nFromThisIP = 0;
+                if (!fLoopback)
+                    CRITICAL_BLOCK(cs_vNodes)
+                        for (vector<CNode*>::iterator it = vNodes.begin(); it != vNodes.end(); ++it)
+                            if ((*it)->addr.ip == addr.ip)
+                                nFromThisIP++;
+
                 if (nNodes >= MAX_CONNECTIONS)
                 {
                     LogPrint("net", "refusing connection from %s, already at %u\n",
                              addr.ToString().c_str(), nNodes);
                     BtfCloseSocket(hSocket);
                 }
+                else if (!fLoopback && nFromThisIP >= MAX_CONNECTIONS_PER_IP)
+                {
+                    LogPrint("net", "refusing connection from %s, already %u from that address\n",
+                             addr.ToString().c_str(), nFromThisIP);
+                    BtfCloseSocket(hSocket);
+                }
                 else
                 {
                     LogPrint("net", "accepted connection from %s\n", addr.ToString().c_str());
diff --git a/src/net.h b/src/net.h
index 984588b..e3d4a93 100644
--- a/src/net.h
+++ b/src/net.h
@@ -112,6 +112,23 @@ static const int          BTF_INCOMPLETE_MESSAGE_TIMEOUT_SECS = 2 * 60;
 // 125 is Bitcoin's number and remains a conservative public-node default.
 static const unsigned int MAX_CONNECTIONS = 125;
 
+// Cap inbound connections from any single address. Without it one source can
+// hold every slot up to MAX_CONNECTIONS -- exactly what happened to the
+// rendezvous relays, where a single IP parked hundreds of connections and
+// starved real peers. A legitimate peer, even a relay talking to a relay,
+// needs only a handful; 32 leaves generous room while denying any one address
+// more than a quarter of the table. The firewall connlimit on the relays does
+// the same thing a layer lower; this makes every build carry the defense.
+//
+// Loopback (127.0.0.0/8) is exempt in the accept path. A managed-Tor node
+// receives every inbound onion peer over its local hidden-service listener, so
+// they all appear as 127.0.0.1 -- capping loopback would cap onion peers as a
+// group, which is exactly wrong for a network moving toward onion-only. The
+// global MAX_CONNECTIONS still bounds the total; a per-onion-identity limit,
+// applied once identity is known after accept(), is the right future tool for
+// onion floods.
+static const unsigned int MAX_CONNECTIONS_PER_IP = 32;
+
 // A node marked for disconnect is normally held until its buffers drain, so
 // a last message still goes out. But vSend cannot drain through a socket
 // whose far end is gone, and that made such a node immortal: it stayed in