RFC: Introducing Watchdog, a cross-layer anomaly detection module #18987

pull ariard wants to merge 5 commits into bitcoin:master from ariard:2020-05-rfc-watchdog changing 10 files +268 −0
  1. ariard commented at 10:49 am on May 16, 2020: member

    This PR proposes to introduce a new subsystem for anomaly detection and notifications of those for corrective behaviors. It showcases a proof-of-concept laying out the design of such a new system with a new heuristic.

    Prevention of eclipse-attacks and network partitions is critical for application security and user funds. Beyond fork detection and obvious protocol misbehavior, Bitcoin Core doesn’t implement any active anomalies detection. These vulnerabilities may be even more destructive for time-sensitive protocol with harder security assumptions, such as those requiring real-time block processing with regards to honest majority network. Active detection at the base-layer, where it’s easier to monitor, may be used in two ways: a) With an application, like a payment system or a LN node, cutting its deposit flow or closing its channels in reaction or stopping HTLC processing, and therefore limiting exposure. b) With an internal Bitcoin Core module, triggering rescue header-fetching – see the AltNet subsystem proposal as an example of consumer usage.

    Even if notifications must be interpreted according to application requirements, such automatic reactions, well-implemented, would be a positive increase for their security.

    Detection may rely on a wide range of cross-layer heuristics, including the local clock, packets RTT, ASN distribution among addrman, abnormal peer rotation, stalling or delayed block issuance, mempool congestion and bandwidth consumption surges. You may combine heuristics to increase confidence, but due to the p2p nature of the network or Poisson block interval false positives must be taken into account. Ideally consumer would be able to fine-tune their false-positives exposure with regards to application security and the cost of their reaction.

    This PR introduces a new module (CWatchdog), with low-reliance on other modules beyond synchronous events harvesting (LogHeader). Anomalie detections (ScanAnomalie) is scheduled each SCAN_ANOMALIES_INTERVAL on its own thread. Integration is done with NodeContext, making the module accessible to future RPCs. A subscription interface (CWatchdogInterface) is added, the model of CValidationInterface. This can host the actual fork detection in the future after refactoring CheckForkWarningConditions.

    This new module, less intertwined with current code can be disabled by default, and only activated with --enable-watchdog by node operators willingly to use it.

  2. [watchdog] Introduce CWatchdog class
    CWatchdog is a cross-layer anomalies detection module aims to
    cover block issuance, peer management, local clock or net level.
    
    If any anomalie is detected an event is triggered to inform an
    application layer or any internal consumer of a future watchdog
    interface.
    
    This code is only integrated in next commit.
    816f50f4b1
  3. [watchdoginterface] Introduce CWatchdogInterface class
    CWatchdogInterface is consumed by another module or application
    willingly to take corrective actions based on anomalies detected.
    
    CWatchdogInterface only callback is BlockHeaderAnomalies, meaning
    block header aren't received at a normal rate modulo block variance.
    14c392ae08
  4. [init] Integrate CWatchdog and its interface in init sequence
    CWatchdog is integrated in NodeContext to make it accessible to any
    futute rpc calls. Some application may fine-tune watchdog according
    to their requirements.
    
    This code is not scheduled yet.
    fcafe5787f
  5. [scheduler] Schedule ScanAnomalies every 60min
    Run ScanAnomalies to process any heuristics and trigger watchdog
    interface callback.
    
    As of present commit, there is no heuristic implemented, callback
    is blankly called to exerce watchdog interface.
    7dd1b22b6f
  6. [net] Integrate CWatchdog in CConman
    Insert watchdog LogHeader after a successful ProcessNewBlockHeaders,
    therefore updating last time watchdog have seen a step forward
    on headers tree construction.
    
    Watchdog loggers should be designed on being invasive-minimal at they
    may encumber hot paths.
    7d0e7c9884
  7. DrahtBot added the label Build system on May 16, 2020
  8. DrahtBot added the label P2P on May 16, 2020
  9. DrahtBot commented at 5:54 pm on May 16, 2020: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #18354 (Protect wallet by using shared pointers by bvbfan)
    • #15367 (feature: Added ability for users to add a startup command by benthecarman)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  10. DrahtBot commented at 12:05 pm on May 23, 2020: member

    🐙 This pull request conflicts with the target branch and needs rebase.

  11. DrahtBot added the label Needs rebase on May 23, 2020
  12. 0xB10C commented at 1:33 pm on August 3, 2021: member

    I haven’t looked at this PR closer, but I think anomaly detection could be done via USDT in an external application hooking into Bitcoin Core internals too.

    bandwidth consumption surges

    This could be done with the net tracepoints for inbound / outbound P2P messages. See this example https://bitcoind.observer/p2p-network-traffic and code https://github.com/0xB10C/bitcoind-observer.

    Prevention of eclipse-attacks, ASN distribution among addrman

    I’ve added a few tracepoints (not in a PR yet) to addrman to externally observe the new and tried tables too. See e.g. this realtime visualization (colors are addr type here, but could also be AS based) of my addrman tables:

    image

    Let if you think this might be an alternative to a module in Bitcoin Core. Happy to chat.

  13. ariard commented at 0:50 am on August 4, 2021: member

    Honestly, I’ve not been that far in the design of a specific hook interface servicing watchdog/statistical tools.

    This PoC was relying on a CWatchdogInterface inspired from the current CValidationInterface. Though one of the prevailing feedback I received with this proposal was that it would be far better to have the module separated in another runtime, and even external to Bitcoin Core internals or build system. Thus letting any module to be plugged in.

    One solution I’m working on is pursuing on the work done by multiprocess with the newly introduced abstract interfaces (src/interfaces), where your potential external modules could be written in Rust to talk directly to core C++ code through Cap’n Proto or in the future another protocol (fyi, see https://github.com/chaincodelabs/libmultiprocess/issues/56).

    Of course, w.r.t to event collection, the USDT approach you’re proposing sounds the right tool. One could imagine a watchdog module where the low-level event collection is gathered through tracing and the high-level corrective logic relying on a *.capnp interface, all bundled in the same runtime.

    This could be done with the net tracepoints for inbound / outbound P2P messages. See this example https://bitcoind.observer/p2p-network-traffic and code https://github.com/0xB10C/bitcoind-observer.

    I need to think more, but I think tracepoints could cover the whole range of proposed heuristics: local clock, packets RTT, peer rotation frequency, mempool feerate groups, … ?

    Let if you think this might be an alternative to a module in Bitcoin Core. Happy to chat.

    First impression, I think this tracepoint approach is far better than yet-another-non-critical-module in core for sure. Yeah happy to chat, on this PR, a new issue or irc :)

  14. DrahtBot commented at 12:29 pm on December 22, 2021: member
    • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
    • Is it no longer relevant? ➡️ Please close.
    • Did the author lose interest or time to work on this? ➡️ Please close it and mark it ‘Up for grabs’ with the label, so that it can be picked up in the future.
  15. MarcoFalke commented at 2:12 pm on April 29, 2022: member
    Closing for now. Let us know when this should be reopened.
  16. MarcoFalke closed this on Apr 29, 2022

  17. MarcoFalke deleted a comment on Apr 29, 2022
  18. DrahtBot locked this on Apr 29, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 09:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me