home *** CD-ROM | disk | FTP | other *** search
- My appologies for taking so long with this it became much larger than
- I'd though it would.
- Please Note:
- 1) My intent in this was to limit my audience enough so that
- this document would not become too large and cumbersome.
- Please note the intended audience.
- 2) This document is sure to undergo revision, and I hesitate to
- ever call any revision a final draft.
- 3) Please forgive any typo's and gramatical errors. It's late
- and I wanted to get this out on a day other than Friday.
- Send me notes of typos and spelling directly don't bother
- the rest of the net with such.
- 4) I'll try to post when I'm able to put this list up on our
- ftp server ftp.Hawaii.Edu:/pub/security.
-
- Again many thanks to all those who provided feedback.
-
- I'm not sure where the other lists are but here's what I've got,
- please let me know if it's of help:
-
- ----------------------------------------------------------------------
-
-
- How to improve security on a newly installed SunOS 4.1.3 system.
-
- Version 1.0 Thomas M. Kroeger - July 94
- tmk@hawaii.edu
-
- Copyright -- Thomas M. Kroeger - July 94
- Please feel free to redistribute or include this list or parts of it
- wherever you desire, but, please include appropriate citation.
-
- Goal -
- Attempt to provide a list of some of the more basic steps that
- can be done to improve security on a newly installed SunOS 4.1.3 system.
- This is by no means an all inclusive list of actions, just a list of
- some simple and more common measures.
-
- Intended Audience -
- Anyone responsible for the system administration duties of a machine
- running SunOS 4.1.3. These recommendations applicable to a stand-alone *
- workstation. It is assumed that the reader has some familiarity with basic
- system administration (you should be able to do a basic system installation
- by yourself, install patches, and use an editor).
-
- [* which may be connected to a larger network?]
-
- NOTE: This list limits it's coverage to measures that can
- be done for a stand-alone workstation addition to the steps listed here
- there are many measures that can be taken to improve the security of
- an enviornment, measures such as; filtering traffic to port 2049/udp
- at the routers will prevent NFS calls from outside your domain.
-
-
- Disclaimer ---
- These recommendations come with no guarantees of anything! Support is only
- offered within the University of Hawai'i community.
-
- The truly paranoid may wish to these implement these recommendations while in
- single user mode as an extra measure of security to avoid possible subversive
- shenannigans by a wily cracker.
-
-
- To Do on a system Just installed
- ------------------------------
-
- Patches --
- + install the following patches
-
- 4.1.3 Security listing
- 100103 SunOS 4.1;4.1.1;4.1.2;4.1.3: script to change file permissions
- 100173 SunOS 4.1.1/4.1.2/4.1.3 : NFS Jumbo Patch
- * 100224 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch
- 100257 SunOS 4.1.1;4.1.2;4.1.3: jumbo patch for ld.so, ldd, and ldconf
- 100272 SunOS 4.1.3: Security update for in.comsat.
- 100296 SunOS 4.1.1, 4.1.2, 4.1.3: netgroup exports to world
- 100305 SunOS 4.1.1, 4.1.2, 4.1.3: lpr Jumbo Patch
- 100372 SunOS 4.1.1;4.1.2;4.1.3: tfs and c2 do not work together
- * 100377 SunOS 4.1.1, 4.1.2, 4.1.3: sendmail jumbo patch
- * 100383 SunOS 4.0.3;4.1;4.1.1;4.1.2;4.1.3: rdist security and hard link
- 100448 OpenWindows 3.0: loadmodule is a security hole.
- 100452 OpenWindows 3.0: XView 3.0 Jumbo Patch
- 100478 OpenWindows 3.0: xlock crashes leaving system open
- * 100482 SunOS 4.1;4.1.1;4.1.2;4.1.3: ypserv and ypxfrd fix, plus DNS fi
- 100507 SunOS 4.1.1, 4.1.2, 4.1.3: tmpfs jumbo patch
- 100513 SunOS 4.1.1;4.1.2;4.1.3: Jumbo tty patch
- 100564 SunOS 4.1.2, 4.1.3: C2 Jumbo patch
- * 100593 SunOS 4.1.3: Security update for dump.
- 100623 SunOS 4.1.2;4.1.3: UFS jumbo patch
- 100630 SunOS 4.1.1, 4.1.2, 4.1.3: SECURITY: methods to exploit login/su
- 100631 SunOS 4.1.x: env variables can be used to exploit login(US only)
- * 100632 SunSHIELD 1.0: ARM jumbo patch release
- 100890 SunOS 4.1.3: domestic libc jumbo patch
- 100891 SunOS 4.1.3: international libc jumbo patch
- 100909 SunOS 4.1.1;4.1.2;4.1.3: Security update for syslogd.
- 101072 SunOS 4.1.1;4.1.2;4.1.3: Non-related data filled the last block
- 101080 SunOS 4.1.1 4.1.2 4.1.3: security problem with expreserve
- 101200 SunOS 4.1.1, 4.1.2, 4.1.3: Breach of security using modload
- 101206 ODS 1.0; NFS/fsirand security fix.
- * 101480 SunOS 4.1.1;4.1.2;4.1.3: Security update for in.talkd.
- * 101482 SunOS 4.1.3, 4.1.2, 4.1.1: Security update for write.
- 101640 SunOS 4.1.3: in.ftpd logs password info when -d option is used.
- 101710 ONLINE DISKSUITE (ODS) 1.0: Security update for dump.
-
- 4.1.3 U1 security listing
- 101434 SunOS 4.1.3_U1: lpr Jumbo Patch
- * 101435 SunOS 4.1.3_U1: ypserv fix
- * 101436 SunOS 4.1.3_U1: bin/mail jumbo patch
- 101440 SunOS 4.1.3_U1: security problem: methods to exploit login/su
- 101558 SunOS 4.1.3_U1: international libc jumbo patch
- * 101579 SunOS 4.1.3_U1: Security problem with expreserve for Solaris 1.
- 101587 SunOS 4.1.3_U1: security patch for mfree and icmp redirect
- 101590 ONLINE DISKSUITE (ODS) 1.0, NFS/fsirand security fix
- 101621 SunOS 4.1.3_U1: Jumbo tty patch
- * 101665 SunOS 4.1.3_U1: sendmail jumbo patch
- 101679 SunOS 4.1.3_U1: Breach of security using modload
- 101759 SunOS 4.1.3_U1: domestic libc jumbo patch
-
- * - Note: some patches may not be required if you are disabling this
- feature. If this is the case, ensure that all relevant files have had
- their mode changed to remove the SUID bit -- chmod u-s <file>.
-
- Note 2: Some patches may not necessarily apply based on packages
- installed (US Encryption...) or your configuration. Please carefully
- check the README for each patch.
- Patches are available via anonymous ftp from
- ftp.uu.net:/system/sun/sun-dist
-
- Network level changes -------
-
- + Disable source routing
- Why:
- Source routing enables the originating host to dictate the route the
- packet will take. This can be used to spoof a system into believing
- that the packets are coming from a trusted source.
- How:
- Install patch found in Ref. 19
- More info: Ref. 2 [Cheswick 94] Chap 2, Ref. 19
-
- + Comment out all unnecessary services in /etc/inetd.conf
- Why:
- RPC services can be used to gain access as well as information about
- a system. These are very site specific adjustments and will have to
- be tailored to your needs. Additionally, TCP wrappers [Ref. 4] can be
- used to improve loging, prevent IP spoofing (one host pretending to be
- another to gain access) and limit access to a service as well as
- totally removing it.
- How:
- Edit file /etc/inetd.conf and put a # in front of services that
- are not needed.
-
- Services possibly needed, but probably desired:
- ftp - possible needed for file transfer, however if all you
- want is outgoing ftp then this is can be commented out.
- telnet - obvious (recommend restricting with TCP wrappers Ref. 4)
- finger - Possibly but better to get a modified version that doesn't
- give up that much information (To be honest I have no
- experience with any of these I'd recommend checking into
- some of the ones on ftp.uu.net).
- talk - nice to have but how much will you miss it?
-
- Services which are probably unnecessary - see man pages for details
- name - for name services (man tnamed)
- comsat - for mail - not necessary.
- login - for rlogin - please see discussion under ruserok().
- uucp - if you aren't sure if your using this then you are not.
- exec - services for rexecd - do without.
-
- Services recommended against - FIND A WAY TO LIVE WITHOUT.
- shell - for rsh -- major source for security problems
- tftp - only needed for support of an X terminal or diskless
- clients, doubtfully needed on a desktop machine.
- More info: Ref. 4 [Venema 92]., Ref. 15
-
-
- + Enable NFS port monitoring (This is of value only if you are exporting
- filesystems over NFS)
- Why:
- Port monitoring ensures that calls to NFS to mount a file system come
- from a port < 1024 (in other words, a port that requires root
- access to use).
- How:
- The default /etc/rc.local sets up port monitoring only if the file
- /etc/security/passwd.adjunct exists. If you will be implementing
- shadowing then you can skip over this step. If you will not be
- implementing shadowing and you will be exporting files then you should
- modify /etc/rc.local to do the following 2 lines: (regardless of
- whether the passwd.adjunct file exists):
- echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem > /dev/null 2>&1
- rpc.mountd
-
- Shadowing is covered under the section Changes to ID Management.
-
- Note: one possible side effect: non-sun nfs client might not
- be able to mount exported files.
- More info: Ref. 3 [Stern 92] pg 177 & mountd(8C)
-
- + Ensure that ypbind is started with the -s option.
- Why:
- Users could easily start thier own ypbind services and activate a
- phony NIS database giving them access as any user.
- How:
- As with port monitoring the default /etc/rc.local sets up ypbind in the
- secure mode (-s option) only if the file /etc/security/passwd.adjunct
- exists. If you will be implementing shadowing then you can skip over
- this step, overwise you should modify /etc/rc.local to start ypbind
- with the -s option regardless of whether the passwd.adjunct file exists.
- More info: ypbind(8)
-
- + Disable IP forwarding -
- Why:
- I'm not sure if this can be abused on a machine with only one interface
- but I'd rather err of the side of safety. It could be used to spoof
- an IP address.
- How:
- Install the following line in the kernel configuration file:
- options "IPFORWARDING=-1"
- For info on how to custom configure a kernel, see the file
- /usr/sys/`arch`/conf/README.
-
-
- Kernel changes -------
-
- + modify ruserok() in /usr/lib/libc.so.1.8 (9 on 4.1.3 U1) to disable:
- - root .rhosts authentication, wildcards in .rhosts, or
- .rhosts entirely depending on the level of security you want.
- Why:
- ruserok() is a library routine that does the checking of both the
- .rhosts and /etc/hosts.equiv files for all the r commands.
- a) ruserok() uses the source IP address in the rpc request for
- authentication. There are no guarantees that this address is correct.
- This address can easily be spoofed, yielding illegitimate access to
- a system.
- b) Crackers will often insert +'s into users' .rhosts file
- to allow them to gain access at a latter date. Most users
- don't look at their .rhosts file too often.
- Note: While using .rhosts prevents crackers from sniffing your users'
- passwords, it also make them vulnerable to IP spoofing (claiming
- to be a host that you're not) it becomes a matter of preference
- what level of protection you'd choose here.
-
- How:
- To modify the source code requires a source code license.
- At Univ of Hawaii, modified version of libc.so.1.8 should be
- available though the systems group.
-
- For those who wish to create thier own modified version of ruserok()
- please see the section at the end that describes some of the details
- for creating a custom libc.so.
-
- Additionally the logdaemon package Ref. 15 has a modified version
- of libc.so that helps with this. This site also has BSD sources
- for the ruserok() routine.
-
- Finally TCP wrappers can also be used to restrict access to each
- individual r command. Ref. 4
-
- More info: ruserok(3), hosts.equiv(5),
- source code file /lib/libc/net/rcmd.c, Ref. 4, Ref. 15
-
-
-
- Filesystem change----------
-
- + create the file /etc/ftpusers
- Why:
- This file is a list of users that will not be allowed to access the
- system via ftp. This prevents Joe Cracker from using ftp to
- modify a file (such as /etc/passwd) if he is able to determine your
- root password.
- How:
- create the file /etc/ftpuser with the following entries (one per line):
- root, nobody, daemon, sys, bin, uucp, news, ingres, AUpwdauthd,
- AUyppasswdd, sysdiag, sundiag, and any other ID's that exist that
- you don't want to allow ftp access.
-
- More info: man ftpusers(5)
-
- + Remove the + in /etc/hosts.equiv
- Why:
- Well..... Everyone gains access with this.
- Note: This file should not have any comment lines.
- More info: hosts.equiv(5)
-
- + edit /etc/exports remove all entries you don't want exported.
- - ensure whatever entries remain have restricted access
- Why:
- NFS leaves the normal file system protection up to the client
- instead of the server. Acracker with root access on a client can
- work around many of these protections. As a result filesystems
- exported to the world are particularly vulnerable.
- How:
- Edit the file /etc/exports
- 1) Only export what you need to export. If you aren't certain that
- it needs to be exported, then it probably doesn't.
- 2) Never export to the world. Use a -access=host.foo.bar.edu option.
- 3) When ever possible export the file systems read-only. option ro
- You can use showmount -e to see what you currently have exported.
-
- More info: exports(5), exportfs(8), showmount(8)
-
- + Install random number inode generator on filesystems fsirand
- Why:
- Predicable root handles assists crackers in abusing NFS. After
- installing the patch for fsirand you'll need to run fsirand for
- all your filesystems.
- How:
- Ensure the filesystem is unmounted and run fsirand.
- More info: fsirand(8), SunOS patch 100173 (NFS Jumbo)
-
- + nosuid in mounts
- Why:
- Use the nosuid option when adding entries to /etc/fstab to mount a
- filesystem exported by another host. Anyone gaining access to the
- other host can create or modify an existing program which could
- compromise your system. Note: this doesn't work on tmpfs filesystems.
- How:
- Include the nosuid when you add an entry to /etc/fstab to import
- a filesystem.
- More info: Ref. 3 [Stern 92] pg. 175 fstab(5)
-
- + Edit /etc/ttytab to remove the secure option from all entries.
- Why:
- The secure entry in /etc/ttytab allows logins directly to root on that
- tty. If you feel that your machine is not in a physically secure
- location, you may choose to remove the secure option from the
- console as well.
- More info: ttytab(5)
-
- + Set eeprom secure field to command or full -
- Why:
- If you feel that your machine is not in a secure location, then
- the eeprom field secure can be used to prevent unauthorized root
- access by crashing your machine. Note: with the full option the
- system will not auto-reboot and will wait for the root password to
- be entered.
- More info: eeprom(8)
-
- + chmod 600 /dev/eeprom -
- Why:
- Prevents users from reading the eeprom passwd.
- More info: eeprom(8)
-
- + Remove openprom support if you do not intend to use the eeprom
- secure field.
- Why:
- A cracker who gains root access could install an eeprom password and
- make your life a bit harder.
- How:
- Remove the device driver from the kernel by commenting out
- the following:
-
- # The "open EEPROM" pseudo-device is required to support the
- # eeprom command.
- #
- pseudo-device openeepr # onboard configuration NVRAM
- More info: eeprom(8)
-
- + Uncomment security options in frame buffer table file /etc/fbtab
- Why:
- Without these entries ownership of console devices will not be properly
- set.
- More info: fbtab(5)
-
- + add umask 022 to /etc/rc & /.login
- Why:
- Prevent key files created during startup and root operation from
- being created world writeable. Note you may want to set umask in
- /.login to 077 instead of 022
- More info: umask(1), rc(8)
-
- + chmod go-w /etc/* ; chmod g+w /etc/dumpdates
- Why:
- None of these file in /etc should require write access
- by world except for dumpdate, which requires group write access.
- More info: chmod(1), aliases(5), state(5), utmp(5V), remote(5), rmtab(5)
-
- + edit /etc/rc.local to comment change part that chmod's 666 motd
- Why:
- /etc/motd is the normal system's message of the day; it won't
- allow people to gain root access, but it could be a nuisance if they
- can change this anonymously. Additionally it is important to
- ensure that the line "rm -f /tmp/t1" is at the begining of this part.
-
- + Chmod u-s the following files unless you specifically use them:
- Why:
- Changing the modes for those file which you will not be using
- helps prevent would be crackers from exploiting unknown security
- flaws in these files which could be used to compromise your system.
-
- /usr/bin/cu /usr/bin/tip /usr/bin/fusage
- /usr/bin/nsquery /usr/bin/uucp /usr/bin/uuname
- /usr/bin/uustat /usr/bin/uux /usr/ucb/rcp
- /usr/ucb/rdist /usr/ucb/rlogin /usr/lib/uucp/uusched
- /usr/lib/uucp/uuxqt /usr/ucb/rsh /usr/lib/uucp/uucico
- /usr/games/hack /usr/games/chesstool /usr/games/fortune
- /usr/lib/exrecover /usr/games/robots /usr/lib/uucp/remote.unknown
- /usr/games/hack /usr/games/snake /usr/bin/sunview1/sv_release
- /usr/etc/rfsetup
- /usr/bin/allocate - used with C2 security.
- /usr/ucb/quota - used with disk quotas
- /usr/lib/expreserve - used to recover edit session that died.
-
- Following may only be needed to be run by user root; as such, they would
- not need to be SUID root:
- /usr/etc/shutdown /usr/lib/acct/accton
-
- More info: lots of man pages ;-)
-
- + chmod g-s the following file unless you specifically use them:
- Why:
- Changing the modes for those file which you will not be using helps
- prevent would be crackers from exploiting unknown security flaws
- in these files which could be used to compromise your system.
-
- /usr/bin/wall /usr/etc/trpt /usr/bin/sunview1/toolplaces
- /usr/bin/iostat /usr/bin/ipcs /usr/ucb/vmstat
- /usr/ucb/netstat /usr/etc/arp /usr/etc/dmesg
- /usr/etc/dkinfo /usr/etc/chill /usr/etc/dumpfs
- /usr/etc/devinfo /usr/etc/nfsstat /usr/old/perfmon
- /openwin/bin/xload /usr/kvm/pstat /usr/kvm/crash
- /usr/kvm/getcons /usr/etc/kgmon /usr/etc/trpt
-
- More info: lots of man pages ;-)
-
- + edit syslog.conf -- uncomment auth & mail lines
- Why:
- The enables improved loging of logins and su's be prepared for lots of
- data.
- More info: syslog.conf(5)
-
- + chmod 640 /vmunix; chgrp kmem /vmunix ;
- Why:
- Prevent crackers from finding out more about your kernel configuration.
-
-
- Changes to ID management ------
-
- + Disable SUID passwd (if using NIS) or -F option in /bin/passwd
- Why:
- Here two options exist:
- 1) you are using NIS for your user database; so you don't need
- /bin/passwd (and the two hard links to it /bin/chfn & /bin/chsh)
- to be SUID root.
- 2) You will have local entries in your /etc/passwd that you would
- like to be able to change thier own passwd. Then please note that
- /bin/passwd has a race condition that can be exploited to write to
- files as root, allowing a cracker to gain root access.
-
- In either case yppasswd (and ypchfn & ypchsh) does not need to
- be SUID root.
- How:
- In all cases - cd /bin; chmod u-s yppasswd ypchfn ypchsh
- Option 1 - cd /bin; chmod u-s passwd chfn chsh
- Option 2a - Replace passwd with a proactive (check for bad passwds)
- passwd program. Ref 7.
- Option 2b - Do a binary edit of passwd (sun's code) as shown below:
- # cd /bin
- # cp passwd passwd.old; chmod 700 passwd.old
- # adb -w - passwd
- not core file = passwd
- /l 'F:'
- 0x68de This address is required in the following step:
- 0x68de/w 0
- 0x68de: 0x463a = 0x0
- <CTRL-D>
- # chmod 4711 /bin/passwd
- Note: The following files should all contain the same code, and
- be SUID root (unless chmod u-s was done above). If you intend
- to use any of these, ensure they are a link to the modified
- file /bin/passwd: yppasswd, ypchfn, ypchsh, chfn, chsh.
- More info: Ref. 6 [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX
-
- + remove ID sync:::
- Why:
- This ID is created to enable the admin to sync the file system before a
- system crash. It defaults without and password, and can be abused to
- gain access to the system. The simplest solution is to live without
- this feature and remove this ID.
- More info: passwd(5)
-
- + Implement shadowing
- Why:
- To restrict access to all users' encrypted passwords. Even though
- passwords are encrypted, Crack (a publicly available program) can
- be used to effectively guess users' passwords.
- How:
- This can be done two different ways:
- 1. by implementing Sun's C2 security package, which
- provides additional auditing. I've found that this auditing can be
- troublesome to maintain and I didn't have need for the extensive data.
- 2. the second option is to implement shadowing but not C2, this
- procedure is fully explained in detail in Ref. 5. In short:
- - ensure patch 100564 is installed, (note this also implements
- securenets for NIS)
- - split /etc/passwd into /etc/passwd & /etc/security/passwd.adjunct
- - split /etc/group into /etc/group & /etc/security/group.adjunct
- - add required Audit users (even if not implementing auditing)
- - comment out the part of rc.local that starts audit
- - reboot.
- The existence of the file /etc/security/passwd.adjunct has several
- other effects in rc.local that improve system security; (ypbind -s
- and rpc.mountd without -n).
- More info: Ref 5
-
- + ensure all ID's have passwd
- Why:
- Any ID without a password provides open access to your system,
- Root comes without a password.
- More info: passwd(5)
-
- Modify mail system -----
- Why:
- The sendmail program itself has been notorious for numerous bugs that
- gave crackers root access illegitimately. This is a huge topic and
- should be a paper or book in itself. I claim no expertise here, and
- to my great fortune my sendmail experience is limited. ;-)
- There are several different possible configurations and options
- I'll outline them and point you to further References.
-
- Host configuration:
- 1. If you intend to send and receive mail directly on your machine.
- Options are:
- a. Live with sendmail - install the newest version 8.6.9 (currently)
- - ensure a mail file is always in existence for all users
- Ref.10 &11.
- - "chmod u-s /bin/mail" and change sendmail to use "procmail"
- or mail.local Ref. 17
- Ref.where to get???
- - change sendmail default UID in sendmail.cf to 65534 "Ou65534"
- - turn on security features of sendmail:
- "Opauthwarnings needmailhelo noexpn novrfy restrictmailq"
- Refs. 2 [Cheswick & Bellovin 94] & 9 [Costales 93]
-
- b. Install zmailer -- Ref 8 [URL to zmailer package]
- - zmailer does not use /bin/mail so chmod u-s /bin/mail
-
- 2. If mail for your host is received on a different host (ie. local mail
- delivery is handled by another host). Here your system should only
- need to support outgoing mail. To prevent the sendmail daemon from
- being started comment out the part or /etc/rc.local that starts
- sendmail. For outgoing mail:
- a. install latest version of sendmail.
- - see config 1 for thing to change in sendmail config.
- - since mail delivery is being handled by main mail host
- there is no need for /bin/mail so - chmod u-s /bin/mail
- b. Install zmailer -- Ref 8 [URL to zmailer package]
- - zmailer does not use /bin/mail so chmod u-s /bin/mail
-
- 3. No need for mail whatsoever on this machine
- (incoming, outgoing, or internal).
- This is certainly most secure mode because e-mail will not be able to
- be sent from or to this machine. This basic restriction of outside
- access will prevent abuse of that access.
- How:
- To disable mail totally:
- - chmod u-s /usr/lib/sendmail & /usr/lib/sendmail.mx & /bin/mail
- - comment out the part of rc.local that starts sendmail
-
-
- Packages to enable better monitoring and security:
- ------------------------
-
- + tripwire - Ref.13.
- - Include all suid & sgid file in config.
- - I've modified COPS script to check this with every run, awaiting
- response from Dan Farmer if he minds my releasing script.
- + tcp wrappers - Ref.4.
- + Cops - Ref. 14
- - Set up to run each night - be careful to check the
- bitbucket output to ensure that it is working properly.
- + Modified portmapper, login, rshd, rlogind, pidentd from W. Venema
- Ref. 15
- + TAMU tiger scripts - Ref. 16.
-
- Note: the Australian group SERT has put together a package called
- MegaPatch that includes several of these packages as well as many
- of the patches to SunOS previously mentioned. Ref. 18
-
- References
- ----------
-
- [1] Dan Farmer & Wietse Venema, "Improving the security of your Site by
- Breaking Into it", 1993.
- URL:ftp.win.tue.nl:/pub/security/admin-guide-to-cracking.Z
-
- [2] W. Cheswick & S. Bellovin, "Firewalls and Internet Security," Addison-
- Wesley, April 94.
-
- [3] H. Stern, "Managing NFS & NIS", O'Reilly & Associates, April 92
-
- [4] Wietse Venema, "TCP WRAPPER: Network monitoring, access control and
- booby traps," Proceedings of the Third Usenix Unix Security Symposium,
- pg 85-92.
- URL:ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (paper - .txt.Z avail)
- URL:ftp.win.tue.nl:/pub/security/tcp_wrappers_6.3.shar.Z (package)
-
-
- [5] Eric Oliver, "How to shadow without C2 Auditing", June 94
- URL:ftp.Hawaii.Edu:/????????
-
- [6] [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX
-
- [7] Proactive password changing programs
- (There are several this is the only one who's URL I had available)
- URL:info.mcs.anl.gov:/pub/systems/anlpasswd-2.2.tar.Z
-
- [8] Zmailer package -
- URL: cs.toronto.edu:/pub/zmailer.tar.Z
- /pub/zmailer.README
-
- [9] Bryan Costales, Eric Allman & Neil Rickert, "Sendmail,"
- O'Reilly & Associates, June 93
-
- 8lgm advisories are avaiable though the 8lgm file server -
- 8lgm-fileserver@bagpuss.demon.co.uk
- [10] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992
- [11] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992.PATCH
- [12] [8lgm]-Advisory-6.UNIX.mail2.2-May-1994
-
- [13] Tripwire - Gene Kim & Gene Spafford 1994
- URL:ftp.cs.purdue.edu:/pub/spaf/COAST/Tripwire
-
- [14] Cops - Dan Farmer & Gene Spafford 1990
- URL:ftp.cert.org:/pub/tools/cops
-
- [15] portmapper, login, rshd, rlogind - Wietse Venema
- URL:ftp.win.tue.nl:/pub/security/portmap.shar.Z
- URL:ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z
-
- [16] TAMU tiger script. - Safford et al 93
- URL:net.tamu.edu/pub/security/TAMU
-
- [17] Local mail delivery agents:
- URL:ftp.informatik.rwth-aachen.de:/pub/packages/procmail
- URL:ftp ---- ????? mail.local Joerg Czeranski
-
- [18] MegaPatch - SERT
- URL:ftp.sert.edu.au:/security/sert/tools/MegaPatch.1.7.tar.Z
-
- [19] Source Routinng Patch -
- URL:ftp.greatcircle.com:/pub/firewalls/digest/v03.n153.Z
-
- Acknowledgements:
- Thanks to all the people in comp.security.unix who offered their
- suggestions, and thanks to the following people for their kind review:
- casper@fwi.uva.nl (Casper Dik)
- baron@uhunix.uhcc.Hawaii.Edu (Baron K Fujimoto)
- rgoodman@uhunix.uhcc.Hawaii.Edu (Becky Goodman)
- newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham)
- andys@unipalm.co.uk (Andy Smith)
-
-
- ------ Other Thoughts for future development & other ---
- Didn't have enough time to do these as well as I'd like.
-
- + disable routed (standard routing table)
- Prevents receiving a false routing table.
-
- + remove /dev/nit?
-
- + Customizing ruserok() - a bit beyond the basics but here's some info:
- If you have source license to 4.1.3 modify the routine
- ruserok() to return -1 for the cases you wish to disallow.
- To disable .rhosts authentication entirely, simply have this routine
- return -1. Look at the file /usr/lib/shlib.etc/README for how to modify
- libc.so, note: also make the following changes:
- in the file /usr/lib/shlib.etc/README below the line
- % mv rpc_commondata. rpc_commondata.o
- insert
- % mv xccs.multibyte. xccs.multibyte.o
- in the Makefile:
- change the lines below to read as they do here:
- OBJSORT=/usr/lib/shlib.etc/objsort
- AWKFILE=/usr/lib/shlib.etc/awkfile
- and add the -ldl option at the end of both ld command lines.
-
- More info: ruserok(3), hosts.equiv(5)
- source code file /lib/libc/net/rcmd.c Ref. 4, Ref. 15
-
- --
- tmk
-
- -----------------------------------------------------------------------
- Tom M. Kroeger Pray for wind
- University of Hawaii Computing Center \ Pray for waves and
- 2565 The Mall, Keller Hall |\ Pray it's your day off!
- Honolulu HI 96822 (808) 956-2408 |~\
- e-mail: tmk@uhunix.uhcc.hawaii.edu |__\
- ,----+--
-
-