This appendix summarizes the hints and recommendations made
in this book. You can use this appendix as a reminder of things
to examine and do, or you can use it as an index.
-
Reread your manuals and vendor documentation.
-
Mark your calendar for 6-12 months in the
future to reread your manuals, again.
-
Order other appropriate references
on security and computer crime. Schedule time to read them when
they arrive.
-
Become familiar with your users' expectations
and experience with
UNIX
.
-
Write a letter to your vendors indicating your interest
and concern about (insufficient) software quality and security features.
-
Post a reminder above your computer or desk: "Security
is not `Me versus the Users' but `All
of Us versus Them.'"
-
Assess
your environment. What do you need to protect? What are you protecting
against?
-
Understand priorities, budget, and resources available.
-
Perform a risk assessment and cost-benefit analysis.
-
Get management involved.
-
Set priorities for security and use.
-
Develop a positive security policy. Circulate it
to all users.
-
Ensure that authority is matched with responsibility.
-
Ensure that everything to be protected has an "owner."
-
Work to educate your users on good security practice.
-
Don't have different, less secure rules
for top-level management.
-
Be sure that every person who uses your computer
has his or her own account.
-
Be sure that every user's account has a
password.
-
After you change your password,
$don't forget
it!
-
After you change your password, test it with the
su
command, by trying to log in on another
terminal, or by using the
telnet localhost
command.
-
Pick strong, nonobvious passwords.
-
Consider automatic generation or screening of passwords.
-
Pick passwords that are not so difficult to remember
that you have to write them down.
-
If you must write down your password, don't
make it obvious that what you have written is, in fact, a password.
Do not write your account name or the name of the computer on the
same piece of paper. Do not attach your password to your terminal,
keyboard, or any part of your computer.
-
Never record passwords online or send them to another
user via electronic mail.
-
Don't use your password as the password
to another application such as a Multi-User Dungeon (
MUD
)
game.
-
Don't use your password on other computer
systems under different administrative control.
-
Consider use of one-time passwords, tokens, or smart
cards.
-
Ensure that all users know about good password management
practices.
-
Ensure
that no two regular users are assigned or share the same account.
-
Never give any users, other than
UUCP
users, the same
UID
.
-
Think about how you can assign group IDs to promote
appropriate sharing and protection without sharing accounts.
-
Avoid use of the
root
account for routine activities
that can be done under a plain user ID.
-
Think of how to protect especially sensitive files
in the event that the
root
account is compromised. This protection
includes use of removable media and encryption.
-
Restrict access to the
su
command, or restrict the
ability to
su
to user
root
.
-
su to the user's ID when investigating
problem reports rather than exploring as user root.
-
Scan the files
/var/adm/messages
,
/var/adm/sulog
, or other appropriate log files
on a regular basis for bad
su
attempts.
-
Learn
about the useful options to your version of the
ls
command.
-
If your system has
ACLS
, learn
how to use them. Remember, do not depend on
ACLS
to protect files on
NFS
partitions.
-
Set your umask to an appropriate value (e.g., 027
or 077).
-
Never write
SUID/SGID
shell scripts.
-
Periodically scan your system for
SUID/SGID
files.
-
Disable
SUID
on disk partition
mounts (local and remote) unless necessary.
-
Determine if
write
,
chmod
,
chown
, and
chgrp
operations
on files clear the
SUID/SGID
bits on your system.
Get in the habit of checking files based on this information.
-
Scan for device files on your system. Check their
ownership and permissions to ensure that they are reasonable.
-
If your system has "universes"
or Context Dependent Files (
CDFS
), be sure that
all your administrative actions actually scan
all
the
files and directories on your system.
-
Learn about the restrictions
your government places on the use, export, and sale of cryptography.
Consider contacting your legislators with your opinions on these
laws, especially if they negatively impact your ability to protect
your systems.
-
Never use
rot13
as an encryption
method to protect data.
-
Don't depend on the
crypt
command to protect anything particularly sensitive, especially if
it is more than 1024 bytes in length.
-
If you use the Data Encryption Standard (
DES
)
algorithm for encryption, consider superencrypting with Triple-
DES
.
-
Use the
compress
command (or
similar compression system) on files before encrypting them.
-
Learn how to use message digests. Obtain and install
a message digest program (such as MD5).
-
Never
use a login password
as an encryption key. Choose encryption keys as you would a password,
however - avoid obvious or easily guessed words or patterns.
-
Protect your encryption key as you would your password - don't
write it down, put it in a shell file, or store it online.
-
Protect your encryption programs against tampering.
-
Avoid proprietary encryption methods whose strengths
are not known.
-
Consider obtaining a copy of the
PGP
software and making it available to your users. Use
PGP
to encrypt files and sensitive email, and to create and check digital
signatures on important files.
-
Make
regular backups.
-
Be certain that
everything
on your system is on your backups.
-
Remember to update your backup regimen whenever
you update your system or change its configuration.
-
Make paper copies of critical files for comparison
or rebuilding your system (e.g.,
/etc/passwd
,
/etc/rc
, and
/etc/fstab
).
-
Make at least every other backup onto a different
tape to guard against media failure.
-
Do not reuse a backup tape too many times, because
the tapes will eventually fail.
-
Try to restore a few files from your backup tapes
on a regular basis.
-
Make periodic archive backups of your entire system
and keep them forever.
-
Try to completely rebuild your system from a set
of backup tapes to be certain that your backup procedures are complete.
-
Keep your backups under lock and key.
-
Do not store your backups in the same room as your
computer system: consider off-site backup storage.
-
Ensure that access to your backup tapes during transport
and storage is limited to authorized and trusted individuals.
-
If your budget and needs are appropriate, investigate
doing backups across a network link to a "hot spare"
site.
-
Encrypt your backups, but escrow the keys in case
you lose them.
-
When using software that accesses files directly
rather than through the raw devices, consider remounting the filesystems
as read-only during backups to prevent changes to file access times.
-
Make periodic paper copies of important files.
-
Make
sure that every account has a password.
-
Make sure to change the password of every "default"
account that came with your
UNIX
. system. If
possible, disable accounts like
uucp
and
daemon
so that people cannot use them to log into your system.
-
Do not set up accounts that run single commands.
-
Instead of logging into the
root
account,
log in to your own account and use
su
.
-
Do not create "default" or "guest"
accounts for visitors.
-
If you need to set up an account that can run only
a few commands, use the
rsh
restricted shell.
-
Think about creating restricted filesystem accounts
for special-purpose commands or users.
-
Do not set up a single account that is shared by
a group of people. Use the group ID mechanism instead.
-
Monitor the format and contents of the
/etc/passwd
file.
-
Put time/tty restrictions on login to accounts
as appropriate.
-
Disable dormant accounts on your computer.
-
Disable the accounts of people on extended vacations.
-
Establish a system by which accounts are always
created with a fixed expiration date and must be renewed to be kept
active.
-
Do not declare network connections, modems, or public
terminals as "secure" in the
/etc/default/login
or
/etc/ttys
files.
-
Be careful who you put in the
wheel
group, as these people
can use the
su
command to become the superuser
(if applicable).
-
If possible, set your systems to require the
root
password when rebooting in single-user mode.
-
If your system supports the
TCB
/trusted
path mechanism, enable it.
-
If your system allows the use of a longer password
than the standard
crypt()
uses, enable it. Tell your users to use longer passwords.
-
Consider using some form of one-time password or
token-based authentication, especially on accounts that may be used
across a network link.
-
Consider using the Distributed Computing Environment
(
DCE
) or Kerberos for any local network of single-user
workstations, if your vendor software allows it.
-
Enable password constraints, if present in your
software, to help prevent users from picking bad passwords. Otherwise,
consider adding password screening or coaching software to assist
your users in picking good passwords.
-
Consider cracking your own passwords periodically,
but don't place much faith in results that show no passwords
cracked.
-
If you have shadow password capability, enable it.
If your software does not support a shadow password file, contact
the vendor and request that such support be added.
-
If your system does not have a shadow password file,
make sure that the file
/etc/passwd
cannot
be read anonymously over the network via
UUCP
or
TFTP
.
-
If your computer supports password aging, set a
lifetime between one and six months.
-
If you have source code for your operating system,
you may wish to slightly alter the algorithm used by
crypt
()
to encrypt your password. For example, you can increase the number
of encryption rounds from 25 to 200.
-
If you are using a central mail server or firewall,
consider the benefits of account-name aliasing.
-
If
your system supports immutable files, use them. If you don't
have them, consider asking your vendor when they will be supported
in your version of
UNIX
.
-
If possible, mount disks read-only if they contain
system software.
-
Make a checklist listing the size, modification
time, and permissions of every program on your system. You may wish
to include cryptographic checksums in the lists. Keep copies of
this checklist on removable media and use them to determine if any
of your system files or programs have been modified.
-
Write a daily check script to check for unauthorized
changes to files and system directories.
-
Double check the protection attributes on system
command and data files, on their directories, and on all ancestor
directories.
-
If you export filesystems containing system programs,
you may wish to export these filesystems read-only, so that they
cannot be modified by
NFS
clients.
-
Consider making all files on
NFS
-exported
disks owned by user
root
.
-
If you have backups of critical directories, you
can use comparison checking to detect unauthorized modifications.
Be careful to protect your backup copies and comparison programs
from potential attackers.
-
Consider running
rdist
from
a protected system on a regular basis to report changes.
-
Make an offline list of every
SUID
and
SGID
file on your system.
-
Consider installing something to check message digests
of files (e.g., Tripwire). Be certain that the program and all its
data files are stored on read-only media or protected with encryption
(or both).
-
Consider installing a dedicated PC or other non-
UNIX
machine as a network log host.
-
Have your users check the last login time each time
they log in to make sure that nobody else is using their accounts.
-
Consider installing a simple
cron
task to save copies
of the
lastlog
file to track logins.
-
Evaluate whether C2 logging on your system is practical
and appropriate. If so, install it.
-
Determine if there is an intrusion-detection and/or
audit-reduction tool available to use with your C2 logs.
-
Make sure that your
utmp
file
is not world writable.
-
Turn on whatever accounting mechanism you may have
that logs command usage.
-
Run
last
periodically to see
who has been using the system. Use this program on a regular basis.
-
Review your specialized log files on a regular basis.
This review should include (if they exist on your system)
loginlog,
sulog, aculog, xferlog
, and others.
-
Consider adding an automatic log monitor such as
Swatch.
-
Make sure that your log files are on your daily
backups before they get reset.
-
If you have
syslog
, configure
it so that all
auth
messages are logged to
a special file. If you can, also have these messages logged to a
special hardcopy printer and to another computer on your network.
-
Be aware that log file entries may be forged and
misleading in the event of a carefully crafted attack.
-
Keep a paper log on a per-site and per-machine basis.
-
If you process your logs in an automated fashion,
craft your filters so that they exclude the things you don't
want rather than pass only what you do want. This approach will
ensure that you see all exceptional condition messages.
-
Be
extremely
careful about installing
new software. Never install binaries obtained from untrustworthy
sources (like the Usenet).
-
When installing new software, install it first on
a noncritical system on which you can test it and observe any misbehavior
or bugs.
-
Run integrity checks on your system on a regular
basis (see Chapter 9).
-
Don't include nonstandard directories in
your execution path.
-
Don't leave any
bin
or library directories writable by untrustworthy accounts.
-
Set permissions on commands to prevent unauthorized
alteration.
-
Scan your system for any user home directories or
dot files that are world writable or group writable.
-
If you suspect a network-based worm attack or a
virus in widely circulated software, call a
FIRST
response team or the vendor to confirm the instance before spreading
any alarm.
-
Never write or use
SUID
or
SGID
shell scripts unless you are a hoary
UNIX
wizard.
-
Disable terminal answer-back, if possible.
-
Never have "." (the current directory)
in your search path. Never have writable directories in your search
path.
-
When running as the superuser, get in the habit
of typing full pathnames for commands.
-
Check the behavior of your
xargs
and
find
commands. Review the use of these
commands (and the shell) in all scripts executed by
cron.
-
Watch for unauthorized modification to initialization
files in any user or system account, including editor start-up files,
.forward
files, etc.
-
Periodically review all system start-up and configuration
files for additions and changes.
-
Periodically review mailer alias files for unauthorized
changes.
-
Periodically review configuration files for server
programs (e.g.,
inetd.conf
).
-
Check the security of your
at
program,
and disable the program if necessary.
-
Verify that any files run from the
cron
command
files cannot be altered or replaced by unauthorized users.
-
Don't use the
vi
or
ex
editors in a directory without first checking
for a Trojan
.exrc
file. Disable the automatic
command execution feature in
GNU
Emacs.
-
Make sure that the devices used for backups are
not world readable.
-
Make sure that any shared libraries are properly
protected and that protections cannot be overridden.
-
Develop a physical security plan that includes a
description of your assets, environment, threats, perimeter, and
defenses.
-
Determine who might have physical access to any
of your resources under any circumstances.
-
Have heat and smoke alarms in your computer room.
If you have a raised floor, install alarm sensors both above and
below the floor. If you have a dropped ceiling, put sensors above
the ceiling, too.
-
Check the placement and recharge status of fire
extinguishers on a regular basis.
-
Make sure that personnel know how to use all fire
protection and suppression equipment.
-
Make sure that the placement and nature of fire-suppression
systems will not endanger personnel or equipment more than is necessary.
-
Have water sensors installed above and below raised
floors in your computer room.
-
Train your users and operators about what to do
when an alarm sounds.
-
Strictly prohibit smoking, eating, and drinking
in your computer room or near computer equipment.
-
Install and regularly clean air filters in your
computer room.
-
Place your computer systems where they will be protected
in the event of earthquake, explosion, or structural failure.
-
Keep your backups offsite.
-
Have temperature and humidity controls in your computer
room. Have alarms associated with the systems to indicate if values
get out of range. Have recorders to monitor these values over time.
-
Beware of insects trying to "bug"
your computers.
-
Install filtered power and/or surge protectors
for all your computer equipment. Consider installing an uninterruptible
power supply, if appropriate.
-
Have antistatic measures in place.
-
Store computer equipment and magnetic media away
from building structural steel members that might conduct electricity
after a lightning strike.
-
Lock and physically isolate your computers from
public access.
-
Consider putting motion alarms or other protections
in place to protect valuable equipment when personnel are not present.
-
Protect power switches and fuses.
-
Avoid having glass walls or large windows in your
computer room.
-
Protect all your network cables, terminators, and
connectors from tampering. Examine them periodically.
-
Use locks, tie-downs, and bolts to keep computer
equipment from being carried away.
-
Encrypt sensitive data held on your systems.
-
Have disaster-recovery and business-continuation
plans in place.
-
Consider using fiber optic cable for networks.
-
Physically protect your backups and test them periodically.
-
Sanitize media (e.g., tapes and disks) and printouts
before disposal. Use bulk erasers, shredders, or incinerators.
-
Check peripheral devices for local onboard storage
that can lead to disclosure of information.
-
Consider encrypting all of your backups and offline
storage.
-
Never use programmable function keys on a terminal
for login or password information.
-
Consider setting
autologout
on
user accounts.
-
Conduct background checks of individuals
being considered for sensitive positions. Do so with the permission
of the applicants.
-
If the position is extremely sensitive, and if it
is legally allowable, consider using a polygraph examination of
the candidate.
-
Have applicants and contractors in sensitive positions
obtain bonding.
-
Provide comprehensive and appropriate training for
all new personnel, and for personnel taking on new assignments.
-
Provide refresher training on a regular basis.
-
Make sure that staff have adequate time and resources
to pursue continuing education opportunities.
-
Institute an ongoing user security-awareness program.
-
Have regular performance reviews and monitoring.
Try to resolve potential problems before they become real problems.
-
Make sure that users in sensitive positions are
not overloaded with work, responsibility or stress on a frequent
or regular basis, even if compensated for the overload. In particular,
users should be required to take holiday and vacation leave regularly.
-
Monitor users in sensitive positions (without intruding
on their privacy) for signs of excess stress or personal problems.
-
Audit access to equipment and critical data.
-
Apply policies of least privilege and separation
of duties where applicable.
-
When any user leaves the organization, make sure
that access is properly terminated and duties transferred.
-
Make sure that no user becomes irreplaceable.
-
Make
sure that incoming modems automatically log out the user if the
telephone call gets interrupted.
-
Make sure that incoming modems automatically hang
up on an incoming call if the caller logs out or if the caller's
login process gets killed.
-
Make sure that outgoing modems hang up on the outgoing
call if the
tip
or
cu
program
is exited.
-
Make sure that the
tip
or
cu
programs automatically exit if the user gets logged out of the remote
machine or if the telephone call is interrupted.
-
Make sure that there is no way for the local user
to reprogram the modem.
-
Do not install call forwarding on any of your incoming
lines.
-
Consider getting
CALLER
*
ID/ANI
to trace incoming calls automatically. Log the numbers that call
your system.
-
Physically protect the modems and phone lines.
-
Disable third-party billing to your modem lines.
-
Consider getting leased lines and/or callback
modems.
-
Consider using separate callout telephone lines
with no dial-in capability for callback schemes.
-
Check permissions on all associated devices and
configuration files.
-
Consider use of encrypting modems with fixed keys
to guard against unauthorized use or eavesdropping.
-
Be
sure that every
UUCP
login has a unique password.
-
Set up a different
UUCP
login
for every computer you communicate with via
UUCP
.
-
Make sure that
/usr/lib/uucp/L.sys
or
/usr/lib/uucp/Systems
is
mode 400, readable only by the
UUCP
user.
-
Do not export
UUCP
files or commands
on a writable
NFS
partition.
-
Make sure that the files in the
/usr/lib/uucp
directories can't be read or written remotely or locally
with the
UUCP
system.
-
Make sure that no
UUCP
login
has
/usr/spool/uucp/uucppublic
for its home directory.
-
Limit
UUCP
access to the smallest
set of directories necessary.
-
If there are daily, weekly, or monthly administrative
scripts run by cron to clean up the
UUCP
system,
make sure that they are run with the
UUCP
UID
but that they are owned by
root
.
-
Make sure that the
ruusend
command is not in your
L.cmds
file (Version 2
UUCP
.
-
Only allow execution of commands by
UUCP
that are absolutely necessary.
-
Consider making some or all of your
UUCP
connections use callback to initiate a connection.
-
Make sure that mail to the
UUCP
users gets sent to the system administrator.
-
Test your mailer to make sure that it will not deliver
a file or execute a command that is encapsulated in an address.
-
Disable
UUCP
over IP unless you
need
UUCP
.
-
If the machine has an active
FTP
service, ensure that all
UUCP
users are listed
in the
/etc/ftpusers
file.
-
Be sure that the
UUCP
control
files are protected and cannot be read or modified using the
UUCP
program.
-
Only give
UUCP
access
to the directories to which it needs access. You may wish to limit
UUCP
to the directory
/usr/spool/uucppublic
.
-
Limit the commands which can be executed from offsite
to those that are absolutely necessary.
-
Disable or delete any
uucpd
daemon if you aren't using it.
-
Remove all of the
UUCP
software
and libraries if you aren't going to use them.
-
Consider low-level encryption
mechanisms in enterprise networks, or to "tunnel"
through external networks.
-
Do not depend on IP addresses or
DNS
information for authentication.
-
Do not depend on header information in news articles
or email as they can be forged.
-
Routinely examine your
inetd
configuration
file.
-
If your standard software does not offer this level
of control, consider installing the
tcpwrapper
program to better regulate and log access to your servers. Then,
contact your vendor and ask when equivalent functionality will be
provided as a standard feature in the vendors' systems.
-
Disable any unneeded network services.
-
Consider disabling any services that provide nonessential
information to outsiders that might enable them to gather information
about your systems.
-
Make sure that your version of the
ftpd
program is up to date.
-
If you support anonymous
FTP
,
don't have a copy of your real
/etc/passwd
as an
~ftp/etc/passwd.
-
Make sure that
/etc/ftpusers
contains
at least the account names
root
,
uucp
, and
bin
. The file should
also contain the name of any other account that does not belonged
to an actual human being.
-
Frequently scan the files in, and usage of, your
ftp
account.
-
Make sure that all directory permissions and ownership
on your ftp account are set correctly.
-
If your software allows, configure any "incoming"
directories so that files dropped off cannot then be uploaded without
operator intervention.
-
Make sure that your
sendmail
program will not deliver
mail directly to a file.
-
Make sure that your
sendmail
program does not have
a wizard's password set in the configuration file.
-
Limit the number of "trusted users"
in your
sendmail.cf
file.
-
Make sure that your version of the
sendmail
program
does not support the
debug
,
wiz
, or
kill
commands.
-
Delete the "decode" alias in your
aliases
file. Examine carefully any other alias that delivers to
a program or file.
-
Make sure that your version of the
sendmail
program
is up to date, with all published patches in place.
-
Make sure that the
aliases
file cannot be altered
by unauthorized individuals.
-
Consider replacing
sendmail
with
smap
, or another
more tractable network agent.
-
Have an alias for every non-user account so that
mail to any valid address gets delivered to a person and not to
an unmonitored mailbox.
-
Consider disabling
SMTP
commands
such as
VRFY
and
EXPN
with
settings in your
sendmail
configuration.
-
Disable zone transfers in your
DNS
,
if possible.
-
Make sure that you are running the latest version
of the nameserver software (e.g.,
bind
) with all patches applied.
-
Make sure that all files used by the nameserver
software are properly protected against tampering, and perhaps against
reading by unauthorized users.
-
Use IP addresses instead of domain names in places
where the practice makes sense (e.g., in
.rhosts
files). (But beware
that most implementations of trusted commands don't understand
IP addresses in .rhosts, and that, in such cases, doing this might
introduce a vulnerability.)
-
Make sure that
TFTP
access, if
enabled, is limited to a single directory containing boot files.
-
Tell your users about the information that the
finger
program makes available on the network.
-
Make sure that your
finger
program is more recent
than November 5, 1988.
-
Disable or replace the
finger
service with something
that provides less information.
-
If you are using
POP
or
IMAP
,
configure your system to use
APOP
or Kerberos
for authentication.
-
Consider running the
authd
daemon for all machines
in the local net.
-
Configure your
NNTP
or
INND
server to restrict who can post articles or transfer Usenet news.
Make sure that you have the most recent version of the software.
-
Block
NTP
connections from outside
your organization.
-
Block
SNMP
connections from outside
your organization.
-
Disable
rexec
service unless needed.
-
Routinely scan your system for suspicious
.rhosts
files. Make sure that all existing
.rhosts
files are protected to
mode 600.
-
Consider not allowing users to have
.rhosts
files
on your system.
-
If you have a plus sign (+) in your
/etc/hosts.equiv
file,
remove it.
-
Do not place usernames in your
/etc/hosts.equiv
file.
-
Restrict access to your printing software via the
/etc/hosts.lpd
file.
-
Make your list of trusted hosts as small as possible.
-
Block incoming
RIP
packets; use
static routes where possible and practical.
-
Disable
UUCP
over IP unless needed.
-
Set up your
logindevperm
or
fbtab
files to restrict
permissions on frame buffers and devices, if this is possible on
your system.
-
If your X11 Server blocks on null connections, get
an updated version.
-
Enable the best X11 authentication possible in your
configuration (e.g., Kerberos, Secure
RPC
, "magic
cookies") instead of using
xhost
.
-
Disable the
rexd
RPC
service.
-
Be very cautious about installing
MUDS
,
IRCS
, or other servers.
-
Scan your network connections regularly with
netstat
.
-
Scan your network with tools such as
SATAN
and
ISS
to determine if you have uncorrected
vulnerabilities - before an attacker does the same.
-
Re-evaluate why you are connected to the network
at all, and disconnect machines that do not really need to be connected.
-
Consider running any
WWW
server
from a Macintosh platform instead of from a
UNIX
platform.
-
Do not run your server as user
root
. Have it set
to run as a
nobody
user
unique to the
WWW
service.
-
Become familiar with all the configuration options
for the particular server you use, and set its options appropriately
(and conservatively).
-
Disable automatic directory listings.
-
Set the server to not follow symbolic links, or
to only follow links that are owned by the same user that owns the
destination of the link.
-
Limit or prohibit server-side includes.
-
Be extremely cautions about writing and installing
CGI
scripts or programs. (See the specific programming
recommendations in the chapter.) Consider using
taintperl
as the
implementation language.
-
Configure your server to only allow
CGI
scripts from a particular directory under your control.
-
Do not mix
WWW
and
FTP
servers on the same machine in the same filesystem hierarchy.
-
Consider making your
WWW
server
chroot
into a protected directory.
-
Monitor the logs and usage of your
WWW
service.
-
If you are transferring sensitive information over
the
WWW
connection (e.g., personal information),
enable encryption.
-
Prevent general access to the server log files.
-
Be aware of the potential risks posed by dependence
on a limited number of third-party providers.
-
Enable Kerberos or Secure
RPC
if possible.
-
Use
NIS
+ in preference
to
NIS
, if possible.
-
Use netgroups to restrict access to services, including
login.
-
Put
keylogout
in your
logout
file if you are running
secure
RPC
.
-
Make sure that your version of
ypbind
only listens
on privileged ports.
-
Make sure that your version of
portmapper
does not
do proxy forwarding.
-
If your version of
portmapper
has a "securenets"
feature, configure the program so that it restricts which machines
can send requests to your portmapper. If this feature is not present,
contact your vendor and ask when it will be supported.
-
Make sure that there is an asterisk (*)
in the password field of any line beginning with a plus sign (+)
in both the
passwd
and
group
files of any
NIS
client.
-
Make sure that there is no line beginning with a
plus sign (+) in the
passwd
or
group
files on any
NIS
server.
-
If you are using Kerberos, understand its limitations.
-
Program your firewall and routers to block
NFS
packets.
-
Use
NFS
version 3, if available,
in
TCP
mode.
-
Use the netgroups mechanism to restrict the export
of (and thus the ability to remotely mount) filesystems to a small
set of local machines.
-
Mount partitions
nosuid
unless
SUID
access is absolutely necessary.
-
Mount partitions
nodev
, if available.
-
Set
root
ownership on files and directories mounted
remotely.
-
Never export a mounted partition on your system
to an untrusted machine if the partition has any world- or group-writable
directories.
-
Set the kernel
portmon
variable to ignore
NFS
requests from unprivileged ports.
-
Export filesystems to a small set of hosts, using
the
access=
or
ro=
options.
-
Do not export user home directories in a writable
mode.
-
Do not export filesystems to yourself!
-
Do not use the
root=
option when exporting
filesystems unless absolutely necessary.
-
Use
fsirand
on all partitions
that are exported. Rerun the program periodically.
-
When possible, use the
secure
option for
NFS
mounts.
-
Monitor who is mounting your
NFS
partitions (but realize that you may not have a complete picture
because of the stateless nature of
NFS
).
-
Reconsider why you want to use
NFS
,
and think about doing without. For instance, replicating disk on
local machines may be a safer approach.
-
Keep
in mind that firewalls should be used
in addition to
other security measure and not
in place of
them.
-
Consider setting a policy of default deny for your
firewall.
-
Consider internal firewalls as well as external
firewalls.
-
Use the most complete firewall you can afford and
one that makes sense in your environment. At the very least, put
a screening router in place.
-
Consider buying a commercially provided and configured
firewall, rather than creating your own.
-
Plan on centralizing services such as
DNS
,
email, and Usenet on closely guarded bastion hosts.
-
Break your network up into small, independent subnets.
Each subnet should have its own
NIS
server and
netgroups domain.
-
Don't configure any machine to trust machines
outside the local subnet.
-
Make sure that user accounts have different passwords
for machines on different subnets.
-
Make sure that firewall machines have the highest
level of logging.
-
Configure firewall machines without user accounts
and program development utilities, if possible.
-
Don't mount
NFS
directories
across subnet boundaries.
-
Have a central mail machine with MX aliasing and
name rewriting.
-
Monitor activity on the firewall regularly.
-
Configure your firewall/bastion hosts to
remove all unnecessary services and utilities.
-
Keep in mind that firewalls can sometimes fail.
Plan accordingly: periodically test your firewall and have defense
in depth for that eventuality.
-
Give serious thought to whether or not you really
want all your systems to be connected to the rest of the world,
even if a firewall is interposed. (See the discussion in the chapter.)
-
Consider installing the
smap
proxy in place
of the sendmail program to receive mail over the network.
-
Consider installing the
tcpwrapper
program to restrict
and log access to local network services.
-
Consider installing the
ident/authd
service
on your system to help track network access. However, remember that
the results returned by this service are not completely trustworthy.
-
Consider writing your own wrapper programs to provide
extra control or logging for your local system.
-
Convey to your vendors your concern
about software quality in their products.
-
Observe the 24 general rules presented in the chapter
when writing any software, and especially when writing software
that needs extra privileges or trust.
-
Observe the 17 general rules presented in the chapter
when writing any network server programs.
-
Observe the 14 general rules presented in the chapter
when writing any program that will be
SUID
or
SGID
.
-
Think about using
chroot
for privileged programs.
-
Avoid storing or transmitting passwords in clear
text in any application.
-
Be very cautious about generating and using "random"
numbers.
-
Plan
ahead: have response plans designed and rehearsed.
-
If a break-in occurs, don't panic!
-
Start a diary and/or script file as soon
as you discover or suspect a break-in. Note and timestamp everything
you discover and do.
-
Run hardcopies of files showing changes and tracing
activity. Initial and time-stamp these copies.
-
Run machine status-checking programs regularly to
watch for unusual activity:
ps
,
w
,
vmstat
, etc.
-
If a break-in occurs, consider making a dump of
the system to backup media before correcting anything.
-
Carefully examine the system after a break-in. See
the chapter text for specifics - there is too much detail
to list here. Specifically, be certain that you restore the system
to a known, good state.
-
Carefully check backups and logs to determine if
this is a single occurrence or is related to a set of incidents.
-
If user quotas
are available on your system, enable them.
-
Configure appropriate process and user limits on
your system.
-
Don't test new software while running as
root
.
-
Install a firewall to prevent network problems.
-
Educate your users on polite methods of sharing
system resources.
-
Run long-running tasks in the background, setting
the
nice
to a positive value.
-
Configure disk partitions to have sufficient inodes
and storage.
-
Make sure that you have appropriate swap space configured.
-
Monitor disk usage and encourage users to archive
and delete old files.
-
Consider investing in a network monitor appropriate
for your network. Have a spare network connection available, if
you need it.
-
Keep available an up-to-date paper list of low-level
network addresses (e.g., Ethernet addresses), IP addresses, and
machine names.
-
Ensure good physical security for all network cables
and connectors.
-
Consult
with your legal counsel to determine legal options and liability
in the event of a security incident.
-
Consult with your insurance carrier to determine
if your insurance covers loss from break-ins. Determine if your
insurance covers business interruption during an investigation.
Also determine if you will be required to institute criminal or
civil action to recover on your insurance.
-
Replace any "welcome" messages
with warnings against unauthorized use.
-
Put explicit copyright and/or proprietary
property notices in code start-up screens and source code. Formally
register copyrights on your locally developed code and databases.
-
Keep your backups separate from your machine.
-
Keep written records of your actions when investigating
an incident. Time-stamp and initial media, printouts, and other
materials as you proceed.
-
Develop contingency plans and response plans in
advance of difficulties.
-
Define, in writing, levels of user access and responsibility.
Have
all
users provide a signature noting their
understanding of and agreement to such a statement. Include an explicit
statement about the return of manuals, printouts, and other information
upon user departure.
-
Develop contacts with your local law-enforcement
personnel.
-
Do not be unduly hesitant about reporting a computer
crime and involving law-enforcement personnel.
-
If called upon to help in an investigation, request
a signed statement by a judge requesting (or directing) your "expert"
assistance. Recommend a disinterested third party to act as an expert,
if possible.
-
Expand your professional training and contacts by
attending security training sessions or conferences. Consider joining
security-related organizations.
-
Be aware of other liability concerns.
-
Restrict access to cryptographic software from the
network.
-
Restrict or prohibit access to material that could
lead to legal difficulties. This includes copyrighted material,
pornographic material, trade secrets, etc.
-
Make sure that users understand copyright and license
restrictions on commercial software, images, and sound files.
-
Prohibit or restrict access to Usenet from organizational
machines. Consider coupling this to provision of personal accounts
with an independent service provider.
-
Make your users aware of the dangers of electronic
harassment or defamation.
-
Make certain that your legal counsel is consulted
before you provide locally developed software to others outside
your organization.
-
Read the chapter. Develop a healthy
sense of paranoia.
-
Protest when vendors attempt to sell you products
advertised with "hacker challenges" instead of
more reliable proof of good design and testing.
-
Make your vendor aware of your concerns about security,
adequate testing, and fixing security bugs in a timely fashion.
-
Buy another 1000 copies of this book for all your
friends and acquaintances. The copies will make you intelligent,
attractive, and incredibly popular. Trust us on this.
-
Learn more about security.
-
Explore other resources concerning security,
UNIX
,
and the Internet.
-
Monitor newsgroups, mailing lists, and other resources
that will help you stay current on threats and countermeasures.
-
Explore professional opportunities that enable you
to network with other professionals, and add to your knowledge and
experience.
|