Sybil Attack Tool overreacts and hallucinates that attacks are happening #15

New Issue

idk · 2025-04-21T14:58:00-04:00

idk commented

2025-04-21 14:58:00 -04:00

I'm using this issue to document changes in the functionality of the sybil attack tool that I have been experimenting with, and the reasons for them.

Background: during the 2024 netDb attacks, hundreds of thousands(millions?) of routerInfos were published by an attacker which "Cloned" IP addresses and ports which the attacker discovered by analyzing the netDb and harvesting the IP addresses and ports of reachable routers. This caused the Java I2P distribution to misidentify routers as part of a Sybil attack. In response, all IP checks in the Sybil Attack Tool were disabled.

At this time, the only thing the Sybil Attack Tool has the energy to care about is the people who got an old version of Vuze by downloading it from SourceForge(33 versions behind). It is basically impossible to reach the attack threshold without modifying it. This should not necessarily remain the case, in my opinion. Instead, I believe it is possible to reconsider aspects of the Sybil Attack Tool to improve it's capabilities and limit it's ability to hallucinate an attack. This suggestion is based on some hypotheses:

it is useful to know when we are hallucinating
a single indicator of an attack is not likely to be enough to indicate an attack
a single indicator of an attack which manages to indicate an attack is likely to be a false positive
different combinations of multiple attack indicators give information about the nature of the attack

What should we change?

Codify "Reasons" as static constants somewhere and use them instead of strings on the fly and/or the mix of other stuff that we kinda do
Create a mechanism for applying penalties on a "Curve" which approaches a maximum value as penalties accrue
Create a mechanism for applying a fixed maximum to any individual penalty
Store points alongside the reason which they were assigned and change persistence format to match(be backward compatible?)
Assign "weights" to the reasons/points sources used in the tool as parts of a fixed total

Effectively this should render the possible points value a fixed range, perhaps from 0-100, wherein it's only possible to reach the ban threshold if multiple penalties are high. The weights should take into account categories also, as in it should be impossible to reach the ban threshold using only IP-related penalties for instance.

Additional modifications beyond this point are still speculative, and it will be very difficult to test this without a running clone attack.

Related branches:

I'm using this issue to document changes in the functionality of the sybil attack tool that I have been experimenting with, and the reasons for them. Background: during the 2024 netDb attacks, hundreds of thousands(millions?) of routerInfos were published by an attacker which "Cloned" IP addresses and ports which the attacker discovered by analyzing the netDb and harvesting the IP addresses and ports of reachable routers. This caused the Java I2P distribution to misidentify routers as part of a Sybil attack. In response, *all* IP checks in the Sybil Attack Tool were disabled. At this time, the only thing the Sybil Attack Tool has the energy to care about is the people who got an old version of Vuze by downloading it from SourceForge(33 versions behind). It is basically impossible to reach the attack threshold without modifying it. This should not necessarily remain the case, in my opinion. Instead, I believe it is possible to reconsider aspects of the Sybil Attack Tool to improve it's capabilities and limit it's ability to hallucinate an attack. This suggestion is based on some hypotheses: - it is useful to know when we are hallucinating - a single indicator of an attack is not likely to be enough to indicate an attack - a single indicator of an attack which manages to indicate an attack is likely to be a false positive - different combinations of multiple attack indicators give information about the nature of the attack What should we change? - Codify "Reasons" as static constants somewhere and use them instead of strings on the fly and/or the mix of other stuff that we kinda do - Create a mechanism for applying penalties on a "Curve" which approaches a maximum value as penalties accrue - Create a mechanism for applying a fixed maximum to any individual penalty - Store points alongside the reason which they were assigned and change persistence format to match(be backward compatible?) - Assign "weights" to the reasons/points sources used in the tool as parts of a fixed total Effectively this should render the possible points value a fixed range, perhaps from 0-100, wherein it's only possible to reach the ban threshold if *multiple* penalties are high. The weights should take into account categories also, as in it should be impossible to reach the ban threshold using **only** IP-related penalties for instance. Additional modifications beyond this point are still speculative, and it will be **very** difficult to test this without a running clone attack. Related branches: - https://git.idk.i2p/idk/i2p.i2p/-/tree/i2p.i2p-2.7.0-sybil-attack-points-caps?ref_type=heads - https://git.idk.i2p/idk/i2p.i2p/-/tree/i2p.i2p-2.6.0-increase-old-version-penalty-factor?ref_type=heads - https://git.idk.i2p/idk/i2p.i2p/-/tree/i2p.i2p-2.7.0-sybil-index-points-by-reason?ref_type=heads - Combined for testing: https://git.idk.i2p/idk/i2p.i2p/-/tree/i2p.i2p.2.6.0-sybil-IP-penalty-limits-master?ref_type=heads

idk self-assigned this 2025-04-21 14:58:00 -04:00

idk commented

2025-04-21 14:58:01 -04:00

I was actually going to ping you on this later after I have it tidied back up. This would qualify as another one of those "long-term projects" that I might have dropped all at once but I'm trying to change my ways here and split it up into reasonable, reviewable parts that only do one or two things at a time. To answer your questions anyway:

Confused about the term "hallucinate". During the attack, it was a real attack, not hallucinations.

By hallucinations I mean a few things:

the routerInfos were fake in that they did not correspond to real routers

Pretty straightforward. A router under attack "saw" dozens of peers on the same IP address, when in fact there was only one there.

the attacks that the Sybil tool was identifying were not similar to the attacks that were actually happening

Because of the fact that the router saw routers that weren't actually there, Sybil tool mis-identified the nature of the attack. It saw fleets of routers appearing on the same IP address, concludes that someone on that IP address was running a bunch of routers to try and take over multiple hops in somebody's tunnel, and decided to ban them. I think I also referred to this phenomenon as "Threat Inflation." The actual attack could never have affected the network in this way(by tunnel takeover) because the routers were fake, and didn't look like what the Sybil tool saw.

Currently, as you say, it's impossible to reach the threshold, so there are no hallucinations. So you're proposing to fix a problem that doesn't exist?

No, I think that making it impossible to reach the threshold is a different(current) problem, and that threat inflation hallucinations are the one I'm trying to figure out. I'd like to make it possible to reach the ban threshold again, but only if multiple sources of threat points(reasons) contribute to the overall threat point total reaching the threshold. In other words, I want to re-enable IP checks, but I want to make it impossible for the Sybil tool to indicate a Sybil attack using only IP checks, and the total for all IP checks should never be over a specified value, a value which is lower than the minimum threshold for banning routers.

Changing the points system from linear to exponential or to a fixed range doesn't help you implement a 'multiple penalties are high' algorithm. That's orthogonal. So that doesn't make sense. You could do either/or/both but they're independent.

Sure it does? If I can make it so that, for instance, it's only possible to get 30 total points from IP checks, then if the ban threshold is 50, another 20 total points must come from some other indicator or set of indicators. If there is a "hard maximum" on every potential source of threat points, then we can both limit the effect of any individual "hallucination" and decide on how seriously we take any given source of threat points as part of the total.

In fact, I think forcing each individual source of threat points to adhere to a range is a prerequisite for a meaningful definition of a "High" penalty, because right now there is no clearly defined range for most of them, they range from -40(For a verified router family with keys included in the router) to +(the biggest possible double). This is most problematic so far for the IP checks because it's obviously super easy to make the IP checks go through the roof and outweigh anything else in the analysis.

I was actually going to ping you on this later after I have it tidied back up. This would qualify as another one of those "long-term projects" that I might have dropped all at once but I'm trying to change my ways here and split it up into reasonable, reviewable parts that only do one or two things at a time. To answer your questions anyway: > Confused about the term "hallucinate". During the attack, it was a real attack, not hallucinations. By hallucinations I mean a few things: 1. the routerInfos were fake in that they did not correspond to real routers Pretty straightforward. A router under attack "saw" dozens of peers on the same IP address, when in fact there was only one there. 2. the attacks that the Sybil tool was identifying were not similar to the attacks that were actually happening Because of the fact that the router saw routers that weren't actually there, Sybil tool mis-identified the nature of the attack. It saw fleets of routers appearing on the same IP address, concludes that someone on that IP address was running a bunch of routers to try and take over multiple hops in somebody's tunnel, and decided to ban them. I think I also referred to this phenomenon as "Threat Inflation." The *actual* attack could never have affected the network in this way(by tunnel takeover) because the routers were fake, and didn't look like what the Sybil tool saw. > Currently, as you say, it's impossible to reach the threshold, so there are no hallucinations. So you're proposing to fix a problem that doesn't exist? No, I think that making it impossible to reach the threshold is a different(current) problem, and that threat inflation hallucinations are the one I'm trying to figure out. I'd like to make it possible to reach the ban threshold again, but only if multiple sources of threat points(reasons) contribute to the overall threat point total reaching the threshold. In other words, I want to re-enable IP checks, but I want to make it impossible for the Sybil tool to indicate a Sybil attack using *only* IP checks, and the total for *all* IP checks should never be over a specified value, a value which is lower than the minimum threshold for banning routers. > Changing the points system from linear to exponential or to a fixed range doesn't help you implement a 'multiple penalties are high' algorithm. That's orthogonal. So that doesn't make sense. You could do either/or/both but they're independent. Sure it does? If I can make it so that, for instance, it's only possible to get 30 total points from IP checks, then if the ban threshold is 50, another 20 total points must come from some other indicator or set of indicators. If there is a "hard maximum" on every potential source of threat points, then we can both limit the effect of any individual "hallucination" and decide on how seriously we take any given source of threat points as part of the total. In fact, I think forcing each individual source of threat points to adhere to a range is a prerequisite for a meaningful definition of a "High" penalty, because right now there is no clearly defined range for most of them, they range from -40(For a verified router family with keys included in the router) to +(the biggest possible double). This is most problematic so far for the IP checks because it's obviously super easy to make the IP checks go through the roof and outweigh anything else in the analysis.

idk commented

2025-04-21 14:58:01 -04:00

Confused about the term "hallucinate". During the attack, it was a real attack, not hallucinations. Currently, as you say, it's impossible to reach the threshold, so there are no hallucinations. So you're proposing to fix a problem that doesn't exist?

Changing the points system from linear to exponential or to a fixed range doesn't help you implement a 'multiple penalties are high' algorithm. That's orthogonal. So that doesn't make sense. You could do either/or/both but they're independent.

Your 'must have two separate high penalties' is an interesting proposal but not clear what it buys us or why that's better.

As a documentation exercise or first step it may be helpful to write up the current checks/weights/min/max for each check.

Confused about the term "hallucinate". During the attack, it was a real attack, not hallucinations. Currently, as you say, it's impossible to reach the threshold, so there are no hallucinations. So you're proposing to fix a problem that doesn't exist? Changing the points system from linear to exponential or to a fixed range doesn't help you implement a 'multiple penalties are high' algorithm. That's orthogonal. So that doesn't make sense. You could do either/or/both but they're independent. Your 'must have two separate high penalties' is an interesting proposal but not clear what it buys us or why that's better. As a documentation exercise or first step it may be helpful to write up the current checks/weights/min/max for each check.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: I2P_Developers/i2p.i2p#15