When you've completed an installation, support the project by submitting
a 'dmesg'

dmesg displays the contents of the system message buffer. It is most
commonly used to review system startup messages. It is also very useful
to the project to get copies of system messages with each new release.

Downloading packages for installation seems to be the biggest cause
for time delay during a system build process. But that doesn't mean
you need to mirror the full package tree. Once you've completed
your trial/test installations, you have a list of packages that
are installed in your configuration (@ /var/db/pkg).

Improve deployment speed (reinstallations) by having your required
installation packages available locally either on the build CDs
or from a networked internal resource (use Apache, it's easier.)

With packages available locally you can significantly decrease
your full build/restore process to 15 minutes or less.

Tip: Caching Packages

In true Unix fashion, GUI Environments (such as Gnome and KDE) involve
installing a lot of tools, toolkits. Subsequently, installation of
a single binary package generally requires a lot of downloads. For those
of us with slow connections to the Internet, we either pre-cache (download)
all packages or cache downloads so for re-installs and speed deployment on other hosts.

Pre-cached packages are usually made available on our LAN from another machine,
and we can cache packages downloaded during the pkgadd process using the environment
variable PKGCACHE.

Minimal | Common Configuration

Purposing of hosts differs, so there is no consistent set of tools that
are "appropriate" for each system. However, there are some tools that
might be appropriate for your maintainance of any given host.

The following a tools that may or may not be useful on your hosts.
The goal is minimal functionality that can be audited (i.e. we can at least
keep tabs of published vulnerability reports.)

newsyslog - Trim Log Files

Log files can be your single largest collection of 'growing' files.
Make sure you understand, know where it is stored on your system
(normally /var/log) and you maintain a vigilant watch over the
standard files, and application log files (e.g. Apache in base
will normally retain it's logs in /var/www/logs)

Today's large capacity drives have significant storage capacity
for most server requirements, but everything is dependent on
your log maintenance policies, data and log growth.

Verify

Verify that typing errors do not cause problems with your installation
by launching newsyslog in verbose mode, without performing the log
trimming.

$ sudo /usr/bin/newsyslog -nvv -f /etc/newsyslog.conf

inetd.conf

Remove all unnecessary services listed on inetd.conf.

Take a look at the services listed in inetd.conf and if you don't understand
what it is doing, look it up. If you don't need it, then disable it.
If you need the service, is there another way of securing the service
(such as authentication or data encryption.)

Remove all service settings and only reconfigure services that are specifically
to be secured and used. Whether the removal of these services, provides any
additional security is another debate for another forum.

In general, choose services that are secureable daemons with good security
practises, or set as local access only while another secure transport is used
for accessing the server (such as ssh or ssl tunnels.) For example, we
often use pop3 secured as below.

$ grep -v "^#" /etc/inetd.conf | grep -v "^;" | grep -v "^$"

127.0.0.1:pop3 stream tcp nowait root /usr/sbin/popa3d popa3d

In the above example, pop3 is available only from the localhost (by
implication a user has to be authenticated onto the host before
they can gain access to pop3, which will again authenticate them.)

Restart the inetd daemon by passing a HUP signal.

$ sudo kill -HUP `cat /var/run/inetd.pid`

Audit the above changes using the `grep' sequence of commands as well as
using 'nmap' discussed further below.

Verify

[ ]

Verify that the inetd.conf file is configured correctly by manually connecting the
the specified services.

For our above configuration, a validation would be:

$ telnet 127.0.0.1 pop3

Ensuring that the responses from the server is 'correct.'

pf.conf - Packet Filter Configuration

OpenBSD 4.6 and later releases enable the firewall by default.

Remember to enable IP Forwarding if you intend to release this box as a firewall.

Refer to the PF FAQ for current details: http://www.openbsd.org/faq/pf/index.html

Extended test mode. check the validity of the configuration file, output the effective
configuration to stdout and then exit. Optionally, Match rules may be applied by
specifying the connection parameters using on or more -C options.

audit - sshd_config

There are a number of different things that can go wrong with your
sshd configuration that can potentially keep you off your box.
It is important to test remote boxes carefully before fully enabling
changes to your configuration file.

Check /var/log/authlog for current access behaviour.

If you are seeing "sshd[####]: Accepted password for ..."
then your sshd configuration
is using PasswordAuthentication and your user-account may
have a broken public-key/private-key combination.

Basic syntax configuration changes can be validated with the -t
command-line option

-t Test mode. Only check the validity of the configuration file and
sanity of the keys. This is useful for updating sshd reliably as
configuration options may change.

$ sudo /usr/sbin/sshd -t

Other changes can have more subtle circumstances. For example,
do not disable password authentication until you are sure that the
public key authentication is working correctly.

Start sshd with the new configuration on another port with something
similar to the below

$ sudo /usr/sbin/sshd -ddd -p 9999

SSHD is now running in the foreground to a user-defined port.
Track access behaviour in /var/log/authlog.

audit - sysctl.conf

The `only' way to validate the syctl.conf changes are functioning is to restart
the machine and verify each entry update is correct. For example, if the
above net.inet.ip.forwarding entry has been made, then after a restart
a successful change will show the following:

The best way of keeping tabs of security updates to the OpenBSD ecosystem
is to follow the mailing lists.

The web interface for reviewing changes, are a smaller subset of
reported updates normally available in the web Errata and Current Changelog.

The Errata pages list updates (and where possible, patches) for Stable releases
of OpenBSD. The url/filename for errata pages are usually in the form
errataXY.html where XY is the major/minor version numbers.

Changelogs show many of the machine-independent changes between the previous
release and the versioned release. This lists further service/application
specific updates that may be useful in your environment.

For example:

Current Changelog normally has the changes between
the latest "stable" release and current code development.

plus49.html holds the changes between
the OpenBSD 4.8 release and OpenBSD 4.9.

plus20.html holds the changes between
the OpenBSD 4.8 release and OpenBSD 4.9.

Note, that not all updates are listed on these pages. For a more complete
list of changes, you can follow the source code updates at source-changes,
or ports-changes mailing list.

monitor's cron

Basic monitor user configuration includes maintaining current state of peer
hosts not accessible from other hosts. The backup.peer.configs.sh script is
responsible for hosts hidden behind this host (such as CARP peers without
accessible IP addresses, or hosts behind a firewall.)