0
\$\begingroup\$

I'm in the design phase of a turn based game with low load on the server (<1 message every 10 seconds per user, <50'000 users at a time). The game is multi-platform.

The protocol has not been decided yet.

How can I mitigate DDoS attacks against such a server by design?

\$\endgroup\$

closed as off-topic by Seth Battin, Anko, congusbongus, Kromster, Josh Jul 20 '15 at 16:50

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – Seth Battin, Anko, congusbongus, Kromster, Josh
If this question can be reworded to fit the rules in the help center, please edit the question.

2
\$\begingroup\$

When a large scale attack reaches your machines, there's a limited amount of things that the code can do to mitigate the problem.

For low volume attacks, you could attempt to recognize bogus requests early and rate-limit/ignore sources that do not appear to do anything useful to lessen the amount of computational resources your application wastes on them. You can limit unauthorized connection attempts rather heavily, and move all your static unauthorized assets like images and CSS onto a content delivery network.

For high volume attacks, most of the traffic will not reach your application and is probably not even intended for your application. The purpose there is to completely saturate the network connection to your machine, or to spend all CPU time and memory in the kernel on buffering.

The way to combat the latter kind is to work with your hosting provider and their upstream providers to prevent traffic recognized to be part of an attack from reaching the site in the first place. This is an ongoing process and nothing you can solve up-front, except by establishing communication paths and terms of service.

You can also gain some resilience by making your service distributed and placing all core services on backend machines separate from the frontends. This ensures that if your some of your fluffy cloud frontends get hammered, a few of them will remain reasonably functional and be able to talk with the backends as normal.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.