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)
zzz
so
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
so?
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
orignal
ofc
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
true
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
weko
+
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