For Server Owners

Metin2 Server Security: DDoS Protection and Anti-Cheat Basics

Metin2 Server Security: DDoS Protection and Anti-Cheat Basics

What wears a Metin2 Pvp server down most are disconnects at peak hours and never-ending cheating complaints. No server is completely immune to attacks, but with the right preparation you can shrink an attack's impact and make cheating harder. This guide lays out the basic defensive steps of Metin2 server security, from DDoS protection to cheat prevention, as a checklist.

DDoS protection starts with your provider

In a DDoS attack, your server receives more traffic than its connection or the server itself can handle. Once that traffic reaches your machine, there's very little you can do from inside the server; the real protection happens on your hosting provider's network.

  • Pick a provider that protects game traffic too: Ask whether the protection covers not just your website but also the game ports your players connect to.
  • Find out how the protection kicks in: Always-on filtering and protection that starts once an attack is detected aren't the same; with the latter, you may see short outages.
  • Keep the website separate: Host your site on a different machine from the game server and put it behind a CDN or proxy service. Most of these services only protect web traffic, so the game ports need separate measures.
  • Have an attack plan: Decide in advance on the provider's support channel, where you'll keep players informed and who on the team does what.

Firewall and ports

The basic rule: close everything and open only what's needed.

Service Open to the outside?
Login (auth) and channel ports Yes, players connect to them
Inter-core (P2P) ports No, server-internal only
The db core's port No, server-internal only
MySQL No; if the site is on a separate machine, only to its IP
SSH or remote desktop Only to your own IP address

The PORT, P2P_PORT and DB_PORT lines in the game cores' CONFIG files show which ports are in use. Write your firewall rules based on this list, then scan your own server from the outside to confirm that only the necessary ports are open.

Database and admin access

  • Don't expose the database to the internet: Have MySQL listen only on the local network, and instead of root, create a separate user for the website with rights only to the tables it needs.
  • Change default passwords: Change the database and admin passwords that come with ready-made files on day one. Also check the ADMINPAGE_IP and ADMINPAGE_PASSWORD settings in the game core's CONFIG file: in the source we examined, if the IP list is empty, any address that knows the password can reach the core's remote admin commands.
  • Turn off test mode: With TEST_SERVER on in the CONFIG, every player gets the highest GM level in the source. For GM account security, see our GM rights guide.
  • Harden SSH: Use key-based login instead of passwords, disable direct root login and keep system packages up to date.
  • Use trustworthy files: Ready-made server files and tools of unknown origin can contain backdoors. Get your files from developers you trust and have the code reviewed.

Backups and monitoring

  • Automatic backups: Back up the account, player, common and log databases every day, and keep at least one copy on a different server.
  • Test your restores: A backup that won't open is useless, so restore your backups to a test server at regular intervals.
  • Backups before updates: Take an extra backup before every update and maintenance.
  • Monitoring: Set up a system that watches CPU, memory, network traffic and whether the cores are up, and have it alert you to sudden traffic spikes. Read the cores' error logs (syserr) regularly as well.

Cheat prevention basics

The first rule against cheats: don't trust the client. The more checks run on the server side, the harder they are to get around.

  • Server-side checks: In the source we examined, there are checks for position sync, movement timing and combo attacks; suspicious cases are written to the hack_log table in the log database, and the player can be disconnected. Don't loosen the CONFIG settings for these checks (e.g. SYNCHACK_LIMIT_COUNT, CHECK_MULTIHACK) without a good reason.
  • Client protection: Anti-cheat software helps catch known cheats on the client side, but it's no substitute for server-side checks.
  • Close exploits: Keep your files up to date against known exploits, collect bug reports from players privately and reward the players who report them.
  • Review the logs: Search the log tables for warning signs such as unusual Yang growth, excessive item gains in a short time or lots of accounts created from the same IP.
  • A transparent penalty policy: Write the penalties for cheating clearly into your rules and apply them the same way to everyone.

We explain how players recognize a server with cheat protection in our fair play guide. Smooth, fair gameplay is also the foundation for climbing the best servers ranking, which is built purely on player votes. You can share your experiences with other server owners on the forum.

Frequently asked questions

Is a DDoS-protected server completely safe?

No. Protection reduces an attack's impact, but there's no guarantee it will fully stop every attack. It should go hand in hand with measures such as a firewall, backups and monitoring.

Does the service that protects my website also protect my game server?

Usually not. Web protection services generally cover only HTTP and HTTPS traffic; for the game ports, you need your hosting provider's network-level protection or a separate service that supports game traffic.

How often should I take backups?

At least one automatic backup a day, plus an extra one before every update, is a good start. As your player count grows, back up more often.

Is anti-cheat software enough on its own?

No. Client-side protection catches some cheats; the real safeguard is server-side checks, up-to-date files and regular log reviews.

0 Likes

More posts

Comments 0

No comments yet.