[tor-relays] Nagios/Icinga plugin check_tor_bandwidth for gathering bandwidth data

Josef 'veloc1ty' Stautner hello at veloc1ty.de
Thu Nov 26 07:07:39 UTC 2015


Hi Tim,

you hit me hard today because I didn't think about the privacy of the
users :-)
But the data points for read and write are just average values and the
time series database also only stores the average values. So I don't
think that just by looking at the graph you can track specific Hidden
Services or make other attempts. They would get better precision if they
trace the IP of the server.

~Josef

Am 25.11.2015 um 23:33 schrieb Tim Wilson-Brown - teor:
>
>> On 26 Nov 2015, at 05:36, Josef Stautner <hello at veloc1ty.de
>> <mailto:hello at veloc1ty.de>> wrote:
>>
>> Hello @all,
>>
>> (I'm not sure if you guys are interested in a topic like this)
>> I wrote a perl script to gather bandwidth data from my Tor exit relay.
>> The script connects to the Tor control socket, fetches the running
>> config to extract the bandwidth limits and the reject rule count.
>> Afterwards the last 60 bw-cache entries are fetched and average values
>> are built for bandwidth in and out.
>> All this performance data is then forwarded to Nagios/Icinga where you
>> can do anything with that values.
>>
>> Every 30 minutes a cronjob renders the graph showing the datapoints of
>> the last 6 houres and uploads the resulting image to my website. You can
>> find the image here (Hint: The values for in and out are stacked):
>> https://blog.veloc1ty.de/bandwidth-large.png
>>
>> The source of the script can be found here on GitHub:
>> https://github.com/vlcty/check_tor_bandwidth
>> It's released under the GPLv3
>>
>> Maybe somebody will find it usefull :-)
>
> Hi Josef,
>
> Thanks for creating this tool - it looks like a great way for
> operators to keep an eye on their relay.
>
> But I wonder about the privacy implications of making a relay's
> high-resolution bandwidth figures public.
> For example, attacker can correlate a traffic-based attack on a hidden
> service, with a traffic peak on its Guards.
> (I am not sure if any similar attack applies to Exits, or any other
> role Exits may have.)
> We previously moved to a bandwidth statistics interval of 6 hours for
> this reason.
> (That's why the 3 days and 1 month bandwidth graphs are empty on Globe.)
>
> You lose a certain amount of precision moving to a graph, rather than
> reporting exact figures in a data file.
> But I'm not sure if that's enough to avoid the attack I described above.
>
> Tim
>
> Tim Wilson-Brown (teor)
>
> teor2345 at gmail dot com
> PGP 968F094B
>
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20151126/ad781507/attachment-0001.html>


More information about the tor-relays mailing list