&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21881
Irc2PGuest5995
Irc2PGuest88897
Irc2PGuest95630
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
T3s|4__
aargh2
acetone_
anon2
b3t4f4c3
bak83
boonst
cumlord
dr4wd3_
dr|z3d
eyedeekay
eyedeekay_bnc
hagen_
khb_
not_bob_afk
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
x74a6
mesh
wonderful. For some reason the angry demons have decided to disable my spacebar key
zzz
big burst from that obscuratus-reported router about 2 hours ago
obscuratus
Rather than manually banning routers like this on a onesy-twosy basis, I'm just curious what they're doing, what their use case is. And I'm concerned if we get 10-20 routers like this popping up.
dr|z3d
burst as in hundreds of tunnel requests?
dr|z3d
I saw a very rapid ramp on one router equating to about 4000 part requests in ~10m earlier.
obscuratus
Unless this router is targeting a small subset of routers (which includes us, and is worrisome on it's own) this router must be generation 1000s of particpating tunnels.
dr|z3d
probably that fileshare guy still running a dodgy version using BOB.
dr|z3d
retroshare, that's the one.
zzz
put BuildHandler on WARN and you'll see it as "hop throttle" and "from throttle"
dr|z3d
CyLG seemed to be the offender earlier, maybe.
dr|z3d
I say maybe.. it was about 4-5 times more present in part tunnels at the time of the spike, but it could just have been an innocent recruit.
dr|z3d
the graph here gives a good indication of the scale of the request spikes from earlier -> linuxfarm.i2p/lgstats.html
zzz
that's the one, yes
dr|z3d
ok, it's still top banana for part tunnels on that router.
dr|z3d
i2pd. could it be buggy?
obscuratus
If I had to guess, I'd suspect the service that is using this router rather than i2pd itself.
dr|z3d
ok, this one merits a blacklist.
dr|z3d
> 194.127.199.10 reported as spam20 websites attacked, discovered Sep 11, 2022, last activity Dec 03, 2022 08:00:51.
obscuratus
The IP address for this router has been wander around. Similar to the last router we saw like this.
dr|z3d
looks like dedicated hosting.
dr|z3d
oh, wait. looks like it's a Mullvad VPN ip.
zzz
he was on 193.32.126.233 yesterday
zzz
also 2a03:1b20:1:f410:0:0:0:a18e yesterday; 2a02:20c8:4120:0:0:0:0:a01e today
dr|z3d
so, yeah, mullvad. not much doing I guess other than blocking the router id.
obscuratus
If the consensus is that this router is abusing the service, it may make sense to think about a longer term solution.
obscuratus
When does this kind of behavior transend into the category of "abuse of the service"?
dr|z3d
just adding the hash to blocklist.txt is sufficient I think. it's not like there are 100s of routers out there hammering away at the network :)
dr|z3d
besides, without routers like this to keep an eye on, we'd probably carry on blithely believing everything's cool, honeybun. so it's good to have the occasional outlier that tests the network.
dr|z3d
I just wonder if floodfills couldn't be used to track routers that appear to be misbehaving.
obscuratus
Since this is the second time we've run into this, it makes sense to at least have a policy.
dr|z3d
router is throttled locally, router tells a few floodfills. floodfills query other floodfills and if there's enough of a consensus to indicate misbehavior, floodfills then broadcast to other floodfills "hey, x looks like it's a bad 'un" and routers get told when they talk to a floodfill to temp blocklist said router.
dr|z3d
or you just null route requests for the router's leaseset at the floodfill.
obscuratus
That get's compicated. It would involve ammending the spec for floodfills
dr|z3d
only problem is the scope for abuse. and that's a fairly huge problem if a floodfill goes rogue. :)
obscuratus
To me, a simpler solution would be for routers to track the number of part tunnels requested, and throttle the routers that are 4-5 sigma over the standard deviation.
dr|z3d
well, it's a complicated problem if just manually adding ips and/or hashes to the blocklist file isn't sufficient and you want something automated.
dr|z3d
router already has a throttler.
obscuratus
Excellent! Problem solved!
obscuratus
That throttle would explain something to me.
obscuratus
I've played around with manually banning CyLg, and my part. tunnel count goes down more that I would have expected. But I'm already dropped a lot of tunnels to CyLg directly. Then there's the other pieces of CyLg's tunnels that eventually drop off.
dr|z3d
just add the hash to your ~/.i2p/blocklist file if you want a more perm solution.
dr|z3d
if you want to play with the code, obscuratus, have a look at router/tunnel/pool/ParticipatingThrottler.java
dr|z3d
private static final int MIN_LIMIT = 18 / LIFETIME_PORTION;
dr|z3d
private static final int MAX_LIMIT = 66 / LIFETIME_PORTION;
obscuratus
dr|z3d: Thanks, was just diving into that...
dr|z3d
I've got those limits bumped up so I'm more likely to see spikes on my graphs.
obscuratus
I see some commented out code that auto-bans routers like this. Hhhmmmm...
dr|z3d
yeah, when I last talked to zzz about that, he suggested you want to be careful there as an attacker may be able to get other routers banned.
obscuratus
Makes sense.
dr|z3d
I'm banning routers temporarily, but with a might higher threshold for detection.
dr|z3d
int random = (1 + context.random().nextInt(15) * context.random().nextInt(60)) * 1000;
dr|z3d
int bantime = Math.max(random, (5 + context.random().nextInt(10)) * 60 * 1000);
dr|z3d
s/might/much
dr|z3d
I figured throwing in some random makes it harder for an attacking router to determine when to time their attacks. but I know nothing :)
obscuratus
What's the difference between DROPPING a tunnel request, and REJECT-ing a tunnel request?
dr|z3d
I think that's just semantics, amounts to the same thing. I may be wrong.
zzz
whether you send the request on with the reject code
dr|z3d
ok, so same as iptables then? "go away!" vs silent treatment?
obscuratus
zzz: Thanks.
zzz
reject is polite, drop is less so
zzz
re: solution, it looks like we have throttlers in the right place, and I'm not getting any false positives...
zzz
so in theory we may be able to tighten them down, but I'm not running a very fast router
obscuratus
Yeah, now that I see what the ParticipatingThrottler is doing, it looks like there's much slimmer chance of a bigger problem.
zzz
so the experiment would be to reduce the limits until you get false positives, then back off a bit
zzz
maybe maybe not obscuratus. I don't think we have data to prove the limits are low enough to prevent big problems
zzz
and we can't use data from drz because his limits are higher and he's banning
obscuratus
I'll play around with making those limits configurable. Something that'll let me adjust them on the fly.
zzz
there's two throttlers, Participating and Request; Participating seems to trigger more often
obscuratus
I'm still just curious as heck what this router is doing with this many tunnels. If there's a legitmate use case for this many tunnels (even 1/10th this many tunnels), I can't think of it.
zzz
as drz says it's some rogue sam/bob app, possibly retroshare