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/motdThat 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 > ./excludedfilesThe 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 > ./md5filesThe 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.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 5 of 5.
-
Editorial Corrections
2002-11-07 13:24:16 chromatic |
[Reply | View]
A couple of angle brackets made it through without being translated into HTML entities. As such, the code examples were incorrect. I've fixed them now, and apologize for the inconvenience.
-
sshd
2002-11-05 10:35:11 anonymous2 [Reply | View]
------------------------
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.
------------------------
Don't forget restarting sshd or atleast HUP'ing it ;)
From the sshd man page:
sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name it was started as, i.e., /usr/sbin/sshd
I know this is fairly obvious to most, but for those who are not aware, this may cause a BSD box (with its amazing stability) to be up for quite some time with an "insecure" sshd.
-
Secure Passwords.
2002-11-04 18:19:19 anonymous2 [Reply | View]
I'm not quite sure why people seem to skip this tip over, in my experience.
I've noticed that people tend to choose passwords like jmnd78cb4092x or sdto098243609vcan and consider this to be very secure. It's much more secure than johnnybgood, but you can easily do better.
Add one single punctuation mark to your password. like an exclamation point at the end.
Which password is more secure: "jmnd78cb4092xsdto098243609vcan" or "johhnyb!good"?
Most analysts will tell you that the first password is more secure. But this us usually not the case.
Most people choose passwords that contain only letters and numbers. Therefore, most hackers only try to brute-force (and, for that matter, use dictionary or hybrid attacks) agains passwords contianing only A-Z, a-z, and 0-9. To include punctuation is usually a waste of time, and greatly increases cracking time, so it's usually disabled by default.
This means that an attacker will try to attack your password with every A-Z, a-z, and 0-9 combination possible before failing (QUITE some time later). Only then will they try adding punctuation.
Of course, you can never have a password TOO secure, so long as you can remember it. My password on the systems I admin is a 35-char random jumble of symbols including A-Z, a-z, 0-9, and several types of punctuation symbols (yes, I can remember it all). You're better off going after my SSH server's 2048-bit RSA private key than my password.
"somebody might get access with your rootpassword
"
so .. what?
.. if they can read my ssh-session
they will get my su - password too
ok .. say: "use sudo!" .. yes so what?
.. an attacker gets the same rights
that the user has
so basicly:
-check the fingerprint of the server
that you are connecting to
-use private keys to authenticate
passwords are local on the machine
that you are logging in from
(they are used to unlock your private key)
if you don't trust that machine->
do not login from there!
-you can even have several users with uid 0
each with there own ~/.ssh/authorized_keys
you can do accounting this way too!
with regard to your perl-scripts
-what the f... are they for?
use mtree!
if you do not want to check certain files
-> expand its exclude list
it manages all kinds of stuff for you
(creation of directories, flags/permissions/ownerships ..)
yours
Christian Bahls
[if you want to contact me:
google for my name
use the contact at uni-rostock.de]