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

[Gordon Morehouse]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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
> 

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJSZAsYAAoJED/jpRoe7/ujsNsH/3CtN72LfrRXe8qFmj7QmVkO
8bQRZh0d2Wtp6cV9YhEzIvQxK74snzQiK4pVG2y2fmXOTH9ctf+sL0eHlBGnJxcL
RP2J0abgK2M2RUGSNFBp93y73aMwm8hKWTmdCx51pNAul9SXppXf0udZiy2NrIlP
aUIdzEHYQNXj3ykyH+uyv+/e2MZMY5sTqfGO1/O1yM5AKSH6zAhzuBh/nc46lvGr
Eo8vRp/ZEtgyJ79E6dzQjj0hWJcuXsfctUbBUUu0kcrPtNp6dqsQMA05bImrUlYr
KZaZqkwQATAzySuzzpUli4xN3Cs1m2xLkgfDP0yVWRPQJZCMW/NQfifpuXv6xPk=
=m0H3
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x1EEFFBA3.asc
Type: application/pgp-keys
Size: 1749 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20131020/b42e932e/attachment-0001.key>