IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/02/07
dr|z3d orignal: except whoever they are hasn't switched over to ssu, at least not entirely.
dr|z3d the ntcp attack is still ongoing.
orignal yes, but also many SSU
orignal NfR routers
dr|z3d parallel attack, then.
orignal no. I thin i2pd and Java
dr|z3d nothing about 10K banned routers suggests ntcp attack has run its course.
orignal Tunnel creation success rate: 46%
orignal ha ha
dr|z3d snap.
orignal Floodfills: 1477
orignal I have found a way to clear them ))
dr|z3d 46% exactly build success on the router I'm looking at.
orignal but don't want to tell here for obvious reason
dr|z3d 10K banned routers loading on a java console page, not the best experience :|
obscuratus The attack may be subsiding (for now), my router has also cleared the extraneous routers, but I haven't done anything to clear them.
orignal maybe
orignal but I was not a floodfill
dr|z3d 10h uptime, ~16K banned NTCP-only FFs.
obscuratus hexcellent, the attack is back on!
zzz extra salt for breakfast this morning
dr|z3d what dis one? 37.228.88.201
dr|z3d whatever it is, it's looking super dodgy from here right now.
dr|z3d_ ah, salt.
dr|z3d_ now I get the reference. doctored RIs..
dr|z3d Capabilities: Xfsalt
dr|z3d did that ip I posted earlier hit the channel? about 20m ago..
orignal zzz my approach works well
orignal with this new stuff ))
orignal attack is back on but not for me ))
dr|z3d seeing a bunch of: Corrupt fragment received [Offset: 742] (Null Pointer Exception)
zzz as usual, figure it out, either fix or reproduce on canon
dr|z3d_ as much as I know you want to pin every bug on me, zzz, I doubt that's mine :)
zzz orignal's theory wins, at least some of them are real, I'm connected outbound to several
zzz sure dr|z3d_ but it has to be this way
zzz sure dr|z3d_ but it has to be this way
orignal dr|z3d do you need my patch?
orignal you don't need the code just a explanation what to do
dr|z3d orignal: don't mind taking a look at what you gone and done :)
orignal in PM
dr|z3d wouldn't say I need it, however, my mitigations are working pretty well, but I'm a mere novice in the scheme of things :)
dr|z3d thanks.
zzz ad hoc short-term identification and banning is fine if you're dead in the water, but...
zzz sybil tool is also catching a lot on some of my routers but not others, which is complicating/masking things as well
dr|z3d sure, short term mitigations are by definition short term. but they're not entirely useless.. what remains is arguably more interesting than what generalized mitigations catch.
zzz they may be helpful for some people but would actively get in the way of my R&D
dr|z3d you do your thing, wouldn't want to interfere with that :)
zzz sure, go block salt caps and 0.9.58 routers, that might buy you or your users a couple hours, but I can't go down that road
dr|z3d wouldn't expect anything less. :)
zzz and as for NPEs, they're about the easiest possible class of bugs to find and fix, and I know you have lots of experience :)
dr|z3d if the exploit du jour is seeding out thousands of bogus ff RIs into the network, the fix is presumably fairly easy, conceptually speaking. validate the ips before talking to the routers, or ban if validation fails.
zzz ok he turned off the 0.9.58 routers and they've all expired out
zzz at least my graphs will now add up to 100% again
zzz dr|z3d, at least some of them are real, as I said above, I was connected to them. I don't know if they all are (or were)
zzz and the salts are all gone too
dr|z3d yeah, that tallies with what I'm seeing.
dr|z3d did you get the ip I posted earlier? if not, can pm. interesting one.
zzz no time to chase IPs
dr|z3d ok. 1/2 dozen RIs one of my netdbs, all same ip/port.
dr|z3d origin: moscow.
zzz could be prestium
dr|z3d all Xf, poor to zero lookup success.
zzz but I guess port would change
dr|z3d prestium is likely firewalled too, no?
dr|z3d salt's not gone.
dr|z3d salty routers running on 0.9.57 and .58 here that I can see.
zzz could be different expirations, or different blocks/bans, hard to get a consistent view
zzz but let me boil it down really simple
zzz where we're at yesterday vs. today
zzz yesterday: two theories:
zzz 1) lots of real routers all over
zzz 2) lots of fake RIs being sprayed into the net, possibly from a single source
zzz today:
zzz 1) is proven
zzz 2) is still unconfirmed, but could be a possible 2nd attack. However, unlikely to come from a single source given 1)
orignal My theory is that "salt" is difefernt attack than the main one
zzz there's little reason to go hunting for a single source of 2)
zzz the priority is to fix 1) which is proven
orignal and what will it tell you?
orignal say you prove it comes from 37.228.88.201
zzz right, waste of time to "find the single IP"
orignal e.g. you prove that it was Plaz
orignal will he stop doing it? no
zzz agreed
zzz fix the problems 1) is causing
obscuratus Or, I guess, rather pass them on to the closer DHT peer, then ploink them.
orignal LeaseSets: 3
orignal interesting to see it on non-FF router
dr|z3d zzz: +v for not_bob please.
not_bob Thank you
zzz welcome
orignal any updates?
orignal salt said we will be regretting soon ))))
zzz fun times
dr|z3d obscuratus: I'm already grading RIs based on an "interesting" quotient. slow/unreachable peer RIs get dropped a lot sooner, and peers with those caps don't get profiled.
dr|z3d uninteresting peer RIs also stay in ram only, so are expunged at the end of the router session.
not_bob I'm using dr|z3d's latest dev build and that router fucntions much better than the rest of my fleet. 40% tunnel build succcess vs around 10% for my i2pd routers.
zzz all a losing battle when all the salt is interesting
zzz I'm going to spend the next couple days landing simple mitigations
zzz don't hold breath for any clever recommendations
zzz as most of my ideas were w.r.t. fake routers, not real ones
not_bob Are there any sorts of sanity checks that can be performed on new routers to verify they work before added?
dr|z3d no harm in mitigating against fake routers. this won't be the last time we seem them.
orignal yes weko has this idea
orignal don't consider a new router as as FF until you connect to it al leat once
orignal I like this approach
not_bob That would work well I suspect.
weko Decrease chance for connect to 1/10 for example
orignal if you are floodfill you connect to all other floodfills frequetly
orignal so we have a profile for FF
orignal if we receive one from a reseed we enable it instatly
orignal otherwise try to connect and only that include it to reponses and flood
zzz you don't need a direct connect, just a response to a lookup or store
weko zzz: also
zzz which is essentially what java does now
weko Any prove what it is legal floodfill
weko Proof*
orignal might be trough a tunnel
orignal zzz really?
orignal I didn't know it
weko But I guess detect it with destinations can have deanonimity risks...
orignal I will do the same
weko Don't know sure. Just guess.
dr|z3d we have floodfill profiling, orignal.
dr|z3d good, ok, dogshit.
orignal yes, I'm going to implement
orignal but I didn't know you wait
dr|z3d we prefer good over the bad, but in the event of no profiles, anything goes.
weko [22:43:04] <dr|z3d> we have floodfill profiling, orignal.
weko Have you same feature?
zzz yeah we don't declare a ff to be non-ff, but we kinda, more or less, sort them into good/ok/bad based on the profile
orignal and that's wrong
weko zzz: it is very slow process while attack
orignal weko's idea to not use a FF until we know it's good
orignal LeaseSets: 20
orignal new attack?
weko orignal: on non FFs?
weko I think it is
orignal number of leasesets keep groing on my non-FF router
orignal and it never been a FF
orignal zzz the question is
orignal if you flood new floodfills once you receive them
zzz don't store LS on non-ff
orignal no, you receive new FF on your FF, do you flood it?
zzz sure, following the usual rules
orignal maybe we put it hold
orignal should
orignal until we have proof it's good
weko But we need verify what it is real FF, for prevent spamming with fake RIs
orignal non-FF RIs are fine
orignal who cares?
zzz guys it's meeting time over in #i2p-dev so I will be over there for an hour
weko orignal: it is interesting
weko Maybe attacker found new type of attacks
weko Or just trying
orignal no problem
orignal will talk later
weko orignal: so, we should reject LS store request if we not a floodfill
weko Yes
weko But not reject if we setup floodfill in config but have non OK status
weko For prevent problems
weko With status
weko As I had