Re: [tor-relays] Fast flag - wrong speed in dir-spec.txt?
Yep makes sense now. Thanks for clearing this Roger:) Am Fr., 30. Aug. 2019 um 10:31 Uhr schrieb Roger Dingledine < a...@torproject.org>: > On Fri, Aug 30, 2019 at 05:52:22PM +1000, teor wrote: > > The default value for AuthDirFastGuarantee is still 100 KB. > >[...] > > 6/9 authorities use measured bandwidth, rather than reported bandwidth. > > So your relay won't get Fast unless it is measured by the bandwidth > authorities, > > faster than 100 KB. > > Right, it's this last part that's critical here. Directory authorities > that do their own "bandwidth authority" measurements use their bwauth > numbers rather than the self-reported numbers in the relay descriptor, > for deciding whether to assign flags. > > If you go to the very bottom of > https://consensus-health.torproject.org/#relayinfo > and put in this relay nickname or fingerprint, you'll see that 4 > directory authorities -- the ones not running bandwidth authorities -- > look at the self-reported number, and give the relay the Fast flag. But > 5 of them, which are running bwauths, use their own numbers, which put > the relay below the threshold. And since 5 is a majority of 9, their > choice wins. > > Hope that makes sense, > --Roger > > ___ > 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] Fast flag - wrong speed in dir-spec.txt?
On Fri, Aug 30, 2019 at 05:52:22PM +1000, teor wrote: > The default value for AuthDirFastGuarantee is still 100 KB. >[...] > 6/9 authorities use measured bandwidth, rather than reported bandwidth. > So your relay won't get Fast unless it is measured by the bandwidth > authorities, > faster than 100 KB. Right, it's this last part that's critical here. Directory authorities that do their own "bandwidth authority" measurements use their bwauth numbers rather than the self-reported numbers in the relay descriptor, for deciding whether to assign flags. If you go to the very bottom of https://consensus-health.torproject.org/#relayinfo and put in this relay nickname or fingerprint, you'll see that 4 directory authorities -- the ones not running bandwidth authorities -- look at the self-reported number, and give the relay the Fast flag. But 5 of them, which are running bwauths, use their own numbers, which put the relay below the threshold. And since 5 is a majority of 9, their choice wins. Hope that makes sense, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Please test bandwidth and resiliency of greyponyitnyc002
Hello, I was wondering if Rob would be willing to perform speed measurements on this node, it’s. 20 vcpu running CentOS 7 with manually compiled Tor against OpenSSL 1.1.1 on a 30Gbit link. I know it’s not going to see all of that bandwidth, it’s meant as a high powered VM platform because my intention is to start giving VMs back to the guys on my old infrastructure, and hopefully setup a “Torservers” type arrangement down the road, since this is hosted on unique ASN and addresses. Thanks, Conrad Rock Rockenhaus Greypony IT Consulting (254) 292-3350 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fast flag - wrong speed in dir-spec.txt?
Hi, > On 30 Aug 2019, at 17:21, Michael Gerstacker > wrote: > > Hi Torproject, > > as far as i can see my relay currently can advertise 560 KiB/s. That are > 573,44 KB/s. > 43C7BC2E17FB26B204EC0BD9AA784E4736979087 > > Following your dir-specs it should get the "Fast" flag if it can provide more > than 100KB/s. > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2595 The default value for AuthDirFastGuarantee is still 100 KB. I don't know if a majority of authority operators have set it higher. The other way a relay gets Fast is if it is in the fastest 7/8ths of the routers. > At my other relay i already saw it providing 562 KiB/s and it got the "Fast" > flag. > A9DB853547A6459AB5190E62BF2F7B8F068FEB0A > > It seems the limit is above 560 KiB/s? > If i remember it right then i already read somewhere that the requirements > are now higher than 100 KB/s so i guess your documentation is wrong? > Am i missing something why my relay with 560 KiB/s dont get the "Fast" flag? 6/9 authorities use measured bandwidth, rather than reported bandwidth. So your relay won't get Fast unless it is measured by the bandwidth authorities, faster than 100 KB. T 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] SSH scanning on TOR Exit - Nerfing Rules
Hi, > On 30 Aug 2019, at 09:26, AMuse wrote: > > I have SSH open as an exit port on a TOR exit that my friends and I are > maintaining - and of course it's the #1 offender by far in automated abuse > notifications we get from our ISP, from peoples' fail2ban servers sending > abuse emails. This all seems like a huge waste of time, but that's a separate > issue. > > I'm wondering if nerfing outbound SSH to rate limit will be effective at > getting the SSH scanning bots to stop using my exit in their circuit, while > leaving SSH open for actual humans who need to SSH while using TOR. I ran some large exits from 2016-2018, and I thought about this issue a lot. Usually while dealing with automated abuse mails. Ideally, we want a DoS mode that: * allows the first connection from a circuit at full speed * with each extra rapid connection, gradually slows connections from the same circuit There's a bunch of fine tuning we could do by port, traffic volume, and how busy other circuits are. But that needs to be implemented in Tor, because only Tor can see circuits. > I've implemented, as a test, rate limiting outbound on the SSH port. What do > you think the impact of this will be? No impact? Probably. > Losing exit status because connections on SSH die? Unlikely. I think Exitmap only measures HTTP(S). > Something else entirely? Maybe scanners will move to another exit. Maybe some SSH connections will be blocked, you should set your exit in a client's torrc and try it out: ExitNodes (fingerprint) StrictNodes 1 T 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
[tor-relays] Fast flag - wrong speed in dir-spec.txt?
Hi Torproject, as far as i can see my relay currently can advertise 560 KiB/s. That are 573,44 KB/s. 43C7BC2E17FB26B204EC0BD9AA784E4736979087 Following your dir-specs it should get the "Fast" flag if it can provide more than 100KB/s. https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2595 At my other relay i already saw it providing 562 KiB/s and it got the "Fast" flag. A9DB853547A6459AB5190E62BF2F7B8F068FEB0A It seems the limit is above 560 KiB/s? If i remember it right then i already read somewhere that the requirements are now higher than 100 KB/s so i guess your documentation is wrong? Am i missing something why my relay with 560 KiB/s dont get the "Fast" flag? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] SSH scanning on TOR Exit - Nerfing Rules
Hi all! I'm curious what y'all think of this situation.
I have SSH open as an exit port on a TOR exit that my friends and I are
maintaining - and of course it's the #1 offender by far in automated abuse
notifications we get from our ISP, from peoples' fail2ban servers sending
abuse emails. This all seems like a huge waste of time, but that's a
separate issue.
I'm wondering if nerfing outbound SSH to rate limit will be effective at
getting the SSH scanning bots to stop using my exit in their circuit, while
leaving SSH open for actual humans who need to SSH while using TOR.
I've implemented, as a test, rate limiting outbound on the SSH port. What
do you think the impact of this will be? No impact? Losing exit status
because connections on SSH die? Something else entirely?
Here's the pf rules in question:
pass in on $ext_if proto {tcp udp} from any to any port 9000:9150 keep state
pass in on $ext_if proto tcp from any to any port 22 keep state
pass in on $ext_if proto tcp from any to any port 80 keep state
pass out on $ext_if from any to any keep state
pass out on $ext_if proto tcp from any to any port 22 keep state
(max-src-conn 25, max-src-conn-rate 1/5 )
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
