On Wed, Nov 26, 2014 at 10:30:42AM +0000, Gareth Owen wrote:
I wonder if it might be worth having a discussion on how to detect malicious and/or suspicious relays. To my knowledge, the project currently only scans for MITM and tries to detect larger Sybil attacks (but doesn't always act when detected).
At the moment, we use exitmap [0] to detect MitM attacks and doctor [1] to spot possible sybil attacks. And it's true that our process for dealing with these incidents (or more accurately, our lack of process) was insufficient. We tried to improve by creating the bad-relays@ mailing list and by making the list of blacklisted relays openly accessible [2,3]. More suggestions are always welcome.
I'm currently trying to organise funding for a project to improve our sybil detector and also to find other anomalies in network status documents.
- Many relays being launched on sequential IP addresses, and/or with two
nodes per IP - again - likely intercepting DHT publications or Sybil.
This is particularly a problem with cloud providers because they make it so easy to spawn new relays. I'm not sure if this issue is severe enough for directory authorities to blacklist the IP address space of popular cloud providers.
- We also have the wider question of traffic tampering by exits, like
the recent binary patching exit which I believe was not detected by the project.
Unfortunately, nobody was looking for this kind of attack, so it was not discovered sooner. I would be happy to add new exitmap modules if there are suggestions for additional scans.
- And finally, Exits that only exit ports which permit tampering - e.g.
the exits that only exit Bitcoin traffic for example.
This is indeed interesting. Right now, there are 199 relays with a non-empty exit policy which were not assigned the exit flag.
The question of course is where is the threshold and what does one do in the event of one of these.. Personally I am of the view that suspicious relays are not worth keeping in favour of diversity - but that view does contradict the project's I think.
That's a good question worth discussing. It depends on the threshold of "suspicious". For example, while we used to assign the badexit flag to exit relays using a broken OpenDNS configuration, this is not done any more because sacrificing exit bandwidth for something most users would only perceive as a mild nuisance is perhaps not worth it. (Also, while the amount of relays over time increases, the amount of exit relays remains mostly static [4].)
It would also be great if more relay operators would set contact information. For example, we had cases where exit relays seemed to tamper with exit traffic but after talking to the operator, it turned out to be an adjacent server in the relay's data centre doing ARP poisoning. I suppose, running a Tor relay can actually improve a data centre's security :)
[0] https://gitweb.torproject.org/user/phw/exitmap.git [1] https://gitweb.torproject.org/doctor.git [2] https://gitweb.torproject.org/authdirbadexit.git [3] https://trac.torproject.org/projects/tor/ticket/13302 [4] https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2008-08-28&end=2014-11-26
Cheers, Philipp