RE:NODE
Browse hosting

Security

What actually protects your account and your servers

RE:NODE writes its own panel rather than licensing one, so the security of this place is something we built and can describe rather than a feature list somebody else sold us. This page is what is in it - including the parts that are limits rather than features.

HTTPS only
Plain HTTP is redirected; certificates renew on their own.
Two-factor
One-time codes from any authenticator app, with recovery codes.
Nightly, off-box
Backups copied to separate hardware and verified after each copy.
A container each
Your server has its own filesystem, memory and CPU ceiling.

Your account

Everything that decides whether a request is really you.

Passwords are hashed, never stored

The panel keeps a bcrypt hash and nothing else. Nobody here can read your password - which is the same reason nobody here can tell you what it was. A reset is the only way back, and that is the point.

Two-factor authentication

Time-based codes from any authenticator app, with single-use recovery codes issued the moment you turn it on. Keep those codes somewhere that is not the phone: they are what gets you back in when the phone is gone.

Signing in is throttled and challenged

Login, registration and password reset are rate limited per address and sit behind a captcha. Guessing a password stops being a thing worth trying long before it starts working.

Sessions you can see and end

Your account page lists every session that is open right now, where it is being used from and when it was last active, and lets you end the ones you do not recognise. The cookies themselves are encrypted, unreadable to JavaScript and not sent from other sites.

The front door

What a request goes through before it reaches anything of yours.

HTTPS, and only HTTPS

Plain HTTP is redirected rather than served, and certificates are issued and renewed automatically - so an expired certificate is not something that can quietly happen on a Sunday.

Every form carries a CSRF token

A request that changes something and did not come from a page we served is rejected. Another site cannot act as you in a tab you left open.

Scanners are refused, not answered

Most traffic that finds a panel is not looking for it: it walks the internet asking every host for credential files and source trees that do not exist here. Those requests are recognised on sight, the address behind them stops being answered, and it stays blocked for longer each time it comes back. Every refusal is written to a log an operator actually reads.

Bans at the edge

fail2ban sits in front of the application, so the traffic that is clearly not a customer never costs a PHP process at all.

Your server

One customer's server is not a folder inside another's.

Isolated containers

Each server runs in its own container with its own filesystem and its own memory, CPU and disk ceilings. A neighbour cannot read your files, and a neighbour having a busy night cannot spend your resources.

Credentials generated per server

Admin passwords, RCON passwords and database users are generated for your server rather than shared across a plan, and they are shown to you rather than to anybody else.

API keys you can pin to an address

A key can be restricted to a list of addresses, which makes a leaked key useless from anywhere else. Keys are stored encrypted and shown once, when they are created.

Sub-users instead of a shared login

Give somebody the console without the files, or backups without billing. Every action is attributed to the account that took it in the server's own activity log, so "who restarted it" has an answer.

Data and backups

Insurance that is not sitting on the same disk as the thing it insures.

Nightly, and safe to run unattended

The database and the runtime data are dumped every night. The dump is taken without stalling the panel behind a lock, the database password never appears on a command line where other processes could read it, and two runs cannot overlap and corrupt each other.

A second copy off the machine

The panel, the customer volumes and the on-machine backups share one storage pool - so a pool failure would take production and its insurance together. Everything is pulled down to separate hardware as well.

Verified, not merely copied

Each copy is checked for archive integrity and, for a database dump, for the completion trailer that is only written when the dump actually finished. A backup nobody has verified is a guess.

Retention that cannot fill the disk

Copies are pruned on a schedule instead of kept forever. Backups that grow until they take the panel down with them are a failure mode we would rather not invent.

What a request goes through

In order, from the moment you press a button in the panel.

  1. 1

    Encryption

    The connection is encrypted before a single byte of the request is sent. Plain HTTP gets a redirect and nothing else.

  2. 2

    Reputation

    The address is weighed against what it has been doing. Requests that have already identified themselves as hostile end here, with a 404 that tells them nothing.

  3. 3

    Session and origin

    The session cookie is decrypted and the CSRF token checked - so the request is both from you and from a page we served you.

  4. 4

    Permission

    Only then is the action checked against what that account is allowed to do on that specific server, and written to that server's activity log.

What we do not do

The part of a security page that is usually missing.

  • Nobody is asked where you are

    Country lookups are answered from a table on our own machine. Resolving an address through a third-party service would mean telling somebody else about our visitors, one request at a time.

  • Page views are stored without addresses

    We count what gets read so we know which guides are worth writing. We do not keep who read them.

  • We cannot recover a lost password

    That is what hashing means. And if two-factor is on and the recovery codes are gone as well, the account cannot be handed back to anybody - including to you. Keep the codes.

  • Some game credentials are stored as typed

    Arma 3, DayZ, Project Zomboid and 7 Days to Die cannot be installed anonymously: the installer signs in to Steam as you, and the server needs those details again on every update. Use an account kept for servers, never your main one. Each of those game pages says so before you buy, not after.

Found something?

If you think you have found a vulnerability, tell us before you tell anyone else and we will fix it. A report about a real problem is worth more to us than it is to anybody you could sell it to.

Contact us