This is a small quick and dirty doc to locking down openbsd.
This document is by no means complete and there could be mistakes...
This assumes a working knowledge of unix in general and you have some idea
of how to use vi, ps, kill, etc etc...

The process begins with your install...It is advised you don't install
any compilers, X, games etc... that only a base install (base + etc + bsd ) 
be installed. If you are doing this in a large production environment it is often
a good idea to have one machine with a compiler which will then build the binary files
for the rest which can be mounted off nfs.


It is expected that from here on in, your machine (on first boot with openbsd) should not be connected
to any public networks.

First I suggest you comment out ALL services in /etc/inetd.conf, the most used
are telnet and ftp, both can be replaced with sshd. It is often a good idea to netstat -a | grep LISTEN
to see what is running, I believe you just take a paranoid approach and force yourself to justify each port open.
Now it is time to take a look at all SUID binary files, once again having to justify these in a production environment
is a very good idea. You should leave yourself with less than a handful of SUID binary files, however this can vary
depending on the task of your machine, if it is an all round server then it could have more, if it is just
let's say a nameserver, then having uucp, mail etc... binaries with suid or setgid bits set is often silly.

Since you will be using SSHD to connect to the machine and have remote access, it is a good idea
to not just use passwords, but to use keys. Keys not only make life easier (especially with a large
number of machines, due to ssh-agent) on the sys admin, but makes life more secure too.
Using private RSA keys is a very good idea and should be encouraged.


For root access to a machine, sudo should be the normal solution, it can be used with your normal password,
or using something like kerberos integated with sudo to allow for a stronger authentication system
with logging of commands.

Venturing off a little...back to an example, which would be that sshd should nearly always be turned on.
Well this is true, however from a network level you need to ask yourself who needs access,
can you put in one modem with callback and deny the outside world access to sshd.
Personally I think the trade off with ease of use and having setting up good remote access
is worth it, I know many people who always trusted sshd and had no issues leaving the world see it,
however when a remote root came out and they were a few hours late (while asleep) patching
the systems, they were rooted.
Generally a deny all on the gateway/firewall on the way in is a good idea, then allow specific ports
to specific hosts, only.

This is, to say the least a work in progress, but I will be adding more soon.