10. Security#

OSM is built to be safe by default: the web desktop asks for an account first, the part of OSM that faces the network has no privileges, and every change goes through a small, checked core. The Security overview explains the design. This chapter covers what you control.

A checklist#

1. Turn on two-step sign-in or a passkey for every Administrator (My Account).
2. Leave automatic security updates on (Settings > Updates and Recovery).
3. Keep the firewall on, and open nothing on your router that you do not need. To reach the server from outside, prefer the VPN or remote access to forwarding the web desktop's port.
4. Use a trusted certificate if the server is reached by name from outside (Let's Encrypt).
5. Back up to a place other than the server's own disks, and keep immutable snapshots of what matters most.
6. Run Security Check now and on a schedule, with its report by email.
7. Give people only the access they need: Standard users rather than Administrators, shared folder permissions, App Permissions.

The firewall#

Settings > Security > Firewall. The firewall is on by default: only the ports of the services and apps you run answer, and its page lists them. It also lets you:

• Always let in (every port), or Never let in, addresses and networks;
• block countries, or let in only the countries you choose (Who may connect, from the Internet registries' lists). Your local network is never blocked.

These lists apply to the server's own services and to the ports that container apps publish. OSM refuses a change that would shut out the browser you are using.

While the firewall is on, the services meant for your network alone (the monitoring exporters, SNMP, the syslog server, the domain controller, a UPS shared with your other servers) answer only to your local network. Each app can also have network rules of its own. An app with an address of its own on your network, like a virtual machine on the bridge, is a separate device: the firewall does not stand in front of it, and it has no network rules, so set its rules on your router.

Security Check#

Security Check looks at the settings that matter most: updates, SSH, the firewall, two-step sign-in, the certificate and more. Red comes first; Fix does it for you where it can, Open shows the setting.

• On its own: every day, week or month, with a report by email if you want, and a notification when it finds a problem.
• Vulnerabilities: the known vulnerabilities (CVEs) of the installed software, from Debian's security tracker, and which ones an available update fixes.

Antivirus#

Install Antivirus from the App Catalog (ClamAV). It scans the shared folders you choose, now or every night or week, at low priority so the server stays responsive. What it finds goes into the volume's quarantine (or is only reported, as you choose), where nobody can open it: put a file back only when you are sure, or delete it. Its signatures update every day by themselves.

Sign-in protection#

• Addresses are paused after repeated failed sign-ins, and sign-ins end when idle. If you turn on Lock an account that keeps failing in Settings > Security > Account, accounts are locked after repeated failures too (Accounts).
• Password reset by email, in the same tab, lets people reset a forgotten password from the sign-in page with a link sent to their email address. It works once email is set up in Settings > Notifications.
• Settings > Security > Signed in lists the current sign-ins and ends any of them.
• Logs, source Administrator actions, records every change made in the web desktop, with an API token or with the osm command. Changes made in a shell with sudo are not in it: the source Sign-ins and sudo shows the commands run with sudo.
• Settings > Desktop Access > More host names: the desktop answers to an IP address, to the server's name (alone or followed by .local), to localhost, osm.local and osm-installer.local, and to the names you add here. It refuses other names, which stops DNS rebinding.

Encryption#

• The system: OSM and its settings, encrypted at installation if you choose, unlocked by the TPM or a passphrase (Installation). The volumes are not part of it: encrypted shared folders protect files.
• Shared folders: encrypted folders, locked and unlocked with their password (Shared folders). Unlock at start-up keeps a folder's password on the server, so that the folder unlocks by itself.
• Backups: always encrypted with the task's password (Backup).
• On the network: the web desktop is HTTPS only; SSH and the VPN are encrypted; SMB is signed and encrypted when the computer asks for it. NFS and Media Streaming are not encrypted, and FTP is encrypted only with FTPS: keep those on your local network.

Whoever has the server in hand#

Someone at the server's keyboard and screen can give an Administrator a new password (key R on its screen), and start the server in recovery mode, a root shell that asks for no password. That is by design, as on any computer, so that you can always get back in: keep the server where strangers cannot reach it.

Encrypting the system protects OSM and its settings on disks taken out of the server, not your volumes. With the TPM, the server starts by itself, so a stolen server starts too, reset menu included. If the whole server could be stolen, keep what matters in encrypted shared folders, and either unlock the system with a passphrase typed at every start, or do not use Unlock at start-up for those folders.

Reporting a vulnerability#

To report a vulnerability in OSM, follow SECURITY.md. The server publishes the same contact at https://<server>:5001/.well-known/security.txt.