- tor-relays - lists.torproject.org

Fast Exit Node Operators - ISP in US
by SiNA Rabbani 29 Nov '14

29 Nov '14

Dear Relay Operators, I noticed there are very few US based exit nodes in the network. And more and more people are jumping on the same set of AS numbers in Europe. I am not if the reason is lack of Tor friendly ISPs or people are just too freaked out about the summer of Snowden. I think it's very wrong to assume that EU countries are not part of the world-wide-wiretap, packets are going through a few internet exchanges anyways. I have been hosting/operating Faravahar (one of the authority directory servers) at Rethem Hosting (rethemhosting.net) for a couple of years now, and never had any issues. I also just brought up 2 exit nodes there: https://atlas.torproject.org/#details/A5B1C342B316C2AE5695B903CED18F619A836… https://atlas.torproject.org/#details/6FFCDF910C32D620FCC6EEF7A8A57F3E9A234… If anyone is interested in running fast Tor Exit nodes at Rethem Hosting. Feel free to contact me directly, so I can make proper referral/introductions. Rethem Hosting is also able to provide hosting In IceLand, but you get the most bang for your buck in the US datacenter. Thank you for contributing to Tor. All the best, SiNA # Consensus Weights Advertised Bandwidth Guard Probability Middle Probability Exit Probability Nickname Fingerprint Exit Guard Country Autonomous System 1.5958% 0.0000% 0.0000% 0.0000% 4.8946% (11 other relay groups) 17.6751% 0.0000% 0.0000% 0.0000% 54.2124% (total in selection) 1 4.1722% 0.0000% 0.0000% 0.0000% 12.7968% * (26 relays) (26) (22) FR (4) 2 3.8256% 0.0000% 0.0000% 0.0000% 11.7338% * (19 relays) (19) (16) DE (6) 3 2.1098% 0.0000% 0.0000% 0.0000% 6.4712% * (10 relays) (10) (8) NL (6) 4 1.4620% 0.0000% 0.0000% 0.0000% 4.4843% * (5 relays) (5) (5) RO (1) 5 0.9090% 0.0000% 0.0000% 0.0000% 2.7881% * (6 relays) (6) (5) SE (4) 6 0.8788% 0.0000% 0.0000% 0.0000% 2.6955% * (4 relays) (4) (4) CH (2) 7 0.8560% 0.0000% 0.0000% 0.0000% 2.6255% * (3 relays) (3) (3) LU (1) 8 0.6510% 0.0000% 0.0000% 0.0000% 1.9967% * (1 relays) (1) (1) LR (1) 9 0.6433% 0.0000% 0.0000% 0.0000% 1.9731% * (10 relays) (10) (8) US (10) 10 0.5715% 0.0000% 0.0000% 0.0000% 1.7528% * (2 relays) (2) (2) GB (1)

17 40

Re: [tor-relays] Fast Exit Node Operators - ISP in US
by teor 23 Nov '14

23 Nov '14

> Date: Sat, 22 Nov 2014 17:58:37 -0800 > From: Seth <list(a)sysfu.com> > ... > > I should have also mentioned in my previous post I put the following in > /etc/tor/torrc > > # Bandwidth and data caps > AccountingStart day 19:45 # calculate once a day at 7:45pm > AccountingMax 33 GBytes # 33GB X 30 days = 10GB shy of 1000GB/mo. > RelayBandwidthRate 3000 KBytes > RelayBandwidthBurst 3750 KBytes # allow higher bursts but maintain average There are 7/12 months that have 31 days, where your 33GB per day will result in a (potential) 23GB overuse. (And that's not including non-tor traffic like OS updates.) Why not use 32GB x 31 days = 992GB, or 31GB x 31 days = 961GB ? teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

3 2

(no subject)
by Chris Boyd 23 Nov '14

23 Nov '14

http://estudiohalabi.cl/problem.php?4z0oxj4vkg5 wodencafe wodencafe(a)gmail.com +++++++++++++ Penalty for premature evacuation. -- Reality Bites

2 1

wild swings in Advertised Bandwidth
by jchase 23 Nov '14

23 Nov '14

Hi, I'm running a low-volume bridge on a raspberry pi. Globe.torproject says that my fingerprint is 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . I'm keeping an eye on myself and traffic via globe.torproject and my advertised bandwidth makes wild swings: one day its 56 kB/s and the next day it's 8 kB/s. When I read that "The minimum BandwidthRate setting is 20 kilobytes per second", I am confronted with the fact that 8 is less than 20 and it doesn't seem worth it keeping my bridge up and working. Why would a bridge make such swings in advertised bandwidth? And is there any good reason to keep the bridge up and working if it sinks to 8 kB/s? Thanks, J Chase

2 1

Decision on Dedicated Server for Exit Node
by Libertas 22 Nov '14

22 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've been looking for a budget dedicated server to host an exit node on, and the best option I've found is BalticServers. However, they're already listed on the GoodBadISPs wiki page, and because they're in Northeast Europe (Lithuania, to be precise) I'm concerned that their ISP already has more exit nodes than is healthy for network diversity. Is it a good idea to host another exit node there? If you think there's a better option, I'd appreciate it if you could tell me either publicly or privately. Thanks, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUb8qfAAoJELxHvGCsI27Nx0sP/j5wBhV7EJZZ4EJoPgnoEH8A i6cDB3sL+Q50MgZivZLG47U+wdj95EJeIRl16RsaL0JaShVwyvbpStaIuhpOoujX FN0oumg3Z27fists+CSImLAHHHyr3a526XbWQazKZ7ReBvBZeIOa4PKA/OWsI8wg CWogwEWxbVNMojWaHMID3Y43qEeSH/T0R9ibqyrvqoZrOhnVqH1+1HzVs4FAWoST UMS2m/+b1qL4riL20XyaS0SUO0OkNbL3ecBnCN9LZJwMMuXVB4QNrsBSNFtDTpeu r8ZPJ/DxLJuQOtOvluSqqriKZCCi2lFAHovcXAf2ele0xqPrnJLFXDvhKkuAlv2o wQb+hdpBZ95u073cu/md8vTYVzA8NJ/sRTPmsWtxdRR8PMVpx59+BOAWNYMLWgEu JdTVinsbaWuKKTCtsZY0KAmYRbYC8E0O46z3OnOaeLX2s4MLUK/rPV3FoOAJ0tA3 ixnJ0kjuaFiBN7SRn+N4imBEmt5DP3cbPmai6YX5FzaL0RjlD+1uWk/ZxV66iK3c YrisgQ0bWFbVCGeztblvBGQF3o6cElCJ26Cvy3EaTn7No+1d4f+/1rYwYCmNHjYY mdfUhSfWWFNv+oaF9MU/IHek45l+yrTHHZlhrk3pmFX/bcUWWcfcYX1D/aMhgH58 7p48+5liXZOtSuVK44aS =/fUH -----END PGP SIGNATURE-----

4 4

Website no longer available from Tor
by Marcello Vitagliano 22 Nov '14

22 Nov '14

Hi from a few weeks the site spacemarc.it is no longer accessible via TOR. My hosting does not apply any filter nor I do it from code. I do not get any error from web server (forbidden, timeout and so on...) but the Tor Browser (v4.0.1) simply tries to connect for several seconds but to no avail (try yourself please). I checked the Apache logs and I do not see any request from an IP Tor. In your opinion why is not it more accessible? Thanks

3 3

building Tor against LibreSSL 2.1.1 fails with "undefined reference to `EVP_aes_128_ctr'" error
by Seth 22 Nov '14

22 Nov '14

I'm trying to build tor-0.2.5.10 from source against LibreSSL 2.1.1 on a FreeBSD 9.3x jail system. It fails with this message ----------------------------------- CC src/tools/tor-gencert.o CCLD src/tools/tor-gencert src/common/libor-crypto.a(aes.o): In function `aes_new_cipher': /usr/local/src/tor-0.2.5.10/src/common/aes.c:100: undefined reference to `EVP_aes_128_ctr' *** [src/tools/tor-gencert] Error code 1 Stop in /usr/local/src/tor-0.2.5.10. *** [all] Error code 1 Stop in /usr/local/src/tor-0.2.5.10. -------------------------------------- Has anyone has any luck building Tor against LibreSSL? -- Seth I <3 nicely trimmed email replies

2 2

OrPort self-testing sometimes fails
by Julien ROBIN 21 Nov '14

21 Nov '14

Hi everybody, Second time it happen to me so I would like to know if you have ideas about it. Sometimes after a reboot, I haven't the following message into the log : "Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor." And after a while (fortunately), I receive a warning (Tor Weather) because my server is shown as offline. So I just type /etc/init.d/tor stop and /etc/init.d/tor start, and it works fine. I would like to know how does the test works, in order to check what can fail during the test. If my server's IP (95.130.9.190) is not reachable by a part of the Internet for example, in order to open a support ticket with my ISP (do you know how I can easily check it ?). Also, since few month now, the bandwith usage seems to keeps far below what I had before (even with a good consensus weight, fresh OS install with new keys and name a month ago) so I now realize that may be there is a problem somewhere with this machine. Thank you in advance for your help and ideas ! Best Regards, Julien ROBIN ---- Please find below the logs of the "failed" start, followed by the "working" start Nov 21 11:56:53.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening log file. Nov 21 11:56:53.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Nov 21 11:56:53.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Nov 21 11:56:53.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. Nov 21 11:56:53.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 11:56:53.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 11:56:53.000 [notice] Your Tor server's identity key fingerprint is 'MagnetronFR1 145AEE9359A8943189500C5451722CAA7EEEC6C3' Nov 21 11:56:53.000 [notice] Bootstrapped 0%: Starting Nov 21 11:56:57.000 [notice] We now have enough directory information to build circuits. Nov 21 11:56:57.000 [notice] Bootstrapped 80%: Connecting to the Tor network Nov 21 11:56:57.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Nov 21 11:56:58.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 21 11:57:00.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 21 11:57:00.000 [notice] Bootstrapped 100%: Done Nov 21 13:56:58.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Nov 21 13:57:28.000 [notice] Clean shutdown finished. Exiting. Nov 21 13:57:39.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening log file. Nov 21 13:57:39.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Nov 21 13:57:39.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Nov 21 13:57:39.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. Nov 21 13:57:39.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 13:57:39.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 13:57:39.000 [notice] Your Tor server's identity key fingerprint is 'MagnetronFR1 145AEE9359A8943189500C5451722CAA7EEEC6C3' Nov 21 13:57:39.000 [notice] Bootstrapped 0%: Starting Nov 21 13:57:39.000 [notice] Bootstrapped 5%: Connecting to directory server Nov 21 13:57:41.000 [notice] We now have enough directory information to build circuits. Nov 21 13:57:41.000 [notice] Bootstrapped 80%: Connecting to the Tor network Nov 21 13:57:41.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Nov 21 13:57:41.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Nov 21 13:57:43.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 21 13:57:44.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 21 13:57:44.000 [notice] Bootstrapped 100%: Done

2 1

[Tor Weather] Node Down! - AccountingMax and ORPort 80
by Chuck Peters 21 Nov '14

21 Nov '14

I thought it might be nice to run a relay only node with ORPort 80 because it might make tor more available to some users where blocking occurs. And to limit unexpected expenses I calculated 220GB a week would be good. Now I have found out why running ORPort 80 with AccountingMax is a problem... Can I work around this issue of after hibernation the node won't bind to port 80? Or do I need to set it to something above port 1024, for example the default port 9001? Initial setup includes the following: ORPort 80 AccountingMax 220 GB AccountingStart week 7 00:00 After a few weeks running the node, day 7 of the week's AccountingMax Tor Weather reports Node Down! Date: Sat, 15 Nov 2014 15:52:45 -0000 Subject: [Tor Weather] Node Down! Nov 15 14:15:09.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Nov 15 15:37:55.000 [notice] Heartbeat: Tor's uptime is 10 days 12:00 hours, with 68 circuits open. I've sent 315.47 GB and received 315.06 GB. We are currently hibernating. ... Nov 16 00:00:00.000 [notice] Hibernation period ended. Resuming normal activity. Nov 16 00:00:00.000 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 16 00:00:00.000 [notice] Opening OR listener on 0.0.0.0:80 Nov 16 00:00:00.000 [warn] Could not bind to 0.0.0.0:80: Permission denied I restart the server, after a bit of downtime. [1]. Following week on day 5 of the AccountingStart week I am approaching the limit again and decide to try a daily AccountingMax, and then perhaps I could restart the server with cron at 5:01, but that isn't going work well with random hibernation. ORPort 198.211.99.146:80 IPv4Only AccountingMax 32 GB AccountingStart day 05:00 Then Node Down again, this time it happens right after the AccountingStart resets. Date: Fri, 21 Nov 2014 07:13:07 -0000 Subject: [Tor Weather] Node Down! Nov 21 05:00:00.000 [notice] Configured hibernation. This interval began at 2014-11-21 05:00:00; the scheduled wake-up time is 2014-11-21 06:20:24; we expect to exhaust our quota for this interval around 2014-11-22 04:16:24; the next interval begins at 2014-11-22 05:00:00 (all times local) Nov 21 05:00:01.000 [notice] Commencing hibernation. We will wake up at 2014-11-21 06:20:24 local time. Nov 21 05:00:01.000 [notice] Going dormant. Blowing away remaining connections. Nov 21 06:20:24.000 [notice] Hibernation period ended. Resuming normal activity. Nov 21 06:20:24.000 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 21 06:20:24.000 [notice] Opening OR listener on 198.211.99.146:80 Nov 21 06:20:24.000 [warn] Could not bind to 198.211.99.146:80: Permission denied ... after logrotate runs Nov 21 07:46:25.000 [warn] Could not bind to 198.211.99.146:80: Permission denied Nov 21 07:46:25.000 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Nov 21 07:46:25.000 [err] Reading config failed--see warnings above. For usage, try -h. Nov 21 07:46:25.000 [warn] Restart failed (config error?). Exiting. I would like to run an exit node, but the advise seems to be try a relay only node for 6 months to a year first... It seems it might be more of an issue with expenses that might prevent me from running an exit node, or multiple nodes. I'l upgrade the VPS to the 2TB transfer, but that might be after the holidays. However I suspect that it will only be a matter of days or weeks before I run into the AccountingMax limits and that may preclude changing the configuration to be an exit node. 1. Downtime starting the 15th. eth0 08:59 ^ t | rt rt | rt rt rt | rt rt rt | t rt rt rt rt | rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 09 1,380,268 1,409,649 17 1,244 2,753 01 3,117 6,815 10 1,383,154 1,407,057 18 1,100 1,720 02 161,632 164,035 11 1,143,056 1,163,393 19 706 228 03 1,564,910 1,578,327 12 1,920,541 1,953,502 20 127 201 04 1,036,805 1,054,792 13 2,719,316 2,742,037 21 675 222 05 1,630,340 1,644,128 14 854,474 869,997 22 124 150 06 3,189,069 3,215,147 15 81,036 82,419 23 732 324 07 2,952,173 2,999,409 16 52,548 52,515 00 6,367 2,718 08 2,115,794 2,150,727 ------------------------------------------------------------------------------- And some other stats that seem to follow the expected life cycle. day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 10/06/2014 28.32 MiB | 13.31 MiB | 41.63 MiB | 0.49 KiB/s 10/07/2014 37.10 MiB | 30.33 MiB | 67.43 MiB | 0.80 KiB/s 10/08/2014 200.13 MiB | 170.99 MiB | 371.12 MiB | 4.40 KiB/s 10/09/2014 194.58 MiB | 188.91 MiB | 383.49 MiB | 4.55 KiB/s 10/10/2014 578.48 MiB | 588.95 MiB | 1.14 GiB | 13.84 KiB/s 10/11/2014 1.09 GiB | 1.10 GiB | 2.19 GiB | 26.62 KiB/s 10/12/2014 1.34 GiB | 1.34 GiB | 2.68 GiB | 32.57 KiB/s 10/13/2014 977.57 MiB | 984.14 MiB | 1.92 GiB | 23.25 KiB/s 10/14/2014 1.68 GiB | 1.67 GiB | 3.34 GiB | 40.56 KiB/s 10/15/2014 1.35 GiB | 1.36 GiB | 2.71 GiB | 32.91 KiB/s 10/16/2014 8.49 GiB | 8.58 GiB | 17.07 GiB | 207.20 KiB/s 10/17/2014 11.88 GiB | 12.02 GiB | 23.91 GiB | 290.15 KiB/s 10/18/2014 13.33 GiB | 13.55 GiB | 26.88 GiB | 326.25 KiB/s 10/19/2014 15.95 GiB | 16.19 GiB | 32.15 GiB | 390.12 KiB/s 10/20/2014 12.34 GiB | 12.53 GiB | 24.87 GiB | 301.83 KiB/s 10/21/2014 17.41 GiB | 17.68 GiB | 35.10 GiB | 425.94 KiB/s 10/22/2014 23.84 GiB | 24.21 GiB | 48.04 GiB | 583.08 KiB/s 10/23/2014 26.52 GiB | 26.93 GiB | 53.46 GiB | 648.77 KiB/s 10/24/2014 26.19 GiB | 26.60 GiB | 52.79 GiB | 640.64 KiB/s 10/25/2014 24.77 GiB | 25.13 GiB | 49.89 GiB | 605.53 KiB/s 10/26/2014 32.19 GiB | 32.66 GiB | 64.86 GiB | 787.13 KiB/s 10/27/2014 28.44 GiB | 28.84 GiB | 57.28 GiB | 695.12 KiB/s 10/28/2014 24.39 GiB | 24.80 GiB | 49.19 GiB | 596.97 KiB/s 10/29/2014 23.66 GiB | 24.04 GiB | 47.70 GiB | 578.94 KiB/s 10/30/2014 26.16 GiB | 26.64 GiB | 52.80 GiB | 640.83 KiB/s 10/31/2014 24.48 GiB | 24.94 GiB | 49.42 GiB | 599.75 KiB/s 11/01/2014 26.62 GiB | 27.02 GiB | 53.64 GiB | 650.94 KiB/s 11/02/2014 26.65 GiB | 27.02 GiB | 53.67 GiB | 651.32 KiB/s 11/03/2014 25.09 GiB | 25.51 GiB | 50.60 GiB | 614.08 KiB/s 11/04/2014 25.06 GiB | 25.43 GiB | 50.49 GiB | 612.75 KiB/s 11/05/2014 27.74 GiB | 28.17 GiB | 55.91 GiB | 678.50 KiB/s 11/06/2014 23.62 GiB | 23.98 GiB | 47.61 GiB | 577.79 KiB/s 11/07/2014 26.63 GiB | 27.06 GiB | 53.69 GiB | 651.61 KiB/s 11/08/2014 30.29 GiB | 30.73 GiB | 61.02 GiB | 740.58 KiB/s 11/09/2014 30.93 GiB | 31.38 GiB | 62.32 GiB | 756.31 KiB/s 11/10/2014 37.56 GiB | 38.16 GiB | 75.72 GiB | 918.98 KiB/s 11/11/2014 33.97 GiB | 34.46 GiB | 68.43 GiB | 830.48 KiB/s 11/12/2014 37.92 GiB | 38.52 GiB | 76.45 GiB | 927.78 KiB/s 11/13/2014 32.15 GiB | 32.65 GiB | 64.80 GiB | 786.41 KiB/s 11/14/2014 36.32 GiB | 36.81 GiB | 73.14 GiB | 887.61 KiB/s 11/15/2014 25.40 GiB | 25.75 GiB | 51.15 GiB | 812.74 KiB/s 11/16/2014 44.23 GiB | 44.88 GiB | 89.11 GiB | 1.06 MiB/s 11/17/2014 44.96 GiB | 45.64 GiB | 90.60 GiB | 1.07 MiB/s 11/18/2014 48.38 GiB | 49.16 GiB | 97.53 GiB | 1.16 MiB/s 11/19/2014 51.38 GiB | 52.33 GiB | 103.71 GiB | 1.23 MiB/s 11/20/2014 43.68 GiB | 44.43 GiB | 88.11 GiB | 1.04 MiB/s 11/21/2014 5.52 GiB | 5.62 GiB | 11.14 GiB | 398.39 KiB/s Chuck

3 2

Re-installed Tor relay node as exit node with same name, different OS.
by Seth 19 Nov '14

19 Nov '14

I recently re-installed the operating system for a VPS that was running Parabola GNU/Linux and acting as a Tor relay. The new OS is OpenBSD 5.6 running tor-0.2.5.10. Instead of running as a relay I modified torrc so it runs a ReducedExitPolicy policy. Initially there were several problems with Tor exit node traffic being blocked by the firewall which has since been resolved. The Tor status page however still does not list this router as an exit node. http://jlve2y45zacpbz6s.onion/router_detail.php?FP=e1e1059d8c41fc48b823c6f0… Any ideas why? -- Seth I <3 nicely trimmed email replies

2 2

BSDNow, OpenBSD Journal
by Libertas 19 Nov '14

19 Nov '14

1 0

List of Relays' Available SSH Auth Methods
by Libertas 19 Nov '14

19 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, everyone. Linked below is a list of relays that were live last night along with the SSH authentication methods they support: https://gist.githubusercontent.com/plsql/27e80e6dab421f8cba6c/raw/8bb0c7aa9… If no auth methods are listed, the SSH connection to the relay failed (more on that below). I used this script to generate it: https://github.com/plsql/ssh-auth-methods The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below. Generally, it is far more secure to allow only public key auth. The Ubuntu help pages have a good guide on setting up key-based auth: https://help.ubuntu.com/community/SSH/OpenSSH/Keys Be sure to disable password authentication after you get key-based auth working! https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#disable-password-… To test whether password auth is still supported, use my script (the README is pretty thorough) or try SSHing from a machine that doesn't have access to your private key. In the latter case, you should get the response 'Permission denied (publickey).' immediately. If you're having issues, make sure that you've restarted sshd since the last time you changed the config. Be sure to back up the node's secret key or your SSH private key, but only somewhere safe! For example, store it in a password manager database on Tarsnap or a USB. This script doesn't attempt any kind of authentication or unauthorized access, so it's about as benign as network scanning scripts come. Regardless, let me know if you have any concerns. It made successful SSH connections with 2839 / 6551 relays. Reasons for failure include: * SSH being served on a non-standard port - something other than port 22. This is a good idea, as many brute-force attackers will only bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information. * The server only allowing SSH connections from certain IP addresses. This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?). * The server going down between when I downloaded the consensus and when I ran the script. * My VPS's IP address getting added to a shared blacklist that the server uses. * etc. If I gave any poor advice or got anything wrong, please let me know. Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUa2ExAAoJELxHvGCsI27Np8IP/2duANtd55hs5L9IskFD2REe 9x5TR+uwZ54GhYLiFc+qiX3JnfoxfurZW7vi++D4R3E9L7nGo5weEZd0b88yJ6kx fUT9QG8gq2RFYdG+RQgYoEI9mLNObK/uc6J9qV3Y7dLOE/may6t6BDWpQTh7g5BJ 8fOnhrqjs0JdfTldc6xzrHT+m1dKBpylWus/WwGaJBReKOx6v7FoMEY53qowK0iA Vb5QS4idYb5WWF+K3Uzqk56v6sUzds/LTTlVc/R6mxjdse4AiMXO3DZsEffhI95W 8xSuw45e/Cfv/j80njsm4O1gFnrqyv/KcGwmL7vNPmtH4+i6dijTbBRroVElm1o3 LQBgCdUmQLz7njeprKnw8xdKT9X3oht4p9VZDfqWogXGiqRRdEtQCVUVhJp+ZrPA KrJBtV/IbYxyndhzC5cMAcTQUff0SOvDtzFnC4cxUbxSemtuO1NMwnIZtv3aGmG5 NEfXS3RjaUlZeZPZuymBDL1CnFqki6+eBDvka8ZOhL1/BgmDqcgT7nRWhlC5MtCG wBAfuJWB8BZl2PHg66VUN9X05TeHbVmrlyuRXaZO6SZof0Wp5vPjzJ1mKD6AyTlt Y/7liLapWgCVSYldohvbLB016iO/aHyGf3oTvZqUyG3NyD267aRQCDQ+sZZq7Cdz +eQO5eJLW/gFNXEptaJz =alRk -----END PGP SIGNATURE-----

19 30

Call for obfs4 bridges, and a brief discussion of obfs4proxy.
by Yawning Angel 18 Nov '14

18 Nov '14

Hello everyone, As people who have been following Tor Weekly News or other news sources, I have been working on a new pluggable transport in the obfs-line to better allow censored users to reach the Tor network. The result, obfs4 is what I would consider ready for general deployment[0], and as part of the process there needs to be bridges for the users. To entice people to run obfs4 bridges, I would like to talk briefly about obfs4 and obfs4proxy. I am also planning on doing a blog post about obfs4 some time after I regenerate my experimental TBB snapshots. On obfs4: obfs4 is the next up and coming pluggable transport in the obfs[2,3] line, though in terms of design, a better name would be "ScrambleSuit 2". The main difference is the switch from UniformDH to ntor-with-Elligator2 for the key exchange process, which means that clients strongly authenticate the identity of the bridge (The key exchange succeeding means that the bridge possesses a Curve25519 private key that is known only to the bridge). Additionally the ntor handshake (even with the Elligator2 transform in the picture) is considerably faster than UniformDH which should increase scalability. On obfs4proxy: obfs4proxy is the current obfs4 reference implementation, written in the Go programming language. The use of Go was primarily driven by the availability of an Elligator2 implementation at the time, though it also has other practical benefits over writing it as a component of the python obfsproxy code, for example, it is trivial to run bridges listening on ports < 1024 on modern Linux systems. obfs4proxy implements support for obfs[2,3,4], as a managed tor pluggable transport (no standalone mode currently). Note that obfs2 support is for backward compatibility purposes only and it is discouraged that new obfs2 bridges are run as the protocol is trivially broken by most adversaries. In terms of code stability, we have been running one of the Tor Browser's default obfs3 bridges on obfs4proxy for quite a while with no issues. Similar to ScrambleSuit, obfs4 bridges MUST be running tor-0.2.5.x, otherwise the bridge lines that are published will be useless[1], though people that wish to run obfs3 bridges with obfs4proxy naturally can do so with tor-0.2.4.x. Source: https://gitweb.torproject.org/pluggable-transports/obfs4.git Debian packages (Thanks Lunar!): https://packages.debian.org/sid/obfs4proxy Note: I just tagged/pushed obfs4proxy-0.0.2, but the only significant change is that it is easier to get an obfs4 bridge line to give out to people as the bridge operator. I expect packages to catch up as the wonderful packager has the time. Questions, comments, and bridges appreciated, -- Yawning Angel [0]: https://trac.torproject.org/projects/tor/ticket/12130 [1]: https://trac.torproject.org/projects/tor/ticket/13202

5 12

FYI: ISP's and blocked Authorities
by Sebastian Urbach 17 Nov '14

17 Nov '14

Hi, It seems to be the case that a few ISP's are not up to date and still using old IP's to block Authorities. That means if you are able to connect to just 1 or 2 Authorities but not to all of them your ISP could be one of those candidates. I saw this behaviour in one case just today. Connectivity with Gabelmoo and longclaw was possible but no other Authority was reachable. Gabelmoo recently changed the IP and longclaw is brand new afaik. That ISP is clearly using an old list of IPs to block Tor for their VPS systems. What makes it even worse is that this system was going to be a Non-Exit relay :-( I will ask the operator for more details and the good/bad ISP page will be updated accordingly. If you can reach some Authorities (not all) and you are not getting indexed and measured (also you can't find your system on the Atlas / Tor site), this could be the reason why. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 4

Re: [tor-relays] Obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 15 Nov '14

15 Nov '14

OK, I updated the obfsproxy apparmor profile so it works for both standalone and managed obfs3. Needed to add a line to /etc/apparmor.d/local/system_tor too. Profiles below and included in the attachment along with an init.d definition. /etc/apparmor.d/usr.bin.obfsproxy ------------------- #include <tunables/global> # vim:syntax=apparmor /usr/bin/obfsproxy { #include <abstractions/base> #include <abstractions/python> network inet stream, /dev/random r, /dev/urandom r, /etc/nsswitch.conf r, /etc/passwd r, /usr/** r, /usr/bin/obfsproxy rix, /var/log/tor/obfsproxy rw, signal (receive) set=("term") peer=system_tor, } ------------------- /etc/apparmor.d/local/system_tor ------------------- # Site-specific additions and overrides for system_tor. # For more details, please see /etc/apparmor.d/local/README. signal (send) set=("term") peer=/usr/bin/obfsproxy, -------------------

1 0

iptables / dump
by Sebastian Urbach 15 Nov '14

15 Nov '14

Dear list members, My iptables dump, as promised (v4). Updated every hour and available as long as my relay is alive ;-) I run a pretty tight ship, just one ssh user and harsh fail2ban settings. All these listed IP's are considered to be "the usual suspects". Please feel free to use it, should give you a jump start. It is getting pretty quiet now since i passed the 300+ ip's milestone. Download: https://www.urbach.org/~sebastian/rules.v4 -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

4 5

Re: [tor-relays] iptables / dump
by Sebastian Urbach 15 Nov '14

15 Nov '14

On November 15, 2014 2:33:23 PM Libertas <libertas(a)mykolab.com> wrote: Hi, > > Honestly, the safest thing to do is to NOT USE PASSWORD BASED > > LOGINS. Im aware of that. > I wrote a script to scan the Tor network for password-based login > availability. If I have the time and no one beats me to it, it'll lead > to a site that warns relay operators about security problems with > their servers. For example, I can combine it with basic, non-invasive > nmap results to warn about non-essential network applications, old OS > versions, and old Tor versions as well. Awesome, like to see that. Sebastian

1 0

Graph not updating.
by Kevin de Bie 14 Nov '14

14 Nov '14

Is there any paticular reason the bandwidth graph flatlined since last night? My ISP may have had some maintenance but my TOR relay is purring like a kitten again, data throughput is quite formidable at the moment at around 1mbps. I use orbot on android.

1 0

Relay's clock settings off no matter what
by Austin Bentley 14 Nov '14

14 Nov '14

Hello everyone, I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings: >05:56:12 [WARN] Received directory with skewed time (server '154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often): >02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data. Could someone shine some light on this? Thanks, Austin

7 9

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running Tor
by Dan Hanley 13 Nov '14

13 Nov '14

Looks like the BBC have changed their rules. I am still running a relay, but can now access www.bbc.co.uk in a normal fashion. Still blocked by national lottery, but I'm hopeful that they both use the same third party ip checker, and that the next lottery update will fix the issue. On Thu, Sep 18, 2014 at 10:41 PM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. RELAY_EARLY tor network update status (CVE-2014-5117) (Nusenu) > 2. Re: BBC and UK Lottery blocking ip addresses running relay > (Ross Petrie) > 3. Re: BBC and UK Lottery blocking ip addresses running relay > (Chris Whittleston) > > > ---------- Forwarded message ---------- > From: Nusenu <BM-2D8wMEVgGVY76je1WXNPfo8SrpZt5yGHES(a)bitmessage.ch> > To: tor-relays(a)lists.torproject.org > Cc: markus(a)mdfnet.se, info(a)enn.lu, torpids(a)yahoo.com, nick(a)calyx.com > Date: Thu, 18 Sep 2014 21:00:41 +0000 > Subject: [tor-relays] RELAY_EARLY tor network update status (CVE-2014-5117) > (if you are on the CC list of this email you are probably one of the tor > relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] > relays on the tor network. Please upgrade your tor relay) > > > The tor network is currently at 64% of the bandwidth being served by > > relays running a recommended version according to torstatus.blutmagie.de > . > > I updated a previous metrics feature request so we might see nice > > graphs about patching progress in the future [2]. > > Since we are seeing active RELAY_EARLY attacks again (or new buggy tor > implemantations) I was wondering what the current update stats look like. > > ~85%* of the tor network's bandwidth is provided by patched relays. > (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) > > *) according to data from torstatus.blutmagie.de > > > 10 fastest relays still running a vulnerable version: > > > https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… > > https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… > > https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… > > https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… > > https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… > > https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… > > https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… > > https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… > > https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… > > https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE… > > > > > ---------- Forwarded message ---------- > From: Ross Petrie <ross.petrie(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 22:18:05 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay > > Hi all, > > I've just reported this same issue this week, no reply yet. > > I can still watch catch up BBC TV through my sky box though. > On 18 Sep 2014 21:40, "Dan Hanley" <hanley.dan(a)gmail.com> wrote: > >> >>> I have just received a slightly more positive reply: >> >> "At present, our GeoIP data provider classes Tor nodes as proxies, >> regardless of whether or not they're an exit node. We understand that there >> is room for improvement in this model, since non-exit relays do not present >> traffic on behalf of other users. We have asked our provider to give us a >> way of differentiating Tor exit nodes from non-exit relays, to allow us to >> block exit nodes only." >> >> So perhaps they will make a change... certainly reporting the issue seems >> to raise its importance :-) >> >> atb >> >> Dan >> >> >> >>> >> >> 5. Re: BBC and UK Lottery blocking ip addresses running relay >>> nodes (Chris Whittleston) >>> ---------- Forwarded message ---------- >>> From: Chris Whittleston <csw34(a)cam.ac.uk> >>> To: tor-relays(a)lists.torproject.org >>> Cc: >>> Date: Thu, 18 Sep 2014 01:40:31 +0100 >>> Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses >>> running relay nodes >>> Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt >>> though, it seems like they still don't get the difference between using Tor >>> as a client and running a relay, so this isn't the end of the road there. >>> You are going to have to rely on them wanting to actually think about it >>> though. >>> >>> If all else fails, you could always try to simply report the issue again >>> using the form I linked before, but this time just don't mention Tor at all >>> and see if you get a different customer service person... >>> >>> http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 >>> >>> I suspect you'll end up having to explain that you're running a relay in >>> the end anyway, but you never know. >>> >>> Chris >>> >>> On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: >>> >>>> Stephen Mollett: >>>> > [...] >>>> > "Thank you for contacting the BBC iPlayer support team. >>>> > >>>> > "I understand you’re experiencing problems accessing BBC iPlayer as >>>> > you’re told that you are outside of the UK. >>>> > >>>> > "Please note that if you run TOR, then I’m afraid as per our >>>> development >>>> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >>>> > continue to use TOR then your IP address may be blacklisted against UK >>>> > only services across bbc.co.uk." >>>> > >>>> > I made a point of stating explicitly in my original case filing that I >>>> > run a middle relay and that no traffic exits from my node to the BBC's >>>> > website or to anywhere else, along with a link to my node's stats on >>>> > blutmagie confirming the (non-)exit policy. >>>> > [...] >>>> >>>> Hi Stephen, >>>> >>>> I'm not sure whether I'm surprised at the BBC or not! >>>> >>>> It is a shame if they seem to be doing blanket blocking of Tor relay IP >>>> addresses. I suppose this >>>> ( >>>> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >>>> ) >>>> has /some/ relevance. >>>> >>>> The problem is obviously convincing a organisation like the BBC to treat >>>> individual IP addresses different from other Tor relay IP addresses (and >>>> whether they should be doing that at all). Although it seems Chris >>>> Whittleston obviously managed it! Maybe you simply got 'the wrong person >>>> at the other end'. Personally, I would continue to pursue this with >>>> them! >>>> >>>> --Matt >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> tor-relays(a)lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>> >>> >>> >>> >>> -- >>> *Dr Chris Whittleston 栗主* >>> Department of Chemistry >>> University of Cambridge >>> Lensfield Road, Cambridge, CB2 1EW >>> Email: csw34(a)cam.ac.uk >>> Tel: +44 (0)1223 336423 >>> >>> _______________________________________________ >>> 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 >> >> > > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 22:41:04 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay > > That's great news Dan, keep us posted! > > Chris > On 18 Sep 2014 21:40, "Dan Hanley" <hanley.dan(a)gmail.com> wrote: > >> >>> I have just received a slightly more positive reply: >> >> "At present, our GeoIP data provider classes Tor nodes as proxies, >> regardless of whether or not they're an exit node. We understand that there >> is room for improvement in this model, since non-exit relays do not present >> traffic on behalf of other users. We have asked our provider to give us a >> way of differentiating Tor exit nodes from non-exit relays, to allow us to >> block exit nodes only." >> >> So perhaps they will make a change... certainly reporting the issue seems >> to raise its importance :-) >> >> atb >> >> Dan >> >> >> >>> >> >> 5. Re: BBC and UK Lottery blocking ip addresses running relay >>> nodes (Chris Whittleston) >>> ---------- Forwarded message ---------- >>> From: Chris Whittleston <csw34(a)cam.ac.uk> >>> To: tor-relays(a)lists.torproject.org >>> Cc: >>> Date: Thu, 18 Sep 2014 01:40:31 +0100 >>> Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses >>> running relay nodes >>> Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt >>> though, it seems like they still don't get the difference between using Tor >>> as a client and running a relay, so this isn't the end of the road there. >>> You are going to have to rely on them wanting to actually think about it >>> though. >>> >>> If all else fails, you could always try to simply report the issue again >>> using the form I linked before, but this time just don't mention Tor at all >>> and see if you get a different customer service person... >>> >>> http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 >>> >>> I suspect you'll end up having to explain that you're running a relay in >>> the end anyway, but you never know. >>> >>> Chris >>> >>> On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: >>> >>>> Stephen Mollett: >>>> > [...] >>>> > "Thank you for contacting the BBC iPlayer support team. >>>> > >>>> > "I understand you’re experiencing problems accessing BBC iPlayer as >>>> > you’re told that you are outside of the UK. >>>> > >>>> > "Please note that if you run TOR, then I’m afraid as per our >>>> development >>>> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >>>> > continue to use TOR then your IP address may be blacklisted against UK >>>> > only services across bbc.co.uk." >>>> > >>>> > I made a point of stating explicitly in my original case filing that I >>>> > run a middle relay and that no traffic exits from my node to the BBC's >>>> > website or to anywhere else, along with a link to my node's stats on >>>> > blutmagie confirming the (non-)exit policy. >>>> > [...] >>>> >>>> Hi Stephen, >>>> >>>> I'm not sure whether I'm surprised at the BBC or not! >>>> >>>> It is a shame if they seem to be doing blanket blocking of Tor relay IP >>>> addresses. I suppose this >>>> ( >>>> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >>>> ) >>>> has /some/ relevance. >>>> >>>> The problem is obviously convincing a organisation like the BBC to treat >>>> individual IP addresses different from other Tor relay IP addresses (and >>>> whether they should be doing that at all). Although it seems Chris >>>> Whittleston obviously managed it! Maybe you simply got 'the wrong person >>>> at the other end'. Personally, I would continue to pursue this with >>>> them! >>>> >>>> --Matt >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> tor-relays(a)lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>> >>> >>> >>> >>> -- >>> *Dr Chris Whittleston 栗主* >>> Department of Chemistry >>> University of Cambridge >>> Lensfield Road, Cambridge, CB2 1EW >>> Email: csw34(a)cam.ac.uk >>> Tel: +44 (0)1223 336423 >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

4 4

Why isn't my relay getting indexed?
by Dedalo 13 Nov '14

13 Nov '14

I was running 2 relays but I'm currently running 1 (with no problem) since some months ago, One of my VPS accounts got suspended and I'm now trying to setup another relay, a middle relay. This new VPS has been running the tor relay since about 12 hours ago but It's not getting indexed in http://torstatus.blutmagie.de/ neither atlas :/ not sure why, I can see I'm getting connections to 9001 but I can't understand why is this happening... Regards, Dedalo. -- Twitter: @SeguridadBlanca Site: Blog.Dedalo.In

3 6

Re: [tor-relays] Standalone obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 13 Nov '14

13 Nov '14

Drake Wilson <drake(a)dasyatidae.net> wrote: > thegreatwent(a)Safe-mail.net wrote: > > So that mostly just leaves open the question of why managed mode obfsproxy wants to read /etc/passwd and nsswitch.conf? > > Sorry for jumping in without reading the whole context, but on GNU/Linux systems, > nsswitch.conf is used for determining how resolution works for host and user names > (among other things), and passwd is usually needed to map names to UIDs. If there's > anything that takes a "which user should I run as" parameter then it'll read those > two in the process of looking up the user, for instance. > > ---> Drake Wilson Thank you, I knew enough to be a bit concerned about /etc/passwd (even though there's no actual passwords in it), but not enough to know if it was an issue in this particular case! I'll continue with adding those files to the Apparmor profile and post back here when it's complete.

1 0

Re: [tor-relays] Standalone obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 12 Nov '14

12 Nov '14

I fixed the logging issue by changing "/var/log/tor/log rw," in the profile to "/var/log/tor/obfsproxy rw,"; and changing the value in my service script to: DAEMON="/usr/bin/obfsproxy -- --profile=/usr/bin/obfsproxy -- /usr/bin/obfsproxy --log-file=/var/log/tor/obfsproxy --log-min-severity=info obfs3 --dest $DEST server $SERVER" I also changed to PIDFILE="/var/run/obfsproxy.pid" because the earlier version didn't work on reboot. Now I can see I am getting traffic! 8 unique addresses in the past hour etc. So that mostly just leaves open the question of why managed mode obfsproxy wants to read /etc/passwd and nsswitch.conf? Is this the wrong place to ask? -------- Original Message -------- From: thegreatwent(a)Safe-mail.net Apparently from: tor-relays-bounces(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Subject: [tor-relays] Standalone obfsproxy apparmor profile etc. Date: Tue, 11 Nov 2014 18:01:16 -0500 > Not sure if this is the right place to post or if this will help anybody, but I think I figured out how to run a standalone (NOT managed) obfs3 obfsproxy on Ubuntu 14.04 with a somewhat confined apparmor profile running under the debian-tor user. > > I verified this by looking at ps and it shows "debian-tor [...] /usr/bin/python /usr/bin/obfsproxy obfs3[...]". AA-STATUS says /usr/bin/obfsproxy is in enforce mode, and removing "network inet stream," for example from the aa profile results in obfsproxy failing to start. > > The line in the profile for "/usr/** r," is ugly, but replacing it with "/usr/bin/** r," didn't work. Obfsproxy log messages also seem to be going to /dev/null, so I'm missing something there. > > So Linux/Apparmor experts, is there anything bad/wrong with this setup? Am I relatively safe from bad guys hacking into my obfsproxy ports? How can I see if the good guys are using it successfully? > > The aa profile does not work for managed instances of obfsproxy. It complained about wanting read access to nsswitch.conf and /etc/passwd and I don't know enough python to understand why it wants that, so I didn't add it. > > Below is also attached: > > /etc/tor/torrc [just the relevant lines, using iptables to redirect from advertised obfs3port to actual] > > ------------------- > ServerTransportPlugin obfs3 proxy a.b.c.d:[advertisedobfs3port] > ExtORPort auto > ------------------- > > > /etc/apparmor.d/usr.bin.obfsproxy > > ------------------- > # vim:syntax=apparmor > #include <tunables/global> > > /usr/bin/obfsproxy { > #include <abstractions/base> > #include <abstractions/python> > network inet stream, > > /var/log/tor/log rw, > /dev/urandom r, > /dev/random r, > /usr/** r, > /usr/bin/obfsproxy rix, > > } > ------------------- > > > /etc/init.d/obfsproxy > > ------------------- > #!/bin/bash > > PIDFILE="/var/run/obfsproxy/obfsproxy.pid" > DEST="127.0.0.1:[ORPort]" > SERVER="a.b.c.d:[obfs3port]" > DAEMON="/usr/bin/obfsproxy -- --profile=/usr/bin/obfsproxy -- /usr/bin/obfsproxy obfs3 --dest $DEST server $SERVER" > > ### BEGIN INIT INFO > # Provides: Obfsproxy > # Required-Start: > # Required-Stop: > # Default-Start: 2 3 4 5 > # Default-Stop: 0 1 6 > # Short-Description: Obfsproxy > ### END INIT INFO > > case "$1" in > start) > echo "Starting Obfsproxy" > > /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ > --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON > ;; > stop) > echo "Stopping Obfsproxy" > > /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose > ;; > restart|reload) > /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose > sleep 1 > /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ > --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON > ;; > *) > echo "Usage: /etc/init.d/obfsproxy {start|stop|restart|reload}" > exit 1 > ;; > esac > > exit 0 > -------------------

2 1

Standalone obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 11 Nov '14

11 Nov '14

Not sure if this is the right place to post or if this will help anybody, but I think I figured out how to run a standalone (NOT managed) obfs3 obfsproxy on Ubuntu 14.04 with a somewhat confined apparmor profile running under the debian-tor user. I verified this by looking at ps and it shows "debian-tor [...] /usr/bin/python /usr/bin/obfsproxy obfs3[...]". AA-STATUS says /usr/bin/obfsproxy is in enforce mode, and removing "network inet stream," for example from the aa profile results in obfsproxy failing to start. The line in the profile for "/usr/** r," is ugly, but replacing it with "/usr/bin/** r," didn't work. Obfsproxy log messages also seem to be going to /dev/null, so I'm missing something there. So Linux/Apparmor experts, is there anything bad/wrong with this setup? Am I relatively safe from bad guys hacking into my obfsproxy ports? How can I see if the good guys are using it successfully? The aa profile does not work for managed instances of obfsproxy. It complained about wanting read access to nsswitch.conf and /etc/passwd and I don't know enough python to understand why it wants that, so I didn't add it. Below is also attached: /etc/tor/torrc [just the relevant lines, using iptables to redirect from advertised obfs3port to actual] ------------------- ServerTransportPlugin obfs3 proxy a.b.c.d:[advertisedobfs3port] ExtORPort auto ------------------- /etc/apparmor.d/usr.bin.obfsproxy ------------------- # vim:syntax=apparmor #include <tunables/global> /usr/bin/obfsproxy { #include <abstractions/base> #include <abstractions/python> network inet stream, /var/log/tor/log rw, /dev/urandom r, /dev/random r, /usr/** r, /usr/bin/obfsproxy rix, } ------------------- /etc/init.d/obfsproxy ------------------- #!/bin/bash PIDFILE="/var/run/obfsproxy/obfsproxy.pid" DEST="127.0.0.1:[ORPort]" SERVER="a.b.c.d:[obfs3port]" DAEMON="/usr/bin/obfsproxy -- --profile=/usr/bin/obfsproxy -- /usr/bin/obfsproxy obfs3 --dest $DEST server $SERVER" ### BEGIN INIT INFO # Provides: Obfsproxy # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Obfsproxy ### END INIT INFO case "$1" in start) echo "Starting Obfsproxy" /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON ;; stop) echo "Stopping Obfsproxy" /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose ;; restart|reload) /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose sleep 1 /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON ;; *) echo "Usage: /etc/init.d/obfsproxy {start|stop|restart|reload}" exit 1 ;; esac exit 0 -------------------

1 0

Re: [tor-relays] Node Operators Web Of Trust
by tor＠t-3.net 11 Nov '14

11 Nov '14

On 11/07/2014 10:26 PM, grarpamp wrote: > Is it not time to establish a node operator web of trust? > Look at all the nodes out there with or without 'contact' info, > do you really know who runs them? Have you talked with > them? What are their motivations? Are they your friends? > Do you know where they work, such as you see them every day > stocking grocery store, or in some building with a badge on it? > Does their story jive? Are they active in the community/spaces > we are? Etc. This is huge potential problem. I can't think of a good reason to do this, or why there is a problem. Can think of quite a few negatives, the worst of which are related to the fact that NSA/GCHQ would like for Tor to go away. Something like what you describe would be a nice little tool for them to get useful-to-them personal info about Tor node operators. Even assuming that the node operators' identities are already known to the aforementioned agencies, how could feeding them juicy little details possibly help the situation. It also kinda has "perfect environment for social engineering" written all over it. Who's to say that the most trusted-feeling people in such a group wouldn't necessarily be one of the infiltrating baddies. They are pro at this.

1 0