Simple Things to Improve Your System's Security (OpenBSD -- zt)

cobrawgl

Jacek Artymiak returns with a grab bag of simple ways to enhance the security of your system. These techniques apply to OpenBSD in specific, the BSDs in general, and most Unixes.

1.Simple Things to Improve Your System's Security
http://www.oreillynet.com/pub/a/bsd/2002/10/31/ssn_openbsd.html


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.

#!/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 is a freelance consultant, developer, and writer.