Re: [tor-relays] minimum useful ram

[Joshua Datko]

I would recommend the BeagleBone Black.  It's only $10 more than the Pi and
it runs actual Debian and the tor development debs work out of the box.
 It's also has a 1GHz processor and 512MB RAM.  My uptime is 45 days right
now.

My bandwidth settings (below) allows for an always-on relay that doesn't
detract from my home network.  Gordon is doing some great work getting the
Pi setup, but the BBB has basically worked out of the box for me.  (I'm
limited to 5Mbps upload).

Josh

MaxAdvertisedBandwidth 200 KB
RelayBandwidthRate 520 KB
RelayBandwidthBurst 640 KB




On Wed, Oct 23, 2013 at 10:20 PM, I  wrote:

> Gordon,
>
> Thanks.
> >> To see if it was possible just now I set up an obfsproxy bridge as
> >> best I could but it failed to download properly.
>
> I reinstalled Ubuntu 11.10 64 and free -m brought this..
>  total   used   free sharedbuffers cached
> Mem:   256 38217  0  0 26
> -/+ buffers/cache: 12243
> Swap:0  0  0
>
> Again following the instructions
> https://www.torproject.org/docs/debian.html.en#development
> apt-get install tor deb.torproject.org-keyring
> brought this...
>
> Get:1 http://archive.ubuntu.com/ubuntu/ oneiric/main libevent-2.0-5 amd64
> 2.0.12-stable-1 [132 kB]
> Err http://deb.torproject.org/torproject.org/ experimental-oneiric/main
> tor amd64 0.2.4.17-rc-1~oneiric+1
>   404  Not Found [IP: 82.195.75.101 80]
> Get:2 http://deb.torproject.org/torproject.org/ oneiric/main
> deb.torproject.org-keyring all 2012.08.29 [4138 B]
> Err http://deb.torproject.org/torproject.org/ experimental-oneiric/main
> tor-geoipdb all 0.2.4.17-rc-1~oneiric+1
>   404  Not Found [IP: 82.195.75.101 80]
> Get:3 http://archive.ubuntu.com/ubuntu/ oneiric/universe torsocks amd64
> 1.1-4 [69.7 kB]
> Fetched 206 kB in 0s (290 kB/s)
> Failed to fetch
> http://deb.torproject.org/torproject.org/pool/main/t/tor/tor_0.2.4.17-rc-1~oneiric+1_amd64.deb
>  404  Not Found [IP: 82.195.75.101 80]
> Failed to fetch
> http://deb.torproject.org/torproject.org/pool/main/t/tor/tor-geoipdb_0.2.4.17-rc-1~oneiric+1_all.deb
>  404  Not Found [IP: 82.195.75.101 80]
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
>
> I am a Linux newboy so any help is welcome, Gordon.
>
> Of the Tor Cloud project using Amazon's free year I have only had a $3
> charge for one of three in six months. The versions of Obfsproxy are set
> not to break Amazon's free limit, as I understood Tor to say.
> If there are $12USD a year servers available can't a package be set-up to
> utilise them.
> I'm burrowing through the Linux lingo as well as I can but it's a real
> test of mettle!
>
> Have you looked at the Cubie 2 board?
> To seek finance to distribute a devoted board with the best balance of
> components and cost would lead to more Tor network I reckon.
>
>
> Robert
>
> 
> FREE ONLINE PHOTOSHARING - Share your photos online with your friends and
> family!
> Visit http://www.inbox.com/photosharing to find out more!
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> 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

Re: [tor-relays] minimum useful ram

[I]

Gordon, 

Thanks. 
>> To see if it was possible just now I set up an obfsproxy bridge as
>> best I could but it failed to download properly.

I reinstalled Ubuntu 11.10 64 and free -m brought this..
 total   used   free sharedbuffers cached
Mem:   256 38217  0  0 26
-/+ buffers/cache: 12243
Swap:0  0  0

Again following the instructions 
https://www.torproject.org/docs/debian.html.en#development
apt-get install tor deb.torproject.org-keyring 
brought this...

Get:1 http://archive.ubuntu.com/ubuntu/ oneiric/main libevent-2.0-5 amd64 
2.0.12-stable-1 [132 kB]
Err http://deb.torproject.org/torproject.org/ experimental-oneiric/main tor 
amd64 0.2.4.17-rc-1~oneiric+1
  404  Not Found [IP: 82.195.75.101 80]
Get:2 http://deb.torproject.org/torproject.org/ oneiric/main 
deb.torproject.org-keyring all 2012.08.29 [4138 B]
Err http://deb.torproject.org/torproject.org/ experimental-oneiric/main 
tor-geoipdb all 0.2.4.17-rc-1~oneiric+1
  404  Not Found [IP: 82.195.75.101 80]
Get:3 http://archive.ubuntu.com/ubuntu/ oneiric/universe torsocks amd64 1.1-4 
[69.7 kB]
Fetched 206 kB in 0s (290 kB/s)
Failed to fetch 
http://deb.torproject.org/torproject.org/pool/main/t/tor/tor_0.2.4.17-rc-1~oneiric+1_amd64.deb
  404  Not Found [IP: 82.195.75.101 80]
Failed to fetch 
http://deb.torproject.org/torproject.org/pool/main/t/tor/tor-geoipdb_0.2.4.17-rc-1~oneiric+1_all.deb
  404  Not Found [IP: 82.195.75.101 80]
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?

I am a Linux newboy so any help is welcome, Gordon.

Of the Tor Cloud project using Amazon's free year I have only had a $3 charge 
for one of three in six months. The versions of Obfsproxy are set not to break 
Amazon's free limit, as I understood Tor to say.
If there are $12USD a year servers available can't a package be set-up to 
utilise them. 
I'm burrowing through the Linux lingo as well as I can but it's a real test of 
mettle!

Have you looked at the Cubie 2 board? 
To seek finance to distribute a devoted board with the best balance of 
components and cost would lead to more Tor network I reckon.


Robert


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traceroute measurement from Tor relays

[grarpamp]

On Wed, Oct 23, 2013 at 1:26 PM, Aaron Hopkins  wrote:
> On Wed, 23 Oct 2013, Karsten Loesing wrote:
>
>> Basically the experiment does traceroutes to three groups: all
>> "routable IP prefixes", all Tor relays, and then all /24 subnets.
>
>
> Based on my read of your input data, these will run traceroutes to 491762,
> 9058, and 13597431 IPs respectively, sending at least 100 million packets?
> This is a bigger ask than I think you made clear.
>
> I question the utility of scanning all /24s.  By definition, all /24s in a
> BGP prefix take the same path to its origin AS; the only variation will be
> within that.  If you are looking for chokepoints, you've already found it
> with the origin AS.

Initially I didn't see the sense in this either, perhaps it's in the
referenced docs.
If the internal paths of a large aggregated AS were of interest it could be used
for that. Though you might use the BGP table to reduce the /24 query set to
just those matching the AS you reside in. Then again, there can be higher
precedence side peerings that would not be found with that.

Also, I'd merge in current BGP AS and GeoIP data for each hop of the trace.
That could probably be done upon receipt of a submission if they happen daily.
However on the client may be better since in order to test new routes over time
they'll need to update BGP tables anyway.

And for the Tor node... capture the IP,  IP whois, DNS ptr, DNS ptr whois,
BGP AS and prefix, and GeoIP.

I can see this being useful for siting nodes in the future.

> They are uncommon from a Tor exit node, which already receives enough

It's opt-in so I see no issue here.

> Which by default will try to keep 128 traceroute processes running all the
> time.  This is potentially problematic for relays with limited RAM or CPU
> available.  I'd recommend making this more clear.

...and more tuneable via config file.

If looking for more network input and similar work, make a post to
NANOG etc. There have been lots of traceroute projects.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traceroute measurement from Tor relays

[Aaron Hopkins]

On Wed, 23 Oct 2013, Karsten Loesing wrote:


As you may be aware, the anonymity of a connection over Tor is vulnerable
to an adversary who can observe it in enough places along its route.


Are you trying to work backward to physical-layer chokepoints, like how the
inter-contentinal network topology maps to the landing sites on
?


Basically the experiment does traceroutes to three groups: all
"routable IP prefixes", all Tor relays, and then all /24 subnets.


Based on my read of your input data, these will run traceroutes to 491762,
9058, and 13597431 IPs respectively, sending at least 100 million packets?
This is a bigger ask than I think you made clear.

I question the utility of scanning all /24s.  By definition, all /24s in a
BGP prefix take the same path to its origin AS; the only variation will be
within that.  If you are looking for chokepoints, you've already found it
with the origin AS.

This also does all scans sequentially, which will have a couple of negative
side-effects.  You are much more likely to trigger ICMP response
rate-limiting on intermediate routers and more likely to trigger IDS alarms
than if you'd randomized your target selection.  Running your target list
through one of the following would mitigate this:

awk 'BEGIN{srand()}{print rand()"\t"$0}' | sort -k1 -n | cut -f2-

perl -MList::Util -e 'print List::Util::shuffle <>'

sort -R


These kinds of measurements are not uncommon, and they will not be
done at a high rate.


They are uncommon from a Tor exit node, which already receives enough
complaints where it is really helpful to be able to truthfully claim to my
ISP and others that none of the traffic was generated by me, there's not
much I can do to stop it, and I have no logs about anything.


If you are not able to run scamper, the script will also work with the
more-common but less-accurate and slower "traceroute" utility.


Which by default will try to keep 128 traceroute processes running all the
time.  This is potentially problematic for relays with limited RAM or CPU
available.  I'd recommend making this more clear.

I may run this from a machine on the same network as my Tor node, but
definitely not on the Tor node itself.

-- Aaron
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traceroute measurement from Tor relays

[David Carlson]

On 10/23/2013 10:09 AM, Karsten Loesing wrote:
> Hello Tor relay operators,
>
> We could use your help in a pilot project to improve Tor security. As
> you may be aware, the anonymity of a connection over Tor is vulnerable
> to an adversary who can observe it in enough places along its route.
> For example, traffic that crosses the same country as it enters and
> leaves the Tor network can potentially be deanonymized by an authority
> in that country who can monitor all network communication. Researchers
> have been working to figure out how Tor traffic gets routed over the
> Internet [0-3], but determining routes with high confidence has been
> difficult.
>
> That's where you come in. To figure out where traffic travels from
> your relay, we'd like you to run a bunch of "traceroutes" - network
> measurements that show the paths traffic takes. This is a one-time
> experiment for now, but, depending on what we find out, regularly
> making such measurements may become a part of Tor itself. We have
> already gotten some results thanks to Linus Nordberg of DFRI and
> Moritz Bartl of
> torservers.net, and now it's time to ask all relay operators to help.
> We would like to start this right away.
>
> We have written some shell scripts to automate most of the process.
> The easiest way for you to get them is with git, using the following
> commands:
>
>   git clone https://bitbucket.org/anupam_das/traceroute-from-tor-relays
>   git checkout f253f768d14e3368e4fe4de9895acd2715a19412
>
> You can also just download the files directly by visiting [4].
> Detailed instructions for setting up and running the experiment are in
> the README.
>
> Basically the experiment does traceroutes to three groups: all
> "routable IP prefixes", all Tor relays, and then all /24 subnets.
> These kinds of measurements are not uncommon, and they will not be
> done at a high rate. By default the scripts will periodically move the
> results to our server [5] via SSH, although you can keep the results
> around and/or not send them automatically if you wish (see the
> README). The traceroute data recorded is not sensitive or private at
> all. We plan to make the code and data public, following Tor's
> practice of open cooperation with the research community [6].
>
> The measurements will work best if you have the "scamper" tool from
> the Cooperative Association for Internet Data Analysis (CAIDA)
> installed (see the README for installation instructions). This is a
> standard and open-source tool that handles the many modern
> complexities of Internet routing measurement. If you are not able to
> run scamper, the script will also work with the more-common but
> less-accurate and slower "traceroute" utility. We do not currently
> have support for Windows relays. The output will take up around 500KB
> (110MB if you disable automatic removal after upload) disk space if
> you use scamper; on the other hand if you use "traceroute" utility
> each output will be around 4MB (1GB with automatic removal after
> upload disabled). * *Depending on whether you run scamper or
> traceroute the total time required varies but results for traceroutes
> to "routable IP prefixes" and all Tor relays should finish within one
> week (possibly earlier). We would like to request relay operators to
> upload those results once finished.* *
>
> This experiment is in collaboration with several researchers, but the
> leads are Anupam Das, a Ph.D. student at the University of Illinois at
> Urbana-Champaign, and his advisor Nikita Borisov. Based on a review of
> the scripts of commit f253f768d14e3368e4fe4de9895acd2715a19412, we
> believe that they operate as described above. Please do read through
> them yourself, and let us know if you have any questions or concerns.
> And also feel free to contact any of us for help or with suggestions.
>
> Because of you, Tor is the "king" of anonymous communication.  With
> your help, we will keep improving to face the new challenges to
> privacy and freedom online.
>
> Thank you,
> Karsten Loesing 
> Anupam Das 
> Nikita Borisov 
>
> [0] "Protecting anonymity in the presence of autonomous system and
> internet exchange level adversaries" by Joshua Juen. Master's Thesis,
> UIUC. 2012. 
> [1] "Users Get Routed: Traffic Correlation on Tor by Realistic
> Adversaries" by Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr,
> and Paul Syverson. ACM CCS 2013.
> 
> [2] "AS-awareness in Tor path selection" by Matthew Edman and Paul F.
> Syverson. ACM CCS 2009.
> 
> [3] "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries"
> by Steven J. Murdoch and Piotr Zieliński. PETS 2007.
> 
> [4] https://bitbucket.org/anupam_das/traceroute-from-tor-relays/downloads
> [5] ttat-control.iti.illinois.edu
> [6] https://metri

[tor-relays] Traceroute measurement from Tor relays

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Tor relay operators,

We could use your help in a pilot project to improve Tor security. As
you may be aware, the anonymity of a connection over Tor is vulnerable
to an adversary who can observe it in enough places along its route.
For example, traffic that crosses the same country as it enters and
leaves the Tor network can potentially be deanonymized by an authority
in that country who can monitor all network communication. Researchers
have been working to figure out how Tor traffic gets routed over the
Internet [0-3], but determining routes with high confidence has been
difficult.

That's where you come in. To figure out where traffic travels from
your relay, we'd like you to run a bunch of "traceroutes" - network
measurements that show the paths traffic takes. This is a one-time
experiment for now, but, depending on what we find out, regularly
making such measurements may become a part of Tor itself. We have
already gotten some results thanks to Linus Nordberg of DFRI and
Moritz Bartl of
torservers.net, and now it's time to ask all relay operators to help.
We would like to start this right away.

We have written some shell scripts to automate most of the process.
The easiest way for you to get them is with git, using the following
commands:

  git clone https://bitbucket.org/anupam_das/traceroute-from-tor-relays
  git checkout f253f768d14e3368e4fe4de9895acd2715a19412

You can also just download the files directly by visiting [4].
Detailed instructions for setting up and running the experiment are in
the README.

Basically the experiment does traceroutes to three groups: all
"routable IP prefixes", all Tor relays, and then all /24 subnets.
These kinds of measurements are not uncommon, and they will not be
done at a high rate. By default the scripts will periodically move the
results to our server [5] via SSH, although you can keep the results
around and/or not send them automatically if you wish (see the
README). The traceroute data recorded is not sensitive or private at
all. We plan to make the code and data public, following Tor's
practice of open cooperation with the research community [6].

The measurements will work best if you have the "scamper" tool from
the Cooperative Association for Internet Data Analysis (CAIDA)
installed (see the README for installation instructions). This is a
standard and open-source tool that handles the many modern
complexities of Internet routing measurement. If you are not able to
run scamper, the script will also work with the more-common but
less-accurate and slower "traceroute" utility. We do not currently
have support for Windows relays. The output will take up around 500KB
(110MB if you disable automatic removal after upload) disk space if
you use scamper; on the other hand if you use "traceroute" utility
each output will be around 4MB (1GB with automatic removal after
upload disabled). * *Depending on whether you run scamper or
traceroute the total time required varies but results for traceroutes
to "routable IP prefixes" and all Tor relays should finish within one
week (possibly earlier). We would like to request relay operators to
upload those results once finished.* *

This experiment is in collaboration with several researchers, but the
leads are Anupam Das, a Ph.D. student at the University of Illinois at
Urbana-Champaign, and his advisor Nikita Borisov. Based on a review of
the scripts of commit f253f768d14e3368e4fe4de9895acd2715a19412, we
believe that they operate as described above. Please do read through
them yourself, and let us know if you have any questions or concerns.
And also feel free to contact any of us for help or with suggestions.

Because of you, Tor is the "king" of anonymous communication.  With
your help, we will keep improving to face the new challenges to
privacy and freedom online.

Thank you,
Karsten Loesing 
Anupam Das 
Nikita Borisov 

[0] "Protecting anonymity in the presence of autonomous system and
internet exchange level adversaries" by Joshua Juen. Master's Thesis,
UIUC. 2012. 
[1] "Users Get Routed: Traffic Correlation on Tor by Realistic
Adversaries" by Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr,
and Paul Syverson. ACM CCS 2013.

[2] "AS-awareness in Tor path selection" by Matthew Edman and Paul F.
Syverson. ACM CCS 2009.

[3] "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries"
by Steven J. Murdoch and Piotr Zieliński. PETS 2007.

[4] https://bitbucket.org/anupam_das/traceroute-from-tor-relays/downloads
[5] ttat-control.iti.illinois.edu
[6] https://metrics.torproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.eni