- tor-relays - lists.torproject.org

Watching the attacks on my relay
by elrippo 09 Nov '13

09 Nov '13

Hy there. I did some graphs of the attacks raiding against the network and the method is quite interesting. Take a look at it, maybe it helps a bit. https://elrippoisland.net/public/tor_attack/attack.html -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo(a)elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL -----END PGP PUBLIC KEY BLOCK-----

8 11

Relay-Bandwith
by Oliver Schönefeld 09 Nov '13

09 Nov '13

hey folks i'm having some issues with my bandwidth... my ISP is offering 50 Mbps downstream 10 Mbps up, so i thought i'd share 20 Mbps max and 15 Mbps avg (respectively 2560 KBps max and 1920 KBps avg) in a inner tor-relay. so i put the latter vaues in the bandwith-limits tab of the sharing options in vidalia with the download speed set to custom. However the tor metrics indicate an advertised bandwith of 317,44 KBps and the worldmap of vidalia even shows just 20 KBps :( So my question is now: Can this be improved and if so, what should i do about it? Or is this maybe because the relay isn't even up 24 hrs and the bandwith will level in somehow later? thx 4 any advice in advance, 1v3ry

4 3

Re: [tor-relays] tor-relays Digest, Vol 34, Issue 22
by that guy 09 Nov '13

09 Nov '13

On 11/09/2013 11:32 AM, tor-relays-request(a)lists.torproject.org wrote: > Using a VPN *might* work, but Microsoft blocks access from many of those too. > > Complaining to Microsoft, especially if you're a paying Skype customer, might not help, but it can't hurt. Same boat but with two woman on two continents and both use Mshit and there is not a chance in the world that they will ever ever ever get jitsi, linphone, Ekiga or any of the other joke excuses for a Skype replacement going. Until there is a non-MS solution that lets non-techies use a service like that from behind NAT they are a HUGE waste of developer's time not to mention consumers. Take a look at the Ekiga mailing list, makes the problems people have with tor relay's seem like child's play. It is almost pathetic listening to them try to help people who WILL NEVER manage to get one up and running. It is a joke. My VPN blocks Skype. I tried hard to get rid of it but it is just not possible unless it's another geek that you are talking to. Complaining to MS or Apple can hurt actually, in the hopelessness area. May end up hanging yourself after trying to talk to them.

1 0

(no subject)
by bbzxrmy wowman 09 Nov '13

09 Nov '13

high, i recently set my relay and also mailing list, however my screen name "BBZzXArmy does not show on the tor world map, can anyone confirm or help me with this im pissed at it zigzagarmy }{}{}{}{}{}{}{}{ BbZzXArmy PrajectoRkiDD ****MASS CHAIN MESSAGE read and spread to all your friendlists (. http://zeja11.blogspot.com/ .) 22eterniA .xex

3 2

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

09 Nov '13

> Date: Wed, 6 Nov 2013 17:12:37 +0000 > From: Thomas Hand <th6045(a)gmail.com> > To: tor-relays <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] exit and skype > Message-ID: > <CAKqc3T7u6mWC6CZLMoaEGkr2iUPe3rabgV-=fi=3LzP67w=oHA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > If you want to continue using skype, you could invest in a VPN just to hide > it from your ISP and make microshaft think you are coming from a different, > non-tor related IP. > > Tom Thanks for the suggestion. Jitsi is working fine, in combination with running prosody on my server. Gf is happy too, fhew! One down, one to go (her mother).

1 0

Gmail forcing a password reset with tor birdy
by Zack Becker 08 Nov '13

08 Nov '13

I use Gmail for my junk email because of its storage. I would like to use Tor Birdy for thunder bird, but Google forces me to reset the password because of a "suspicious sign in prevented".

2 1

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 > > there > > > anything I can do except converting the exit into a relay? > > > > You could try Jitsi or Blink. They're not the same as Skype but they > > are freer and the sound is better. > > > > /Lars Thanks for the suggestions. I would need something cross-platform (Linux, Windows, ipad). I'll try Jitsi.

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'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