- tor-relays - lists.torproject.org

Tor relay is restarting every minute
by Michael 19 Jun '15

19 Jun '15

My Tor relay interrupts and restarts every minute (without my involvement), so it isn't usable by anyone. Nothing new in my obfsproxy log. My relay was running fine until I moved and changed to a new ISP (AT&T). Jun 19 06:10:28.717 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8. Jun 19 06:10:28.717 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jun 19 06:10:28.717 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jun 19 06:10:28.717 [notice] Read configuration file "/etc/tor/torrc". Jun 19 06:10:28.722 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand. Jun 19 06:10:28.722 [notice] We were compiled with headers from version 2.0.19-stable of Libevent, but we're using a Libevent library that says it's version 2.0.21-stable. Jun 19 06:10:28.722 [notice] Opening Control listener on 127.0.0.1:9051 Jun 19 06:10:28.723 [notice] Opening Control listener on /var/run/tor/control Jun 19 06:10:28.723 [notice] Opening OR listener on 0.0.0.0:9001 Jun 19 06:10:28.723 [notice] Opening Extended OR listener on 127.0.0.1:0 Jun 19 06:10:28.723 [notice] Extended OR listener listening on port 55831. Jun 19 06:10:28.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jun 19 06:10:28.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jun 19 06:10:28.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jun 19 06:10:29.000 [notice] Your Tor server's identity key fingerprint is [REDACTED] Jun 19 06:10:29.000 [notice] Your Tor bridge's hashed identity key fingerprint is [REDACTED] Jun 19 06:10:29.000 [notice] Bootstrapped 0%: Starting Jun 19 06:10:33.000 [notice] Bootstrapped 80%: Connecting to the Tor network Jun 19 06:10:34.000 [warn] The communication stream of managed proxy '/usr/local/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. Jun 19 06:10:34.000 [notice] Failed to terminate process with PID '13164' ('Success'). Jun 19 06:10:34.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Jun 19 06:10:35.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jun 19 06:10:36.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jun 19 06:10:36.000 [notice] Bootstrapped 100%: Done Jun 19 06:11:13.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Jun 19 06:11:43.000 [notice] Clean shutdown finished. Exiting. Jun 19 06:11:43.000 [notice] Tor 0.2.6.9 (git-145b2587d1269af4) opening log file. Jun 19 06:11:43.958 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running with 1000106f: OpenSSL 1.0.1f 6 Jan 2014). Jun 19 06:11:43.958 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.

1 0

Installing Tor-ramdisk
by eldorado 17 Jun '15

17 Jun '15

Installing Tor-ramdisk I have question about installing Tor-ramdisk on Dedicated server in hetzner datacenter. I want install iso file without using USB and DVD . i followed this link[1] . My iso file is in my VPS that LARA could access to iso via SAMBA/CIFS . LARA shows me the iso file attached but after running KVM and press F11 the boot menu have my hard disks not "PepperC Virtual Disc 1 0.01" in boot menu . How i can mount Tor-ramdisk with KVM . i don't want pay € 21.01 for using USB stick/DVD . [1] http://wiki.hetzner.de/index.php/LARA/en

1 0

Questions about GUI monitor
by nks nks 17 Jun '15

17 Jun '15

Dear Sir/Madam: My system is Debian 32bit, Tor non-exit bridge. 1. For Debian, is there any pure Tor service monitoring and analyzing software for the local machine (not the entire Tor network), with/without a GUI ? 2. Does "Vidalia" really end developing? May I ask why? May I install the "Vidalia" which is still could be found in the Debian apt system? 3. https://www.torproject.org/projects/projects.html.en "orlib" the link is dead. 4. About "Tor2web", are there any clearer figures and docs which could explain the security differences between "Tor" and "Tow2web" ? Especially for the client. Thank you.

4 4

Exit relay is apparently being used to attack other servers
by trillium 16 Jun '15

16 Jun '15

Hello, I’m running an exit relay (fingerprint: 5793CB9E1F5BAD3D5DA6C4158E16067D80CD8A2E) on a Linode VPS right now, and so far they’ve been really fantastic with dealing with a couple of DMCA notices that were sent to them. However, in the last week, I received notice from them that my server is attacking multiple sites around the web. Their suggestion was to go through my logs and remove the offending user, which is obviously unhelpful advice as I don’t keep any logs on my relay’s users. I’d like to keep running the exit relay, but I’m not really sure how to best go about mitigating these sorts of threats and don’t want Linode to shut down the entire server. Any suggestions are very much welcomed. Thanks, trillium

6 6

Encryption in French servers
by Javi 15 Jun '15

15 Jun '15

I know in France it's illegal to encrypt data so if I run a tor relay in a French server I would have any problem? Thanks.

2 1

Re: [tor-relays] Exit relay is apparently being used to attack other servers
by spiros_spiros＠freemail.gr 13 Jun '15

13 Jun '15

Hi Trillium, It is always sad when Tor is used to hack/DoS/compromise servers. As operator of an Exit Node unfortunately you will see as well as the DMCA notice the hacking/abuse/spamming/botnet alerts from some service provider, also you will get notification that the node is added to this blacklist and that spammer list. My advice is to work very closely with your Exit Node datacentre and make them know that you respond quickly to abuse emails (even the annoying automatic ones) with polite message to tell them you have a Tor Exit and cannot provide details of traffic source or realistically block individual user or IP. If the datacentre is friendly you will hopefully not be shut down or account closed. If you get paranoid about one particular provider, or they harass you with email threats/notifications you could use iptables or ipfw to block individual host, or close the port to the Exit Node in your torrc. It would be better to explain situation if you are in contact with them and go from there. In my experience when I email complaining party to explain I run Tor relays I almost never get a response but sometimes they just block the Exit Node IP on their firewall which is fine. If really paranoid, consider moving to provider that does not require scan of government ID or passport, pay with BitCoin if possible, don't provide real house address and don't log in to server from your home IP. As others have written before me, Linode is not great for Tor friendliness. S On 13 Jun 2015, at 19:03, trillium <trillium(a)riseup.net> wrote: Hello, I’m running an exit relay (fingerprint: 5793CB9E1F5BAD3D5DA6C4158E16067D80CD8A2E) on a Linode VPS right now, and so far they’ve been really fantastic with dealing with a couple of DMCA notices that were sent to them. However, in the last week, I received notice from them that my server is attacking multiple sites around the web. Their suggestion was to go through my logs and remove the offending user, which is obviously unhelpful advice as I don’t keep any logs on my relay’s users. I’d like to keep running the exit relay, but I’m not really sure how to best go about mitigating these sorts of threats and don’t want Linode to shut down the entire server. Any suggestions are very much welcomed. Thanks, trillium _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Recommendation: Upgrade your OpenSSL! (Nick Mathewson)
by teor 12 Jun '15

12 Jun '15

> Date: Thu, 11 Jun 2015 14:30:35 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > > Hi, relay operators! > > There have been a series of new openssl releases today: 0.9.8zg, > 1.0.0s, 1.0.1n, and 1.0.2b. > > They fix a set of security issues described in this announcement: > https://www.openssl.org/news/secadv_20150611.txt > > Since some of these issues could allow a remote denial-of-service > attack, I would suggest that everybody should upgrade as OpenSSL > packages become available for your operating systems. If you build > OpenSSL from source, now's a good time to rebuild. You probably don't > need to run in circles freaking out, or anything -- just upgrade when > you can. > > Also, if you can possibly avoid it, it would be a good idea to stop > using the OpenSSL 0.9.8 series entirely. It's old and crufty and is > missing many security improvements in later versions. OpenSSL 0.9.8 > will not be supported in Tor 0.2.7.2-alpha or later. Please also note that OpenSSL versions 0.9.8 and 1.0.0 are becoming unsupported at the end of 2015: "As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html) support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade." See the second-last section in https://www.openssl.org/news/secadv_20150611.txt teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Recommendation: Upgrade your OpenSSL!
by Nick Mathewson 11 Jun '15

11 Jun '15

Hi, relay operators! There have been a series of new openssl releases today: 0.9.8zg, 1.0.0s, 1.0.1n, and 1.0.2b. They fix a set of security issues described in this announcement: https://www.openssl.org/news/secadv_20150611.txt Since some of these issues could allow a remote denial-of-service attack, I would suggest that everybody should upgrade as OpenSSL packages become available for your operating systems. If you build OpenSSL from source, now's a good time to rebuild. You probably don't need to run in circles freaking out, or anything -- just upgrade when you can. Also, if you can possibly avoid it, it would be a good idea to stop using the OpenSSL 0.9.8 series entirely. It's old and crufty and is missing many security improvements in later versions. OpenSSL 0.9.8 will not be supported in Tor 0.2.7.2-alpha or later. best wishes, and many thanks! -- Nick Mathewson

1 0

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by starlight.2015q2＠binnacle.cx 11 Jun '15

11 Jun '15

>Mon Jun 8 05:25:55 UTC 2015 >> UBSAN seems expensive and doesn't seem >> it would run other than test, but >> I didn't work on it long and am not >> 100% certain. Was trying ASAN extra >> stack checking at the time, which may >> have been the culprit. > >As I said in my previous email, if you're >running releases before 0.2.6.6 (2015), >Tor won't run under UBSAN due to issues >that have been fixed in subsequent >releases. Had a need to run ASAN+UBSAN and it works perfectly fine for me with version 0.2.4.27. Required a minor patch to convert a single common variable 'incoming_queue' to extern. Performance hit was not as bad as I thought from the earlier try, but bad enough that I limited the instrumented modules to only what's necessary.

1 0

Incorrect IP Address change reported
by Pascal Terjan 10 Jun '15

10 Jun '15

I got my IP address reported as changed to some Deutsche Telekom IP twice in a few minutes by 154.35.175.225 yesterday This IP is "Faravahar" according to https://trac.torproject.org/projects/tor/ticket/14487 Jun 09 12:21:50.000 [notice] Our IP Address has changed from 149.18.2.82 to 91.5.121.93; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:21:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:21:54.000 [notice] Performing bandwidth self-test...done. Jun 09 12:22:51.000 [notice] Our IP Address has changed from 91.5.121.93 to 149.18.2.82; rebuilding descriptor (source: 86.59.21.38). Jun 09 12:22:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:22:51.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jun 09 12:23:52.000 [notice] Our IP Address has changed from 149.18.2.82 to 91.5.121.93; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:23:52.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:24:10.000 [notice] Our IP Address has changed from 91.5.121.93 to 149.18.2.82; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:24:10.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:25:00.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.

2 1