|
||
|
2 October 2011 Tor Reject Exit Policy to Syria, Iran, Belarus, Saudi Arabia, Moldavia, Qatar, etc?
Date: Sun, 02 Oct 2011 21:23:15 +0200 i made some dirty stats by looking at all "reject" lines in Exit Policies from cached-descriptors. Then i sorted them, uniq'ed them and made a geoip look on top of them. Attached you can find the file on which stats are done (cached-descriptors extraction from 2 October 2011 20.30 GMT+1). The scripts (ugly and dirty) and files of brief analysis are: SCRIPT-1: http://privacyresearch.infosecurity.ch/blocktest/extract-blacklisted-ip.sh RESULT-1: http://privacyresearch.infosecurity.ch/blocktest/blacklisted.txt SCRIPT-2: http://privacyresearch.infosecurity.ch/blocktest/blacklist-stat.sh RESULT-2: http://privacyresearch.infosecurity.ch/blocktest/blocklist-stat.txt It's interesting to notice that the amount of IP blocked in Tor Exit Policies for countries that apply censorship are:
SY 147 It would be interesting to further analyze: - Which Tor Exit Node reject IP to Syria, Iran, Belarus, Saudi Arabia, Moldavia and Qatar? - Which is the reason to block IP addresses destinated to that country? - What's running on that systems to get blocked? It would probably require some further investigation, but weekend is finishing and i have no more time to look at it. If someone would like to check it, eventually using some python magic with a parsers of cached-descriptors fine, it would be interesting to see the results and/or resulting tool to make the analysis. -naif _______________________________________________
tor-talk mailing
list
Date: Sun, 2 Oct 2011 16:29:47 -0400 On Sun, Oct 02, 2011 at 09:23:15PM +0200, Fabio Pietrosanti (naif) wrote:
> i made some dirty stats by looking at all "reject" lines in
Exit Here are some suggestions to get better accuracy: A) You're overcounting relays by looking at every descriptor in your cached-descriptors file. One simple fix, assuming your Tor is just a client, is to look at the fingerprint line in the router descriptor, and discard all but the newest descriptor for a given fingerprint. B) Most relays reject their own IP address in their exit policy (since it's common that there's some service that trusts connections from that IP address, e.g. a linksys router that lets you log in). So you should read the IP address out of the router line, and ignore reject lines for that IP address. I expect once you correct for A and B your numbers will look very different. All it takes is one guy in SA running a relay and having his IP get changed 15 times and you suddenly have 15 reject lines to SA in your list. The next step is that you'll want to think about bandwidth and uptime of relays -- SA has a heck of a lot of Tor users, and every once in a while one of them clicks the "make me a relay" button, but it doesn't stay up very long or push much bandwidth. I guess how much you should read out of tiny transient relays depends on what you're trying to learn by these stats. > It's interesting to notice that the amount of IP blocked in Tor Exit Another thing you should know is that some of these addresses you've got aren't IP address, but rather netblocks. So reject 7.0.0.0/8:* is quite different from reject 7.0.0.0:*
> If someone would like to check it, eventually using some python
magic You might like https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/exitlist --Roger _______________________________________________
tor-talk mailing
list
|