- tor-relays - lists.torproject.org

Whitelist
by Thomas White 24 Dec '14

24 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Directory Authorities, Can you please remove the following fingerprints/IP's from the blacklist as per my previous updates in tor-talk. D78AB0013D95AFA60757333645BAA03A169DF722 6F545A39D4849C9FE5B08A6D68C8B3478E4B608B 5E87B10B430BA4D9ADF1E1F01E69D3A137FB63C9 0824CE7D452B892D12E081D36E7415F85EA9988F 35961469646A623F9EE03B7B45296527A624AAFD 1EA968C956FBC00617655A35DA872D319E87C597 E5A21C42B0FDB88E1A744D9A0388EFB2A7A598CF 5D1CB4B3025F4D2810CF12AB7A8DDDD6FC10F139 1324EC51FBFA5FD1A11B94563E8D2A7999CD8F57 93CD9231C260558D77331162A5DC5A4C692F5344 IPs: 77.95.229.0/24 5.104.224.15 77.95.224.187 89.207.128.241 128.204.207.215 Authorities who haven't signed yet: gabelmoo tor26 maatuska moria1 urras Regards, T - -- Activist, anarchist and a bit of a dreamer. PGP Keys: key.thecthulhu.com Current Fingerprint: E771 BE69 4696 F742 DB94 AA8C 5C2A 8C5A 0CCA 4983 Key-ID: 0CCA4983 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Key-ID: EF1009F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 4321B19F A9A3462C FE64BAC7 294C8A7E A53CC966 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUmfi/AAoJEFwqjFoMykmDLpwP/iRLkxYXMGzW4ohr/sG2nvYX Fitv6242N0NuGEFkwZgjaYEdiab4Afdg5xacu5r3+tzdccKawZX9w7NOpx1w8iXS IxO4i/nU5DhA2hyn/67/J/JBOqjVY7V0nXVtEOAK3NUGjiRK+uaSojfZ/y3iXgvv MHdr5eGM5Rj7/sZ2eqLsCdzSr0atGQXxyz2JhlVim5rZfG9ikzvGcv8PbDl67Fgp e5l/aq3NAHv8EiMAML1Wpah+hi7fDuyX4QcSLfrrwK2sv+oetbPSa6Kue26PP2Fr UKQLB412hJ4gtLFL5LiQXWvs1cuQO4Yw7tBOJ3qsh4kWpDtVUD7OTIDZRCK+FkwF FuH2XHwN8IVhIcQcTZ+I7dKqWi9vMxaJPWi15osah5rW48ozqCCSqFO9xICOyMDH V1JSeHTVzWCKpkpocUYzIMJvjuqADtAyuR9CX0hgEgUdGf9kMYdo+zGsiXomHO02 1iuWsq1HjwNxL2nAZJpCNsNetcHSvRtwGXbWx2Fr6P/T3tBh7gYfTSD2KwNnw+yE X0IDz5J02Xqz1nU2kiKr+IkZDXI+0aKzkD0KI6Uia0LEcZmjKNEePccHd+PcwIY/ YnH55rVyilUsLBvgQKZwGBVk+9kNmXjwiH1JJbUrGcfsCvZb+E05n5WMcbNYRwW2 N+2CQDnmN8aHLErrs5RU =zOpP -----END PGP SIGNATURE-----

2 1

help needed to setup a bridge on amazon and relay on PC
by Sasikantha babu 24 Dec '14

24 Dec '14

I've been trying to setup a bridge on amazon cloud and relay node on PC but never succeeded in setting it up. I always get an error "Your server (IP:9001) has not managed to confirm that its ORPort is reachable". 1. My PC is behind netgear router and I had configured portforwarding (portforwarding seems to work but tor-relay fails complains about ORPort reachability). 2. Follow the steps https://cloud.torproject.org/#get_started and created an instance on amazon cloud but facing the ORPort reachability. Dec 23 14:19:37.000 [notice] Bootstrapped 5%: Connecting to directory server Dec 23 14:19:40.000 [notice] We now have enough directory information to build circuits. Dec 23 14:19:40.000 [notice] Bootstrapped 80%: Connecting to the Tor network Dec 23 14:19:40.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 23 14:19:41.000 [notice] Guessed our IP address as ip (source: ip). Dec 23 14:19:41.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Dec 23 14:19:42.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Dec 23 14:19:42.000 [notice] Bootstrapped 100%: Done Dec 23 14:19:42.000 [notice] Now checking whether ORPort IP:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Dec 23 14:39:41.000 [warn] Your server (IP:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Thanks

2 3

Tor Relay Operators Meetup at 31c3 *moved* - 28.12. 13:00
by Moritz Bartl 23 Dec '14

23 Dec '14

Hi, I had to move the meetup slightly in time and to a different room. I was told by CCC orga that they need the original room for Engel meetings. NEW DATE: 28.12.2014 13:00 LOCATION: HALL C https://events.ccc.de/congress/2014/wiki/Session:Tor_Relay_Operators_Meetup See you! -- Moritz Bartl https://www.torservers.net/

1 0

Tor Relay Operators Meetup at 31c3 - 28.12. 14:15
by Moritz Bartl 23 Dec '14

23 Dec '14

Hi, Torservers.net invites Tor exit relay operators and organizations to a meetup. If possible/relevant, for example if you're a member of one of the 'Torservers partner organizations', please prepare some slides on your activities. You're obviously also welcome to suggest sessions as a member of the broader relay community! We will do quick presentations on recent and future activities around Torservers.net, talk about events relevant to the Tor relay community, and what lies ahead. https://events.ccc.de/congress/2014/wiki/Session:Tor_Relay_Operators_Meetup 2014/12/28 14:15 - 16:15 See you there! -- Moritz Bartl https://www.torservers.net/

5 8

DDoS attack targeted on my exit node
by Michael Renner 22 Dec '14

22 Dec '14

Hi, my tor exit node was targeted with two DDoS attacks, one on 2014-12-20 01:00 CET and one on 2014-12-22 18:00 CET [1], both lasting about 5 minutes each. This alone wouldn’t be too noteworthy if it weren’t for the fact that a) there’s a certain state of alarm WRT the Tor networks integrity and b) these are the only attacks my ISP has on record for the over 2.5 years of operating the Tor Exit node. If no other operators have noticed anything out of the ordinary (given by the silence on the list) this is most likely a fluke (getting rid of pesky IRC users?), but better be safe than sorry. best, Michael [1] http://i.imgur.com/Zu9UkW3.png <http://i.imgur.com/Zu9UkW3.png> Summary screen

3 2

ntp needs attention
by Felix 22 Dec '14

22 Dec '14

Hi See: https bugs.debian.org/cgi-bin/bugreport.cgi?bug=773576 Debian will be fixed by 'apt-get update' and 'apt-get upgrade'. dpkg.log tells if the fix is in place: https security-tracker.debian.org/tracker/CVE-2014-9293 ... Cheers!

3 2

Hibernation and Guard flag
by Filippo Valsorda 21 Dec '14

21 Dec '14

Hello, I set up a relay node on my VPS to eat up all that unused bandwidth, and it's doing well so far [1]. Since I have ~3TB per month and I heard hibernation is preferable to throttling, I set up monthly accounting with that cap. However I have two doubts: 1. Is daily accounting preferable? That is, what's best, shorter or longer hibernation periods? 2. How does hibernation play with the Guard flag? I know Guards rotation plays a crucial role in users privacy, and it seems to me hibernation would really hurt a client that selected you as its Guard, since it will have either to run with one less available Guard, or pick a new one and increase its risk. Also, I know there are talks about making only 1 Guard selected, how would that play with hibernation? N.B. please cc me into the replies, I might not be getting only-in-list replies. Thanks, Filippo [1] https://globe.torproject.org/#/relay/2EC042F4274CC8A54381C78E8D1BF322FA26A0…

2 1

Re: [tor-relays] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by teor 16 Dec '14

16 Dec '14

> From: Richard Johnson <rdump(a)river.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Platform diversity in Tor network [was: > OpenBSD doc/TUNING] > > On 2014-11-05 10:47, Libertas wrote: >> I appreciate your interest! Also, I hope I'm not speaking with too >> much authority. If anyone here has more OpenBSD experience than me, >> please send addendums or corrections. > > Maybe call this an addendum? Some version of the following work in progress > is going onto our local documentation store for others maintaining our > OpenBSD relays. > > It's a bit long-winded for inclusion in doc/TUNING per > https://trac.torproject.org/projects/tor/ticket/13702 , as it's intended to > educate *BSD and Linux sysadmins about a smidgen of the why behind the > tuning recommendations, as well as point at further exploration. > > > Richard > > ------- > Our OpenBSD tuning for Tor involves: ... > 4) Probably running more than one relay on a host to use available CPU > cores and bandwidth. ... > 4) Loading more CPU cores > > If you have one of your CPUs maxed out running a Tor relay, with the other > CPU(s) mostly idle (see top(1)), yet you have bandwidth to spare still, you > can run additional Tor instances to sop some of it up. > > The sanest way to handle this is to make each relay a stand-alone entity > with a naming scheme to keep them straight. Here, we'll use "tor#" for every > relay past the first. > > Make per-relay directories in /var owned by _tor:_tor mode 700 > drwx------ 5 _tor _tor 512 Jan 13 18:52 /var/tor/ > drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor2/ > drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor3/ > ... > Copy the tor startup script /etc/rc.d/tor to match the naming scheme. > /etc/rc.d/tor2 > /etc/rc.d/tor3 > ... > Copy the torrc from /etc/tor/torrc. > /etc/tor/torrc2 > /etc/tor/torrc3 > ... > Modify /etc/tor/torrc2, /etc/tor/torrc3, ... so they refer to their > appropriate private DataDirectory and PidFile, listen on the appropriate > ports and IP addresses, and have the appropriate exit policies. (Remember > that the public Tor network will by design ignore more than two relays per > IP address.) > DataDirectory /var/tor2 > PidFile /var/tor2/pid > ControlPort 9222 > Address 10.2.2.2 > ORPort 8222 > DirPort 7222 > ... > DataDirectory /var/tor3 > PidFile /var/tor3/pid > ControlPort 9333 > Address 10.3.3.3 > ORPort 8333 > DirPort 7222 > ... > Set each relay to launch at system startup via the named /etc/rc.d scripts in > /etc/rc.conf.local's pkg_scripts. > tor_flags="${tor_flags} -f /etc/tor/torrc" > tor2_flags="${tor2_flags} -f /etc/tor/torrc2" > tor3_flags="${tor3_flags} -f /etc/tor/torrc3" > ... > pkg_scripts=" ... tor tor2 tor3 ..." > Set openfiles-max for each named pkg_script from /etc/rc.conf.log in > /etc/login.conf. > tor:\ > :openfiles-max=8192:\ > :tc=daemon: > tor2:\ > :openfiles-max=8192:\ > :tc=daemon: > tor3:\ > :openfiles-max=8192:\ > :tc=daemon: > ... > Remember to allow inbound traffic to the additional ports set in > /etc/tor/torrc[#] in your /etc/pf.conf. Why give advice on "tor3" when the current consensus parameter for limit per IP is 2? In case someone has an extra IP? Or are you hoping we will increase the consensus parameter to 3? I could revive that suggestion, by the way - it stalled as trac #13414 due to concerns with making sybils easier. https://trac.torproject.org/projects/tor/ticket/13414 Maybe we could try for 3 per IP? teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

2 1

Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by grarpamp 16 Dec '14

16 Dec '14

On Tue, Nov 4, 2014 at 12:25 PM, Libertas <libertas(a)mykolab.com> wrote: > I think it would be a good idea to add OpenBSD to doc/TUNING because [...] > promoting OpenBSD relays benefits the Tor network's security. Absolutely. Not just due to OpenBSD's security positioning, but moreso from network diversity. Windows is its own world. But if you're a Unix admin there's no reason Linux should be deployed 20x more often than [Free/Open]BSD. It's ridiculously counter to meeting diversity goals, especially with bandwith weighting if one platform is getting grossly disproportionate traffic than another. Just pick one of the two BSD's and run it instead. FreeBSD in particular is well suited to the OS and network needs of Tor. And knowing how to admin more Unixes will serve any admin well. 5950 Linux 1593 Windows 173 FreeBSD 55 Darwin 44 OpenBSD 7 NetBSD 6 SunOS 4 Bitrig 2 GNU/kFreeBSD 1 DragonFly

12 29

Out of memory message
by Logforme 15 Dec '14

15 Dec '14

I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC3). Yesterday I saw new messages in the log file: Dec 06 09:28:13.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 06 09:28:16.000 [notice] Removed 1040388096 bytes by killing 1 circuits; 14631 circuits remain alive. Do I read that correctly as one circuit using 1GB of memory? Here's the first lines from the top command: top - 09:40:41 up 31 days, 1:51, 1 user, load average: 0.53, 0.62, 0.66 Tasks: 95 total, 3 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 10.2 us, 2.0 sy, 0.0 ni, 83.2 id, 0.0 wa, 0.0 hi, 4.5 si, 0.0 st KiB Mem: 3950828 total, 3833092 used, 117736 free, 49696 buffers KiB Swap: 3212284 total, 1296392 used, 1915892 free, 99168 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2680 debian-t 20 0 4134m 2.8g 24m R 63.5 73.4 27199:00 tor The relay is running on a dedicated debian box with 4GB of ram. It usually only uses about 0.5GB but now it is maxed out. The relay and the box is so far working fine, I just wonder if this is some kind of attack or if anything is wrong and if there is anything I should do about it.

5 8