Showing posts with label Tor. Show all posts
Showing posts with label Tor. Show all posts

Thursday, August 31, 2006

Listing active Tor servers...

Want to know the list of active Tor servers at any given time? It turns out that this is fairly easy to do.

When a Tor client starts up, and from time-to-time during normal operation, it needs to refresh it's list of active servers. The Tor network maintains several "directory servers" which keep track of which nodes are willing to perform onion routing functions. Because the Tor client may not have yet started (it can't join the Tor network before it knows which Tor servers to use), anyone can fetch the directory from the public Internet using HTTP.

The basic idea is pretty simple. Just visit one of the directory servers with a URL like the following:


http://belegost.mit.edu/tor/

The belegost.mit.edu system is one of the five or so authoritative Tor directories on the Internet, so it should be fairly stable. The file it returns contains all the information that a Tor client needs to know about each of the servers, including IP addresses and port numbers. The Tor directory protocol document can help you interpret the details fairly easily.

Of course, if you just want to know the list of active servers for monitoring or blocking purposes, you can just run the following perl script, which will dump out the server names, IP addresses and onion routing ports for you.

#!/usr/bin/perl
#
# Fetch the list of known Tor servers (from an existing Tor server) and
# display some of the basic info for each router.

use LWP::Simple;

# Hostname of an existing Tor router. We use one of the directory authorities
# since that's pretty much what they're for.
$INITIAL_TOR_SERVER = "18.244.0.114"; # moria2 / belegost.mit.edu
$INITIAL_TOR_PORT = 80;

# Fetch the list of servers
$content = get("http://$INITIAL_TOR_SERVER:$INITIAL_TOR_PORT/tor/");
@lines = split /\n/,$content;

foreach $router (@lines) {
if($router =~ m/^router\s+(\S+)\s+(\S+)\s+(\S+)\s+(\S+)\s+(\S+)\s*$/m) {
($name, $address, $or_port, $socks_port, $directory_port) =
($1, $2, $3, $4, $5, $6);
print "$name $address $or_port\n";
}
}


Update 2008-06-09 11:38: In the nearly two years since I wrote this original post, the Tor folks have updated their directory protocol, and this script no longer works. Please see my newer post for an update and some working code.

Tuesday, January 17, 2006

ShmooCon 2006 Wrap Up

Having recently returned from ShmooCon 2006 (and having further spent most of yesterday resting and recovering), here's my brief writeup: "Go next year."

Ok, here's my slightly less brief writeup. I arrived around 1:00PM Friday. Giant kudos to the registration team, who checked me in without delay. In fact, they checked in nearly everyone without delay, thanks to the nifty bar codes they emailed to the registered attendees. Print it out, scan it and get a conference bag. It was great. What was even better about it was that the badges had no name tag. They were just (sharp) metal access tokens, and if you had on around your neck, you were in. Good for anonymity, though a little annoying at times when I think I should know someone's name, but don't.

I don't want to give a blow-by-blow account, because

  1. that's boring
  2. others have done it better
  3. it's still boring
I would like to mention several of my favorite presentations, though, in roughly chronological order.

First, Dan Moniz and Patrick Stach presented their work on creating an exhaustive rainbow table for LANMAN ("Breaking LanMan Forever"), which was a little math-y but in the end they've made the results available. The good thing about this is that by going for a guaranteed complete coverage instead of a statistical coverage, they reduced the number of tables you have to search through to find password hashes, and avoiding the overlap speeds things up a lot. Good job guys.

Second, Acidus' talk on "Covert Crawling" (a spider that is indistinguishable from a set of human visitors) was pretty fun. Nothing terribly high-tech, but he's thought through a lot of the problems and solved most of them. Should be good code when it's released.

Dan Kaminsky's talk on "Black Ops of TCP/IP 2005.5" was, of course, stellar. IP fragmentation timing attacks. Genius.

I also enjoyed Lasse Overlier and Paul Syverson's talk on detecting hidden services in Tor, and the upcoming countermeasures to these attacks. Makes me want to go right out and hide something!

Deviant Ollam's lockpicking talk scared the hell out of me, and I've pretty much sworn off all locks by now. Only trained attack dogs for me from now on.

And of course, the highlight of the con was Johnny Long's "Hacking Hollywood" presentation. The image of hackers and hacking in the movies has always fascinated me, and it was nice to see such an informed send-up. Hillarious and timely. I can't wait for the video to be released!

So, this was my first ShmooCon, but it won't be my last!

PS. Richard Bejtlich and I did a talk on sguil. It went well, I thought. In case you were wondering.

Monday, July 11, 2005

Tor is a double-edged sword

Yes, this article's conclusions are a little obvious. An anonymizing network protects the privacy of normal users and evildoers alike. That was just about my second thought on hearing about Tor (the first was, "Cool!").

I like this article, though, because it has a step-by-step guide to running some simple Nessus scans through Tor. I haven't been using Tor in my penetration tests, partly because being anonymous isn't much of an issue, but mostly because I don't know that I trust it to work well for all the various Nessus tests. I might give this guy's method a try, though, and see how it goes.

Tuesday, January 25, 2005

Detecting TOR on your network

I've written about the TOR anonymizing TCP proxy before, and in general I think it's quite a useful tool. There are a lot of situations where you might legitimately want to obfuscate your true online identity and/or prevent your ISP from keeping track of what you access over the Internet. TOR is really good for these sorts of things, and is a cool project, to boot.

There are some situations, though, in which using TOR (or any other similar service) is not appropriate. One such situation is when your Acceptable Use Policy forbids it, as is probably the case for many people using their employer's LAN. If you're a network administrator and you need to monitor TOR usage, you can try the following Snort rule I cooked up:

alert tcp any any -> $HOME_NET any (msg: "TOR 1.0 Proxy Connection Attempt"; content: "TOR"; content: "<identity>"; within:30; classtype:policy-violation; resp:rst_all; sid:5000030; rev:1;)

This should alert you any time the TOR proxy attempts to create a connection to the rest of the TOR network. As written, this rule also makes use of Snort's "flexible response" feature to try to shut down the connections as they are established. This isn't entirely effective, but it seems to work about 80% of the time for me, which at least makes TOR really annoying to use. If you prefer not to take action, delete the part that says "resp:rst_all;".

Tuesday, December 21, 2004

EFF-sponsored anonymizer

According to this press release, The EFF is sponsoring the TOR project.

If you're not familiar with TOR, it uses a concept called "Onion Routing" to forward TCP traffic from your computer, though a complex series of semi-anonymous hops, and finally to the packet's ultimate destination. The idea is that you can run the TOR client on your computer, which exports a SOCKS proxy interface. Then any SOCKS-compatible application can use the proxy to route it's traffic through the onion network.

Check it out, it's super cool, and free (as in speech AND beer), so you have nothing to lose.

I love the EFF!

Friday, August 06, 2004

Tor: Anonymous TCP

Tor is an anonymizing layer on top of TCP. It uses a concept called "onion routing" to keep your online activities anonymous. Basically, packets are routed at random through a network of Tor servers (provided by the Tor user community), making it very difficult to trace their real origin. The contents are encrypted separately for each server, so only the final Tor server will be able to read your payload data, just before it is sent to it's final destination, but by that time the IP information tying that packet to you will be lost.

In short, Tor is to TCP what Mixmaster is to email.

If this all sounds too confusing, check out the nice article on Wired's website.