tor-relays October 2013

tor-relays@lists.torproject.org

80 participants
54 discussions

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

Amazon abuse report
by Sanjeev Gupta 10 Nov '13

10 Nov '13

Hi, I am running a number of Tor relays, in my own DC and at Amazon Singapore. I got an email from Amazon last week, for the Windows instance: == Hello, It's come to our attention that one of your EC2 instances may be configured as a Tor exit node. Please note that any open proxy activity is prohibited in our AUP: http://aws.amazon.com/aup/ Please respond to this email detailing the corrective measures you plan to take. If you believe our findings to be in error, please provide additional information about how this activity relates to your use case. Regards, Amazon EC2 Abuse Team == Since Tor Cloud https://cloud.torproject.org/ suggests running on Amazon EC2, I am confused. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

20 53

max TCP interruption before Tor circuit teardown?
by Gordon Morehouse 03 Nov '13

03 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm working on building support scaffolding[1] for Tor on Raspberry Pi and other small ARM single-board computers (SBCs). With the slower computers, sometimes too many attempts to connect to the ORPort (I am almost positive as part of TAP circuit building, but not *really* sure) can eventually cause Tor to consume more physmem than available and cause the oom-killer to kill Tor. Also, depending on the crappiness of the user's router, it's effectively a SYN flood, and can crash or impair consumer routers. My solution, so far, is to define (through trial and error on a per-machine basis, since [1] is only officially supporting 3 SBCs right now) limits on how many SYNs may be sent to the ORPort and the DirPort per second. This is done with iptables. I experimented, tuned the parameters and watched traffic for weeks and came up with a pretty good set of limits for a 950MHz Raspberry Pi: 4 SYNs/sec burst 10. (For those about to say the Pi is thus too slow to be used as a relay, it's quite capable of relaying *at least* 2.5Mbps, but *not* when it's getting SYN flooded.) So, sometimes hosts exceed this limit. Once the limit is exceeded, my current strategy is to use iptables REJECT to send an ICMP Service Unavailable (or whatever it's called, sorry no coffee yet) back to the hosts that triggered the filter. This is on a per-SYN basis. After watching the data, I noticed that some hosts just try to connect once or twice, or try to connect (during overload conditions) at reasonable intervals of tens of seconds to a few minutes. Other hosts will quadruple-tap the ORPort with SYNs, four in a row, and otherwise be much more aggressive with sending SYNs. I'm currently testing fail2ban[2] as a way to ban aggressive peers by changing that iptables REJECT to a DROP for a short period, in order to accomplish two things: 1. Encourage them to knock off their bad behavior (i.e., go away for a little while). 2. Free up CPU time, RAM and bandwidth because we don't have to construct and send ICMP packets to banned peers. Currently, if a peer violates the 4/sec burst 10 SYN limit more than 5 times in 60 seconds, that peer will be banned for 90 seconds. I'm trying to trim this down to the minimum that will protect the relay, and 90 seconds is a guess given some of my fears, read on... During an overload condition, my primary priority is to protect the relay, but of course I wish to do so with as little disruption to the Tor network as possible. So, here is a potential problem with my approach that I can think of, which could degrade service (mildly, for a few end users) on the Tor network. First, during a SYN flood type overload, some peers which have *existing* circuits built through the relay and are sending SYNs as normal traffic, will stochastically get "caught" in the filter and banned for a short time. If these hosts already have circuits open through the relay which is overloaded, I would prefer to preserve those circuits rather than break them. My defensive strategy versus overload here is to throttle new circuit creation requests, *not* to break existing circuits. So here's the $64,000 question: If a tor relay has a circuit built through a peer, and the peer starts dropping 100% of packets, how long will it take before the relay with the circuit "gives up" on the circuit and tears it down? I want to set my temp ban time *below* this timeout. Thus, unlucky peers that were caught in the filter and have circuits already built through the relay they will experience a brief performance degradation, but they won't lose their active circuits through the overloaded relay, and in the meantime hopefully the overload condition is becoming resolved. Is there such a timeout? There must be. Can someone tell me what it is? Or, is there a better way to protect low-resource machines (slow CPU, 512MB RAM) against the SYN flood "circuit creation storm" conditions which occasionally arise on the Tor network? Again, I must reiterate, machines with specs like these can be very good relays for home broadband users. The true goal of my project[1] is to build a set of software which enables a "plug and forget" relay for home broadband users that costs well under $100. [1] https://github.com/gordon-morehouse/cipollini [2] http://www.fail2ban.org/wiki/index.php/Main_Page Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSZAfXAAoJED/jpRoe7/ujGQ4H/jUUjdufoWw1qthjsqdf4ICO ejJXBuZ60O8TpuiT07EtZq9tSDsb5hLqjJMORNJWPJe3ffD7/BHv/6St0y0fkjFh svEFBwVMmkNfaDd65z2JaFBRnSQTsgtiOeOnQFQt1evWQMeVmFsvoMvVIbqGSkf6 NipJnfFeoAtt/6cCMl7+yIxmGGb1Udl0ZEmlVacIYtFr8MjgIo59vT94k7SuzV1N 4Na9PNeQ9WIBlZf9vyesHgnuzJA8hEkFyoP5Fc3bPT/e3WYdAIifswE6rhZVT+AQ 9rHRvBUVoYpMNyy0fqMY34rLYegelIYstsy26dmW+robJKDxGVC3zBeGbOtcEOE= =mSYu -----END PGP SIGNATURE-----

5 29

Cisco ASA
by starlight.2013q4＠binnacle.cx 31 Oct '13

31 Oct '13

For anyone running a Cisco ASA between their 'tor' relay and the Internet, some potentially useful info: The default ASA connection timeout is short and often results in 'telnet' sessions through VPN tunnels getting whacked. So one might add timeout conn 48:00:00 to a config to mitigate that issue. However a busy 'tor' relay instance will rapidly accumulate large numbers of dead connection table entries due to loss of FIN packets from flaky corners of Internet. I'm not 100% sure about this, but it seems these dead connection table entries can impair the formation of new connections, not to mention the obvious potential for excessive memory consumption on the ASA. The solution is: access-list tor-class extended permit tcp any host X.X.X.X access-list tor-class extended permit tcp host X.X.X.X any where X.X.X.X is the 'inside' server running 'tor' class-map tor match access-list tor-class policy-map outside class tor set connection timeout idle 0:06:00 As 'tor' sockets have a default KeepalivePeriod 300 any connection with an idle time of more than five minutes is a dead duck and can safely be removed. Checked this out carefully. The comment above was inspired by a seeming performance boost and increase in connections observed after the change was made, not by direct traffic analysis. Could be coincidental. The way to verify it's working is with the show conn addr X.X.X.X long command, which includes the idle timeout associated with each connection. If one has other services running on the same box as 'tor', it might be necessary to adjust the 'access-list' to take them into account.

1 0

Re: [tor-relays] Advice on dealing with ISP's response toDMCAtakedownnotice.
by tor＠t-3.net 30 Oct '13

30 Oct '13

Yeah. Not saying I see a good way to do it. Not really asking for it. Whiny, IDS-noticed, almost nuisance-type complaints are the only ones we've gotten. The complaints aren't even describing successful intrusions. Sucks if these whinebucket type of complaints are making it harder in real world terms for people to host exit nodes. On Wednesday 30/10/2013 at 8:56 am, Linus Nordberg wrote: > Hi, > > Sounds like you risk ending up with a censorship tool controlled by > those who control the list of attack signatures. > > I'd prefer if we educate service providers about this dangerous place > called the internet with the goal of making them turn down the volume > on > their sirens a notch. > > > tor(a)t-3.net wrote > Wed, 30 Oct 2013 07:56:28 -0400: > > | What he said. > | > | No DMCA so far but, one thing I keep getting is complaints about > "SQL > | injection attacks". Apparently snort or other IDS picks this stuff > up > | and emails the abuse box. Some but not all of the complaints are > | automated. > | > | It would be nice if something could detect these attack signatures > on > | the internet-bound packets from our exit node and drop them. With > | trends as they are, we'd see zero abuse complaints, if there were a > | good way to do that. > | > | > | > | > | On Wednesday 30/10/2013 at 6:41 am, Moritz Bartl wrote: > | > On 25.10.2013 19:13, krishna e bera wrote: > | >> > | >>> > | >>> ExitPolicy accept *:1723 # PPTP > | >> How are you getting PPTP to work over Tor? The ISP-supplied > modems > | >> i've > | >> seen won't pass IP protocol 47 (GRE) packets without putting the > | >> target > | >> machine in a DMZ. > | > > | > > https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy> > contains it. > | > > | > It's more of a "catch all" exit policy, but gets rid of most DMCA > | > complaints. > | > _______________________________________________ > | > 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

1 0

Re: [tor-relays] Advice on dealing with ISP's response to DMCAtakedownnotice.
by tor＠t-3.net 30 Oct '13

30 Oct '13

What he said. No DMCA so far but, one thing I keep getting is complaints about "SQL injection attacks". Apparently snort or other IDS picks this stuff up and emails the abuse box. Some but not all of the complaints are automated. It would be nice if something could detect these attack signatures on the internet-bound packets from our exit node and drop them. With trends as they are, we'd see zero abuse complaints, if there were a good way to do that. On Wednesday 30/10/2013 at 6:41 am, Moritz Bartl wrote: > On 25.10.2013 19:13, krishna e bera wrote: >> >>> >>> ExitPolicy accept *:1723 # PPTP >> How are you getting PPTP to work over Tor? The ISP-supplied modems >> i've >> seen won't pass IP protocol 47 (GRE) packets without putting the >> target >> machine in a DMZ. > > https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy > contains it. > > It's more of a "catch all" exit policy, but gets rid of most DMCA > complaints. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Advice on dealing with ISP's response to DMCA takedownnotice.
by tor＠t-3.net 30 Oct '13

30 Oct '13

Reply to the email, say that you found a misconfiguration in your Tor daemon which could have accounted for this problem and you've repaired it, and hopefully this problem is resolved for the future. Put the below as your exit policy in torrc, and I'd stop/start the service to be sure it grabbed it. Using the below exit policy, we've had our exit node running for a couple months or so doing pretty good bandwidth, and not had a single warez-related complaint. Seen some complaints about SQL injection attacks but perhaps those will annoy your ISP less. ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews etc ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy reject *:* On Thursday 24/10/2013 at 9:11 pm, Christopher Jones wrote: > > I’ve been running an exit relay for about 3 days and, sure enough, > some BitTorrent bugger caused sh3lls.net to send me a DMCA nastygram: > >> >> We have got the following complain, please remove all illegal torrents >> immediately from your server: >> >> Evidentiary Information >> Title: Suits (TV) >> Infringement Source: BitTorrent >> Initial Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Recent >> Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Infringing Filename: >> Suits Season 3 Episode 6 (The Other Time) (HDTV x264)-ASAP (1GBps >> SeedBox).mp4 URL if applicable: >> Infringing File size: 364405400 >> Infringers IP Address: 64.32.14.34 >> Bay ID: 7fbb4256bfca558d5a809b9f6536b5fd5e4e782d|364405400 >> Port ID: 33788 > > I followed through with the templates provided by the Tor Project as a > response to the DMCA takedown notification. A day later, the ISP sent > me this: > >> >> Dear Christopher >> Whether you run Tor or not, we even told you in past, it's your >> responsibility to stop all abuse >> If Tor is causing it, stop the program Tor on your server, if we get >> another complain we will have to suspend/terminate your services >> >> tor always always gets lots and lots of abuse and complains >> >> Update us within 24 hours >> >> Thanks > > I was never provided with the full text of the original DMCA > complaint, so I was unable to respond. Furthermore, I was never > “even told…in the past” that I had to stop all abuse caused by > Tor. Tor is not singled out in the ToS or AUP. And I was certainly > never told anything in the past about abuse and Tor specifically. As I > said, first warning. Then there’s the “tor always always gets lots > and lots of abuse and complains [sic]”. Which is kind of bizarre, > because their position on tor seems a bit cagey. Does the claim about > lots of abuse mean they won’t allow exit nodes? Or is that just a > “hint” that I’d be better off not trying to run it? > > And this is an ISP I picked from the good list. > > Suggestions are welcome. I’m running with the default exit node > policy, which should block most of the abuse-laden ports. > BitTorrent’s a little harder to deal with. I’ve no qualms working > with the ISP to mitigate their concerns, but I’m not sensing their > returning the same spirit of cooperation. > > .cpj_______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

3 2

Filtering TOR Non-exit Relay - Just Curious
by Nelson 29 Oct '13

29 Oct '13

Tor Exit Relay have the ability to filter traffic by allowing the operator make choices based on personal preferences for personal, legal (ex: country of origin) and for other reasons. Non-exit Relays do not have the ability to set "Relay Policies" (torcc??), and why would they, considering that all this traffic is encrypted anyway, as I understand it, and one would not ever know what type of traffic it is, or its origin, based on the bandwidth graph. I checked my smoothwall firewall logs it does not seem to show the traffic flowing on my relay, I guess this would be obvious because it's Tor traffic; unless I'm not filtering the logs correctly. Running a Tor relay seems straightforward and one could just fire-it-up and easily contribute to the network. But my curiosity gets the best of me. I was looking to add additional URL Filter rules for my smoothwall as a more centralized way of controlling what gets to the LAN for my users. While checking for additional blocklists I came upon P2P rules and I started to compare the new blocklists with my old ones and then I stumbled upon PeerBlock which has been around for a while. On Windows 7, PeerBlock seemed to provide two things I was looking to test on a TOR Relay: 1. Real Time Traffic Logging (ip's and ports logged) 2. The ability to filter traffic. Apparently I am able to do both with PeerBlock, although I'm sure there are more suitable and capable tools available out there that do this, but I'm not aware of or have used any of these tools. In peerblock I can create new custom lists and completely block specific ip ranges (ex: warez, torrents etc.), and I am able to see what traffic is allowed or blocked based on policies created. 1. What problems, if any, arise from using peerblock and Tor together? 2. Why do we not have the ability to at least set our own policy for the type of traffic on a relay just like an Exit Relay?

6 9

"stable" flag voting differences
by starlight.2013q4＠binnacle.cx 28 Oct '13

28 Oct '13

I observed an interesting behavior in the authority votes regarding relay stability and am curious if anyone can comment. Have a new relay, about ten days old. Relay is marked Fast Guard Running Stable Valid One 10 minute network outage three days ago and then a 68 minute outage one day ago for repair. Overall about 4680 seconds down over the last week, and if one uses a 646220 second timeframe per this post https://lists.torproject.org/pipermail/tor-relays/2013-July/002255.html It works out to about 99.27% uptime, which seems within the 98% threshold quoted in the posting. What was interesting was that Faravahar gabelmoo maatuska tor26 urras all immediately removed the "stable" flag when the relay came back online after maintenance, while dannenberg moria1 left the stable flag in place. The two remaining authorities dizum turtles have never set the stable flag due to heavy link congestion between AS286/AS3265 for 'dizum' and congestion within AS6461 for 'turtles'. Then exactly 24-hours after the end of the outage the five naysayers turned the stable flag back on. Mainly a point of curiosity, but I'd guess from this that the first five authorities listed above are using a much shorter window for evaluating stability while the second two are using the seven-day window. I couldn't find per-authority logging of this category of information so it's hard to know. Perhaps it's relevant that the node was removed from the consensus directory briefly immediately after the outage ended. Finally it is interesting that 'dizum' and 'turtles' have set the "guard" flag even though they consider the relay unstable. This is a recent development. Earlier the two impaired-path authorities had the guard flag set off.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays October 2013