Lobby and Game appear to be on the net to me. If you're forwarding to them, they're on the net.

The typical behavior is to have a proxy server that sits between the servers that do the game logic and the player. The proxy server does all the validation, load balancing, packet validation, etc. Then it forwards the player requests on to the game logic servers. Those servers do the processing of things like physics, making sure that the actions are acceptable, and then issue a response to the proxy server that tells it aye or nay to the player's request, along with publishing relevant state information.

That sounds like a lot of work unless validation/packet validation is heavyweight - and that should depend a lot on the type of game. I personally worked on poker server backends for a few years and I never ran into a need to do something like that.

That said, the same company worked on a "next gen" poker platform which distributed everything, even worse than what you describe. Scalability and reliability was in the dust for that platform.

So to me that solution sounds like quite the trade-off.

I'm also wondering what sort of attack you'd do on a game server with a single open port. Yes, it's possible to overload it, but killing the proxy by overloading it would amount to the same thing, wouldn't it? Please explain the benefits, because I don't really see them.

As to the encryption, I don't generally trust myself to get all the edge cases correct and rather use the separate SSL connection for initialization. The ssl connection is only used for login and other secure items. As a benefit, you can use it for the initial NAT traversal since you have the connection anyway. In general though, this tcp connection is only there for a brief period and won't interfere with the UDP once initiated.

That's good advice in general. I've dug deep into cryptography to design a protocol which I feel fairly confident in. Mostly because it's basically an implementation combining two well known protocols. Still, I know it's a risk.

(Even if it's broken, I don't actually use any user generated passwords. In addition, gameplay is mostly anonymized. It's not really possible to determine the e-mail of another player, and since game is partitioned into separate worlds, if you get hold of someone's credentials it's unlikely to be someone playing in the same world as you.)

Using https wouldnt protect the game servers directly but could do woners as far as login and lobby systems. With the pro cloudflare you can set the cache to 30 seconds and they have servers all over the world so when people hi the lobby they can bring up the cached version 30 seconds isnt that much of a difference then the cloudflare servers would only touch your server once every 30 seconds. You would probably want to whitelist the cloudflare servers and block anything else through a firewall. Also the nameservers would point to cloudflare not your ip so you can keep your ip for login/lobby not known to the public. You could also have a fall back server or multiple if some get in trouble. You would also have the servers report over https to keep that login/lobby server masked. Overhead would also drop as you dont have to serve https from your server you could serve http and have cloudflare do all the heavy https work.

In my case all of login/lobby/game are plain sockets. No http. That said, it would be possible to convert them to http(s) services. However, cached data would not do. Both login and lobby servers serve personalized results, and for security reasons the login server shouldn't serve the same data twice. Some of the lobby functions might be possible to cache, but player registration - to take one example - obviously wouldn't work.

Or am I missing something?

Well even if the results are personalized cloudflare has more ddos protection than 1 person with limited funding and limited time can do and caching could still be of use just not as much for the personalized results but things like some of the lobbys and player registration(until posted) could be and wouldnt have to touch your server at all. I run quite a few websites and trying to get into the gaming world on my spare time so my answers will definitly be web biased :) but running my own servers cloudflare has opened many doors that would have cost much more and much more time to handle on my own.

And like I mentioned it can handle the ssl so your server doesnt have to which is a major plus because you can quickly kill the server resources with multiple connections on a ddos and it would be much harder to take down a network like cloudflare.

What kind of game are you making is it a mmo or something like fps? Some mmos work entirely over web traffic and some fps use ssl web traffic to login and get going like firefall they use aws.

I personally feel like if its a fps your better off getting high powered servers and trying managing the downtime that comes from my team fortress and css servers theres just not much you can do other than not making it worth the attack.

Packet validation, i.e. verifying CRCs, packet types, etc. and then translating those into game events is fairly lightweight, and the perfect job for a proxy device. It allows you to have a buffer between the players and the game play servers, which allows you to invisibly scale game play servers based on CPU load, and add additional proxies to handle network load.

Well, that depends on the game again. Depending on the setup, you might still be able to scale up game play servers, even without a proxy.

This was already something with could do on the poker servers I mentioned. Basically tables would spawn on all available game server, auto-balancing themselves so the server with the lowest load took on the most new tables. If you added a new game server it would report itself to the lobby and start creating tables. Removing a server was as simple as telling the server not to create any more tables.

This was a very straightforward solution and consequently had very few issues.

Similarly in my game, each game server is really game agnostic. Game worlds are persisted to a db, but held entirely in memory once a game server start "hosting" it. Once gameplay winds down the new state can again be persisted to db. Again, this is very domain specific to my particular game as play is done in short sessions and each game only holds about 100 players.

But I can easily see games that your proxy solution could work great for too.

Because the proxy must be able to send data out, one could use a remote code execution exploit on the open incoming port to launch a process that establishes an outgoing connection to a remote server. At that point I now have the ability to remotely control the proxy server.

Let's say the firewall is a NetBSD installation forwarding ports 6000, 6100, 6200 to three different machines on the local network. This machine again is firewalled from the local network except for the game ports. Typically it's only possible to reach the firewall using ssh from a special machine, everything else is blocked.

It doesn't seem like a trivial hack, breaking into the servers hosting the games (and from those, reaching the db)

Washu:

So your point is that with a proxy I can lock the game servers to a single outbound port which is a big security win, right?

You're basically thinking of an exploit that can go right through the firewall and execute arbitrary code on the machines hosting the game servers. But if you are, then locking the game servers shouldn't be much of an issue. It's a few more jumps to attack the service hosting the db and then onto the db, but there's not really any new kind of obstacle added, is there?

But I am assuming a breach so:

1. Login does not depend on permanent passwords, when you log in with an existing account you need to verify the login using your e-mail. You're the issued a new temporary passcode for that device. In case of a breach, all passcodes can be reset server side with the only inconvenience that the players need to re-authorize. No passwords are leaked.

2. Game server certificates and keys are stored encrypted in the config files, so even with the config files the private keys can't be recovered.

3. Even if the keys are leaked, changing them will only invalidate issued tickets.

4. If the game server private key is leaked that will only enable a MitM attack, as the keys are only used to authenticate the server to a player.

Not perfect, but better than having user passwords in the db.