Fast & Easy Security guide for Minecraft servers

Discussion in 'BungeeCord Discussion' started by LinsaFTW, Mar 20, 2018.

  1. This guide is meant to be a Fast & Easy guide for non-programmers to protect their servers and know how exploits basically work.
    Don't use plugins for Firewalling

    People tend to use plugins for Firewalling like IPWhitelist, OnlyProxyJoin, etc... when hosting a BungeeCord Network.

    This plugins aren't really safe because they are not denying connections completelly to your server and in the worst cases this can be bypassed (by fowarding a null address) and let exploiters to UUIDSpoof you by forwarding Spigot with a selected UUID. (ex: A player called "haxxor" changes his UUID to yours to get your permissions) [Forwarding Spigot invalid addresses/uuids can only be done if Spigot has bungeecord: true wich is a necessary function for BungeeCord networks]

    A real solution is to install a Firewall in your server, you need a linux system for this. You can use IPTables or UFW (I personally recommend UFW because it helps you manage IPTables easier for begginers) (For servers with multiple machines you would need to make a special ruleset to only allow access from your machines)

    Or set your Spigot servers addresses to 127.0.0.1 so only your BungeeCord that is in the same machine can access them.

    If for some reason you can't use this methods keep using plugins for firewalling but this is not recommended.

    A little Firewalling tutorial for UFW

    Im going to give you up some tips for UFW as its my personal selection. (You can replicate this for IPTables with different procedures)

    Command to install UFW (Uncomplicated Firewall)

    sudo apt-get install ufw

    Go to /etc/ufw/ and open the file before.rules ad add the following rules:

    Add this lines after *filter to use rate limiting.

    Code (Text):
    *filter
    :ufw-user-limit - [0:0]
    :ufw-user-limit-accept - [0:0]
    Add this lines to open your 25565 port ratelimited by 10 connections in 1 second. (You can modify this as you like)

    Feel free to add as many ports as you want to open.

    Code (Text):
    -A ufw-before-input -p tcp --dport 25565 -m conntrack --ctstate NEW -m recent --set
    -A ufw-before-input -p tcp --dport 25565 -m conntrack --ctstate NEW -m recent --update --seconds 1 --hitcount 10 -j ufw-user-limit
    -A ufw-before-input -p tcp --dport 25565 -j ufw-user-limit-accept
    Run this command in the Linux console to open the SSH port limited by 6 connections in 30 seconds:

    sudo ufw limit ssh

    If you're using RedisBungee run the following command to allow only your BungeeCord machines to connect your servers:

    sudo ufw allow from <bungee-ip> to any port <port-of-your-spigot-server> proto tcp

    After finishing setup this run the following commands:

    sudo ufw enable
    sudo ufw reload


    You can block ICMP Packets to prevent ICMP Packet flood. (pinging from windows cmd, with sometimes causes lag)


    Add this lines to /etc/ufw/before.rules

    Code (Text):
    # icmp flood
    -A ufw-before-input -p icmp --icmp-type echo-request -j DROP
    -A ufw-before-input -p icmp -m icmp --icmp-type address-mask-request -j DROP
    -A ufw-before-input -p icmp -m icmp --icmp-type timestamp-request -j DROP
    -A ufw-before-input -p icmp -m icmp --icmp-type 8 -m limit --limit 1/second -j ACCEPT
    Preventing Crashes and other Exploits

    Crashes are caused for multiple reasons, i will recommend ExploitFixer and FlameCord for protection because i developed them and i personally think that they are the best free option for Exploit fixing at the moment.

    ExploitFixer protects you from the following exploits:

    · CustomPayload packets with big book data used to overload the server and lag it.
    · UUIDSpoof that is used on non-firewalled servers with bungeecord: true by connecting to a Spigot instance and forwarding a invalid UUID/Address.
    · NullAddress its a exploit used to bypass ipwhitelist by forwarding a invalid address and making it return a server error
    · Commands that some plugins have and can crash your server are blocked by ExploitFixer.
    · Items are remade by ExploitFixer to prevent invalid Hacked Creative Items. (Players with creative mode can create any kind of item by sending a packet)
    · Packets that accomplish certain conditions (ex: sending big book data) will be blocked from the server to prevent lagging your network. (ExploitFixer protects you from every packet possible sent by players)
    · Signs created by hacked clients that have extra lines to crash your server.

    Download ExploitFixer

    Netty is the API used by BungeeCord to establish connections with players.

    Netty Exploits are exploits that lag the Netty threads to make the BungeeCord stop accepting connections. (ex: generating exceptions to prevent the connection from closing until timeout)

    FlameCord simply fixes Netty Exploits by following this procedures:

    · Flush() before closing a connection. (Closing them normally seems to keep the connection instead of closing it)

    · Close on invalid request. (If a invalid request is done FlameCord closes the connection)

    · Close on exception. (If a exception occurs because invalid data is sent FlameCord will close the connection)

    Preventing Bot Attacks

    To prevent bot attacks i personally recommend using this plugin.

    My Server IP: play.arkflame.com
    2LSpigot Discord: https://discord.gg/cjt9bPA

    Did i forgot something? Let me know in the thread comments!

    DISCLAIMER: I am the developer of ExploitFixer, FlameCord and AntiBot, my intention by promoting those is to give you the best protection plugins available for free at the time.​
     
    #1 LinsaFTW, Mar 20, 2018
    Last edited: Feb 14, 2020 at 6:38 PM
    • Like x 14
    • Useful x 6
    • Winner x 2
    • Informative x 2
    • Agree x 1
    • Friendly x 1
  2. Very nice and usefull!

    As addition i'd like to mention another usefull service if you are running a linux host, and that is Fail2Ban.
    Fail2Ban can help you prevent hack attempts (bot server, people with wrong intentions, etc..).
    It can keep track of failed login attempts on pre configured services like SSH to detect brute force attacks, and as countermeasure create an IP Tables packet drop rule for x amount of hours or permanent, so that for example if a server bot is bruteforcing your SSH port, and reaches the preconfigured threshold (let's say 5 failed attempts within 5 minutes?) it won't be able to reach your server at all for the upcomming 5 hours.

    Another thing i'm missing is what to do when you have one proxy and are hosting your servers on multiple dedicted hosts.

    My Advice would be using ufw to secure the connection to those server, like on your second host you will have to have the ports for those servers accecible by the proxy server. The best way to do this is to open the ports on the second server, only for data comming from your proxy server
    ufw allow from <IP ADDRESS> to any port <PORT NUMBER>
    This way only the proxy can send data to those server, so only people who are playing through your proxy can access the servers. This prevents hackers from setting up a proxy themself and adding your servers to their proxy list, and joining through their proxy, and thus be able to use offline mode to impersonate you or one of your staff members and gain access to critical plugins! (Also when you are hosting your servers on the same machine as your prexy, never open up their ports for public access through the firewall!)
     
    • Like Like x 1
  3. Im going to test it and maybe i will add it :) Thanks.
     
    • Like Like x 1
  4. How is this even close to max security? Setting localhost in the server.properies file does not work on redisbungee servers & a simple ufw firewall with a 25565 limit is nothing. I don't think you understand how proxies work other than a proxy running on the same server. I would recommend looking into actual linux sec rather than posting a garbage infosec post where the bungee iptables firewall rules located in the docs are as basic as it gets, but provide more information than this.

    I don't even want to know what your network backend looks like...

    Basically worse than a digital ocean tutorial.
     
    #4 Cisnet, Mar 20, 2018
    Last edited: Mar 20, 2018
    • Agree Agree x 4
    • Funny Funny x 1
  5. Looks good, doing most of it already. Have my server port set to allow instead of limit though so I'll most likely be changing that soon. :)

    Another thing I like to do to protect against console access is install two-factor authentication:
    Code (Text):
    apt-get install libpam-google-authenticator
    Best walk through I've found for installing it is here. May or may not be worth the risk though, depending how prone you are to losing or breaking your phone. I'd recommend taking a screenshot of the QR code and keeping it on a USB drive just in case.
     
    • Agree Agree x 1
  6. This guide is meant to be for Normal Bungee and Spigot servers, not for Redis Setups.

    It is a "Super Easy" guide, i just wanted to share this for people that needs a good protection ASAP.

    For redis you should only allow 25565 in the proxy and then allow the ip of your proxy server in your dedicated with the spigot servers.

    Hmmm... Maybe im going to write how to setup firewall for redis...
     
    • Informative Informative x 1
  7. This is the most stupid and pointless security guide I've seen on this forums so far. Half is nonsense and the other half is forgotten.
    If this is how your own network is setup then I would highly suggest you to actually do your homework properly.

    Also this user mentions it:
    But you rated him funny. Ignorance is a choice I guess.

    Edit: Oh look, another funny. Immature kid.
     
    #7 MrDienns, Mar 20, 2018
    Last edited: Mar 20, 2018
    • Agree Agree x 2
  8. If you atleast knew a little about spigot community you should know that theres people that doesnt even know how to setup a firewall...

    As i said before this is made for people that wants to prevent most important exploits/hacks ASAP and i will add more if people gives me feedback. It seems i just got haters :p
     
  9. This is the most stupid and pointless response to a security guide I've seen on this forums so far. Half adds nothing of value and the other half is forgotten. Turnabout is fair play. ;)

    If it's that bad then link to a better one, that way anyone stumbling across this thread is actually stumbling across two threads.
     
  10. Limiting the amount of connections per IP is going to do absolutely zero. Read the wiki instead.

    There's a wiki that perfectly explains it, which is listed in the bungeecord installation guide as far as I know.
    https://www.spigotmc.org/wiki/firewall-guide/
     
    • Winner Winner x 1
    • Useful Useful x 1
  11. There are people that doesnt understand that. Thats why i made a more specific guide. Really there is lot of people that still uses OnlyProxyJoin and IPWhitelist and get griefed because of that.

    Im just trying to spread some common sense.

    Btw, Limiting prevents packet spam from the same IPs and even brute force attempts.
     
  12. Thanks. Looks like the official guide mostly focuses on iptables, but it still has some good information for people who prefer ufw as well.
     
  13. Thing is that this tutorial doesn't even cover this. I mean I really don't care whether you use UFW or IPTables, that's not my point, people have preferences and should use whatever they like, my point is that this guide is totally incomplete and doesn't remote cover what the average user needs. The wiki I linked earlier explains you how to properly firewall a server to prevent people from directly connecting to your Spigot (without hosting on 127.0.0.1, since not everyone can do that). At least cover that part in your guide.

    If @LinsaFTW wants to provide UFW commands as well, then I suggest him to update the wiki as well and mention UFW commands. People are more likely to look at the wiki rather than threads here on the forums, especially people not being part of the community that much.
     
  14. Okay, ill cover that part. EDIT: Done!
     
    #14 LinsaFTW, Mar 20, 2018
    Last edited: Mar 20, 2018
    • Like Like x 1
  15. Bien hecho, se lo pasaré a gente que tenga un servidor y así puedan seguir tus pasos, sigue haciendo esto, ayuda mucho.
     
    • Friendly Friendly x 1
  16. Buena guía, mete el complemento que te pase para más seguridad, sigue asi! Es bueno compartir con los demás .:)
     
    • Friendly Friendly x 1
  17. Ya esta agregado en la seccion de exploits :)
     
  18. The problem isn't that people don't understand the wiki, the problem is that the wiki is already a simplified version of what has to be taken seriously. The people who just 'want' and don't want to learn, they glance over something, look for what to copy/paste, complain when it's not working.

    Thanks for writing something up, it's nice to discuss it and get more tips and tricks, and information. Hopefully it shows to somebody that they're perhaps not ready yet to run a public server and learn terminology and the os (and networking) a bit more.
     
    • Agree Agree x 1
  19. electronicboy

    IRC Staff

    Then update the wiki with better alternatives, there is no reason why one couldn't/shouldn't exist (I was planning to create one, but kinda a "simple/too boring/do I really wanna deal with support?"); A thread falls into darkness, a wiki is always there, and can easily be linked to as opposed to trying to link towards the "latest thread"

    Your thread is also highly biased towards a single setup type, which is generally one of the least common for the types of people you're aiming at; iptables is honestly much more used and preferred in the industry as opposed to a bunch of scripts which attempt to wrap iptables functionality, if somebody shows me an iptables chain generated with ufw, I'll scream because the thing has more jumps than a brothel (and really, relying on ufw to produce information which is accurate, i.e. not hitting one of the many quirks where ufw doesn't understand rule prioritisation properly), if somebody shows me an iptables setup, more than likely I can work out exactly what is wrong.
     
    • Like Like x 1
  20. Excelente guia, muy eficiente ahora si podré proteger mi network de tramposos. :)
     
    • Friendly Friendly x 1