Opened 3 years ago

Last modified 20 months ago

#18142 new enhancement

Anti-Automated-Scanning: Support "marking" with iptables TCP connections differently "for each circuits"

Reported by: naif Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: needs-design maybe-bad-idea tor-relay problematic-privacy
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This ticket is to support "marking" with iptables TCP connections differently "for each circuits".

The basic idea is that a Tor Exit operator, in order to reduce automated scanning, may wish to apply specific rate limiters available from the iptables stack of his linux machine.

The usual Tor connection pattern of an automated scan, from a Tor Exit relay point of view, is that from a single circuit there are a lot of TCP connections going out to the same host within a relatively short amount of time.

The usual HTTP(S) connection pattern of normal Browser, from a Tor Exit relay point of view, is to open a bunch of connection to the same IP and keep those open with keep-alive.

So, if Tor software would made available to Iptables stack the "individual marking" of all TCP connections coming out of a specfic circuit, it would be possible for the Tor Exit operator to apply rate limiting finely tuned in a way not to break normal end-user browsing but to break automated scanner efficiency.

Obviously, that works against automated scanners that does not apply a specific technique to bypass this specific prevention technique, that shall be considered most of the automated scanners.

Child Tickets

Change History (6)

comment:1 Changed 3 years ago by teor

Component: - Select a componentTor
Type: defectenhancement

comment:2 Changed 3 years ago by cypherpunks

This feature probably has very limited value. It's trivial for any scanner to simply use more circuits. Many targets likely have some anti-scanning defenses anyway, so scanners need to distribute scanning in the first place.

Is there any evidence that this would be useful?

This feature will expose Tor state to the rest of the system and enable new and easier ways for attackers with system access to perform circuit tracking.

comment:3 Changed 3 years ago by yawning

Keywords: tor-core added
Milestone: Tor: unspecified
Priority: MediumLow
Version: Tor: unspecified

I'm skeptical about this for the reasons that cypherpunks mentioned, and that it'll be fundamentally non-portable.

The portable version of this sort of mitigation would be something like clamping the number of simultaneous streams to a given value, like how we can for HSes, but that still is of limited use, and would be either overly brittle or totally pointless depending on what the exact number for "given value" ends up being.

comment:4 Changed 3 years ago by naif

Well, we are not speaking about encryption, that can be secure or unsecure, 0 or 1, but about implementing features that could enable to slowdown most automated scanning (but not fix with 100% result automated scanning, that's just impossibile).

Given the assumption that most automated scanners works with normal software, that's does not employ Tor specific optimizations other than supporting Socks, this measure could be effective, where effective means "reducing the amount of automated scanning" .

It's like for the chinese GFW, it's an arm race and there's no definitive lethal weapon that's going to make us win the war, but we can still fight.

Said that i think that's really something worth experimenting to reduce the impact of automated scan on Tor Relay operators, enabling ppl like me with sysadmin, network and security skills to experiment the approach.

Fabio
p.s. I also opened up a new idea to reduce the impact of automated scanning, but it's really more complicated
https://lists.torproject.org/pipermail/tor-talk/2016-January/040011.html

comment:5 Changed 21 months ago by dgoulet

Keywords: tor-core removed

The tor-core keyword doesn't really make sense now that we have "Core Tor/Tor" for component.

comment:6 Changed 20 months ago by nickm

Keywords: needs-design maybe-bad-idea tor-relay problematic-privacy added
Note: See TracTickets for help on using tickets.