Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
Well, it's still going on, and is pretty much ruining Libero :( . Running CentOS 6, here. Actually, I think from what I'm seeing that it may not exactly be a synflood targeting Libero. I think Libero may be being (ab)used to do massive portscanning or similar. Image should be visible below - it's normal statistics for the 18th through say, part of the 21st, messed up 22ed - 24th and on the 24th me trying different things in an attempt to mitigate (graph is from yesterday). Look at the SYN_SENT2 maximum. When it's happening it can look like this: # netstat -n | grep -c SYN 17696 # Also one tiny part of the netstat looked like this: tcp 0 1 64.113.32.29:33354 <external IP munged>:81 SYN_SENT tcp 0 1 64.113.32.29:39659 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:44247 <external IP munged>:87 SYN_SENT tcp 0 1 64.113.32.29:42038 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:42077 <external IP munged>:83 SYN_SENT tcp 0 1 64.113.32.29:36282 <external IP munged>:8888 SYN_SENT tcp 0 1 64.113.32.29:46023 <external IP munged>:8888 SYN_SENT Port 8888 is supposedly opened up for listen by a virus.
The subject of this new thread is detecting network attack upon tor network / relays itself. You report is users using tor's exits / exit traffic from relays, which would be excluded from such monitoring, most absolutely in any identifiable manner. If the exit traffic bothers you, exitpolicy reject 8888 or whatever else makes up the issue. It should go away after time for new descriptor to pass around.
On 26 Nov 2017, at 07:14, grarpamp <grarpamp@gmail.com> wrote:
The subject of this new thread is detecting network attack upon tor network / relays itself.
Nick Mathewson has mentioned wanting to do this for Tor protocol violations. But we need a privacy-preserving aggregation scheme in Tor so we can do these counts safely. (Otherwise, anyone who can remotely trigger a rare protocol violation can find out which relays a client or onion service is using.) When we create this list, we will also think about what other kinds of attacks on the network we can reliably detect and monitor. We're limited in the number of counters we can create for these events, and they must track integer counts. Do you have a "top 5" list of attacks we could detect this way? T
On Sat, Nov 25, 2017 at 5:15 PM, teor <teor2345@gmail.com> wrote:
need a privacy-preserving aggregation scheme
(Otherwise, anyone who can remotely trigger a rare protocol violation can find out which relays a client or onion service is using.)
The above don't necessarily lead to each other.
scheme in Tor so we can do these counts
That's thinking of 'in tor' code, which is good way and project to see some things only visible there, and way to count and submit them over tor. I'm more thinking using external tools to watch the network interface itself... Attackers will read / fuzz the source code till they exploit via tor's open ports anyway. Though it could still be good to instrument those ports with both tor protocol analyzer, and a raw packet statistical analyzer / classifier to see what's incoming. Instrumenting the IP itself to look for debilitating inbound packet bursts from the internet indicating node pruning segmentation attacks. Would be interesting discovery. Though attackers might find the method redundant given already ways to deanon hidden services and fewer to deanon users. And all the usual IDS type of tools that could be deployed and collected to see who / what is probing away at the network itself and how. Might want to look for modulation patterns in OR traffic proving existance of certain known attack methods. Not talking about content of exit traffic in any of this. It's exposing attacks from clearnet, not users of tor. Operators could opt in. Prebuilt tool packages could be created. Someone with a handful of relays could always do the research project on their own, and like silent attackers, may already be.
participants (3)
-
grarpamp -
teor -
tor＠t-3.net