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(a)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(a)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(a)lists.torproject.org mentioning "
"your address(es) and fingerprint(s)?";
- tor-network-alerts(a)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(a)lists.torproject.org
Public. DocTor report detected issues to that list. No discussions.
- ornetradar(a)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
--
21BSebbtTMg1u+swxsy4Y2IVWlthi9t/XgN+FybFMe8=
Hi!
Mike uploaded the meeting notes of our network health session today and
I complemented them with the notes I had:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/No…
Please have a look over them and make those notes even more usable in
case we forgot something or got something wrong.
Thanks for the session today to everyone being there,
Georg
