- tor-relays - lists.torproject.org

cryptsetup some folders
by Petrusko 26 Oct '16

26 Oct '16

Hey all, I'm planning to customise a RPi with Raspbian already running, and using cryptsetup (LUKS) to have a partition more secure for some reasons... So the goal is to move some existing sensitive folders to this new encrypted partition. Some sym-links will be used for those directories. About Tor, if I'm not wrong, those directories can be moved to this encrypted partition : /var/lib/tor : so I'm planning to move /var... So at final, planning to move : /home /var /tmp (why not swap file ?) Any suggestions and master's thoughts are welcome :) -- Petrusko EBE23AE5

7 17

Re: [tor-relays] most (>57% cwfr) of the tor network still vulnerable to CVE-2016-8860 - update your relay!
by Alan 26 Oct '16

26 Oct '16

Thanks for the update, my main relay was vulnerable but i've patched it now to 0.2.8.9. My Raspberry Pi is running 0.2.5.12 -- is that ok? > just a reminder since most of the tor network (including some of the biggest operators) still runs vulnerable relays > > https://blog.torproject.org/blog/tor-0289-released-important-fixes > > > Since 2/3 directory authorities removed most vulnerable versions from their 'recommended versions' you should see a log entry if you run outdated versions (except if you run 0.2.5.12). > > > It is not possible to reliable determine the exact CW fraction > affected[1] due to the fact that patches were released that didn't increase tor's version number. > Therefore it is also possible that you get log entries even if you run a patched version (IMHO this hasn't been handled in the most professional way). > > > Update instructions > > Debian/Ubuntu > ============== > > make sure you use the Torproject repository: > https://www.torproject.org/docs/debian.html.en > > (you can also use the debian repository but the Torproject's repo will provide you with the latest releases) > > > aptitude update && aptitude install tor > > > CentOS/RHEL/Fedora > =================== > > yum install --enablerepo=epel-testing tor > > > FreeBSD > ============ > > pkg update > pkg upgrade > > OpenBSD > =========== > > pkg_add -u tor > > > Windows > ======== > > No updated binaries available for this platform yet. > > > > > [1] as of 2016-10-25 18:00 (onionoo data) > conservative estimate > ---------------------- > (counts only 0.2.8.9 and 0.2.9.4-alpha as patched) > 31% CW fraction patched > > optimistic estimate > ------------------- > (additionally assumes every non-Windows running 0.2.4.27, 0.2.5.12, 0.2.6.10, 0.2.7.6 that restarted since 2016-10-17 is patched): > 43% CW fraction patched > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

33C3 Voucher
by pa011 26 Oct '16

26 Oct '16

Anybody holding a Voucher for 33C3 in Hamburg at the End of December? More than happy to get hold of it :-) Paul

2 1

Research project - comparing abuse complaints on Tor exits to those of regular ISPs
by dguthrie＠posteo.net 24 Oct '16

24 Oct '16

Hi folks, I am looking to research what proportion of Tor traffic across a Tor exit is "legitimate"/regular internet traffic, by comparing abuse complaints on Tor exits to those of regular ISPs. I think this is an interesting project because it is illegal to analyse traffic on the exit node without amounting to a wiretap, so this is a good way to get some idea about what traffic is comparable to regular internet traffic. I am aware that some people on this list run small ISPs. I am asking a favour that you might be able to send me a sample of abuse complaints over several months, or at least and some idea of how many complaints you recieved. I would need to know what type of complaint they were (torrenting vs more serious complaints), and the volume of traffic that passed through your network. My public key is posted below. Thank you, Duncan Guthrie 4096R/16BD5A5D 425A BEE8 24BB 7665 7FDC F7B6 8767 0301 16BD 5A5D

6 6

Re: [tor-relays] IP address change
by balbea16 24 Oct '16

24 Oct '16

Hi TimTNX for your fast response. I'm afaid, that I have to stay with my current ISP. However, from time to time he keeps my IP address unchanged for up to 4 days. Mike -------- Ursprüngliche Nachricht -------- Von: teor <teor2345(a)gmail.com> Datum: 24.10.16 14:34 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] IP address change > On 24 Oct. 2016, at 23:12, balbea16 <balbea16(a)gmx.de> wrote: > > Hi There > My ISP changes my IP address about every 24 hours. It takes 10 minutes until my tor server recognises this, and an hour until all usual connections are reestablished. How can I speed this up? The tor directory authorities vote on relays every hour. There is no way to speed this up. > Does it help to use a DNS? No, Tor uses your IP address. > To pay for a static address is not an option. > Any ideas? Thank you. Mike I'm sorry, this is just how Tor is designed. But you are still contributing to the network. You could try renting a cheap server in a data centre. Most of them offer static IP addresses. Tim 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

IP address change
by balbea16 24 Oct '16

24 Oct '16

Hi There My ISP changes my IP address about every 24 hours. It takes 10 minutes until my tor server recognises this, and an hour until all usual connections are reestablished. How can I speed this up? Does it help to use a DNS? To pay for a static address is not an option. Any ideas? Thank you. Mike

2 1

numtcpsock prevents relay from working properly.
by Nils Erik Flick 24 Oct '16

24 Oct '16

Hi, I am experiencing trouble with a new VPS relay. https://atlas.torproject.org/#details/41F07731207742860D43AC426FBAE2F3947BD… It spontaneously acquired an advertised bandwidth of 2.67MB/s but then started to sputter. Failing because we have 1314 connections already ... Specifically, looking at /proc/user_beancounters numtcpsock is the culprit, which is limited to 1360 (some other processes are using the remaining sockets). This artificial limit causes new connections to fail even though send/receive buffers or CPU usage are well below critical. The value can't be changed from inside the OpenVZ container. That's a pity because traffic appears to be unmetered and a lot of potential is wasted this way. I understand that there is currently no way to limit this inside the Tor process because every relay needs to be ready to connect to every other relay at any time. So I tried to get its consensus weight down. Gradually lowering the MaxAdvertisedBandwidth to 300k caused it to briefly acquire the "Stable" flag and run into trouble again. That's no better than a home connection. Worse, in fact, because the problem persists. I'm curious, is this a common experience? Asking customer service would mean explicitly drawing attention to the fact that I'm trying to use the cheap plan to run Tor nodes. That's completely against my instincts. On the other hand they *did* offer a free-form box in the registration form. Has anyone tried and if so, to any avail? Is there a workaround I'm missing? iptables can be configured freely, but I don't see how that would help. At this point I'll probably call it a day, try elsewhere and set this one up as a bridge instead. Frankly I was a bit surprised that technical snags like this aren't generally mentioned in relay setup guides or FAQs. For all I know, it may be common knowledge among expert sysadmins that OpenVZ should be shunned or whatever, but to someone with little prior experience as a user of commercial hosting, some of these limitations come as a surprise. In a bout of post factum searching, I only found this discussion https://serverfault.com/questions/698845/debian-limit-number-of-tcp-sockets… IMHO this kind of knowledge should be spread more "pro-actively", which is why I'm posting this on a public list. Peace, Erik

2 3

Linux kernel vulnerability
by I 24 Oct '16

24 Oct '16

Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel http://dirtycow.ninja/

9 14

CentOS 7 Packages
by Alice . 23 Oct '16

23 Oct '16

Hi, I have one relay on CentOS 6 and one on CentOS 7. The one running CentOS 7 hasn't had the 0.2.8.8 update yet and so is still running 0.2.8.7. The one running CentOS 6 has had the latest update. Is there a problem with getting CentOS 7 packages out? How much of a problem is this? Both now and in the future? Thanks Alice

2 1

Recommendation for DUMB COMPUTING devices for Tor Relays
by Dan Michaels 21 Oct '16

21 Oct '16

The Tor Project website recommends various security setups for people running Tor relays. Such as, don't run a web browser on the same machine as your Tor relay, otherwise the browser could get hacked, and then if Tor relays are hacked, it compromises the entire concept of Tor. In the age of FBI mass hacking, the FBI will attempt to hack all Tor relays, and thus, they can trace traffic throughout the entire proxy chain. According to NSA documents, all it takes is "one page load" to infect a browser, because they re-direct you to a fake website that hosts browser exploits, known as QUANTUM INSERT. The FBI will use this to take over all Tor relays that are running web browsers. So, I have a suggestion that I would like Tor Project to recommend. Tor Project needs to tell people.. use DUMB COMPUTING devices for running Tor relays. If your computer gets hacked, it can be deeply exploited in the firmware, such as BIOS, GPU, WiFi chip, etc. There are devices on the market, such as Raspberry Pi, or similar, which have NO WRITABLE FIRMWARE. This is known as being "stateless". It does not "hold state" across reboots. All firmware/drivers are stored on the SD card on the Raspberry Pi, and only loaded in on boot time. No component on the entire Pi holds state. NONE. There will likely be other similar devices. Therefore, it is truly possible to wipe a dumb computing device completely clean. If you try to wipe a regular laptop or desktop, you may have all this deeply infected firmware, such as BIOS, so you keep getting re-infected upon startup. Some people say, once deeply infected, it's near-impossible to clean it out, and you should just throw away your entire laptop and start again. Everyone running a Tor relay should be told to use a DUMB COMPUTING DEVICE. Another advantage is that these devices are often very cheap. Raspberry Pi is very cheap to buy. Other devices may be even cheaper. The instructions should be as follows... (1) Wipe your device clean, i.e. wipe clean the SD card which holds the OS + all firmware/drivers. (2) Then, re-install the OS clean, install Tor, and set up the relay. (3) Tor should be installed from the command line or from a previously-downloaded version on USB stick. Do not install Tor using the web browser, otherwise you could get infected. (4) Do not run anything else on the machine, other than the Tor relay. Using other programs, especially the web browser, could compromise the entire machine. And that's it. Tor Project should send out a message telling all people running Tor relays to follow these instructions. Let me know what you think.

8 7