Establish a Conservative Security Baseline

Synopsis #

OpenBSD begins with a small enabled-service set and integrated exploit mitigations. A useful hardening baseline preserves those defaults, removes unnecessary authority, and makes changes observable and recoverable. 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. Service-specific policy still belongs in the relevant Handbook chapter and threat model.

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
# 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
# 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:

# syspatch
  # Apply available base-system errata patches on a supported release
# fw_update
  # Update installed firmware packages
# 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:

# 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:

# rcctl disable exampled
  # Prevent the daemon from starting at future boots
# 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;
  • permit established state through explicit pass rules;
  • 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:

# pfctl -nf /etc/pf.conf
  # Reject syntax errors without changing the active ruleset
# 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:

# test -e /etc/example.secret || 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 provides a tested workflow.

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