- tor-relays - lists.torproject.org

network scan results for CVE-2016-5696 / rfc 5961
by dawuud 12 Dec '16

12 Dec '16

Greetings Tor relay operators, First of all, if you operate non-Linux Tor relays then good job! Thanks! This notice isn't for you. Only Linux is affected. This morning I scanned the tor network for vulnerability to CVE-2016-5696 [1], again so that I could compare the results with the scan from last month. Linux implemented RFC 5961 [2] using a global counter which can be used as a side channel allowing blind TCP injection and other consequences as well. I used this collector consensus file for my scan: https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-… That's 7080 relays. The scan produced: 246 relays had connection timeouts and were not scanned. 60 relays had connection refused. 6795 relays scanned. 2034 relays are vulnerable according to the rationale I used a month ago to categorized the results as vulnerable (if the probe response receives between 90 and 220 Challenge ACKs). These results should be reproducible. The source code to the scanner is here: https://github.com/david415/scan_tor_rfc5961 Last month's scan showed 4069 vulnerable relays. Each probe does a TCP handshake and then sends 500 in-window packets and counts the resulting Challenge ACKs. (followed by a TCP connection close). However we've updated the buckets of probe results to this: "r == 0" : "zero challenge ACKs", "0 < r <= 10" : "probably new kernel", "10 < r <= 20" : "maybe new kernel?", "20 < r <= 90" : "inconclusive?", "90 < r < 100" : "probably vulnerable", "(r%100)==0 and 0<r<500" : "almost definitely vulnerable", "(r%100)!=0 and 100<r<450" : "probably vulnerable", "(r%100)!=0 and 450<=r<=490" : "inconclusive?", "490 < r < 500" : "most likely applied sysctl workaround", "r == 500" : "probably applied sysctl workaround", "500 < r" : "extra duplicate packets?", The researchers who discovered this vulnerability published an excellent paper [3]. Although they incorrectly described an attack on tor's path selection it may be possible that other attacks on the Tor network are possible. I think it would be better to upgrade and reboot your relays rather than risk the Tor network's exposure to attacks that may utilize CVE-2016-5696 in combination with other techniques. Furthermore being vulnerable to CVE-2016-5696 also implies that you have a Linux kernel which is also vulnerable to dirty COW; https://dirtycow.ninja If you operate a relay you can check to see if your relay's TCP stack has counted many TCP Challenge ACKs. Please let us know if your counters have very high values. Vulnerable Linux kernels will have snmp stat counters like this:: root:/# netstat -s | grep -i challenge TCPChallengeACK: 113338 TCPSYNChallenge: 1157 High counter values maybe indicative of attacks. Linux 4.7.x has got a per socket rate limiting feature which if it has a high value may also be indicative of attack attempts and probing:: root:/# netstat -s | grep -i challenge TCPChallengeACK: 2614 TCPSYNChallenge: 442 TCPACKSkippedChallenge: 141795 If you are too lazy to upgrade your Linux kernel and reboot then you may apply a convenient workaround: sysctl net.ipv4.tcp_challenge_ack_limit=9999999999 read more about this workaround here: https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-sta… Special thanks to Least Authority for supporting my research. sincerely, David Stainton 1. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 2. https://tools.ietf.org/html/rfc5961 3. Off-Path TCP Exploits: Global Rate Limit Considered Dangerous http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf

12 29

Inconsistent BW measurements of unused relay
by Rana 12 Dec '16

12 Dec '16

My relay remains severely under-used. One thing that bothers me are inconsistent bandwidth measurements. Here they are: Atlas "advertised" (which is actually supposed to be "measured"?: 100 KB/s = ~ 800,000 bit/s "I have sent" reported in Tor log: on the average pretty stable 17 mbytes every 6 hours = ~ 200 bit/s Atlas graphs: 1 Kbytes/s on the average ~ 8,000 bit/s Consensus BW: 26 = ~ 26,000 bit/s Average upload bw reported by arm: 100 kb/s = ~ 100,000 bit/s Makes zero sense.

3 8

ansible for tor relay ops
by nusenu 11 Dec '16

11 Dec '16

> You are quite often referring to Ansible which is new to me. Is there > a permanent free version around to let your > https://github.com/nusenu/ansible-relayor run on it? Yes ansible is free software and you can install it with your preferred package manager (depending what OS you use). > Isn’t it somehow dangerous in the area we operate, to rely on a piece > of software created more or less by a single person? Thanks for this question. Can you give a few examples for "dangerous" in the context of your question so I might be able to address your concerns more specifically? thanks, nusenu

2 1

Atlas - location of relay changed
by Duncan Guthrie 10 Dec '16

10 Dec '16

Hi folks, My Tor exit, ecntor, recently changed from being listed in the UK to being listed in Canada, without any input on our part. On the IRC channel, I was reassured that this was not a bad thing, that GeoIP is inaccurate, for example. However, I am interested in what might have caused the relay to change location listing like this? Thanks, Duncan

2 1

Connections from UNKNOWN relays
by Rana 10 Dec '16

10 Dec '16

Arm shows that my middle relay has incoming connections from UNKNOWN relays (no consensus data on them at all except locale). Are these bridges? There is also one outgoing connection to UNKNOWN but the address of that is 0.0.0.0:0

3 3

Re: [tor-relays] torworld relays in entry and exit position
by nusenu 10 Dec '16

10 Dec '16

Security TorWorld wrote (2016-11-14): > We believe that next month on the 1st of December would be a good time > to add this feature. What is the current state on this? You are still on the top of this list: https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan…

3 2

0.2.8.11 bridge + hidden service, restart loop
by Petrusko 10 Dec '16

10 Dec '16

Hey, Compiled current 0.2.8.11 (git-c49e563d0096aa5d) on a RPi, set up as a bridge + hidden service (http) Before update, everything was fine. Now, it's starting only fine when only bridge is enabled.... If hidden service is enabled in torrc, some problems : - restart loop - /var/log/tor/notices.log is not used. but can watch log in /var/log/syslog file... Custom hostname + private_key in hidden_service, it was nice before... Thx for your help :) Dec 9 23:48:06 XXX systemd[1]: Starting Anonymizing overlay network for TCP... Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.336 [notice] Tor v0.2.8.11 (git-c49e563d0096aa5d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.342 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.343 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.343 [notice] Read configuration file "/etc/tor/torrc". Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.399 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742 Dec 9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.405 [notice] Based on detected system memory, MaxMemInQueues is set to 361 MB. You can override this by setting MaxMemInQueues by hand. Dec 9 23:48:08 XXX tor[3935]: Configuration was valid Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.088 [notice] Tor v0.2.8.11 (git-c49e563d0096aa5d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.093 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.093 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.094 [notice] Read configuration file "/etc/tor/torrc". Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.151 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742 Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.157 [notice] Based on detected system memory, MaxMemInQueues is set to 361 MB. You can override this by setting MaxMemInQueues by hand. *Dec 9 23:48:10 XXX systemd[1]: tor(a)default.service: main process exited, code=exited, status=1/FAILURE** **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied** **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.** **Dec 9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [err] Reading config failed--see warnings above.** **Dec 9 23:48:10 XXX systemd[1]: Failed to start Anonymizing overlay network for TCP.** **Dec 9 23:48:10 XXX systemd[1]: Unit tor(a)default.service entered failed state.** **Dec 9 23:48:10 XXX systemd[1]: tor(a)default.service holdoff time over, scheduling restart.* Dec 9 23:48:10 XXX systemd[1]: Stopping Anonymizing overlay network for TCP... Dec 9 23:48:10 XXX systemd[1]: Starting Anonymizing overlay network for TCP... -- Petrusko EBE23AE5

2 1

Exit Node Geographical Location
by Chris Adams 09 Dec '16

09 Dec '16

Hello, I want to start up another exit node. I have a few choices for which country it's in. I currently live in a country with quite a high exit node/population density. Are there any advantages to distributing nodes around the globe in terms of performance/privacy? Are there some countries where you definitely shouldn't run exit nodes? (Censored internet is an obvious example) C

7 10

Belarus (finally) bans Tor
by Rana 09 Dec '16

09 Dec '16

https://ooni.torproject.org/post/belarus-fries-onion/

1 0

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by Rana 09 Dec '16

09 Dec '16

-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of pa011 Sent: Tuesday, December 06, 2016 1:24 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP > I would like to hear about ONE Raspi Tor operator who was allowed by DirAuths (or bwauths or whatever) to come even near 1 mbit/s bandwidth utilization > let me tell: https://atlas.torproject.org/#details/AA44C4BE3C90DCAAC09E5CD26150710AAA80D… https://atlas.torproject.org/#details/CA9A5D5C4688F04EEC1AF810B0FD348109FA1… are sharing the same dynamic IP on a Rasp2 -cut every 24 hours day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 05.12.2016 27,20 GiB | 28,39 GiB | 55,59 GiB | 5,40 Mbit/s that is slight above 1 Mbit/s :-) Best regards Paul ---------------------------- Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each? Definitely refutes the previously claimed 1 Mbit/s Tor limit on Raspi, and means that Raspi has nothing to do with the ridiculously low utilization of my relay, just as I thought. As a matter of fact this means that whoever is NOT running a relay on a Raspi (or two, or four of them) is wasting money, unless he has a computer lying about with nothing better to do. Also, what's the max memory and CPU utilization on your Raspi (I have read somewhere that Tor is only capable of utilizing 2 of the 4 CPU cores), and what kind of Internet connection do you have? BTW the $35 Raspi 3 has 33% more CPU power than your Raspi 2 and the same amount of memory. Rana

14 36