[Security] Server Ignore Attack

[Torres 197]

Hello, friends! I'm very happy to be here for almost 5 years. First of all, I'm very grateful to every developer who has helped me! Salute to you!

Today I'm here to show my server network solution!
This is because the server is always attacked, which makes me very upset...
I usually prepare 3 servers, 1 acceleration (A), 1 backup (B), and 1 to store my game files (C).

When I am attacked and my players are offline, they can choose to log in through another line, because my backup server (B) automatically switches in 5 seconds,
and my previous server (A) will be restored in about 2 minutes, all of which is automatic!

 

If your server has more players, just add more servers.
The server is always invisible, which means that players and attackers cannot directly contact the server, but only contact the peripheral load nodes.
Keep the server always online, this is the advantage of automatic switching!No human intervention is required
The advantages of our automated solution are:
1. The original server is always invisible
2. Improve anti-attack capabilities and security
3. Improve game players' connection speed through distributed network architecture

I used (Mr. TMP4's file) to demonstrate, and I would like to thank him!
If you are interested in this system, please download the client (Mr. TMP4's file, of course I changed some things),
I will give you an account and let you experiment in the game, what will happen when you are attacked? Thank you

Download address:https://files.d9.fit/Demo_Client.zip

MD5:fbdcb8a3379b36ba0a5198769ac9374f  Demo_Client.zip

Edited February 22, 2025 by Metin2 Dev International
Core X - External 2 Internal

[Helia01 3416]

Congratulations, you invented k8s

[Khabib Nurmagomedov 388]

Quite literally nothing new. The official gameforge servers have been doing this ever since 2011 and i would expect major P-Servers to run such thing as well (as far as i remember Aeldra always went back up the second someone attacked it so that kinda explains)

[Matteo 69]

Also more failure points, but good idea. I would simply use NGINX load balancing or just as a reverse proxy. However i don't think its ever neccessary, if your 2 "simple" server get DDoSed, your firewall one would be also down. OVH + a decent PF will keep everything safe  Hard to get down.
  

Also if you seek kind of things, i personally at my bigger projects use OVH's vRack solution to communicate between the servers (copying backups, reaching database (from webserver) or proxying out different services from different machines)

Edited February 23, 2025 by Matteo

[Khabib Nurmagomedov 388]

12 minutes ago, Matteo said:

Also more failure points, but good idea. I would simply use NGINX load balancing or just simply as a reverse proxy. However i don't think its ever neccessary, i your 2 "simple" server get DDoSed, your firewall one would be also down. OVH + a decent PF will keep everything safe  Hard to get down.

Good point! But a solid firewall should also consider in-game actions that could spam the server with requests, like opening a bunch of gift boxes at once, which might still get you rate-limited. I think the smartest approach would be to whitelist an IP when a player first logs in. If the API confirms they’re not a bot or using a blacklisted ASN, they should be free to connect to any game core, making the system both secure and flexible.

Prior to the API whitelisting you into the firewall, any request to the game server should be completely rejected.

You can handle this with Cloudflare if you're hosting your website on a VPS. The VPS should only communicate with Cloudflare, never directly with the person sending the request. Once Cloudflare validates it, the request is processed and access is granted. Cloudflare’s tunnel service (like cloudflared) makes this even easier to set up. (Keep in mind that this is just an example for the API stuff i mentioned earlier).

Also...a nice trick that many do not know is that major botnets will not proceed with the attack if the IP does not ping back(ICMP), so i guess you could also just disable that and that would be one in your buck as well.

Edited February 23, 2025 by Khabib Nurmagomedov

[Torres 197]

6 hours ago, Khabib Nurmagomedov said:

Quite literally nothing new. The official gameforge servers have been doing this ever since 2011 and i would expect major P-Servers to run such thing as well (as far as i remember Aeldra always went back up the second someone attacked it so that kinda explains)

That's right.

1 hour ago, Khabib Nurmagomedov said:

Good point! But a solid firewall should also consider in-game actions that could spam the server with requests, like opening a bunch of gift boxes at once, which might still get you rate-limited. I think the smartest approach would be to whitelist an IP when a player first logs in. If the API confirms they’re not a bot or using a blacklisted ASN, they should be free to connect to any game core, making the system both secure and flexible.

Prior to the API whitelisting you into the firewall, any request to the game server should be completely rejected.

You can handle this with Cloudflare if you're hosting your website on a VPS. The VPS should only communicate with Cloudflare, never directly with the person sending the request. Once Cloudflare validates it, the request is processed and access is granted. Cloudflare’s tunnel service (like cloudflared) makes this even easier to set up. (Keep in mind that this is just an example for the API stuff i mentioned earlier).

Also...a nice trick that many do not know is that major botnets will not proceed with the attack if the IP does not ping back(ICMP), so i guess you could also just disable that and that would be one in your buck as well.

Thanks for your answer

[Koray 3345]

7 hours ago, Khabib Nurmagomedov said:

I think the smartest approach would be to whitelist an IP when a player first logs in. If the API confirms they’re not a bot or using a blacklisted ASN, they should be free to connect to any game core, making the system both secure and flexible.

I completely agree, this is the most basic step when setting up multi layered and effective protection so best approach is to start by setting up a few lightweight and scalable web servers to handle initial connection requests and running them behind a load balancer or if you want something even simpler some serverless solutions like CF Workers or AWS Lambda can do the job just fine. once that’s in place, have the game’s auto patcher establish a handshake with this server to build a basic whitelist and there make sure the game servers only accept connections from whitelisted IPs

CF isn’t just for web servers, it can also help filter game server connections. you can do this with their Spectrum service or if you prefer a more hands-on approach you can use Workers to route TCP connections in a similar way. at this point, you did want to set up preconfigured proxy servers to handle initial connections and making sure only players verified through the patcher can reach the actual game server

If you also want to take it a step further, instead of using a traditional user&pwd login, you can implement a token based authentication system like GF Launcher(preferably using JWT) and the entire connection process can be validated through the token, adding an extra layer of security and flexibility for validation

[Torres 197]

1 hour ago, Koray said:

I completely agree, this is the most basic step when setting up multi layered and effective protection so best approach is to start by setting up a few lightweight and scalable web servers to handle initial connection requests and running them behind a load balancer or if you want something even simpler some serverless solutions like CF Workers or AWS Lambda can do the job just fine. once that’s in place, have the game’s auto patcher establish a handshake with this server to build a basic whitelist and there make sure the game servers only accept connections from whitelisted IPs

CF isn’t just for web servers, it can also help filter game server connections. you can do this with their Spectrum service or if you prefer a more hands-on approach you can use Workers to route TCP connections in a similar way. at this point, you did want to set up preconfigured proxy servers to handle initial connections and making sure only players verified through the patcher can reach the actual game server

If you also want to take it a step further, instead of using a traditional user&pwd login, you can implement a token based authentication system like GF Launcher(preferably using JWT) and the entire connection process can be validated through the token, adding an extra layer of security and flexibility for validation

It seems that several friends prefer to whitelist in the first login, my approach is mainly inclined to malicious attacks, if the player can let our server offline, it must make our file bug or unreasonable Settings, I mainly targeted at hackers attack the server...
Thank you for your answer...

 

[Khabib Nurmagomedov 388]

2 hours ago, Torres said:

It seems that several friends prefer to whitelist in the first login, my approach is mainly inclined to malicious attacks, if the player can let our server offline, it must make our file bug or unreasonable Settings, I mainly targeted at hackers attack the server...
Thank you for your answer...

 

The idea you presented is great and has been used for a period of time, but you might wanna try to prevent attacks as much as possible prior to using a fallback server to keep the game alive, so in a combo both would be great.

[Torres 197]

 

12 minutes ago, Khabib Nurmagomedov said:

The idea you presented is great and has been used for a period of time, but you might wanna try to prevent attacks as much as possible prior to using a fallback server to keep the game alive, so in a combo both would be great.

I quite agree with you, the best of both worlds!

[Matteo 69]

15 hours ago, Khabib Nurmagomedov said:

Good point! But a solid firewall should also consider in-game actions that could spam the server with requests, like opening a bunch of gift boxes at once, which might still get you rate-limited. I think the smartest approach would be to whitelist an IP when a player first logs in. If the API confirms they’re not a bot or using a blacklisted ASN, they should be free to connect to any game core, making the system both secure and flexible.

Prior to the API whitelisting you into the firewall, any request to the game server should be completely rejected.

You can handle this with Cloudflare if you're hosting your website on a VPS. The VPS should only communicate with Cloudflare, never directly with the person sending the request. Once Cloudflare validates it, the request is processed and access is granted. Cloudflare’s tunnel service (like cloudflared) makes this even easier to set up. (Keep in mind that this is just an example for the API stuff i mentioned earlier).

Also...a nice trick that many do not know is that major botnets will not proceed with the attack if the IP does not ping back(ICMP), so i guess you could also just disable that and that would be one in your buck as well.

Why would you do a packet rate limit on an online game? rofl. The only rate limit you should set is connection based, which is not affected by already established connections. Cloudflared is a good idea btw, thanks

[Shogun 5791]

I'm not sure of what is the advantage of this approach. What is this firewall doing that can't be done when you are not being attacked? How much are you inconveniencing the users when under attack?

Whitelisting IPs is a must yet it will only take you so far. The web server(s) themselves must be protected from being DDoSed, and criteria set on who can get whitelisted, and even then attackers can replicate legitimate traffic and go over such line of defense so you must be prepared to deal with a torrent of traffic hitting your actual game server, directly or not.

Even hardware Anti-DDoS solutions, which must be in front of your public facing endpoint nevertheless, can only perform a limited mitigation, because they are not tailored to your particular sort of traffic. Sure you will not be hit by a 40 Gbps DDoS on OVH, but you can still be hit by far more than a vanilla host can handle, and at that point, you must ask yourself how the traffic you want to let in differs from the traffic you do not want to let in, and act in consequence. The answer to this question will be different for each application you are trying to protect, and this is why there is no good general "plug and play" solution.

Then there is the non trivial question of how many resources you can put to the task of filtering that traffic, and whether you have even enough bandwidth to handle it to start with, even after the traffic has gone through the scrubbing center. Overengineer your filtering and you may find the solution is worse than the problem.

In the end, even within your application there will be vulnerable spots, such as a page on your site that directly reads from the database like it's 2005 (the typical "ranking" that's the ddosers favourite), or some feature ingame that did not account for the possibly of automated traffic, here I recall in Metin2 that the guild board could be spammed to the point of overloading the database, which is something that can only be solved within the application as no (external - pf and such) rate limiting is going to slow the attacker down without affecting legitimate users.

Edited February 25, 2025 by Shogun

[Torres 197]

40 minutes ago, Shogun said:

I'm not sure of what is the advantage of this approach. What is this firewall doing that can't be done when you are not being attacked? How much are you inconveniencing the users when under attack?

Whitelisting IPs is a must yet it will only take you so far. The web server(s) themselves must be protected from being DDoSed, and criteria set on who can get whitelisted, and even then attackers can replicate legitimate traffic and go over such line of defense so you must be prepared to deal with a torrent of traffic hitting your actual game server, directly or not.

Even hardware Anti-DDoS solutions, which must be in front of your public facing endpoint nevertheless, can only perform a limited mitigation, because they are not tailored to your particular sort of traffic. Sure you will not be hit by a 40 Gbps DDoS on OVH, but you can still be hit by far more than a vanilla host can handle, and at that point, you must ask yourself how the traffic you want to let in differs from the traffic you do not want to let in, and act in consequence. The answer to this question will be different for each application you are trying to protect, and this is why there is no good general "plug and play" solution.

Then there is the non trivial question of how many resources you can put to the task of filtering that traffic, and whether you have even enough bandwidth to handle it to start with, even after the traffic has gone through the scrubbing center. Overengineer your filtering and you may find the solution is worse than the problem.

In the end, even within your application there will be vulnerable spots, such as a page on your site that directly reads from the database like it's 2005 (the typical "ranking" that's the ddosers favourite), or some feature ingame that did not account for the possibly of automated traffic, here I recall in Metin2 that the guild board could be spammed to the point of overloading the database, which is something that can only be solved within the application as no (external - pf and such) rate limiting is going to slow the attacker down without affecting legitimate users.

Thank you for your answer. My main direction is that GM does not have to solve the server problem manually when there is an attack, but can be deployed calmly, and my plan can be improved