- tor-relays - lists.torproject.org

How to install Tor on Ubunt 12.10?
by The Maker 06 Nov '13

06 Nov '13

I want to run a relay that starts every time I login to my machine. I went to the page that discusses how to add the correct PPA to Ubuntu but it stops at 11.10. Is this also the PPA I should use for 12.04 or is there another one? Many Thanks, The Maker

3 2

Re: [tor-relays] exit and skype
by Jan Hendrik den Besten 05 Nov '13

05 Nov '13

> On Tue, Nov 5, 2013 at 2:54 PM, Lars Nood?n <lars.nooden(a)gmail.com> wrote: > > > On 11/05/2013 09:00 PM, Jan Hendrik den Besten wrote: > > > Boy, now I am in trouble... > > > > > > I run an exit node from my home address for a few weeks now, but my gf > > > starts complaining she cannot use Skype anymore to chat with her mum. > > > > > > I understand Microsoft blocks all tor exits from accessing Skype. Is > > … [View More]

1 0

Re: [tor-relays] Amazon abuse report
by tor＠tafb.xxx 04 Nov '13

04 Nov '13

I'm new to running a relay. There are lots of exit policies when I look at my atlas details: https://atlas.torproject.org/#details/DDB401F4CA108C6F6AF4E0DCE2DFC3407F577… Is this a pretty good exit policy list to prevent harassment from my ISP? Thanks! -Jamie M. > Putting the extensive exit restriction policy in the responses to take-down demands seems like a good idea. > > Robert

7 11

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'… [View More]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----- [View Less]

5 29

Re: [tor-relays] dynamically adjusting bandwidth
by starlight.2013q4＠binnacle.cx 03 Nov '13

03 Nov '13

>The question is, should I put in an adjustment for >'MaxAdvertisedBandwidth' during the backup window >or make any other change to advise remote relays to >de-prioritize the node for the duration? Another unanswered question now understood: As a consequence of a simple parameter tweak, Vidalia buggily zapped (for the second time) the relay configuration and turned off relaying. Quickly restored 'torrc' and restarted the relay, but noticed that the getinfo dir/server/authority … [View More]

2 1

connecting to obfsproxy bridge from OSX10.9 and TorBrowser-Pluggable-Transports-2.4.17-beta-2-pt3-osx-i386
by Paul Garrett Hugel 03 Nov '13

03 Nov '13

Please steer me to the correct list if off topic here Remote machine is Ubuntu obfsproxy bridge on amazon ec2 using ARM My local machine running 10.9 Mavericks with TorBrowser-Pluggable-Transports-2.4.17-beta-2-pt3-osx-i386 I read the trouble ticket #10030 https://trac.torproject.org/projects/tor/ticket/10030 changed the torrc file entries as indicated below ClientTransportPlugin flashproxy exec ./flashproxy-client --register :0 :9000 ClientTransportPlugin obfs2,obfs3 exec ./obfsproxy.bin … [View More]

3 2

Re: [tor-relays] significance of different bandwidth values
by starlight.2013q4＠binnacle.cx 01 Nov '13

01 Nov '13

At 16:19 10/15/2013 -0400, starlight(a)binnacle.cx wrote: >Question: > >What the difference between the bandwidth >value given by > getinfo ns/name/xxxxx > >>> w Bandwidth=297 >and > getinfo dir/server/authority > >>> bandwidth 300000 375000 335872 Since no one answered the question and I now have an idea about it, I'll attempt an answer for future web-searchers. . . getinfo ns/name/<node-name> This appears to be a consensus … [View More]

1 0

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 … [View More]

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 … [View More]

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 … [View More]

2 1