tor-relays May 2014

tor-relays@lists.torproject.org

60 participants
34 discussions

Trying Trusted Tor Traceroutes
by Sebastian Urbach 06 Jul '14

06 Jul '14

Dear list members, Just a quick update regarding the TTTT project. There are multiple GB's of data to analyse and it is still being worked on. We are also working on the public script(s) as well. Thanks for your ongoing support ! -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

2 1

running Tor relay live with AddressSanitizer
by starlight.2013q4＠binnacle.cx 28 Jun '14

28 Jun '14

Has anyone tried running a live relay with an image built using GCC 4.8 and -fsanitize=address? AddressSanitizer documentation says it should be no worse than about x4 on CPU and typically about x2, so it looks reasonable to try. I'm seeing peak CPU of about 7-8% of a 2.2GHz AMD core. I'd probably create a static build, with 'libevent' and 'tor' compiled using -fsanitize=address -O1 -fno-omit-frame-pointer -g per the Google documentation and 'libz' compiled normally since 'zlib' is stable and mature. Any thoughts or experience? Thanks

3 6

Need help to get TorDNSEL compiled
by BlueStar88 26 Jun '14

26 Jun '14

Hi there, today I've read about the outage at "check.torproject.org". Since my torcheck-service "torcheck.xenobite.eu" needs the underlying TorDNSEL feature I'm trying to get this to work on my host. Like this I won't need to query the TorDNSEL-part of "check.torproject.org" anymore. I'm not into programming and do not know anything about haskell, c++ and such. So be patient with me on such matters. ;-) I've DL'ed the code from the internet website mirror [2]. I've prepp'ed all the dependencies using lucid binary packages: ghc6 6.12.1-12 libghc6-mtl-dev 1.1.0.2-10 libghc6-network-dev 2.2.1.7-1 libghc6-time-dev 1.1.2.4-2 libghc6-hunit-dev 1.2.2.1-2 libssl-dev 0.9.8k-7ubuntu8.15 libghc6-stm-prof 2.1.1.2-5 libghc6-binary-prof 0.5.0.2-1 First error I got on compile attempt was: src/TorDNSEL/Main.hs:81:21: parse error on input `#' That was quite easy thought: import GHC.Prim (Addr#) I deleted the '#' hopefully making it correct this way. Next error is some numbers too high for me now: src/TorDNSEL/DeepSeq.hs:20:7: Could not find module `Data.ByteString': It is a member of the hidden package `bytestring-0.9.1.5'. Perhaps you need to add `bytestring' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. The libghc6-bytestring-dev-0.9.1.5-125af ist installed by it's main package ghc6 6.12.1-12. Any ideas? Or are there some binary packages for TorDNSEL around, to make this more easy for me? :-P Thanks, BlueStar88 [1] https://blog.torproject.org/blog/tor-check-outage-03-and-04-july-2013 [2] https://www.torproject.org/tordnsel/dist/tordnsel-0.0.6.tar.gz

3 7

Ops request: Deploy OpenVPN terminators
by grarpamp 17 Jun '14

17 Jun '14

Ops request: Deploy OpenVPN terminators We are ops because we want to allow people to avoid censorship and speak freely. But are we doing all we can? It is well known that all relays, exit or non-exit are added to a variety of blocklists. Primarily through scraping the consensus. And those blocklists are then used to indiscriminately deny legitimate users/people access to sites, regardless of their 'behaviour', which more often than not has simply not been determined yet. So we need to augment what we're doing in order to be effective in our mission. Here's how... We already run Tor on an IP, that IP is blackballed as noted above, so using another port on it as a vpn terminator is pointless. Yet our hosting packages often offer other IP's in the same range, or we already have them to use as part of the deal (or, failing that, we can forward the openvpn TCP port on our bad relay IP to another clean non-bulk-blocked IP we control). We obviously cannot publish this new openvpn 'exit/termination' IP anywhere, such as in the comment field of the consensus as it will be banned. *But we can bind to it and let users find it with their own openvpn scans close to (one up or down from) our OR IP.* Just use the standard openvpn TCP port on it. There is no bandwidth cost to us to do this because all the traffic is moved between the exit IP and the openvpn termination IP over localhost. (Well, unless you are forwarding openvpn port on OR IP to another termination real IP off your box.) At minimum we should allow TCP transport out from the vpn to the world, aka the usual nat, so as to make websurfing work for our users. Bonus for allowing nattable outbound UDP, ICMP, etc. Further bonus for allowing inbound binds on whatever port on the IP that is available to be bound to. Obviously sine the IP is scarce to us, we can't allow full unnatted use of the IP. The point is, we already own these extra IP's, and legitimate people are being blocked from services for no reason other than kneejerk or blind reactions to Tor via blocking services. Ahem, cloudflare, et al and other blocking 'services' well known to us. So to the extent we have other IP's available to us, we should set them up to be unpublished openvpn nodes and let users find us by trying to terminate their vpn connections on us at that IP and openvpn port. Yes, blocklists could try the 'one IP up/down' scan method and list this project of ours too, but it's more work for them and they're unlikely to do it in any sort of global fashion. Especially since they can't prove it's part of Tor (because we don't publish the IP's as such). If we wish to make an announcement that we are running such terminators, obviously it should not be made from addresses related to our OR IP's. [FWIW, there is another openvpn terminator project out there. Unlike ours would be, its nodes are public, and even with that detriment (though possibly only because it is lesser known) it obtains more freedom from blocklisting than Tor. However its termination points perform poorly/unreliably whereas ours would be both nonpublished and better managed.]

10 18

Usefulness of very limited exit policy nodes?
by Phil 31 May '14

31 May '14

Hi, Opinions please - is it worthwhile running an exit node on a home DSL connection with limited bandwidth and exit policies? I'm talking 150Mb per day, 20Kb/s, and only allowing ports 80, 443 and 53 out. I'm concerned about potential abuse from exit traffic more so than limited bandwidth. I've only had it up for a few days and the bandwidth is being used. Is such an exit policy useful for the network? Or would I be better off just running as a relay? Are there other ports that I could allow to exit that would make this node more useful, while not greatly increasing the risk of abuse reports coming my way? Phil

4 5

Running exits from home, posting exit-notice
by grarpamp 31 May '14

31 May '14

In some threads people are running exits from home for principle, economy, management, etc. Some threads question risk. Just as you put exit-relay-notice on your IP to obtain advantage of chance of reading it first before interacting with you, you may consider literally posting it on your doors. Also, even paid hosting location could have advantage from this. https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/contrib/operator-too… Btw, the link to that at the bottom of here is 404: https://www.torproject.org/docs/tor-doc-relay.html.en

2 1

Confirm IPv6 Setup as Exit Node
by Adam Brenner 30 May '14

30 May '14

Howdy, I have setup a Tor exit node and IPv4 appears to work (will get a real test in the next 48 hours). I would like to confirm my IPv6 setup as I have found the documentation on this subject lacking (or my googling skills suffering!) Added the following to my torrc file: ORPort 9001 ORPort [2606:2e00:0:19::4]:9050 # first line works with IPv4 while second line is supposed to be IPv6 IPv6Exit 1 ExitPolicy accept6 *:* # Allow all IPv6 Requests I did not specify anything for DirPort as I believe this is not working under IPv6? Is this correct? For reference my fingerprint is 6269EC22B7970ACDE4AF09F6ADE67CEB0C7F7964 -- Adam Brenner <adam(a)aeb.io>

7 9

Exit node little traffic after Named flag?
by Mike Patton 29 May '14

29 May '14

Hi all, I started running an exit node as a test, about a month ago. Initially everything was fine and traffic was good up to my throttled limit. However since my relay got given the Named flag, my traffic has been very very low. Any idea why that would be? Relay nick is NetFreedomTest2 Regards, M.

2 1

Please help profile Tor 0.2.5.4
by Moritz Bartl 28 May '14

28 May '14

Nick could use your help identifying potential bottlenecks in the 0.2.5.4-alpha release by profiling your relay. This is especially useful on high bandwidth relays (> ~50 Mbit/s). https://trac.torproject.org/projects/tor/ticket/11332 Ideally, attach your report(s) to the ticket (you can use cypherpunks/writecode as login if you don't want to create a user). Thanks! -- Moritz Bartl https://www.torservers.net/

1 0

hardening a tor relay
by Contra Band 27 May '14

27 May '14

Hi all, I'm impressed by Tor and its contribution to freedom of speech and started to run some tor relays. The first one is https://atlas.torproject.org/#details/DBE3CE33BA8BF1CB98091EE2A72690DF8218C… and I have applied tight iptables to that as below. Can somebody advise what should be add/remove to make it more efficient to tor network? =========iptables-rules.sh========== # Flushing all rules iptables -F iptables -X # Setting default filter policy iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP #ipv4 udp drop all iptables -A INPUT -p udp -j DROP iptables -A OUTPUT -p udp -j DROP #ipv6 udp drop all ip6tables -A INPUT -p udp -j DROP ip6tables -A OUTPUT -p udp -j DROP # Allow unlimited traffic on loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT # Allow incoming SSH iptables -A INPUT -p tcp --dport xxx -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport xxx -m state --state ESTABLISHED -j ACCEPT # Allow incoming 443 iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 443 iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT # Allow incoming 9050 iptables -A INPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 9050 iptables -A OUTPUT -p tcp --dport 9050 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9050 -m state --state ESTABLISHED -j ACCEPT # Allow incoming 9051 iptables -A INPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 9051 iptables -A OUTPUT -p tcp --dport 9051 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9051 -m state --state ESTABLISHED -j ACCEPT # Allow incoming 9001 iptables -A INPUT -p tcp --dport 9001 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 9001 -m state --state ESTABLISHED -j ACCEPT # Allow outgoing 9001 iptables -A OUTPUT -p tcp --dport 9001 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 9001 -m state --state ESTABLISHED -j ACCEPT Thanks Simon

8 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays May 2014