DoS attack on my relay

Support Relay Operator
1

My relay (v 0.4.9.11) was working fine for 1.5 months, but today problem appeared:

It consumed 6 GB of RAM instead of usual 1 GB and started to print warnings to the log file:

Jul 13 02:47:02.000 [notice] HSDir cache exceeded limit (214770954 > 214748364 bytes). Pruned 50032667 bytes during an HS descriptor upload.
Jul 13 05:37:05.000 [notice] General overload -> Ntor dropped (10102743) fraction 38.5814% is above threshold of 0.5000%

Relay restart did not helped much, but it changed type of warnings:

Jul 13 07:42:48.000 [notice] We're low on memory (cell queues total alloc: 1012968000 buffer total alloc: 57765888, tor compress total alloc: 0 (zlib: 0, zstd: 0, lzma: 0), rendezvous cache total alloc: 3704468). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Jul 13 07:42:48.000 [notice] Removed 108354576 bytes by killing 4901 circuits; 117229 circuits remain alive. Also killed 0 non-linked directory connections. Killed 0 edge connections

Is there a way of controlling RAM usage besides MaxMemInQueues (which does not help much)?

Is this attack new? Will developers modify relay code to add protection against such attack?

2

It looks like someone is trying to flood your Tor relay by creating a large number of circuits? Tor comes with some defense parameters, and there’s an introduction link below.

I previously configured it to use all consensus default parameters (as follows), and since enabling these defenses I haven’t encountered any issues (other than my relay complaining in heartbeat messages that it killed a large number of DoS attack circuits).

DoSCircuitCreationEnabled 1
DoSCircuitCreationDefenseType 2
DoSConnectionEnabled 1
DoSConnectionDefenseType 2
DoSRefuseSingleHopClientRendezvous 1
DoSStreamCreationEnabled 1
DoSStreamCreationDefenseType 3
3

Here are few observations regarding this attack:

It is rare. It happens about once a month.

Most likely, it targets some specific service, which is occasionally registered on my relay because of HSDir flag. When flag is gone, attack is gone as well.

Relay restart actually helps, but not immediately: after an hour attack stops and relay can be restarted once more to free more RAM.

Such properties make testing of different configuration parameters inconvenient. But I will keep in mind your suggestion and will try it if something changes. Thank you.

4

This reminds me of the attack vector mentioned here: the attacker’s goal is to DDoS a specific Onion service, but they do so by taking down the Tor guard relays and directory relays that the service relies on.

In this scenario, it no longer matters whether the attacker is targeting your relay or that ‘unknown Onion service’—you both end up as victims.