mirror of
https://relay.ngit.dev/npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/ngit-grasp.git
synced 2026-10-05 15:08:24 +00:00
68 lines
2.5 KiB
Markdown
68 lines
2.5 KiB
Markdown
# 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)*
|