[tor-relays] An easy self-DoS and how to avoid it

[j4c4l4]

Hi there,

I have been operating a non-exit relay and a bridge for about one week now.
I discovered by chance a quite silly self-DoS which could be triggered by
using a NIDS (Network Intrusion Detection System) on relays. I don't know
if it is known, but I thought it was worth reporting it here.

In many Linux distributions, several NIDSs come with a default policy that
blocks all the traffic from offending IPs after they have reached a
threshold score. The offending IPs are normally put into a separate
firewall chain/table that DROPs all the traffic originating from them, and
then re-enabled after a period that could vary between 30 minutes and a few
hours (again, depending on the config).

Now, this could be potentially used to periodically shut down relays. In
fact, an attacker could perform something as simple as an ssh login scan
*through tor*, which is among the "attacks" monitored by most of the NIDS
out there. But since the login attempts appear to originate from the tor
exit relay, this effectively flags *the exit* as an "offending" host, and
triggers the corresponding firewall rule (which is normally a blind "DROP",
to save on rule processing).

Once an exit node is flagged as "offending" and put in the firewall rule,
any traffic between the relay and the exit node is effectively forbidden,
until the firewall rule is removed or the tables flushed. If performed on
a large scale, this can potentially shut down all the relays which run a
NIDS with such policy on ssh logins. The same is true for other simulated
attacks on other protocols (but ssh monitoring and blind DROPs are so much
common to be the ones of most concern, maybe).

I don't know how many relays run a NIDS (I suspect several do, actually),
but it would be better to be aware of this potential self-DoS attack. The
easy solution (apart from not using any IDS on relays) is to make sure that
all the incoming traffic to the ORPort is always accepted, e.g. introducing
an ad-hoc firewall first rule that accepts all TCP stuff from the ORPort,
before processing NIDS-managed rules.

Sorry if this was known already, but I couldn't find anything related by
looking at the recent topics in the ML archives, and I thought it coud be
useful to share.

Regards