Establish a Conservative Security Baseline

Synopsis #

OpenBSD begins with a small enabled-service set and integrated exploit mitigations. A useful security baseline preserves those defaults, restricts privileges, records changes, and provides a recovery procedure. It does not consist of an imported sysctl list, a third-party kernel, or disabling platform security mechanisms to make applications work.

This guide establishes a conservative host baseline. Use the relevant Handbook chapter to configure each exposed service.

Record the System Role #

Document the host’s purpose, administrators, exposed services, management networks, data sensitivity, backup destination, and recovery path. Every enabled daemon, listening socket, package, privileged account, and PF exception should support that role.

Capture the starting state:

uname -a
  # Record release and architecture
doas rcctl ls on
  # List daemons enabled through rc.d
netstat -na -f inet
  # List IPv4 sockets without name lookups
netstat -na -f inet6
  # List IPv6 sockets without name lookups
doas pfctl -sr
  # Display the active filter policy

Keep this inventory with change records, not in a public report when it reveals internal addresses or services.

Establish Administrative Recovery First #

Create and verify a named administrator account, SSH key, and doas(1) policy before restricting remote access. Create an Administrator Account provides the complete workflow.

Maintain an independent recovery route such as an authorized console, provider console, or tested local access path. Keep an existing SSH session open while changing SSH or PF policy, then prove a new session works before closing it.

Apply Supported Updates #

Use signed OpenBSD mechanisms for each maintenance layer:

doas syspatch
  # Apply available base-system errata patches on a supported release
doas fw_update
  # Update installed firmware packages
doas pkg_add -u
  # Update installed third-party packages

Release upgrades are separate and must follow the current official upgrade guide. See Update and Upgrade OpenBSD . Unsupported releases do not become secure through local hardening alone.

Minimize Enabled Services and Packages #

Review enabled daemons and installed packages:

doas rcctl ls on
  # Review every enabled base and package daemon
pkg_info -mz
  # Record manually installed package stems

Disable a daemon only after confirming that the host role and dependent services do not require it:

doas rcctl disable exampled
  # Prevent the daemon from starting at future boots
doas rcctl stop exampled
  # Stop the current instance after dependency review

exampled is a placeholder, not an OpenBSD service. Do not paste the example unchanged.

Remove unused packages with pkg_delete(1) after reviewing reverse dependencies and retained configuration. Fewer installed components reduce maintenance work, but indiscriminate removal can break the documented host role.

Restrict Network Exposure #

Bind services to the required addresses and apply an explicit pf.conf(5) policy. A host policy should normally:

  • block unsolicited inbound traffic by default;
  • allow required new connections with stateful pass rules; packets matching an existing state do not require a separate established-traffic rule;
  • expose only required ports on intended interfaces;
  • restrict management services to administrative sources where practical;
  • retain ICMP and ICMPv6 required for correct network operation;
  • log selected policy failures without creating an unbounded log stream.

Parse a complete ruleset before loading it:

doas pfctl -nf /etc/pf.conf
  # Reject syntax errors without changing the active ruleset
doas pfctl -f /etc/pf.conf
  # Load the rules only after parsing and recovery review

Use Configure Secure Remote Access with OpenSSH and the PF chapters for complete policies. Port changes and address hiding do not replace authentication or patching.

Protect Secrets and Configuration #

Review ownership and mode on private keys, password databases, VPN configuration, backup credentials, and automation material. Use a restrictive creation mode before writing a secret:

doas test -e /etc/example.secret || doas install -o root -g wheel -m 600 /dev/null /etc/example.secret

/etc/example.secret is a placeholder. The existence test prevents truncation. Apply the pattern only to a configuration file whose daemon documentation requires it.

Do not grant broad supplementary groups, device access, or passwordless doas merely to bypass one application error. Treat an automation account with unrestricted passwordless doas as a root credential.

Preserve OpenBSD Security Mechanisms #

pledge(2) and unveil(2) are application mechanisms, not global tuning switches. Package-provided policies should remain enabled unless a maintained package README requires a narrow local exception.

Do not raise kern.securelevel or set immutable file flags as a generic checklist item. These mechanisms can prevent package maintenance, PF changes, log rotation, or recovery. The Security chapter explains their administrative tradeoffs.

Make Failure Visible and Recoverable #

Direct root mail to an actively read mailbox, review failed daemons and logs, and establish capacity and update checks. Monitor an OpenBSD System provides the baseline.

Back up data and locally changed configuration to independent storage, then perform test restores. Protect backup credentials and encryption material separately from the host. Back Up and Restore an OpenBSD System describes backup creation and restore testing.

After each policy change, verify the intended service from its client network and verify that an unintended path remains blocked. Record the command, configuration revision, result, and rollback method.

Report a bug