November 2016 - tor-relays - lists.torproject.org

Monitoring multiple relays
by Xza 01 Nov '17

01 Nov '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I have a couple relays / exits running. Now my question is : how do you manage them is there any dashboard or CLI tools to manage them ( statistics, ect.. ) I know the cli tool specially for Tor "arm" Thanks alot. - -- PGP : 29A4CE52 -----BEGIN PGP SIGNATURE----- iQI4BAEBCgAiGxxEbyA8eWFuZGVyZXNvbkByaXNldXAubmV0PgUCV0SJlwAKCRBI of/XNyszSvv/D/9VtjI+bmiqK53v//StUbmpYjgQjYheYvwktFld+2XDURh52dmU sbk3lab2RS1eQJxjV0BVXMF9O2JUAlp4NA2UMpj8ZJlCk0h1S6p2o4/sAlsrHr8Z nb67HiaRIyEvi9cQiXFtDtK/onAkEuKskolyvh3ysJRRUubHSX1z8WuNJIc4xyGH ZpSLPGUOO6qI7mM8ztS0muEy1khmkHgtlyHi2l4K/NsW3I90cV3w6Db2AEnV6v1c tsfehqLExsHUdEo0U3hHU7yY1p2fzD5Z+C0tgVKTnP5Zus/Vr9OH/zFwxneo0E7a 5FHdnCZnNIG9W32uQgjDdmBEv/YFEd0um/vMWFGUehFANSt+DIps7E+AjwiJwm2i ov97JJurQkrSMX7ZchTEsy720Ju272olp2eDiHaXXTK2TkxcEq+d1gZfj7CXycPW 6mCrj6L6URJAZ34GJQfFFjv8QbFmKkAvGhxl/O8KXRbXxedbLH7PY73jmFjJcmxO +KnSeyqMe1KbzazYyFydP+VmgI2k1IlO89l8Jq1Gq9f2KOPY9UKFZjGDKLS0xGZW EnqU/KUINcrGejYFT8nYNxA+OFTd/ZGIX5qP4Vo5NsZ/pDLZjdxIcvHx1jjZbER+ 5Ku2bihm2KTNAGoYDqB3LGCm+QdEFG/p573xQCcXPk92GyhMJDi9EMPDgA== =mTa0 -----END PGP SIGNATURE-----

8 8

Please enable IPv6 on your relay!
by Moritz Bartl 28 Jan '17

28 Jan '17

Hi! We still have a depressingly low number of relays that support IPv6 (currently only ~120 of ~1900 relays). If your host supports IPv6, please enable it, especially if you run an exit! This has to be done explicitly. https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto In short, you add: ORPort [IPv6::address]:port IPv6Exit 1 ExitPolicy reject6 *:* (or a more open exit policy respectively) Thanks! -- Moritz Bartl https://www.torservers.net/

30 42

torworld relays in entry and exit position
by nusenu 14 Jan '17

14 Jan '17

Hi torworld, thanks for joining the tor network with your relays! You are operating entry and exit relays without proper 'MyFamily' configuration, this can be dangerous for tor clients because they might choose you as entry _and_ exit relay, please help protect tor clients by properly specifying the MyFamily configuration in your torrc files. If you need any help please let us know. https://www.torworld.org/ https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… https://lists.riseup.net/www/arc/ornetradar/2016-10/msg00101.html kind regards, nusenu https://github.com/nusenu/ansible-relayor

1 1

is it possible to relay using ipv6?
by Flavio Leitner 19 Dec '16

19 Dec '16

Hi, I am trying to configure a relay for the first time but I am behind a cgnat for IPv4. I have a public and open IPv6 though. However, ORPort doesn't accept [ipv6]:443 and it doesn't automatically bind to :::443 either. This is running LEDE tor 0.2.8.9-1. I couldn't find if worth to run over IPv6 or not. Thanks, -- Flavio

10 25

Netflix overblocking non-exit Tor relays
by Gero Kuehn 16 Dec '16

16 Dec '16

tl;dr: Even paying customers sharing IPs with non-exit Tor relays are now blocked from accessing Netflix Hello everyone ! After two very fruitless attempts to get the issue silently resolved through proper Netflix support channels, the time has come to make this public. As some of you have probably already read in the news, Netflix recently announced a crackdown on what they call "VPN Pirates" and what I call "paying customers using the same benefits of globalization that global companies like Netflix (ab)use for their taxes". They have now obviously changed their strategy regarding the Tor network. I am operating (among others) a middle-relay on a German residential fixed-ip VDSL-50 line (dc6jgk1/486740353B905AA4731F82C0B4CC25821A62C6E3) behind a NAT. Until 2 days ago, none of the devices sharing the same external IP address had any problem connecting to Netflix and there never was a Tor exit relay on that IP as far as I can tell. It is also obviously not possible for users of the Tor network to connect to Netflix through middle relays. As a consequence they should not be classifying such IP addresses as VPNs/Proxies and they should not be blocking them. This has been escalated and explained twice to "technical supervisors" in their callcenters. They did however not leave the impression that they a) care or b) intend to fix this at some point by parsing the Tor network information properly instead of using whatever cheap&wrong hack they use now. The official response from Netflix is that you now need to make a choice between operating that Tor relay (of any type) and the ability to watch Netflix. They also strictly refuse to refund any remaining credit in the customer account. My personal choice with regards to that blackmailing is as clear my next steps (conditional cancellation, 14 day deadline for refund and a legal challenge of their German AGB with regards to this issue). I am allergic to being blackmailed like that and being called a pirate by a service I legitimately paid for. For those of you who just would like to contribute to the Tor network without having trouble like that, please do not let this nonsense stop you. A more diversified Tor network is a more healthy network and I would really like to see more normal users operating tor relays operating in as many different locations as possible - including DSL lines "that are there anyways". If you do not want to be put into a position where you have to choose between your contribution to the network and some legal and paid-for entertainment, you might want to operate only a bridge until the issue has been resolved. If you already have the same problem, make it as expensive for Netflix as possible and spread the word about why this block (and geoblocking in general) is wrong. Thanks ! Kind regards, Gero / dc6jgk

14 21

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

LLC vis-à-vis Nonprofit
by Kenneth Freeman 04 Dec '16

04 Dec '16

An Idaho nonprofit has expressed guarded interest in Tor. Ideally I'd like them to run an exit node without fuss or bother, but the Tor Project's Tips on Running an Exit Node only covers limited liability corporations (LLCs) regarding the legal/corporate set-up. Is there anything to add, or is that sufficient? Thanks in advance.

3 5

Re: [tor-relays] [OrNetRadar] AS: "Choopa, LLC" - Linux (20), "GMO Internet, Inc" (10)
by nusenu 30 Nov '16

30 Nov '16

I hope you got them on your radar as well. Wondering for which HS they will become the hsdir +------------+----------+-------+----------------------+ | FP | nickname | hsdir | as_name | +------------+----------+-------+----------------------+ | 0759DB6F6C | schedule | 0 | GMO Internet,Inc | | 0759DB6F9F | dengue | 0 | GMO Internet,Inc | | 0759DB6FA6 | Almond | 0 | GMO Internet,Inc | | 09A54DB0F2 | epitome | 1 | Choopa, LLC | | 09A54DB35E | euler | 0 | GMO INTERNET PTE LTD | | 09A54DB3F5 | niche | 1 | GMO Internet,Inc | | 1F00D604D2 | Unnamed | 0 | Choopa, LLC | | 2FDDD920C8 | fufu | 0 | Choopa, LLC | | 32E71B90DA | zebra | 0 | GMO Internet,Inc | | 3968276F7A | pizza | 0 | Choopa, LLC | | 71363B816E | dessert | 0 | GMO Internet,Inc | | 71363B83B2 | bury | 0 | GMO Internet,Inc | | 905CC77C4B | sour | 0 | Choopa, LLC | | A0E83AA0E2 | bowl | 1 | GMO Internet,Inc | | A0E83AA191 | truth | 1 | GMO INTERNET PTE LTD | | A0E83AA283 | develop | 1 | Choopa, LLC | | DE2702F4E5 | genre | 1 | Choopa, LLC | | EBF154D8BB | quinoa | 1 | Choopa, LLC | | EBF154D9E2 | quote | 1 | Choopa, LLC | | EBF154DA21 | monk | 1 | Choopa, LLC | | F87AD9C6A1 | caker | 0 | Choopa, LLC | | FD1F34023C | Unnamed | 0 | Choopa, LLC | +------------+----------+-------+----------------------+ ornetradar(a)riseup.net: > 2016-11-23 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | CC | ORp | Dirp |Version | ContactInfo | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 0 |03:34:42| 45.76.128.202 | us | 9001 | 9030 |0.2.8.9 | None | epitome | 1 > 1 | 0 |03:34:46| 45.76.128.202 | us | 9002 | 9031 |0.2.8.9 | None | develop | 1 > 0 | 0 |07:08:45| 45.32.48.248 | jp | 9001 | 9051 |0.2.8.9 | None | caker | 1 > 0 | 0 |07:13:14| 45.32.48.248 | jp | 9001 | 9051 |0.2.8.9 | None | caker | 1 > 0 | 0 |07:22:52| 45.32.48.248 | jp | 9002 | 9052 |0.2.8.9 | None | fufu | 1 > 0 | 0 |15:09:32| 104.238.165.134 | us | 9001 | 9030 |0.2.8.9 | None | pizza | 1 > 0 | 0 |15:09:44| 104.238.165.134 | us | 9002 | 9031 |0.2.8.9 | None | monk | 1 > 1 | 0 |17:20:05| 104.238.165.134 | us | 9001 | 9030 |0.2.8.9 | None | pizza | 1 > 1 | 0 |17:23:04| 104.238.165.134 | us | 9002 | 9031 |0.2.8.9 | None | monk | 1 > 1 | 0 |18:25:05| 107.191.47.191 | fr | 9001 | 9030 |0.2.8.9 | None | genre | 1 > 1 | 0 |18:27:05| 107.191.47.191 | fr | 9002 | 9031 |0.2.8.9 | None | quote | 1 > 1 | 0 |19:15:05| 45.63.20.92 | us | 9001 | 9030 |0.2.8.9 | None | sour | 1 > 1 | 0 |19:17:05| 45.63.20.92 | us | 9002 | 9031 |0.2.8.9 | None | quinoa | 1 > 1 | 0 |12:30:24| 150.95.143.40 | jp | 9001 | 9030 |0.2.8.9 | > 1 | 0 |12:30:29| 150.95.143.40 | jp | 9002 | 9031 |0.2.8.9 | > 1 | 0 |12:33:54| 133.130.122.105 | jp | 9001 | 9030 |0.2.8.9 | > 1 | 0 |12:34:02| 133.130.122.105 | jp | 9002 | 9031 |0.2.8.9 | > 0 | 0 |12:41:09| 150.95.142.186 | jp | 9001 | 9030 |0.2.8.9 | > 0 | 0 |12:41:14| 150.95.142.186 | jp | 9002 | 9031 |0.2.8.9 | > 1 | 0 |13:30:05| 163.44.113.116 | us | 9001 | 9030 |0.2.8.9 | > 1 | 0 |13:35:05| 163.44.113.116 | us | 9002 | 9031 |0.2.8.9 | > 1 | 0 |14:50:05| 150.95.142.186 | jp | 9001 | 9030 |0.2.8.9 | > 1 | 0 |14:55:05| 150.95.142.186 | jp | 9002 | 9031 |0.2.8.9 |

1 0

Assigning new IP adrees to current relay
by Sec INT 30 Nov '16

30 Nov '16

Hi I have more than one ip address in a server - I want to assign a new ip to a current relay that I am running. The new ip is correctly setup on my ubuntu server so i know thats ok In order to make the relay use the new ip I added Address <New IP Address> to the torrc file and restarted tor - this did seem to work and tor detectedthe new address and started to use it but then I got a number of warnings like 'Remote server sent bogus reason code' The relay does seem to be working but with these errors im not sure - is the method above how you should assign a particular IP address to a Tor relay? Thanks for any advice Snap

3 9

re
by dark side 29 Nov '16

29 Nov '16

re

1 0