[thaumaturgy]

The packet signature thing is maybe sort of interesting, but it's not hard to block Tor exit nodes; Tor themselves makes this easy:

    #!/bin/bash
    addresses=$(curl -s https://check.torproject.org/torbulkexitlist?ip=<your-server's-ip> | sed '/^#/d')

    if [ -n "$addresses" ]; then
        /sbin/ipset flush tor
        echo "$addresses" | while read address; do
            /sbin/ipset -q -A tor "$address"
        done
    fi

Add that to a cron job and your form abuse traffic falls off a cliff.

[EE84M3i]

If you feel it necessary to block Tor nodes in some way, I think it's better to only block non-safe methods.

Personally, I don't do it, but I understand why it's appealing. I see it as a personal decision (its your website after all) and not morally wrong as some see it.

I once talked to someone working security for a Canadian government agency. They considered it against their charter and/or illegal to block tor nodes, because it could be blocking legitimate access for Canadian citizens potentially in distress, much to the chagrin of their downstream customers (other agencies). I thought that was pretty interesting.

[gpm]

I think there are also some Canadian court cases protecting the right to speak anonymously over the internet. It's an area where I think our government is going a pretty decent job (as governments interacting with new fangled technologies go)

[EE84M3i]

Yeah, I don't remember the exact reason they didn't consider it a possibility, but I seem to remember the guy saying it would save him a headache but it wasn't in the cards and that they had to explicitly configure some solution they were using (perhaps cloudflare?) to not DoS the traffic.

[thaumaturgy]

Yeah. I'm sympathetic towards the Tor project in general, but it's also a huge source of nuisances and almost 0% legitimate traffic (in my case). As a beleaguered one-man sysadmin who also wears a full-time dev hat, I just don't have the resources available to build out a more clever rule-based filter for Tor traffic. This approach took me all of about 10 minutes to figure out and deploy across my little network of servers, and it made an entire stream of daily emails disappear immediately.

If I were fortunate enough to be part of a larger team, I'd advocate for exactly what you're suggesting.

[EE84M3i]

I was thinking that Apache / Nginx blocking based on IP match and HTTP method is likely approximately equivalent complexity.

Also CDNs generally offer this if you use one.

[thaumaturgy]

Not quite, unfortunately. Apache's not all that nimble; setting up rewrites for a handful of ips-and-methods is pretty easy, but it doesn't have a built-in way to use an external list of ips (that I'm aware of). I just checked, there are over 1300 tor ips in the result set currently.

I could write a conf.d file to be included in each vhost, and write a script to generate a large rewrite file nightly and "apachectl graceful" it afterward, and that would probably work... but I expect that will have a measurable impact on response times and, again, I'm not hosting governmental sites or anything that could reasonably be considered vital to the health and well-being of innocent tor users.

[cryo]

The article also mentions banning ip ranges and it's disadvantages. The described detection of Tor traffic seems to be more bullet proof and performant.

Hopefully the Tor devs consider the proposed enhancements to make the traffic less vulnerable to identification. As he already digged into the source code, maybe it's easier when he submits a PR for a higher chance to fix the issue.

[ColanR]

I believe the article mentions that, but also notes your method works for low-traffic situations. The 0day is a high-performance alternative.

[thaumaturgy]

ipset is very fast (http://web.archive.org/web/20160514091316/http://daemonkeepe...).

The author's approach requires examining a certificate to see if it matches a pattern that may or may not change in the future.