Hi all
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).
We have a lot of knowledge now about types of attacks and the unusual behaviours that might present if they are being deployed. For example:
1) Relays changing their ident every 24 hours are likely trying to be in a position to be the directory node for a HS (there are several of these relays active today). 2) Many relays being launched on sequential IP addresses, and/or with two nodes per IP - again - likely intercepting DHT publications or Sybil. 3) I have spotted several times a large number of relays in the same subnet, or adjacent /24 subnets. You could extend this to ASes. 4) Honeypot relays that try to spot unusual cells or traffic patterns traversing the tor network. For example, this could have detected the RELAY_EARLY attack if it was based on a different code base. One could define very robust and tight rules for what is permitted - flagging nodes sending unusual traffic. Additionally, PADDING cells are not currently used by the official client but are used very widely in traffic confirmation attacks - whilst intermediate relays wont be able to detect this, clients can and could flag it with an authority (via a 3-hop circuit). 5) One could scan for unusual descriptors being returned too - e.g., the descriptor is currently with in tight size bounds - but one could pad with bytes to support traffic confirmation if PADDING cells are put on the red flag list. 6) 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. 7) And finally, Exits that only exit ports which permit tampering - e.g. the exits that only exit Bitcoin traffic for example.
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.
Best Gareth
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
-
Gareth Owen -
Philipp Winter