[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Snakes On A Tor Scanner - 0.0.3
Over the past month or so I've been testing and improving my Tor
network scanner, and it seems to be shaping up pretty nicely.
As a quick refresher, the scanner consists of two parts:
A Tor Controller that allows you to customize properties of your
Tor routes. You can control path length, exit country, "fast node"
cutoff, and lots of other neat things.
Snakes On A Tor:
A Scanner that uses the Metatroller to scan the network for nodes
that are unstable and/or modifying exit traffic. Docs are now
obtained randomly from google queries.
Metatroller will work in ActivePerl on Windows without any other
dependencies, however SOAT will require curl, md5sum, and openssl.
I think SOAT and Metatroller are in good enough shape that they
should make for good QA tools for Tor to help reduce circuit failure,
and also useful tools for people who would like to monitor the Tor
I'm also suspicious of the 7/8 node cutoff for "fast" nodes. I think
that perhaps it should be raised to 65% or so, but I have no hard data
as of yet to illustrate this cutoff point. Since adoption is critical
to anonymity, and regular people won't use Tor if they think it is
slow, I believe it is far more imporant that we have known reliable,
fast nodes than lots of slow ones that are prone to dropping circuits.
Hopefully we can discover these cutoffs using this tool.
Here's the CHANGELOG for 0.0.3:
- Now gets its node list directly from Tor using the control port
- Implemented guard nodes
- Added circuit/stream failure statistics
- Improved reliability/recovery from circuit and stream failures
- All commands can now take no arguments to print current value
- obtains its doc list via google filetype queries
- verifies this list contains no dynamic content
- Saves long-term aggregate failure stats from metatroller
I've given Roger and Nick some patches to expose circuit failure
reason codes to the controller. I think part of these made it into
0.1.2.2-alpha, and hopefully the rest will be in 0.1.2.3. Metatroller
does not need these reason codes to record failures, but it is more
accurate if they are present.
Here's the current list of Metatroller commands:
214 COUNTRY <CC|ALL>
214 - Pick a two letter country code to select exits from, or ALL
214 - List countries that have tor exits
214 PERCENTFAST <#>
214 - What % of the network is considered 'fast' for node selection
214 BWCUTOFF <#>
214 - Minimum observed bandwidth (KB) that a node must have to be selected
214 UNIFORM <1|0>
214 - Should selection among fast nodes be uniform (or bandwidth-biased)?
214 ORDEREXITS <1|0>
214 - Should exits be chosen one after another instead of randomly?
214 FASTEXITS <1|0>
214 - Should exits be chosen from 'fast' nodes or all nodes?
214 GUARDNODES <1|0>
214 - Use guard nodes?
214 PATHLEN <#>
214 - What should the path length of circuits be?
214 - Throw away all circuits and choose a new exit
214 SETEXIT <NAME>
214 - Hardcode an exit for all future circuits
214 - Lists the last used exit
214 - Print out the failure rates of nodes
While it is still not advisable for you to use SOAT on a machine you
wish to preserve your anonymity with, Metatroller is perhaps not as
dangerous as I thought.
I've looked into the Tor source, and it turns out that in some cases
Tor does make circuits out of low-uptime nodes. With that, and the
addition of Guard Nodes to Metatroller, it is perhaps not nearly as
dangerous as I had originally thought. The main dangers revolve around
PATHLEN and PERCENTFAST, and are explained in the README.
I believe normal usage should be comparable to Tor in safety at this
point, though there are a couple of attractive fixes in 0.1.2.x I
would like to adopt.
Plans for the future include more finer-grained failure statistics,
node max/min/avg bandwidth stats, and possible integration with the
directory servers to help avoid unstable/malicious nodes (or at the
very least, an internally saved blacklist for high failure-rate
Also, the metatroller currently does not subscribe to router info or
(non-existent) network status events, so it should be restarted
periodically. When network-status events are available in 0.1.2.x I'll
Mad Computer Scientist
fscked.org evil labs