What setting up a self-hosted Minecraft server has taught me about business-to-business sales

Ben Standen

— 6 min read
What setting up a self-hosted Minecraft server has taught me about business-to-business sales

Okay, so a disclaimer upfront… setting up a self-hosted local Minecraft server didn’t actually teach me anything about business-to-business sales. I mean, you were expecting that, right? If so, great, we’re on the same page, if not, well apologies, but hopefully there’s some value here for you anyway.

What it did provide was a couple of great examples of two separate topics: DNS-based redirect attacks and the current state of artificial intelligence (AI) when implementing technical projects.

The Project

My kids love Minecraft, and to be honest, I really enjoy playing it with them as well. As they’ve gotten older however we have encountered more and more multiplayer challenges around persistent worlds and cross-play functionality, while avoiding additional cloud-based subscriptions and potentially unsafe online environments. With all that in mind we decided to create a local self-hosted Minecraft server that solved these challenges as well as addressed the following criteria:

  • The ability to connect on the local network.
  • Allow family and friends to connect over the internet.
  • Be compatible with multiple platforms; Windows, MacOS, Linux, PlayStation, Xbox, and Switch.
  • Allow both code bases, Bedrock and Java, to be able to play together in the same world.
  • Run on an old unused Linux-based network attached storage (NAS) server I had lying around.

After an evening of research with the help from a handy AI assistant (we’ll call them ‘Clyde’), the implementation only took a day (https://attack.mitre.org/techniques/T1588/007/). There were some interesting implementations, however.

The Implementation

Using the already on hand Linux-based NAS didn’t have any impact on the implementation of the project. It did create a bottleneck for player count due to the older CPU; however, it catered to our needs just fine. As with most modern systems these days Minecraft could also be easily deployed and managed through containerisation (https://attack.mitre.org/matrices/enterprise/containers/) which happily ran on the NAS.

Local connections to the server ran out of the box as you would expect using just the IP address of the NAS and the appropriate port of the Minecraft server’s container. Remote internet connections took a couple more steps, but thankfully my years spent as a Cisco Netacad trainer finally paid off. Dynamic DNS was configured to continuously map the required external IP address of the network, port forwarding then moved the external traffic from the edge router to the internal Minecraft container, and IP address allow-listing ensured only trusted locations could access the router through the firewall. A VPN or similar secure tunnel could have been used instead; however, this creates an additional complication when connecting from a remote device with limited networking options such as a Nintendo Switch. IP addresses do need to be allowlisted prior to family and friends being able to connect, however given the small player base this shouldn’t be an issue. If it is, I’ll probably introduce port knocking for easier allowlisting (https://attack.mitre.org/techniques/T1205/001/).

The original version of Minecraft, released in 2009 was written in the Java programming language and ‘Minecraft: Java Edition’ still runs on that codebase today. ‘Minecraft: Bedrock Edition’ was developed later and written in the C++ programming language to run efficiently on mobile, console, and lower-powered devices (https://attack.mitre.org/techniques/T1027/008/). Allowing connections from clients running both code bases for Minecraft was the first ‘challenge’, however thanks to Clyde’s quick referencing, the ingenuity of the Minecraft community, and the opensource software already available (https://attack.mitre.org/software/), calling it a challenge isn’t really fair. A new container was deployed that proxied any Bedrock platform connecting to the server converting the connection through to Java. This allowed players with the Bedrock version of Minecraft to connect to the same Java-based server as the Java players.

Allowing multiple platforms to connect to the same server was the only real challenge during implementation. As Windows, MacOS and Linux can all natively run Minecraft Java, these platforms were compatible ‘out of the box’. Additionally, with the proxy in place for Bedrock connections anyone running Bedrock on these platforms were covered as well. The challenge lay in the restrictions on console devices to directly connect to a self-hosted server. They could ‘see’ and connect to shared worlds running on the same console type on the same local network but did not have the functionality to enter the address of a self-hosted server and directly connect like their Windows, MacOS, and Linux ‘cousins’ could. This may be to address concerns around connecting to ‘unmoderated’ servers; however, it also means that the only officially advertised way to host your own server (which is cross-platform by default) is to pay a monthly fee for a Minecraft ‘Realm’ (https://attack.mitre.org/techniques/T1657/).

Outside of the ‘Realm’ subscription service there are a number of community managed public servers featured by Minecraft within the console platform (PlayStation, Xbox, Switch) which can be directly connected to. So, I did what any respectable hacker would do: identify the domain name of each featured server and set manual DNS entries on my network to intercept any request to those servers and send them to my self-hosted Minecraft container instead. With this in place, a Minecraft player on PlayStation, Xbox or Switch could attempt to connect to any featured server provided by the Bedrock console version and be redirected to our self-hosted Java server instead (https://attack.mitre.org/techniques/T1557/).

The Lessons

While the intent of this project was to play Minecraft with my kids, alongside some other family and friends, it did provide a couple of fun lessons along the way.

Adversary in the Middle (AiTM) attacks aren’t anything new and are commonly seen across cyber incidents. During offensive security engagements, be it penetration testing or adversary simulation, they are also often used to gain initial access, laterally move, or escalate privileges.

This may be:

What is not commonly executed on offensive engagements however (outside of some more open-scoped red teaming engagements), is the full manipulation of DNS records to redirect all users on a network to an adversary-controlled asset. I daresay there are two reasons for this. Firstly, there may be a simpler path which can be used instead, such as modification of the host file on a single device. Noting that full DNS manipulation within an environment requires escalation of privileges to control the DNS server, or a vulnerability in place allowing unauthorised modification to DNS records. Secondly, while an experienced operator would be able to ensure minimal risk to business operation impacts, there is always the possibility that a change in DNS records may cause an interruption to users trying to perform their duties.

Implementing this project provided a nice reminder that manipulating records on an environments DNS server to redirect clients to an attacker-controlled asset is effective and overcomes cross platform barriers.

AI, in the form of large language models (LLMs), such as our friend Clyde, have done an excellent job at disrupting a range of different industries and functions. Cyber security, both offensive and defensive, certainly hasn’t been an excluded from this. Having Clyde help with implementing this project provided a great example of LLM capabilities when implementing a technical project such as this one. To caveat, I did not provide Clyde with access to a terminal, browser, or any files, nor did I equip them with an open set of claws (https://openclaw.ai/). I could have, but this project again reminded me why sometimes it is best not to.

To be fair, Clyde did expediate the research and implementation of this project. As my great-grandmother always said, “there’s no point ‘Googling it’ when you have an AI dog to digitally bark for you” (maybe we’ll delete that one during the proofread…). Could Clyde have done this project on their own though? Probably not. Yes, they generated some good container YAML files, but they all needed to be edited to get them to work. Yes, they provided insight into file deployment for the Minecraft server, but they couldn’t overcome permission issues on their own without saying I should just set directory ownership for files to ‘Everyone’. Clyde was also adamant that the PlayStation Minecraft ecosystem was completely closed:

“PS5: PlayStation uses a completely closed Bedrock network that is isolated from other platforms by Sony. PS5 players cannot connect to custom/private Bedrock servers at all — they can only play on Realms or official servers built into the Marketplace. There is no workaround for this.”

Thankfully they were also polite enough to somewhat say that they were wrong:

“That's a clever solution and makes sense — you've got a fairly unique configuration with a combination that isn't well documented anywhere as far as I'm aware.”

The Conclusion

Interesting problems usually need interesting solutions, and while an LLM can help, it cannot do creative problem solving, well at least for now. Clyde, like many others, is bound by their training and embedded biases. Humans on the other hand, while also somewhat bound by their ‘training’ and embedded biases, have the capacity to create unique solutions to novel problems. The number of opensource projects looking to solve the same problems I encountered was such a pleasure to see. It reminded me that this ‘hacker mindset’ can be found in so many communities outside of cyber security, and it is not something I see when using an LLM.

Hack the planet, or at least your Minecraft world.

Read more