Note: This series isn't finished yet, and I may refactor pages severely the upcoming days. A comprehensive series of posts explaining why Minecraft servers get hacked, and what you can do to prevent it. This post will speak of several things which are almost always the case in those classic YouTube videos where servers get hacked. I will explain in detail why this happens, how this happens, and what you can do to prevent it. This is a post designed towards everyone; from (public) plugin developers, to system administrators, to the professionals who have full custom networks. In cyber security, you shouldn't asked yourself if you get hacked, but when. These posts consists of the following parts; Part 1; Awareness (current) Part 2 The exploit chain Part 3; Identifying risks Part 4; Reducing risks Part 5; Preventing risks Introduction I am writing this because I (too often) see servers get hacked. Now, this on it's own, while problematic, isn't necessarily alarming. What is alarming to me is how, and why they get hacked. For that reason I'm writing a multi part security blog (or whatever you want to call it) raising awareness to pretty much all. Note that this guide isn't specific to Minecraft; this is software development and system administration in general. This is the first part in the series. Awareness Be really honest with yourself in this part. You most likely have something running (probably a Minecraft server). Have you ever sat down for quite some time and had a good, deep thought about how secure your network is? How it could be hacked, and what would happen if you get hacked (in terms of damage) and how you would tackle a breach? Most likely not. That's where the first problem comes in. If you did think about it, congratulations, you're on the right path. Unfortunately, many people don't realise that the lack of security attention will result in security risks. It's inevitable; unless you're actively thinking about security while building or maintaining your setup, you're very likely to create risks. Assess the current The first step in this is to start an assessment. Look at your entire setup (yes, everything, as large as it may be) and investigate how exactly things are integrated with each other. Which things are connected, what are some shared services or databases? This is crucial to know for the next section. When doing this assessment, create a layout of how everything works and how everything is connected. One could use an UML Component Diagram for this. Exploit chain The reason why we do this is further explained in part 2; the exploit chain. Without spoiling too much, it comes down to one exploit causing another. The minor breach in system A could result in a breach in system B, C, D, etc. This is what many people simply do not realise. A perfect example is the permission system. Many administrators which configure the MC server will think that a certain functionality is safe because it's locked down a permission. This is true, until you figure out that you misconfigured your bungee and someone could simply OP himself. At that point, your permissions are no longer preventing anything, and the fact that your bungee connection got breached (initial exploit) thus now results in further exploits (chained exploits). This is what I call the exploit chain (there's probably an official term for it) which I will cover in detail in part 2. Example Below is an example. We have a classic Minecraft server, with a BungeeCord setup, three different gamemodes (factions, towny and skyblock). It consists of databases, a web shop (Tebex) link, and a Discord synchronization (DiscordSRV). I suppose this is as generic of a setup as one could imagine. Any tips or additions to this, be sure to suggest them below. Let's view the below image of how things are connected in this scenario (most likely!); We have a BungeeCord, connected to all Spigot servers. All Spigot servers are also connected to the same database server and the same database (like a MySQL database). They're also both connected to Tebex and Discord. For the sake of this section, let's assume both Discord and Tebex are integrated to the max; synchronized console to Discord, and being able to manage your store from in-game in Tebex. We are assuming this because I believe this is the most common. Now, I want you to take this image and paste it somewhere in paint or anything which allows you to easily draw on this. I want you to draw a red cross (double line) through connections which shouldn't exist at all, and a single red line through connections which should be modified (integrations or functionalities which should be disabled). Review the current In the spoiler below is my view on it. Somethings may surprise you. Spoiler: My advice Now hold on, I can already see you cracking your knuckles, preparing to go full out in the comment box below. But hold on, let's carefully look at this. This is where awareness comes in. Look at these functionalities, and really think to yourself which of these is necessary. This may differ for everyone; one person may have more custom development capacity compared to others. However, point remains; both should review things and and question if things should work this way. The happy-flow mentality Many people will set up their Minecraft server in a happy-flow strategy. They'll start setting up things, and once it works, they stop. It works, it runs, you have players, your job is done. Right? No. We're all (at least I hope) aware of the classic Bungeecord "exploit" where players can directly connect to your Spigot server through a spoofed Bungee proxy if you didn't firewall your setup properly. As ridiculously old this technique is, it still works even today. This should prove the above mentality of lots of people. The problem is that the most obvious and straight forward setup is usually not the best (or, at least not the most secure). Think about what I mentioned earlier with your permission problem and you getting Bungee'd (a verb to indicate you got Bungeecord firewall hacked). You may think that things are fine with just some permissions. You leave a functionality enabled, but you hide it behind a permission. It works, it runs, you have players, nothing is wrong. Yet. Untill you get Bungee'd, and your permissions are all bypassed. This goes for everything you can then do from within your Minecraft server; manage your Discord server, access private user data, read personal data from your webshop, modify your webshop, execute SQL queries or read files from the disk (yes, some plugins are stupid enough to have such functionality). Spigot plugins While Spigot is lovely because of the plugin mechanism, this does introduce a big risk. Spigot is great for modding because of plugins. But, let's think about this for a second. A plugin, what is that exactly? In a sense, it's just some code which automatically got executed by some other code. By definition, that is extremely risky. All hacking pretty much comes down to making a machine do what you want to do. Some more unexpectedly or complex than others, but it comes down to the same thing. The fact that a plugin is in the end nothing but some code being automatically invoked, is risky. You as developer and administrator should keep this into account. Why you should keep this into account has a developer is explained in further parts. You should always be careful with the plugins you install. @Optic_Fusion1 has a list of all of the malware he found on Spigot. Would be interesting if he could share some numbers on how much malware he found, and what this malware does, and how it works. Also be noted, malware can spread! If you don't setup your permissions properly, one plugin could just write another Jar file, effectively moving the malware code to a new Jar, which may help hide its malicious intent. Not only is this risky from a code perspective, but also from a configuration & data perspective. More about this in part 2, 3, 4 and 5. Summary This first section may be a bit hectic in it's writing, but that's because I want to raise awareness, and that's the summary for the first part. Look at your setup, and most important, be honest with yourself. Reviewing your technology stack, how it's all integrated with each other, and ask yourself if you really need it. Don't use something just because; use it because you genuinely need it. Not a single soul on this planet genuinely needs to synchronize his Minecraft console to a Discord server. I'll pay you $100 if you can convince me otherwise. Next up; Part 2; The exploit chain Comments or suggestions are welcome.