To wrap up this series of posts on security tools I’ve written for use on OpenBSD, I want to reiterate how the components work together, and how they raise the cost of attack.

The tools together provide a way for protecting against unauthorized or accidental change (syslock), detecting unauthorized change (sigtree.pl), detecting unauthorized or unusual activity (reportnew), distributing authorized changes securely with verification (distribute.pl, install.pl, and Signify.pm), and moving data securely (rsync-tools).

A few scenarios:

Routine package update: distribute.pl signs (or verifies signature) and pushes, install.pl verifies and installs while using syslock to unlock and relock, sigtree.pl detects the changes on next check, reportnew monitors activity of the _rsyncu user during the distribution.

WAN IP address change: change is detected manually, via reportnew from connection failures, or via a script not covered in this series that I mention below; distribute.pl is used to modify relevant config files, package them up and sign them, and send them to the hosts where they need to be installed, using IPv6 if the primary WAN IPv4 address has changed (since the remote hosts don’t allow connections yet from the new IPv4 address); and install.pl verifies and installs the updated configs.

Security incident response: reportnew alerts on anomalous process accounting logs, sigtree.pl check reveals unexpected file changes, syslock audit shows unexpected unlocked files.

These tools fit into a larger ecosystem with additional controls, one of the most important of which is centralized logging, with mutual TLS authentication. The deployment of reportnew augments centralized logging by providing another mechanism to monitor logs and send alerts off-host to mailboxes which are independent of the centralized logging host. An attacker compromising one host cannot conceal logging and alerting that has already occurred without also compromising at least two additional hosts.

The default permissions on config files (rsync-client.pl, reportnew, distribute.pl) and sigtree.pl specs are intended to keep that information from being used to identify the specifics of what hosts are involved and what is being monitored to identify gaps or what is counted as “normal” and ignored. The use of signed files for reportnew macros and install.pl installations is intended to preclude an attacker from being able to modify or substitute content easily even in the absence of system immutable flags, the use of which raises the bar further. An attacker who gains root on one host still faces locked files they cannot modify without a reboot, signed configs they cannot substitute without a valid signing key, integrity monitoring that will detect unexpected changes, and anomaly detection that will report unexpected activity–all sending alerts to hosts they do not control.

Across these tools, the OpenBSD-first design, the use of pledge and unveil, and the use of privilege separation are all intended to prevent an attacker from being able to subvert the tools in their normal use. All of the tools arose from real operational needs and have been modified as the result of real mishaps (e.g., the deadly typoed rm taking out important files in /etc which prompted expansion of syslock groups and putting fstab into its own group).

No security architecture is perfect–there are always tradeoffs–and this is no exception. By running reportnew every 30 minutes, there’s a 30-minute window of attack. The requirement to shut down to single-user mode to update sigtree.pl primary specs and to do software installations introduces friction and requires downtime. The use of a common signing key is a single point of failure. The goal is not perfection–it’s making unauthorized changes more difficult and more detectable.

Other Scripts

There are numerous other scripts I’ve written over the years that aren’t covered here for a variety of reasons–arguably not “security” tools, much narrower use cases, built as quick hacks not suitable for distribution, etc. One that I left out but which is in good shape and available on Github is faild.pl, which is a daemon that uses privilege separation or can be run in monitor-only mode, to monitor WAN gateways and external hosts for up-time and, optionally, perform failover between WAN connections. (I use it with a dual-WAN Internet setup.) Another which has evolved over time but is a bit hacky is ca.pl, which is scripting around openssl for managing a certificate authority (CA).