Planning in Progress
passive P2P network attack and anomaly monitoring
Between July 8 and 13, 2021:
(supported by a Brink grant 🎉)
- vasild, mzumsande, sipa noticed peers triggering the rate limiter during review
- sipa raised the question if this could be related to the bitcointalk post
August 02, 2021:
DSN Research Group (KIT) running Bitcoin Network Monitor noticed this too.
Report: Estimating the Peer Degree of Reachable Peers in the Bitcoin P2P Network
- Active monitoring crashed: couldn't keep up connecting to the fake IPs
- Addresses "distributed uniformly over the IPv4 address space" (including reserved blocks)
addr message last connected timestamp "up to nine minutes into the future"
- An attacker might use this to infer topology of the network:
- number of peers of a node
- other interfaces a node is listening on (IPv6, Onion, ...)
addr flooding only detected by coincidence (?)
- passive monitoring with honeypot nodes
- goal: detecting and alerting on
- issues with
master or RCs
- flow: detect → maybe analyze → maybe react
- dashboard with access for Core Devs?
- historical data recording and data sharing
- use anomaly detection methods?
What to monitor?
- P2P messages: inbound and outbound
- Addrman: changes to tried and new tables
- Connections: opened, closed, peer evictions
- Invalid blocks and transactions (e.g., orphan tx)
- DoS metrics: UTXO cache uncaches, ...
Out of scope:
forks, reorgs, mempool weather
How to monitor?
- primarly, via USDT tracepoints
- semi-stable interface to Bitcoin Core internals
- P2P message tracepoints exist, others are WIP/missing
- don't disclose IP addresses of honeypot nodes
- nodes in different data-centers / hosted by different orgs
- nodes on different networks (non-IP, e.g., Tor, might see more attacks)
- different features enabled on different nodes, e.g., BIP158 block filters
Dissecting P2P messages
addr: time, services, IP, port (addrv2 similar)
reject: message, reason, extra data