Goal: expose only the services players actually need
This is a defensive deployment review for a host you administer. It does not install a firewall automatically or change your server. Metin2 branches use different ports and process names, so begin with the real configuration instead of copying a port list from another pack.

1. Make a listener-to-owner table
On FreeBSD, inspect active listeners:
sockstat -4 -6 -l

For each entry, write down process, address, port, purpose and intended source networks. Wildcard bindings can include interfaces you did not intend to expose. IPv4 and IPv6 must both be considered. This inspection does not prove external reachability.

Service          Intended callers
SQL database     game/db services on local or private network
Core/P2P links   only the required peer hosts/cores
SSH/admin        designated admin network or VPN
Player service   player clients, only documented ports
Backup endpoint  authorised backup systems only

This is a policy example, not a claim that every branch has all five services.

2. Restrict both bindings and network access
Configure SQL and internal services to listen on the appropriate private/loopback addresses where supported. Enforce the same boundaries in the host/provider firewall. If cores run on separate hosts, permit the specific peers they need; blocking all internal communication can prevent the server from functioning. A non-default port is not a substitute for authentication or access control.

Before applying a firewall change, keep provider/VM console access, preserve the existing rules and prepare a known rollback. Confirm a second administrative connection works before closing the first. Do not paste a generic block-all ruleset over a remote SSH session. Select the firewall implementation you actually run; PF and IPFW configuration are not interchangeable. Follow the FreeBSD firewall handbook.

3. Separate identities and secrets
Use a dedicated game OS account and a database account restricted to the intended schemas and operations. Do not give the game database account administrative privileges simply to make an import work. Replace default credentials shipped in a pack. Keep live configurations, SQL dumps and backup archives outside a web document root and out of public Git history. If a credential was exposed, removing the visible file is insufficient: rotate it and review access.

4. Protect administration without locking yourself out
Use individually attributable admin access and tested SSH keys. Keep a working recovery path before tightening authentication. Review file permissions for private keys, server configurations and backups. Remove unused admin tools and sample web panels; a forgotten panel can expose the database even when its port is private. The FreeBSD security handbook covers host-level administration; exact settings must fit your deployment.

5. Verify from both sides
From an authorised external test host, confirm required player connections succeed and SQL/internal/admin connections are rejected according to the policy. Repeat from the permitted private network, where required peer connections should work. Check both address families and reconnect/restart behaviour. Record timestamp, source network, destination and result. Test only hosts you own or are authorised to assess.

What this does not solve
Network restrictions do not fix an unsafe game packet handler. They also do not create upstream bandwidth protection against a volumetric attack. Track abnormal login failures and connection spikes without logging passwords, authentication tokens or full private payloads. Keep security and capacity claims separate.

This is a sourced operational checklist, not a penetration test or certification of your server. Share a redacted listener/purpose table and the specific access requirement in the discussion, never passwords or public dumps.