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 |__\
,----+--
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
