Hosting dedicated Terraria server to learn HCP Boundary
Introduction
HashiCorp Boundary is an access management system for human to machine access. Boundary has many features but we’re focusing on accessing private networks through Boundary. One of the use cases of Boundary is providing access to a private network.
When I joined the HCP Boundary team, I wanted to build something that would allow me to experiment with some use cases while having some fun with it. I decided I wanted to try using HCP Boundary to secure a game server for a very popular sandbox game: Terraria.
Dedicated Terraria server
I host a server in a private network and provide access to the server through the HCP Boundary multi-hop feature. This project covers using Boundary to access a target that the users would not have access to otherwise.
Generally speaking, when hosting a game server, the players (clients) need to be able to communicate to the server through the internet; however, exposing a server to the internet comes with risks.
Distributed Denial of Service (DDOS) attack
Exposing the server to the public internet means a malicious actor can send a large amount of traffic to my server, which would saturate the server’s network and could lead to players being unable to connect.
Unauthorized access
A public server can also be vulnerable to unauthorized access. Even though a password can be set on the server, it is a server-wide shared password used by all players, which can be leaked. It is difficult to trace back to where the leak came from, and revoking access is also difficult. In a scenario where I need to revoke access for a particular player, the server password must be reset, requiring the server to be restarted, and the new password must be distributed to all players, which is inconvenient and disruptive
Exposing server IP address
Players need a server IP address to connect to the game server. If the server resides in my home network, this means I am distributing my public IP address, which may lead to a possible breach of my network in case of firewall misconfigurations or an unpatched CVE.
Security and maintenance
Allowing direct access to the game server means that I must ensure my server is secure. The stakes of accidentally port-forwarding to the server’s SSH port or making accidental firewall misconfigurations are now higher due to the server being accessible from the internet.
Benefits of using Boundary
Instead of having players directly access the server, we can utilize Boundary’s multi-hop feature to provide access to the server running in a private network. In this configuration, my players will not be able to connect to the server directly. They are required to log in to Boundary with their personal account and start a Boundary session before connecting to the server through Boundary. This mitigates all risks mentioned above and provides additional security features.
Individual username/password for each player
As discussed under “Unauthorized Access,” the Terraria server only allows a single server password, which needs to be shared with all players. Shared passwords can be prone to leaks and are difficult to trace back to the source of the leak. By using Boundary, each player will have their own unique username and password for logging into Boundary to connect to the game server eliminating the need for the shared server password since users are already required to authenticate to Boundary before being able to access the server.
Revoking access for a specific player is also much more convenient since we can simply terminate their Boundary user without making any changes to the server.
No internet no outsider
In this configuration, the server is completely hidden from the internet. This eliminates all attack vectors that require server access, including DDOS attacks and unauthorized access. The stakes of misconfiguring the server are also lower since no external traffic can reach the server.
Privacy
By going through Boundary, the server’s IP can be kept secret since the users will be connecting through Boundary.
What I learned
Boundary is much larger than I thought
In this blog, I only covered the simplest use case of Boundary without touching on advanced features such as session recording, audit logging, and credentials injection. Features that would be helpful in this case such as using credentials injection to allow admins to SSH onto the game server host to perform maintenance but this is out-of-scope for what I was trying to achieve for this build.
Boundary is valid for home use but probably overkill
HashiCorp Boundary is a powerful tool designed to provide secure access to systems running in private networks, offering features such as multi-hop connections and individual authentication for users. These features are helpful for folks with resources they’d like to expose to others, like a game server. However, for general use, they might be overkill for typical home use. Home networks generally do not require the same level of security and access management that Boundary provides, making its extensive features and configuration options more suited for enterprise environments. There are also limitations such as the lack of mobile clients for Boundary which eliminates some use cases such as running a media server at home and accessing it on a mobile device.
For tech enthusiasts or those with specific security needs, implementing Boundary at home can provide an excellent learning opportunity and enhanced security, albeit with a steeper learning curve and potentially unnecessary features.
Other possibilities
Now that I have a running Terraria server behind Boundary, here are some ideas on what could be built on top of the setup we discussed in this blog
Management Target vs. Player Target
Currently, I only expose a “player target” which allows players to connect to the server. In the real world, I may want to have multiple administrators to moderate the server and they may need direct access to the server to handle tasks such as backups, banning players, restarting the server, etc. I could add a second target for “administration” with dynamic credentials using Vault to allow admins to SSH to the server (optionally, enable session recording for auditability) to perform administrative tasks in an auditable way.
OIDC authentication
I added OIDC authentication so my players can log in using their Google, Microsoft, or Facebook accounts instead of having a username/password account on Boundary, providing an even more convenient way to log in.
More game servers
With this setup, I could host multiple game servers backed by the same Boundary cluster allowing users to have a single place to log in, browse all game servers, and securely connect to them. We could go further by designing the permission models that grant different users different permissions such as restricting servers they could join.
Architecture overview
We’ll run Terraria server in a private network where no external user can connect to the server. On the same machine, we’ll run a Boundary self-managed worker connected to our HCP Boundary worker as an egress worker, which allows our players to connect to the server by hopping through a multi-hop network (read more about multi-hop).
Worker on the same host vs. dedicated host
One decision we have to make is whether to run our Boundary worker on the same machine as the Terraria server, or run the worker in the same network but on a different machine. I choose to run the worker on the same machine because:
- This is a game server and I’d like to keep latency as low as possible. Running Boundary worker on the same host as the game server means we avoid an additional network hop between Boundary self-managed worker and the game server.
- Ease of configurations. Running a self-managed worker on a different machine means that the self-managed worker needs to be able to connect to the game server. This means we may have to configure a firewall on the game server to allow the Boundary worker to connect to the port, which is just an additional step.
- Small number of clients; the game server does not have to support a large number of players so I am not concerned about having to add more Boundary workers to absorb the traffic. The game server is the bottleneck, not Boundary.
The build
This is how I build out the game server starting with creating HCP Boundary cluster, creating required resources, configuring a self-managed worker, and ending with connecting to the game server.
Creating HCP Boundary cluster
Follow this guide to create HCP Boundary cluster. Once the cluster is up and running, login to Boundary cluster admin UI.
Creating resources
Boundary resources are organized into scopes. More information on scopes can be found here. In this example, we will create the following scope structure:
Create a new Organization “Gamers”
Inside “Gamers” org, create a “Terraria” project.
Under “Terraria” Project, in “Targets” tab, create a “Terraria Server” Target with following parameters:
Name: Terraria Server
Types: Generic TCP
Target Address: 127.0.0.1
Default Port: 7777
Default Client Port: 7777 ← this is for the client’s convenient to keep the session port consistent
Egress Worker Filter: terraria in “/tags/games”
Trying to connect to the target will not work at the moment because Egress worker filter was specified but no self-managed workers with the corresponding tags have been registered yet. Next section will cover configuring and authorizing the self-managed worker.
Self-managed Boundary worker
Since this blog is focused on Boundary component of this build, I will not go over how to setup and run Terraria server — more on those can be found at https://terraria.fandom.com/wiki/Server
For simplicity, I choose to run a self-managed Boundary worker on the same machine as the game server. A few pros of doing it this way are:
- No firewall rule changes: the server does not need to accept any connections from external IPs
- Low latency: no additional network hop between boundary worker and the server
Running self-managed worker
To be able to connect to the Terraria server, Boundary needs to be able to resolve the “egress worker” with a routable path to the server. We achieve that by running a self-managed worker with the tags that matches egress worker filter configured on the target.
Start a Boundary worker inside a Docker container
Create a config.hcl file — this file will be mounted into Boundary container providing its configuration.
disable_mlock = true
hcp_boundary_cluster_id = "<cluster-uuid>"
listener "tcp" {
purpose = "proxy"
address = "0.0.0.0:9200"
}
worker {
auth_storage_path = "/boundary/auth/worker1"
tags {
type = ["gameserver"]
game = ["terraria"]
}
}Start boundary-enterprise container.
docker run \
--network host \
-d -v "$(pwd)/config.hcl":/boundary/config.hcl \
hashicorp/boundary-enterpriseOnce Boundary is up and running, we can fetch the Worker Auth token by looking at the logs.
❯ docker logs <container_id>
Couldn't start Boundary with IPC_LOCK. Disabling IPC_LOCK, please use --privileged or --cap-add IPC_LOCK
==> Boundary server configuration:
Cgo: disabled
Listener 1: tcp (addr: "0.0.0.0:9200", max_request_duration: "1m30s", purpose: "proxy")
Log Level: info
Mlock: supported: true, enabled: false
Version: Boundary v0.16.0+ent
Version Sha: ad952555caf942873e0b410eecc69feda81fdb64
Worker Auth Current Key Id: magenta-overtake-shortly-zodiac-grating-unmade-alike-overbid
Worker Auth Registration Request: GzusqckarbczHoLGQ4UA25uSRrdrJDpBchpuNqwUZRbquLbUotBvNTbqSVhenYK819nP9eEMeKeCPFhUvHrTAi2oEbhxNYsoPJFSVEbGuZrxq79V8wcxFegBAKn78kThaY8M4q6KVCN8Xa36kTAbKLgpJmg9h59AbRkAhn1nnDbexhCaQMQpymcsqzN7SdtBLsaj5MLnJoxxvCfcBBzwqqmwrpePS3Vr7ss6Ksc3H6VeTgRnc3uFpuxc9n49b8EHnTpPKDf61L5zCwgaptF3FJXZtPW3WKxfB8Ts63xjWt
Worker Auth Storage Path: /boundary/auth/worker1
Worker Public Proxy Addr: 0.0.0.0:9200
==> Boundary server started! Log data will stream in below:Copy the Worker Auth Registration Request. That’ll be needed to authorize the worker against the Boundary cluster.
On Boundary cluster admin UI
Navigate to “workers” tab.
Click “New” and scroll down to section “3. Confirm the worker when they connect” — Enter the Registration Request token and click “Register Worker”.
Navigate back to the “Workers” tab — another worker should appear on the list.
Connecting to the server
To connect to the server through Boundary, we’ll use Boundary desktop as a Boundary client but Boundary CLI works as well. Install Boundary desktop by following this guide.
Configuring Boundary desktop
Once Boundary desktop is installed, we need to point it to our HCP Boundary client and login. Launch the application and enter the cluster URL. Click “Submit” and login with your username and password.
Starting Boundary session
Navigate to “Targets” and find “Terraria-server”.
Click “Connect”.
Session is now started and ready to accept connections to 127.0.0.1 at port 7777. Any connection to this port will be connected to the Terraria server.
Let’s play!
Launch Terraria game — then go to multiplayer.
Select “Join via IP”.
Learn more
By hosting the game server in a private network and providing access via Boundary, the game server is now safe from common threats such as DDoS attacks, unauthorized access from the public internet. This approach not only enhances security but also simplifies the setup process by eliminating the need for port-forwarding and complex firewall configurations. The only caveat is that the UDP is not currently supported; therefore, this method may not work for other games such as Minecraft (Bedrock edition).
For more information, check out HCP Boundary to get started with multi-hop sessions. Review our tutorial on managing multi-hop sessions to set up Boundary for accessing resources in a private network.
