release Essential Security Checklist For Your Metin2 Server

[Queen]

Hello everyone,

Having operated a Metin2 server for over a year and a half while facing numerous attempts to undermine it, I’ve gained a solid understanding of what true security entails. After enduring various types of online attacks, I am ready to present a brief guide on how to safeguard your Metin2 server from malicious and disruptive actions. This checklist will be categorized into four main sections: in-game, website, server, and staff security.

While I’ll provide some explanations on how these attacks can be executed, the primary focus will be on effective defense strategies. This guide is not intended for use by malicious individuals.

Remember, complete safety is an unattainable ideal—it’s contingent on the resources and determination of your attackers. Consider this checklist as a foundational step. Keep in mind that the landscape of security is ever-evolving; what seems secure today may not be tomorrow.

Disclaimer: This guide is based on five years of experience managing server technicalities. Note that I haven’t engaged in certain activities (like quest creation) for quite some time, so please excuse any errors.

---

Part 1 - In-Game Vulnerabilities and Exploits

This section addresses threats that arise through the game client or external applications that interact with it.

While often underestimated, in-game exploits can pose a greater risk to your server than many other forms of attack. Monitor your server’s economy—especially item prices. A sudden spike or drop in the price of specific items could indicate an exploit. This is one reason we maintain both public and private records of average market prices for all items at WoM.

A frequent pitfall is inadvertently allowing an item to return more yang when sold to an NPC than it costs to purchase from a shop. This creates an opportunity for infinite yang exploitation by those who discover the loophole. Some even use automated bots to exploit these items, wreaking havoc on the economy over time. It is crucial to have your Game Masters verify that no item can be sold for more than its purchase price.

Players can also exploit poorly designed quests to repeat their rewards by closing their clients while the quest dialogue is still open. A straightforward way to prevent this is to ensure that the commands rightfully rewarding the player are the last executed in the code block before transitioning states.

Disruptive behavior is often showcased through bugs that lead to server crashes, such as the infamous number_ex bug. This flaw affects commands that rely on its function, making it exploitable with specific parameters. This bug has been resolved in version 40k and subsequent compilations. If you're running version 34k, it’s advisable to employ iMer’s library, which includes multiple security enhancements. For version 2089, you can find public patches.

Another notable issue resides within the war command in version 34k and earlier, which may also cause server crashes. Since this command is essential for guild leaders to initiate wars against other guilds, disabling it isn’t an option. However, iMer's library addresses this bug in 34k.

A lesser-known, yet equally concerning issue involves a gold drop bug present in version 2089 but fixed in 34k. Dropping substantial amounts of gold or other mass-items can crash the server. Unfortunately, I am unaware of any public fixes for this exploit.

The kickhack or sync position hack (partially patched only in 40k) is another exploit that grants an attacker the ability to disconnect other players at will—there are even videos showcasing this from years past. Thankfully, iMer’s library also provides a fix for this in rev 34k.

Finally, there exists a range of cheats aimed purely at gaining unfair advantages during gameplay. Numerous client protection tutorials and services can be found on various forums, so I won't delve deeper into this topic here.

---

Part 2 - Securing the Server and Operating System

This part examines threats impacting your server and operating system.

Part 2.1: Selecting and Preparing Your Server

As of this writing, OVH stands out as the most cost-effective provider of DDoS protection services. While many companies offer such services, their high costs often don’t correlate with enhanced protection. For this guide, we’ll consider either a dedicated server from OVH or a VPS from Eterhost, which I’m familiar with. Other providers may have different configurations.

Dedicated Server at OVH

OVH provides two versions of its Anti-DDoS solution: Basic and Pro. The Basic level is free for Kimsufi or Soyoustart servers. It detects attacks targeting your IP address and filters your traffic through its mitigation system, but for serious threats, this level may not suffice; your server could still collapse temporarily before an attack is detected.

The Pro version included with professional OVH servers allows for permanent traffic routing through the mitigation system and comes with a hardware firewall. If you are concerned about serious attacks, this version is recommended.

To activate permanent mitigation on OVH Professional servers:

1. Open the new manager. If you’re unsure where to find it, open the classic manager, click on "Home," then under it, click the "Dedicated" icon.
2. Select "IP" from the left column.
3. Click on the settings icon next to your server’s IP address.
4. Choose "Mitigation: permanent."

To set up the hardware firewall:

1. Click the settings icon again and select "Activate firewall." Wait roughly one minute and refresh the page.
2. Click on the settings icon and select "Configure firewall."
3. You will see a rules screen where you can add up to 20 rules for allowing or denying specific ports. Start with allowing lower-numbered ports and conclude with a global deny rule. Leaving a field blank defaults to a wildcard—meaning entering a blank IP address affects all IPs.

Example of Adding Ports:

• To permit a port: Choose "Add Rule," select rule priority, choose the protocol (TCP or UDP), select "Accept," and enter the port number.
• For a global deny rule: Choose rule priority (must exceed that of previously allowed ports), select the protocol (TCP or UDP), and choose "Deny."

Make sure to include the SSH port and the game and authentication ports, along with MySQL port 3306 for web connections. For added security, I recommend specifying the web server’s IP in the firewall rules to restrict database access, although I typically prefer restricting access through the software level via the pf firewall.

If you’re using Navicat for MySQL access, simply use the SSH Tunnel option, which allows you to log in via SSH and connect to the MySQL server as localhost. You’ll enter your server's SSH login information in the SSH section and your MySQL credentials in the General tab, ensuring that you connect as localhost (127.0.0.1)—not your public address, as this will indicate a local connection.

Regarding UDP, it’s best to disable this protocol entirely, as was done in the rules above. The official client previously relied on UDP for server status checks, but it’s trivial to manipulate it in Python to return "NORM" regardless of the server’s real status. If you’re operating version 40k or later, the check should already utilize TCP, provided your port numbers are under 32768.

VPS from Eterhost

Our VPS servers are routed through a mitigation system by default, and a hardware firewall can be activated for an additional 5€/month.

Part 2.2: Securing SSH

First and foremost, ensure your operating system is always updated to the latest version.

Experts often recommend accessing your server through a non-administrative account. Some systems like CentOS require this during installation. We will create a restricted user for our game server:

adduser game
    

Leave all settings as default, except for the login group—assign it to "wheel." Members of this group can use the su command to gain administrative access, allowing us to disable root remote logins fully.

Next, we will create an SSH key for the new user, thereby making brute-force attacks nearly impossible.

To restrict root login and logins without a key, edit the SSH configuration:

ee /etc/ssh/sshd_config
    

Locate the "PermitRootLogin" line and change it to:

PermitRootLogin no
    

Then, locate "PasswordAuthentication" and modify it to:

PasswordAuthentication no
    

Now, restart the SSH service for the changes to take effect:

service sshd restart
    

Caution: At this stage, it’s wise to open a new PuTTY window to ensure you can log in with the new user and key and utilize the su command to gain root access. Incorrect configurations can lock you out of your server.

Once confirmed that everything is functioning correctly, upload your server files to /home/game, which serves as the user’s home directory—similar to "My Documents" on Windows. Ensure you adjust permissions so that the "game" user can read and write to these files:

chown -R game /home/game
    

(This command should be executed by the root user, as only root can modify another user's permissions.) To switch between the game and root accounts, use the su command:

root# su game
Password: (game user's password)

game# su
Password: (root user's password)

root#
    

Alternatively:

root# su game
Password: (game user's password)

game# exit

root#
    

It might also be prudent to install ssh-guard for additional security, or change your SSH port if you wish to reduce log noise from port scans. To change your SSH port, modify the Port line in /etc/ssh/sshd_config, and remember to restart the SSH service as mentioned above. Ensure the new port is opened in your firewall to avoid locking yourself out.

Part 2.3: Implementing a Software Firewall: pf

At this juncture, it’s advisable to introduce a secondary layer of defense with the pf firewall. First, we’ll create the /etc/pf.conf file, following this sample configuration.

ee /etc/pf.conf
    

Be sure to include the correct network interface and to open necessary ports—SSH and game ports in this instance. Avoid exposing P2P or database core ports to the public. Under the trusted_hosts section, include your web server’s IP address so it can communicate with the database (assuming a common setup of a web server alongside the game/database server), rather than opening port 3306 to all users.

This firewall provides us with advanced scrubbing and rate-limiting capabilities that the hardware firewall does not offer.

Next, activate pf:

kldload pf
pfctl -e
    

Once everything is functioning correctly, add the following line in /etc/rc.conf to enable pf at startup:

pf_enable="YES"
    

---

With these security measures in place, you should have a solid foundation to protect your Metin2 server from various threats. Always remember, vigilance and continual improvement are key to maintaining overall safety.

 

Author

Shogun