[tor-relays] Monitoring multiple relays

[Vasilis]

Hi,

DaKnOb:
> It depends on what you consider “professional” monitoring. Do you mean information collected, or how was it collected?

By professional monitoring I mean a way to find out in a short time-span
what was the reason for a relay that suddenly  is disconnected from the
Tor network, uses an outdated version of tor, performs badly on the Tor
network, runs an outdated OS version, misses security updates or other
crucial software that may compromise the Tor relays and subsequently the
Tor network.

Some important properties of this monitoring system:

- Hardware issues: RAID/HD/hardware failures, kernel panic/OOM states
- Software issues: OS updates, tor updates, security updates
- Network issues: RBLs, IP blocking, upstream network issues
- Abuse issues: Monitor of abuse emails per relay/network -sort of
ticketing system for operators that are unwilling/don't know/have the
capacity to track and respond to abuse emails (that most of the time are
automated and just a 'foo' response back)
- Legal issues: Initiating a canary-like or similar for relay operators
that would like to be reached out when they don't provide any updates. I
suspect this to have many false positives but better safe that sorry
(quite often you are not allowed to speak openly about a legal issue
until this is settled, in this part potential organizations may reach
out to help operators)

> Is measuring something from the tor process using bash scripts and cron professional?
> Is measuring network traffic using Prometheus and plotting to Grafana professional?

My "professional point of view" will be a system -preferably agent-less-
 that could ping operators via email and provide alert notifications on
an IRC channel.

> For a few nodes I control / controlled I measured lots of network info such as:
> 
> - Network Traffic in / out (b/s)
> - Network Packets in / out (p/s)
> - Network Flows in / out (f/s)
> 
> And I always run a local resolver, so DNS info too:
> 
> - Query Responses / Second
> - Query Latency 
> - SERVFAILs / Second
> 
> The DNS info was gathered only in one node, as an experiment, since I wasn’t sure whether it could leak information, and only for a limited amount of time. 

I share the same concerns with you so I'm not really interested in
measuring DNS responses or collecting long-term stats that may leak
sensitive information or potentially used to de-anomymize or compromise
in any way (in ways that we don't know yet) the Tor network.


~Vasilis
-- 
Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171020/76f91151/attachment.sig>