I am no security specialist but here are my two cents based on my findings and expertise as a
backend engineer (web developer).
1. How do you prevent people from DDoS'ing your server? I am interested in another way than Hetzner/OVHCloud/Contabo. I would like to know how do you actually put the server behind a proxy or what's the steps to secure against people scanning for your IP and then DDoS'ing it?
I can't help you much with the DDoS concern since it is a broad security concern that has been tackled by enterprise companies like cloudflare and others and so it is not easy to just give direction unless there is context around a specific issue you’re currently facing.
It is better to just use cloudflare's service to protect your server and website if you have one.
And your host provider matters as well. whether its hetzner, OVH or others, pick one that has proven DDoS protection.
To avoid spamming bots on your website implement captcha, there is reCAPTCHA by Google and hCaptcha, they're both good solutions to use, especially on pages where form data is submitted like the login page and sign up page.
If your website has an API it is also good to implement rate limiting as well.
2. Is there any way to encrypt data that is being sent from server to client?
Based on my reverse engineering findings and the areas I explored (which are limited), the short answer is “No, not really”
The server sends data unencrypted either to the clients externally (connected players) and internally (between different servers; DS<->GS / LS<->DS) and that is by design, if you try to force the server to encrypt data, the client simply won't recognize it and it will stop working.
The client-side is usually the part that sends encrypted data, even though practically they should be both exchanging data that is encrypted bi-directionally.
That is the case for the game client when you attempt logging in, the game client sends its data encrypted to the login server while the server responds with plain unencrypted data.
That is also the case for the OPER_TOOL which I discovered while rebuilding my own version of it.
Even then the encryption that is being applied is useless, because when it was developed, the developers made and used a file called `lump.dat` as a part of the encryption key that is used to encrypt data on the client-side before it's transmitted, both the server and the client have that file.
For the OPER_TOOL it is being the party that is responsible for the encryption key's generation, because the key is simply the data in the `lump.dat` file + elapsed seconds since 1970 (a.k.a. epoch seconds).
If you keep sending the same seconds the server would use it without validating it (e.g., send 1778153070 repeatedly and the server will read the data without any problems and the key and the data shape becomes predictable) and you couldn't rely on anything else as the key since this is hardcoded into the system.
3. Can someone explain what are the steps to securing a server? (Preferably someone that already had a running successful server)
Start with your firewall.
A general rule of thumb when it comes to securing your server, you should only expose ports that are necessary for the player to be able to access your server and block the rest on your system (probably Windows)’s firewall.
The ports that the client uses are as follows:
| Service | Topology | Port | Notes |
|---|
| Maps | TCP | 25001 ~ 25023 | You can find them at /env/ServerEnv.inf |
| MS (messenger server) | TCP | 7411 | - |
| NDLogin_US (login server) | TCP | 48300 | - |
| NDLogin_US (patch server) | TCP | 5001 | Yes, the same executable is exposing two TCP sockets |
| HTTP | TCP | 80 | If you’re hosting your own website or the Apache Web Server to server the GameGuard files and client updates |
| HTTPS | TCP | 443 | If you’re hosting your own website and have an SSL certificate with HTTPS enabled |
Though what is even better is that you change these ports to something other than the default and then whitelist them on your server’s firewall with the same conditions and rules in mind.
The rest should be blocked so that no outsider can access them, emphasizing on the following ports:
| Service | Topology | Port | Notes |
|---|
| DS_Server | TCP | 9999 | This is an internal service that should not be publicly exposed |
| DS_Server (OPER_TOOL) | TCP | 9998 | Only you and your team mates should have access it and even then its still not safe, whitelist your IP addresses for that port so that only you can access it and no outsider can, if an outsider gets a hold of it you’re basically toast, they can spawn items, skills, you name it, without any problem, because there is no form authentication or authorization on that socket, the login process on the OPER_TOOL’s GUI is a client-side auth, it is not enforced or even realized by the server; |
| Microsoft SQL Server | TCP | 1433 (default; check your Microsoft SQL Server Configuration TCP/IP Settings) | If you’re using the OPER_TOOL you will need to expose that port to the users of the tool since it requires a database connection (extremely dangerous and unrecommended) but that is what you’re dealt for now, it is also an internal service to your server so block it from the public |
| Remote Device Service | TCP | 3389 | If you’re accessing your server with Remote Desktop Connection, keep this open only for you by whitelisting your local machine's IP address to that port in the server’s firewall inbound rules; be careful if you don’t whitelist your IP address you will immediately lose access to your server and only get access back by rebooting it to remove the changes made along with system files and data you probably don’t want to lose |
Then block the rest whether its TCP or UDP topologies.
After you’ve applied all of this, it's better to double check by running an nmap scan against your server’s IPv4 address to make sure there are no open ports that should be closed.
And still as I mentioned in the first part of the reply, implement captchas on your website if you have one.
Make sure to change your SQL server's passwords every time you take the server down for maintenance/updates. The files that holds the passwords and sensitive credentials for your server no one should have access to it but you and your team mates.
There are even more security concerns than this, but I won't disclose it publicly so it doesn't get abused.
If you have your own server, I am more than happy to help audit its security for you based on my findings, reach out to me on discord `.chaoxiang`.