- tor-relays - lists.torproject.org

Re: [tor-relays] Second relay on same ESX
by balbea16 12 Dec '16

12 Dec '16

Hi Are you actually talking about identical relays, i.e. with the same fingerprint? That would be interessting for me, as I'd like to run a second Rasp Pi in parallel for redundency reasons.Mike -------- Ursprüngliche Nachricht -------- Von: Patrick DERWAEL <patrick(a)derwael.be> Datum: 12.12.16 06:41 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Second relay on same ESX John, The host has 32GB RAM& 4 CPUs I have allocated 2GB & 2CPUs to my VM As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would it then be used at 80% average?) P. 2016-12-11 18:22 GMT+01:00 John Ricketts <john(a)quintex.com>: Patrick, I run all of my relays under VMware and I don't have any issues at all. How many CPUs do you have in the physical server and how many virtual CPUs do you have assigned to the VM? John On Dec 11, 2016, at 11:19, Patrick DERWAEL <patrick(a)derwael.be> wrote: Hi guys, I'm running a relay in a VM on a physical server which is largely under used Current advertised bandwidth 26MB, consensus 76500 I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: - is there any issue running it at the same geographical place? - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? - basically, would it have any significant added value to the network? Thanks _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Patrick Derwael Rue de la fontaine, 3 4210 Burdinne G:0479.80.50.79

3 2

Re: [tor-relays] Second relay on same ESX
by balbea16 12 Dec '16

12 Dec '16

Hi Tim,TNX for your fast response. That was more or less what I thought already. Mike -------- Ursprüngliche Nachricht -------- Von: teor <teor2345(a)gmail.com> Datum: 12.12.16 07:28 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Second relay on same ESX > On 12 Dec. 2016, at 17:08, balbea16 <balbea16(a)gmx.de> wrote: > > Hi > Are you actually talking about identical relays, i.e. with the same fingerprint? That would be interessting for me, as I'd like to run a second Rasp Pi in parallel for redundency reasons. > Mike Please don't run a second relay on the same fingerprint. Your relay won't get much traffic, because it will look like its address and ports are changing all the time. Instead, run two relays with different keys, and let the network load-balance between them. Tim > -------- Ursprüngliche Nachricht -------- > Von: Patrick DERWAEL <patrick(a)derwael.be> > Datum: 12.12.16 06:41 (GMT+01:00) > An: tor-relays(a)lists.torproject.org > Betreff: Re: [tor-relays] Second relay on same ESX > > John, > The host has 32GB RAM& 4 CPUs > I have allocated 2GB & 2CPUs to my VM > As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would it then be used at 80% average?) > > P. > > 2016-12-11 18:22 GMT+01:00 John Ricketts <john(a)quintex.com>: > Patrick, > > I run all of my relays under VMware and I don't have any issues at all. > > How many CPUs do you have in the physical server and how many virtual CPUs do you have assigned to the VM? > > John > > On Dec 11, 2016, at 11:19, Patrick DERWAEL <patrick(a)derwael.be> wrote: > >> Hi guys, >> >> I'm running a relay in a VM on a physical server which is largely under used >> Current advertised bandwidth 26MB, consensus 76500 >> I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: >> >> - is there any issue running it at the same geographical place? >> - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? >> - basically, would it have any significant added value to the network? >> >> Thanks >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > -- > Patrick Derwael > Rue de la fontaine, 3 > 4210 Burdinne > G:0479.80.50.79 > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Second relay on same ESX
by Patrick DERWAEL 12 Dec '16

12 Dec '16

Hi guys, I'm running a relay in a VM on a physical server which is largely under used Current advertised bandwidth 26MB, consensus 76500 I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: - is there any issue running it at the same geographical place? - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? - basically, would it have any significant added value to the network? Thanks

4 5

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