Simple Things to Improve Your System's Security
Pages: 1, 2

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.

#!/usr/bin/perl -W
#
# makefilelist.pl -- create a list of all files with full access
#                    paths
#                                   Copyright 2002 Jacek Artymiak
#                                                License: XFree86
#----------------------------------------------------------------

open (FILES, "ls -Rp1 /* |") or die "Couldn't open file list: $!";

while (<FILES>) {

        chomp;

        # make new path

        if (/^\/.*:$/) {
                $newpath = substr($_, 0, length($_) - 1) . "/";
                next;
        }       

        # skip empty lines

        if (/^$/) {
                next;
        }

        print $newpath . $_ . "\n";
}

close FILES;

Make makefilelist.pl executable and run it to create a list of files:

$ chmod 0700 ./makefilelist.pl
$ ./makefilelist.pl > ./excludedfiles

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.

#!/usr/bin/perl -W
#
# makemd5list.pl exclude_files  -- create a list of MD5 digests 
#                              for all files except exclude_files
#
#                                   Copyright 2002 Jacek Artymiak
#                                                License: XFree86
#----------------------------------------------------------------

open (SKIPFILES, "< $ARGV[0]") or 
                        die "Couldn't open skipped file list: $!";
open (ALLFILES, "ls -Rp1 /* |") or 
                        die "Couldn't open file list: $!";

$n = 0;
while (<SKIPFILES>) {
        chomp;
        $skiplist{$_} = $n++;
}

while (<ALLFILES>) {

        chomp;

        if (/^\/.*:$/) {
                $newpath = substr($_, 0, length($_) - 1) . "/";
                next;
        }       
        if (/^$/) {
                next;
        }

        $newfile = $newpath . $_;

        if (exists($skiplist{$newfile})) {
                next;
        }

        print `md5 $newfile`;
}

close ALLFILES;
close SKIPFILES;

Make makemd5list.pl executable and run it to create a list of MD5 digests of all files not on the list of excluded files:

$ chmod 0700 ./makemd5list.pl
$ ./makemd5list.pl ./excludedfiles > ./md5files

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.

Well, that's it for this week, more tips next time.

PS. The scripts are available here.

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.

---

Read more Securing Small Networks with OpenBSD columns.

Return to the BSD DevCenter.