|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
UNIX System Administrator Responsibilities (Navy R
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
UNIX System Administrator Responsibilities
This model is designed to aid a system administrator in preparing to place
a computer on the Internet. It is written for those who have only a minimal
knowledge of UNIX and system administration. For those already experienced
in administration of UNIX, the following procedures will be familiar. This
information has been compiled to help system administrators certify that good
security practices are being used BEFORE a computer is connected to the
network. The ACTION line summarizes what action needs to be taken or what
policies should be followed.
Installing System Patches
The latest patch list is available from your vendor. It is recommended
that you install every patch recommended for your computer which isn't
yet installed. Since some patches restore default configurations, it's
important that patches are put in place before any furthur security
precautions are taken. Also, patch lists, documents, and tools are
available via gopher from coast.cs.purdue.edu.
Additionally, a 'Vendor Contacts FAQ' is available from the author
of ISS at http://iss.net/~iss/vendor.html. It contains a 'list of
security contacts to reach at various vendors for reporting security
vulnerabilities and obtaining new security-related patches'.
ACTION : Install operating system patches.
Recording System Defaults
When a computer is accessed by an unauthorized user, there is a possibility
that system files and data have been changed or deleted. The system
administrator needs to check the computer for deleted files, trojan horses,
hidden files, etc., and then restore the computer to its original state. The
Detection section of this model is designed to aid the administrator in
checking for changed files, and the Recovery section explains how to restore
them; the system administrator must first record the state of the computer
before it is available for general use.
For computers that don't come with a copy of the operating system, the first
thing the administrator should do is a complete backup of all the system
software. If the computer has a tape drive or an optical disk, this can be
done immediately; otherwise, the administrator should do the least amount of
system configuration required for a backup to be made.
ACTION : Backup the original software distribution, or make sure
the original load media is saved, and then save a list of
files that were changed during install.
Before Recording System Defaults
Before starting to record system defaults, a directory should be created to
store them. This model contains an example cron script that compares the
current computer state with the original or previous state. Besides
storing system defaults in a protected directory, they should also be recorded
on a removable disk or tape. If an unauthorized user does gain access to
root priviledges on the computer and changes the accounting system, the
administrator will still have an original copy of it for comparison. For
safety, the system administrator should check the files against the original
about once a month. For this model, a security directory under /usr/adm will
be used. As root, do the following:
mkdir /usr/adm/checks ; chmod 700 /usr/adm/checks
After the system administrator checks the validity of the attributes of the
files, he/she can use the cron file presented in the Detection section to record
the system defaults to the /usr/adm/checks directory and to a removable disk or
tape. Then, the administrator should configure a script to record file
attributes as part of a backup.
ACTION : Check file attributes regularly. It would be a good idea
to do an 'ls -lR' of the entire system right after the
initial install, in order to have a master list to check
against.
Recording SUID and SGID Programs
Before any software is added to the basic operating system release, the system
administrator should check for SUID and SGID programs. If unauthorized access
occurs, frequently the intruder will leave a program that enables priviledged
re-entry. The list of SUID and SGID programs should be stored both on and
off the computer. The version on the computer will be used by a daily cron
job to check for changes, while the version stored off of the computer will
ensure that even if root access is acquired, a record of the system's original
state is available. The command to list SUID and SGID files is:
find / -type f \( -perm -002000 -o -perm -004000 \) ls
-type f: looks only at regular files
-perm: checks for permissions
-002000: checks for SGID programs
-004000: checks for SUID programs
'ls' gives a listing of the results
To store the results in a file that can be checked against the results
of a cron procedure later change the command to:
find / -type f \( -perm -002000 -o -perm -004000 \) ls | \
sort > /usr/adm/checks/suid_sgid
[note that the \ ending the first line is a continue-on-the-next-line
mark, not part of the command itself]
ACTION : Record the SUID and SGID programs.
Check and Record Permissions on all Device Files
By changing the permissions on device files, an unauthorized user can gain
access to devices, using this access to change files, impersonate another user,
or listen in on conversations. Record the permissions on the device files on
and off the computer using:
ls -al /dev/* | sort > /usr/adm/checks/devices
ACTION : Record device permissions.
Record all World and Group Writable Files, Devices, and Directories
World writable files and directories allow unauthorized users to add, delete or
change existing configurations. There are, however, some directories that must
be world writable, most notably the /tmp area and the tty devices. Record
world writable files, devices, and directories using:
find / -perm -2 ! \(-type -l -o -type p -o -type s \) ls | \
sort > /usr/adm/world_write
For NFS mounted disks use:
find / \( -fstype 4.2 -o -prune \) -perm -2 ! \(-type -l \ -o \
-type p -o -type s \) ls | sort > /usr/adm/world_write
To record group writable files, devices, and directories:
find / -perm -020 ! \(-type -l -o -type p -o -type s \) ls|\
sort > /usr/adm/group_write
For NFS mounted disks:
find / \( -fstype 4.2 -o -prune \) -perm -020 ! \(-type -l \ -o \
-type p -o -type s \) ls | sort > /usr/adm/group_write
ACTION : Record world and group writable files, directories, and
devices. (Note: some of the above 'find' options are
system-dependent; ULTRIX and other flavors of UNIX may not
have '-fstype' or '-prune'.)
Record an Encrypted Checksum of all System Binaries
If unauthorized access occurs, the intruder will frequently replace system
binaries with changed versions that will allow them to regain access to the
computer or that will perform undesired actions on the computer later.
There are two methods for checking for changed system binaries; the first
compares checksums, while the second method encrypts files before doing a
checksum. The reason for the second approach is that a knowledgeable person
can change a file without changing the checksum, so this approach is more
secure. Unfortunately, it is difficult to put an encryption routine into a
cron process without the possibility that the encryption key will be found. It
is a good idea to keep both versions in the secure directory. Also, the
checksum method can be used in the cron file while the encrypted checksum methodshould be used by th
system administrator during monthly computer security
checks.
Sum calculates and prints a 16-bit checksum and the total blocks for the named
file. It is typically used to look for bad spots, or to validate a file
received over a network. An example is:
sum /bin/ar
19956 10
To do an encrypted checksum, the system administrator must supply
a key to crypt and pipe the output into sum. An example is:
crypt key </bin/ar | sum
35391 10
All files in these directories and their sub-directories should be
checked.
/bin /usr/bin
/usr/local/bin /dev
/etc /lib
/usr/lib /usr/ucb
/usr/include /usr/src
/usr/etc
ACTION : Record a checksum and an encrypted checksum of
vulnerable files.
Prevention
Passwords
Passwords and Shells on System Accounts
Check the system password file to ensure that all accounts
have passwords. Many vendors ship their computers with no
passwords on the system accounts. System accounts such as bin,
lp, and sync should have a '*' for the password field. No
account should be left without a password.
Also, the system administrator should check to see if the
computer comes with any passwords already assigned. Some
vendors give default passwords to system accounts. Since anyone
who has the same type of system knows what the default passwords
are, passwords should be changed immediately.
Every account needs to have a shell assigned to it. Most
administrative accounts should have /bin/false as the shell, which
would disallow crackers from gaining shell access using obscure
system holes.
ACTION : Put passwords or an '*' on every system account.
Change all factory set passwords. Use /bin/false
as the shell for administrative accounts.
Checking User Passwords
A vulnerable computer can jeopardize the security of your entire
network. The first line of defense against intruders is good password
management. Most unauthorized use of systems happens through weak
passwords. So, it is important to assign a password that has a mixture
of letters, numbers, and symbols, and that makes use of the full eight
character UNIX password field. Be sure that this first password isn't
a word or combination of words in the dictionary. '$2much4U' is an
example of a good password.
Users will base their idea of a proper password on the one that
the system administrator first assigns to them. Users should be
told to change their password immediately upon receipt of an
account. The system administrator should record the first password
on the user's account sheet and check it several days after the
account has been issued to be sure that it has been changed.
Another option is to install programs such as 'npasswd' or 'passwd+'.
They will proactively check passwords as they are entered into the
computer. However, these programs were not designed to be used with
shadow password systems. They will simply disallow users to choose
passwords which could be 'cracked'. Apply password aging if possible.
'npasswd' and 'passwd+' are available from info.cert.org in the
/pub/tools directory. 'skey' is a one-time password system which will
provide authentication over networks that are subject to eavesdropping/
reply attacks. It can be ftp'ed from coast.cs.purdue.edu in /pub/tools
/unix/skey.
There are several programs available from public archive sites
that check passwords. A detailed discussion of the method used by
these programs is in the NRL User's Responsibilities Model. If the
system administrator has little or no knowledge of how password
cracking programs work, he/she should read the User's section on
passwords. It is strongly recommended that the system
administrator use one of the password cracking programs regularly
to check the passwords on the computer. When these types of
programs are run on a computer where password security has not
been much of an issue, they typically find an amazing 30+% of all the
user passwords! The recommended program is Crack, written by
Alec D. E. Muffett. Crack, and a large dictionary that should be used
with it, is available from anonymous ftp at hightop.nrl.navy.mil.
The system administrator should install Crack and check user
passwords regularly. The first run of the program can take many
hours, but later runs take much less time. The system administrator
can configure Crack to distribute its workload across different
computers on the network. Although Crack installation instructions
are included, the system administrator should examine the Crack
README file, and become familiar with how the program works.
ACTION : Assign a secure first password to all user accounts.
ACTION : Run Crack on the password file, and continue to run it
regularly.
Expire Inactive Accounts
Computers with large numbers of users tend to have accounts
that become inactive. The beginning of a new fiscal year often
brings changes in who is using the computer, as users' funding
sources change. The system administrator needs to be sensitive to
those accounts that become inactive, and disable them by replacing
the password field in the /etc/password file with an '*'. If the user
has left important data on the computer, eventually they will
contact the system administrator to make arrangements to retrieve
the data. Once this data is retrieved, the account should be removed.
ACTION : Disable inactive accounts.
ACTION : Remove expired accounts.
Restrict Root Login to the Console
The ability to login to the root account should be restricted to
the console. Anyone not at the console should have to use 'su' to
become root. Tries to 'su' are recorded in a file in /usr/adm such as
/usr/adm/sulog, for accounting purposes. To restrict root login to
the console, edit the /etc/ttys or /etc/ttytab file, removing the
word "secure" from all entries but the entry for the console. The
/etc/ttytab file should be owned by root and have permissions 644.
ACTION : Edit /etc/ttys or /etc/ttytab to insure root logs in
at the console only.
Use /bin/su Instead of 'su'
When the system administrator uses su to become root, they
should not simply type 'su'. They should first unalias, and then use
the complete path name, i.e. /bin/su or /bin/su.wheel. This
prevents the system administrator from falling victim to several
different types of attacks. The unalias will prevent an alias for 'su'
from executing instead of the real 'su' while supplying the full path
name will insure that the correct version of 'su' is executed, if
someone put a phony 'su' program in a location that gets executed by
the path variable before the real 'su' program.
ACTION : Use /bin/su instead of 'su'. (Note: this is also
system-dependent.)
Restrict 'su' to the Wheel Group
Restriction should be placed on the ability to 'su' to root by
only allowing the ability to 'su' to root to members of the wheel
group. This feature appears only on newer BSD systems, where it is
the default.
ACTION : Restrict 'su' to members of the wheel group. (Also
system-dependent; some UNIXes do not support a 'wheel'
group. If no wheel group exists, you can set another
group to have execute permissions on the file.)
Check for Duplicate Groups
Replace any duplicated group with a group of its own. This
will remove ambiguity and make membership in a group clearer.
ACTION : Verify there are not duplicate groups.
Do Not Establish Guest Accounts
Do not establish accounts for guest usage. These accounts,
often appearing as an account with login guest and password
account, are common holes exploited by unauthorized users. Every
user of the computer should undergo the same security procedures,
receive the same security briefing, and be held accountable to the
same standards. When users are finished using the computer, their
accounts should be removed from the password file.
ACTION : Remove all guest accounts.
Network Security
Filtering
Check everything listed in /etc/services. If a port doesn't need
to be open to the world, filter it out at the router. More information
can be found in CERT advisory CA-95:01. /etc/services should be owned
by root and have permissions 644.
ACTION : Filter out unneeded services at the router.
'r' Commands
Commands preceded by the letter 'r', such as 'rlogin' or 'rsh',
should be disabled. They are a source of many attacks on sites
across the Internet. If you must use 'r' commands, make sure you
filter the TCP ports (512,513,514) at the router; it is important
to note this will only stop outsiders from abusing the commands.
ACTION : Disable 'r' commands.
NFS
NFS should be disabled if you don't need it. If you do need it,
make sure you filter traffic at the router level (TCP/UDP on port
111 and TCP/UDP on port 2049). This will prevent machines outside
your subnet from accessing file systems exported by your machines.
Enable NFS port monitoring; calls to mount a file system will only
be accepted from port < 1024 (root access). Check your vendor's
documentation to see if this is an option for your version of UNIX.
Under SunOS, to enable NFS port monitoring, add the following commands
to /etc/rc.local:
/bin/echo "nfs_portmon/W1" | /bin/adb -w /vmunix /dev/kmem > /dev/null s>&1 \
rpc.mountd
Install 'PortMap_3'. This is the 3rd enhanced portmapper release. The
code compiles fine with SunOS 4.1.x, Ultrix 4.x and ESIX System V release
4.0, but it will work with may UNIX flavors. This program is a
portmapper with access control in the style of the tcp_wrapper (log_tcp)
It provides a simple mechanism to discourage access to the NIS (yp),
NFS, and other services registered with the portmapper. In some cases,
better or equivalent alternatives are available; the SunOS portmap that
is provided with patch id 100482-02 should close the same security holes.
In addition, it provides NIS daemons with their own access control lists.
The "securelib" shared library (eecs.nwu.edu:/pub/securelib.tar) implements
control for all kinds of RPC services, not just the portmapper. Reportedly,
IRIX 4.0.x already has a secured portmapper. However, many vendors still
ship portmap implementations that allow anyone to read or modify its
tables and that will happily forward any request so that it appears to
come from the local system. Portmap_3 is available for ftp from
coast.cs.purdue.edu.
ACTION: Monitor NFS closely. Mount noexec, nosuid, and
nodev unless necessary.
Insure that /etc/exports has Proper Access Control
The system administrator should check the /etc/exports file
to verify that the computers granted mounting privileges are
explicitly stated. If access and root are not explicitly stated,
anyone, anywhere on the network can mount the disks. The file
should contain the complete computer name for the access and root
flags. E.g.:
/ -access=ollie.itd.nrl.navy.mil,root=stanley.itd.nrl.navy.mil
Also, run 'fsirand' for all your file systems. Check that any patches
for 'fsirand' are installed, make sure the file system is unmounted, and
run 'fsirand'. Predictable root handles assist crackers in abusing NFS.
Root should own /etc/exports, and the file should have the permissions
644. Export file systems read-only whenever possible, and use the secure
option if it is available. To check your exports, execute the
'showmount -e' command. Keep in mind that you must run /usr/etc/exportfs
for any changes to take effect.
ACTION : Use access control on all exported file systems.
'export -ro' whenever possible.
ACTION : Use root ownership on exported file systems.
No SUID and SGID on Mounted File Systems
Avoid storing SUID and SGID programs on mounted file
systems. Storing SUID and SGID programs on file systems that can
be mounted by other computers gives an unauthorized user an
opportunity to change or delete them.
ACTION : Avoid storing SUID and SGID programs on mounted file
systems.
NIS Security
NIS presents several problem areas because of design flaws in
the NIS code. There isn't much that can be done about the design
flaws, so system administrators use NIS at their own risk. If the
system administrator does decide to run NIS, verify that the use of
the '+' is in files on the clients, not on the server. Also make
sure that you can't log into the clients as '+' with no password; if
you can, they need a '*' in their password fields.
ACTION : Try not to run NIS; if you must, check for a '+' login.
Modem Device File Permissions
Set modem device file permissions (on files such as /dev/cua)
to 600, and ownership to root or uucp.
ACTION : Set modem device permission to 600; ownership to root
or uucp.
Check Files Made with tip
Shell escapes run under cu or tip should execute with the
user's ID. (tip and cu are suid programs). Test to see if this is true
by:
tip <my_modem_number>
connected
login: ~!
#escapes back to the original computer and prints [sh]
[sh]
touch /tmp/myfile
ls -l /tmp/myfile
# a Ctrl-d will close the shell on the computer
The listed file should be owned by the person who created it, not by
root or uucp. If the file is owned by root or uucp, there is a bug in
the tip or cu program, and it should be disabled and replaced.
ACTION : Check that shell escapes under cu and tip run with the
user's id.
Test to Verify that the Computer Hangs the Phone Up
Properly
If a computer is accessed through a modem there is the
possibility that when the user hangs up, the modem doesn't really
hang up the connection. If this happens, the next user calling the
computer on that line will get the previous user's login session. In
earlier days, this was one of the primary ways "hackers" got onto a
computer. They would just keep calling the same number until a
user logged out, but the user's modem did not hang up the call.
Here are a few tests to do to see if the computer hangs up
properly:
Call the computer and login. Type 'tty' to see which serial line
is in use. Log out. The computer should hang up the phone.
Call the computer and login, checking the tty line again.
Disconnect the phone cord from the modem.
Call the computer back on the same number. The system
administrator should get a new login banner, not a connection
to the old shell. Login again and check the tty to be sure it is
the same one. Type 'ps' to see if the old process was killed.
ACTION : Verify that the computer hangs up properly.
UUCP
Disable UUCP
If uucp isn't used, disable it, including the shell that it executes
for logging in. Remove any '.rhosts' file at the uucp home directory.
Make sure 'L.cmds' is owned by root. Ensure no uucp-owned files are
world-writable. Check that you have assigned a different uucp login
for each site that needs uucp access to your machine. Check that you
have limited the number of commands that each uucp login can execute
to a bare minimum.
ACTION : Disable UUCP, or try and restrict each login.
Sendmail
Test Sendmail to Verify that the Debug and Wizard Options
are not Enabled
Early versions of sendmail were released with the debug
option included. The option was intended to allow testing of
sendmail, but was not intended to be released because it is a major
security hole. This hole has been widely written about and widely
exploited, so if the computer does have a bug in the sendmail
program, the program must be replaced. To test for the bug use:
telnet Localhost 25
connected to localhost.
Escape character is '^]'.
220 sphinx.nrl.navy.mil Sendmail 5.52 ready at Mon,
27 Jan 92 11:23:57 EDT
kill
500 Command unrecognized
debug
500 Command unrecognized
wiz
500 Command unrecognized
quit
221 sphinx.nrl.navy.mil closing connection
Connection closed by foreign host
If *any* message other than 'Command unrecognized' appears, the
computer probably has a bug and sendmail should be replaced. Fixed
source for sendmail is available from anonymous ftp from ftp.uu.net.
Make sure you have installed all the latest sendmail patches. Eric
Allman's version 8.6.11 sendmail contains no KNOWN vulnerabilities.
Increase sendmail(8) logging to a minimum log level of 9. This will
help detect attempted exploitation of sendmail vulnerabilities. To
do this, include the following line in the options part of the general
configuration information section of the sendmail configuration file:
#log level
OL9
Also, increase the level of logging provided by syslog. Enable a minimum
level of "info" for mail messages to be logged to the console and/or the
syslog file. For example, include the following lines in the syslog.conf
file:
mail.info /dev/console
mail.info /var/adm/messages
ACTION : Test the sendmail program for bugs and increase logging
levels.
Wizard Password
When the system administrator enters 'wiz' in the above procedure,
a message about a 'wascally wabbit' may be displayed. If it is,
use extra care during this procedure. Verify that the wizard
password is not in the sendmail alias file. The original wizard
password begins with 'OW'. To check for it:
grep OW /etc/sendmail/aliases* (or wherever the aliases file
lies)
grep izard /etc/sendmail/aliases* (or wherever the aliases
file lies)
ACTION : Remove the wizard password from sendmail aliases file.
Mailing Files
Verify that the mail program will not mail files to directories
that do not have write permission. Be sure to check the carbon copy
(Cc:) option as well. An example is:
mail /trojan_horse
Subject::
Will this actually show up?
^ D
Cc: /trojan_horse.cc
Be sure to check all versions of mail, including rmail, on the
computer, as many computers come with two or three versions of
mail. Mail programs are most often found in /bin and /usr/ucb, and
sometimes in /usr/bin and /usr/local/bin.
ACTION : Verify all versions of mail on the computer cannot send
files to protected areas.
Mailing Lists
If you use the majordomo mailing list software, check that your version
is greater than 1.91.
ACTION : Don't use majordomo versions up to 1.91.
Tftp and Ftp Configuration
Check Tftp to Verify that it Cannot be Used to Get the
Password File
In the following test, if the password file is successfully copied to
tmp, the computer will let anyone in the world get the password file.
This is extremely undesirable because anyone on the Internet can use
tftp to get the password file, run a cracking program on it to recover
weak passwords, and gain access to the computer through one of the
user's accounts, making the unauthorized access very hard to detect.
To check tftp use:
tftp localhost
get /etc/passwd tmp
Error code 1: File not found
quit
If the error code message doesn't appear and you have managed to acquire
the password file, there is a bug in tftp and it should be disabled until
it can be replaced. Additionally, a shadowed password file scheme should
be installed if one doesn't already exist on the system; if configured
correctly, an intruder will be unable to gain anything useful from the
standard password file.
Unless the system administrator has a good reason to use it, disable
tftp altogether. Comment it out in the /etc/inetd.conf file.
Unfortunately, this is not always possible, because some diskless
workstations use the tftp protocol during the boot process; in that
case, tcp_wrap the tftp daemon.
ACTION : Ensure that tftp disallows password file transfer.
ACTION : Disable tftp unless it must be used in this environment.
Bugs in ftpd
There are some known bugs in the ftp daemon, ftpd, that is
dated before December 1988. There are known bugs in many versions
AFTER that date, as well. Make sure you install all patches before
running ftpd.
ACTION : Replace any ftpd daemon dated before December 1988.
Install appropriate patches.
Ftp Configuration
Instructions for setting up anonymous ftp are in the man pages
under ftpd. They should be read thoroughly before enabling an
anonymous ftp setup.
There must be an entry in the /etc/passwd file for ftp. The
home directory must be set to ftp's own directory. Many system
administrators use /usr/spool/ftp. As summarized by Garfinkel and
Spafford in "Practical UNIX Security":
mkdir ~ftp/bin ~ftp/etc ~ftp/pub
cp bin/ls ~ftp/bin
chmod 111 ~ftp/bin/ls
chmod 111 ~ftp/bin
chown root ~ftp/bin
sed -e 's/:[^:]*:/:*:/' /etc/passwd > ~ftp/etc/passwd make a
copy of the password file, replacing all the passwords with
asterisks.
sed -e 's/:[^:]*:/:*:/' /etc/group ~ftp/etc/group copy group also
chmod 444 ~ftp/etc/*
chmod 111 ~/ftp/etc
chown root ~ftp/etc
chmod 1777 ~ftp/pub set the sticky bit on the world writable
pub directory
chown ftp ~ftp/pub
chgrp ftp ~ftp/pub
chmod 555 ~ftp
chown root ~ftp
ftp://ftp.cert.org has tips on how to set up anonymous ftp as well,
in /pub/tech_tips/anonymous_ftp.
The anonymous ftp login will change the root directory to ~ftp
so the anonymous ftp user will not have access to the rest of the
computer. If ftp is not configured correctly, anyone on the Internet
may be able to access the computer. It is important to remember
that there should NOT be a valid shell in the password file for the
ftp account. It might read as follows:
ftp:*:400:400:Anon FTP:/home/ftp:/bin/false
Also, make sure that ~ftp/etc/passwd is NOT the same as /etc/passwd.
Create a password file with permissions 444 and owned by root. It should
not contain any accounts listed in /etc/passwd. It should have dummy
entries with disabled passwords, such as:
ftp:*:400:400:Anon FTP::
bowyer:*:0:0:J.::
The same thing goes for /etc/group; create a dummy ~ftp/etc/group.
In addition, make sure all delete, overwrite, rename, chmod and umask
options are NOT allowed for guests and anonymous users. In general,
anonymous users should not have any unnecessary priviledges. Also,
ensure ~ftp/.rhosts and ~ftp/.forward are zero length, permissions 600
and owned by root.
Make sure the ftp account doesn't own anything it is not supposed to,
nor should any files have ftp for their group if they are not part
of the ftp home directory. If they are, it would be possible to replace
them with a trojan horse. Last, NEVER mount disks from other machines
to the ~ftp hierarchy unless they are read-only.
ACTION : Configure anonymous ftp properly (system-dependent).
SITE EXEC
Make sure your ftp server doesn't have the SITE EXEC command. Do this
by telnetting to port 21 and typing SITE EXEC. If your ftp daemon has SITE
EXEC, then make sure you have the most recent version of the daemon (eg,
wu-ftp 2.4). In older versions of ftpd, SITE EXEC allows anyone to gain
shell via port 21. Check that any commands from ~ftp/bin, ~ftp/usr/bin,
~ftp/sbin, or similar directory configurations that can be executed by
SITE EXEC do not contain system commands or include a shell. If they do
contain system commands, it's possible for local users to gain root access.
ACTION : Make sure SITE EXEC is not enabled.
Set a Mail Alias for Ftp
Put an entry in the aliases file for the system administrator to
receive ftp's mail; root should own /usr/spool/mail/ftp, with permissions
400.
ACTION : Alias the system administrator to receive ftp's mail.
/etc/ftpusers
The system administrator should disable access to the ftp
facilities for every login ID that isn't a user, such as sync, bin,
lp, uucp, news, nobody, root, ingres, daemon, sundiag, and sysdiag.
Also, he/she may wish to disallow ftp access to particular users.
The /etc/ftpusers file should list every login ID that is NOT
allowed access to ftp, including all administrative IDs listed above.
ACTION : List all system accounts in /etc/ftpusers file.
Files and Directories
Setting the Umask
The umask value determines the default values for files and
directories created on the computer. Each user normally sets a
umask value in his/her own .login, .profile, or .cshrc file. The
system can set a default umask in the /etc/profile file. This
default umask is usually set to 022. This will give most system
files the permissions of 644 and the program files permissions of
755. Be sure to check root's umask to verify that it isn't creating
world and group writable files. Optimum security for individual
users would be a umask of 077, which creates files which are only
accessible by the creator.
ACTION : Set the default umask to at least 022. Check the
permissions of files created by root.
Avoid '.rhosts' Files
The biggest threat to the computer after weak passwords is the use
of '.rhosts' files. Every user, including root, can create these
files. The '.rhosts' file allows a user to log into the computer from
a remote site without using a password. Since there is no guarantee
that another system is secure, it is very dangerous to have these
files on the computer. Users should be instructed not to use '.rhosts'
files and the system administrator should write a cron script to
remove '.rhosts' files daily.
ACTION : Remove all '.rhosts' files currently on the computer.
Use a cron script to do this on a daily basis.
Permissions on all .files
Permissions on all executable .files in each user's home directory
and the default files that they are generated from should be checked
carefully. These files include .login, .logout, .profile, .cshrc,
.kshrc, .emacs, .exrc, .forward; /etc/profile or profile.std,
/etc/cshrc or cshrc.std, /etc/login or login.std, and /etc/logout or
logout.std. It is important that these files not be world writable,
because anyone could insert commands into them that would then
execute under the user's ID. Also, commands can be inserted into
some of these files to capture a user's password, write or email it
elsewhere, and then erase all traces of the trojan horse. Generally,
these files should not be world writable. It is recommended that
unless there is a reason to do otherwise, these files should not be
group writable; their permissions should be set to either 600 or 700.
A procedure should be placed in the cron file to check these files
regularly.
Furthermore, if any of these files call other scripts or programs,
verify that those programs run with the most restricted permissions
possible, and are not world writable or in world writable directories.
ACTION : Check permissions on all .file scripts and the default
files where they are generated.
ACTION : Check permissions on all scripts called by .files. Check
scripts' directory permissions.
Search for Special Block or Character Files in Directories
Other than /dev
Use find to search for block and character files. Put an entry
into the cron to do this and remove any special files.
ACTION : Search for block and character files in directories other
then /dev.
Search for .exrc Files in System Directories
Use find to search for .exrc files. Put an entry into the cron to
do this and remove any .exrc files found in system directories.
ACTION : Search for .exrc files in system directories.
uudecode Should not be SUID
The uudecode program, usually found in /usr/bin/uudecode,
should not have it's permissions set to 4xxx (SUID). If the uudecode
version is SUID, the system administrator should change the
permissions to remove the SUID bit.
ACTION : Remove the SUID enable bit from uuencode permissions.
Restore Should not be SUID
If the restore program is SUID, the system administrator
should change the permissions to remove the SUID bit.
ACTION : Remove SUID enable bit from restore permissions.
User's Home Directories Should not be World Writable
User's home directories should not be world writable. Unless
there is a reason to do so, they should also not be group writable.
Permissions on users home directories should be 755.
ACTION : Set user's home directory permissions to no greater then
755.
Root and System Directories Should not be World Writable
The root partition also should not be world or group writable.
Set the permission of this directory to 755, and include this check
in a cron script.
ACTION : Set root directory permissions to 755. Check for
changed permissions in a cron script.
Wtmp and Utmp Should not be World Writable
Ensure that the wtmp and utmp files are not world-writable.
ACTION : Remove world-write privileges from wtmp and utmp.
/etc/aliases.dir and /etc/aliases.pag Should not be World
Writable
Verify these files are not world writable. Also, verify that
any files created by /var/yp/Makefile are not world writable.
ACTION : Remove world write permission from
/etc/aliases.{dir,pag} and verify that any files
created by /var/yp/Makefile are not world writable.
Set the Sticky Bit on the /tmp and /usr/tmp Directories
Enable the sticky bit on the /tmp directory. The sticky bit
allows only the owner of a file to delete or rename it. Change the
permissions to 1777 on /tmp and /usr/tmp.
ACTION : Set the sticky bit on the /tmp and /usr/tmp
directories.
Check Sensitive Files and Directories
Check the /etc/hosts.equiv file to verify that it is configured
properly. Don't include computers in this file that cannot be verified
as secure. Only put computers in the local sub-network, under the
system administrator's direct administrative responsibility, in this
file. Make sure the computers listed in the file are fully qualified.
The first character in the file shouldn't be '-', and there should
NEVER be a '+' in it. Permissions on /etc/hosts.equiv should be set
to 600, and it should be owned by root. These rules also apply to
/etc/hosts.lpd. Any /etc/hosts* file should have comment lines removed
(those with the first characer of '#'). It has been possible in the
past for an intruder to change his host name to something with a '#'
in it, to be able to gain access to a computer.
Other files to check the contents of before the computer is put
on the network are:
/etc/aliases: comment out "decode" alias; ensure all programs
executed are owned by root with 755 permissions, and are
stored in a systems directory (e.g. /usr/local/bin).
/etc/inetd.conf: owned by root; mode 644; disable unneeded services.
/etc/inittab
/etc/motd and /etc/mtab: should be set to 644.
/etc/sendmail/aliases
/etc/sm and /etc/sm.bak: should be set to 2755.
/etc/state: should be set to 644.
/etc/syslog.pid: should be set to 644.
/usr/lib/aliases
/usr/lib/expreserve: replace versions prior to July 1993; if this
cannot be accomplished, remove execute permission.
/usr/kvm/crash: remove SETGID priviledges ('chmod g-s').
/vmunix: should be root-owned, group set to 0 (wheel on SunOS), and
permissions 644.
Check the contents of /etc/rc.*. Any program run by /etc/rc.*
should not be world writable, should not be in a directory that is
world writable, and should be owned by root. /etc/rc.* should not
start up rpc.rexd or its equivalent.
/etc/rc.local shouldn't chmod 666 /etc/motd. Ensure that the line
'rm -f /tmp/t1' (or similar) exists in /etc/rc.local to clean up
the temporary file used to create /etc/motd. This should occur
BEFORE the code to startup the local daemons.
The following directories should be owned by root: /etc, /bin, /usr/etc,
/usr/bin, and /tmp. /tmp also needs a sticky bit (drwxrwxrwt).
ACTION : Read sensitive files to ensure contents are acceptable.
Check for changes regularly. Monitor directory
permissions.
Check Permissions on /dev/*mem Files
File permissions of /dev/*mem should not be world readable
or world writable. These files access the computer's memory,
therefore world read and write permissions could allow an
unauthorized user to change the instructions in memory to gain
privileges or access to otherwise protected processes. Ideally, the
group on the /dev/*mem files should be "kmem". All programs, such
as 'ps', that need to read from /dev/*mem, should be SGID to
whatever group owns the /dev/*mem files.
ACTION : Check that /dev/*mem files are not world read or
writable. If possible put them in group "kmem" and set
programs that access /dev/*mem to SGID "kmem".
Check Permission of Cron Scripts
Crontab files and their directories should not be world read,
write, or executable. This keeps unauthorized users from changing
crontab files.
ACTION : Set least possible permissions on crontab files and their
directories.
Miscellaneous Concerns
Path Concerns
The path variable has two security problems associated with
it. The first problem is that users tend to put a '.' (current
directory) in their path variable, and most put this as the first
directory searched! This sloppiness has spilled to many system
administrators and opens the door for an earlier-described attack
where the attacker replaces a file by the same name as a commonly
used file so that when the file is accessed the phony version
executes. This phony version may be as crude as recording the root
password when the system administrator su's (improperly), mailing
the password off, and erasing itself while printing 'Sorry' and calling
on the real su program to take over.
This type of attack can also be successful if the path is set
incorrectly, or if the path lists a world writable directory before
the intended directory. An unauthorized user can deposit a phony
program in the world writable directory, having it executed
legitimately by the path variable.
The path should first list the directories that contain binaries,
starting with /bin, and including the ucb directory, the libraries, and
etc directories. Since the root account should not be used for
personal work, the system administrator's personal directories
should not be in root's path.
ACTION : Don't use a '.', don't have world writable files
and list binary directories first in roots path.
YP Security
When using ypbind, NIS can be spoofed into giving information to the
wrong computer. This situation can be avoided by using the -secure
flag with the ypbind command.
ACTION : Use the -secure flag with ypbind.
Fingerd Bug
There is a hole in the fingerd program that allows an unauthorized
user to overwrite the buffer, planting instructions on the stack
without ever gaining access to the computer. The fingerd program
dated after 5 NOV 88 has closed the hole.
ACTION : Replace fingerd programs dated before 5 NOV 88.
Disable the Rexecd Daemon
Comment out the rexecd line in the /etc/inetd.config file. Rexecd
contains too many holes to be used safely.
ACTION : Disable rexecd.
Rdist Upgrade
CERT recently reported a hole in versions of rdist. The system
administrator should check to see if the rdist version has been fixed.
The system administrator can get updated versions of rdist for the
computer from anonymous ftp at hightop.nrl.navy.mil. A temporary
fix would be to remove the SUID bit from the rdist file.
ACTION : Replace rdist with a secure version, or remove the
SUID bit if no secure version is available.
Check At
At allows users to queue execution of programs to be run later. The
at directory stores files that should not be writable by others, and
the files at creates should not be readable or writable by others.
Check the permissions of /usr/spool/at, /usr/spool/atrun, or
/var/spool/atrun. Disable the atrun daemon if there is a problem.
ACTION : Check the permissions of /usr/spool/at, /usr/spool/atrun,
and /var/spool/atrun. Disable the atrun daemon if there
is a problem.
Checking System Integrity
A program named COPS is available from anonymous ftp on
hightop.nrl.navy.mil. COPS should be run after every software
upgrade, and at least every month. It provides redundant checks
for many security problems addressed here. You can also use a
program called 'SPI', available via ftp from assist.mil.
The Tripwire package, available from coast.cs.purdue.edu, maintains
a checksum database of important system files. It can serve as an
early intrusion detection system. It would be important to note,
however, that tools dependent on any type of checksum can possibly
be thwarted by some of the more knowledgeable intruders. Commercial
intrusion detection systems are also available. Some information is
available from the Intrusion Detection mailing list and archives; to
subscribe to the list, mail [email protected] with "subscribe ids"
in the body of your message.
ACTION : Install and run COPS or SPI, fixing the holes that
the program finds. Run it after every software upgrade
and in a cron job every month. Consider installing
some kind of intrusion detection system.
Install tcp_wrapper (aka log_tcp)
This software provides logging and access control to most network services.
It is available via anonymous ftp from info.cert.org in the /pub/tools
directory. Customize and install wrappers on all your systems. Deny all
hosts by putting "ALL:ALL" in /etc/hosts.deny and explicitly list trusted
hosts who are allowed access to your machines in /etc/hosts.allow. Wrap ALL
TCP services that you have enabled. It is also a very wise idea to send
all your audit data to a machine which has little or no relation to the
machines being monitored, and/or send the data directly to a printer. Some
intruders can alter audit data before you even suspect they were there.
ACTION : Customize and install tcp_wrappers.
Don't Use 'xhost +'
When using X-Windows, grant permission to the display on a
computer-by-computer basis. Use 'xhost +computername' rather than
'xhost +'.
ACTION : Grant access only those those sites that need it
when running X-Windows.
Display Both Last Login and Who is Currently on at Login
Configure the computer to display who is currently on, using
the 'w' command, and when the current user previously logged on,
using last $USER | grep -v still | head -1, or similar, at login.
This is easily done by putting those two commands in /etc/profile,
and will let everyone see who is currently onto the computer as
well as when they last logged in. It is an easy way to remind users
to look for discrepancies.
ACTION : Display who is currently on and when this user was last
on for each new login session.
Backup Schedule
Create a backup schedule that meets the needs of the users.
Most system administrators will use a multi-level backup scheme in
which user data gets backed up daily, and less frequently changed
files are backed up weekly or monthly. If a problem occurs, the
administrator will need recent backups or users will lose many
hours of hard work.
ACTION : Establish a regular backup schedule and stick to it.
Lock Unattended Terminals
Any time the system administrator walks away from his/her
terminal, the screen should be locked so people cannot easily
access a privileged account. For maximum security, he/she
should log out when he/she leaves the terminal.
ACTION : Use a screen locker when a terminal is unattended.
SunOS Security
IP Forwarding
Make sure that IP forwarding is disabled (this is a problem with
AIX as well). Put the following line in the kernel configuration
file:
options "IPFORWARDING=-1"
Framebuffers
If somebody can log into your Sun workstation from a remote
source, they can read the contents of your framebuffer, which
is /dev/fb. Sun provides a mechanism which allows the user
logging in to have exclusive access to the framebuffer, by using
the file /etc/fbtab. A sample /etc/fbtab file:
# File: /etc/fbtab
# Purpose: Specifies that upon login to /dev/console, the
# owner, group and permissions of all supported
# devices, including the framebuffer, will be set to
# the user's username, the user's group and 0600.
# Comments: SunOS specific.
# Note: You cannot use \ to continue a line.
#
# Format:
# Device Permission Colon separated device list.
#
/dev/console 0600 /dev/fb
/dev/console 0600 /dev/bwone0:/dev/bwtwo0
/dev/console 0600 /dev/cgone0:/dev/cgtwo0:/dev/cgthree0
/dev/console 0600 /dev/cgfour0:/dev/cgsix0:/dev/cgeight0
/dev/console 0600 /dev/cgnine0:/dev/cgtwelve0
#
/dev/console 0600 /dev/kb:/dev/mouse
/dev/console 0600 /dev/fd0c:/dev/rfd0c
After the above file has been created, reboot your machine, or log
out fully, then log back in again.
Read the man page for fbtab(5) for more information.
/usr/kvm/sys/*
Make sure no files under /usr/kvm/sys/ are group-writable.
/dev/nit
To see if your system is running in promiscuous mode, do an 'ifconfig -a'.
If you see PROMISC, there is a sniffer on your network. However, it
is also possible to set up a sniffer without the PROMISC flag showing
up. Disable the /dev/nit interface if you don't need it. For SunOS 4.x and
Solbourne systems, the promiscuous interface to the network can be
eliminated by removing the /dev/nit capability from the kernel. Once the
procedure is complete, you may remove the device file /dev/nit since it's
no longer functional.
EEPROM Security
The eeprom on the server should be set to require a password before
being booted from CD or tape from the prom monitor:
eeprom secure=command
Tools for Checking Suns
There is a program available from coast.cs.purdue.edu called 'Secure_Sun'.
(/pub/tools/unix/secure-sun-check) It checks for 14 common SunOS
configuration security loopholes. It's only been tested on SunOS4.0.3
on Sun4, Sun3, and Sun386i machines. Each test reports its findings, and
will offer to fix any problems found. The program must be run as root if
you want it to fix any of the problems.
Patches are available via World Wide Web at http://sunsolve1.sun.com.
Sun also makes its security patches available to customers who don't
have a support contract, via anonymous ftp:
/systems/sun/sun-dist on ftp.uu.net
AIX Security
There is a document entitled 'Preparing your AIX System for SATAN',
written by the AIX Security Response Team, which provides detailed
information on AIX-specific vulnerabilities. It can be ftp'ed from
hightop.nrl.navy.mil, as /pub/models/aix-security.
IRIX Security
Disable the /usr/lib/vadmin/serial_ports program if you aren't using your
serial ports and don't need to change their configuration. If you are using
version 5 and the serial_ports program is present, it has been superceded
by /usr/Cadmin/bin/cports on version 5 and therefore, is no longer required.
/usr/lib/vadmin/serial_ports can be disabled by the following command:
# /bin/chmod 700 /usr/lib/vadmin/serial_ports
If you intend to change the serial port configuration, you can still
disable the serial_ports program as above. To change the serial port
configuration, run the serial_ports program as root.
There is an IRIX security scanner available for ftp from coast.cs.purdue.edu.
It's in /pub/tools/unix/securescan/.
X-windows Security
Access to your X server may be controlled through either a host-based or
user-based method. The former is left to the discretion of the
systems administrator and is useful as long as all hosts registered
the /etc/Xn.hosts file have users that can be trusted, where 'n'
represents your X server's number.
This may not be possible at every site, so a better method is to educate
users about the security implications. Better yet, when setting up an
account, give the user a set of X security-related template files, such
as '.xserverrc' and '.xinitrc'.
Release 6 of X11 is now available and solves many problems associated with X
security. If possible, obtain the source for R6 and compile and install it
on your system. Source for R6 is available via anonymous ftp from:
ftp://munnari.oz.au/X.V11/R6
'xdm' bypasses the normal getty and login functions, which means that
quotas for the user, ownership of /dev/console and possibly other
preventive measures put in place by you may be ignored.
Read the man pages for xauth and X security, and configure systems security
appropriately.
Securing Telnet and Ftp Sessions
There is a tool called 'SRA' which provides drop-in replacements for
telnet and ftp client and server programs. It uses secure RPC code to
provide encrypted authentication across the network, so plaintext
passwords aren't used. The clients and server negotiate the availability
of SRA so that they work with unmodified versions. These programs
require no external keyserver or ticket server, and work equally well for
local or internet-wide connections.
Another option is Kerberos. Kerberos is a network authentication system
for use on physically insecure networks, based on the key distribution
model presented by Needham and Schroeder. It allows entities communicating
over networks to prove their identity to each other while preventing
eavsdropping or replay attacks. It also provides for data stream
integrity (detection of modification) and secrecy (preventing
unauthorized reading) using cryptography systems such as DES.
Both tools are available for ftp from coast.cs.purdue.edu in the /pub/tools
directory.
Firewalls
It may even be feasible to install a firewall on your network. Detailed
information is available from various sources, including the Firewalls
mailing list. (send mail to majordomo@greatcircle.com with 'subscribe
firewalls' in the message body) At least two firewall products are available
as shareware, and there are several commercial products. 'Drawbridge'
and 'fwtk' are available for ftp from coast.cs.purdue.edu.
Detection
Check for BAD 'SU'
Check the /usr/adm/messages file for failed 'su' attempts. If
there are attempts to 'su' by users who do not have root privileges,
the system administrator should contact them to verify that they
were the ones who tried to 'su'. Repeated 'su' failures are a sign of
someone trying to gain privileges they are not entitled to, and should
be treated accordingly. They often indicate an account that has been
compromised and is now being used to try to gain further privileges.
ACTION : 'grep BAD /usr/adm/messages' for bad 'su' attempts.
Monitor Messages, Last, Lastcomm, Etc.
Get in the habit of reading through the /usr/adm/messages
files, looking for system problems.
Use 'last' to check that all connections are by legitimate users
and the the users are entering the computer from expected places.
If there is unusual activity, call the user to double check that the
activity was really generated by him/her, or if misconducted is
suspected, contact the user's government supervisor.
If accounting is enabled, check lastcomm regularly for strange
activity.
Edit the /etc/syslog.conf file to control where messages are logged.
Make sure that these logs are not readble or writable by users.
ACTION : Use syslog.conf to control logging of messages and read
the message files it creates.
Double Check the System Before Long Weekends
Long weekends, such as over Thanksgiving, Christmas, New Year's,
the Fourth of July, etc., are traditional times for increased
break-in attempts. Double check the computer before long weekends
to ensure there are no security problems with it. A backup just
before a long weekend is advisable.
ACTION : Double check the computer before long weekends.
Description of cron Files
The previous section detailed some procedures that can be put
into cron files to help check the computer. Some example cron files
to assist in setting up the system are available using anonymous ftp
from hightop.nrl.navy.mil. The included README file explains what
the files do.
ACTION : Edit the cron files for the particular configuration and
install and run it. Write a crontab entry to run the cron
files on the suggested schedule.
Do a Monthly System Check
Run the cron script against the cron stored on the removable media
in case the unauthorized user gained root access and altered the
system without being noticed.
ACTION : Do a monthly system check by comparing results against
the default configuration recorded on removable media.
Recovery
Any unauthorized accesses or attempts to access should be
immediately reported to the Computer Security Office. If an
intruder is discovered, the system administrator will want to
go through the computer thoroughly with someone from the
Computer Security Office.
First, the system administrator should remove the sub-network
from the rest of the network. Then, the system administrator
should remove each individual computer from the sub-network.
This is in case a program was left on one of the systems that
would seek out other computers to invade. The program won't be
able to reinfect computers that have already been recovered.
Next, the system administrator should run the cron file against
the system, comparing the current system to the state recorded on
the removable media. In this process, the administrator should
use the encrypted checksums to insure that system binaries have
not been altered. If any discrepancies are found, the offending
binary should be replaced with one from the original distribution
tape. The system administrator should also check all of the .file
scripts in individual user's directories and for new SUID and SGID
files. During this process the system administrator should try to
figure out how the unauthorized user gained access to the computer;
did he/she exploit a known hole, a weak password, or was a new
technique used?
The system administrator should look for strange files in
hidden places such as '...', '.. .', '.z', etc. This should be done
with 'ls -al' so the system administrator can also see if a normal
file has been linked to someplace else, such as linking '..' to a
trojan horse program.
After the system administrator is assured that each computer
has been completely repaired, he/she should assign new passwords
to every user, assuming that the unauthorized user has a copy
of the password file.
Lastly, the system administrator should review this checklist
to verify that any holes introduced either by the unauthorized user
or by the replacement of altered binaries have been closed.
Even given all of these precautions, there is some probability
that the computer is still infected. This is why it is important for
both the system administrator and the users to keep regular backups.
Backup frequency should depend on how much data the users can
afford to lose. The only way to be sure that any trojan horses have
been removed is to completely wipe the disk and reinstall the
system software from original distribution media. This also means
removing all user data. The system administrator then has to ensure
that all known holes have been closed, plus the holes used by the
unauthorized user. Reinstallation of user data should be done from
backups that are known to be clean, otherwise the administrator
may be doing this all over again!
Awareness
The system administrator should develop a written security policy
that fits the needs of the site and its users. The policy should
include a list of things to be checked and a schedule for checking
them; it will help to track down holes in the system should there
be unauthorized access, and will also provide the administrator
with documentation about the measures that have been insituted when
higher levels of management become interested in the security
program. The system administrator is the one held accountable for
security at the site and he/she may have to show that he/she has
performed his responsibilities in an appropriate manner. The policy
should also detail what actions will be taken against users who
refuse to be security sensitive. Details of this policy should be
spelled out for users when they are assigned new accounts so that
they will be aware of their responsibilities and understand what
actions will be taken against them should they not heed proper
security procedures.
The system administrator should also assess the situation to
determine if further steps should be taken to increase security at
the site. There is a list on further security enhancements in the
next section. In the policy should be a means of communicating
security related issues to the users. Below are some suggestions.
It is important to stay current with security issues. There are
mechanisms in place that disseminate security-related information.
Rest assured that someone attempting an unauthorized access will be
reading up on the latest security flaw discoveries, so the system
administrator should also.
Netnews
Netnews provides several news groups that every system
administrator should read daily. The comp.security.announce
group contains CERT postings of vulnerabilities in system
software. These postings will also instruct the administrator
on how to fix the problem, or where patches are available. The
alt.security newsgroup contains discussions of computer security
issues. Netnews is available at ra.nrl.navy.mil.
nrl.adp-security ADP Security
nrl.compusec-info CompuSec Information
alt.hackers
alt.hackers.malicious
alt.security
alt.security.index
comp.security.announce Announcements from the CERT about security.
comp.security.misc Security issues of computers and networks.
comp.security.unix
ACTION : Read appropriate newsgroups regularly.
Books
The following books may also be helpful:
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 Windows 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
Additional Information
Also available at http://iss.net:
'Security Patches FAQ'
'Compromise FAQ'
'Anonymous FTP FAQ'
'Sniffer FAQ'
There's a fairly recent holes list located at:
http://spy.org:70/0Z/System/bbs/SECURITY/LOCAL/HoleList.gz
Some other interesting WWW sites:
http://hightop.nrl.navy.mil/
http://www.cs.cmu.edu/afs/cs.cmu.edu/user/bsy/www/sec.html
http://www.cs.purdue.edu/coast/coast.html
http://www.cs.purdue.edu/homes/spaf/spafs-hotlist.html#csec
http://www.atlantic.com/atlantic/fire.html
http://ciac.llnl.gov/cstc/CSTCHome.html
http://mls.saic.com/
http://underground.org/
All the CERT advisories are available via ftp from ftp.cert.org
in /pub/cert_advisories. /pub contains other directories which
may contain files of interest, such as /papers and /tech_tips.
User Security Guide
The system administrator should provide users with a security
guide that outlines general security issues and includes instructions
on:
How to Pick a Good Password
If the password cracking program guesses someone's password,
give that user an explanation on how to pick a good
password. If the cracking program guesses the user's
password a second time, user counseling is in order.
Use Different Passwords on Different Sub-Networks
If a user's password is compromised, damage will be
limited if the user has different passwords on different
sub-networks.
How to Use the Email System
It should be stressed to the user that email is NOT a
secure form of communication. Sensitive information should
never be sent through email. PASSWORDS SHOULD NEVER BE
SENT THROUGH EMAIL. The user should assume everyone on the
Internet can read their mail; since anyone can pull packets
from the network, this may not be far from the truth.
Sending Passwords Over the Network
Users should be instructed that the network is not secure
and anyone on the network may be able to read packets sent
from or received by their computer. If the user has the option,
it is always better to login or ftp TO a remote computer from
NRL than to login or ftp to NRL FROM a remote computer. This
way, any passwords sent over the net during login are not for
accounts on NRL computers.
How to Set the Umask and the Permissions on Critical
Directories and Files
Although the system administrator checks for file and
directory permission in the cron scripts, users should be made
aware that they are the ones responsible for insuring system
integrity using proper permissions.
How to Access the Help System
Instruct the users on how to access the help system on
the computer.
ftp-ing Issues
Users should be instructed about the dangers of using any
software that is available only in binary form. They should be
instructed that Internet archive sites should not be trusted,
and that they should only ftp source code onto the computer.
They should read the source before compiling it, and if there
are things in the source that they are not sure of the results
of, they should get help in interpreting the source BEFORE they
compile it. As the old adage goes: Use the force, read the
source!
ACTION : Develop a user's guide for this site.
Account Request Form
Develop an account request form that contains enough
information about the user that the system administrator can get in
touch with them if there is an emergency, and enough information
for the system administrator to properly administer the account.
Things that the form should include are:
1. User's login ID.
2. User's home directory.
3. Expiration date on the account.
4. Computers to which the user has been granted access.
5. Groups that the user has been placed in.
6. Any aliases installed in the system that reference the
user.
7. User's government point of contact.
ACTION : Develop and implement a user account form.
System Security Diary
Keep a diary of the security checks done on the computer and
what their results are. Also, document what actions are
taken if holes are found or problems occur. If there is a problem,
others will want to know what the system administrator has been
doing to secure the computer. The Computer Security Office will
want to be able to look through the logs to help the system
administrator find where problems happened so they can be
corrected; NRL management will want to know why there are
problems at this site and the diary may be the system
administrator's best defense.
ACTION : Develop a written security policy. Document all security
related actions.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
