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 :-)
~Josef
On 26 Nov 2015, at 05:36, Josef Stautner hello@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
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@veloc1ty.de mailto:hello@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 26 Nov 2015, at 18:07, Josef 'veloc1ty' Stautner hello@veloc1ty.de wrote:
Hi Tim,
you hit me hard today because I didn't think about the privacy of the users :-)
Sorry about that :-(
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.
I think you're right, but it depends on your threat model: * an adversary with access to a router/IXP near your server could get precise bandwidth figures (bytes/second) that way; * an adversary anywhere in the world could see averaged bandwidth figures (kilobytes?/minute) using your graph.
I could imagine your users facing either type of adversary.
But there might be ways to work around that: * a public graph could average bandwidth over the time period used on Globe (6 hours), or * a private graph could provide as much detail as you like, and be made available over password-protected HTTPS, or as a hidden service with client authentication.
Tim
Am 25.11.2015 um 23:33 schrieb Tim Wilson-Brown - teor:
On 26 Nov 2015, at 05:36, Josef Stautner < mailto:hello@veloc1ty.dehello@veloc1ty.de mailto:hello@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 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 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@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hi,
Nice work, but in this time i use vnstat to get global traffic info from my servers. Doing great job, but i will check your solution as well. Sharing is carring. Have a nice day.
On 26 November 2015 at 09:02, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 26 Nov 2015, at 18:07, Josef 'veloc1ty' Stautner hello@veloc1ty.de wrote:
Hi Tim,
you hit me hard today because I didn't think about the privacy of the users :-)
Sorry about that :-(
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.
I think you're right, but it depends on your threat model:
- an adversary with access to a router/IXP near your server could get
precise bandwidth figures (bytes/second) that way;
- an adversary anywhere in the world could see averaged bandwidth figures
(kilobytes?/minute) using your graph.
I could imagine your users facing either type of adversary.
But there might be ways to work around that:
- a public graph could average bandwidth over the time period used on
Globe (6 hours), or
- a private graph could provide as much detail as you like, and be made
available over password-protected HTTPS, or as a hidden service with client authentication.
Tim
Am 25.11.2015 um 23:33 schrieb Tim Wilson-Brown - teor:
On 26 Nov 2015, at 05:36, Josef Stautner < hello@veloc1ty.de hello@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 listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Josef 'veloc1ty' Stautner -
Josef Stautner
-
Tim Wilson-Brown - teor -
ZEROF