docs(prd): add PRD 0013 — Make attacks expensive instead of blocking them - #62
Merged
Conversation
…them Blocking has a tell: an attacker whose connection is refused learns immediately that they were detected and rotates address, which on a botnet costs nothing. Slowing them instead inverts the economics — a connection held open for thirty seconds costs the attacker a worker, a socket and a timeout, while costing the defender almost nothing. Against a scanner working a list, slow is worse than closed: closed is a fast negative, slow ties up capacity and yields nothing. It also fills a real gap as a MIDDLE response, useful exactly where confidence is moderate and blocking would risk collateral damage. The defining hazard is self-inflicted denial of service: a tar-pit costing a thread and a descriptor per attacker has simply moved the DoS to the defender. Hence a hard concurrency ceiling and a non-blocking implementation as P0 requirements rather than tuning, and an open question about auto-disabling under a real flood, where holding connections open is precisely what the attacker wants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Specification for the
tar-pitcore module, listed inPRD.mdand not yet specified.Blocking has a tell: an attacker whose connection is refused learns immediately that they were detected and rotates address, which on a botnet costs nothing. Slowing them instead inverts the economics — a connection held open for thirty seconds costs the attacker a worker, a socket and a timeout, while costing the defender almost nothing. Against a scanner working a list, slow is worse than closed: closed is a fast negative, slow ties up capacity and yields nothing.
It also fills a real gap as a MIDDLE response, useful exactly where confidence is moderate and blocking would risk collateral damage.
The defining hazard is self-inflicted denial of service: a tar-pit costing a thread and a descriptor per attacker has simply moved the DoS to the defender. Hence a hard concurrency ceiling and a non-blocking implementation as P0 requirements rather than tuning, and an open question about auto-disabling under a real flood, where holding connections open is precisely what the attacker wants.
Spec only — no implementation in this PR.