0% found this document useful (0 votes)
10 views

Unix Os

Uploaded by

Fares Salman
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views

Unix Os

Uploaded by

Fares Salman
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 17

Information Systems Audit and

Control Association
www.isaca.org

UNIX OS

AUDIT PROGRAM
&
INTERNAL CONTROL QUESTIONNAIRE

The Information Systems Audit and Control Association


With more than 23,000 members in over 100 countries, the Information Systems Audit and Control Association®
(ISACA™) is a recognized global leader in IT governance, control and assurance. Founded in 1969, ISACA
sponsors international conferences, administers the globally respected CISA® (Certified Information Systems
Auditor™) designation earned by more than 25,000 professionals worldwide, and develops globally applicable
information systems (IS) auditing and control standards. An affiliated foundation undertakes the leading-edge
research in support of the profession. The, IT Governance Institute, established by the association and
foundation in 1998, is designed to be a "think tank" offering presentations at both ISACA and non-ISACA
conferences, publications and electronic resources for greater understanding of the roles and relationship between
IT and enterprise governance.

Purpose of These Audit Programs and Internal Control Questionnaires


One of the goals of ISACA’s Education Board is to ensure that educational products developed by ISACA support
member and industry information needs. Responding to member requests for useful audit programs, the Education
Board has recently released audit programs and internal control questionnaires on various topics for member use
through the member-only web site and K-NET. These products are intended to provide a basis for audit work.
E-business audit programs and internal control questionnaires were developed from material recently released in
ISACA’s e-Commerce Security Technical Reference Series. These technical reference guides were developed by
Deloitte & Touche and ISACA’s Research Board and are recommended for use with these audit programs and
internal control questionnaires.
Audit programs and internal questionnaires on other subjects were developed by ISACA volunteers and reviewed
and edited by the Education Board. The Education Board cautions users not to consider these audit programs and
internal control questionnaires to be all-inclusive or applicable to all organizations. They should be used as a
starting point to build upon based on an organization’s constraints, policies, practices and operational
environment.

Disclaimer
The topics developed for these Audit Programs and Internal Control Questionnaires have been
prepared for the professional development of ISACA members and others in the IS Audit and
Control community. Although we trust that they will be useful for that purpose, ISACA cannot
warrant that the use of this material would be adequate to discharge the legal or professional
liability of members in the conduct of their practices.

September 2001

1
UNIX OS
Audit Program and ICQ

Get Preliminary Procedure Step: Objective: Policy/Guidance:


Information The objective is to There are a number
gather as much audit software products
systems information as available that will assist
possible without the auditor to obtain
spending a great deal of information from a UNIX
time doing it. system.

Comments:

Details/Test:
· If possible, purchase and run one of these programs against the selected
UNIX systems.

2
UNIX OS
Audit Program and ICQ

Get Preliminary Procedure Step: Comments:


Information Other Information

Details/Test:
· Gather the following information:
· An inventory of all UNIX hardware and software, including workstations.
· Policies, standards, and procedures.
· A schematic for the UNIX platform and the overall view.
· The unit's strategies and objectives.
· File listings (or equivalents), profile, cshrc and login files for:
· root
· systems administrator (with the highest level of privilege)
· privileged users or special group users
· a typical non-privileged user
· the default (as supplied to new users)
· All significant UNIX servers should be audited. For each server, do the following:
· Telnet to them from the MS-DOS prompt
· Log onto the system as root to extract the relevant information. Otherwise, ask
a system administrator to run the commands on your behalf.
· Start logging, or alternatively redirect the output of the following commands to
a file.
· hHostname
· rusers –l
· finger 0
· finger system
· finger root
· finger guest
· finger demo
· finger ftp
· finger bin
· cat /etc/inittab/
· cat /etc/group/
· cat /etc/passwd/
· cat /etc/shadow/
· cat /usr/lib/uucp/
· cat /usr/lib/uucp/System Devices
· cat /usr/lib/uucp/Devices
· cat /usr/lib/uucp/Systems
· cat /usr/lib/uucp/Permissions
· cat /usr/lib/cron/cron.allow
· cat /usr/lib/cron/at.deny
· cat /usr/lib/cron/cron.deny
· ls –alnupFq /etc
· ls –alnupFq /bin/
· ls –alnupFq /dev/
· ls –alnupFq /lib/
· ls –alnupFq /stand/
· ls –alnupFq /tmp/
· ls –alnupFq /usr/
· ls –alnupFq /unix/
· ls –alnupFq /usr/spool/cron/crontabs
· ls /alnupFq /etc/ftpusers
· pPg /etc/ftpusers
· pg /etc/inetd.conf
· pg /etc/hosts.lpd
· ls –alnupFq /etc/security/
· ls –alnupFq /etc/security/audit/
· rsh <system name> csh –I
· Stop logging

3
UNIX OS
Audit Program and ICQ

File and System Security Procedure Step: Comments:


Password construction
Details/Test:
· Review and evaluate password construction.
· Run CRACK or similar program to determine the adequacy of current
passwords. This test needs to be performed on the password or
shadow password file as appropriate.

File and System Security Procedure Step: Comments:


Password Management
Details/Test:
· Determine the controls over password length and quality (system specific)
· Is use of the “root” password adequately controlled? (The “root”
account is unrestricted)

4
UNIX OS
Audit Program and ICQ

File and System Security Procedure Step: Comments:


Users and user groups
Details/Test:
· Identify the users and user groups defined to the system by listing the contents of the
/etc/passwd and /etc/group files. The /etc/passwd file contains seven colon-separated
fields:
· login name
· password (encrypted) and password aging qualifiers, (Note - passwords are not shown in
the passwd file if a shadow file is used.)
· user id (UID, numbers below 100 are reserved by the system and 0 is the super user UID)
· group id
· account name
· home directory (i.e., the directory where the user is placed after logging in)
· program (i.e., program invoked after the user logs in, default program is /bin/sh, however,
special shells such as the restricted shell (/bin/rsh) can be used)
Note: The /etc/group file has four fields: group name, password (which should not be used),
group id, and login names associated with the group id.

For each user account in /etc/passwd file:


· Ensure that each user has a unique logon ID.
· Ensure that no group logons exist for accountability purposes.
· Ensure that all logon ids are for existing employees.
· Ensure that all accounts which are not required (e.g. guest) are disabled.
· Ensure a password is required and it is adequately aged. This includes forced password
changes after a certain number of days, minimum password lengths, and number of weeks
to elapse before changing passwords. The password field consists of two entries: the
encrypted password and aging qualifiers. The aging entry has the format: Mmww with M =
max. duration in weeks and m = min. duration in weeks between changes. The week of the
last password change is recorded in ww.
Character codes for the Mm fields are:
Code - Number of weeks
. 0
/ 1
0-9 2-11
A-Z 12-37
a-z 38-63
· Review the home directory.
· Ensure that the user's directory does not permit access to sensitive aspects of the
operating system. Examples are the root and /etc directories.
· For each group in the /etc/group file review members of user groups to ensure that access
permitted to group members is authorized.
· Review the password file and note which Superuser names are present. (Look for any accounts
with UID=0 (superuser)) On some systems, this can be done by using the following
command: cat /etc/passwd. Each Superuser name should appear in the first position of
this file. Names include, but are not limited to:
br - This command invokes the backup and restore menus. (This is implementation
specific)
setup - This command sets up the computer. (This is implementation specific)
sysadm - This command allows access to many useful utilities that do not require a user to
log in as root.
powerdown - Powers the computer down. (The “powerdown” command is called
“shutdown” in some UNIX systems.
checkfsys - Initiates a check of the file system on the specified removable media.
makesys - Makes a new file system on removable media.
mountfys - Mounts a file system on removable media for use.
umountfsys - Unmounts a specified mounted file on the system.
· Determine if there are passwords set for each of these names.
· Ensure that a shadow password file is used and encrypted passwords are not located
in the /etc/passwd file. To view the shadow password file, if it is available, use
cat /etc/shadow. If a password exists, an encrypted password will appear in the
second position. If a password does not exist, either NONE of just:: will appear in
the second position.
· Determine if the systems administrator regularly maintains and reviews the sulog for
unauthorized su attempts. The ability to 'superuser' or the su command should be
reserved for only the system administrator(s). The sulog will show how many attempts
have been made to a superuser account. If the sulog is not maintained, there are no
other utilities available to track attempts to use superuser accounts. The sulog can
generally be viewed with the command more /usr/adm/sulog. It can become quite
large if not reviewed daily.
5
UNIX OS
Audit Program and ICQ

File and System Security Procedure Step: Comments:


System directory access
Details/Test:
· Review access capabilities to operating system directories and files to
determine if allowed access is appropriate.
· Analyze the listing of all directories containing operating system files.
· Identify the users, users within the group, and other users allowed
access to the operating system files and directories.

You must use a logon ID, which has execute access to these directories.
Ask the system administrator for an ID with these capabilities (the system
administration ID would suffice). While logged on, change the current
directory to each of the above listed directories using the cd command
(similar to cd command in MS-DOS) and while in the directory, issue at the
$ prompt, ls -l. This command will display the access capabilities for each
of the files within the directory. Repeat this step for subdirectories also.

Some of the operating system directories are as follows:

/ Root
/bin Contains executable programs and UNIX utilities
/dev Contains special files which represent devices
/etc Contains miscellaneous administration utilities
and data files for system admin
/lib Contains libraries for programs and languages
/stand Contains stand-alone programs, including copy
of operating system kernel loaded by disk-based boot
loader
/tmp Contains temporary files that can be created by any
user
/usr Contains user directories and files
/unix UNIX Kernel is located in this directory

File and System Security Procedure Step: Comments:


User and group flags
Details/Test:
· Evaluate the effective user-ids and group-id flags set for operating system
files.
· While in the root directory issue the command: find /-user root -perm-
4100-exec ls -l. This command lists all set-UID programs owned
by root.
· Review the directory listing and evaluate group names listed.
· Evaluate the group names to see if they are authorized group names.

6
UNIX OS
Audit Program and ICQ

File and System Security Procedure Step: Comments:


init utility
Details/Test:
· Review the table in the /etc/initab file which contains the instructions for
the init utility. The init utility executes at system startup that calls the
getty utility for each terminal. The getty utility displays a login prompt
and accepts the user name. Next the getty utility calls the login utility
and validates the user name, password and starts the shell to accept
commands from the user.
· Determine if the getty and login utilities are replaced by other
utilities/programs. These other programs/utilities are called by the init
utility.
· If so, evaluate the utilities/programs to determine if on-line access is
authorized.

File and System Security Procedure Step: Comments:


UNIX login program
Details/Test:
· Determine which login program is used by the UNIX operating system.
Four versions of the login program can be linked to /bin/login. The
most secure version, login.secure, requires a password for the
superuser account (root) and restricts the superuser account to login
only at the operator console.

File and System Security Procedure Step: Comments:


User profiles and restricted
shells
Details/Test:
User system access can be further modified by user profiles and restricted
shells. Profiles are files executed by the login process, and can modify
parameters system-wide (/etc/profile) or for specific user accounts (. profile,
located in the user's home directory).

Restricted shells are default programs, specified in the /etc/passwd record,


which prohibit a user from changing directories, changing values in their $PATH
statement, issuing commands with /, and redirecting output. Often, restricted
shells are used to limit users to very specific and restrictive environments.
These are enforced after .profiles have been executed.

· List the contents of selected user's profile file. This file will determine which
directory is accessed through the specification of path variables.
· Determine if the directory accessed is the appropriate directory given
the user's job duties.
· Review also for the use of the unmask command in either the system
or user's profiles. This command can modify default access.
· Evaluate the need and use of restricted shells.
· Ensure that write access to system and user profiles, and any restricted
shells is appropriately restricted. This is achieved by reviewing file
access permissions for these .profile files.

7
UNIX OS
Audit Program and ICQ

Networking Security Procedure Step: Comments:


inetd.conf
Details/Test:
· Review inetd.conf.
· Ensure that all non-needed and default entries are removed or commented
out:
· shell stream tcp nowait root (/usr/etc/in.rshd in.rshd)
· login stream tcp nowait root (/usr/etc/in.rlogind in.rlogind)
· exec stream tcp nowait root (/usr/etc/in.rexecd in.rexec.d)
· comsat dgram udp wait root (/usr/etc/in.comsat in.comsat)
· uucp stream tcp nowait root (/usr/etc/in.uucpd in.uucpd)
· tftp dgram udp wait root (/usr/etc/in.tftpd in.tftpd -
s /tftpboot)
· finger stream tcp nowait nobody (/usr/etc/in.fingerd in.fingerd)
· rusersd/1-2 dgram rpc/udp wait root (/usr/etc/rpc.rusersd rpc.rusersd)

Networking Security Procedure Step: Comments:


.netrc
Details/Test:
· Review the need for .netrc files. They allow auto-login to remote machines
and contain unencrypted passwords.

Networking Security Procedure Step: Comments:


/passwd file
Details/Test:
· Review the ftp/etc/passwd file. It should contain no passwords.
· If ftp is not needed, see that it is disabled.
· If ftp is not required, disable it in inetd.conf file.
· Review the file “/etc/ftpusers”. This should contain the names of all of
the users who are allowed to use ftp.

Networking Security Procedure Step: Comments:


tftp
Details/Test:
· Review tftp to see that it runs as userid -2 (NOBODY).
· Check inetd.conf. to see that it runs with secure option (-s) to force tftp to
restrict access to the restricted directory.
· If this is not required it should be disabled in the in the inetd.conf file.

UNIX OS
Audit Program and ICQ

8
Networking Security Procedure Step: Comments:
remote execution
Details/Test:
The files hosts.equiv and .rhosts allow users on defined remote machines to log
on to the local machine without using a password.
· Examine the file /etc/hosts.equiv and ensure that all listed hosts are
appropriate.
· Find all files called .rhosts (these may be located in the users home
directories) and ensure that these are appropriate. Remember that use
of host.equiv and .rhosts is convenient but can be used as a backdoor.
They should never be allowed for root and is at all possible should be
banned.

Networking Security Procedure Step: Comments:


finger
Details/Test:
· See that "finger" is disabled to improve security.

Logging and Reporting Procedure Step: Comments:


Logging steps
Details/Test:
· Determine that the following system logs are being reviewed and have
restricted access:
· /etc/wtmp - contains a history of system logins. (This file is not
viewable and needs to be interpreted by a UNIX utility such as
“who”.
· /usr/adm/sulog - Review the contents of this file which logs the use of
the su command. The su (super user) command can compromise
security by accessing files belonging to other users without their
knowledge. The user must know the password of the file owner.
Use of this command will evidence the use of a password by other
users.
· /usr/lib/cron/log - contains a history of actions taken by /etc/cron.
· /usr/bin/uulog - contains a history of each use of uucp, uuto, and
uux.
· /etc/security/failedlogin - Review the log to determine who has failed
their login.
Note: The most important files to review are /usr/adm/syslog and /usr/adm/messages
(or equivalent).

9
UNIX OS
Audit Program and ICQ

Directory and File Security Procedure Step: Comments:


User profile sample
Details/Test:
· Select a sample of user profiles to review.
NOTE: Individual user profiles can override the default system umask
by inserting their own umask. All users creating files will have their file
permissions defaulted to based on the following umask settings:
· umask 000 - No restrictions - read/write permissions grated to all
· umask 002 - No write permissions for others outside the group.
Read/write to all within the group.
· umask 022 - No write permissions for others outside or inside the
group. Read granted to all.
· umask 027 - No read/write permissions to those outside the group. No
write within but read only.
· umask 077 - No read/write permissions to anyone except the defined
user.

Directory and File Security Procedure Step: Comments:


User controlled changes to
profile
Details/Test:
· Determine if users have the ability to change their own profiles or if that is
not under the control of the Systems Administrator. Remember: user
profiles define paths, umask file creation permissions, and other critical
start-up information. To make this determination, look in the user's
home directory and look at the long listing of the profile. For example, if
the user's home directory is /usr/drs01, then issue the command:

ls -l .profile

The listing should provide a response similar to the following:


-rwxrwx--- 1 drs01 usr 1070 Mar 7 23:!5 .profile where:

- marks it as a file
rwx states the owner/creator has read/write/execute
permissions
rwx states that group members of group usr have
read/write/execute permissions
--- states that others outside of the group
usr have no rights
1 states that there are no other file links
drs01 the owner of the file
usr the owners group affiliation
1070 the file size
Mar 7
23:15 the date and time created/last updated
.profile the file name

The above example allows the user and all members of the users group to change
the profile. Security would be better if only the administrator could change the
profile i.e.

10
(-r-x------), alternatively is users are allowed to change their own .profile, the
permissions should be set to (-rwx------).

UNIX OS
Audit Program and ICQ

Directory and File Security Procedure Step: Comments:


Critical directory
permissions
Details/Test:
· Document the directory permissions on critical directories to ensure they
provide proper integrity.
· Critical directories include but are not limited to the following:

Directory Others permission Setting Owner Typical Group

/bin r-x bin bin


/dev r-x root sys
/dev/dsk r-x root other
/dev/rdsk r-x root other
/etc r-x root sys
/etc/conf r-x root sys
/etc/default r-x root bin
/etc/init.d r-x root sys
/etc/log r-x root sys
/etc/perms r-x root sys
/lib r-x bin bin
/root r-x root bin
/shlib r-x root sys

Accounting Data Procedure Step: Comments:


Accounting on and used
Details/Test:
· Determine if accounting is turned on and reviewed regularly.
· Issue the command ls –l /usr/adm/pacct. If the file exists and has a
recent modify date, then accounting is turned on.

Accounting Data Procedure Step: Comments:


cron
Details/Test:
· Determine if cron through a root crontab or adm crontab is regularly
schedule to perform accounting.

11
UNIX OS
Audit Program and ICQ

System Backups Procedure Step: Comments:


Sync utility
Details/Test:
· Determine if the sync utility is periodically executed to copy disk buffers to
disk so that loss of data is kept at a minimum in the event of system
failure. This can be verified by reviewing the contents of the table
stored in the \etc\crontab file that lists the programs executed
periodically. These programs are executed by the cron utility as
background processes.
· Determine if the system administrator typically maintains the \etc\crontab
file.

If backups are run automatically


· Examine the relevant crontab file (usually root)
· Determine the frequency with which the backup script is run
· Ensure that this is appropriate for the operation being audited.

System Backups Procedure Step: Comments:


Backup Scripts
Details/Test:

· Examine the backup script


· Ensure that the relevant files are backed up.

System Backups Procedure Step: Comments:


Procedures
Details/Test:
· Ensure that backup and restore procedures are logged to log files. Logging
of backups provides an audit trail of backup procedures. This would
provide a means to determine if an unattended backup procedure did
not execute properly.
· Review the contents of this file
· Determine if all vital file systems are included in this procedure.
· Compare this information with the contents of the file that is a text file that
contains a list of file systems and partitions, which are backed up
during a full backup. This file provides the command with a description
of the systems in order to execute a proper backup and restore.
· If the backup process records a status log (e.g. backup success or
failure) ensure that this is regularly reviewed by the system
administrator (i.e. daily).

System Backups Procedure Step: Comments:


Write verify passes
Details/Test:
· Ensure that write verify passes are made to enhance the reliability of the
new archive. Write verify passes will occur by default unless they are
disabled.

12
UNIX OS
Audit Program and ICQ

Breaking in Procedure Step: Comments:


Testing security
Details/Test:
· Use the UNIX checklist to ascertain the level of security of the selected
machines.

Other Procedure Step: Comments:


Other Tests
Details/Test:
· Use a disk space command (e.g. “df-v”) to ensure that there is sufficient
disk space on all of the volumes
· Where the UNIX server is being used purely as an application server,
ensure that users are prevented from accessing the UNIX shell
· Review all available applications for shell escapes, including utilities
such as e-mail.

13
UNIX OS
Audit Program and ICQ

Appendix A: References

Practical UNIX Security


Simson Garfinkel and Gene Spafford
(C) 1991 O'Reilly & Associates, Inc.

UNIX Systems Security


Patrick Wood and Stephen Kochan
(C) 1986 Hayden Books

UNIX system security: A Guide for Users and System Administrators


David A. Curry
Addison-Wesley Professional Computing Series
May 1992.

X Window System Administrators Guide


Chapter 4
(C) 1992 O'Reilly & Associates, Inc.

Information Security Handbook


William Caelli, Dennis Longley and Michael Shain
(C) 1991 MacMillan Publishers Ltd.

Firewalls and Internet Security


William R. Cheswick & Steven M. Bellovin
(C) 1994 AT&T Bell Laboratories
Addison-Wesley Publishing Company

Building Internet Firewalls


Brent Chapman and Elizabeth Zwicky
(C) 1995 O'Reilly & Associates, Inc.

CERT advisories are available via anonymous FTP from


ftp://ftp.auscert.org.au/pub/cert/cert_advisories/*

CERT vendor-initiated bulletins are available via anonymous FTP from


ftp://ftp.auscert.org.au/pub/cert/cert_bulletins/*

UNIX System Administration Handbook (second edition)


Evi Nemeth, Garth Snyder, Trent R. Hein and Scott Seebas
Prentice-Hall, Englewood Cliffs (NJ), 1995

Essential System Administration


Aeleen Frisch
O'Reilly & Associates, Inc.

Managing Internet Information Services


Cricket Liu, Jerry Peek, Russ Jones, Bryan Buus, Adrian Nye
O'Reilly & Associates, Inc.
14
Managing NFS and NIS
Hal Stern, O'Reilly and Associates, Inc., 1991

UNIX OS
Audit Program and ICQ

Appendix B: Useful security tools

There are many good tools available for checking your system. The list below is not a complete list, and
you should NOT rely on these to do ALL of your work for you. They are intended to be only a guide. It is
envisaged that you may write some site-specific tools to supplement these. It is also envisaged that you
may look around on ftp servers for other useful tools.

AUSCERT has not formally reviewed, evaluated or endorsed the tools described. The decision to use
the tools described is the responsibility of each user or organization.

Crack
Crack is a fast password cracking program designed to assist site administrators in ensuring that users
use effective passwords. Available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/crack/*

COPS and Tiger


These packages identify common security and configuration problems. They also check for common
signs of intrusion. Though there is some overlap between these two packages, they are different enough
that it may be useful to run both. Both are available via anonymous ftp.
COPS:
ftp://ftp.auscert.org.au/pub/cert/tools/cops/1.04
tiger:
ftp://ftp.auscert.org.au/pub/mirrors/net.tamu.edu/tiger*

anlpasswd
This program is a proactive password checker. It runs a series of checks on passwords at the time users
set them and refuses password that fail the tests. It is designed to work with shadow password systems.
It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirror/info.mcs.anl.gov/*

tcp_wrapper
This software gives logging and access control to most network services. It is available via anonymous
ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/tcp_wrappers_7.2.tar.gz

Tripwire
This package maintains a checksum database of important system files. It can serve as an early
intrusion detection system. It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/coast/COAST/Tripwire/*

cpm
cpm checks to see if your network interfaces are running in promiscuous mode. If you do not normally
run in this state then it may be an indication that an intruder is running a network sniffer on your system.
This program was designed to run on SunOS 4.1.x and may also work on many BSD systems. It is
available via anonymous ftp from:
ftp://ftp.auscert.edu.au/pub/cert/tools/cpm/*

Vendor supplied security auditing packages


Sun provides an additional security package called SUNshield. Please direct enquiries about similar
15
products to your vendor.

UNIX OS
Audit Program and ICQ

smrsh
The smrsh(8) program is intended as a replacement for /bin/sh in the program mailer definition of
sendmail(8). smrsh is a restricted shell utility that provides the ability to specify, through a configuration,
an explicit list of executable programs. When used in conjunction with sendmail, smrsh effectively limits
sendmail's scope of program execution to only those programs specified in smrsh's configuration. It is
available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/smrsh
Note: smrsh comes bundled with Eric Allman's sendmail 8.7.1 and higher.

MD5
MD5 is a message digest algorithm. An implementation of this is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/md5/

rscan
This tool checks for a number of common IRIX-specific security bugs and problems. It is available via
anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.vis.colostate.edu/rscan/*

SATAN
SATAN (Security Administrator Tool for Analyzing Networks) is a testing and reporting tool that collects
information about networked hosts. It can also be run to check for a number of vulnerabilities accessible
via the network. It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/satan*

logdaemon
Written by Wietse Venema, this package includes replacements for rsh and rlogin daemons. By default
these versions do not accept wild cards in host.equiv or .rhost files. They also have an option to disable
user .rhost files. logdaemon is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/logdaemon*

portmapper/rpcbind
These are portmapper/rpcbind replacements written by Wietse Venema that disallow proxy access to the
mount daemon via the portmapper. Choose the one suitable for your system. They are available via
anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/portmap_3.shar.Z
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/rpcbind_1.1.tar.Z

PGP Pretty Good Privacy implements encryption and authentication


It is available from:
ftp://ftp.ox.ac.uk/pub/pgp/unix/

chrootuid
Allows chroot functionality. The current version is 1.2 (at time of writing). Please check for later versions.
It is available from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/chrooduid1.2
A digital signature is available from:
16
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/chrooduid1.2.asc

CGIWRAP
It is available from:
ftp://ftp.cc.umr.edu/pub/cgi/cgiwrap

UNIX OS
Audit Program and ICQ

X11R6
It is available from:fttp://archie.au/X11/R6/*
ftp://archie.au/X11/contrib/*
or
ftp://ftp.x.org/pub/R6/*

Washington University ftpd (wu-ftpd)


This can log all events and provide users with a login banner and provide writable directory support in a
more secure manner. It is available from:
ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu/packages/wuarchive-ftpd/*

NOTE: Do not install any versions prior to wu-ftp 2.4 as these are extremely insecure and in some cases
have been trojaned. Refer to the CERT advisory CA-94:07 (C.8).

Patch 005 for BSD/386 v1.1. It is available from:


ftp://ftp.auscert.org.au/pub/mirrors/ftp.bsdi.com/bsdi/patches/README
ftp://ftp.auscert.org.au/pub/mirrors/ftp.bsdi.com/bsdi/patches/?U110-005
or
ftp://ftp.bsdi.com/bsdi/patches/README
ftp://ftp.bsdi.com/bsdi/patches/?U110-005
(where ? is B or S for the Binary or Source version)

Anonymous FTP Configuration Guidelines


The CERT document which addresses the many problems associated with writable anonymous ftp
directories. It is available from:
ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp

Appendix C: Other AUSCERT information sources

AUSCERT advisories and alerts


Past AUSCERT advisories and alerts can be retrieved via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/auscert/advisory/

AUSCERT's World Wide Web server


AUSCERT maintains a World Wide Web server. Its URL is
http://www.auscert.org.au

AUSCERT's ftp server


AUSCERT maintains an ftp server with an extensive range of tools and documents. Please browse
through it. Its URL is
ftp://ftp.auscert.org.au/pub/

17

You might also like