
"Trickle" attack on Minecraft servers, or Don't Use Thread-Per-Connection - AndyKelley
http://corbinsimpson.com/entry/take-a-bow
======
trotsky
Lots of purpose built servers are vulnerable to slowloris type attacks. Which
doesn't mean that they shouldn't be fixed, just that it's hardly remarkable to
find one. While certainly everyone is entitled to do disclosure however they
see fit, it comes off kinda jerky to drop a working POC on the community just
to advertise your unfinished competition.

~~~
jschrf
Agreed. Yes, it is easy to attack video game servers. Indie game servers even
more so.

If you want to DoS a server so that players can't die wool or smelt iron or
hit pigs for porkchops, you should probably reevaluate what you're spending
your time on.

------
gojomo
Paul Tyma's counterpoint from 2008, that thread-per-connection is scalable to
tens (and maybe hundreds) of thousands of threads, using recent Java & Linux
NPTL:

[http://paultyma.blogspot.com/2008/03/writing-java-
multithrea...](http://paultyma.blogspot.com/2008/03/writing-java-
multithreaded-servers.html)

~~~
KirinDave
Indeed, I'm reading this wondering how 400 connections could even crash a JVM
on an OSX machine. It's surprising.

I suspect it's not a threading issue in the sense he's describing. 400 threads
probably shouldn't give you an OOM unless your heap size is set perilously low
(in which case just about everything will give you that error).

It's also painful to then see him argue that epoll/select/NIO is the magical
path to freedom. Erlang and Akka developers are trying to to cry and laugh at
the same time when they see this.

~~~
caf
400 threads with a thread stack size of 8M means that 3.2GB of virtual address
space needs to be committed, which suspiciously close to the usual limit on a
32 bit system.

If you want to create that many threads, you need to start by severely tuning
down the stack size.

~~~
riobard
And use 64-bit systems.

~~~
ajross
_Or_ use 64 bit systems. That 8M isn't physical memory, it's just allocated
address space. Only the tiny handful of pages at the end of the region
actually get faulted in.

------
rdtsc
One thread per connection might not scale but in this case other things could
be done to mitigate the potential problem before re-writing the whole server.
Perhaps use a special encoding for the authentication that doesn't use
unbounded strings for username but a fixed size array of chars? Then maybe
start a timer and if authentication isn't performed during a given time
period, disconnect that client.

~~~
blake8086
Say you kill connections after 1 second (pretty aggressive) and you can hold
1,000 connections open (that's a fair number of threads)

All I have to do is create 1,000 connections per second and I'll hog all your
thread resources. That's not too hard to do.

~~~
wtallis
Killing connections after a full second has elapsed probably isn't at all
aggressive in the context of a game server. If the connection is legit but
takes a full second to send authentication info, then there's no hope for the
game actually being _playable_ over that connection.

~~~
kpreid
Depends on the game. Minecraft is hardly twitchy, especially if you're
building, not fighting; the client proceeds as if each action has already
happened, so you don't have to wait for the roundtrip between actions.

------
bartwe
Exhausting ports or generating a lot of TIME_WAIT states would also cause
similar problems. How to protect against those ?

~~~
bnoordhuis
You'll be hard-pressed to exhaust all ports: modern operating systems track
connections by source address + source port + target address + target port. I
wouldn't be surprised if the TCP sequence number is also part of the mix.

TIME_WAIT times can be tweaked with the net.ipv4.tcp_tw_recycle and
net.ipv4.tcp_tw_reuse sysctls, on Linux systems anyway.

~~~
cnlwsu
Exactly, you can only really exhaust the ports from the server address/port to
your single host, which is effectively only DoSing your own access to the
server. Ive seen over a million sockets in time_wait and it did not effect the
servers.

However if doing something like behind a single software load balancer then
the number of ports available will be limited to the 65k connections since the
source address/port and target address(the lb) are fixed.

------
vegai
Except if your language/platform hides the actual thread implementation in an
epoll loop.

 _coughhaskellcough_

