Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

2020-10-11 Thread lists
On 11.10.2020 22:41, Roger Dingledine wrote: Right, in this particular case, we already run a scanner which provides public output: it's the tordnsel scanner, and check out https://check.torproject.org/exit-addresses Damn it, the boy was hardworking. ExitNode 385527185E26937D05E0933DD29FF1699

Re: [tor-relays] rerouting exits

2020-10-11 Thread Mike Perry
On 10/11/20 3:08 PM, nusenu wrote: >> Are your scanners available for others to run? I understand that it is a >> risk that making them public may allow bad exits to avoid them, but is >> it ok if other specific people use and adapt the scanners? > > You don't need to actively perform scans (in

Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

2020-10-11 Thread Roger Dingledine
On Sun, Oct 11, 2020 at 01:39:17PM -0500, Mike Perry wrote: > > I believe I can tell rerouting exits from exits having distinct IPs for > > inbound and outbound connections - in most cases. > > Are your scanners available for others to run? I understand that it is a > risk that making them public

[tor-relays] support for exit IP ranges on exit relays

2020-10-11 Thread nusenu
> I am losing patience with the "let's play nice and let exit IP addresses > be predictable" model... I'd like to see: add support for multiple OutboundBindAddressExit IP(ranges) https://gitlab.torproject.org/tpo/core/tor/-/issues/26646 (the time based approached mentioned towards the end)

Re: [tor-relays] rerouting exits

2020-10-11 Thread nusenu
> Are your scanners available for others to run? I understand that it is a > risk that making them public may allow bad exits to avoid them, but is > it ok if other specific people use and adapt the scanners? You don't need to actively perform scans (in the sense of establishing circuits) to detec

Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

2020-10-11 Thread Mike Perry
On 10/11/20 1:17 PM, nusenu wrote: >> I am losing patience with the "let's play nice and let exit IP addresses >> be predictable" model... We are not being treated well by the banhammer >> brigade, and it might be time to flip some tables. I would not call >> simply using a different exit IP than y

Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

2020-10-11 Thread nusenu
> I am losing patience with the "let's play nice and let exit IP addresses > be predictable" model... We are not being treated well by the banhammer > brigade, and it might be time to flip some tables. I would not call > simply using a different exit IP than your relay's OR port a bad exit. I'm no

Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

2020-10-11 Thread Mike Perry
On 10/11/20 10:20 AM, nusenu wrote: > Thanks for the report, I have forwarded it for removal. > > li...@for-privacy.net: >> Wtf, this exit has addresses that do not belong to it! >> https://metrics.torproject.org/rs.html#details/385527185E26937D05E0933DD29FF1699056CAF3 > > Yes, rerouting exit t

Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 45.63.11.98

2020-10-11 Thread nusenu
Thanks for the report, I have forwarded it for removal. li...@for-privacy.net: > Wtf, this exit has addresses that do not belong to it! > https://metrics.torproject.org/rs.html#details/385527185E26937D05E0933DD29FF1699056CAF3 Yes, rerouting exit traffic is a practice we have observed in the past.

[tor-relays] Is this next bad exit trick?

2020-10-11 Thread lists
Wtf, this exit has addresses that do not belong to it! https://metrics.torproject.org/rs.html#details/385527185E26937D05E0933DD29FF1699056CAF3 I'm very sure there are only nifty rabbits on the 185.220.101.0/24 subnet! -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you fr