[tor-relays] Botnet issues and upgrading to 0.2.4.x

Sun Oct 20 17:25:04 UTC 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks Gordon, I've been following your posts about the
circuit-creation storms with interest. I recently upgraded my Pi to
Tor v0.2.4, and haven't witnessed a storm yet (they are relatively
rare for me). But I am certainly interested in trying out your
mitigation strategies.

Regarding your deb packages, have you considered talking with any
Debian or Raspbian devs? Getting them to sign your public key, and
possibly even accepting your packages upstream, would create a web of
trust so folks would be more willing to install what you build.

On 10/20/2013 12:55 PM, Gordon Morehouse wrote:
> Dan Staples:
>> In my experience, setting the bandwidth advertising options does
>>  nothing to stop the "storms" of circuit creation requests.
> 
> This is absolutely correct, and I've been working on this problem
> with the Pi for months now.
> 
> 
>> It *will* affect the *average* bandwidth used by your relay, but 
>> every once in a while, I'll still get circuit-creation storms
>> that completely overwhelm my RPi and knock it offline (I'm
>> talking continuous 3Mbps bandwidth use for several hours when 
>> MaxAdvertisedBandwidth is 200 kbps). It seems from past
>> discussions on the mailing list, this is still an unresolved
>> issue.
> 
> Correct.
> 
> I have an ongoing project to support Tor on small single-board 
> computers, including the Raspberry Pi.[1]
> 
> In the contrib/90_slowboards dir, I've included some iptables
> rules that drastically reduce, but *do not eliminate*, Tor's
> vulnerability to running out of physical RAM and being killed
> during a SYN flood/circuit creation storm.
> 
> I've also included some fail2ban[2] rules that ban hosts for short 
> periods of time when they ignore the iptables SYN throttling.
> However (and I'll push a commit in the next hour changing this),
> I'd suggest you use a "findtime" of 60 and "bantime" of 90, not 300
> and 600 as I first pushed to the repo.  Please see this post[3] for
> more technical talk/questions, which I *just* made before reading
> yours and writing this reply.  Please be aware that the fail2ban
> fallback is much less battle-tested (on my relay) than the iptables
> SYN throttling.
> 
> Incidentally, I host binary .debs compiled *for Raspbian* at [1]
> as well, if you trust random internet dudes and don't want to
> compile it yourself.  A deterministic build is a (very long-term)
> goal.
> 
> 1. https://github.com/gordon-morehouse/cipollini
> 
> 2. http://www.fail2ban.org/wiki/index.php/Main_Page
> 
> 3. 
> https://lists.torproject.org/pipermail/tor-relays/2013-October/003074.html
>
>  Best, -Gordon M.
> 
> 
>> On Mon 14 Oct 2013 04:43:50 PM EDT, Chris Whittleston wrote:
>>> Thanks Logforme - yeah I was trying that before I sent the
>>> first email in this chain, but maybe I didn't go low enough
>>> with the advertised bandwidth. When the 0.2.4 compilation is
>>> done (it's still chugging along) I'll try going lower and see
>>> if it helps.
>>> 
>>> Chris
>>> 
>>> 
>>> On 14 October 2013 21:38, Logforme <m7527 at abc.se 
>>> <mailto:m7527 at abc.se>> wrote:
>>> 
>>> On 2013-10-14 22:01, Chris Whittleston wrote:
>>>> I see - so I'll probably still see the problem with a huge 
>>>> number of circuits being created after I've finished
>>>> building 0.2.4. Is there any way to limit this, I'm guessing
>>>> reducing the bandwidth wouldn't actually help? I guess I'll
>>>> look into how much further I can
>>> overclock
>>>> the CPU...
>>> Only option that I know of is to reduce the bandwidth you 
>>> advertise to the network. The more bandwidth you advertise the 
>>> more circuits the tor network will throw at your relay. The 
>>> following flags in the torrc file can be used (with my current 
>>> understanding of them): BandwidthRate : The max bandwidth you 
>>> provide over a long period of time BandwidthBurst : The max 
>>> bandwidth you provide over a short period of time 
>>> MaxAdvertisedBandwidth : The max bandwidth you tell the tor 
>>> network about So you can set BandwidthRate to the real max you 
>>> want to provide and then set MaxAdvertisedBandwidth to a
>>> number low enough to prevent circuit overload.
>>> 
>>> _______________________________________________ tor-relays 
>>> mailing list tor-relays at lists.torproject.org 
>>> <mailto:tor-relays at lists.torproject.org> 
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>>
>>>
>>>
>>>
>>> 
- -- *Dr Chris Whittleston 栗主* Department of Chemistry University
>>> of Cambridge Lensfield Road, Cambridge, CB2 1EW Email: 
>>> csw34 at cam.ac.uk <mailto:csw34 at cam.ac.uk> Tel: +44 (0)1223
>>> 336423
>>> 
>>> 
>>> _______________________________________________ tor-relays 
>>> mailing list tor-relays at lists.torproject.org 
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>>> 
>> -- http://disman.tl OpenPGP key: http://disman.tl/pgp.asc 
>> Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 
>> _______________________________________________ tor-relays
>> mailing list tor-relays at lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> 
> 
> 
> _______________________________________________ tor-relays mailing
> list tor-relays at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

- -- 
http://disman.tl
OpenPGP key: http://disman.tl/pgp.asc
Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSZBHuAAoJEPZwdO29hkOplfQQAKvZpovSoEx963br39ZwSQyw
wkR2Z68ojDulmuq8Keorui5Xm+HOka4lAenJPfxUr7ZlYftLT0C1/VsidIx39vic
JcH+YSN31JftryW+bU2YGPp5err+9jrg6mw0CmuryV4OKRZt5VsXKJXxS6AO9uX8
Myg6MQvDqmn4KWy80coppayp+sOjt3QScNN+PNXvSy8JkqOmzvQ/uDy/zq2xLwWp
fb61wlciHDhzAsOkgZUNeei5QLqdrqah14Me9XCm5F7XKNaLSoBUpvYOsHHcFPzT
1L8qUGi/zNao/hbZs/dwRWsIPwf7VkXN+vl1xuBJivsh2NdK1pse84AuoFVARJ9E
rX9EFEPQQ8bm8bXhjEV1yVuvJ6aqweckWUaYF4IAICdRUoroZuSBEWfPATtliSzB
7e6fC5pkKipnIUzlajIF3IYK2dMdUCF8lDkx6CyhFhjjXIGfLOYc6RM1BEejAE/t
EZVGDBDGVxQp2YGu6YeF02FKM9bRnuxSGvwDCQnXkNq8B9dw+Og0n/ES1jrdCe3z
aKP+VDOqNOgF+fambcKVNsdRGyTP7lzLZ3DpNMUulCmzeqmAlvjNyw47LfGXXMzw
Xwtrh8r6rGKp+zuyMvy0hTCfnW7dOoV7SOS1X3o+9E7+g+ZAy+hVRnZPlEWRdP/w
MruFG5BcbKjEiwkSvX0D
=yRmz
-----END PGP SIGNATURE-----