Jump to content

Tim

Inactive Member
  • Posts

    13
  • Joined

  • Last visited

  • Feedback

    0%

Posts posted by Tim

  1. 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
    
    • Love 4
  2. 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.

  3. @iRemix, no "pkg_add" isn't rly secure, cause it won't compile the mysql files, so if the host uses modified kernels it could be, that the mysql bin doesn't work anymore with this kind of install!

    [...]

    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, ...)

    [...]This way the software will be optimized for your particular setup.

    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)
    • Love 2
  4. Hello dear community,

     

    because I'm in worry to exclude myself from my server, I wanted to ask you to check my rules:

    IPF="ipfw -q add"
    ipfw -q -f flush
    
    #loopback
    $IPF 10 allow all from any to any via lo0
    $IPF 20 deny all from any to 127.0.0.0/8
    $IPF 30 deny all from 127.0.0.0/8 to any
    $IPF 40 deny tcp from any to any frag
    
    # statefull
    $IPF 50 check-state
    $IPF 60 allow tcp from any to any established
    $IPF 70 allow all from any to any out keep-state
    $IPF 80 allow icmp from any to any
    
    # ssh
    $IPF 90 allow tcp from any to any 22 in
    $IPF 100 allow tcp from any to any 22 out
    
    # ports used by server
    $IPF 110 allow tcp from any to any 13001 in
    $IPF 120 allow tcp from any to any 13001 out
    $IPF 130 allow tcp from any to any 11002 in
    $IPF 140 allow tcp from any to any 11002 out
    $IPF 150 allow tcp from any to any 13099 in
    $IPF 160 allow tcp from any to any 13099 out

    And I want you to ask how I can manage that my webserver can use port 3306?

     

    Regards

     

    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.

  5. That's not all. Edit /etc/libmap.conf and /etc/make.conf.

     

    Tutorial:

    http://www.freebsd.org/doc/en/articles/custom-gcc/article.html

     

    You can just edit the Makefile to use gcc48.

     

    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

    • Love 2
  6. I want to apply the changes on the source directly instead of letting others patch it. You can still patch, if you want, but if you have any wishes you can just ask, I want to adapt the core to the communities needs. You won't need dif's if you can fully customize the gamecore.

     

    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

     

    vanilla_core_2_1:
    
            libstdc++.so.6 => /usr/local/lib32/metin2/libstdc++.so.6 (0x28593000)
    
            libm.so.5 => /lib/libm.so.5 (0x28690000)
    
            libmd.so.5 => not found (0)
    
            libz.so.6 => /lib/libz.so.6 (0x286b2000)
    
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x286c6000)
    
            libthr.so.3 => /lib/libthr.so.3 (0x286d1000)
    
            libc.so.7 => /lib/libc.so.7 (0x286f3000)
    
    vanilla_dbcache:
    
            libstdc++.so.6 => /usr/local/lib32/metin2/libstdc++.so.6 (0x2811c000)
    
            libm.so.5 => /lib/libm.so.5 (0x28219000)
    
            libz.so.6 => /lib/libz.so.6 (0x2823b000)
    
            libthr.so.3 => /lib/libthr.so.3 (0x2824f000)
    
            libc.so.7 => /lib/libc.so.7 (0x28271000)
    
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x283db000)
    
    vanilla_core_2_1:
    
            libstdc++.so.6 => /usr/local/lib32/metin2/libstdc++.so.6 (0x28593000)
    
            libm.so.5 => /lib/libm.so.5 (0x28690000)
    
            libmd.so.5 => /usr/local/lib/compat/libmd.so.5 (0x286b2000)
    
            libz.so.6 => /lib/libz.so.6 (0x286ca000)
    
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x286de000)
    
            libthr.so.3 => /lib/libthr.so.3 (0x286e9000)
    
            libc.so.7 => /lib/libc.so.7 (0x2870b000)
    
    vanilla_dbcache:
    
            libstdc++.so.6 => /usr/local/lib32/metin2/libstdc++.so.6 (0x2811c000)
    
            libm.so.5 => /lib/libm.so.5 (0x28219000)
    
            libz.so.6 => /lib/libz.so.6 (0x2823b000)
    
            libthr.so.3 => /lib/libthr.so.3 (0x2824f000)
    
            libc.so.7 => /lib/libc.so.7 (0x28271000)
    
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x283db000)
    

  7. and the syslog?

    my sysser of auth

    SYSERR: Feb  7 17:58:08 :: socket_bind: bind: Address already in use
    SYSERR: Feb  7 17:59:23 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 17:59:26 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 17:59:29 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 17:59:32 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 17:59:35 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 17:59:38 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 17:59:42 :: socket_bind: bind: Address already in use
    SYSERR: Feb  7 17:59:53 :: socket_bind: bind: Address already in use
    SYSERR: Feb  7 18:00:24 :: socket_bind: bind: Address already in use
    SYSERR: Feb  7 18:03:14 :: hupsig: SIGHUP, SIGINT, SIGTERM signal has been received. shutting down.
    SYSERR: Feb  7 18:03:14 :: pid_deinit: 
    End of pid
    
    SYSERR: Feb  7 18:06:33 :: socket_connect: HOST localhost:15000, could not connect.
    SYSERR: Feb  7 18:07:18 :: SetBilling: cannot find login key 0
    SYSERR: Feb  7 18:12:58 :: socket_bind: bind: Address already in use
    SYSERR: Feb  9 08:19:58 :: hupsig: SIGHUP, SIGINT, SIGTERM signal has been received. shutting down.
    SYSERR: Feb  9 08:19:59 :: pid_deinit: 
    End of pid
    
    SYSERR: Feb  9 08:22:09 :: SetBilling: cannot find login key 0
    SYSERR: Feb  9 08:46:24 :: hupsig: SIGHUP, SIGINT, SIGTERM signal has been received. shutting down.
    SYSERR: Feb  9 08:46:24 :: pid_deinit: 
    End of pid
    
    SYSERR: Feb  9 08:51:14 :: SetBilling: cannot find login key 0
    SYSERR: Feb  9 11:15:44 :: socket_bind: bind: Address already in use

    If i extract the archive with the IV and i put type 2 or 1  or 0 this works.

    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

     

  8. 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

    • Love 3
  9. That's right, you need the key to decompress them.

     

    To generate an iv file the easiest way is to go here:

     

    http://www.random.org/bytes/

     

    Enter 32 in the byte field and Download as file, you got an iv file now.

    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.

    • Love 5
×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.