My relay ran out of connections once and also crashed once so I followed the suggestions in the "DoS attacks are real (probably)" thread and implemented connection limits in my firewall. Everything has run smoothly since.
I missed this thread, thank you for highlighting it!
My only concern is how low I can set the number of connections per IP address. Someone wrote a legit client will only open max 2 tcp connections. I'd like this verified before I lower my limits further.
Two connection limit is fine for single-IP clients, but will penalize multiple clients operating behind NAT IPs. I've decided that's too bad for them for the moment. . .
Limiting connections-per-IP fixes it. I set
-m connlimit --connlimit-above 2 --connlimit-mask 32 -j DROP
and obtained good mitigation. The attacker relies on opening tons of connections and this simple rules squashes it. Rule accumulated 15 million hits over a short span.
I have kept an eye on the number of peer-relay connections and client connections for a long time and the client connection count has been artificially high of late. With the above rule it went right back to the usual level.
The limit can be higher than two and it should work as well--the rate of new connections appears to be critical to the attack. Possibly the low performance CPU here lacking AES hardware mitigates it since each connection appears to require an onionskin calculation, and whatever old-connection cleanup logic exists in Tor easily keeps pace. This has been going on for months and only became a problem now with the attacker enhancing it to somehow queue huge amounts of data on circuits--but per my initial post that's simple to mitigate.