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.

Become familiar with the important files on your system.

Understand why SUID/SGID files have those permissions.

Understand how processes work on your system.

Understand the commands that are available to manipulate processes on your system.

Paper Sources

Electronic Resources

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.

Read the table and add your own site notes indicating the services you do and do not wish to support.