Tim

The original config (and the modified one too!) uses states to keep track of open connections. The state table however, is by default limited to 10000 entries (FreeBSD 10.1 amd64), which could lead to problems during medium-/large-scale attacks, since new connections will be dropped once the table is full. I usually use the following memory pool limits for PF: set limit { states 100000, frags 20000, src-nodes 100000, table-entries 200000 } Raising the table-entries limit is also a good idea if you have dynamically filled tables of "bad hosts", same goes for src-nodes. It's also recommended to have a few whitelisted static IPs, whose traffic is passed unconditionally and stateless. e.g.: table <ovh> const { 213.186.33.13, 213.186.50.100 } pass in quick on $ext_if from <ovh> to any no state

These "evil"-process checks are prone to false positives (or different definitions of "evil") and too easily bypassed. Also I consider killing other processes bad practice (even if they're "evil"). Not even XTrap / HackShield do this. To the file checks: Why delete these files? If you don't want your client to load e.g. loginInfo.py, then remove the relevant code from your shipping client (or use the new xml-based loginInfo). Or hard-code the pack list if you don't want people to mess with it. Same goes for Miles and its extension modules. Most of these checks are vulnerable to race conditions anyway (e.g. I can use the time between the check for *.mix files and Miles actually trying to load all of them) PS: You should really add a call to time.sleep() to your loop. Currently you're spending a huge amount of CPU time on these checks which will surely cause problems for users with low-end hardware.

That would only be an issue if you had changed APIs. Since just building an own kernel with special options/built-in drivers doesn't do that, there's no reason not to use the binary packages unless you need to change config. options (less dependencies, extra features, ...) Only if you added extra optimization flags (eg. -Ofast etc.) to your /etc/make.conf (which isn't recommended since you can break ports that are incompatible with the settings you added)

If you have the source installed, you can find the default sshd_config in /usr/src/crypto/openssh/sshd_config Otherwise download it from here (for FreeBSD 9.2): [Hidden Content]

What I don't understand is: Why do so many people copy the source to /usr/src ? This directory is used for the FreeBSD source code and normally you don't put your own stuff there.

The rules should work the way you have them. But unless your server is to act as a router, you don't need to use "any to any" in rules like #70, #80+ If you add keep-state to all rules, you can even replace the allow in #60 with deny to catch some spoofed ACK packets. You should however note that ipfw's state table can (much like pf's state table) become full, which will take your server offline. The max. number of state table entries can be changed with the net.inet.ip.fw.dyn_max sysctl. My version of your ruleset would look like the following: IPF="ipfw -q add" ipfw -q -f flush # Loopback interface $IPF 10 allow all from any to any via lo0 $IPF 10 deny all from any to 127.0.0.0/8 $IPF 10 deny all from 127.0.0.0/8 to any # As noted above, this can be changed. # You can either get rid of the state table completely, which will require you to open ports like 53 (DNS) for returning traffic # or you can change all rules to use the state table. # The third option is to just keep it as-is, which will probably be the best if you don't want to bother with all this. $IPF 50 check-state $IPF 55 deny tcp from any to any frag $IPF 60 allow tcp from any to me established $IPF 65 allow all from me to any out keep-state # Allow incoming ICMP (ping etc.) packets # Outgoing ones are already handled by #65 $IPF 100 allow icmp from any to me # Open SSH to general public $IPF 110 allow tcp from any to me 22 # Whitelist # 172.19.22.167 can only access the mysql port # 10.33.184.22 can access everything $IPF 150 allow all from 172.19.22.167 to me 3306 $IPF 151 allow all from 10.33.184.22 to me # Opens the game port range 13000-14000 # Obviously your dbcache and p2p ports shouldn't be part of this range $IPF 200 allow tcp from any to me 13000-14000 If you're afraid of locking yourself out, try using /usr/share/examples/ipfw/change_rules.sh to edit your ruleset.

The article only applies to the ports tree. For Metin2 it is already enough to edit the Makefiles and replace c++ with g++48 etc. The runtime linker will be able to find and use the libs from your gcc48 installation. You only need to add rpaths or use ldconfig if you plan to use your compiled binaries somewhere where you don't have gcc48 installed. Kind Regards, Tim

I don't think he meant binary diffs. He was probably referring to "traditional" source patches that are generated using diff(1) and applied using patch(1) btw: Is there any reason why you are using RAR instead of one of the more popular formats (tar, zip) that are supported out-of-the-box by FreeBSD ? btw2: It seems like you need to install misc/compat9x to run the game on FreeBSD10

what does ldd game say?

and the syslog? But type 3 doesn't work? (The other types are irrelevant, they have nothing to do with the IV file) socket_bind: bind: Address already in use Your auth server seems to be already/still running

What's in your auth server's syslog/syserr? Does extracting the archive again work? Kind Regards, Tim

I'd just use GCC 4.8 and ship the necessary libraries (libstdc++, ...) with your released game. Using the -rpath Linker-Option you can force the loader to search one of your custom library-paths first, allowing you to leave libmap.conf / ldconfig unchanged. The user just needs to place all custom libraries into this directory, which shouldn't be too hard. Example: (Obviously I use /usr/local/lib32/metin2 for my libraries) [...] -Wl,-rpath,/usr/local/lib32/metin2 Kind Regards, Tim

The archiver can generate an IV file too. Just point IvPath to a non-existent file and it will be created for you. Kind Regards, Tim PS: Just setting an IV path does not cause all files to be encrypted. You still need to use type 3 / PANAMA.