Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!spaf
From: spaf@cs.purdue.edu (Gene Spafford)
Newsgroups: news.sysadmin
Subject: Re: Security checkup
Message-ID: <5014@medusa.cs.purdue.edu>
Date: 3 Oct 88 15:34:02 GMT
References: <167@carpet.WLK.COM>
Sender: news@cs.purdue.EDU
Reply-To: spaf@cs.purdue.edu (Gene Spafford)
Distribution: na
Organization: Department of Computer Science, Purdue University
Lines: 67


Here's a very rough list of things to check:

1) make sure / /bin /usr /usr/bin /etc /usr/spool 
and any other bin directories are all mode 755 or less (ie, 555,
751, etc).

2) Allow NO accounts without passwords, including uucp.

3) Don't have any accounts other than root with uid 0

4) Make sure no files in any bin or /etc are writeable by anyone
other than user root (or bin, if you have things set up that way --
if you do, don't have bin's entry in /etc/passwd with a
runnable shell or password).

5) crontab, mem, kmem, uucp/L.sys should not be readable by
world.  Crontab should probably be mode 600.  The rest should
be something like 440.  Programs that read kmem to display
status should be setGid to some group (named, kmem, for instance).

6) On many systems, "at" is a security hole.  If no one uses it,
disable it.

7) Don't run anything out of crontab as root unless you absolutely
must.  For instance, to run the nightly news scripts, use "su"
in the crontab file to run the scripts as user news.
E.g.,
40 1 0 0 0	su news </usr/lib/news/nightly

8) Keep a list of all setuid/setgid files on your system (use
"find", for instance).  Keep the list off-line.  Recheck it
periodically and see if any files have changed size or modification
time (or had those bits added or deleted).

9) If your system logs bad login attempts to the console, or
bad attempts to change passwords, then be sure to audit your
logs -- frequently!

10) On BSD systems, don't have any setuid/setgid shell scripts --
unless you know that the security hole with them has been fixed
on your system.

11) Don't have the "." directory in the PATH variable for root
or for any privileged user.

12) Don't have any special versions of "su" around that don't
require a password.

13) If you're running in an NFS environment, don't have
any workstations located where untrusted individuals can
reboot them.


None of these is hard and fast "must do's", but if you don't
understand why I recommend them, you probably shouldn't
avoid them.  I know how to use all but 8 & 9 to break into
systems, and I am certainly not the only one.  There are other
considerations, but they are more specific and might give
clues to someone wanting to know how to break into a system,
so I won't go into detail here.

-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf