DoS attacks against my online game
hookrace.net
hookrace.net
Yeah that's the problem, attackers get 10+ gigabits UDP flood quiet easily these days and with that they simply hammer down your line, well before any of your software protection mechanism could react.
IIRC, we eventually used AWS Elastic Load Balancer to just soak up the attack, which was a pretty basic SYN flood. Then we waited the attacker out until he got sick of spending money. That temporary redirect definitely impacted performance and cost us some money but it pretty well mitigated the issue. We also spent a bit of time optimizing our servers to drop obvious nonsense requests as quickly as possible but in the end the ELB handled most of the issue for us.
):
Or so I've heard
Edit: Found it. http://opentnl.sourceforge.net/doxydocs/history.html (the „puzzles“)
Regarding the HTTPS request thing, we already did this for an event and I'm currently getting it set up on all servers. The blog post forgot to mention this one :)
Cost more to check than it would for the attacker to generate an _incorrect_ proof. I'm sure that's what you mean, but my brain first went to NP problems.
And actually, now that I think of it, maybe, maybe not. A PoW can be pre-calculated (possibly using off-peak cloud resources for very cheap) and then stored in a lookup table. It can be reused until the attacker actually solves the problem. Then _maybe_ you could offload that verification to a cheaper, harder to DDoS service, like a cloud function that won't charge you for SYN flooding.
But then the hard part is letting legitimate users bypass the check after doing their PoW, but not letting an attacker through.
Edit: I should add that the DDOS protection is included with the server rental and there is no limit on the size or duration of the attack.
Mind you, this is a process using a single port, with only around 100 active connections. You'll easily see half if not more lose connection during a DDoS attack.
Thanks for the heads up :)
From running a service with 50-100k concurrently active connections on a single VPS on OVH that has shrugged off a lot of attempted DOS attacks over multiple years, I have the impression that OVH handles DOS attacks exceptionally well. Specifically I've never seen it drop (a lot) of legitimate traffic.
In comparison to OVH, Hetzner (which this game seems to be using), is utter garbage when it comes to responding to any kind of incident well, or at least predictably. Their responses range from doing absolutely nothing, to nullrouting you, to terminating your service. With OVH I at least know how they'll respond to various things and they're (with few exceptions) professional about it, even if I don't like it.
I'd say you get what you pay for, but OVH (when comparing dedicated servers) aren't much more expensive.
OVH has consistently been filtering legitimate traffic for us each time we tried them and we’ve tried almost every tier of service they offer.
Edit: you could always contact their support as well. Fighting DDOS on your own it's an expensive/difficult battle. But their DDOS filter is fully custom (mostly Asic and some Arbor as well).
Do you modify any kernel options? net.ipv4.conf.all.rp_filter=1
I know that, if you own a gambling site, you can look forward to meeting exciting slavs. I didn’t realize they were taking it to other types of games, but I guess that makes sense. Wiseguys coerce Grandma’s Bake Shop, just as they do Moneybags National Bank.
We have a small team who work on this project during our free times and most of us just don’t currently have the time to dig into conntrack/nftables/xdp.
[0] https://duo.com/labs/tech-notes/writing-an-xdp-network-filte...
Interesting. I wonder if running an overlay network would help there. More choices today for userspace overlay networks. Rogue server owners would still see an IP, but they could only attack it from their connected server, not the internet at large. And you could do some kind of ingress/egress filtering.
Some sort of periodic coordinated switching from UDP port A to port B might help too, like a control message that tells the game client to switch ports. Or randomized initial port assignments combined with filters/firewalling or just in-band 'you're not supposed to send here, bye'.
1. Cloudflare offer TCP based DDoS protection too, see their Magic Transit or Spectrum product
2. This sucks, but put your servers behind WireGuard or Tailscale VPN so that in order to connect you need to have authenticated
Have you looked at ddos-guard's pricing? They seem to be a common budget option.
but I'll throw the idea out to see if anyone else could improve on it etc..
initial strawman draft idea: have a front door service that just verifies your gamers (eg log on server) This will need to be protected by a Ddos but the throughput shouldn't be large. once authenticated your clients IP address is then passed to some sort of software based firewall protecting each of the main game servers
Embark Studios recently open sourced (in alpha) a UDP proxy[1] designed for games that lets you implement a load balancing layer. This allows you to remove servers in the load balancing layer in the event that it comes under attack, allowing the game server to stay up and only having to disconnect a portion of players connected to the attacked loadbalancer. Having a proxy layer is also how Steam protects game servers using the Steam Datagram Relay[2].
[1]: https://github.com/googleforgames/quilkin [2]: https://partner.steamgames.com/doc/features/multiplayer/stea...
Original post: Have you looked into using a serverless pub/sub model, like Cloudflare's Workers KV? The example they give is a simple IRC-like distributed chatroom (https://github.com/cloudflare/workers-chat-demo), but theoretically it may work for games too.
Player state can be stored in a decentralized key-value store that Cloudflare manages (Cloudflare Durable Objects). They absorb all the DDoS and handle replication between edge nodes. You don't see any of that. https://developers.cloudflare.com/workers/learning/using-dur...
Then each game client uses a worker to access that KV on a subscription basis, and Cloudflare will route that worker to its nearest edge node and retrieve the state from there (which was previously replicated a moment ago, internal to Cloudflare's infrastructure). Changes to state are replicated across the edge network and pushed to client workers.
https://workers.cloudflare.com/
I don't know if this would result in acceptable latency, but it could help with DDOS at least. The main benefit is that it's incredibly affordable, especially when you're only talking about thousands of players.
It is indeed possible for ISPs to stop this, but my guess is that it's cheaper not to :) Large ISPs could require egress filtering for peering with them.
As for their charging, that is called "value pricing" - what matters is the value to you, not the cost to them.
1h timeout is way too long, you should not have more than a couple of minutes max.
I worked on some popular online games and it was a combination of 1) + some IP tables rules ( to allow the traffic ).
Too many login would block the IP etc ...
With proper auth ( based on TCP ), IPtables, kernel tuning you can get a lot of good results without doing some complicated things like UDP proxy / relay / load balancing.
The idea from my original post is that your gameserver should allow traffic only if the player is authenticated.
The prosecutor is a #@*&%! : your time costs money. Working outside normal office hours is costly.
Maybe you need to setup a contract between the "organization" that runs the servers and yourself that states how much time (and money) does it cost to run the game.
Yes.
In fact, when my mother's grandfather was in conservatorship, his conservator (my mother's cousin) embezzled over $600,000 from his estate, and the prosecutor refused to prosecute.
We were able to get somewhere over half of the amount back through a civil suit.
Don't ever expect that the prosecutor is there to help you.
That is sort of a non starter for us without some workaround like maybe hosting our own relays for the open source clients.
The clients connect to a relay server that just forwards the packets back and forth between the client and the real server. The client never gets to know the real server IP, preventing attackers from DDoSing the servers. If the connection to the relay server drops (which can easily happen if the attacker DDoSes the relay server instead), it can easily resume the connection with any other relay server, and the real server never notices it dropped.
This relies on the fact that there are too many relay servers to DDoS at once, and attackers never get to know the real server running the game code, so they can't make it unreachable.