Harden your servers with the firewall, SSH keys and updates

A server that SrvYard provisions starts with sensible defaults: password logins off, a firewall that denies everything except SSH, HTTP and HTTPS, and automatic security updates. Hardening is keeping it that way as the server grows: every port you open, key you add and package you install changes the picture.

This article lists what SrvYard sets up for you, then works through the checks that stay with you, in order of how often they matter: the firewall, SSH keys, updates, databases, and what to watch. Each check is a screen you can open in a minute.

Before you begin#

• A server that SrvYard provisioned. The defaults below are applied during provisioning. A machine you connected after the fact, or adopted, may differ, so check it. See Connect an existing server.
• The right permissions. Firewall changes need servers:manage-firewall, keys need servers:create-keys and servers:delete-keys, and packages need servers:manage-packages. See Roles and permissions.
• A way in that is not SrvYard. Keep your provider's console available. If you ever cut yourself off, that is how you get back.

What SrvYard sets up for you#

During provisioning SrvYard applies these defaults:

Everything below is about what you add on top of that.

1. Keep the firewall tight#

Open the server and choose Firewall.

1. Add rule. Opens the rule panel (below).
2. A rule row. Shows the name, Allow or Deny, the port, the protocol, the source and the status. The default rows are SSH, HTTP and HTTPS.
3. Sync from server. Reads the rules that exist on the machine, which is useful after someone changed them by hand.

SrvYard rebuilds the whole UFW ruleset when you save, and keeps SSH open so a mistake cannot lock SrvYard out. A deny rule on SSH for specific addresses still applies to them, so check your own address first. Deny rules are applied before allow rules.

Rules to follow:

• Open only what a service needs. If you open a port to test something, close it afterwards.
• Never open a database to the internet. MySQL, PostgreSQL and Redis are meant for localhost or a private network. When you must reach a database from your office, use a source restriction, as below, or an SSH tunnel.
• Restrict by source. Source takes IP addresses or ranges (IPv4 or IPv6) separated by commas, empty meaning anywhere.

1. Action. Allow or Deny.
2. Port. One port, or a range such as 8000:8100 (a range needs TCP or UDP, not both). A port is optional when you give a source.
3. Source. Here the documentation range 198.51.100.0/24, so only that range can reach port 3306. Use your own office address.

The panel warns that a deny rule on SSH for specific addresses still applies. See Open and close ports with the firewall for the full tour. Remember that your cloud provider may have its own firewall in front of the machine; keep both in step.

2. Keep the list of SSH keys short#

Choose SSH keys on the server.

1. Add key. Adds a key from your library to the server. A key you add can log in, so add only your own and your team's.
2. SrvYard (Required). SrvYard's own key. It manages the server and cannot be removed.
3. A saved key. Each row shows who it is, the user it logs in as and its fingerprint. Remove a key from its row when a person leaves, a laptop is replaced or a deploy key is no longer used.

Removing a key here removes only the line SrvYard added to the machine. Deleting a key from the organisation library does not remove it from servers it was already added to, so remove it on each server. The fingerprints let you tell two similar names apart; compare them with the fingerprint shown by ssh-keygen -lf on the real key.

Good habits: one key per person and device, never a shared private key, a passphrase on every private key, and no keys for people who left. See Add SSH keys to a server and to your account.

3. Apply updates and reboots#

SrvYard installs security updates by itself, but not everything, and a kernel update only counts after a reboot.

1. A reboot is required. Shown under Uptime when updates need a restart to take effect. Plan a reboot in a quiet hour.
2. Updates. The number of packages that can be upgraded. A high number, or one that never goes down, means updates are not being applied.

Apply the waiting packages from the server's Packages tab, restart the services and then reboot if the tile says so. See Install system packages and apply updates. Also keep your applications up to date: composer audit and npm audit report known vulnerabilities in your own dependencies, which no server setting can fix. PHP versions that have reached end of life (the Runtimes tab marks them) no longer get security fixes: move sites off them. See Choose and switch PHP versions.

4. Protect databases, files and secrets#

• Databases listen on localhost by default. Keep it that way, and give each application its own database user with a long password.
• .env files hold your secrets. SrvYard stores them encrypted and writes them to the server with strict permissions. Never print them in a deploy script, and never commit them.
• Site users. Each site can run as its own Linux user (website isolation, chosen when the site is created and not changeable later), so one compromised site cannot read another's files.
• Backups. A server with no backup is a risk of its own. Send backups off the server. See Schedule database backups.
• Certificates. Serve every site over HTTPS and keep port 80 open for renewals. See Get a free Let's Encrypt certificate.

5. Watch for change#

Hardening is not a one-off. Three cheap habits catch problems early:

1. Alerts. Create monitors for disk, memory and CPU, and turn on the notification channels so alerts reach a person. See Alert thresholds and silencing.
2. The activity feed. Firewall changes, new SSH keys and new daemons show up in the server's Activity tab for 14 days. Skim it weekly.
3. A review. Once a quarter, go through firewall rules, SSH keys, database users and members. Remove what nobody can explain.

Troubleshooting#

• I locked myself out of SSH. Use your provider's console. SrvYard keeps SSH open in its own ruleset, so the block is usually a provider firewall or a deny rule for your address.
• A port is open that I never opened. Another tool or someone with shell access added it. Open Firewall, press Sync from server, and remove the rule. Check the Activity tab and the SSH keys.
• SrvYard reports a changed SSH host key. The machine was rebuilt, or something is impersonating it. Do not reset it blindly. See Fix a server that will not connect.
• Updates never reduce. Packages held back or a broken source. Read the output under Packages.
• I removed a key but the person can still log in. The key may exist under another user or on another server. Check each server's SSH keys tab and the authorized_keys files on the machine.
• My provider's firewall and SrvYard's disagree. The most restrictive of the two wins. Keep the same ports open in both.

Related#

• Open and close ports with the firewall: rules in detail.
• Add SSH keys to a server and to your account: the key library.
• Install system packages and apply updates: keeping software current.
• What SrvYard stores and how credentials are encrypted: the other side of the trust.