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

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.

https://dip.torproject.org/torproject/network-health

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:

https://github.com/NullHypothesis/exitmap

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

3. DocTor

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

https://gitweb.torproject.org/doctor.git/

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

https://github.com/DonnchaC/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 attack.

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.

https://git.ini-tech.com/stem-scripts.git/tree

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@lists.torproject.org

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

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@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@lists.torproject.org mentioning " "your address(es) and fingerprint(s)?";

- tor-network-alerts@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@lists.torproject.org

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

- ornetradar@lists.riseup.net

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

Events are also published here: https://nusenu.github.io/OrNetRadar/

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.

Cheers! David