[tor-dev] Malicious relays and honeypots

[Philipp Winter]

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.

> 2) 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.

> 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.

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.

> 7) 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