Game dev #7: Securing accesses
With the bulk of the Minecraft 1.13 update behind us, let's look back at an unexpected issue I faced while moving between the two dedicated servers.
I used the opportunity of migrating the software on a new server to optimize the various config files a bit. One of the changes I did for the Minecraft servers is to have them running on localhost only, as they don't need to be visible to the outside world: only Bungee, the point that ties it all together and is used by the players to connect, needs to be accessible. As such, instead of having the game servers use a public IP address, they only run on a private one. An added benefit is that this matches what I'm using on my PC to run tests, so I can move config files back and forth without editing anything!
A problem I discovered, however, is that this only exposed the related services to the local environment as well. It's possible to use special calls to do things like get the list of players online, the maximum amount of players allowed, or even run commands remotely. However, if the ports for the services aren't opened to the outside world, it's impossible to use them! Things as simple as displaying the list of connected players on the website would no longer work.
To work around this, I ended up writing a simple PHP page on the dedicated server itself that waits for requests. Whenever one is received, it translates it into a game server command and runs it before returning the result. It's able to make the connection as this page is visible both internally and externally, acting as a bridge between the two worlds while keeping the security model intact!
With this new setup, no game ports are visible to the outside. Once in a while, I'll notice that random people (script kiddies?) try to scan the dedicated server for weaknesses. As of now, nothing is opened or accessible without the proper authorization, so these attempts won't even connect!
– Doctacosa