bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein) (10/23/89)
The title is self-explanatory. I'll try to archive all responses. Follow up, don't reply. My mailbox is full enough already, and we need to get everybody's mind off ``how to tell a wizard.'' ---Dan Bernstein, brnstnd@acf10.nyu.edu, bernstei@hpuxa.ircc.ohio-state.edu
montnaro@sprite.crd.ge.com (Skip Montanaro) (10/24/89)
I've been thinking about this topic recently. While I can't rattle off a list of shoulds and shouldn'ts, you might take a look at Bruce Spence's paper in the proceedings of latest USENIX workshop on administering large systems. He described a program (actually a shell script) called 'spy' which looked at a number of things, such as badly formatted /etc/passwd files, writable .rhost files, and so forth. I'd give you more details, but I can't find my copy of the proceedings at the moment. I'm sure others on the net can elaborate. -- Skip Montanaro (montanaro@crdgw1.ge.com)
fuat@cunixc.cc.columbia.edu (Fuat C. Baran) (10/24/89)
Take a look at "UNIX System Security" by Patrick H. Wood and Stephen G, Kochan (Hayden Books, 1985) for ideas. --Fuat -- INTERNET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 854-5128 New York, NY 10025
jfh@rpp386.cactus.org (John F. Haugh II) (10/24/89)
In article <363@nisca.ircc.ohio-state.edu> bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein) writes: >The title is self-explanatory. I'll try to archive all responses. > > Subject: Re: What should go into a security-checking shell script? The real question is what can you afford to not put into your shell script? shell is too clumsy for something as important as a security checking program. There was a little file scanner posted some time back that can be used as a nice start. Most of the inode is security-relevant. Owner, group, mode, size and modification time are all important. The checksum and file format may also be interesting, so the ability to specify a per-file checking program is desirable. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of EMACS is ... InterNet: jfh@rpp386.cactus.org | ... EMACS makes a computer slow. UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---
jeffm@uokmax.ecn.uoknor.edu (Jeff Medcalf) (10/24/89)
Password checking
- No system password should be allowed to be nonexistent or the same as
the name of the account.
- Users whose accounts have such passwords should be warned that their
password is unsafe
- Should check for null password entries and blank lines in /etc/passwd
This is not intended to be anything more than a minutes work at 5am, so it is
not by any means all inclusive.
--
Jeff Medcalf jeffm@uokmax.uucp jeffm@uokmax.ecn.uoknor.edu
!chinet!uokmax!jeffm jeffm@invent_an_address (as reliable as the preceeding)
In 1869, the waffle iron was invented, thus solving the annoying tendency of
waffles to wrinkle in the dryer.greg@cheers.uucp (Greg Onufer) (10/25/89)
A few things to think about:
- Compare checksums of all vendor-supplied executables
with known-correct checksums.
- Use find(1) to search the disks for set-uid
and set-gid executables as well as special
devices (since they can only be made by root).
- Check the validity of root's dot-files (incl.
root's default PATH).
- Validate the permissions of all important
configuration files (/etc/passwd, /etc/group,
/etc/{tty,ini}tab, UUCP L.sys/Systems files,
etc).
- Check that all users have passwords, even going as far
as checking against the system dictionary to determine
if existing passwords are "easy" to break.
That's most of the checking I do locally, more ideas would be welcome!
Cheers!greg (Greg Onufer, cheers!greg@lll-winken.llnl.gov)davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/25/89)
If you mean a script to be run regularly looking for problems, here are a few things to look for: 1. any world writable directory (eliminate the obvious, or just look in user space). 2. any world writable setuid program! 3. Any setuid program (again eliminate the usual system stuff) 4. Check critical programs with length and 2 CRC programs, one of which is not sum. Write your own, as long as it's not the same as sum. Check against a protected list. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
madd@world.std.com (jim frost) (10/26/89)
In article <1TDnkx#VBnsh=greg@cheers.UUCP> greg@cheers.uucp (Greg Onufer) writes: |A few things to think about: | - Compare checksums of all vendor-supplied executables | with known-correct checksums. Actually it's better to do both a CRC and an inode-change test; the latter is very fast and fairly difficult to get around portably, the former is kind of slow but tough to get around. A combination of the two is fairly effective. This kind of test should be done on the kernel regularly! jim frost software tool & die madd@std.com
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/28/89)
> - Compare checksums of all vendor-supplied executables > with known-correct checksums. > - Use find(1) to search the disks for set-uid > and set-gid executables as well as special > devices (since they can only be made by root). > - Validate the permissions of all important > configuration files (/etc/passwd, /etc/group, > /etc/{tty,ini}tab, UUCP L.sys/Systems files, > etc). I have a couple of small programs that do this if anyone is interested. -- Branch Technology <zeeff@b-tech.ann-arbor.mi.us>
borg@cbnewsc.ATT.COM (daniel.w.meeks) (10/30/89)
There is a very good book you can find with some shell-scripts included in the text. The book, ``UNIX(r) System Security,'' by: Wood and Kochan. This book is published by: Hayden Books. --dwm@iexist.att.com
jkimball@SRC.Honeywell.COM (John Kimball) (10/31/89)
>Re: What should go into a security-checking shell script?
Here's the list which I've been maintaining. Apologies for the terseness.
Some of the stuff is BSD/Sun specific. I have a script (with associated
programs) which checks most of these; it's pretty raw yet.
*** Compare the attributes of "critical" files against a snapshot taken
at a certain time.
Attributes to check:
uid, gid
permissions
modification time
number of links
checksum / CRC
size
Files to check:
/vmunix
any suid/sgid
/bin/* , /usr/ucb/* , /usr/bin/*
/etc/*
/usr/etc/*
/usr/local/* (?)
/usr/lib/many-things
/usr/lib/uucp/many-things
/usr/include/many-things
/lib/many-things
*** scan all files for dangerous combinations of file attributes
SUIDs, SGID
SUIDs, SGIDs writable by group,other
SUIDs, SGIDs owned by system ids but not in system bins/libs
any SUIDs in non-system (ie user) areas
special files
block special files readable/writable by group,other
char special files readable/writable by group,other
(excluding ttys, sigh)
block/char special files not in /dev
writable system files
system directories writable by other, or by group
(excluding tmp directories, uucppublic)
system files writable by other/group
(excluding tmp directories, uucppublic)
writable binaries, writeable stuff in /etc
certain readable system files
syslog*!
crontab, /dev/mem, /dev/kmem, and L.sys shouldn't be
other-readable.
user startup files
user startup files writable by group/other
(.login, .cshrc, .profile, .exrc, .mailrc, .emacs,
.logout)
user .exrc files in directories writable by group/other
user dirs writable by group/other
user files writable by other
*** scan for dangerous attributes within critical files (and yp maps)
/etc/passwd
users without passwords
including uucp!
users with same uid
including non-root accounts with uid 0!
guest accounts
blank lines, ::0:0::
number of fields
length of fields (ie number of characters in field)
/etc/group
users in administrative groups (eg, bin)
number of fields
length of fields (ie number of characters in field)
crontab
reduce number of things run as root (su to news, etc, instead)
/etc/servers
Only run the minimum number of servers you need.
rpc.rexd is bad news
/usr/lib/uucp/USERFILE
only /usr/spool/uucppublic should be readable/writable for
incoming uucps
/usr/lib/uucp/L.cmds
only rmail and rnews should be uuxqtable
/.rhosts, /etc/hosts.equiv
look for nonlocal hosts, '+'.
/etc/securetty or /etc/ttytab
disallow root login on most/all terminals
/etc/netgroup, /etc/exports
/.profile, /.cshrc, /.login
check for bad PATH (have *no* ., or . as last!)
look for bad user PATHs
look for user .rhosts files mentioning external hosts
*** scan for untoward users
stale logins (users who haven't logged in for a long time)
trivial passwords
It's best to catch these at password-changing time, but
password guessers are also available.
*** scan for odd activity
last: look for logins/ftps by sync, daemon, sysdiag, etc.
ps: look for cpu-eaters, etc
*** dangerous filenames
user .rhost files
disallow if feasible
su,login,passwd,crypt in strange places
*** monitor the various logs
search the uucp logs, the syslog logs, etc, for oddities.rhare@carina.unm.edu (robert...) (11/11/89)
In article <21399@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: >Jim Magee writes: > > Dont forget to double check the mount points before doing this. > > More than once I have seen people mount NFS filesystems over > > directories just to hide their version of setuid-root shell > > underneath the mount point. > A neat way to check under NFS file systems for files when your can't afford to umount the filesystem on the local host. For example: Host A has /usr/local mounted from Host B You want to check under /usr/local on host a for hidden files. You can use: mount /usr@hosta /mnt Then check in /mnt/local for hidden files. The files from then NFS mount will not show up. Just a cute trick. If there is an easier way to do this other than reading the raw disk device please let me know. Robert Hare rhare@ariel.unm.edu