Files
ngit-grasp/1f4f-poor-naughty-list-identification.md
T

2.5 KiB

Poor Naughty List Identification

ID: 1f4f

⚠️ COORDINATION REQUIRED: This issue is part of the Administrator Observability and Management Strategy (issue ec1f). Before starting work: Check issue ec1f for current phase, dependencies, and coordination requirements. This issue contributes to Phase 4 (Enforcement) and depends on Phase 3 (blacklist API) completion.

Issue Summary

We need to detect malicious behavior from clients and relays to protect our system from abuse, DoS attacks, and bandwidth exhaustion. This should feed into a reputation system or connection throttling/banning mechanism.

Types of Malicious Behavior to Detect

  1. Invalid signatures:

    • Events with bad/invalid cryptographic signatures
    • Events claiming to be from public keys they don't control
  2. Filter violations:

    • Sending events that don't match requested subscription filters
    • Clients sending EVENT messages when they should only be sending REQ/CLOSE
  3. DoS/Resource exhaustion:

    • Sending large amounts of unrequested data over the websocket
    • Excessive message rates (flooding)
    • Extremely large individual messages
    • Connection spam (rapid connect/disconnect)
  4. Protocol violations:

    • Malformed JSON messages
    • Invalid Nostr message types
    • Messages designed to crash parsers or consume excessive memory

Requirements

  1. Detection mechanisms:

    • Track per-connection metrics (message count, bytes sent, error rate)
    • Identify patterns of abuse vs legitimate heavy usage
    • Differentiate between client errors and malicious intent
  2. Response actions:

    • Warning/throttling for minor infractions
    • Temporary bans for repeated violations
    • Permanent bans for severe malicious behavior
    • Different handling for clients vs relay sync sources
  3. NaughtyList integration:

    • Add malicious relays to NaughtyList when detected via sync
    • Track client connections separately (by IP or connection ID)
    • Persistence across relay restarts

Investigation Tasks

  • Review existing validation in event handling pipeline
  • Check what metrics we currently track per connection
  • Identify all ingress points where abuse could occur
  • Research Nostr relay best practices for abuse prevention
  • Determine appropriate thresholds for rate limiting
  • Review NaughtyList implementation capabilities

Findings

(To be filled in during investigation)

Implementation Plan

(To be determined after investigation)