@ x9p:
# netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort | egrep -v ' 1 | 2 | 3 '
with this information in hand, double the max of it (mine was 10 connections from 188.214.30.0/24):
10 188.214.30iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT --reject-with tcp-reset
Thank you! This was extremely helpful.
In our case we found a handful of IPs that had *thousands* of concurrent connections on several of our relays. The offending IPs were not in the consensus. After restarting the Tor service, these suspect connections come back rapidly, again across several of our relays. Since our relays are all in the same declared family, it is very difficult to see how this traffic is legitimate. If it's valid Tor clients, they are behaving very strangely, and in either case we need to limit their impact. As such we've implemented connlimits by /24 as suggested (with a much higher limit to err on the side of not rejecting valid traffic). We can already see that this has improved our situation.
@ Scott Bennett:
What you are seeing is most likely the same phenomenon brought up onthis list repeatedly over at least the last decade or so. That phenomenon is providing HSDir service, or perhaps a rendez-vous point, for a popular hidden service.
If you don't like it, you can set
HidServDirectoryV2 0
Thanks for your reply. The data suggests this was not the case (this time). Some of these relays have been up almost a year with the same configuration, often with the HSDir flag. The recent issues just started occurring, and happened across several relays during the same timeframe.
Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule it out. However it appears that option is deprecated (on 0.3.1.9). Enabling it causes this in the log:
[WARN] Skipping obsolete configuration option 'HidServDirectoryV2'
It's also no longer listed in the Tor manual (https://www.torproject.org/docs/tor-manual.html.en). It looks like we might be able to achieve the same effect with something like this instead:
MinUptimeHidServDirectoryV2 52 weeks
Anyone have any info on why HidServDirectoryV2 is consider obsolete? Is using MinUptimeHidServDirectoryV2 instead going to achieve the same effect?
We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:
elif [ "$system_max" -gt "40000" ] ; then MAX_FILEDESCRIPTORS=16384
Surely that is high enough for normal service?
If by normal you mean "low traffic", then yes, it's probably enough.However, that's really not very high in a general sense.
Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise. Obviously we could comment out these lines, but it seems odd the default config tries to cap it at 16384 if that's too low for a high traffic relay.
Thanks everyone for your replies!