Simple Things to Improve Your System's Security

First, I'd like to thank all of the readers who sent me their suggestions
on what they'd like to read about in the future installments of
this series. Your input is very valuable to me, because I do not
want to write about things you are not interested in. The list of
topics is very long and I will have to sort it into thematic units
that can be covered in one or more articles, but among your suggestions
are also topics that can be bundled together with others in a form
of a list of tips. And this time, we'll take a break from pf
and discuss small and simple things that you can do to improve the security of your OpenBSD system.

Do Not Allow root Logins Over SSH

This is something you should turn off as soon as you install
OpenBSD. Logging in as root over networks, whether they are public
or private, is bad practice from the point of view of security.
You should never trust your network, and assume that the traffic
might be sniffed. And it doesn't matter that you are using SSH;
always assume the worst. The good practice is to log in as an ordinary
user and then use su to become superuser, or, even
better, use sudo to execute commands you need to run
as root. (As it happens, ONLamp.com has two articles about
sudo by Michael Lucas, "Eliminating Root with Sudo"
and "Sudo Aliases and Exclusions.")

To turn root logins off, edit /etc/ssh/sshd_config
and change

#PermitRootLogin yes

to

PermitRootLogin no

Save changes to make them permanent, and you won't have to worry
about it anymore.

Learn to Use Groups and File Permissions

Juggling file permissions takes some practice, but those who master
it will end up with a more secure system and less headaches. To
help you with that, ONLamp.com published an interesting article, "Using Groups to Eliminate Root," by Michael Lucas. Read it and apply that knowledge
in practice.

Learn to Use File Flags

Properly used, file permissions, ownership, and groups can greatly
enhanced the overall security of your system, as shown in the default
OpenBSD configuration. However, OpenBSD (and other BSD systems)
provide an additional file protection mechanism known as file flags.
Every file can have a number of flags (listed in man
chflags and man 2 chflags), out of which the
following are particularly interesting, from the point of view of
system security:

sappnd: system append-only, only superuser can write to this file and even then, any writes are in append mode (information is added to the end of the file, without overwriting earlier information).

schg: system immutable, only superuser can change, move or delete this file.

uappnd: user append-only, only owner and superuser can write to this file and even then, any writes are in append mode (information added to the end of the file, without overwriting earlier information).

uchg: user immutable, only owner and superuser can change, move or delete this file.

To set flags, use chflags, e.g.:

$ chflags uchg ./signature

To unset flags, add no prefix, e.g.:

$ chflags nouchg ./signature

Once sappnd and schg flags are set,
they can only be unset while the system is at security level 0 or
-1. Not even root can change these flags in any other mode.

You can check file flags with ls -lo (compare its
output with that of ls -l).

How do file flags help? Well, if you set schg flags on binaries,
the attacker cannot modify them and insert rogue code. Similarly,
if you set that flag on files in the /etc directory,
nobody will be able to make changes to them.

Change /etc/motd

Every time you log on to your OpenBSD box, you are greeted with
this message:

Last login: Fri Sep 13 23:08:33 2002 from basket.foo.bar
OpenBSD 3.1 (GENERIC) #59: Sat Apr 13 15:28:52 MDT 2002
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

This innocent-looking greeting is very valuable to attackers,
who have much greater chance of succeeding in their malicious
attempts if they know what type of system they have broken into.
Of course, an experienced hacker will always find ways to quickly
identify the system, but the system ought to make life a little harder for
rookies. So it is prudent to hide that information from those who
don't need to know, i.e. everyone but the system administrator, who
by definition ought to know what system he or she is administering.
The message of the day is stored in /etc/motd. It is
a simple text file and you can create your own replacement
/etc/motd using vi or any other plain-text editor. Remember that you should not reveal the nature of the
system, so avoid mentioning the name of the system or even its type.
You can set it to something silly, like:

I find your presence disturbing. I will watch your every
step while you are here.

Now, this not exactly a warm welcome, but so what? Security is
not about being warm and fuzzy. If you want, you can include the
phone number or the e-mail address of the help desk, but some
administrators say it is a bad practice, as administrators
and their personnel are also vulnerable to sophisticated social
engineering techniques applied by hackers. In any case, the less
information you give out, the better. If you don't want to display
greetings at all, just do:

$ /dev/null > /etc/motd

That will keep OpenBSD from saying anything at all.

Use Long and Secure Passwords

Yes, this has been beaten to death, but you really ought out to
use long and difficult-to-guess strings. For example, instead of
jonnyBgood, use something like J04iye85ut42y.
This is much harder to type, but is also much harder to guess or
crack.

Create MD5 Digests and Compare Them Regularly

Because even the simplest default OpenBSD installation contains
hundreds of files and directories, it is virtually impossible to
watch them all and detect changes made to them. Of course, you
could write a script that checks file sizes and creation or
modification dates, but these security measures are rather weak -- dates
can be modified and changes to files do not have to result in changes
in size of the affected files.

A much better mechanism for detecting changes are checksums
generated by sum, cksum, md5,
rmd160, or sha1. For example, when you
download a new release of OpenBSD, a patch, or a package, the
distribution sites publish checksums for every file. After you
download the chosen file, you ought to run cksum or
md5 (it depends on which algorithm was used) on that file and compare the results with the checksum published on the site
from which you downloaded your files. When these results do not match,
you may have downloaded rouge code and you should delete such files
immediately. (Note that checksums generated by cksum,
md5, and other commands are computed using different
algorithms, so if md5 generates a strange-looking
result, check if the original checksum was perhaps computed using
cksum.)

The beauty of checksums is the fact that even a change of one
byte in a file generates a different checksum, so any modifications
made to files can be detected immediately.

OK, but how do you detect changes in hundreds of files? Apply
a touch of Perl, for example. The following two scripts,
makefilelist.pl and makemd5list.pl, will
help you manage the list of files you want to run md5
on.

The result of running this script is a list of all files and
directories on your system. Generating it may take a while, but
you will only have to do it once. Once makefilelist.pl
is done, edit excludedfiles and remove all entries
except those that you do not want to compute MD5 digests for. You
have to do this for two reasons: you do not want to compute MD5 digests
for files that are constantly changing, like system logs or files
in users' own directories, and to shorten the time it takes to
compute MD5 digests -- you don't really want to do it for every file
on your department's file server. Also, some files in the
/dev directory, like /dev/random, will
hang md5 indefinitely, so they are prime candidates for
exclusion.

Fortunately, you only have to create this file once, and then
maybe add an odd file or two to the list from time to time. And anyway, if you
had been looking for a good excuse to finally learn all of those
vi commands for wholesale editing of large files, you
have just found one.

Once you're done editing, save it and run the second script to
generate MD5 digests for all files that are not on the list of
excluded files.

The whole operation may take a while, especially when you are
letting makemd5list.pl run on your departmental file server.

You should run makemd5list.pl at least once a day,
but running it more often is even a better idea. Once an hour is
not too cautious. After every run of makemd5list.pl,
compare its results with the previous results using comm
(read man comm) and check any discrepancies. Any
changes in binary files or configuration files ought to be treated
with utmost suspicion and investigated ASAP.

Jacek Artymiak
started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs devGuide.net, writes and teaches about Open Source software and security, and tries to make things happen.