Sign in to follow this  
Awoken

performance vs security with socket.io and messenger

Recommended Posts

I'm currently trying to figure out how to set up my game node.js server(s).  I'm going to take the advice of Khawk and host the game server and website server on two different VPS'.

I'm thinking of having a relay server which acts as a go between the client and game logic server (GLS). The relay server will rely on socket.io to receive and emit data between the clients and GLS.  The relay server will use messenger to receive and emit data to the GLS.  I was thinking of using the relay to authentic the data coming in before sending it off to the GLS.  

Now my concern is that this may slow down the communication between the clients and GLS.  I'm also taking a shot in the dark thinking this may provide more security for the GLS?  

Anyone have any comments on my proposed approach, or advice?

Share this post


Link to post
Share on other sites
There may be more security from the game logic server, if you don't give it an external IP address, so it can't be found at all on the internet.
However, if you have a hole in your relay server, then that hole can be used to jump into your network, and from there, a determined attacker can then get to the game server, and if the game server is not hardened like it would be if it were exposed to the public internet, you're in more trouble than you might be if you considered the game server as public.
Also, there is the cost of running three servers instead of two.

For a small game, OR for a game where "seamless server transition" isn't necessary, I'd rather just expose the game servers directly than use a gateway/proxy/relay.
Fewer things to go wrong.

Share this post


Link to post
Share on other sites

I'd rather just expose the game servers directly than use a gateway/proxy/relay.
Fewer things to go wrong.

Yes, this is what I'm going to have to do.  I'll have to redirect GLS requests to a specific IP address.  How would I go about 'Hardening' the host server?  I'm currently looking into how to implement CA's and using https.  

messenger asks for speaker and listener IP addresses.  I could get the relay server which hosts the website to relay to and from the GLS, the relay server could utilise https.  Should I also have it set up so the GLS and relay server use https to communicate between each other? 

Edited by Awoken

Share this post


Link to post
Share on other sites

How would I go about 'Hardening' the host server?


In theory, hardening is a simple mixture between good configuration, good software, and good operational practice:

- Don't run any services you don't need to. Typically, this means just running a SSH server and your specific game server. Other services, like a local caching DNS server, is generally not a good idea!
- Don't allow connections to management interfaces from the greater internet. For example, if you have a private network, don't allow SSH connections from public addresses, only from private addresses.
- Enforce access rules both in configuration files (assuming your servers have configurations for which addresses/interfaces they bind to) as well as using host-level filtering (iptables on Linux, Windows Firewall on Windows.)
- Be fast about patching as soon as security updates are available for your OS and for servers you didn't write yourself.
- For software you write, make sure that you check the size and validity of each packet. If a field of a UDP packet says "there are 312 bytes of user name" but you only received 270 bytes total, that's a bad packet. Beware signed values (char is signed and may be negative!) and test all code with all extreme edge case values.
- Religiously read the logs from your server. When there is a new kind of log message you haven't seen before, research what it is and why you see it. Classify log messages into exactly two classes: "can be ignored at runtime, but useful for post-mortem debugging" and "needs human attention pronto." If some log is not useful and doesn't indicate a problem, AND you know what it means, then configure/filter that specific message out.
- Keep a constant eye on metrics such as CPU load, RAM usage, network ingress/egress, CPU temperature, disk space, disk I/O rate, swap usage, and so on. Set alerts when they fall outside normal bands.
- Inside your private network, still enforce access with SSH keys, use TLS where possible, etc. Only allow cross-host connections that make sense. For example, if you have application servers, and game servers, and database servers, the game servers should not be allowed to access the database servers, but should have to go through the application servers. Enforce these rules with network filtering. Another good example is SSH command line access; typically you have a "bastion" host that you can SSH into, and SSH to other hosts is only allowed from that host and some spare/backup host. SSH directly from a game server host to an application server host would indicate a non-standard use, which should be disallowed.
- Keep track of what traffic you see internally. If there is a new protocol or new pair of hosts talking that you haven't seen before and don't expect, alert and investigate!

When you actually get to implement this in practice, you will find that certain practices or requirements will conflict -- maybe the ability to quickly patch servers means that your servers need to be able to SSH outside of your network to grab those patches, but you don't generally want to allow SSH out from the servers to the greater internet. Or maybe there is a traditional "features versus security versus schedule" conflict. How you deal with those determines your culture.
I can say that starting to do these things early is, in the long run, much easier than trying to come from behind later. If you have a mess of internal connections and millions of unaudited log messages per day, trying to bring order is a massive undertaking. On the other hand, if your game sucks because you spent all time on hardening and not on gameplay and polish, then all that hardening work was wasted (other than as a learning excercise.)

Share this post


Link to post
Share on other sites

 

At first your post intimidated me, but then as I read through and began to understand each point I was like 'Oh yeah, I get that, makes sense..'  Thank you for all your feedback.

So far I've got my development version of relay server working with database support, webpage instances, third party encrypting and salting support and other features I need for my website/game.  One point that I wanted to touch on; soon here, sometime next month, I'll be running this server on a Virtual Machine.  I noticed that node.js comes with a whole host of modules packed in, many of which I won't be using. For added security, would you recommend I only install those modules and dependencies I'll be needing, maybe this is a no-brainer, but I'm just making sure it's worth the extra hassle?

Share this post


Link to post
Share on other sites

For added security, would you recommend I only install those modules and dependencies I'll be needing, maybe this is a no-brainer, but I'm just making sure it's worth the extra hassle?


If you can get away with having less software on the box, then you should! Less to break, less to use for an attacker, less to configure/manage/upgrade.

The risk of having a module installed, but not used by your program, is small, but not quite non-zero. Specifically, if an attacker manages to inject code that your Node process runs, AND one of the installed-but-not-used modules have a security hole, then the attacker could load that module and use it to try to break out of the Node.js process. This is somewhat far-fetched, but, as I said, non-zero risk. Whether mitigating this risk is worth it depends on how expensive it is for you to not install these bits, and how bad you think it would be if this risk ended up in a problem.

Security isn't really a "100% all the time" thing, anyway. The most secure computer is the one that's turned off and locked into a vault with no contact with the outside world. To actually get value out of the computer, you must lower those defenses, and the return on investment calculation is "how much return will I get by doing this, versus how much exposure do I add, and how bad would it be if that exposure got exploited?"

Share this post


Link to post
Share on other sites

Security isn't really a "100% all the time" thing, anyway. The most secure computer is the one that's turned off and locked into a vault with no contact with the outside world. To actually get value out of the computer, you must lower those defenses, and the return on investment calculation is "how much return will I get by doing this, versus how much exposure do I add, and how bad would it be if that exposure got exploited?"

That's just it.  I'm thinking this is all good to know, but at the end of the day I'll be lucky if I can get a hundred people playing this thing.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this