RCON safely: ports, passwords and the panel console

RCON sends administrative commands to a running game server from somewhere else. In the original design and in most of the implementations that copied it, the password crosses the network in plain text, there is no encryption, there is no session, and anybody who has the password can do anything the server console can do - which includes stopping it, opping themselves, and on some games executing arbitrary code inside your container. It was designed in 2004 for a LAN. It is still the default remote-administration mechanism in a dozen games. This post covers how it actually works, where it lives in each game, how to lock it down if you need it, and why most servers should simply turn it off.

What RCON is, and how the protocol works#

RCON is a TCP protocol. The client connects, sends the password, and the server either accepts or rejects it. After that, the client sends command strings and gets output back. Valve's Source RCON protocol is the one nearly everybody implements, including Minecraft, so it is worth seeing the shape of a packet:

All integers are little-endian, and the maximum packet is 4096 bytes. Authentication is a type 3 packet whose body is the password. The server replies with a type 2 packet: if the ID matches the one you sent, you are in; if the ID is -1, the password was wrong.

Three consequences follow, and they are the entire security story.

• The password is sent as-is. There is no hashing, no challenge, no key exchange. Anybody in a position to read the traffic reads the password. On the open internet, that is more people than you think, and it includes every intermediate network between you and Germany.
• There is no session. Every connection re-authenticates. A brute-force attempt is just a lot of connections, and whether that is throttled depends entirely on the implementation.
• Authentication is all-or-nothing. There are no RCON users and no per-command permissions. One password, complete control.

Minecraft's implementation is the same protocol with its own defaults. Some games deviate: Rust runs RCON over WebSocket rather than raw TCP, and 7 Days to Die uses Telnet instead, which is the same idea with even less protection.

Where RCON lives in each game#

The single most useful thing to know is which port and which protocol, because that determines the firewall rule.

enable-rcon=falsercon.port=25575rcon.password=broadcast-rcon-to-ops=true

Minecraft ships with RCON off and an empty password, which is the right default. broadcast-rcon-to-ops is worth leaving on: it echoes RCON command output to online operators, so an admin in the game can see a command arriving from outside. That is free intrusion detection.

The Source engine case has a detail that is genuinely useful. Game traffic is UDP on the game port; RCON is TCP on the same port number. That means a firewall rule blocking TCP on port 27015 kills RCON without affecting a single player, which is the cleanest way to close it on a Source server without editing configs.

# Source server: block RCON, leave the game alone$ sudo ufw deny proto tcp to any port 27015$ sudo ufw allow proto udp to any port 27015

Palworld deserves a specific warning: RCONEnabled=True uses AdminPassword as the RCON password, so the in-game admin password and the remote console password are the same string. Give the admin password to a moderator and you have given them RCON. Palworld admin commands and RCON goes through that configuration in full.

Turn it off if nothing uses it#

Most servers have RCON enabled and idle. It gets switched on during setup because a guide said to, and then nothing ever connects to it again. That is a password-protected shell on an open port, maintained by nobody, with a password chosen in a hurry eighteen months ago.

Ask one question: what connects to it? If the honest answer is "nothing", or "a Discord bot I stopped running", turn it off. On Minecraft that is enable-rcon=false and a restart. On Source it is removing rcon_password from server.cfg. On Palworld it is RCONEnabled=False. If your host allocates a separate RCON port, remove the allocation as well so there is nothing listening at all.

If you need RCON, six rules#

Plenty of setups genuinely need it: a Discord bridge, a web panel you wrote, a vote listener, a scheduled announcement. These rules cost nothing and remove most of the risk.

1. A long random password, used nowhere else. Not your panel password, not the database password, not the in-game admin password where the game lets you separate them. Twenty-four random characters from a password manager. The password is the entire authentication system, so treat it as such.
2. Restrict by source address. RCON reachable from the whole internet is a brute-force target with no lockout in some implementations. Restrict it to addresses you control, or do not expose it at all - see the next section.
3. Never put it in a screenshot. The classic leak is a console screenshot pasted into a support channel with the start-up arguments visible. The second classic is a public GitHub repository containing a bot's config file. Environment variables and secrets covers keeping it out of both.
4. Rotate it when anybody who had it stops being involved. A shared secret is shared forever until it changes. This belongs in the same checklist as removing their subuser account, which subusers and least privilege sets out.
5. Log the connections. On Source, sv_rcon_log 1 records RCON activity. Failed authentication attempts appearing in your console are the clearest early warning you will get, and they are worth checking for periodically rather than never. Logs worth keeping has the wider list.
6. Use the failure limits where the game has them. Source servers have a small family of cvars for banning addresses that fail to authenticate:

// Ban an address for this many minutes after too many failures. 0 means permanentsv_rcon_banpenalty 60// Failures before the address is bannedsv_rcon_maxfailures 5// Failures within the time window that trigger a bansv_rcon_minfailures 3sv_rcon_minfailuretime 30sv_rcon_log 1

Vanilla Minecraft has no equivalent. A failed RCON login there closes the connection and that is all, so an attacker can try as fast as the network allows. That makes rule two more important on Minecraft than anywhere else.

Note that sv_rcon_whitelist_address on Source is not an allow list despite the name: it names an address that will never be banned by the rules above. It does not stop anybody else connecting. Use a firewall for that.

Restricting it properly#

There are three ways to reach a running server's admin interface, and they are not equally exposed.

The panel console is the same capability behind an account you already protect properly. It is the server's real standard output and input over HTTPS, with a command line, history and tab completion, sitting behind a password, a second factor and a session you can revoke. There is no second credential, no extra port and no plaintext anything. If your host gives you one, this should be your default and RCON should be the exception.

An SSH tunnel is the right answer on your own machine. Bind RCON to 127.0.0.1 where the game allows it, then forward the port over SSH when you need it:

$ ssh -N -L 25575:127.0.0.1:25575 you@your-server# in another terminal, the client now talks to a local port$ mcrcon -H 127.0.0.1 -P 25575 -p "$RCON_PASSWORD" "list"

Nothing is exposed publicly, the traffic is encrypted, and access is governed by your SSH key rather than by a shared string. SSH keys and hardening covers the key half of that.

A firewall rule is the fallback when the game insists on binding to everything. Allow the addresses that need it and deny the rest, remembering that a home connection's address usually changes. Firewall rules that matter and the UFW guide go through the syntax; the principle is default deny, then allow the specific thing.

The option that is not on the list is "it is fine, the password is strong". A strong password protects against guessing. It does not protect against being read off the wire, being in a config file somebody downloads, or being in the backup archive a subuser exported.

Tools and scripts#

If you are automating, two clients cover most needs. mcrcon is a small C client that works with any Source RCON server despite the name, and rcon-cli is a Go client with a config file for saved servers.

# One command and exit$ mcrcon -H 127.0.0.1 -P 25575 -p "$RCON_PASSWORD" "say Restarting in 5 minutes"# Interactive terminal mode$ mcrcon -H 127.0.0.1 -P 25575 -p "$RCON_PASSWORD" -t# Several commands in one connection$ mcrcon -H 127.0.0.1 -P 25575 -p "$RCON_PASSWORD" "save-all" "say Saved"

Two habits worth keeping. Read the password from the environment rather than typing it on the command line, because command lines end up in shell history and in the process list where anybody on the machine can read them. And give each script its own copy of nothing: since RCON has no users, every script shares the one password, so the fewer scripts that hold it, the fewer places it can leak from.

For scheduled work, check whether you need RCON at all. A panel with a scheduler can send console commands directly on a cron expression, with ordered tasks and delays - a save, a broadcast, a wait, a restart - which is the most common reason people write an RCON script in the first place. Scheduled tasks worth having and cron expressions explained cover the pattern.

What somebody does with a stolen RCON password#

This is not abstract, and it varies by game in ways that matter.

• Minecraft. op themselves, deop you, whitelist off, gamemode creative, then any of the world-editing commands. stop at a moment when the world has not saved. With a plugin like a world editor installed, the damage is measured in chunks.
• Garry's Mod and other Source games. lua_run executes arbitrary server-side Lua. That is file access, HTTP requests and persistence inside your container. sv_downloadurl can be pointed at a server the attacker controls, which then serves files to your players. This is the worst case on the list.
• Palworld, Project Zomboid, 7 Days to Die. Shutdown, kick, ban, wipe-adjacent admin commands, and a shutdown timed to lose the most progress. The console is the admin interface, so everything the admin can do is on the table.
• Any game. Repeated stops. A server that cannot stay up loses its community in about a week, which for a rival is the whole objective.

If you think an RCON password has leaked, treat it as a compromise rather than a scare: change it, change the in-game admin password if the game shares them, take a backup of the current state before anything else overwrites it, and read the console log backwards for commands you did not send. What to do when your server is hacked is the longer version of that procedure.

Troubleshooting#

Connection refused. Nothing is listening. RCON is disabled, the password is empty (which disables it on Source), the server has not finished starting, or you are on the wrong port. Check the startup log for the line confirming RCON started.

Connection times out instead of refusing. A firewall is dropping packets rather than rejecting them. That is usually the host firewall or the port not being allocated, not the game.

Authentication fails with a password you are sure of. Check for a trailing space or a newline, especially if the password came from a file. Check that the game does not share the password with something else you changed. On Palworld, confirm you are using AdminPassword rather than a separate value you invented.

It works, then stops after a few tries. You have hit the failure limits. On Source, your address is now banned for sv_rcon_banpenalty minutes. Fix the password before trying again rather than hammering it.

Commands run but return nothing. Some games return output asynchronously to the console rather than to the RCON connection, and long responses are split across multiple packets that a simple client may not reassemble. Check the server console to confirm the command actually ran.

Output is truncated at about 4 kilobytes. That is the protocol limit per packet. Clients handle multi-packet responses differently, so a long list on a busy server may come back short.

FAQ#

Should I use RCON at all?

Only if something automated needs it. For a human sending a command, the panel console is the same capability without a second credential or an open port. For a bot, a bridge or a script, RCON is the interface the game gives you, so use it with a restricted source address and a password that exists nowhere else.

Is RCON encrypted?

No. The password and every command travel in plain text over TCP. Anybody who can observe the traffic can read both. This is the single fact that should decide how you expose it: not at all, or through a tunnel.

Can I change the RCON port to hide it?

You can change it, and it helps a little against untargeted scanning. It is not protection. Port scanning the whole address space is cheap, and a service that answers the RCON handshake identifies itself immediately. Change the port if you like, but do the firewall rule as well.

What password does RCON use on RE:NODE?

Pre-configured installs generate the admin, RCON and database passwords per server rather than shipping a default, so you do not start with a known value. Rotating it is still on you, and the panel console means you may not need it at all.

Does RCON work if the server is still starting?

No. The RCON listener starts with the game, usually after the world or map has loaded. Scripts that connect immediately after a start command will fail; add a delay or retry rather than assuming a failure means the password is wrong.

Can I give a moderator RCON instead of panel access?

You can, and it is the wrong way round. RCON has no users and no permissions, so the moderator gets everything the console can do and their actions are indistinguishable from yours. A subuser with console permission is narrower, revocable and logged.