The original question was
> From: mlg@cstp.umkc.edu (Meg Grice)
> Subject: Help With Security
>
> Sun Managers,
>
> I manage a heterogeneous network of Sun SparcStations and
> Digital DecStations. Someone has been trying to break-in to
> my computers. Actually, they suceeded about a month ago.
> I disabled the accounts that had been compromised, but they
> seem to be back recently. This is apparently an "inside"
> job not an internet attack.
>
> My configurations are
> SPARCserver 4/390 running SunOS 4.1.1
> SPARCstation 1 running SunOS 4.1.1
> SPARCstation 1+ running SunOS 4.1.1
> SPARCstation 2 running SunOS 4.1.1
> SPARCstation SLC running SunOS 4.1.1
> DECSystem 3100 running Ultrix 4.2
> DECStation 5000/200 running Ultrix 4.2
> (various others)
> I run YP on the Suns and Hesiod on the Ultrix.
>
>
> On the Sun computers, a message is logged to /var/adm/messages
> after the login has failed for the fifth time on a single
> account. Is there a way to change this so that all login
> failures are logged? Does anyone know about doing this
> same thing on Ultrix?
>
> Also, can someone recommend a password checking program.
> The cracker originally gained access by running a phack
> program on the password file. One of the operators had
> a password that was a dictionary word -- lecture has already
> been given to her. I heard that MIT has a good password
> checking program, but do not know what it is called
> or if it is Public Domain. Any suggestions would be
> appreciated.
>
> The cracker has tried to login as various users as well
> as root, bin, uucp, deamon, field, system, admin. I do
> not allow root logins on my systems, but I am concerned
> that sooner or later they will break someone's account
> that is privileged to do something.
>
> The cracker comes in over dial-up lines to a campus
> terminal server. The phone company is willing to
> trace the calls for short periods of time only. Therefore,
> I would like to see if I can figure out a pattern to the
> break-in attempts.
Thanks to the following for replying and any body else that I missed.
-----------------------------------------------------
From: Rick Jones <albert@crick.ssctr.bcm.tmc.edu>
From: phil@pex.eecs.nwu.edu
From: Aydin Edguer <edguer@alpha.ces.cwru.edu>
From: rwolf@dretor.dciem.dnd.ca (Robert J Wolf)
From: stern@sunne.East.Sun.COM
From: John Hasley <hasley@andy.bgsu.edu>
From: jeorg@chs.com
From: bchivers@smiley.mitre.org
From: connie@cec.mtu.edu
From: darin@kaman.com
From: bob@kahala.soest.hawaii.edu
From: David Fetrow <fetrow@biostat.washington.edu>
From: toro.MTS.ML.COM!mike%beethoven@uunet.UU.NET
From: rickz@tfs.COM (Rick Zeller - sysad)
From: tres@roke.rap.ucar.EDU
From: rnw@math.Princeton.EDU
>From feldt@phyast.nhn.uoknor.edu Tue Nov 12 13:30:37 1991
From: sjh@helicon.math.purdue.edu
From: jmcarli@srv.PacBell.COM
From: kwthomas@nsslsun.nssl.uoknor.edu
From: mitch@cirrus.com
From: tjt@cirrus.com
From: Steve Seaney <seaney@robios.me.wisc.edu>
From: poffen@sj.ate.slb.com
From: wes@cco.caltech.edu
From: jet@uh.edu
From: mlf@tcad.ee.ufl.edu
From: smb@ulysses.att.com
From: jem@matt.ksu.ksu.edu
From: etnibsd!vsh@uunet.UU.NET
From: "Fuat C. Baran" <fuat@cunixf.cc.columbia.edu>
From: jwn2@qualcomm.com
From: mcgraw@sunspot.sunspot.noao.edu
From: pomeranz@isis.dccs.upenn.edu
From: admin@summa4.mv.COM
From: lawrence@world.std.com
From: phil@wubios.wustl.edu
From: pla_jfi@pki-nbg.philips.de
From: Konradin Stoehr <topaz@uni-augsburg.de>
From: erueg@cfgauss.uni-math.gwdg.de
From: Ace Stewart <jstewart@zookeeper.cns.syr.edu>
From: jerry%idacrd@Princeton.EDU
From: sherry@hq.af.mil
From: era@niwot.scd.ucar.EDU
From: bit!jayl (Jay Lessert)
From: ellen@acc.com
From: Paul Quare <pq@computer-science.manchester.ac.uk>
From: A.J.C.Blyth@newcastle.ac.uk
From: Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>
From: Calum Mackay <calum.mackay@mrc-applied-psychology.cambridge.ac.uk>
-----------------------------------------------------
I have tried to organize the responses I received into groups of related
topics. The most popular suggestions were to contact CERT, get cops,
and get crack -- (the program not the drug (;-).)
Organizations That Can Help
---------------------------
1) Report the problem to CERT, the national Computer Emergency
Response Team. They can provide assistance and support. Their
e-mail address is cert@cert.sei.cmu.edu.
(Attached at the end is a checklist from CERT. There response
was immediate.)
2) You might also try CIAC as they have a incident handling guideline
and checklist to help you through your incident.
CIAC:
Computer Incident Advisory Capablilty
US Department of Energy
Send e-mail to ciac@llnl.gov or call CIAC at
(510) 422-8193**/(FTS)532-8193.
Altering the Login Program and Logging of Failures
--------------------------------------------------
1) Changing the SunOS to log login failures with less frequency
than five is not possible without source code for login.c.
2) Use shadow passwords.
3) Install Sun's C2 security option.
4) If you run in enhanced security mode on Ultrix, you can tune
this behavior without modifying the binary.
(The Ultrix audit deamon can be setup to audit all login
failures and sucesses.)
Use an Alternate Password Program
---------------------------------
1) Use passwd+ or npasswd. NEITHER one, though, is
complete. passwd+ is easily configured for different
dictionaries, GECOS checks, etc. but has numerous bugs and does not
support NIS (YP). npasswd does not support chsh and chfn and does
not even support all the attacks used by Crack 3.0! It is not as
easy to quickly reconfigure it either.
npasswd, available from (according to Archie)
blacks.jpl.nasa.gov
csc2.anu.edu.au (in pub/security)
emx.utexas.edu (in pub/npasswd)
ix1.cc.utexas.edu (in pub/npasswd)
2) Used pwc.c. It can be obtained via ftp from the internet.
3) Get the tcp_sh wrappers recently posted to comp.unix.sources or
was it alt.sources?. These are a wrapper that logs an incoming tcp/ip
connection to syslog.
4) Use Don Libes's expect utility to build your own wrapper around
passwd, to make sure the user enters a non-dictionary password.
5) Use the password program from the book "Programming in Perl"
by O'Reilly & Associates. You can get the source for this
program and others in the book from anonymous ftp at uunet.uu.net
in the directory nutshell/perl. perl.tar.Z contains all of the
examples. ch6 contains the example for the password program.
The program checks several dictionaries for common words. It does
not allow you to reuse a password; it keeps a history file of all of
your old passwords. The following are some of the things checked
- passwords must be at least 6 characters long. If you try and
persist it will abort the program after 6 tries, not changing
your password.
- Your password cannot be similar to your old one.
- passwords cannot be in the dictionary of common words.
- common names cannot be used (yours or anyone else's).
- dates are not allowed.
- social security numbers are not allowed (i.e., 9 digits).
- passwords cannot be similar to your loginid, license plate
numbers, repeated patterns (abababab...), sequence of
keyboard keys, somebody else's loginid, your loginid
reversed.
Security Checking Programs
--------------------------
1) Get "cops" by Dan Farmer of CERT. It is available via
anonymous FTP from "cert.sei.cmu.edu" in pub/cops.
2) There is a program "Crack" which has been posted to
comp.sources.misc and is available from c.s.m archive sites.
This is a password cracking program. It will not help your users
pick good passwords, but it will help point out account that the
cracker is likely to break into. For best effect, it should be
used with some extra dictionaries that are mentioned in its
README file.
3) There is a program called "Killer Cracker by Doctor Dissector".
Killer Cracker doesn't work on a SPARC without mods but runs
right quick on a DECstation.
4) SunShIeLd - sun unbundled extra
Terminal Server and Modem Possibilities
---------------------------------------
1) You may be able to do some logging on the terminal server itself.
2) Try installing a call-back program on the modems, so you can
trace who's called you.
3) Dial up lines to a terminal server should probably be password
protected.
4) This might help with tracing. Rather than having the phone company run
a constant trace on the line, log the connect times, than have Bell
do a back-trace on your number for those connect times. Such logging
would be necessary to provide repeated malicious intent, anyway.
5) Contact whomever runs the terminal server and ask that they increase
security. Many terminal servers allow people to "telnet in" and then
"telnet out", effectively hiding their origin. ie: I could possibly
telnet in to your terminal server, then telnet into your comptuer,
but you could only trace me to the terminal server.
Reference Books and other Articles
----------------------------------
1) Practical Unix Security - Garfinkel & Spafford
O'Reilly & Associates/Addison Wesley ISBN 0-937175-72-2
Unix system security - Kochan & Wood
Hayden books ISBN 0-672-48494-3
Managing NFS and NIS - Hal Stern
O'Reilly & Associates/Addison Wesley ISBN 0-937175-75-7
2) Att.research.com has a nice paper or two by anonymous Ftp.
3) There are some security related papers available via anonymous FTP
from ftp.sei.cmu.edu.
4) Coping with the threat of Computer Security Incidents
A Primer from Prevention through recovery - R.Brand
RFC1244 Site Security Handbook
Improving the security of your Unix system - D.Curry
available from cert.sei.cmu.edu
Useful News Group
-----------------
1) alt.security
2) comp.unix.admin
3) comp.unix.wizards
Useful Suggestions
------------------
1) First make sure that you have patched all of the known security holes.
A list of CERT advisories and the advisories themselves can be found
via anon ftp to cert.sei.cmu.edu. There about a helf dozen known security
holes in 4.1.1 that CERT has issued alerts for.
2) Any time you think security has been comprimised, lock out *all* users
and force them to physically show up for a new password. This solves two
problems: disued accounts get locked out, and users have to come up
with new passwords so that if the old one is cracked by a program, it's
already been canceled.
3) Don't assume it's an inside job. If they have the passwd file, then
they'll be able to use that to break passwords.
(I didn't originally say why I thought its an inside job, but
all of the computer management staff here agrees.)
4) Start making frequent backups, and keep (and analyze!) logs of
everything you can. Sweep your filesystems for world-writeable
things, for setuid or setgid programs, etc.
5) Check .rhosts files. That's probably how they got in the first time.
6) Look at the output from 'last' and 'ac' to see who logs in just before
or after the break-in attempts and who is eating up lots of CPU time
(running password crackers).
7) Run an idle user killer. It's childs play to write a shell script that
looks like a valid UNIX login and leave it running on a terminal to
snatch users passwords when they try to log in. If you have 'untamo' or
something else that kills idle users, then you reduce the possibility of
this happening.
8) Setup a harmless account and see what they do.
(I would not recommend this. One of the things that the cracker was
doing was using my internet connection to try and break in to other
machines on the internet. We originally thought it was a student,
but it turned out that his account had been stolen. Also, if a
cracker is really good, then they can probably break root once on
your system and you will never know from the logs. -- My opinion, mlg).
Archive servers
---------------
1) cert.sei.cmu.edu
2) uunet.uu.net
Following are some extracts of messages that were sent to me. They
include a note about a password checker, suggested shell script for
setting C2 security, a man page for security at a particular site,
and the check list that CERT sent me.
Thanks Sun-Managers,
Meg Grice
UNIX Systems Administrator
University of Missouri, KC
mlg@cstp.umkc.edu
------------------------------------------------------------------------------
From: sjh@helicon.math.purdue.edu
I got a good password checker from the following
Matt Bishop
Department of Mathematics and Computer Science
Dartmouth College
Hanover, NH 03755
my office: (603) 646-3267
department: (603) 646-2415
uucp: ...{ucbvax!decvax,decvax}!dartvax!Matt.Bishop
internet: Matt.Bishop@dartmouth.edu
if desperate: Matt.Bishop%dartmouth.edu@relay.cs.net (this takes a while,
though!)
I don't know if he is still there, but it's worth a check. I can't
send it to you under agreement from Matt, but it didn't cost anything.
------------------------------------------------------------------------------
From: jmcarli@srv.PacBell.COM
For the SUN systems, run "C2" security which includes logging of all
failed attempts (if you set it up correctly). I advice setting
audit_control "flags:-ad,lo,-p0,p1". We use a shell script to read the
audit trail from cron (due to a bug we need the grep -v on the top.
Here is the script. I can't help with Dec since we don't have any.
#!/bin/ksh
function process {
/usr/etc/praudit -l $1 |egrep -v "cron|administrative" | Mail -s PBJMC.audit audit
if [[ $? -eq 0 ]]
then
if [[ -n "$rmflag" ]]
then
rm $1
else
mv $1 ${1}.DONE
fi
return 0
else
return 1
fi
}
CONTROL=/etc/security/audit/audit_control
RECIPIENT=root
if [[ "$1" = "-r" ]]
then
rmflag=1
shift
fi
if [[ $# -eq 0 ]]
then
filesys=`grep 'dir:' $CONTROL | sed -e 's/dir://'`
set -- $filesys
fi
for filesys
do
if [[ -f $filesys ]]
then
process $filesys
if [[ $? -ne 0 ]]
then
MESSAGE="$MESSAGE\nError processing $filesys"
break
fi
elif [[ ! -d $filesys ]]
then
MESSAGE="$MESSAGE\nInvalid argument $filesys"
break
fi
cd $filesys
for file in $(ls)
do
audit=$filesys/$file
case "$audit" in
*not*) continue;;
*DONE) if [[ -n "$rmflag" ]]
then
rm -f $audit
fi
;;
*) process $audit
if [[ $? -ne 0 ]]
then
MESSAGE="$MESSAGE\nError processing $filesys/$file"
break
fi
;;
esac
done
done
if [[ -n "$MESSAGE" ]]
then
print $MESSAGE | /usr/ucb/mail -s "Process Audit Warning" $RECIPIENT
exit 1
fi
exit 0
------------------------------------------------------------------------------
From: mcgraw@sunspot.sunspot.noao.edu
Below is the manpage for one we use at our site.
.TH NSA 8 SRI "February 1990"
.SH NAME
nsa \- crack passwords
.SH SYNOPSIS
.B nsa
[
.B \-d
] [
.B \-h
] [
.B \-p
.I passwdfile
] [
.B \-w
.I wordlist
]
.SH DESCRIPTION
.PP
.B Nsa
is used by a system administrator to search for easily-cracked passwords
on the system,
so that they can be corrected.
This is done by attempting to crack the passwords.
For this reason,
.B nsa
should always be run in a protected directory,
and should never be made available to the average user.
.PP
By default,
.B nsa
reads all accounts in the file
.I /etc/passwd ,
and tries several checks on each:
the login name,
the login name reversed,
the first and last names,
and the first and last names reversed,
are all tried in lowercase,
uppercase,
capitalized,
and as they appear in the password file.
The
.B \-p
option may be used to specify an alternate file of accounts;
this file should be in
.I passwd (5)
format.
.PP
If the
.B \-h
option (hard) is specified,
then the above twelve checks are also applied for each account to
a list of words.
The default list of words is the system dictionary,
.I /usr/dict/words .
An alternate file may be specified with the
.B \-w
option;
the
.I proper_names
file provided with the program is a good choice.
.PP
For each password cracked,
.B nsa
prints a line to the standard output indicating the account name,
the password it was cracked with,
and the amount of time it took to crack.
.SH AUTHOR
David A. Curry,
SRI International
.SH BUGS
.PP
The standard C library
.I crypt
routine is used,
so the program is somewhat slow.
.SH NOTICE
.PP
YOU MAY NOT REDSITRIBUTE THIS PROGRAM OR OTHERWISE MAKE IT AVAILABLE
TO ANYONE WITHOUT THE PRIOR CONSENT OF THE AUTHOR.
-------------------------------------------------------------------------------- October 18, 1991
CERT/CC Generic Security Information
The following information is provided to sites that have, or may have, experienced a break-in. Section A lists several ways to determine if a system has been compromised. Sections B and C contain lists of vulnerabilities that have been exploited by intruders on UNIX and VMS systems respectively. Section D gives pointers to some tools that may be used to assist in securing your system.
The information in this document can be used to prevent several types of break-ins. We encourage system administrators to review all sections of this document and modify their systems accordingly to close these potential vulnerabilities.
-------------------------------------------------------------------------------
A. How To Determine If Your System Has Been Compromised
1. Examine log files such as your 'last' log, process accounting, syslog, and C2 security logs for logins from unusual locations or other unusual activity. Note that this is not foolproof; many intruders edit accounting files in an attempt to hide their activity.
2. Look everywhere on the system for unusual or hidden files (files that start with a period and are normally not shown by ls) as these can be used to hide information such as password cracking programs and password files from other systems. A favorite trick on UNIX systems is to put a hidden directory in a user's account with an unusual name; something like '...' or '.. ' (dot dot space space) or '..^G' (dot dot control-G). Also, files with names such as '.xx' and '.mail' have been used.
3. Look for set-uid files everywhere on your system. Intruders often leave set-uid copies of /bin/sh around to allow them root access at a later time. The UNIX find program can be used to hunt for setuid root files. The following example will find setuid root files on the '/' (root) partition (Note: The find command will not follow symbolic links):
find / -user root -perm -4000 -print
4. Check your system binaries to make sure that they haven't been changed. We've seen intruders change programs on UNIX systems such as login, su, telnet, and other critical network and system programs. On VMS systems, we've seen intruders change programs such as loginout.exe and show.exe. Compare the versions on your systems with known good copies such as those from your initial installation tapes. Be careful of trusting backups; your backups could also contain Trojan horses.
5. Examine all the files that are run by cron and at. We've seen intruders leave back doors in files run from cron or submitted to at. These techniques can let an intruder back on the system even after you've kicked him or her off. Also, verify that all files/programs referenced (directly or indirectly) by the cron and at jobs, and the job files themselves, are not world-writable.
6. Inspect /etc/inetd.conf for unauthorized additions or changes. In particular, hunt for entries that execute a shell program (for example, /bin/sh or /bin/csh) and check all programs that are specified in /etc/inetd.conf to verify that they are correct and haven't been replaced by Trojan horses.
7. Check your system and network configuration files for unauthorized entries. In particular, look for '+' (plus sign) entries and inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd, and in all ~/.rhost files (especially ~root, ~uucp, ~ftp, and other system accounts) on the system. These files should not be world-writable. Furthermore, ensure that these files existed prior to any intrusion and have not been created by the intruder.
8. Examine all machines on the local network when searching for signs of intrusion. In particular, check those hosts that share NIS (yellow pages) or NFS mounted partitions, or that are referenced in /etc/hosts.equiv files. Also, check any hosts with which your users share .rhost access.
9. Examine the /etc/passwd file on the system and check for any additional or modified accounts. In particular, look for the unauthorized creation of new accounts, accounts with no passwords, or UID changes to existing accounts.
B. UNIX System Configuration Problems That Have Been Exploited
1. Weak passwords
Intruders often use finger or ruser to discover account names and then try simple passwords. Encourage your users to choose passwords that are difficult to guess (for example, words that are not contained in any dictionary of words of any language; no proper nouns, including names of "famous" real or fictitious characters; no acronyms that are common to computer professionals; no simple variations of first or last names. Furthermore, inform your users not to leave any clear text username/password information in files on any system.
A good heuristic for choosing a password is to choose an easy-to-remember phrase, such as "By The Dawn's Early Light", and take the first letters to form a password. Insert in some punctuation or mixed case letters as well. For the phrase above, one example password might be: bt}DeL{. (DO NOT use this sample phrase for your password.)
If intruders can get a password file, they will usually take it to another machine and run password guessing programs on it. These programs involve large dictionary searches and run quickly even on slow machines. The experience of many sites is that most systems that do not put any controls on the types of passwords used probably have at least one password that can be easily guessed.
If you believe that your password file may have been taken, change all the passwords on the system. At the very least, you should always change all system passwords because an intruder may concentrate on those and may be able to guess even a reasonably 'good' password.
Section D details proactive steps that can be taken to ensure that users set 'good' passwords and that encrypted passwords are not visible to system users.
2. Use of TFTP (Trivial File Transfer Protocol) to steal password files
To test your system for this vulnerability, connect to your system using tftp and try 'get /etc/passwd'. If you can do this, anyone else on the network can probably get your password file. To avoid this problem, either disable tftpd if you don't require it or ensure that it is configured with restricted access.
If you believe your password file may have been taken, the safest course is to change all passwords in the system.
3. Accounts without passwords or known passwords (accounts with vendor-supplied default passwords are favorites)
Intruders often exploit system default passwords that have not been changed since installation. Be sure to change all default passwords when the software is installed. Also, be aware that product upgrades can quietly change account passwords to a new default. It is best to change the passwords of default accounts after updates are applied.
Scan your password file for extra UID 0 accounts, accounts with no password, or new entries in the password file. Do not allow any accounts without passwords. Remove entries for unused accounts from the password file. To disable an account, change the password field in the /etc/passwd file to an asterisk '*', and change the login shell to /bin/false to ensure that an intruder cannot login to the account from a trusted system on the network.
4. Holes in sendmail
Make sure that you are running the latest sendmail from your vendor. BSD 5.65 fixes all known holes. To establish which version of sendmail that you are running, use telnet to connect to the SMTP port (25) on your system:
telnet <your hostname> 25
5. Old versions of FTP; misconfigured anonymous FTP
Make sure that you are running the most recent version of ftpd, which is the Berkeley version 5.60 of July 22, 1990. Check with your vendor for information on configuration upgrades. Also check your anonymous FTP configuration. It is important to follow the instructions provided with the operating system to properly configure the files and directories available through anonymous FTP (for example, file and directory permissions, ownership and group). Note that you should not use your system's standard password file or group file as the password file or group file for FTP. The anonymous FTP root directory and its two subdirectories, etc and bin, should not be owned by ftp.
6. Fingerd hole used by the Morris Internet worm
Make sure that you're running a version of finger that is more recent than November 1988. Numerous Berkeley-derived versions of UNIX were vulnerable.
7. Inappropriate network configuration file entries Several vendors supply /etc/hosts.equiv files with a '+' (plus sign) entry. The '+' entry should be removed from this file because it means that your system will trust all other systems. Other files that should not contain a '+' entry include /etc/hosts.lpd and all ~/.rhost files on the system. These files should not be world-writable. We recommend that you do not support the following services in your /etc/inetd.conf file unless you specifically require them:
port 11 - systat port 69 - tftp port 87 - link
8. Misconfiguration of uucp
If your machine supports uucp, check the L.cmds (Permissions) file and ensure that only the commands you require are included. This file should be owned by root (not by uucp!) and world-readable. The L.sys (Systems) file should be owned by uucp and protected (600) so that only programs running setuid uucp can access it.
9. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
Check the file /etc/ttys or /etc/ttytab depending on the release of UNIX being used. The default setting should be that no terminal lines, pseudo terminals or network terminals are set secure except for the console.
10. Inappropriate entries in /usr/lib/aliases
Examine the /usr/lib/aliases (mail alias) file for inappropriate entries. Some alias files include an alias named 'uudecode' or just 'decode'. If this alias exists on your system, and you are not explicitly using it, then it should be removed.
11. Inappropriate file and directory protections
Check your system documentation to establish the correct file and directory protections and ownership for system files and directories. In particular, check the '/' (root) and '/etc' directories, and all system and network configuration files. Examine file and directory protections before and after installing software or running verification utilities. Such procedures can cause file and directory protections to change.
12. Old versions of system software
Older versions of operating systems often have security vulnerabilities that are well known to intruders. To minimize your vulnerability to attacks, keep the version of your operating system up-to-date and apply security patches appropriate to your system(s) as soon as they become available.
C. VMS System Vulnerabilities
1. Accounts with known default passwords
Intruders often exploit system default passwords that have not been changed since installation. Make sure to change all default passwords when the software is installed. Be aware that product upgrades can quietly change account passwords to a new default. It is best to change the passwords of default accounts after updates are applied. Accounts no longer in use should be removed from the authorization file and rights database. Dormant accounts should be set to DISUSER. Intruders also try guessing simple user passwords. See the discussion on weak passwords in Section A for suggestions on choosing good passwords.
2. Unauthorized versions of system files
If an intruder gets into a system, the programs patch.exe, loginout.exe, and show.exe are often modified. Compare these programs with those found in your distribution media.
D. Software Tools To Assist In Securing Your System
***************************************************************************** * The CERT/CC will not formally review, evaluate, or endorse the tools * * and techniques described. The decision to use the tools and * * techniques described is the responsibility of each user or * * organization, and we encourage each organization to thoroughly evaluate * * new tools and techniques before installation or use. * *****************************************************************************
1. Shadow passwords
If your UNIX system has a shadow password capability, you should consider using it. Under a shadow password system the /etc/passwd file does not have encrypted passwords in the password field. Instead the encrypted passwords are held in a shadow file that is not world readable. Consult your system manuals to determine whether a shadow password capability is available on your system, and to get details of how to set up and manage such a facility.
2. COPS (The Computer Oracle and Password System)
COPS is a publicly available collection of programs that attempt to identify security problems in a UNIX system. COPS does not attempt to correct any discrepancies found; it simply produces a report of its findings. COPS was written by Dan Farmer and is available via anonymous FTP from the cert.sei.cmu.edu system (192.88.209.5) in the /pub/cops directory and via uucp from uunet.uu.net.
3. passwd+
passwd+ is a replacement program suite that allows a system administrator to enforce policies for selecting passwords. The suite also provides a logging capability. passwd+ was written by Matt Bishop and can be obtained by anonymous FTP from the dartmouth.edu system (129.170.16.4) in the file /pub/passwd+.tar.Z. Please read the README.IMPORTANT file which accompanies this software distribution.
4. TCP/IP Wrapper Program
This program provides additional network logging information and gives a system administrator the ability to deny or allow access from certain systems or domains to the host on which the program is installed. Installation of this software does not require any modification to existing network software or network configuration files. The program was written by Wietse Venema from Eindhoven University of Technology in the Netherlands and is available via anonymous FTP from the cert.sei.cmu.edu system (192.88.209.5) in the file /pub/network_tools/tcp_wrapper.shar.
------------------------------------------------------------------------------
Meg Grice Unix Systems Administrator University of Missouri, KC mlg@cstp.umkc.edu (816) 235-5212
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:16 CDT