[network-health] State of Bad Relay Team

David Goulet dgoulet at torproject.org
Mon Jul 22 16:15:45 UTC 2019

Hello everyone,

I'm writing this email to help bootstrap more and more the network health team
by outlining the status of the "bad relay team" as in where and what tools we

After discussions at the Stockholm meeting, this is in the spirit of trying to
gather information in one place (this list) and push the effort to consolidate
everything we (Tor Project) have in that space to, ultimately, our Gitlab
instance. We have a team already there although quite empty at the moment.


Several tools are being used by the bad relay team. The following I would
consider them in the "critical path" of the bad relay team operations:

1. Malicious HSDir Scanner

   This one is in a private git repository on Github. For obvious reasons, we
   don't make it public in order to avoid attackers gaming it. It is run
   regularlry by the team.

   I've asked the author if we can move it to dip.tpo under the network health
   team umbrella. Pending...

   This tool has dependencies on "eschalot" with custom patches to it and
   custom patches to "tor" as well. These need to be maintained over time and
   thus should also be on dip.tpo.

   This also need a tor relay to be run which requires the custom tor patches
   mentionned above and the HSDir flag (which you only get after 96 hours of
   uptime so can't be rebooted often...).

   It is an extremely important tool right now for bad HSDir detections so we
   should definitely keep this one well maintained and running as long as v2
   .onion addresses exists.

2. Exitmap

   The core of this tool is public here:


   The modules are in a private repository as well. I've also asked the author
   if we can move this tool to dip.tpo. It is also run quite regularlry by the

3. DocTor

   DocTor is a great public that is run by atagar. Any warnings goes on the
   consensus-health@ mailing list.


   In the case of the bad relay team, custom secret modules exists and run
   daily. This should definitely move to dip.tpo. I have ownership of those so
   easy move.

   Overall, this is a good project to move to the Network Health team in my
   opinion, with atagar's permission of course.

4. Sybilwatch


   This is an extremely useful tool to correlate relays with the same
   characteristics in order to find all the related relays of a detected

   Own by Donncha and public so probably no need to have it on dip.tpo.

5. Custom Stem Scripts

   I made several custom Stem scripts in order to walk the
   consensus/descriptors and extract information which makes it much easier to
   find relay's information to reject/badexit.


   Not the cleanest but very useful. I think having them on dip.tpo would be
   useful but not required.

6. Tes

   Tool written by meejah. Allows us to detect MITM attacks by relays. It is
   in a private git repository so if meejah wants to move it to dip.tpo, I
   think it would be great! Else, documenting that it exists could be enough.

Other tools exists for a variety of purposes like "trnns" made by phw
(https://github.com/NullHypothesis/trnns) but afaict, not in the critical path
of the bad relay team.

About git repositories:

- dirauth-conf.git

  Private. Only a handful of people have commit access to this including all
  directory authorities (9 of them).

  This contains many things including the reject/badexit rules that the bad
  relay team submit there and the directory authorities then each take a
  personal decision on applying the rule or not.

  This is up to debate I believe if it should fall under "Network Health"
  umbrella or not... Difficult to say but I'm leaning towards "yes"
  considering that it also contains configuration files that dirauth should in
  theory use/apply like consensus parameters which is very "health" to me :).

Now in terms of communication, several mailing list exists:

- bad-relays at lists.torproject.org

  Private and with very few people. Coordination happens there for any relay

  It is the advertised list to report malicious relays but also to report that
  your relay is rejected if you are an operator that let say re-used an
  blacklisted IP address.

  It is actually hardcoded in tor code and part of the reject reason string
  that a directory authority will send back:

    *msg = "Fingerprint is marked rejected -- if you think this is a "
         "mistake please set a valid email address in ContactInfo and "
         "send an email to bad-relays at lists.torproject.org mentioning "
         "your fingerprint(s)?";

    *msg = "Suspicious relay address range -- if you think this is a "
           "mistake please set a valid email address in ContactInfo and "
           "send an email to bad-relays at lists.torproject.org mentioning "
           "your address(es) and fingerprint(s)?";

- tor-network-alerts at lists.torproject.org

  Private list. Only scanners/bots email that list with alerts. So 1), 2) and
  3) all are configured to email that list with their alerts.

  Related discussions happens on bad-relays@

- tor-consensus-health at lists.torproject.org

  Public. DocTor report detected issues to that list. No discussions.

- ornetradar at lists.riseup.net

  External from TPO. Public. https://lists.riseup.net/www/info/ornetradar

  Events are also published here:

  Run by "nusenu" volunteer. It has many many detections that we use in order
  to make decision on bad relays.

Those are the active mailing lists that the bad relay team uses/observes.

I believe the above covers it all on the bad relay team side... Thing is that
other volunteers might be running scanners or custom tools so the above really
covers what *I* am aware of.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/network-health/attachments/20190722/457ea7a2/attachment.sig>

More information about the network-health mailing list