Synopsis #
OpenBSD integrates exploit mitigations, privilege separation, conservative service defaults, signed updates, and auditable base-system configuration. Host security still depends on maintained software, deliberate access policy, restricted service exposure, protected secrets, useful monitoring, and tested recovery.
This chapter explains the security mechanisms and their administrative boundaries. Establish a Conservative Security Baseline provides the ordered implementation workflow.
Preserve the Supported System Model #
OpenBSD is maintained as a complete base system. Keep the kernel and base userland from the same supported release or snapshot, apply errata with syspatch(8) , update firmware with fw_update(8) , and maintain third-party packages with pkg_add(1) .
Do not replace the GENERIC kernel, copy libraries from another release, or import kernel tuning from another operating system as a hardening measure. Unsupported combinations remove the tested assumptions on which OpenBSD security work depends.
Accounts and Administrative Authority #
Use named accounts for administration and grant only the required doas(1)
authority through doas.conf(5)
. A rule without a cmd restriction can authorize any command as the target user. A nopass rule transfers that authority to possession of the account’s session or SSH key.
Adding supplementary groups can grant device, log, or administrative access. OpenBSD usermod(8)
replaces the supplementary group list supplied with -G; preserve every intended existing membership when changing it.
Store password hashes in the protected master password database, change them with passwd(1)
, and disable accounts through documented account-management fields. Changing a shell to nologin affects interactive login but does not by itself terminate processes, revoke keys, remove scheduled jobs, or disable every service identity.
Create an Administrator Account and Configure Secure Remote Access provide complete, lockout-safe procedures for administrative delegation and SSH access.
Remote Access #
OpenSSH in base provides encrypted remote administration. Prefer named accounts and verified public-key authentication, keep direct root login disabled, and test new policy through a second connection before closing the recovery session.
Do not freeze cipher, key-exchange, or MAC lists from an old guide. OpenBSD updates default algorithm policy with the base system. Override an algorithm only for a documented interoperability requirement and remove the exception when it is no longer needed.
See Configure Secure Remote Access with OpenSSH for the lockout-safe procedure.
Services and Network Policy #
Most network services are not enabled automatically. Review enabled daemons with rcctl(8) , bind services only to required addresses, and use pf(4) to enforce the host or gateway policy.
PF does not correct an unsafe daemon configuration, and a loopback or management-address binding does not replace PF. Apply both layers, retain required ICMP and ICMPv6 behavior, parse the complete ruleset before loading it, and keep a recovery path for remote changes.
Permissions, Secrets, and Device Access #
Standard ownership, mode bits, groups, and process credentials are the primary filesystem controls. Create private keys and secret-bearing configuration with restrictive modes before writing content. Do not make device nodes or secrets world-readable to resolve one application error.
OpenBSD also supports file flags through chflags(1) . Immutable and append-only flags can protect a carefully selected file, but they also complicate upgrades, package maintenance, log rotation, and recovery. Record every flag and its removal procedure before adopting it.
Securelevels #
The kernel securelevel(7) restricts operations as the level rises. The normal boot process manages the standard level. Higher levels can prohibit raw disk writes, PF changes, and removal of system immutable flags.
Do not raise the securelevel as a generic checklist action. First identify the exact operation to prohibit, confirm the host can operate and be maintained under that restriction, test the boot and recovery path, and document how authorized maintenance will occur. A firewall that cannot receive an emergency rule update or a server that cannot rotate protected logs can become less resilient.
Application Isolation #
pledge(2) restricts the system-call capabilities an application retains. unveil(2) restricts its visible filesystem paths. Base programs and packaged applications can apply these mechanisms internally or through package-provided policy.
They are not global administrator toggles. When an application reports a pledge or unveil failure, read its installed package README, reproduce with a clean profile or minimal configuration, and make only a narrow documented exception. Disabling isolation permanently hides the defect and expands application authority.
Privilege-separated and chrooted daemons divide work among processes with different credentials and filesystem views. Preserve their packaged users, directories, ownership, and startup method unless the daemon manual documents a different design.
Integrity and Change Detection #
mtree(8) can compare filesystem metadata against a specification. Integrity evidence is useful only when the baseline was created from a trusted state, stored where an attacker cannot rewrite it, and reconciled with legitimate updates.
Package inventories, configuration version control without secrets, signed release metadata, and tested backups provide complementary evidence. A rootkit scanner running on a potentially compromised host cannot establish that the kernel or its own results are trustworthy.
Logging and Monitoring #
Direct root mail to an actively read account. Review authentication, daemon, system, PF, capacity, sensor, and update signals at an interval appropriate to the host role. Protect logs from unauthorized reading as well as modification because they can contain account names, internal topology, message metadata, and command details.
Monitor an OpenBSD System establishes a base-system monitoring path. Remote logging can preserve evidence after host loss, but the collector and transport require their own access policy.
Recovery and Incident Handling #
Security controls must preserve an authorized recovery route. Maintain tested console access, current backups, encryption recovery material, and a procedure for boot, filesystem, and account failures.
When compromise is suspected, avoid relying on the affected host to prove its own integrity. Isolate it according to the incident plan, preserve required evidence, rotate exposed credentials from a trusted system, and rebuild from verified OpenBSD media when integrity cannot be established. Restore only reviewed data and configuration.
See Back Up and Restore an OpenBSD System , Recover a System That Does Not Boot , and Collect OpenBSD Diagnostic Evidence .