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

[lists]

On 12.10.2020 15:05, Dr Gerard Bulger wrote:

Torrc allows you to exit from a different IP.  I thought it a good
idea to stop arbitrary blocking of the advertised Tor exit IP, the
captchas and blacklists that tor users suffer. When IPv6 implemented
fully we have a wide range of IPs to send from on each server.


Yes. but always think of prefix/subnet with IPv6.
1 IPv4 = IPv6/64 prefix

I am afraid different IPs from a /64 prefix won't do anything, mostly.
Adversatories will block /48 or 56/ or /64 prefixes.


--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[nusenu]

Dr Gerard Bulger:
> Torrc allows you to exit from a different IP.  I thought it a good
> idea to stop arbitrary blocking of the advertised Tor exit IP, the
> captchas and blacklists that tor users suffer. When IPv6 implemented
> fully we have a wide range of IPs to send from on each server.
> 
> Perhaps it is not considered good form to do so as the internet
> should know who is using Tor.
> 
> So what is the problems for TOR security when exits set up to send
> from a different IP?   Is it that we do not know what the second IP
> is up to in dealing with the IP4 traffic from the exit?

simplified: there can be two reasons for  inbound (OR) IP != exit IP:

a) the exit used 
https://2019.www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit
or some form of NAT

b) the exit relay uses an tor client to route its traffic back into tor


This exit was doing (b), I think you are referring to (a) which is perfectly 
fine.


-- 
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[nusenu]

niftybunny:
> Just woke up. So, whats wrong with some of my relays in this list?

some "exit" relay routed its traffic back into tor by using
a tor client. That tor client used exit relays - yours were among them.

So nothing wrong on your side. 




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Dr Gerard Bulger]

Torrc allows you to exit from a different IP.  I thought it a good idea to stop 
arbitrary blocking of the advertised Tor exit IP, the captchas and blacklists 
that tor users suffer. When IPv6 implemented fully we have a wide range of IPs 
to send from on each server.   

Perhaps it is not considered good form to do so as the internet should know who 
is using Tor.

So what is the problems for TOR security when exits set up to send from a 
different IP?   Is it that we do not know what the second IP is up to in 
dealing with the IP4 traffic from the exit?

Gerry

-Original Message-
From: tor-relays  On Behalf Of 
li...@for-privacy.net
Sent: 11 October 2020 23:13
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] BadExit: Rerouting exit relays detected (1) 
45.63.11.98

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 385527185E26937D05E0933DD29FF1699056CAF3
Published 2020-10-11 11:54:00
LastStatus 2020-10-11 17:00:00
ExitAddress 185.220.102.252 2020-10-11 17:52:50 ExitAddress 45.154.35.218 
2020-10-11 17:13:21 ExitAddress 45.63.11.98 2020-10-11 09:19:06 ExitAddress 
51.158.111.157 2020-10-10 23:51:28 ExitAddress 45.154.35.219 2020-10-10 
20:14:28 ExitAddress 185.220.101.207 2020-10-10 18:10:02 ExitAddress 
185.140.53.7 2020-10-10 15:04:52 ExitAddress 23.129.64.205 2020-10-10 09:14:15 
ExitAddress 23.129.64.100 2020-10-10 06:10:30 ExitAddress 185.220.100.240 
2020-10-10 03:41:38 ExitAddress 23.129.64.207 2020-10-09 21:04:35 ExitAddress 
23.129.64.209 2020-10-09 19:31:42 ExitAddress 23.129.64.212 2020-10-09 15:18:55 
ExitAddress 185.107.47.215 2020-10-09 12:02:09 ExitAddress 45.154.35.216 
2020-10-09 09:11:20 ExitAddress 162.247.74.7 2020-10-09 08:10:41 ExitAddress 
45.154.35.214 2020-10-09 04:27:16 ExitAddress 130.225.244.90 2020-10-09 
03:34:52 ExitAddress 46.165.245.154 2020-10-08 22:09:32 ExitAddress 
185.220.102.248 2020-10-08 21:13:44 ExitAddress 45.154.35.211 2020-10-08 
15:17:28 ExitAddress 45.154.35.213 2020-10-08 14:52:41 ExitAddress 185.140.53.9 
2020-10-08 12:42:16 ExitAddress 145.239.92.26 2020-10-08 11:34:41 ExitAddress 
185.140.53.5 2020-10-08 09:39:55 ExitAddress 51.195.150.250 2020-10-08 05:42:51 
ExitAddress 185.220.102.247 2020-10-08 04:38:46 ExitAddress 51.83.139.56 
2020-10-08 02:41:35 ExitAddress 216.239.90.19 2020-10-07 22:10:28 ExitAddress 
35.0.127.52 2020-10-07 21:46:15 ExitAddress 185.220.102.241 2020-10-07 20:04:33 
ExitAddress 45.154.35.220 2020-10-07 17:28:29 ExitAddress 209.141.39.33 
2020-10-07 15:49:11 ExitAddress 185.220.101.10 2020-10-07 12:39:45 ExitAddress 
185.220.101.200 2020-10-07 05:12:35 ExitAddress 51.195.149.132 2020-10-06 
19:26:01 ExitAddress 45.154.35.212 2020-10-06 18:39:37 ExitAddress 
179.43.167.226 2020-10-06 12:55:24 ExitAddress 185.220.102.242 2020-10-06 
09:04:52 ExitAddress 162.247.74.201 2020-10-05 11:44:18 ExitAddress 
45.154.35.210 2020-10-05 09:59:58 ExitAddress 51.75.144.43 2020-10-05 01:24:36 
ExitAddress 185.220.100.250 2020-10-04 12:52:37 ExitAddress 94.142.244.16 
2020-10-04 09:26:13 ExitAddress 45.154.35.215 2020-10-04 08:15:17 ExitAddress 
185.220.102.243 2020-10-03 20:13:45 ExitAddress 5.79.109.48 2020-10-03 16:56:19 
ExitAddress 54.36.108.162 2020-10-02 18:11:45 ExitAddress 209.141.61.129 
2020-10-01 21:48:30 ExitAddress 18.27.197.252 2020-10-01 18:26:32 ExitAddress 
51.178.43.104 2020-10-01 15:39:56 ExitAddress 185.220.100.252 2020-10-01 
07:57:36 ExitAddress 185.220.102.8 2020-10-01 06:29:39 ExitAddress 51.81.83.151 
2020-09-30 21:55:17 ExitAddress 185.220.102.253 2020-09-30 17:52:13 ExitAddress 
37.120.152.116 2020-09-30 13:25:01 ExitAddress 162.247.74.200 2020-09-30 
11:02:05 ExitAddress 185.220.100.241 2020-09-30 10:44:36 ExitAddress 
45.129.56.200 2020-09-30 07:52:31 ExitAddress 171.25.193.77 2020-09-29 17:15:03 
ExitAddress 185.220.101.205 2020-09-28 22:13:13 ExitAddress 198.251.89.136 
2020-09-28 15:27:51 ExitAddress 193.218.118.140 2020-09-28 12:39:45 ExitAddress 
185.220.101.199 2020-09-28 05:45:20 ExitAddress 85.248.227.165 2020-09-28 
00:42:28 ExitAddress 185.220.101.148 2020-09-27 18:58:16

https://metrics.torproject.org/rs.html#search/185.220.
niftybunny, Zwiebelfreunde, Digitalcourage & F3Netze help each other but have 
their machines in different IX. They don't throw their IPs from the separate 
ASNs onto one machine. ;-)

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[niftybunny]

Just woke up. So, whats wrong with some of my relays in this list?

nifty

> On 12. Oct 2020, at 00:13, li...@for-privacy.net wrote:
> 
> 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 385527185E26937D05E0933DD29FF1699056CAF3
> Published 2020-10-11 11:54:00
> LastStatus 2020-10-11 17:00:00
> ExitAddress 185.220.102.252 2020-10-11 17:52:50
> ExitAddress 45.154.35.218 2020-10-11 17:13:21
> ExitAddress 45.63.11.98 2020-10-11 09:19:06
> ExitAddress 51.158.111.157 2020-10-10 23:51:28
> ExitAddress 45.154.35.219 2020-10-10 20:14:28
> ExitAddress 185.220.101.207 2020-10-10 18:10:02
> ExitAddress 185.140.53.7 2020-10-10 15:04:52
> ExitAddress 23.129.64.205 2020-10-10 09:14:15
> ExitAddress 23.129.64.100 2020-10-10 06:10:30
> ExitAddress 185.220.100.240 2020-10-10 03:41:38
> ExitAddress 23.129.64.207 2020-10-09 21:04:35
> ExitAddress 23.129.64.209 2020-10-09 19:31:42
> ExitAddress 23.129.64.212 2020-10-09 15:18:55
> ExitAddress 185.107.47.215 2020-10-09 12:02:09
> ExitAddress 45.154.35.216 2020-10-09 09:11:20
> ExitAddress 162.247.74.7 2020-10-09 08:10:41
> ExitAddress 45.154.35.214 2020-10-09 04:27:16
> ExitAddress 130.225.244.90 2020-10-09 03:34:52
> ExitAddress 46.165.245.154 2020-10-08 22:09:32
> ExitAddress 185.220.102.248 2020-10-08 21:13:44
> ExitAddress 45.154.35.211 2020-10-08 15:17:28
> ExitAddress 45.154.35.213 2020-10-08 14:52:41
> ExitAddress 185.140.53.9 2020-10-08 12:42:16
> ExitAddress 145.239.92.26 2020-10-08 11:34:41
> ExitAddress 185.140.53.5 2020-10-08 09:39:55
> ExitAddress 51.195.150.250 2020-10-08 05:42:51
> ExitAddress 185.220.102.247 2020-10-08 04:38:46
> ExitAddress 51.83.139.56 2020-10-08 02:41:35
> ExitAddress 216.239.90.19 2020-10-07 22:10:28
> ExitAddress 35.0.127.52 2020-10-07 21:46:15
> ExitAddress 185.220.102.241 2020-10-07 20:04:33
> ExitAddress 45.154.35.220 2020-10-07 17:28:29
> ExitAddress 209.141.39.33 2020-10-07 15:49:11
> ExitAddress 185.220.101.10 2020-10-07 12:39:45
> ExitAddress 185.220.101.200 2020-10-07 05:12:35
> ExitAddress 51.195.149.132 2020-10-06 19:26:01
> ExitAddress 45.154.35.212 2020-10-06 18:39:37
> ExitAddress 179.43.167.226 2020-10-06 12:55:24
> ExitAddress 185.220.102.242 2020-10-06 09:04:52
> ExitAddress 162.247.74.201 2020-10-05 11:44:18
> ExitAddress 45.154.35.210 2020-10-05 09:59:58
> ExitAddress 51.75.144.43 2020-10-05 01:24:36
> ExitAddress 185.220.100.250 2020-10-04 12:52:37
> ExitAddress 94.142.244.16 2020-10-04 09:26:13
> ExitAddress 45.154.35.215 2020-10-04 08:15:17
> ExitAddress 185.220.102.243 2020-10-03 20:13:45
> ExitAddress 5.79.109.48 2020-10-03 16:56:19
> ExitAddress 54.36.108.162 2020-10-02 18:11:45
> ExitAddress 209.141.61.129 2020-10-01 21:48:30
> ExitAddress 18.27.197.252 2020-10-01 18:26:32
> ExitAddress 51.178.43.104 2020-10-01 15:39:56
> ExitAddress 185.220.100.252 2020-10-01 07:57:36
> ExitAddress 185.220.102.8 2020-10-01 06:29:39
> ExitAddress 51.81.83.151 2020-09-30 21:55:17
> ExitAddress 185.220.102.253 2020-09-30 17:52:13
> ExitAddress 37.120.152.116 2020-09-30 13:25:01
> ExitAddress 162.247.74.200 2020-09-30 11:02:05
> ExitAddress 185.220.100.241 2020-09-30 10:44:36
> ExitAddress 45.129.56.200 2020-09-30 07:52:31
> ExitAddress 171.25.193.77 2020-09-29 17:15:03
> ExitAddress 185.220.101.205 2020-09-28 22:13:13
> ExitAddress 198.251.89.136 2020-09-28 15:27:51
> ExitAddress 193.218.118.140 2020-09-28 12:39:45
> ExitAddress 185.220.101.199 2020-09-28 05:45:20
> ExitAddress 85.248.227.165 2020-09-28 00:42:28
> ExitAddress 185.220.101.148 2020-09-27 18:58:16
> 
> https://metrics.torproject.org/rs.html#search/185.220.
> niftybunny, Zwiebelfreunde, Digitalcourage & F3Netze help each other but have
> their machines in different IX. They don't throw their IPs from the separate 
> ASNs onto one machine. ;-)
> 
> --
> ╰_╯ Ciao Marco!
> 
> Debian GNU/Linux
> 
> It's free software and it gives you freedom!
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 385527185E26937D05E0933DD29FF1699056CAF3
Published 2020-10-11 11:54:00
LastStatus 2020-10-11 17:00:00
ExitAddress 185.220.102.252 2020-10-11 17:52:50
ExitAddress 45.154.35.218 2020-10-11 17:13:21
ExitAddress 45.63.11.98 2020-10-11 09:19:06
ExitAddress 51.158.111.157 2020-10-10 23:51:28
ExitAddress 45.154.35.219 2020-10-10 20:14:28
ExitAddress 185.220.101.207 2020-10-10 18:10:02
ExitAddress 185.140.53.7 2020-10-10 15:04:52
ExitAddress 23.129.64.205 2020-10-10 09:14:15
ExitAddress 23.129.64.100 2020-10-10 06:10:30
ExitAddress 185.220.100.240 2020-10-10 03:41:38
ExitAddress 23.129.64.207 2020-10-09 21:04:35
ExitAddress 23.129.64.209 2020-10-09 19:31:42
ExitAddress 23.129.64.212 2020-10-09 15:18:55
ExitAddress 185.107.47.215 2020-10-09 12:02:09
ExitAddress 45.154.35.216 2020-10-09 09:11:20
ExitAddress 162.247.74.7 2020-10-09 08:10:41
ExitAddress 45.154.35.214 2020-10-09 04:27:16
ExitAddress 130.225.244.90 2020-10-09 03:34:52
ExitAddress 46.165.245.154 2020-10-08 22:09:32
ExitAddress 185.220.102.248 2020-10-08 21:13:44
ExitAddress 45.154.35.211 2020-10-08 15:17:28
ExitAddress 45.154.35.213 2020-10-08 14:52:41
ExitAddress 185.140.53.9 2020-10-08 12:42:16
ExitAddress 145.239.92.26 2020-10-08 11:34:41
ExitAddress 185.140.53.5 2020-10-08 09:39:55
ExitAddress 51.195.150.250 2020-10-08 05:42:51
ExitAddress 185.220.102.247 2020-10-08 04:38:46
ExitAddress 51.83.139.56 2020-10-08 02:41:35
ExitAddress 216.239.90.19 2020-10-07 22:10:28
ExitAddress 35.0.127.52 2020-10-07 21:46:15
ExitAddress 185.220.102.241 2020-10-07 20:04:33
ExitAddress 45.154.35.220 2020-10-07 17:28:29
ExitAddress 209.141.39.33 2020-10-07 15:49:11
ExitAddress 185.220.101.10 2020-10-07 12:39:45
ExitAddress 185.220.101.200 2020-10-07 05:12:35
ExitAddress 51.195.149.132 2020-10-06 19:26:01
ExitAddress 45.154.35.212 2020-10-06 18:39:37
ExitAddress 179.43.167.226 2020-10-06 12:55:24
ExitAddress 185.220.102.242 2020-10-06 09:04:52
ExitAddress 162.247.74.201 2020-10-05 11:44:18
ExitAddress 45.154.35.210 2020-10-05 09:59:58
ExitAddress 51.75.144.43 2020-10-05 01:24:36
ExitAddress 185.220.100.250 2020-10-04 12:52:37
ExitAddress 94.142.244.16 2020-10-04 09:26:13
ExitAddress 45.154.35.215 2020-10-04 08:15:17
ExitAddress 185.220.102.243 2020-10-03 20:13:45
ExitAddress 5.79.109.48 2020-10-03 16:56:19
ExitAddress 54.36.108.162 2020-10-02 18:11:45
ExitAddress 209.141.61.129 2020-10-01 21:48:30
ExitAddress 18.27.197.252 2020-10-01 18:26:32
ExitAddress 51.178.43.104 2020-10-01 15:39:56
ExitAddress 185.220.100.252 2020-10-01 07:57:36
ExitAddress 185.220.102.8 2020-10-01 06:29:39
ExitAddress 51.81.83.151 2020-09-30 21:55:17
ExitAddress 185.220.102.253 2020-09-30 17:52:13
ExitAddress 37.120.152.116 2020-09-30 13:25:01
ExitAddress 162.247.74.200 2020-09-30 11:02:05
ExitAddress 185.220.100.241 2020-09-30 10:44:36
ExitAddress 45.129.56.200 2020-09-30 07:52:31
ExitAddress 171.25.193.77 2020-09-29 17:15:03
ExitAddress 185.220.101.205 2020-09-28 22:13:13
ExitAddress 198.251.89.136 2020-09-28 15:27:51
ExitAddress 193.218.118.140 2020-09-28 12:39:45
ExitAddress 185.220.101.199 2020-09-28 05:45:20
ExitAddress 85.248.227.165 2020-09-28 00:42:28
ExitAddress 185.220.101.148 2020-09-27 18:58:16

https://metrics.torproject.org/rs.html#search/185.220.
niftybunny, Zwiebelfreunde, Digitalcourage & F3Netze help each other but 
have
their machines in different IX. They don't throw their IPs from the 
separate ASNs onto one machine. ;-)


--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 may allow bad exits to avoid them, but is
> it ok if other specific people use and adapt the scanners?

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

So what we are missing still is (a) a human to go through that list
periodically to look for exits that have weirdly too many exit addresses,
especially addresses that overlap with other exits, and then (b) somebody
to automate the process that that human uses.

In the 'bad exit finding' world, we've had problems in the past with
false positives, where some automated tool spams us with "possible"
problem relays and we quickly learn that ignoring those reports is the
best use of our time. So as we try to automate this one, I'd be a fan
of putting the detection threshold quite high, so when we trigger on
a relay and escalate to the humans, it's because we're quite confident
there's something that needs action.

> >> Remember that our directory authorities are deliberately independent
> >> from TPI though, and even what I think is not necessarily what TPI
> >> thinks. The dirauths may have different opinions. Coordinating policy of
> >> this nature is difficult and requires consensus building.
> > 
> > Since dir auths have been removing these kinds of relays, I don't think 
> > there
> > is any policy change necessary.
> 
> Ok great! Sometimes I am surprised by their decisions, and I didn't see
> this one.

Right. This one's an easy choice, because not only is it wasteful as
you say, it is also a way that somebody can sign up an exit relay to
look at traffic without needing to actually be the exit for that traffic.

--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 your relay's OR port a bad exit.
> 
> I'm not calling exit relays using distinct IPs or inbound (OR) and outbound
> connections "BadExits" either, quite the opposite, all exits should be using
> https://2019.www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit
> if they have spare IPs.
> That is why I implemented and automated that configuration in relayor.

Ok that sounds reasonable. Thanks!

> 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 may allow bad exits to avoid them, but is
it ok if other specific people use and adapt the scanners?

>> Remember that our directory authorities are deliberately independent
>> from TPI though, and even what I think is not necessarily what TPI
>> thinks. The dirauths may have different opinions. Coordinating policy of
>> this nature is difficult and requires consensus building.
> 
> Since dir auths have been removing these kinds of relays, I don't think there
> is any policy change necessary.

Ok great! Sometimes I am surprised by their decisions, and I didn't see
this one.


-- 
Mike Perry



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 not calling exit relays using distinct IPs or inbound (OR) and outbound
connections "BadExits" either, quite the opposite, all exits should be using
https://2019.www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit
if they have spare IPs.
That is why I implemented and automated that configuration in relayor.

I believe I can tell rerouting exits from exits having distinct IPs for
inbound and outbound connections - in most cases.

 
> Remember that our directory authorities are deliberately independent
> from TPI though, and even what I think is not necessarily what TPI
> thinks. The dirauths may have different opinions. Coordinating policy of
> this nature is difficult and requires consensus building.

Since dir auths have been removing these kinds of relays, I don't think there
is any policy change necessary.






signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 traffic is a practice we have observed in the past.
> 
> BadExit: Rerouting exit relays detected (1)
> The following exit relays are routing their traffic back into the tor network:
> ---
> nickname: exitnew
> First seen: 2020-09-25 12:00:00
> Consensus weight: 1410
> AS: Choopa, LLC
> OR IP address: 45.63.11.98
> Exit addresses: 185.140.53.7 185.220.101.207 45.154.35.219 45.63.11.98 
> 51.158.111.157
> https://atlas.torproject.org/#details/385527185E26937D05E0933DD29FF1699056CAF3
> 
> 
> 
>> I'm very sure there are only nifty rabbits on the 185.220.101.0/24 subnet!
> 
> niftybummy has relays outside of 185.220.101.0/24

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.

However, re-routing exit traffic back into Tor like this is not the
answer. It is simply wasteful. I am in favor of delisting such relays.

Remember that our directory authorities are deliberately independent
from TPI though, and even what I think is not necessarily what TPI
thinks. The dirauths may have different opinions. Coordinating policy of
this nature is difficult and requires consensus building.

Again, I understand your frustration.



-- 
Mike Perry



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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.

BadExit: Rerouting exit relays detected (1)
The following exit relays are routing their traffic back into the tor network:
---
nickname: exitnew
First seen: 2020-09-25 12:00:00
Consensus weight: 1410
AS: Choopa, LLC
OR IP address: 45.63.11.98
Exit addresses: 185.140.53.7 185.220.101.207 45.154.35.219 45.63.11.98 
51.158.111.157
https://atlas.torproject.org/#details/385527185E26937D05E0933DD29FF1699056CAF3


 
> I'm very sure there are only nifty rabbits on the 185.220.101.0/24 subnet!

niftybummy has relays outside of 185.220.101.0/24

-- 
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[teor]

Hi Georg,

> On 27 Mar 2020, at 22:40, Georg Koppen  wrote:
> 
>> (If the DNS for the site they are testing has both IPv4 and IPv6, then
>> the outcome will depend on their tor version and config. 0.4.3 and
>> later will prefer IPv6 by default.)
> 
> Not sure what Arthur is running but I am just using what Debian ships on
> the box I run the tests, which is currently 0.3.5.8. I guess it might be
> worth thinking about switching away from that. Maybe tracking and using
> the version Tor Browser ships is smarter?

I think any supported Tor version is ok.

But yes, using the same version as Tor Browser users could be helpful.

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[niftybunny]

This. Port 22 especially is a nightmare.

niftybunny

> On 27. Mar 2020, at 16:29, Toralf Förster  wrote:
> 
> Signed PGP part
> On 3/27/20 2:17 PM, ger...@bulger.co.uk wrote:
>> I have been free of abuse complaints and copyright claims for two years now.
> Well, the main problem here fore me is to get complaints from my hoster 
> itself b/c any open address range are abused soon for port scans
> --
> Toralf
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[Toralf Förster]

On 3/27/20 2:17 PM, ger...@bulger.co.uk wrote:
>  I have been free of abuse complaints and copyright claims for two years now. 
Well, the main problem here fore me is to get complaints from my hoster itself 
b/c any open address range are abused soon for port scans
-- 
Toralf



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[gerard]

Thanks.  Funny that my long time restricted IPv4 port 80 exit was noticed just 
now giving the bad exit tag.   I suspect the hour one of my  server was 
quarantined by my ISP may have precipitated the system to look hard.

As for my single /8 for port 80, for reason not clear to me, having many ports 
open including 443 open to all, IPV6 open on port 80 to all, while restricting 
IPV4 to a single /8 stops all abuse complaints.  I have been free of abuse 
complaints and copyright claims for two years now.   I tried to offer more IPv4 
/8 ranges but abuses notices soon popped up, as if traffic is being en-route by 
some agencies.   The free-text nature of port 80 meant contents read too 
easily, and IPV6 still not used enough... yet.
  
Gerry

-Original Message-
From: tor-relays  On Behalf Of Georg 
Koppen
Sent: 27 March 2020 12:40
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] BadExit

teor:
> Hi,
> 
>> On 27 Mar 2020, at 02:00, niftybunny  
>> wrote:
>>
>> My bad. Never seen this before. I there a good reason for the accept 
>> 133.0.0.0/8:80 ?
>>
>>> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote:
>>>
>>> "btw, you need to have at least port 80 and 443 … port 80 is missing …"
>>>
>>> It there. But to a /8 area IPV4, all IPv6
>>>
>>> I have not changed my exit policy for years.  Port 80 is there, just 
>>> limited to a  /8  network and all IPv6 addresses port 80 allowed.
>>> 443 all there IPv4 and IPv6
>>>
>>> Testing seems to be exiting OK, but badexit tag still there.
> 
> The Exit flag only request one IPv4 /8 :
> https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2628
> 
> But if the network health team is testing a different IPv4 /8, then 
> your relay might appear down.

Yep, I think that's what happened. I'll get the badexit flag removed from both 
of your relays and think about ways for improving our tests.
Sorry for the inconvenience.

(FWIW: I sent an email to the address you put into your ContactInfo. I heard 
that mails for Tor Project addresses repeatedly land in spam folders. Maybe 
that happened this time, too.)

> (If the DNS for the site they are testing has both IPv4 and IPv6, then 
> the outcome will depend on their tor version and config. 0.4.3 and 
> later will prefer IPv6 by default.)

Not sure what Arthur is running but I am just using what Debian ships on the 
box I run the tests, which is currently 0.3.5.8. I guess it might be worth 
thinking about switching away from that. Maybe tracking and using the version 
Tor Browser ships is smarter?

Georg


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[Georg Koppen]

teor:
> Hi,
> 
>> On 27 Mar 2020, at 02:00, niftybunny  
>> wrote:
>>
>> My bad. Never seen this before. I there a good reason for the accept 
>> 133.0.0.0/8:80 ?
>>
>>> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote:
>>>
>>> "btw, you need to have at least port 80 and 443 … port 80 is missing …"
>>>
>>> It there. But to a /8 area IPV4, all IPv6
>>>
>>> I have not changed my exit policy for years.  Port 80 is there, just 
>>> limited to a  /8  network and all IPv6 addresses port 80 allowed.
>>> 443 all there IPv4 and IPv6
>>>
>>> Testing seems to be exiting OK, but badexit tag still there.
> 
> The Exit flag only request one IPv4 /8 :
> https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2628
> 
> But if the network health team is testing a different IPv4 /8, then your
> relay might appear down.

Yep, I think that's what happened. I'll get the badexit flag removed
from both of your relays and think about ways for improving our tests.
Sorry for the inconvenience.

(FWIW: I sent an email to the address you put into your ContactInfo. I
heard that mails for Tor Project addresses repeatedly land in spam
folders. Maybe that happened this time, too.)

> (If the DNS for the site they are testing has both IPv4 and IPv6, then
> the outcome will depend on their tor version and config. 0.4.3 and
> later will prefer IPv6 by default.)

Not sure what Arthur is running but I am just using what Debian ships on
the box I run the tests, which is currently 0.3.5.8. I guess it might be
worth thinking about switching away from that. Maybe tracking and using
the version Tor Browser ships is smarter?

Georg



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[teor]

> On 27 Mar 2020, at 20:42, teor  wrote:
> 
>>> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote:
>>> 
>>> "btw, you need to have at least port 80 and 443 … port 80 is missing …"
>>> 
>>> It there. But to a /8 area IPV4, all IPv6
>>> 
> The Exit flag only request one IPv4 /8 :
> https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2628

Correction: The Exit flag only *requires* one IPv4 /8.

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[teor]

Hi,

> On 27 Mar 2020, at 02:00, niftybunny  
> wrote:
> 
> My bad. Never seen this before. I there a good reason for the accept 
> 133.0.0.0/8:80 ?
> 
>> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote:
>> 
>> "btw, you need to have at least port 80 and 443 … port 80 is missing …"
>> 
>> It there. But to a /8 area IPV4, all IPv6
>> 
>> I have not changed my exit policy for years.  Port 80 is there, just limited 
>> to a  /8  network and all IPv6 addresses port 80 allowed.
>> 443 all there IPv4 and IPv6
>> 
>> Testing seems to be exiting OK, but badexit tag still there.

The Exit flag only request one IPv4 /8 :
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2628

But if the network health team is testing a different IPv4 /8, then your
relay might appear down.

(If the DNS for the site they are testing has both IPv4 and IPv6, then
the outcome will depend on their tor version and config. 0.4.3 and
later will prefer IPv6 by default.)

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[niftybunny]

My bad. Never seen this before. I there a good reason for the accept 
133.0.0.0/8:80 ?

niftybunny


> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote:
> 
> "btw, you need to have at least port 80 and 443 … port 80 is missing …"
> 
> It there. But to a /8 area IPV4, all IPv6
> 
> I have not changed my exit policy for years.  Port 80 is there, just limited 
> to a  /8  network and all IPv6 addresses port 80 allowed.
> 443 all there IPv4 and IPv6
> 
> Testing seems to be exiting OK, but badexit tag still there.
> 
> 
> Gerry
> 
> 
> -Original Message-
> From: tor-relays  On Behalf Of 
> niftybunny
> Sent: 26 March 2020 12:49
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] BadExit
> 
> btw, you need to have at least port 80 and 443 … port 80 is missing …
> 
> Cheers,
> 
> niftybunny
> 
> 
>> On 25. Mar 2020, at 23:28, ger...@bulger.co.uk wrote:
>> 
>> George
>> 
>> Thanks
>> 
>> My exit, still badexit, is  51AE5656C81CD417479253A6363A123A007A2233
>> and I did get an email which I missed, as it is simply failing to
>> exit, Implying my ISP was doing something before they told me.  Seems
>> to be exiting from my local port now.
>> 
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: tor-relays  On Behalf
>> Of Georg Koppen
>> Sent: 24 March 2020 18:21
>> To: tor-relays@lists.torproject.org
>> Subject: Re: [tor-relays] BadExit
>> 
>> Hi!
>> 
>> ger...@bulger.co.uk:
>>> Oh the shame!   Never had that tag on my exit before.
>> 
>> Sorry to hear. :(
>> 
>>> 
>>> 
>>> I assume it was due to a bad boy attacking an IP, pointed out by my
>>> ISP,
>> and
>>> the ISP put my server "under mitigation".I assume some filtering,
>> which
>>> of course would have looked bad to TOR users.
>>> 
>>> 
>>> 
>>> I did not spot the ISP's email for 30 minutes, but then I was able to
>>> block the offended IP.  Within minutes of doing that the ISP said
>>> attack stop and my server was removed from mitigation.  However the
>>> next day badexit tag on my exit and remains there
>>> 
>>> 
>>> 
>>> How long does the tag last?
>> 
>> So long as the Directory Authorities assign it.
>> 
>>> 
>>> 
>>> I go to my other, overseas exit, a family member, to see the tag is aslo
>>> applied there to.Do family members get tarred with the same brush?
>> 
>> It depends on the reason for badexiting.
>> 
>>> 
>>> 
>>> I have turned both into relays for the time being.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Or have I got this wrong.   Is it a  DNS thing?  Are no some DNS providers
>>> causing issues forcing the tag?   I am not using opendns.
>> 
>> It could be a DNS thing, I am not sure. I recently pushed a commit
>> that leads to some exits getting that flag. I tried to contact all the
>> relay operators beforehand (some did not have any ContactInfo set) but
>> I got almost no reply back. For details see [1].
>> 
>> What's the fingerprint of your relay that got the badexit flag?
>> 
>> Georg
>> 
>> [1] https://trac.torproject.org/projects/tor/ticket/32864
>> 
>>> 
>>> 
>>> Gerry
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>> 
>> 
>> 
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[gerard]

"btw, you need to have at least port 80 and 443 … port 80 is missing …"

It there. But to a /8 area IPV4, all IPv6

I have not changed my exit policy for years.  Port 80 is there, just limited to 
a  /8  network and all IPv6 addresses port 80 allowed.
443 all there IPv4 and IPv6

Testing seems to be exiting OK, but badexit tag still there.


Gerry


-Original Message-
From: tor-relays  On Behalf Of 
niftybunny
Sent: 26 March 2020 12:49
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] BadExit

btw, you need to have at least port 80 and 443 … port 80 is missing …

Cheers,

niftybunny


> On 25. Mar 2020, at 23:28, ger...@bulger.co.uk wrote:
> 
> George
> 
> Thanks
> 
> My exit, still badexit, is  51AE5656C81CD417479253A6363A123A007A2233  
> and I did get an email which I missed, as it is simply failing to 
> exit, Implying my ISP was doing something before they told me.  Seems 
> to be exiting from my local port now.
> 
> 
> 
> 
> 
> -Original Message-
> From: tor-relays  On Behalf 
> Of Georg Koppen
> Sent: 24 March 2020 18:21
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] BadExit
> 
> Hi!
> 
> ger...@bulger.co.uk:
>> Oh the shame!   Never had that tag on my exit before.
> 
> Sorry to hear. :(
> 
>> 
>> 
>> I assume it was due to a bad boy attacking an IP, pointed out by my 
>> ISP,
> and
>> the ISP put my server "under mitigation".I assume some filtering,
> which
>> of course would have looked bad to TOR users.
>> 
>> 
>> 
>> I did not spot the ISP's email for 30 minutes, but then I was able to 
>> block the offended IP.  Within minutes of doing that the ISP said 
>> attack stop and my server was removed from mitigation.  However the 
>> next day badexit tag on my exit and remains there
>> 
>> 
>> 
>> How long does the tag last?
> 
> So long as the Directory Authorities assign it.
> 
>> 
>> 
>> I go to my other, overseas exit, a family member, to see the tag is aslo
>> applied there to.Do family members get tarred with the same brush?
> 
> It depends on the reason for badexiting.
> 
>> 
>> 
>> I have turned both into relays for the time being.
>> 
>> 
>> 
>> 
>> 
>> Or have I got this wrong.   Is it a  DNS thing?  Are no some DNS providers
>> causing issues forcing the tag?   I am not using opendns.
> 
> It could be a DNS thing, I am not sure. I recently pushed a commit 
> that leads to some exits getting that flag. I tried to contact all the 
> relay operators beforehand (some did not have any ContactInfo set) but 
> I got almost no reply back. For details see [1].
> 
> What's the fingerprint of your relay that got the badexit flag?
> 
> Georg
> 
> [1] https://trac.torproject.org/projects/tor/ticket/32864
> 
>> 
>> 
>> Gerry
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> 
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[niftybunny]

btw, you need to have at least port 80 and 443 … port 80 is missing …

Cheers,

niftybunny


> On 25. Mar 2020, at 23:28, ger...@bulger.co.uk wrote:
> 
> George
> 
> Thanks
> 
> My exit, still badexit, is  51AE5656C81CD417479253A6363A123A007A2233  and I
> did get an email which I missed, as it is simply failing to exit, Implying
> my ISP was doing something before they told me.  Seems to be exiting from my
> local port now.
> 
> 
> 
> 
> 
> -Original Message-
> From: tor-relays  On Behalf Of
> Georg Koppen
> Sent: 24 March 2020 18:21
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] BadExit
> 
> Hi!
> 
> ger...@bulger.co.uk:
>> Oh the shame!   Never had that tag on my exit before.
> 
> Sorry to hear. :(
> 
>> 
>> 
>> I assume it was due to a bad boy attacking an IP, pointed out by my ISP,
> and
>> the ISP put my server "under mitigation".I assume some filtering,
> which
>> of course would have looked bad to TOR users.
>> 
>> 
>> 
>> I did not spot the ISP's email for 30 minutes, but then I was able to
>> block the offended IP.  Within minutes of doing that the ISP said
>> attack stop and my server was removed from mitigation.  However the
>> next day badexit tag on my exit and remains there
>> 
>> 
>> 
>> How long does the tag last?
> 
> So long as the Directory Authorities assign it.
> 
>> 
>> 
>> I go to my other, overseas exit, a family member, to see the tag is aslo
>> applied there to.Do family members get tarred with the same brush?
> 
> It depends on the reason for badexiting.
> 
>> 
>> 
>> I have turned both into relays for the time being.
>> 
>> 
>> 
>> 
>> 
>> Or have I got this wrong.   Is it a  DNS thing?  Are no some DNS providers
>> causing issues forcing the tag?   I am not using opendns.
> 
> It could be a DNS thing, I am not sure. I recently pushed a commit that
> leads to some exits getting that flag. I tried to contact all the relay
> operators beforehand (some did not have any ContactInfo set) but I got
> almost no reply back. For details see [1].
> 
> What's the fingerprint of your relay that got the badexit flag?
> 
> Georg
> 
> [1] https://trac.torproject.org/projects/tor/ticket/32864
> 
>> 
>> 
>> Gerry
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> 
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[gerard]

George

Thanks

My exit, still badexit, is  51AE5656C81CD417479253A6363A123A007A2233  and I
did get an email which I missed, as it is simply failing to exit, Implying
my ISP was doing something before they told me.  Seems to be exiting from my
local port now.





-Original Message-
From: tor-relays  On Behalf Of
Georg Koppen
Sent: 24 March 2020 18:21
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] BadExit

Hi!

ger...@bulger.co.uk:
> Oh the shame!   Never had that tag on my exit before.

Sorry to hear. :(

>  
> 
> I assume it was due to a bad boy attacking an IP, pointed out by my ISP,
and
> the ISP put my server "under mitigation".I assume some filtering,
which
> of course would have looked bad to TOR users.
> 
>  
> 
> I did not spot the ISP's email for 30 minutes, but then I was able to 
> block the offended IP.  Within minutes of doing that the ISP said 
> attack stop and my server was removed from mitigation.  However the 
> next day badexit tag on my exit and remains there
> 
>  
> 
> How long does the tag last?

So long as the Directory Authorities assign it.

>  
> 
> I go to my other, overseas exit, a family member, to see the tag is aslo
> applied there to.Do family members get tarred with the same brush?  

It depends on the reason for badexiting.

>  
> 
> I have turned both into relays for the time being. 
> 
>  
> 
>  
> 
> Or have I got this wrong.   Is it a  DNS thing?  Are no some DNS providers
> causing issues forcing the tag?   I am not using opendns.

It could be a DNS thing, I am not sure. I recently pushed a commit that
leads to some exits getting that flag. I tried to contact all the relay
operators beforehand (some did not have any ContactInfo set) but I got
almost no reply back. For details see [1].

What's the fingerprint of your relay that got the badexit flag?

Georg

[1] https://trac.torproject.org/projects/tor/ticket/32864

>  
> 
> Gerry
> 
>  
> 
>  
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] BadExit

[gerard]

Oh the shame!   Never had that tag on my exit before.

 

I assume it was due to a bad boy attacking an IP, pointed out by my ISP, and
the ISP put my server "under mitigation".I assume some filtering, which
of course would have looked bad to TOR users.

 

I did not spot the ISP's email for 30 minutes, but then I was able to block
the offended IP.  Within minutes of doing that the ISP said attack stop and
my server was removed from mitigation.  However the next day badexit tag on
my exit and remains there

 

How long does the tag last?

 

I go to my other, overseas exit, a family member, to see the tag is aslo
applied there to.Do family members get tarred with the same brush?  

 

I have turned both into relays for the time being. 

 

 

Or have I got this wrong.   Is it a  DNS thing?  Are no some DNS providers
causing issues forcing the tag?   I am not using opendns.

 

Gerry

 

 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit

[Georg Koppen]

Hi!

ger...@bulger.co.uk:
> Oh the shame!   Never had that tag on my exit before.

Sorry to hear. :(

>  
> 
> I assume it was due to a bad boy attacking an IP, pointed out by my ISP, and
> the ISP put my server "under mitigation".I assume some filtering, which
> of course would have looked bad to TOR users.
> 
>  
> 
> I did not spot the ISP's email for 30 minutes, but then I was able to block
> the offended IP.  Within minutes of doing that the ISP said attack stop and
> my server was removed from mitigation.  However the next day badexit tag on
> my exit and remains there
> 
>  
> 
> How long does the tag last?

So long as the Directory Authorities assign it.

>  
> 
> I go to my other, overseas exit, a family member, to see the tag is aslo
> applied there to.Do family members get tarred with the same brush?  

It depends on the reason for badexiting.

>  
> 
> I have turned both into relays for the time being. 
> 
>  
> 
>  
> 
> Or have I got this wrong.   Is it a  DNS thing?  Are no some DNS providers
> causing issues forcing the tag?   I am not using opendns.

It could be a DNS thing, I am not sure. I recently pushed a commit that
leads to some exits getting that flag. I tried to contact all the relay
operators beforehand (some did not have any ContactInfo set) but I got
almost no reply back. For details see [1].

What's the fingerprint of your relay that got the badexit flag?

Georg

[1] https://trac.torproject.org/projects/tor/ticket/32864

>  
> 
> Gerry
> 
>  
> 
>  
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit why?

[nusenu]

> Thank you for the answer. I try to get a new IP from the Trabia
> support.

that is not necessary if you can send your IP and wait
for the directory authorities to update their config.

Otherwise you might run into the same problem with the
next IP address at that network.





signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit why?

[Olaf Grimm]

Thank you for the answer. I try to get a new IP from the Trabia support.

Olaf



Am 12.02.19 um 21:51 schrieb David Goulet:
> On 12 Feb (21:35:29), Olaf Grimm wrote:
>>  inet 178.175.148.15
> Thanks Olaf!
>
> That IP was flagged as rewritting bitcoin addresses on Jan 21st, 2019.
>
> It appears you re-used a malicious IP from I.C.S. Trabia-Network S.R.L.
>
> Do you have an easy way to request a new IP for that Exit node or it is kind
> of a pain?
>
> Un-blacklisting a relay that is still not considered expired from our reject
> rule set can be a laborious process because essentially, we have to make a
> case to the directory authorities and they decide if they remove the rule or
> not based on our arguments ;).
>
> So changing the IP would be definitely the easiest way else we can try to
> convince the dirauth :).
>
> Sorry for the inconvenience!
> David
>
>> Am 12.02.19 um 21:34 schrieb David Goulet:
>>> On 12 Feb (21:30:10), Olaf Grimm wrote:
 Hello !

 I provisioning a new exit since two hours. It is a totally new relay in
 a VM. My other relays at the same provider are ok. Why I see "BadExit"
 in Nyx??? Now my first bad experience with my 11 relays...

 fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD
 Nickname Hydra10
>>> This relay is not yet on Relay Search:
>>>
>>> http://rougmnvswfsmd4dq.onion/rs.html#search/CCDC4A28392C7448A34E98DF872213BC16DB27CD
>>>
>>> I'm guessing it is quite new.
>>>
>>> That fingerprint is *not* set as a BadExit so this means you might have 
>>> gotten
>>> the IP address of an old BadExit.
>>>
>>> Can you share the address so I can look it up?
>>>
>>> Thanks!
>>> David
>>>
 At all exits I have the same firewall rules and torrc configs:

 ufw status
 Status: active

 To Action  From
 -- --  
 22/tcp ALLOW   Anywhere 
 9001/tcp   ALLOW   Anywhere 
 9030/tcp   ALLOW   Anywhere 
 80/tcp ALLOW   Anywhere 
 443/tcp    ALLOW   Anywhere 
 1194/tcp   ALLOW   Anywhere 
 53/tcp ALLOW   Anywhere 
 53/udp ALLOW   Anywhere 
 1194/udp   ALLOW   Anywhere 
 22/tcp (v6)    ALLOW   Anywhere (v6)
 9001/tcp (v6)  ALLOW   Anywhere (v6)
 9030/tcp (v6)  ALLOW   Anywhere (v6)
 80/tcp (v6)    ALLOW   Anywhere (v6)
 443/tcp (v6)   ALLOW   Anywhere (v6)
 1194/tcp (v6)  ALLOW   Anywhere (v6)
 53/tcp (v6)    ALLOW   Anywhere (v6)
 53/udp (v6)    ALLOW   Anywhere (v6)
 1194/udp (v6)  ALLOW   Anywhere (v6)

 Please take a look what happens.

 Olaf
 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit why?

[Damian Johnson]

Hi Olaf, Hydra10 is evidently no longer running so we can't tell you
why it got the flag. Your other Hydra* relays aren't flagged that way
so I wonder how Hydra10 differs.

https://metrics.torproject.org/rs.html#search/Hydra

On Tue, Feb 12, 2019 at 12:30 PM Olaf Grimm  wrote:
>
> Hello !
>
> I provisioning a new exit since two hours. It is a totally new relay in
> a VM. My other relays at the same provider are ok. Why I see "BadExit"
> in Nyx??? Now my first bad experience with my 11 relays...
>
> fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD
> Nickname Hydra10
>
> At all exits I have the same firewall rules and torrc configs:
>
> ufw status
> Status: active
>
> To Action  From
> -- --  
> 22/tcp ALLOW   Anywhere
> 9001/tcp   ALLOW   Anywhere
> 9030/tcp   ALLOW   Anywhere
> 80/tcp ALLOW   Anywhere
> 443/tcpALLOW   Anywhere
> 1194/tcp   ALLOW   Anywhere
> 53/tcp ALLOW   Anywhere
> 53/udp ALLOW   Anywhere
> 1194/udp   ALLOW   Anywhere
> 22/tcp (v6)ALLOW   Anywhere (v6)
> 9001/tcp (v6)  ALLOW   Anywhere (v6)
> 9030/tcp (v6)  ALLOW   Anywhere (v6)
> 80/tcp (v6)ALLOW   Anywhere (v6)
> 443/tcp (v6)   ALLOW   Anywhere (v6)
> 1194/tcp (v6)  ALLOW   Anywhere (v6)
> 53/tcp (v6)ALLOW   Anywhere (v6)
> 53/udp (v6)ALLOW   Anywhere (v6)
> 1194/udp (v6)  ALLOW   Anywhere (v6)
>
> Please take a look what happens.
>
> Olaf
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BadExit why?

[David Goulet]

On 12 Feb (21:30:10), Olaf Grimm wrote:
> Hello !
> 
> I provisioning a new exit since two hours. It is a totally new relay in
> a VM. My other relays at the same provider are ok. Why I see "BadExit"
> in Nyx??? Now my first bad experience with my 11 relays...
> 
> fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD
> Nickname Hydra10

This relay is not yet on Relay Search:

http://rougmnvswfsmd4dq.onion/rs.html#search/CCDC4A28392C7448A34E98DF872213BC16DB27CD

I'm guessing it is quite new.

That fingerprint is *not* set as a BadExit so this means you might have gotten
the IP address of an old BadExit.

Can you share the address so I can look it up?

Thanks!
David

> 
> At all exits I have the same firewall rules and torrc configs:
> 
> ufw status
> Status: active
> 
> To Action  From
> -- --  
> 22/tcp ALLOW   Anywhere 
> 9001/tcp   ALLOW   Anywhere 
> 9030/tcp   ALLOW   Anywhere 
> 80/tcp ALLOW   Anywhere 
> 443/tcp    ALLOW   Anywhere 
> 1194/tcp   ALLOW   Anywhere 
> 53/tcp ALLOW   Anywhere 
> 53/udp ALLOW   Anywhere 
> 1194/udp   ALLOW   Anywhere 
> 22/tcp (v6)    ALLOW   Anywhere (v6)
> 9001/tcp (v6)  ALLOW   Anywhere (v6)
> 9030/tcp (v6)  ALLOW   Anywhere (v6)
> 80/tcp (v6)    ALLOW   Anywhere (v6)
> 443/tcp (v6)   ALLOW   Anywhere (v6)
> 1194/tcp (v6)  ALLOW   Anywhere (v6)
> 53/tcp (v6)    ALLOW   Anywhere (v6)
> 53/udp (v6)    ALLOW   Anywhere (v6)
> 1194/udp (v6)  ALLOW   Anywhere (v6)
> 
> Please take a look what happens.
> 
> Olaf
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-- 
m14bORVXHT2lvx+QXt1QVjXPHX/hSBZzykB2ifCZFh0=


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] BadExit why?

[Olaf Grimm]

Hello !

I provisioning a new exit since two hours. It is a totally new relay in
a VM. My other relays at the same provider are ok. Why I see "BadExit"
in Nyx??? Now my first bad experience with my 11 relays...

fingerprint: CCDC4A28392C7448A34E98DF872213BC16DB27CD
Nickname Hydra10

At all exits I have the same firewall rules and torrc configs:

ufw status
Status: active

To Action  From
-- --  
22/tcp ALLOW   Anywhere 
9001/tcp   ALLOW   Anywhere 
9030/tcp   ALLOW   Anywhere 
80/tcp ALLOW   Anywhere 
443/tcp    ALLOW   Anywhere 
1194/tcp   ALLOW   Anywhere 
53/tcp ALLOW   Anywhere 
53/udp ALLOW   Anywhere 
1194/udp   ALLOW   Anywhere 
22/tcp (v6)    ALLOW   Anywhere (v6)
9001/tcp (v6)  ALLOW   Anywhere (v6)
9030/tcp (v6)  ALLOW   Anywhere (v6)
80/tcp (v6)    ALLOW   Anywhere (v6)
443/tcp (v6)   ALLOW   Anywhere (v6)
1194/tcp (v6)  ALLOW   Anywhere (v6)
53/tcp (v6)    ALLOW   Anywhere (v6)
53/udp (v6)    ALLOW   Anywhere (v6)
1194/udp (v6)  ALLOW   Anywhere (v6)

Please take a look what happens.

Olaf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] badexit 29378422C99074D06331D5700E47451610B0D20D

[eric gisse]

Will do next time. Wasn't sure which one to spew at.

Also, homeslice seemed to have turned off the SSH MITM. I'm sure it is
a coincidence it happened after I emailed the contact for the node.

I'm definitely going to write more modules and automate this better.
This is neat. I should have done this ages ago.

On Sat, Jul 29, 2017 at 9:11 PM, teor  wrote:
> Hi,
>
> I've cc'd bad-relays with this report.
>
> Please send reports of bad relays to bad-rel...@lists.torproject.org.
>
>> On 30 Jul 2017, at 02:56, eric gisse  wrote:
>>
>> it looks like i've found an exit node mitm-ing ssh, or at least giving
>> it a shot.
>>
>> https://atlas.torproject.org/#details/29378422C99074D06331D5700E47451610B0D20
>>
>> that exit policy looks more like a wishlist than anything else, at this 
>> point.
>>
>> notice all 3 sites have different clear wire ssh keys (obviously) but
>> all the same when connecting over tor. what a coincidence!
>>
>> module code:
>> https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py
>>
>> #  ./bin/exitmap sshmitm -e 29378422C99074D06331D5700E47451610B0D20D
>> 2017-07-29 16:52:36,797 exitmap [INFO] Attempting to invoke Tor
>> process in directory "/tmp/exitmap_tor_datadir-root".  This might take
>> a while.
>> 2017-07-29 16:52:36,798 exitmap [INFO] No first hop given.  Using
>> randomly determined first hops for circuits.
>> 2017-07-29 16:52:37,369 util [INFO] Tor Bootstrapped 0%: Starting
>> 2017-07-29 16:52:41,942 util [INFO] Tor Bootstrapped 80%: Connecting
>> to the Tor network
>> 2017-07-29 16:52:41,943 exitmap [INFO] Successfully started Tor
>> process (PID=31779).
>> 2017-07-29 16:52:42,117 exitmap [INFO] Running module 'sshmitm'.
>> 2017-07-29 16:52:42,269 modules.sshmitm [INFO] obtaining ssh key
>> information for destinations
>> 2017-07-29 16:52:42,269 modules.sshmitm [INFO] getting key for github.com
>> 2017-07-29 16:52:42,643 modules.sshmitm [INFO] getting key for gitlab.com
>> 2017-07-29 16:52:42,889 modules.sshmitm [INFO] getting key for bitbucket.com
>> 2017-07-29 16:52:58,807 relayselector [INFO] 216 relays have non-empty
>> exit policy but no exit flag.
>> 2017-07-29 16:52:58,816 relayselector [INFO] 1 out of 1000 exit relays
>> meet all filter conditions.
>> 2017-07-29 16:52:59,080 exitmap [INFO] Scan is estimated to take around 
>> 0:00:03.
>> 2017-07-29 16:52:59,080 exitmap [INFO] Beginning to trigger 1 circuit
>> creation(s).
>> 2017-07-29 16:53:02,018 exitmap [INFO] Done triggering circuit
>> creations after 0:00:02.937566.
>> 2017-07-29 16:53:04,169 modules.sshmitm [CRITICAL] tor ssh key
>> mismatch for github.com:22 (192.30.253.112) over exit relay
>> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
>> B3NzaC1yc2EBIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==,
>> over tor value:
>> B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
>> 2017-07-29 16:53:05,573 modules.sshmitm [CRITICAL] tor ssh key name
>> mismatch for gitlab.com:22 (52.167.219.168) over exit relay
>> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
>> ssh-ed25519, over tor value: ssh-rsa
>> 2017-07-29 16:53:05,574 modules.sshmitm [CRITICAL] tor ssh key
>> mismatch for gitlab.com:22 (52.167.219.168) over exit relay
>> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
>> C3NzaC1lZDI1NTE5IAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf,
>> over tor value:
>> B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
>> 2017-07-29 16:53:06,957 modules.sshmitm [CRITICAL] tor ssh key
>> mismatch for bitbucket.com:22 (104.192.143.8) over exit relay
>> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
>> B3NzaC1yc2EBIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==,
>> over tor value:
>> B3NzaC1yc2EDAQABAAABAQCD

Re: [tor-relays] badexit 29378422C99074D06331D5700E47451610B0D20D

[teor]

Hi,

I've cc'd bad-relays with this report.

Please send reports of bad relays to bad-rel...@lists.torproject.org.

> On 30 Jul 2017, at 02:56, eric gisse  wrote:
> 
> it looks like i've found an exit node mitm-ing ssh, or at least giving
> it a shot.
> 
> https://atlas.torproject.org/#details/29378422C99074D06331D5700E47451610B0D20
> 
> that exit policy looks more like a wishlist than anything else, at this point.
> 
> notice all 3 sites have different clear wire ssh keys (obviously) but
> all the same when connecting over tor. what a coincidence!
> 
> module code:
> https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py
> 
> #  ./bin/exitmap sshmitm -e 29378422C99074D06331D5700E47451610B0D20D
> 2017-07-29 16:52:36,797 exitmap [INFO] Attempting to invoke Tor
> process in directory "/tmp/exitmap_tor_datadir-root".  This might take
> a while.
> 2017-07-29 16:52:36,798 exitmap [INFO] No first hop given.  Using
> randomly determined first hops for circuits.
> 2017-07-29 16:52:37,369 util [INFO] Tor Bootstrapped 0%: Starting
> 2017-07-29 16:52:41,942 util [INFO] Tor Bootstrapped 80%: Connecting
> to the Tor network
> 2017-07-29 16:52:41,943 exitmap [INFO] Successfully started Tor
> process (PID=31779).
> 2017-07-29 16:52:42,117 exitmap [INFO] Running module 'sshmitm'.
> 2017-07-29 16:52:42,269 modules.sshmitm [INFO] obtaining ssh key
> information for destinations
> 2017-07-29 16:52:42,269 modules.sshmitm [INFO] getting key for github.com
> 2017-07-29 16:52:42,643 modules.sshmitm [INFO] getting key for gitlab.com
> 2017-07-29 16:52:42,889 modules.sshmitm [INFO] getting key for bitbucket.com
> 2017-07-29 16:52:58,807 relayselector [INFO] 216 relays have non-empty
> exit policy but no exit flag.
> 2017-07-29 16:52:58,816 relayselector [INFO] 1 out of 1000 exit relays
> meet all filter conditions.
> 2017-07-29 16:52:59,080 exitmap [INFO] Scan is estimated to take around 
> 0:00:03.
> 2017-07-29 16:52:59,080 exitmap [INFO] Beginning to trigger 1 circuit
> creation(s).
> 2017-07-29 16:53:02,018 exitmap [INFO] Done triggering circuit
> creations after 0:00:02.937566.
> 2017-07-29 16:53:04,169 modules.sshmitm [CRITICAL] tor ssh key
> mismatch for github.com:22 (192.30.253.112) over exit relay
> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
> B3NzaC1yc2EBIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==,
> over tor value:
> B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
> 2017-07-29 16:53:05,573 modules.sshmitm [CRITICAL] tor ssh key name
> mismatch for gitlab.com:22 (52.167.219.168) over exit relay
> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
> ssh-ed25519, over tor value: ssh-rsa
> 2017-07-29 16:53:05,574 modules.sshmitm [CRITICAL] tor ssh key
> mismatch for gitlab.com:22 (52.167.219.168) over exit relay
> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
> C3NzaC1lZDI1NTE5IAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf,
> over tor value:
> B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
> 2017-07-29 16:53:06,957 modules.sshmitm [CRITICAL] tor ssh key
> mismatch for bitbucket.com:22 (104.192.143.8) over exit relay
> 29378422C99074D06331D5700E47451610B0D20D clear wire value:
> B3NzaC1yc2EBIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==,
> over tor value:
> B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
> 2017-07-29 16:53:06,959 eventhandler [INFO] Ran 1 module(s) in
> 0:00:30.168619 and 0/

[tor-relays] badexit 29378422C99074D06331D5700E47451610B0D20D

[eric gisse]

it looks like i've found an exit node mitm-ing ssh, or at least giving
it a shot.

https://atlas.torproject.org/#details/29378422C99074D06331D5700E47451610B0D20

that exit policy looks more like a wishlist than anything else, at this point.

notice all 3 sites have different clear wire ssh keys (obviously) but
all the same when connecting over tor. what a coincidence!

module code:
https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py

#  ./bin/exitmap sshmitm -e 29378422C99074D06331D5700E47451610B0D20D
2017-07-29 16:52:36,797 exitmap [INFO] Attempting to invoke Tor
process in directory "/tmp/exitmap_tor_datadir-root".  This might take
a while.
2017-07-29 16:52:36,798 exitmap [INFO] No first hop given.  Using
randomly determined first hops for circuits.
2017-07-29 16:52:37,369 util [INFO] Tor Bootstrapped 0%: Starting
2017-07-29 16:52:41,942 util [INFO] Tor Bootstrapped 80%: Connecting
to the Tor network
2017-07-29 16:52:41,943 exitmap [INFO] Successfully started Tor
process (PID=31779).
2017-07-29 16:52:42,117 exitmap [INFO] Running module 'sshmitm'.
2017-07-29 16:52:42,269 modules.sshmitm [INFO] obtaining ssh key
information for destinations
2017-07-29 16:52:42,269 modules.sshmitm [INFO] getting key for github.com
2017-07-29 16:52:42,643 modules.sshmitm [INFO] getting key for gitlab.com
2017-07-29 16:52:42,889 modules.sshmitm [INFO] getting key for bitbucket.com
2017-07-29 16:52:58,807 relayselector [INFO] 216 relays have non-empty
exit policy but no exit flag.
2017-07-29 16:52:58,816 relayselector [INFO] 1 out of 1000 exit relays
meet all filter conditions.
2017-07-29 16:52:59,080 exitmap [INFO] Scan is estimated to take around 0:00:03.
2017-07-29 16:52:59,080 exitmap [INFO] Beginning to trigger 1 circuit
creation(s).
2017-07-29 16:53:02,018 exitmap [INFO] Done triggering circuit
creations after 0:00:02.937566.
2017-07-29 16:53:04,169 modules.sshmitm [CRITICAL] tor ssh key
mismatch for github.com:22 (192.30.253.112) over exit relay
29378422C99074D06331D5700E47451610B0D20D clear wire value:
B3NzaC1yc2EBIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==,
over tor value:
B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
2017-07-29 16:53:05,573 modules.sshmitm [CRITICAL] tor ssh key name
mismatch for gitlab.com:22 (52.167.219.168) over exit relay
29378422C99074D06331D5700E47451610B0D20D clear wire value:
ssh-ed25519, over tor value: ssh-rsa
2017-07-29 16:53:05,574 modules.sshmitm [CRITICAL] tor ssh key
mismatch for gitlab.com:22 (52.167.219.168) over exit relay
29378422C99074D06331D5700E47451610B0D20D clear wire value:
C3NzaC1lZDI1NTE5IAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf,
over tor value:
B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
2017-07-29 16:53:06,957 modules.sshmitm [CRITICAL] tor ssh key
mismatch for bitbucket.com:22 (104.192.143.8) over exit relay
29378422C99074D06331D5700E47451610B0D20D clear wire value:
B3NzaC1yc2EBIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==,
over tor value:
B3NzaC1yc2EDAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT
2017-07-29 16:53:06,959 eventhandler [INFO] Ran 1 module(s) in
0:00:30.168619 and 0/1 circuits failed (0.00%).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] badexit 03F84EA2E09CF427A519C65479DC0BF0D72886A6

[grarpamp]

router Tansam 79.143.87.234 443 0 0
03F84EA2E09CF427A519C65479DC0BF0D72886A6

Appears to be having trouble with, or is doing something with,
http versions of https en.wikipedia.org articles.
They're either blank or stripped of framework.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] badexit D9B6E8F3DC60095F25252A1986E90932454C24D3

[Philipp Winter]

On Sun, Jul 13, 2014 at 11:34:21AM +, Nusenu wrote:
> It hasn't got the badexit flag yet.

The relay operator wasn't aware of the problem and said he would look
into it on Monday.

> How long does it usually take for the dirauth operators to agree on
> that / deploy?

It can range from one hour to several days.  It's clearly not good
enough at this point and we are trying to get better at it.

> I also had in mind that there was a exit relay scanner (from Mike?) that
> would decrease response time. Is that still in place or are we depending
> on volunteers reporting badexits?

All exit relay scanners we are aware of are listed here:


Cheers,
Philipp
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] badexit D9B6E8F3DC60095F25252A1986E90932454C24D3

[Nusenu]

I also got certificate warnings when opening torbrowser.

Vidalia told me I'm using this exit as well.
It hasn't got the badexit flag yet.

How long does it usually take for the dirauth operators to agree on that
/ deploy?


I also had in mind that there was a exit relay scanner (from Mike?) that
would decrease response time. Is that still in place or are we depending
on volunteers reporting badexits?

thanks!


https://atlas.torproject.org/#details/D9B6E8F3DC60095F25252A1986E90932454C24D3

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] badexit D9B6E8F3DC60095F25252A1986E90932454C24D3

[Philipp Winter]

On Sat, Jul 12, 2014 at 02:27:53PM -0400, grarpamp wrote:
> Breaks TLS on check.torproject.org, etc.

Confirmed, thanks.  Seems to be the relay's ISP.  I contacted the
operator and hopefully she/he will be able to fix it.

Cheers,
Philipp
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] badexit D9B6E8F3DC60095F25252A1986E90932454C24D3

[grarpamp]

Breaks TLS on check.torproject.org, etc.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays