Skip to content

multi: add ban manager#3

Open
dnldd wants to merge 6 commits intobisoncraft:masterfrom
dnldd:ban_manager
Open

multi: add ban manager#3
dnldd wants to merge 6 commits intobisoncraft:masterfrom
dnldd:ban_manager

Conversation

@dnldd
Copy link
Contributor

@dnldd dnldd commented Feb 5, 2026

This implements a ban manager that tracks client ips and their associated infractions. Associated tests have been added.

This implements a ban manager that tracks client ips and their associated infractions. Associated tests have been added.
This adds a broadcast rate limiter for clients to control frequency of broadcasts made by clients.
This updates tatanka handlers to punish clients sending malformed messages, spamming broadcasts or impersonating nodes by posting to
restricted topics like the clients ban and oracle topics. Unauthorized errors now propagate to the client to terminate it.
This restructures infractions by gossiping infractions immediately to the mesh, this way mesh nodes keep an equivalent infractions dataset.
Also connecting nodes on startup request for an infraction snapshot, via the infractions snapshot protocol, from one of the mesh nodes
picked at random. The ban manager ensures infractions are deduplicated by checking if an infraction key exists for an infraction or not.
Associated tests have been updated accordingly and an integration test for new nodes joining a mesh and requesting an infraction snapshot
has been added.
This updates client message publishing to return a response in order to be notified of infractions when publishing messages.
The check prevented clients from publishing messages with topic names
starting with "client_infractions", but this was defensive without
real security benefit.

Real infractions use clientInfractionsTopic (whitelist-only, node-to-node).
Clients cannot access the whitelist-only topic (peerFilter blocks non-whitelist
peers). If a client publishes topic="client_infractions" to clientMessageTopic,
it's just a normal broadcast with no effect on the ban system. Infractions are
never sent to clients, so spoofing has no impact.

This differs from the oracle topic check (retained), where clients actually
receive oracle data and could be misled by spoofed messages if the Sender
field is not validated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant