eyedeekay
Re: CCS proposal yes I think we could, re: domain sockets I was actually working on that one of those piles I mentioned but I was going to start with i2pcontrol because it seemed simpler
StormyCloud
Its not much but I can donate 2XMR to the cause
dr|z3d
StormyCloud: I don't think you need to, Monero are offering the bounties as I understand it.
zzz
eyedeekay, here's a start, edit as you please stats.i2p/docs/monero-i2p-sam.md
zzz
eche|off, eche|on, ping re: XMR
orignal
zzz, if we receive completelky different SessionRequest and found out that we have a session with that router already what wqe do?
orignal
SSU2
orignal
looks like we see router multihoming in the netwrok
zzz
orignal, what we do, same as ssu1: drop the old session, we assume we didn't get the disconnect for the old one
orignal
so drop old one
orignal
the problem is it seems they come from different routers with same I2P address
orignal
e.g. multhoming
zzz
like via tor or a vpn?
orignal
not sure
zzz
the reason code for the old session disconnect is 22 "replaced by new session" - see spec
orignal
from different IPs
zzz
there's some site you can check if it's tor, I think dr|z3d knows how to do it
orignal
yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=
zzz
how long is the old session idle for when the new one comes in?
orignal
plenty of connections
orignal
they are not idleing they are all active
orignal
that's the problem
zzz
active as in last second? last minute?
zzz
how many IPs per hour or day?
orignal
we didn't measure
orignal
Vort saw 15 active session simulteniously
orignal
I also saw like 10
zzz
already caught him, took less than 2 minutes:
zzz
03/15 19:31:54.981 INFO [ handler 1/1] ter.transport.udp.UDPTransport: Peer already connected (PBID): old=85.0.223.58:27813 yQN8Qt IB2 recvAge: 3m sendAge: 3m sendAttemptAge: 3m sendACKAge: 3m lifetime: 3m RTT: 81 RTTdev: 54 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3835 acwin: 3835 SST: 2560 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 1 pkts rcvd OK/Dup: 2/0 pkts sent OK/Dup: 1/0 IBM: 0 OBQ: 0 OBL: 0
zzz
weRelayToThemAs: 780851860 new=151.248.142.46:17022 yQN8Qt IB2 recvAge: 0ms sendAge: 54y sendAttemptAge: 0ms sendACKAge: 0ms lifetime: 0ms RTT: 32 RTTdev: 16 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3840 acwin: 3840 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 0 msgs sent: 0 pkts rcvd OK/Dup: 0/0 pkts sent OK/Dup: 0/0 IBM: 0 OBQ: 0 OBL: 0 weRelayToThemAs: 3634586576
zzz
03/15 19:31:54.981 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 85.0.223.58:27813 TO 151.248.142.46:17022
orignal
Vort or that router?
orignal
it didn't change IP because both are active
zzz
that router. changed IP _and_ port
zzz
and again 3 1/2 minutes later, to a THIRD IP:
zzz
03/15 19:35:34.300 INFO [ handler 1/1] ter.transport.udp.UDPTransport: Peer already connected (PBID): old=151.248.142.46:17022 yQN8Qt IB2 recvAge: 3m sendAge: 3m sendAttemptAge: 3m sendACKAge: 3m lifetime: 3m RTT: 75 RTTdev: 51 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3835 acwin: 3835 SST: 2560 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 1 pkts rcvd OK/Dup: 2/0 pkts sent OK/Dup: 1/0 IBM: 0 OBQ: 0 OBL: 0
zzz
weRelayToThemAs: 3634586576 new=86.56.77.56:14517 yQN8Qt IB2 recvAge: 0ms sendAge: 54y sendAttemptAge: 0ms sendACKAge: 0ms lifetime: 0ms RTT: 0 RTTdev: 0 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3840 acwin: 3840 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 0 msgs sent: 0 pkts rcvd OK/Dup: 0/0 pkts sent OK/Dup: 0/0 IBM: 0 OBQ: 0 OBL: 0
zzz
03/15 19:35:34.300 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 151.248.142.46:17022 TO 86.56.77.56:14517
orignal
why do you think it changed rather than 3 different routers?
zzz
I'm not saying either way
zzz
look to see if same RI values like "i" and "s"
orignal
I suspect that some moron cloned whole router
orignal
wigh all keys
orignal
maybe using docker
orignal
so, what should we do with such "multihomed" routers
orignal
ban?
zzz
sure, why not
zzz
but if you're allowing multiple sessions with same router you better fix that asap ))
orignal
ofc, that's a bug in our code
orignal
but what to do it general?
zzz
so far the "i" and "s" values are not changing
zzz
now up to 7 IPs in 10 minutes:
zzz
03/15 19:31:54.981 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 85.0.223.58:27813 TO 151.248.142.46:17022
zzz
03/15 19:35:34.300 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 151.248.142.46:17022 TO 86.56.77.56:14517
zzz
03/15 19:36:27.937 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 86.56.77.56:14517 TO 95.233.49.32:19209
zzz
03/15 19:37:00.439 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 95.233.49.32:19209 TO 2.201.145.207:21569
zzz
03/15 19:38:21.443 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 2.201.145.207:21569 TO 91.51.96.242:9233
zzz
03/15 19:42:39.284 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 91.51.96.242:9233 TO 104.158.233.108:22791
orignal
why shoukd they change?
zzz
if it was really different routers?
orignal
why would they have dofferent s and i?
orignal
if they are all clones
zzz
well, if it's stored in the config I guess it wouldn't
orignal
if it's i2pd that they cpoied whole .i2pd folder
orignal
I store in ntcp2.keys and ssu2.keys files
zzz
ok
orignal
let's discuss how we should detect and ban such idiots
zzz
if it is a botnet, it's the easiest one ever to ban ))
zzz
if eyedeekay is up for it we can ban it today
zzz
thanks for the heads up
zzz
i do see him banned already on one router, not sure why
zzz
maybe unreachable
zzz
or peer test mismatch
zzz
you could do any heuristic you wanted, if you want to spend the memory to count IP changes
zzz
here's one where the "old" session was only 213ms old:
zzz
03/15 19:56:59.423 INFO [ handler 1/1] ter.transport.udp.UDPTransport: Peer already connected (PBID): old=69.206.152.24:23457 yQN8Qt IB2 recvAge: 96ms sendAge: 107ms sendAttemptAge: 89ms sendACKAge: 89ms lifetime: 213ms
orignal
I don't think it's a botnet
orignal
I think some idiot distributes a prebuilt docker image or packet
zzz
well, count how many unique IPs
orignal
Vort says there are few more
orignal
routers
zzz
MogB is a candidate, 3 IPs in 6 minutes
zzz
what's vort's list?
zzz
f~Uz 14 changes in 20 minutes
orignal
<Vort> DtQsGzkbeR3nilr6ZvywR2O7-f0XaaV~YfHXohqwjgI=
orignal
<Vort> F~UzS1mTN3XYlnOfidMBv5Z4lHI7dsCZ8N5mxpyc-OU=
zzz
I recognize DtQs. It's an absolutely terrible terrible router. We banned it over a year ago!
orignal
we don't have a ban list yet
zzz
> 1 ip changes in last 50 minutes:
zzz
27 yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=]
zzz
17 F~UzS1mTN3XYlnOfidMBv5Z4lHI7dsCZ8N5mxpyc-OU=]
zzz
4 ~SN8k6Hid107ighTnxRSiwTwwPMjEpPbDEyEY--zD~U=]
zzz
3 MogB-V71uOsLBu5z9gW5sa3zzUfI5GD43selaYiOy4U=]
zzz
2 6NMfknVMawT~baK0VanEkbXvO2hJCLJ5rreieysRrNE=]
zzz
DtQs not on the list because it's already banned
zzz
sounds like you have some work to do )) Vort+++++ as usual
zzz
orignal, if they are copying config, why do they all have different ports?
orignal
because port is not in config
orignal
they are all U, right?
dr|z3d
identify tor relays here: metrics.torproject.org/rs.html
orignal
U routers don't persist port
orignal
unless it's specified in config
zzz
ok
dr|z3d
If you want to check an exit, you can also use check.torproject.org/torbulkexitlist if you're happy grepping for ips.
dr|z3d
fwiw, MogB isn't using a Tor exit.
zzz
I eyeballed a few for F~Uz and yQN8, didn't see any matches
zzz
thanks
zzz
new contender ~SN8
zzz
here's the change counts after an hour:
zzz
42 yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=]
zzz
19 F~UzS1mTN3XYlnOfidMBv5Z4lHI7dsCZ8N5mxpyc-OU=]
zzz
8 ~SN8k6Hid107ighTnxRSiwTwwPMjEpPbDEyEY--zD~U=]
zzz
5 6NMfknVMawT~baK0VanEkbXvO2hJCLJ5rreieysRrNE=]
zzz
3 MogB-V71uOsLBu5z9gW5sa3zzUfI5GD43selaYiOy4U=]
zzz
I'll let the logging run overnight and then holler at eyedeekay in the morning so we can drop the hammer
dr|z3d
MogB was LR, orignal.
zzz
I think MogB is now under whatever threshold I'd draw
dr|z3d
was LR last I looked, now it's U. that's in the space of 5m.
orignal
false positive I guess
dr|z3d
was swiss, now italian.
dr|z3d
so why don't we set a ceiling for ip changes within an hour or whatever and temp ban routers exceed the limit?
zzz
because we'd need a data structure to store that
dr|z3d
ok, is it worth the effort?
zzz
not just effort but memory
zzz
how many routers you see an hour? figure 200 bytes per
dr|z3d
so we can't just tag the routerinfo with an additional field for the ip count/hr?
zzz
we don't store internal data with the RI, it would get lost whenever we get a new RI, which is every time he connects to us
dr|z3d
ok, thought that was probably a dumb idea.
dr|z3d
so it would need to go in the profile then.
zzz
not dumb, just not the way we do it. I believe i2pd does it that way
dr|z3d
except I don't like the idea of using the profile, I'm pretty selective about what exactly I bother to profile.
zzz
yup
zzz
a stateless heuristic is better
zzz
e.g. incoming && has old session && old session was incoming && ip different && port different && old session idle < 30 sec
zzz
it's keeping long-lived stats that's expensive
dr|z3d
yeah, so a window that's reasonable to things fairly tight sounds good.
dr|z3d
as long as it manages to snag the offenders, obviously :)
dr|z3d
words keep going missing when I type. there was a "keep" in the penultimate sentence when I thought it :)
zzz
stateless isn't the right word, I mean based on current state, not requiring any stored history/stats
zzz
because that reduces any mitigation to basically a one-liner
dr|z3d
yeah, I got what you meant. in-memory, essentially.
zzz
not just in-memory but zero-memory-added
zzz
if you can make decisions based on what you already know, it's a thousand times simpler
dr|z3d
ok
dr|z3d
sounds like you got something cooking, in your mind at least :)
zzz
not really. the problem with heuristics is you have to guess where to draw the line and tradeoff false positives and negatives
zzz
barring new data, I'd just hammer yQN8 and F~Uz and call it a day
dr|z3d
well, that's the simplest solution, but I suspect this isn't the last time we'll see this behavior.
dr|z3d
the other way to deal with constantly cycling ips _without_ a heuristic is to prevent it on the offending routers.
dr|z3d
do a count of ip changes on the router itself, and if it exceeds some ceiling, print a nice big critical class message to the logs and shut it down :)
dr|z3d
"You have exceeded the maximum number of IP address changes permitted per hour, your router will now shutdown."
dr|z3d
there's probably a selection of "issues" that could/should force an immediate shutdown, excessive clow skew being another.