- tor-relays - lists.torproject.org

Upgrading a relay and changing IP address
by Cristian Consonni 25 May '17

25 May '17

Hi, On 18/05/2017 01:56, Gunnar Wolf wrote: > Cristian Consonni dijo [Wed, May 17, 2017 at 05:04:29PM +0200]: >> AS you can see from the Debian package page[1] the latest available >> version of Tor packaged for Wheezy is 0.2.4.27-3, which to me looks >> quite behind either 0.2.5.12-4 available in Jessie (stable) or the >> 0.2.9.X series available through backports or testing. >> >> What's the best to do in this cases? >> * Should I start updating tor manually? >> * Should I update Debian on the server? (which could well me start with >> a fresh install? >> * Is it ok like it is now, provided that the system is updated? > > While Debian Wheezy (7, our "oldstable" release) still has security > support via LTS¹, it is not recommended to run a Tor relay with such > old packages. In fact, not even the version available in Jessie (8, > our "stable" release - 0.2.5.12-4) is recommended nowadays. > > I suggest you to update to _at least_ Jessie and use the version in > backports (depends on your sysadmining, but if your machine's only use > is to run a Tor node, I'd suggest installing Stretch, 9, which has > 0.2.9.9-1). I am running the relays on VPS providers so, I can choose (only) among the versions of Debian that are provided by the services as templates. When Stretch is release I will see if they make it available, in a reasonable time. I am settled anyhow to upgrade the nodes as soon as the new Debian version is released and I have a question. I have read that I can move the node keys when upgrading[1] and I will do that. One thing that will change with a fresh install is the IP address of the nodes. So, I was wondering, in general is a good thing to keep the same IP or changing it? Because in any case, I could try and do a dist-upgrade[2] so that I keep the old IP. I have also discovered now that DigitalOcean, one of the providers I use, provides a kernel-management interface[3] that could make the process easier. So, which is preferable between the two processes where one has the advantage of keeping the same IP (dist-upgrade) and the other not (fresh install)? Of course, I am assuming that I will be able to complete any of the two processes successfully. Cristian [1]: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove [2]: https://www.debian.org/releases/stable/amd64/release-notes/ [3]: https://www.digitalocean.com/community/tutorials/how-to-update-a-digitaloce…

5 9

Kitten1 and kitten2 compromised (guard/hs/fallback directory)
by aeris 24 May '17

24 May '17

Dear Tor Project, Currently, my server hosting kitten1 and kitten2 (tor guard and fallback directory) is under seizure since 14/05 11h. Private key are under encrypted volume and may be protected, but please revoke immediatly kitten1 & kitten2 tor node. Those nodes are also fallback directory. Regards, -- Aeris https://imirhil.fr/ Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/

18 21

Problem starting 0.3.0.7 on Ubuntu?
by Alexander Dietrich 23 May '17

23 May '17

Hello, did anyone else run into a problem when upgrading from 0.2.9.10 to 0.3.0.7 on Ubuntu? Tor is no longer starting, with these messages in syslog: [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". [notice] Read configuration file "/etc/tor/torrc". [warn] Directory /var/lib/tor/SERVICE_NAME/ cannot be read: Permission denied [warn] Checking service directory /var/lib/tor/SERVICE_NAME/ failed. [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details. [err] Reading config failed--see warnings above. The permissions on /var/lib/tor/SERVICE_NAME/ are "rwx--S---" and it's owned by debian-tor, which worked for 0.2.9.10. Thanks, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

4 8

(FWD) [tor-announce] Tor 0.3.0.7 is released, with a medium security fix for relays
by Roger Dingledine 21 May '17

21 May '17

For those of you who are not on tor-announce... now would be a good time to remember to subscribe to tor-announce. :) --Roger ----- Forwarded message from Nick Mathewson <nickm(a)torproject.org> ----- Date: Mon, 15 May 2017 18:57:59 -0400 From: Nick Mathewson <nickm(a)torproject.org> To: tor-announce(a)lists.torproject.org Subject: [tor-announce] Tor 0.3.0.7 is released, with a medium security fix for relays Hi, all! There's a new Tor release (0.3.0.7) available on the website. It fixes a bug affecting relays running earlier versions of 0.3.0.x that could allow attackers to trigger an assertion failure on those relays. Clients are not affected; neither are relays running versions before 0.3.0.x. If you're running a relay with one of the affected versions, you should upgrade. Source is available on the website now; packages should be available over the next several days. =========== Changes in version 0.3.0.7 - 2017-05-15 Tor 0.3.0.7 fixes a medium-severity security bug in earlier versions of Tor 0.3.0.x, where an attacker could cause a Tor relay process to exit. Relays running earlier versions of Tor 0.3.0.x should upgrade; clients are not affected. o Major bugfixes (hidden service directory, security): - Fix an assertion failure in the hidden service directory code, which could be used by an attacker to remotely cause a Tor relay process to exit. Relays running earlier versions of Tor 0.3.0.x should upgrade. should upgrade. This security issue is tracked as TROVE-2017-002. Fixes bug 22246; bugfix on 0.3.0.1-alpha. o Minor features: - Update geoip and geoip6 to the May 2 2017 Maxmind GeoLite2 Country database. o Minor features (future-proofing): - Tor no longer refuses to download microdescriptors or descriptors if they are listed as "published in the future". This change will eventually allow us to stop listing meaningful "published" dates in microdescriptor consensuses, and thereby allow us to reduce the resources required to download consensus diffs by over 50%. Implements part of ticket 21642; implements part of proposal 275. o Minor bugfixes (Linux seccomp2 sandbox): - The getpid() system call is now permitted under the Linux seccomp2 sandbox, to avoid crashing with versions of OpenSSL (and other libraries) that attempt to learn the process's PID by using the syscall rather than the VDSO code. Fixes bug 21943; bugfix on 0.2.5.1-alpha. _______________________________________________ tor-announce mailing list tor-announce(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce ----- End forwarded message -----

10 18

OrNetStats
by nusenu 20 May '17

20 May '17

Hi, if you want to compare your relay(s) with other operators: https://nusenu.github.io/OrNetStats/ Entries on the page link to compass (if you run more than one relay) or directly to atlas if you operate just one. regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 3

seized relays reported for blacklisting?
by nusenu 20 May '17

20 May '17

Hi Nicolas, according to aeris (CC) one(?) [1] of your relays got seized/compromised [2]. Did you report it to tor directory authorities, so they can blacklist the relay? thanks, nusenu [1] InFlames - C46A33E7E56F4F3FF2D36308A37E3DA21CD100FB [2] https://twitter.com/aeris22/status/865317501525045248 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 4

Bridge not being used
by Joel Cretan 19 May '17

19 May '17

Hi relay operators, I've run a number of relays, so I'm familiar with how this usually works for non-bridges. I'm working on a project that might want to connect through a bridge, so I thought I'd fire one of those up to offset the demands I'd be placing on the network. I've been operating this bridge for about 30 days with RelayBandwidthRate set at 5000 KBytes, which I thought might be attractive to some clients, since most bridges are so small. But checking my logs for the last few days, I don't seem to have had any clients at all recently. Is this expected for a bridge, as clients don't rotate their bridge very often, or is something possibly wrong? As far as I can tell, everything is working OK, because I can connect through it with my own Tor client. The server descriptor is published. I'll avoid pasting the whole torrc since it's a bridge, but I can do that with some parts removed if that would help. Thanks! jc

2 2

Re: [tor-relays] seized relays reported for blacklisting?
by nusenu 19 May '17

19 May '17

Hi Nicolas, thanks for your fast response. Nicolas Simond: > I'll do but I don't know if this has been done since I haven't received > any response. Ok so you tried to contact them already? (what email / channel did you use?) > But all relay have disapeared from the atlas. Are you saying that more than one of your relays was seized? I found the following relays (down) with your contactinfo, did all 3 get seized? +----------+-----------------+---------------------+ | FP | nickname | last_seen | +----------+-----------------+---------------------+ | 96D67782 | darkstar | 2017-05-17 09:00:00 | | 6B356C10 | dustofnightmare | 2017-05-17 09:00:00 | | C46A33E7 | InFlames | 2017-05-13 16:00:00 | +----------+-----------------+---------------------+ Atlas is currently hardly working since its backend (onionoo.torproject.org apparently has some availability issues). Atlas also only shows relays that have been running at some point within the last 7 days (which should not be a problem in this case). -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

DirCache 0
by Paul 19 May '17

19 May '17

Running a relay on small RAM I putted "DirCache 0" to save memory. As one can read here https://www.torproject.org/docs/tor-manual.html.en "Setting either DirPort or BridgeRelay and setting DirCache to 0 is not supported. (Default: 1) " I cant set a DirPort as well, which means I cant publish a DirPortFrontPage Exit-notice. Any idea how to circumvent this problem. Thanks Paul

2 1

Strange behaviour Tor 0.2.9.10 - off topic
by Felix 18 May '17

18 May '17

Hi everybody I walked through the March postings and found: > (Please don't put -- in your emails. Some people use broken > mail readers that hide everything below a -- .) Indeed it's not broken, it's *Usenet Signature Convention* https://tools.ietf.org/rfc/rfc3676.txt (chapter 4.3.) That's old school - how we saved bandwidth in ancient times :) -- Cheers, Felix

2 1