Security, Maintenance and Recovery on OpenBSD Handbook

Establish a Conservative Security Baseline

Mon, 01 Jan 0001 00:00:00 +0000

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.

Recover Access and Reset the Root Password

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

An administrator with authorized console access can reset the root password from single-user mode. The procedure boots a minimal root shell, checks and mounts the installed filesystems read-write, runs passwd(1) , and resumes multiuser operation.

This is a recovery procedure for systems under the administrator’s control. Console access is a privileged security boundary. Encrypted root storage still requires its passphrase or keydisk before single-user mode can reach the installed system.

Collect OpenBSD Diagnostic Evidence

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Useful OpenBSD diagnostics identify the failing layer, preserve the first error, and include enough system context to reproduce the problem. A complete dump of /etc, /var/log, or a user profile usually adds secrets without clarifying the failure. This guide explains what to collect for troubleshooting, support requests, and bug reports.

Collect evidence as soon as practical after the failure. Rebooting, restarting a daemon, loading a new PF ruleset, or updating packages can erase the state that explains the problem.

Troubleshoot Package Installation and Update Failures

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

OpenBSD packages are built for a specific architecture and base-system branch. Most pkg_add(1) failures result from an unsupported release, an unexpected package source, a base/package mismatch, temporary snapshot lag, an unavailable package or flavor, or an interrupted transaction.

This guide preserves the first error, identifies the branch and source, and restores consistency before attempting repair. It does not use force flags, unsigned repositories, database deletion, or manual library copying as general remedies.

Schedule Recurring Maintenance

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

OpenBSD uses cron(8) for scheduled commands and runs the base-system daily, weekly, and monthly maintenance scripts from root’s crontab. Local jobs should run as the least-privileged suitable account, use explicit paths, prevent unintended overlap, and report failure to a monitored mailbox.

This guide adds one local job, verifies its non-interactive behavior, and explains when to use a user crontab or a daily.local file. It does not place credentials directly in a crontab or modify the base /etc/daily, /etc/weekly, or /etc/monthly scripts.

Monitor an OpenBSD System

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Start with OpenBSD’s base tools for local monitoring before adding an external platform. This guide covers resource use, services, hardware sensors, logs, scheduled reports, updates, and optional remote monitoring.

Monitoring must produce an actionable signal. Record normal values before setting thresholds, direct root’s local mail to an actively read mailbox, and test each notification path.

Establish a Resource Baseline #

Use systat(1) for interactive views and vmstat(8) for interval samples:

Back Up and Restore an OpenBSD System

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

A usable backup has an independent copy, a known retention policy, integrity checks, and a tested restore procedure. OpenBSD provides dump(8) and restore(8) for FFS filesystems, plus the /altroot facility for a local root-filesystem copy.

RAID, disk encryption, and /altroot solve different problems. RAID preserves availability after some disk failures. Encryption protects confidentiality. /altroot provides a nearby root copy. None replaces an offline or off-host backup.

Inventory the Restore Scope #

Record filesystems, disklabel UIDs, mount options, softraid volumes, boot method, and installed packages:

Configure softraid RAID1

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

The RAID 1 discipline of softraid(4) mirrors data across two or more chunks. The assembled volume appears as a normal sd(4) disk and is partitioned and formatted at that virtual layer.

RAID1 improves availability after a component failure. It does not protect against deletion, corruption, compromise, fire, theft, or an error applied to the mirror. Maintain and test independent backups.

This procedure destroys all data on the selected component partitions. Disk names can change whenever hardware or installation media changes. Identify devices by model, size, attachment, and disklabel UID before every destructive command.

Recover an OpenBSD System That Does Not Boot

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Boot recovery starts by identifying the failing stage. Firmware must select a device, primary boot code must load the OpenBSD boot loader, the boot loader must read a kernel, the kernel must select and check filesystems, and the service configuration must reach multi-user mode.

This guide provides a conservative recovery sequence. It does not assume that disk numbers remain the same, and it does not rewrite partition tables or boot blocks until the disk and cause of failure are clear.