Security Doc Sought
From: xtasc@levels.unisa.edu.au
Newsgroups: comp.security.misc
Subject: [summary] Security Doc Sought Part 1/2
Message-ID: <19595.2b57e646@levels.unisa.edu.au>
Date: 16 Jan 93 10:41:10 +1030
Organization: University of South Australia
Lines: 700
Some time ago I posted a request for information about security related
documentation. Well after much gleaning of ftp sites, I've managed to
get more than enough to read for the next month or so, as well as some
very good pointers to software and a book on the subject.
My apologies if anything in this posting has already been posted, or is
widely known (I'm only new to reading the relevant groups). Similarly my
apologies if any respondee's didnt want their responses posted, but I
did say I'd summarize, and didnt see any notes to the contrary.
Its not that well formatted, but all the responses follow (minus the
people who requested this summary).
A word of warning :-) choose a time when no-one else needs your local
laserprinter .... Theres a lot there, and I managed to fray some tempers ....
Most importantly, many thanks to those who responded. I see no point in
reinventing the wheel, and now after the post I have a number of wheels
to choose from ... thanks again !
Regards .... Rob
Rob Mayfield
Senior Technical Analyst - MIS - Australian Submarine Corporation P/L.
GPO Box 2472, Adelaide S.A. 5001 Ph +61 8 348 7000 Fx +61 8 348 7001
Telex AA186451 Email mayfield@itd.adelaide.edu.au
PS: Ive posted direct followups to those who requested such, sorry if I
missed any.
/*****************/
From: IN%"breinhar@access.digex.com" "Robert B. Reinhardt" 10-JAN-1993 12:33:51.44
Here is something that might be useful to you.
==========================cut here=============================
This is VERSION 3 of my occassional paper on the architecture
of UNIX network security and related methods...
It is not very different from previous versions, but does
contain some additions and corrections at the request of
some of the folks who contribute these tools to the community.
I hope to complete a more complete and polished paper on this
subject in the coming months. My thanks in advance for those
who have contributed changes.
---Bob Reinhardt (breinhar@access.digex.com)
=======================cut here================================
SUMMARY PAPER: An Architectural Overview of UNIX Network Security
(Specifically oriented toward Internet connectivity)
Version 3
By Robert B. Reinhardt, November 11, 1992
(breinhar%srg@uunet.uu.net) - work
(breinhar@access.digex.com) - home
Nothing in this paper should be construed as a product
endorsement. The contents herein are the a result of light
research and some prototype implementation that I've done over the
past nine months. I don't know if this will help you or not. This
is basically just a digest of information that a lot of people
already know. This is for those of you who don't already know.
For each of the FIREWALL layers (sections) below, there is a
subsection that follows that gives a brief description of some of
the most widely used tools and techniques for implementing security
controls and their availability.
=================================================================
| | |
PUBLIC (or) NON-PRIVATE NETWORK ACCESS Y |
| O |
======================================================== U |
| | R Y
SECTION A --------------- | O
| Router | F N U
| | I E R
--------------- R T
| E W P
====================================================== W O O
| A R L
SECTION B --------------- L K I
| Dual-homed | L C
| UNIX Gateway| | A Y
--------------- | N
| | D A
======================================================== N
| E D
SECTION C --------------- Q
| Hosts on | U P
| Local Net | I E
--------------- P R
=========================================================== M S
E O
SECTION D Additional Measures to Enhance Security N N
T N
============================================================= E
L
SECTION E Functional Requirements and Security Policy |
|
================================================================= Before starting into a description of the various elements of
each of the above layers I feel I should reiterate the need for
first developing a local security policy. Each organization or
site needs to have an effective security policy. There are many
tools and techniques available to implement security controls, but
you should first conduct a thorough analysis of what your needs
are, in order to design and implement an efficient operational
environment. You need to determine what your requirements for
network services and features are, what level of security you
require, and what risks you are willing to accept. Sometimes the
benefit outweighs the risk, sometimes not. But, those decisions
differ for each organization. The "firewall" concept for creating
a security demarkation point between your local net and the
outside, as well as the various methods for enhancing security may
not be appropriate for everyone, and in some cases may not go far
enough. But I believe this a good starting point for almost anyone
with a general concern for UNIX network security.
Let me apologize right now to the authors of these tools and
designs. Since I am just giving a brief overview, I cannot do
justice to a complete description of them. To the reader let me
say that you should check the availability section and whenever
possible obtain a README or other information before making your
decisions. In many cases there is at least one paper (in most
cases probably several) that have been published that describe
these things in better detail. I'll try to list at least one
source for each.
Papers describing most if not all of these packages and
techniques can be found in the SYMPOSIUM PROCEEDINGS of the USENIX
Third UNIX Security Symposium (c) 1992 by the USENIX Association.
Some of the functionality of these tools overlap. Since you
have the source to these tools, you can modify them or customize
them to add new features.
SECTION A - Physical Access to your Network
A1. Packet filtering. Several internet protocol routers provide
the capability to filter packets. Packet filtering allows you
to program the router to make a decision whether or not
traffic can pass to or from your network based on several
criteria such as: source ip address, destination ip address,
protocol, tcp or udp port, etc.
Availability: I only have experience with CISCO routers,
however I've been told that Wellfleet and Proteon routers also
have this feature. There may be other vendors as well, but
they probably all implement it a little differently. Read:
Smoot Carl-Mitchell and John S. Quarterman, "Building Internet
Firewalls"; UnixWorld; February, 1992; pp 93-102.
NOTE: This layer of your security firewall also includes other
methods of access between networks such as CALL-BACK
MODEMS.
SECTION B - Logical Access to your Network
B1. TCP_WRAPPER. The "TCP_WRAPPER" tool provides monitoring and
control of network services. Essentially, what happens is
that you configure inetd on your dual-homed gateway to run the
TCP WRAPPER software whenever certain services (ports) are
connected to. Depending on how you configure TCP WRAPPER, it
will then LOG information about the connection and then
actually start the intended SERVER program that the connection
was intended for. Since you have the source to the tool, you
can modify it to do more depending on what your needs are.
For example, you may want TCP WRAPPER to connect the user to
a proxy service instead of the actual program, then have your
proxy software handle the transaction in whatever way your
security requirements demand.
Availability: This is available from several sources, but to
ensure that you get the most recent copy that CERT has
verified, you should use anonymous FTP to retrieve it from
cert.org in ~/pub/tools/tcp_wrappers/tcp_wrappers.*.
B2. SOCKS Library and sockd. The "sockd" and "SOCKS Library"
provide another way to implement a "tcp wrapper." It is not
intended to make the system it runs on secure, but rather to
centralize ("firewall") all external internet services. The
sockd process is started by inetd whenever a connection is
requested for certain services, and then only allows
connections from approved hosts (listed in a configuration
file). The sockd also will LOG information about the
connection. You can use the Socks Library to modify the
client software to directly utilize the sockd for outgoing
connections also, but this is described as very tedious and of
course requires you to have the source to those client
programs.
Availability: The socks package, which in addition to
including both the daemon and the library, has a pre-modified
FTP client and finger client; it is available via anonymous
FTP from s1.gov in ~/pub as socks.tar.Z. Contact the authors
for more information. David Koblas (koblas@netcom.com) or
Michelle R. Koblas (mkoblas@nas.nasa.gov).
B3. Kernel_Wrap for SunOS/RPC via Shared Libraries. Essentially
this is a wrapper for SunOS daemons that use RPC, such as
portmap, ypserv, ypbind, ypupdated, mountd, pwdauthd, etc. To
utilize this, you must have SunOS 4.1 or higher and must have
the capability to rebuild your shared libraries (but, you
don't need the source to your entire system). Essentially
what happens is that you modify the function calls that the
kernel uses to establish RPC connections, such as accept(),
recvfrom() and recvmsg(). Since these calls are maintained in
the shared libraries, you have access to modify them without
rewriting the kernel.
Availability: The secured C library package to implement this
is available via anonymous FTP from eecs.nwu.edu in
~/pub/securelib.
B4. SWATCH. Simple WATCHER is really two things, it is a program
used to parse through the myriad of LOG data generated by the
various security programs, in particular "syslog." But, it's
more than that. It is fully configurable with triggers
(actions), so that while it is continuously monitoring the LOG
in "real-time," it can take actions based upon certain high-
priority events that you tell it to watch for. To get full
use of this, you will need to modify your network service
daemons such as ftpd and telnetd so that enhanced logging is
added to syslog, to feed SWATCH.
Availability: The SWATCH source and documentation is
available via anonymous FTP from sierra.stanford.edu in
~/pub/sources.
B5. Controlled Access Point (CAP). This is more of a method or
protocol definition than a specific product. CAP provides a
network mechanism intended to reduce the risk of: password
guessing, probing for well-known accounts with default
passwords, trusted host rlogin, and password capture by
network snooping. It is really a design for a variation or
enhancement to the general firewall approach to connecting two
or more networks. In the paper describing this there is an
example of two local nets, one a secure segment with an
authentication service, and the other an unsecure segment.
Both communicate with each other via a CAP, while there is a
router for communication to public networks connected on the
unsecure side of the CAP. The CAP is essentially a router
with additional functionality to detect incoming connection
requests, intercept the user authentication process, and
invoke the authentication server.
Availability: Unknown. Contact the authors for more
information. J. David Thompson (thompsond@orvb.saic.com) and
Kate Arndt (karndt@mitre.org).
B6. Mail Gateway. This is more of a procedure than a software
package (although there are packages designed just to do
this). I included this to maintain continuity with what I'm
trying to illustrate in this paper. This really should be
applied to all network services that require external
connectivity (meaning any communication over non-private or
non-secure channels). In the simplest implementation of this,
you configure your router to filter packets so that all mail
traffic (SMTP protocol for example) is only allowed to and
from one host, the "Mail Gateway." Likewise, your DNS and MTA
software will need to be configured for this as well.
B7. TTY_WRAPPER. This is one of my pet ideas. I have not seen
something like this around, and I'll probably never have time
to develop it. But, essentially this would be like "TCP
WRAPPER," only it is designed specifically for serial
communications. After that, we will need a "PSEUDO-TTY
WRAPPER," but that's for another day.
B8. HSC-Gatekeeper. The HSC-Gatekeeper from Herve' Schauer
Consultants, is a complete solution to both layers A and B of
this firewall model. It consists of a thorough firewall
methodology and authentication server, providing pass-thru FTP
and TELNET services. The author (Herve Schauer) noted that
HSC-Gatekeeper was alone to be able to offer fully transparent
authentication for these services. I have not had personal
experience with HSC's products, so I cannot make a conclusive
statement about it other than to comment that the description
of it in HSC's paper "An Internet Gatekeeper" (available in
the USENIX Proceedings) depicts it (IMHO) as a very
comprehensive solution.
Availability: For more information, contact Herve Schauer via
e-mail at Herve.Schauer@hsc-sec.fr.
B9. AT&T INET. Since I discussed HSC's firewall solution, I
thought it only fair to mention AT&T's INET Gateway. For a
complete description of AT&T's internal solution, you should
read Bill Cheswick's paper "The Design of a Secure Internet
Gateway." For additional information, contact the author via
e-mail at ches@research.att.com. I do not believe that AT&T
is in the business of selling this solution to anyone, but the
paper describes in good detail how it was done. It should
provide the puritan firewaller additional depth to the
problems and possible solutions to an Internet firewall
approach.
SECTION C - Physical and Logical Access to Hosts on your Network
C1. Computer Oracle and Password System (COPS). COPS is a UNIX
security status checker. Essentially what it does is check
various files and software configurations to see if they have
been compromised (edited to plant a trojan horse or back
door), and checks to see that files have the appropriate modes
and permissions set to maintain the integrity of your security
level (make sure that your file permissions don't leave
themselves wide open to attack/access).
NOTE: Many vendors of UNIX are now bundling a security
status checker with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them.
Additional Comments: The current version of COPS (1.04) makes
a limited attempt to detect bugs that are posted in CERT
advisories. Also, it has an option to generate a limited
script that can correct various security problems that are
discovered. Dan also offers a quick hint that should easily
get you started using COPS. After you have unarchived the
COPS package, perform the following steps: './reconfig',
'make', and './cops -v -s . -b bit_bucket'. -- There is a lot
of README documentation included if you need more help.
Availability: COPS can be retrieved via anonymous FTP from
cert.org in ~/pub/tools/cops.
C2. Chkacct. Chkacct is a COPS for the ordinary user. This tool
is made available to the users to run, or it is run for them
once per day. It will do an integrity check on the status of
files in their own account and then mail them the results
(such as "Dear user: Your .rhosts file is unsafe"). This
package can help make your users more aware of security
controls and raise their level of participation in the
program.
Availability: Chkacct is distributed with the COPS package
(>= COPS 1.04), for additional information contact
shabby@mentor.cs.purdue.edu.
C3. CRACK. Crack helps the security administrator identify weak
passwords by checking for various weaknesses and attempting to
decrypt them. If Crack can figure out your password, then you
must choose a better password. It is very likely that a
determined intruder will be able to get the password too
(using similar techniques, or the Crack program itself, since
it is publicly available).
Availability: Crack is available via anonymous FTP from
cert.org in ~/pub/tools/crack/crack_4.1-tar.Z.
C4. SHADOW. The shadow password suite of programs replaces the
normal password control mechanisms on your system to remove
the encrypted password from the publicly readable file
/etc/passwd and hides them in a place that only this program
has permission to read. It consists of optional, configurable
components, provides password aging to force users to change
their passwords once in awhile, adds enhanced syslog logging,
and can allow users to set passwords up to a length of sixteen
characters.
NOTE: Many vendors of UNIX are now bundling a shadow
password suite with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them.
Availability: Shadow is available from USENET archives which
store the comp.sources.misc newsgroup. Distribution is
permitted for all non-commercial purposes. For more
information contact the author, John F. Haugh III
(jfh@rpp386.cactus.org).
C5. PASSWD+. Passwd+ is a proactive password checker that
replaces /bin/passwd on your system. It is rule-based and
easily configurable. It prevents users from selecting a weak
password so that programs like "CRACK" can't guess it, and it
provides enhanced syslog logging.
NOTE: Many vendors of UNIX are now bundling a proactive
password checker with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them.
Availability: Passwd+ is available via anonymous FTP from
dartmouth.edu in ~/pub/passwd+tar.Z.
C6. AUDIT. Audit is a policy-driven security checker for a
heterogeneous environment. It is fully configurable so that
you can set up Audit to exactly match your site's security
policy. This program functionally does what COPS is intended
to do, but does not hard-code your policy decisions for you
the way that COPS does.
NOTE: Many vendors of UNIX are now bundling an auditing
subsystem with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them. One
particular subject to note is that most (IMHO)
vendors auditing subsystems only collect and
regurgitate tons of raw data, with no guidance and
assistance for using that information. They leave
that up to you. The Audit and/or Swatch tools are
probably better.
Availability: The final version of Audit will eventually be
posted to USENET. However, the beta release will only be made
available on a limited basis, to larger, heterogeneous sites.
If your interested in participating in the beta test, send e-
mail to the auther, Bjorn Satdeva (bjorn@sysadmin.com).
C7. MIRO. Miro is a suite of tools for specifying and checking
security contraints (like COPS and Audit), including a couple
programming languages. It is general because it is not tied
to any particular OS, and it is flexible because security
administrators express site policies via a formal
specification language. It is easy to extend or modify a
policy by simply augmenting or changing the specification of
the current policy.
Availability: Miro is the product of a large research
project, and to understand it you need more than the paragraph
I've written above. For more information about the Miro
project send e-mail to (miro@cs.cmu.edu), there is even a
video available. The authors Ph.D thesis, as well as the
sources for the Miro tools, are available via anonymous FTP
from ftp.cs.cmu.edu. When you connect there, type "cd
/afs/cs/project/miro/ftp" and "get ftp-instructions"; this
will explain how to get the thesis and/or software.
SECTION D - Additional Security Enhancements
The tools described in sections {A...C} above, are what I
consider part of a "base" set of tools and functional requirements
for general security administration. The tools and methods
described in this section are additional measures that can be
combined with or added to your overall security program at any of
the other levels {A...C}.
D1. One-time Password ("Key Card"). Since reusable passwords can
be captured and used/reused by intruders, consider a "one-time
password" scheme. One-time passwords can be implemented using
software-only solutions or software/hardware solutions, and
there are several commercial products available. The
following is an example of what CERT uses. Each user is
assigned a "Digital Pathways" key-card (approximately $60 per
user). When you enter your PIN code, it supplies a password
that is good only one time. The only other piece to this, is
software that replace the login shell on your "firewall"
server.
Availability: The source-code for this shell is based on code
from the key card vendor and is currently not available to the
public domain via anonymous FTP. For additional information
about this, send e-mail to (cert@cert.org).
D2. Privacy Enhanced Mail (PEM). PEM is a RSA-based encryption
scheme that encrypts sensitive information, but more than that
it checks for message integrity and non-repudiation of origin,
so that the originator cannot deny having sent the message.
PEM is actually a protocol that is designed to allow use of
symmetric (private-key) and asymmetric (public-key)
cryptography methods. In this example, Trusted Information
Systems, Inc. (TIS) has implemented a PEM package using the
public-key technique together with the Rand MH Message
Handling System (version 6.7.2). TIS/PEM libraries can be
adapted for implementation of non-mail applications as well.
Availability: TIS/PEM is a commercially available product,
for additional information send e-mail to (pem-info@tis.com).
D3. Kerberos. Kerberos is a DES-based encryption scheme that
encrypts sensitive information, such as passwords, sent via
the network from client software to the server daemon process.
The network services will automatically make requests to the
Kerberos server for permission "tickets." You will need to
have the source to your client/server programs so that you can
use the Kerberos libraries to build new applications. Since
Kerberos tickets are cached locally in /tmp, if there is more
than one user on a given workstation, then a possibility for
a collision exists. Kerberos also relies upon the system time
to operate, therefore it should be enhanced in the future to
include a secure time server (timed is not appropriate).
There are two versions of Kerberos, one for OSF ported by HP,
and one BSD-based developed by the author.
Availability: Kerberos is distributed via anonymous FTP from
athena-dist.mit.edu in ~/pub/kerberos or ~/pub/kerberos5.
D4. Private-Key Certificates. This is not really a product, but
rather a design proposal that is an alternative method to PEM
for adding network security to applications such as mail.
Simply put, it uses the public-key style of implementation
with private-key cryptography. It can be adapted to different
types of applications and it is boilerplate so that you can
essentially plug-in any encryption algorithm. This is
designed so that public-key protocols no longer have to rely
on public-key encryption.
Availability: Unknown. For more information, contact Don
Davis, at Geer Zolot Assoc., Boston, MA (formerly of Project
Athena at MIT). His paper "Network Security via Private-Key
Certificates" better describes this techique.
D5. Multi-Level Security (MLS). After you've done everything else
(above) to make your network secure, then MLS will probably be
one of your next logical steps. That doesn't mean you have to
wait until you've done everything else before implementing
MLS, it's just (IMHO) that you would be wasting your time to
go to the Nth degree before covering the fundamentals. The
other alternative if you are just now deciding to buy your
UNIX operating system is to buy an MLS variant now, and after
you configure it to manage your security policy, go back
through layers {A...C} to see what you might add to make it
more secure in a networked environment. Many UNIX vendors are
now shipping or preparing to ship a MLS version. A couple
examples that immediately come to mind is SecureWare CMW+
(based on A/UX or SCO ODT 1.1) and AT&T USL System V-Release
4-Version 1-Enhanced Security (SVR4.1ES).
For additional information regarding MLS implementations
within the Department of Defense (DoD), contact Charles West
at (703) 696-1891, Multilevel Security Technology Insertion
Program (MLS TIP), Defense Information Systems Agency (DISA).
For additional information regarding SecureWare CMW+, contact
David Luterancik at (404) 315-6296, or send e-mail to
info@sware.com. For additional information regarding AT&T USL
SVR$.1ES, contact Tom Vaden at (908) 522-6154, or send e-mail
to fate@usl.com.
D6. File Encryption. Users should get into the habit of
encrypting sensitive files whenever they are stored in a
public place or transmitted via public communication circuits.
File encryption isn't bulletproof, but it is better than clear
text for sensitive information. The UNIX crypt utility is the
least secure of these tools, since it can be broken using
well-known decryption techniques. The UNIX des utility
(available in US only) is more secure. It has not been known
to be broken, however DoD does not sanction its use for
transmitting classified material. A new UNIX tool PGP 2.0 is
available (uses RSA encryption), however there may be
licensing issues to be concerned with.
D7. Secure Programming Methods. Programmers can assist in the
effort of security by reducing the chance that a potential
intruder can exploit a hole or bug that is coded into locally
developed software. There is probably a lot that can be said
about this, and their are probably many books on the subject
somewhere. But, here are some common recommendations. (A)
Never create a SETUID shell script. There are well-known
techniques used by intruders to gain access to a shell program
that is running as root. (B) List the complete file name,
including the full path in any system() or popen() call. (C)
Since there is no reason for users to have read access to a
SETUID file (or any exectuble for that matter), set
permissions to 4711 (SETUID) or 711 (Non-SETUID).
D8. Counterintelligence. To extend your security program to seek
out, identify, and locate intruders; you may want to modify
some of the security tools (especially those proxy service
daemons and event-driven auditors) to trace intruders back to
their source, and otherwise maintain logs of data on intrusion
attempts. This information can prove vital in taking an
offensive stance against security break-in's and can help
prosecute offenders.
D9. Other Possibilities. Depending on your requirements you might
look into specialized solutions such as Compartmented Mode
Workstations (CMW), end-to-end Data Link Encryption, and
TEMPEST. The NCSC (Rainbow Series) and ITSEC specifications
can help you define what level of need you have for security
and help lead you to additional types of solutions.
SECTION E - Security Policy
Everything discussed in sections {A...D} involve specific
things you can do, tools and techniques to implement, to address a
particular area or "hole" in security. Your SECURITY POLICY is
what ties all of that together into a cohesive and effective
SECURITY PROGRAM. There are many diverse issues to consider when
formulating your policy, which alone is one of the biggest reasons
why you must have one:
-- What are the functional requirements of your network?
-- How secure do you need to be? What needs to be protected?
-- How will you handle incident reporting and prosecution?
-- What does the law require you to do? What about privacy? Since
break-ins often occur via multiple hops on computers throughout the
US and the rest of the world, you will need to consider a variation
of federal, state, local, as well as foreign laws.
-- Make security a dedicated and deliberate effort.
-- User training and security awareness.
-- What is considered acceptable use for users? Do the users
understand what it is they are permitted to do and what it is they
are not permitted to do?
-- What is considered acceptable use for system administration
staff? Is using Crack to test passwords okay? Is giving friends
outside the organization accounts okay?
-- Maintain a working relationship with the Computer Emergency
Response Team (CERT) at Carnegie Mellon University (CMU) and your
Forum of Incident Response and Security Teams (FIRST) regional
representative "CERT" team.
-- PLUS a myriad of different issues too numerous to go into in a
summary paper.
By answering these questions you determine what packages and
methods in sections {A...D} that you want to implement, and in what
ways you want to modify or configure them. "A security policy is
a formal specification of the rules by which people are given
access to a computer and its resources." (and to extend that to
say...a network and its resources). Whatever tools you install to
help you maintain the security of your network and monitor it, they
must be configured to implement YOUR POLICY, or else they are not
doing the whole job that needs to be done. Therefore, you must
first have a POLICY.
For additional help in the area of policy development, contact
cert@cert.org, and they can probably lead you to useful
documentation on the subject and guide you to your FIRST regional
CERT team representative. A good starting point is Request For
Comments (RFC) 1244 "Site Security Handbook" (96 pages), which is
available via anonymous FTP from numerous RFC archive sites (for
example: nic.ddn.mil). SUMMARY OF AVAILABILITY
Section Name Availability
A1 Router Cisco, Wellfleet, Proteon
B1 Tcp_wrapper cert.org:/pub/tools/tcp_wrappers
B2 Socks s1.gov:/pub/socks.tar.Z
B3 Kernel_wrap eecs.nwu.edu:/pub/securelib
B4 Swatch sierra.stanford.edu:/pub/sources
B5 CAP e-mail to thompsond@orvb.saic.com
B6 Mail Gateway NOT APPLICABLE
B7 Tty_wrapper NOT APPLICABLE
B8 HSC-Gatekeeper e-mail to Herve.Schauer@hsc-sec.fr
B9 AT&T INET e-mail to ches@research.att.com
C1 COPS cert.org:/pub/tools/cops
C2 Chkacct cc.perdue.edu:/pub/chkacctv1.1.tar.Z
C3 Crack cert.org:/pub/tools/crack/crack_4.1-tar.Z
C4 Shadow comp.sources.misc (jfh@rpp386.cactus.org).
C5 Passwd+ dartmouth.edu:/pub/passwd+tar.Z
C6 Audit e-mail to bjorn@sysadmin.com
C7 Miro e-mail to miro@cs.cmu.edu
D1 Key-card e-mail to cert@cert.org
D2 TIS/PEM e-mail to pem-info@tis.com
D3 Kerberos athena-dist.mit.edu:/pub/kerberos5
D4 Private-key contact Don Davis, at Geer Zolot Assoc.
D5 MLS contact your UNIX vendor
D6 File encrypt contact your UNIX vendor
D7 Programming NOT APPLICABLE
D8 Counter-Intel NOT APPLICABLE
D9 Other Poss. research and contact various vendors
E* Policy RFC 1244 and cert@cert.org
Additional Sources of Information
Subscribe to the following mailing lists:
cert-advisory-request@cert.org
cert-tools-request@cert.org
firewalls@greatcircle.com
Read the following USENET newsgroups:
comp.security.announce (echos the CERT advisory mailing list)
comp.security.misc
alt.security (frequently dissolves into "flame wars")
comp.risks
comp.virus (almost exclusively for discussing PC and MAC viruses)
Copy files from the CERT Usenet Clipping Archive via anonymous FTP
from cert.org
CERT Contact Information:
Emergencies: +1 412 268-7090
FAX: +1 412 268-6989
E-mail: cert@cert.org
U.S. Mail: CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213-3890, USA
USENIX Papers are available directly from USENIX:
The USENIX Association
2560 Ninth Street, Suite 215
Berkeley, CA 94710, USA
READ: The SYMPOSIUM PROCEEDINGS of the USENIX Third UNIX Security
Symposium (September 14-16, 1992). It is 330+ pages, containing
papers describing in better detail a lot of the packages and
security techniques I briefly described in this paper.
From: xtasc@levels.unisa.edu.au
Newsgroups: comp.security.misc
Subject: [summary] Security Doc Sought Part 2/2
Message-ID: <19596.2b57e72d@levels.unisa.edu.au>
Date: 16 Jan 93 10:45:01 +1030
Organization: University of South Australia
Lines: 629
Part 2 .... contd
------------------------SUMMARY OF CHANGES-------------------------
Version 1 was distributed on September 19, 1992
Version 2 was distributed on October 8, 1992
Version 3 was distributed on November 11, 1992
(V3) Paragraph B2 (Socks) - Changes to e-mail address submitted by
Ed DeHart of CERT. Changes to availability submitted by the
authors, David and Michelle Koblas, the package is available from
s1.gov. (V3) Paragraph B8 (HSC-Gatekeeper) - Added this at the
suggestion of the author, Herve Schauer. (V3) Paragraph B9 (AT&T
INET) - Added this to show a contrast to new paragraph B8. (V2)
Paragraph C1 (COPS) - Additional Comments and Hints submitted by
Dan Farmer, the author of COPS. (V2) Paragraph C2 (Chkacct) -
Correction to availability, the package is distributed with COPS
(versions >= 1.04). (V2) Paragraph D1 (KeyCard) - Correction to
availability, source code is not in public domain, submitted by Jim
Ellis at CERT. (V3) Paragraph D5 (MLS) - Changed to take a more
progressive stance toward MLS in current operating environments.
(V3) Additional information - Added address for the new Firewalls
mailing list.
------------------------NOTICE---DISCLAIMER------------------------
The contents of this paper do not necessarily reflect the opinions
of my employer or anyone else that I know. Nothing in this paper
should be construed as a product endorsement. No warranty is
expressed or implied. Any comments? Please send me e-mail.
-------------------------------------------------------------------
------------------------NOTICE---COPYRIGHT-------------------------
(c) Copyright 1992, Robert B. Reinhardt. This paper is freely
distributable as long as the paper is not modified in any way,
includes this notice, and is provided without guarantee or warranty
expressed or implied. E-mail comments to breinhar@access.digex.com
-------------------------------------------------------------------
/*****************/
From: IN%"pcl@neon.athena.ox.ac.uk" 7-JAN-1993 23:05:04.74
black.ox.ac.uk:/DOCS/security/*
black.ox.ac.uk:/src/security/*
black is 129.67.1.165
Paul
/*****************/
From: IN%"Marten.Sahlen@eua.ericsson.se" 7-JAN-1993 18:42:41.95
Hi!
I know of a few places that might be of interest. The best source to start
with is probably the NIST Computer Security FTP Archive at csrc.ncsl.nist.gov.
It contains a wide variety of articles, info, software etc. in the security
field.
Another place is ariel.unm.edu in the /ethics directory, which contain a lot
of examples on how security policies can be designed.
Thirdly, for network security and particulary the Kerberos system, try
aeneas.mit.edu under pub/Kerberos/doc.
I would be very interested in a summary of all the sources you get pointers
to.
Regards...
--
>>>>-----------------Marten Sahlen etxsahm@eua.ericsson.se-----------------<<<<
>>>-----Ellemtel Telecom Systems Lab, Box 1505, S-125 25 Alvsjo, Sweden------<<<
/*****************/
From: IN%"SPG@NEREID.SUNQUEST.COM" 7-JAN-1993 16:36:19.73
Rob,
I would really _really_ appreciate a summary/follow-up on anything that you
find.
In regards to PD VMS security stuff, you might try anonymous ftp to
spcvxa.spc.edu in the [.Madison] and [.Macro32] directories
and
ACF1.NYU.EDU in various places.
--
Steve (SPG6) spg@sunquest.com
/*****************/
From: IN%"spaf@cs.purdue.edu" 7-JAN-1993 15:42:37.46
To: IN%"xtasc@levels.unisa.edu.au"
CC:
Subj: RE: Security related Documentation sought.
I don't know if I responded to you already or not. If I did, my
apologies.
You might try taking a look at my book (for Unix and for networks,
passwords, etc). Canned blurb follows.
Cheers,
--spaf
"Practical Unix Security"
by Simson Garfinkel and Eugene Spafford
O'Reilly & Associates (the Nutshell Handbook people).
500 pages, 1991, $29.95.
ISBN 0-937175-72-2
Quotes from reviewers:
Cliff Stoll:
Worried about who's in your Unix system?
Losing sleep because someone might be messing with your computer?
Having headaches from obscure computer manuals?
Then _Practical_Unix_Security_ is for you.
This handy book tells you where the holes are and how to cork 'em up.
Moreover, you'll learn about how Unix security really works.
Spafford and Garfinkel show you how to tighten up your Unix system
without pain. No secrets here -- just solid computing advice.
Buy this book and save on aspirin.
Tom Christiansen, Convex Computer Corp:
This book is the first I've seen that actually seemed to
address the many security issues that I keep around on
my own little list, and it did so well.
Paul Clark, Trusted Information Systems:
The book could easily become a standard desktop reference for
anyone involved in system administration. In general, its
comprehensive treatment of Unix security issues
will enlighten anyone with an interest in the topic.
Matt Bishop, Dartmouth
...I liked the book; it covers a lot of material not
normally covered and provides practical instructions on how to do
things. This will be very useful for practitioners...This book is
far superior to any other I have seen on UNIX security.
Laurie Sefton, Apple:
Finally there is a UNIX security book that covers the BSD world as
well as the SYS V version...The other aspect of UNIX security books
that has been sorely lacking was the "rest of UNIX" security. All the
other books had a very thin overview of "down and dirty" security, as
if they were afraid of giving out too much information...As soon as
this is out, I'm ordering copies for all my people, and extra copies
for the library at Apple.
Orders: 800-998-9938 (US & Canada)
707-829-0515 (Europe)
nuts@ora.com (e-mail)
Table of Contents:
Preface
Scope of this Book
Which UNIX System?
Conventions Used in this Book
Acknowledgments
Three Final Notes
Chapter 1 Introduction
What's Computer Security?
What's an Operating System?
History of UNIX
Security and UNIX
Security and Networks
Types of Security
Risk Assessment
Assessing Your Risk
Reacting to an Emergency
Other Important Steps
The Problem with Security Through Obscurity
The First Step
Chapter 2 Users and Passwords
Usernames
The /etc/passwd File
The /etc/passwd File and Network Databases
Passwords
Why Use Passwords?
Entering Your Password
Changing Your Password
Checking Out Your New Password
UNIX'S Encrypted Password System
The crypt() Algorithm
What is Salt?
The Care and Feeding of Passwords
Bad Passwords: Open Doors
Good Passwords: Locked Doors
Passwords on Multiple Machines
Writing Down Passwords
Administrative Techniques
Assigning Passwords to Users
Password Generators
Shadow Password Files
Password Aging and Expiration
Algorithm Changes
Preventing Direct Logins to Accounts
Account Names Revisited
Summary
Chapter 3 Users, Groups, and the Superuser
Users and Groups
User Identifiers (UIDs)
Groups and Group Identifiers (GIDs)
Special Users
The Superuser
Other Special Users
Impact of the /etc/passwd and /etc/group Files on Security
The su(1) Command: Changing Who You Are
Becoming the Superuser
Restricting su
The Bad su Log
Other Uses of su
Summary
Chapter 4 The UNIX File System
Files
Using the ls(1) command
Understanding File Permissions
File Permissions in Detail
Using File Permissions
chmod: Changing a File's Permissions
Setting a File's Permissions
Calculating Octal File Permissions
Using Octal File Permissions
The umask
The umask command
Common umask Values
Using Directory Permissions
SUID
SUID, SGID, and Sticky Bits
Problems With SUID
Finding All of the SUID and SGID Files
Turning off SUID and SGID in Mounted File Systems
SGID and Sticky Bits on Directories
(Berkeley UNIX and Sun OS Only)
SGID Bit on Files (System V UNIX only)
chown: Changing a File's Owner
chgrp: Changing a File's Group
Chapter 5 Defending Your Accounts
Dangerous Accounts
Accounts Without Passwords
Default Accounts
Accounts That Run a Single Command
Open Accounts
Group Accounts
Dormant Accounts
Changing an Account's Password
Changing the Account's Login Shell
Finding Dormant Accounts
Protecting the Root Account Under Berkeley UNIX
Secure Terminals
The wheel Group
Chapter 6 Securing Your Data
File Backups
Why Make Backups?
What Should You Back up?
Kinds of Backups
How Long Should You Keep a Backup?
Security for Backups
Database Backups and Daily Checking
Integrity Checking and Checklists
Checklists
File Protection Modes
Read-Only Disks
Comparison Copies
Checklists
Signatures
Chapter 7 The UNIX Log Files
The /usr/adm/lastlog File
The /etc/utmp and /usr/adm/wtmp Files
Last Program
Pruning the wtmp File
The /usr/adm/acct File
The Berkeley System Log (syslog) Facility
The syslog.conf Configuration File
Where To Log
Chapter 8 Protecting Against Programmed Threats
Programmed Threats: Definitions
Back Doors and Trap Doors
Logic Bombs
Viruses
Worms
Trojan Horses
Bacteria and Rabbits
Damage
Authors
Entry
Protecting Yourself
Shell Features
Startup File Attacks
Abusing Automatic Mechanisms
Unexpected Interactions
Protecting Your System
File Protections
SUID and SGID Programs
Notes on Writing a SUID Program
SUID Shell Scripts
Chapter 9 Modems
Theory of Operation
Serial Interfaces
The RS-232 Serial Protocol
Originate and Answer
Modems and Security
Modems and UNIX
Hooking Up a Modem to Your Computer
Setting Up the UNIX Device
Checking Your Modem
Physical Protection
Additional Security for Modems
Chapter 10 UUCP
About UUCP
The uucp Command
The uux Command
The mail Command
How The uucp Commands Work
Versions of UUCP
UUCP and Security
Assigning Additional UUCP Logins
Establishing UUCP Passwords
Security of the L.sys and Systems Files
Security in Version 2 UUCP
USERFILE: Providing Remote File Access
A USERFILE Example
L.cmds: Providing Remote Command Execution
Security in BNU UUCP
The Permissions File
Permissions Commands
uucheck(1): Checking Your Permissions File
Additional Security Concerns
Mail Forwarding for UUCP
Automatic Execution of Cleanup Scripts
Early Security Problems with UUCP
Summary
Chapter 11 Networks and Security
The Internet
Internet Addresses
The /etc/hosts File
Network Hostname Service
Clients and Servers
TCP/IP
UDP/IP
UNIX Network Servers
The /etc/services File
Starting the Servers
The /etc/inetd Program
Network Services
TELNET
rlogin and rsh
rexec
finger
Electronic Mail
FTP
TFTP
The X Window System
Security Implications of Network Services
Monitoring Your Network with netstat
Summary
Chapter 12 Sun's NFS
NIS
Netgroups
Setting up Netgroups
NFS
How NFS Works
The /etc/exports File
The showmount Command
Authentication and NFS
Improving Basic NFS Security
Limiting Exported File Systems
Limit Exported Machines
Use Root Ownership
Export Read-only
Do Not Export Server Executables
The fsirand Program
Summary: Security Implications of NFS
Chapter 13 Kerberos and Secure RPC
The Problem
What's Wrong with LANs?
Minimizing the Problems
MIT's Kerberos
What's It Like to Use Kerberos?
How to Install Kerberos
What's Wrong with Kerberos?
Sun Microsystems' Secure RPC
How Secure RPC Works
What's It Like to Use Secure NFS?
How to Install Secure RPC
What's Wrong with Secure RPC?
Chapter 14 Firewall Machines
What's a Firewall?
Internal Firewalls
External Firewalls
Setting Up a Firewall
The Choke
Choosing the Choke's Protocols
Setting up the Gate
Name Service
Electronic Mail
Netnews
FTP
Other Services
An Alternate Method
Special Considerations
Chapter 15 Discovering a Break-in
Prelude
Discovering an Intruder
Catching One in the Act
What to Do When You Catch Somebody
Tracing a Connection
Getting Rid of the Intruder
The Log Files: Discovering an Intruder's Tracks
Cleaning Up After the Intruder
New Accounts
An Example
A Last Note: Never Trust Anything Except Hard Copy
Chapter 16 Denial of Service Attacks and Solutions
Destruction Attacks
Overload Attacks
Process Overload Attacks
Disk Attacks
Swap Space Attacks
Soft Process Limits: Preventing Accidental
Denial of Service
Network Denial of Service Attacks
Service Overloading
Message Flooding
Signal Grounding
Chapter 17 Computer Security and the U.S. Law
Legal Options After a Break-in
Criminal Prosecution
The Local Option
Federal Jurisdiction
Federal Computer Crime Laws
Hazards of Criminal Prosecution
If You or One of Your Employees is a
Target of an Investigation
Other Tips
Civil Actions
Privacy and The Electronic Communications Privacy Act
Chapter 18 Encryption
Who Needs Encryption?
Cryptographic Strength
Types of Encryption Systems
ROT13
crypt
Enigma
UNIX crypt
Ways of Improving the Security of crypt
Example
The Data Encryption Standard (DES)
DES Modes
Use and Export of DES
DES Strength
Sun's des command
RSA and Public Key Cryptography
How RSA Works
An RSA Example
Strength of RSA
Proprietary Encryption Systems
Protect Your Key!
Chapter 19 Physical Security
Protecting Computer Hardware
The Environment
Accidents
Physical Access
Vandalism
Acts of War and Terrorism
Theft
Related Concerns
Protecting Data
Eavesdropping
Backups
Local Storage
Unattended Terminals
Appendix A UNIX Security Checklist
Appendix B Important Files
System Files
Important Files in your Home Directory
SUID Files in Berkeley UNIX
SGID Files in Berkeley UNIX
SUID Files in System V R3.2 UNIX
SGID Files in System V UNIX
Appendix C UNIX Processes
Processes
Processes and Programs
The ps Command
Process Properties
Creating Processes
Signals
The kill Command
Starting Up UNIX and Logging In
Process #1: /etc/init
Letting Users Log In
Running the User's Shell
Appendix D How Kerberos Works
Kerberos's Parts
Using Kerberos
Using a Service
Appendix E Other Sources
References
General Computer Security
UNIX Security
Computer Viruses and Programmed Threats
Computer Crime and Law
Understanding the Computer Security 'Culture'
Understanding and Using Networks
Using and Programming UNIX
Security Products and Services Information
Miscellaneous References
Organizations
Association for Computing Machinery (ACM)
IEEE Computer Society
ASIS
Computer Security Institute (CSI)
NIST
Computer Emergency Response Team (CERT)
DOE's Computer Incident Advisory Capability (CIAC)
Software Resources
Getting Kerberos
Getting COPS
/*****************/
From: rob@panache.b17a.ingr.com (Rob Mount)
Try the book:
Practical UNIX Security
Simson Garfinkel and Gene Spafford
O'Reilly & Associates, Inc. 1991
which is available from:
Addison-Wesley Publishers, Pty. Ltd.
6 Byfield Street
North Ryde, N.S.W. 2113
Australia
Voice: 61-2-888-2733 Fax: 61-2-888-9404
This book contains a wealth of information and is destined to become
your primary source for UNIX security. Much of the information is
general enough to be applicable elsewhere though. Also has an excellent
bibliography!
The book mentioned above contains references to the COPS security package
for UNIX, including information on how to get it via ftp.
Regards,
Rob Mount, Intergraph Corporation +-----------------------------------+
Domain: rob@panache.b17a.ingr.com | I hate quotations. Tell me what |
UUCP: ...!ingr!b17a!panache!rob | you know. -- Ralph Waldo Emerson |
Voice: (205) 730-1518 FAX: -7296 +-----------------------------------+
/*****************/
From: Bob Dowling <rjd4@cus.cam.ac.uk>
I keep a few useful documents that I've found searching through the net
available for anonymous FTP. Take a look in /pub/security/ on ftp.cus.cam.ac.uk
for the documents I have there.
--------
Bob Dowling: UNIX Support,
University of Cambridge Computing Service,
rjd4@cus.cam.ac.uk New Museums Site, Pembroke Street,
+44 223 334728 Cambridge, UK. CB2 3QG.
/*****************/
From: XARJP@Levels.UniSA.Edu.Au
Here's some suggestions:
look in news.answers for comp.security FAQ
for unix - get "cops" and "crack" and shadow passwd suites from
an archive server (archie.au will point you in the right
direction)
for NIST documents, use anonymous ftp to "csrc.ncsl.nist.gov" and
gat the indices, ls-rl's etc etc
Good luck - be paranoid but happy.
Regards, Rob Potter (Secure Data Systems Pty Ltd (08) 271 6612 if you need help)
The End ....
Newsgroups: comp.security.misc
Subject: [summary] Security Doc Sought Part 1/2
Message-ID: <19595.2b57e646@levels.unisa.edu.au>
Date: 16 Jan 93 10:41:10 +1030
Organization: University of South Australia
Lines: 700
Some time ago I posted a request for information about security related
documentation. Well after much gleaning of ftp sites, I've managed to
get more than enough to read for the next month or so, as well as some
very good pointers to software and a book on the subject.
My apologies if anything in this posting has already been posted, or is
widely known (I'm only new to reading the relevant groups). Similarly my
apologies if any respondee's didnt want their responses posted, but I
did say I'd summarize, and didnt see any notes to the contrary.
Its not that well formatted, but all the responses follow (minus the
people who requested this summary).
A word of warning :-) choose a time when no-one else needs your local
laserprinter .... Theres a lot there, and I managed to fray some tempers ....
Most importantly, many thanks to those who responded. I see no point in
reinventing the wheel, and now after the post I have a number of wheels
to choose from ... thanks again !
Regards .... Rob
Rob Mayfield
Senior Technical Analyst - MIS - Australian Submarine Corporation P/L.
GPO Box 2472, Adelaide S.A. 5001 Ph +61 8 348 7000 Fx +61 8 348 7001
Telex AA186451 Email mayfield@itd.adelaide.edu.au
PS: Ive posted direct followups to those who requested such, sorry if I
missed any.
/*****************/
From: IN%"breinhar@access.digex.com" "Robert B. Reinhardt" 10-JAN-1993 12:33:51.44
Here is something that might be useful to you.
==========================cut here=============================
This is VERSION 3 of my occassional paper on the architecture
of UNIX network security and related methods...
It is not very different from previous versions, but does
contain some additions and corrections at the request of
some of the folks who contribute these tools to the community.
I hope to complete a more complete and polished paper on this
subject in the coming months. My thanks in advance for those
who have contributed changes.
---Bob Reinhardt (breinhar@access.digex.com)
=======================cut here================================
SUMMARY PAPER: An Architectural Overview of UNIX Network Security
(Specifically oriented toward Internet connectivity)
Version 3
By Robert B. Reinhardt, November 11, 1992
(breinhar%srg@uunet.uu.net) - work
(breinhar@access.digex.com) - home
Nothing in this paper should be construed as a product
endorsement. The contents herein are the a result of light
research and some prototype implementation that I've done over the
past nine months. I don't know if this will help you or not. This
is basically just a digest of information that a lot of people
already know. This is for those of you who don't already know.
For each of the FIREWALL layers (sections) below, there is a
subsection that follows that gives a brief description of some of
the most widely used tools and techniques for implementing security
controls and their availability.
=================================================================
| | |
PUBLIC (or) NON-PRIVATE NETWORK ACCESS Y |
| O |
======================================================== U |
| | R Y
SECTION A --------------- | O
| Router | F N U
| | I E R
--------------- R T
| E W P
====================================================== W O O
| A R L
SECTION B --------------- L K I
| Dual-homed | L C
| UNIX Gateway| | A Y
--------------- | N
| | D A
======================================================== N
| E D
SECTION C --------------- Q
| Hosts on | U P
| Local Net | I E
--------------- P R
=========================================================== M S
E O
SECTION D Additional Measures to Enhance Security N N
T N
============================================================= E
L
SECTION E Functional Requirements and Security Policy |
|
================================================================= Before starting into a description of the various elements of
each of the above layers I feel I should reiterate the need for
first developing a local security policy. Each organization or
site needs to have an effective security policy. There are many
tools and techniques available to implement security controls, but
you should first conduct a thorough analysis of what your needs
are, in order to design and implement an efficient operational
environment. You need to determine what your requirements for
network services and features are, what level of security you
require, and what risks you are willing to accept. Sometimes the
benefit outweighs the risk, sometimes not. But, those decisions
differ for each organization. The "firewall" concept for creating
a security demarkation point between your local net and the
outside, as well as the various methods for enhancing security may
not be appropriate for everyone, and in some cases may not go far
enough. But I believe this a good starting point for almost anyone
with a general concern for UNIX network security.
Let me apologize right now to the authors of these tools and
designs. Since I am just giving a brief overview, I cannot do
justice to a complete description of them. To the reader let me
say that you should check the availability section and whenever
possible obtain a README or other information before making your
decisions. In many cases there is at least one paper (in most
cases probably several) that have been published that describe
these things in better detail. I'll try to list at least one
source for each.
Papers describing most if not all of these packages and
techniques can be found in the SYMPOSIUM PROCEEDINGS of the USENIX
Third UNIX Security Symposium (c) 1992 by the USENIX Association.
Some of the functionality of these tools overlap. Since you
have the source to these tools, you can modify them or customize
them to add new features.
SECTION A - Physical Access to your Network
A1. Packet filtering. Several internet protocol routers provide
the capability to filter packets. Packet filtering allows you
to program the router to make a decision whether or not
traffic can pass to or from your network based on several
criteria such as: source ip address, destination ip address,
protocol, tcp or udp port, etc.
Availability: I only have experience with CISCO routers,
however I've been told that Wellfleet and Proteon routers also
have this feature. There may be other vendors as well, but
they probably all implement it a little differently. Read:
Smoot Carl-Mitchell and John S. Quarterman, "Building Internet
Firewalls"; UnixWorld; February, 1992; pp 93-102.
NOTE: This layer of your security firewall also includes other
methods of access between networks such as CALL-BACK
MODEMS.
SECTION B - Logical Access to your Network
B1. TCP_WRAPPER. The "TCP_WRAPPER" tool provides monitoring and
control of network services. Essentially, what happens is
that you configure inetd on your dual-homed gateway to run the
TCP WRAPPER software whenever certain services (ports) are
connected to. Depending on how you configure TCP WRAPPER, it
will then LOG information about the connection and then
actually start the intended SERVER program that the connection
was intended for. Since you have the source to the tool, you
can modify it to do more depending on what your needs are.
For example, you may want TCP WRAPPER to connect the user to
a proxy service instead of the actual program, then have your
proxy software handle the transaction in whatever way your
security requirements demand.
Availability: This is available from several sources, but to
ensure that you get the most recent copy that CERT has
verified, you should use anonymous FTP to retrieve it from
cert.org in ~/pub/tools/tcp_wrappers/tcp_wrappers.*.
B2. SOCKS Library and sockd. The "sockd" and "SOCKS Library"
provide another way to implement a "tcp wrapper." It is not
intended to make the system it runs on secure, but rather to
centralize ("firewall") all external internet services. The
sockd process is started by inetd whenever a connection is
requested for certain services, and then only allows
connections from approved hosts (listed in a configuration
file). The sockd also will LOG information about the
connection. You can use the Socks Library to modify the
client software to directly utilize the sockd for outgoing
connections also, but this is described as very tedious and of
course requires you to have the source to those client
programs.
Availability: The socks package, which in addition to
including both the daemon and the library, has a pre-modified
FTP client and finger client; it is available via anonymous
FTP from s1.gov in ~/pub as socks.tar.Z. Contact the authors
for more information. David Koblas (koblas@netcom.com) or
Michelle R. Koblas (mkoblas@nas.nasa.gov).
B3. Kernel_Wrap for SunOS/RPC via Shared Libraries. Essentially
this is a wrapper for SunOS daemons that use RPC, such as
portmap, ypserv, ypbind, ypupdated, mountd, pwdauthd, etc. To
utilize this, you must have SunOS 4.1 or higher and must have
the capability to rebuild your shared libraries (but, you
don't need the source to your entire system). Essentially
what happens is that you modify the function calls that the
kernel uses to establish RPC connections, such as accept(),
recvfrom() and recvmsg(). Since these calls are maintained in
the shared libraries, you have access to modify them without
rewriting the kernel.
Availability: The secured C library package to implement this
is available via anonymous FTP from eecs.nwu.edu in
~/pub/securelib.
B4. SWATCH. Simple WATCHER is really two things, it is a program
used to parse through the myriad of LOG data generated by the
various security programs, in particular "syslog." But, it's
more than that. It is fully configurable with triggers
(actions), so that while it is continuously monitoring the LOG
in "real-time," it can take actions based upon certain high-
priority events that you tell it to watch for. To get full
use of this, you will need to modify your network service
daemons such as ftpd and telnetd so that enhanced logging is
added to syslog, to feed SWATCH.
Availability: The SWATCH source and documentation is
available via anonymous FTP from sierra.stanford.edu in
~/pub/sources.
B5. Controlled Access Point (CAP). This is more of a method or
protocol definition than a specific product. CAP provides a
network mechanism intended to reduce the risk of: password
guessing, probing for well-known accounts with default
passwords, trusted host rlogin, and password capture by
network snooping. It is really a design for a variation or
enhancement to the general firewall approach to connecting two
or more networks. In the paper describing this there is an
example of two local nets, one a secure segment with an
authentication service, and the other an unsecure segment.
Both communicate with each other via a CAP, while there is a
router for communication to public networks connected on the
unsecure side of the CAP. The CAP is essentially a router
with additional functionality to detect incoming connection
requests, intercept the user authentication process, and
invoke the authentication server.
Availability: Unknown. Contact the authors for more
information. J. David Thompson (thompsond@orvb.saic.com) and
Kate Arndt (karndt@mitre.org).
B6. Mail Gateway. This is more of a procedure than a software
package (although there are packages designed just to do
this). I included this to maintain continuity with what I'm
trying to illustrate in this paper. This really should be
applied to all network services that require external
connectivity (meaning any communication over non-private or
non-secure channels). In the simplest implementation of this,
you configure your router to filter packets so that all mail
traffic (SMTP protocol for example) is only allowed to and
from one host, the "Mail Gateway." Likewise, your DNS and MTA
software will need to be configured for this as well.
B7. TTY_WRAPPER. This is one of my pet ideas. I have not seen
something like this around, and I'll probably never have time
to develop it. But, essentially this would be like "TCP
WRAPPER," only it is designed specifically for serial
communications. After that, we will need a "PSEUDO-TTY
WRAPPER," but that's for another day.
B8. HSC-Gatekeeper. The HSC-Gatekeeper from Herve' Schauer
Consultants, is a complete solution to both layers A and B of
this firewall model. It consists of a thorough firewall
methodology and authentication server, providing pass-thru FTP
and TELNET services. The author (Herve Schauer) noted that
HSC-Gatekeeper was alone to be able to offer fully transparent
authentication for these services. I have not had personal
experience with HSC's products, so I cannot make a conclusive
statement about it other than to comment that the description
of it in HSC's paper "An Internet Gatekeeper" (available in
the USENIX Proceedings) depicts it (IMHO) as a very
comprehensive solution.
Availability: For more information, contact Herve Schauer via
e-mail at Herve.Schauer@hsc-sec.fr.
B9. AT&T INET. Since I discussed HSC's firewall solution, I
thought it only fair to mention AT&T's INET Gateway. For a
complete description of AT&T's internal solution, you should
read Bill Cheswick's paper "The Design of a Secure Internet
Gateway." For additional information, contact the author via
e-mail at ches@research.att.com. I do not believe that AT&T
is in the business of selling this solution to anyone, but the
paper describes in good detail how it was done. It should
provide the puritan firewaller additional depth to the
problems and possible solutions to an Internet firewall
approach.
SECTION C - Physical and Logical Access to Hosts on your Network
C1. Computer Oracle and Password System (COPS). COPS is a UNIX
security status checker. Essentially what it does is check
various files and software configurations to see if they have
been compromised (edited to plant a trojan horse or back
door), and checks to see that files have the appropriate modes
and permissions set to maintain the integrity of your security
level (make sure that your file permissions don't leave
themselves wide open to attack/access).
NOTE: Many vendors of UNIX are now bundling a security
status checker with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them.
Additional Comments: The current version of COPS (1.04) makes
a limited attempt to detect bugs that are posted in CERT
advisories. Also, it has an option to generate a limited
script that can correct various security problems that are
discovered. Dan also offers a quick hint that should easily
get you started using COPS. After you have unarchived the
COPS package, perform the following steps: './reconfig',
'make', and './cops -v -s . -b bit_bucket'. -- There is a lot
of README documentation included if you need more help.
Availability: COPS can be retrieved via anonymous FTP from
cert.org in ~/pub/tools/cops.
C2. Chkacct. Chkacct is a COPS for the ordinary user. This tool
is made available to the users to run, or it is run for them
once per day. It will do an integrity check on the status of
files in their own account and then mail them the results
(such as "Dear user: Your .rhosts file is unsafe"). This
package can help make your users more aware of security
controls and raise their level of participation in the
program.
Availability: Chkacct is distributed with the COPS package
(>= COPS 1.04), for additional information contact
shabby@mentor.cs.purdue.edu.
C3. CRACK. Crack helps the security administrator identify weak
passwords by checking for various weaknesses and attempting to
decrypt them. If Crack can figure out your password, then you
must choose a better password. It is very likely that a
determined intruder will be able to get the password too
(using similar techniques, or the Crack program itself, since
it is publicly available).
Availability: Crack is available via anonymous FTP from
cert.org in ~/pub/tools/crack/crack_4.1-tar.Z.
C4. SHADOW. The shadow password suite of programs replaces the
normal password control mechanisms on your system to remove
the encrypted password from the publicly readable file
/etc/passwd and hides them in a place that only this program
has permission to read. It consists of optional, configurable
components, provides password aging to force users to change
their passwords once in awhile, adds enhanced syslog logging,
and can allow users to set passwords up to a length of sixteen
characters.
NOTE: Many vendors of UNIX are now bundling a shadow
password suite with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them.
Availability: Shadow is available from USENET archives which
store the comp.sources.misc newsgroup. Distribution is
permitted for all non-commercial purposes. For more
information contact the author, John F. Haugh III
(jfh@rpp386.cactus.org).
C5. PASSWD+. Passwd+ is a proactive password checker that
replaces /bin/passwd on your system. It is rule-based and
easily configurable. It prevents users from selecting a weak
password so that programs like "CRACK" can't guess it, and it
provides enhanced syslog logging.
NOTE: Many vendors of UNIX are now bundling a proactive
password checker with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them.
Availability: Passwd+ is available via anonymous FTP from
dartmouth.edu in ~/pub/passwd+tar.Z.
C6. AUDIT. Audit is a policy-driven security checker for a
heterogeneous environment. It is fully configurable so that
you can set up Audit to exactly match your site's security
policy. This program functionally does what COPS is intended
to do, but does not hard-code your policy decisions for you
the way that COPS does.
NOTE: Many vendors of UNIX are now bundling an auditing
subsystem with the OS, usually under the
nomenclature of a "C2" or "trusted system." You
may still find that this package has more features
than your canned package. Compare them. One
particular subject to note is that most (IMHO)
vendors auditing subsystems only collect and
regurgitate tons of raw data, with no guidance and
assistance for using that information. They leave
that up to you. The Audit and/or Swatch tools are
probably better.
Availability: The final version of Audit will eventually be
posted to USENET. However, the beta release will only be made
available on a limited basis, to larger, heterogeneous sites.
If your interested in participating in the beta test, send e-
mail to the auther, Bjorn Satdeva (bjorn@sysadmin.com).
C7. MIRO. Miro is a suite of tools for specifying and checking
security contraints (like COPS and Audit), including a couple
programming languages. It is general because it is not tied
to any particular OS, and it is flexible because security
administrators express site policies via a formal
specification language. It is easy to extend or modify a
policy by simply augmenting or changing the specification of
the current policy.
Availability: Miro is the product of a large research
project, and to understand it you need more than the paragraph
I've written above. For more information about the Miro
project send e-mail to (miro@cs.cmu.edu), there is even a
video available. The authors Ph.D thesis, as well as the
sources for the Miro tools, are available via anonymous FTP
from ftp.cs.cmu.edu. When you connect there, type "cd
/afs/cs/project/miro/ftp" and "get ftp-instructions"; this
will explain how to get the thesis and/or software.
SECTION D - Additional Security Enhancements
The tools described in sections {A...C} above, are what I
consider part of a "base" set of tools and functional requirements
for general security administration. The tools and methods
described in this section are additional measures that can be
combined with or added to your overall security program at any of
the other levels {A...C}.
D1. One-time Password ("Key Card"). Since reusable passwords can
be captured and used/reused by intruders, consider a "one-time
password" scheme. One-time passwords can be implemented using
software-only solutions or software/hardware solutions, and
there are several commercial products available. The
following is an example of what CERT uses. Each user is
assigned a "Digital Pathways" key-card (approximately $60 per
user). When you enter your PIN code, it supplies a password
that is good only one time. The only other piece to this, is
software that replace the login shell on your "firewall"
server.
Availability: The source-code for this shell is based on code
from the key card vendor and is currently not available to the
public domain via anonymous FTP. For additional information
about this, send e-mail to (cert@cert.org).
D2. Privacy Enhanced Mail (PEM). PEM is a RSA-based encryption
scheme that encrypts sensitive information, but more than that
it checks for message integrity and non-repudiation of origin,
so that the originator cannot deny having sent the message.
PEM is actually a protocol that is designed to allow use of
symmetric (private-key) and asymmetric (public-key)
cryptography methods. In this example, Trusted Information
Systems, Inc. (TIS) has implemented a PEM package using the
public-key technique together with the Rand MH Message
Handling System (version 6.7.2). TIS/PEM libraries can be
adapted for implementation of non-mail applications as well.
Availability: TIS/PEM is a commercially available product,
for additional information send e-mail to (pem-info@tis.com).
D3. Kerberos. Kerberos is a DES-based encryption scheme that
encrypts sensitive information, such as passwords, sent via
the network from client software to the server daemon process.
The network services will automatically make requests to the
Kerberos server for permission "tickets." You will need to
have the source to your client/server programs so that you can
use the Kerberos libraries to build new applications. Since
Kerberos tickets are cached locally in /tmp, if there is more
than one user on a given workstation, then a possibility for
a collision exists. Kerberos also relies upon the system time
to operate, therefore it should be enhanced in the future to
include a secure time server (timed is not appropriate).
There are two versions of Kerberos, one for OSF ported by HP,
and one BSD-based developed by the author.
Availability: Kerberos is distributed via anonymous FTP from
athena-dist.mit.edu in ~/pub/kerberos or ~/pub/kerberos5.
D4. Private-Key Certificates. This is not really a product, but
rather a design proposal that is an alternative method to PEM
for adding network security to applications such as mail.
Simply put, it uses the public-key style of implementation
with private-key cryptography. It can be adapted to different
types of applications and it is boilerplate so that you can
essentially plug-in any encryption algorithm. This is
designed so that public-key protocols no longer have to rely
on public-key encryption.
Availability: Unknown. For more information, contact Don
Davis, at Geer Zolot Assoc., Boston, MA (formerly of Project
Athena at MIT). His paper "Network Security via Private-Key
Certificates" better describes this techique.
D5. Multi-Level Security (MLS). After you've done everything else
(above) to make your network secure, then MLS will probably be
one of your next logical steps. That doesn't mean you have to
wait until you've done everything else before implementing
MLS, it's just (IMHO) that you would be wasting your time to
go to the Nth degree before covering the fundamentals. The
other alternative if you are just now deciding to buy your
UNIX operating system is to buy an MLS variant now, and after
you configure it to manage your security policy, go back
through layers {A...C} to see what you might add to make it
more secure in a networked environment. Many UNIX vendors are
now shipping or preparing to ship a MLS version. A couple
examples that immediately come to mind is SecureWare CMW+
(based on A/UX or SCO ODT 1.1) and AT&T USL System V-Release
4-Version 1-Enhanced Security (SVR4.1ES).
For additional information regarding MLS implementations
within the Department of Defense (DoD), contact Charles West
at (703) 696-1891, Multilevel Security Technology Insertion
Program (MLS TIP), Defense Information Systems Agency (DISA).
For additional information regarding SecureWare CMW+, contact
David Luterancik at (404) 315-6296, or send e-mail to
info@sware.com. For additional information regarding AT&T USL
SVR$.1ES, contact Tom Vaden at (908) 522-6154, or send e-mail
to fate@usl.com.
D6. File Encryption. Users should get into the habit of
encrypting sensitive files whenever they are stored in a
public place or transmitted via public communication circuits.
File encryption isn't bulletproof, but it is better than clear
text for sensitive information. The UNIX crypt utility is the
least secure of these tools, since it can be broken using
well-known decryption techniques. The UNIX des utility
(available in US only) is more secure. It has not been known
to be broken, however DoD does not sanction its use for
transmitting classified material. A new UNIX tool PGP 2.0 is
available (uses RSA encryption), however there may be
licensing issues to be concerned with.
D7. Secure Programming Methods. Programmers can assist in the
effort of security by reducing the chance that a potential
intruder can exploit a hole or bug that is coded into locally
developed software. There is probably a lot that can be said
about this, and their are probably many books on the subject
somewhere. But, here are some common recommendations. (A)
Never create a SETUID shell script. There are well-known
techniques used by intruders to gain access to a shell program
that is running as root. (B) List the complete file name,
including the full path in any system() or popen() call. (C)
Since there is no reason for users to have read access to a
SETUID file (or any exectuble for that matter), set
permissions to 4711 (SETUID) or 711 (Non-SETUID).
D8. Counterintelligence. To extend your security program to seek
out, identify, and locate intruders; you may want to modify
some of the security tools (especially those proxy service
daemons and event-driven auditors) to trace intruders back to
their source, and otherwise maintain logs of data on intrusion
attempts. This information can prove vital in taking an
offensive stance against security break-in's and can help
prosecute offenders.
D9. Other Possibilities. Depending on your requirements you might
look into specialized solutions such as Compartmented Mode
Workstations (CMW), end-to-end Data Link Encryption, and
TEMPEST. The NCSC (Rainbow Series) and ITSEC specifications
can help you define what level of need you have for security
and help lead you to additional types of solutions.
SECTION E - Security Policy
Everything discussed in sections {A...D} involve specific
things you can do, tools and techniques to implement, to address a
particular area or "hole" in security. Your SECURITY POLICY is
what ties all of that together into a cohesive and effective
SECURITY PROGRAM. There are many diverse issues to consider when
formulating your policy, which alone is one of the biggest reasons
why you must have one:
-- What are the functional requirements of your network?
-- How secure do you need to be? What needs to be protected?
-- How will you handle incident reporting and prosecution?
-- What does the law require you to do? What about privacy? Since
break-ins often occur via multiple hops on computers throughout the
US and the rest of the world, you will need to consider a variation
of federal, state, local, as well as foreign laws.
-- Make security a dedicated and deliberate effort.
-- User training and security awareness.
-- What is considered acceptable use for users? Do the users
understand what it is they are permitted to do and what it is they
are not permitted to do?
-- What is considered acceptable use for system administration
staff? Is using Crack to test passwords okay? Is giving friends
outside the organization accounts okay?
-- Maintain a working relationship with the Computer Emergency
Response Team (CERT) at Carnegie Mellon University (CMU) and your
Forum of Incident Response and Security Teams (FIRST) regional
representative "CERT" team.
-- PLUS a myriad of different issues too numerous to go into in a
summary paper.
By answering these questions you determine what packages and
methods in sections {A...D} that you want to implement, and in what
ways you want to modify or configure them. "A security policy is
a formal specification of the rules by which people are given
access to a computer and its resources." (and to extend that to
say...a network and its resources). Whatever tools you install to
help you maintain the security of your network and monitor it, they
must be configured to implement YOUR POLICY, or else they are not
doing the whole job that needs to be done. Therefore, you must
first have a POLICY.
For additional help in the area of policy development, contact
cert@cert.org, and they can probably lead you to useful
documentation on the subject and guide you to your FIRST regional
CERT team representative. A good starting point is Request For
Comments (RFC) 1244 "Site Security Handbook" (96 pages), which is
available via anonymous FTP from numerous RFC archive sites (for
example: nic.ddn.mil). SUMMARY OF AVAILABILITY
Section Name Availability
A1 Router Cisco, Wellfleet, Proteon
B1 Tcp_wrapper cert.org:/pub/tools/tcp_wrappers
B2 Socks s1.gov:/pub/socks.tar.Z
B3 Kernel_wrap eecs.nwu.edu:/pub/securelib
B4 Swatch sierra.stanford.edu:/pub/sources
B5 CAP e-mail to thompsond@orvb.saic.com
B6 Mail Gateway NOT APPLICABLE
B7 Tty_wrapper NOT APPLICABLE
B8 HSC-Gatekeeper e-mail to Herve.Schauer@hsc-sec.fr
B9 AT&T INET e-mail to ches@research.att.com
C1 COPS cert.org:/pub/tools/cops
C2 Chkacct cc.perdue.edu:/pub/chkacctv1.1.tar.Z
C3 Crack cert.org:/pub/tools/crack/crack_4.1-tar.Z
C4 Shadow comp.sources.misc (jfh@rpp386.cactus.org).
C5 Passwd+ dartmouth.edu:/pub/passwd+tar.Z
C6 Audit e-mail to bjorn@sysadmin.com
C7 Miro e-mail to miro@cs.cmu.edu
D1 Key-card e-mail to cert@cert.org
D2 TIS/PEM e-mail to pem-info@tis.com
D3 Kerberos athena-dist.mit.edu:/pub/kerberos5
D4 Private-key contact Don Davis, at Geer Zolot Assoc.
D5 MLS contact your UNIX vendor
D6 File encrypt contact your UNIX vendor
D7 Programming NOT APPLICABLE
D8 Counter-Intel NOT APPLICABLE
D9 Other Poss. research and contact various vendors
E* Policy RFC 1244 and cert@cert.org
Additional Sources of Information
Subscribe to the following mailing lists:
cert-advisory-request@cert.org
cert-tools-request@cert.org
firewalls@greatcircle.com
Read the following USENET newsgroups:
comp.security.announce (echos the CERT advisory mailing list)
comp.security.misc
alt.security (frequently dissolves into "flame wars")
comp.risks
comp.virus (almost exclusively for discussing PC and MAC viruses)
Copy files from the CERT Usenet Clipping Archive via anonymous FTP
from cert.org
CERT Contact Information:
Emergencies: +1 412 268-7090
FAX: +1 412 268-6989
E-mail: cert@cert.org
U.S. Mail: CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213-3890, USA
USENIX Papers are available directly from USENIX:
The USENIX Association
2560 Ninth Street, Suite 215
Berkeley, CA 94710, USA
READ: The SYMPOSIUM PROCEEDINGS of the USENIX Third UNIX Security
Symposium (September 14-16, 1992). It is 330+ pages, containing
papers describing in better detail a lot of the packages and
security techniques I briefly described in this paper.
From: xtasc@levels.unisa.edu.au
Newsgroups: comp.security.misc
Subject: [summary] Security Doc Sought Part 2/2
Message-ID: <19596.2b57e72d@levels.unisa.edu.au>
Date: 16 Jan 93 10:45:01 +1030
Organization: University of South Australia
Lines: 629
Part 2 .... contd
------------------------SUMMARY OF CHANGES-------------------------
Version 1 was distributed on September 19, 1992
Version 2 was distributed on October 8, 1992
Version 3 was distributed on November 11, 1992
(V3) Paragraph B2 (Socks) - Changes to e-mail address submitted by
Ed DeHart of CERT. Changes to availability submitted by the
authors, David and Michelle Koblas, the package is available from
s1.gov. (V3) Paragraph B8 (HSC-Gatekeeper) - Added this at the
suggestion of the author, Herve Schauer. (V3) Paragraph B9 (AT&T
INET) - Added this to show a contrast to new paragraph B8. (V2)
Paragraph C1 (COPS) - Additional Comments and Hints submitted by
Dan Farmer, the author of COPS. (V2) Paragraph C2 (Chkacct) -
Correction to availability, the package is distributed with COPS
(versions >= 1.04). (V2) Paragraph D1 (KeyCard) - Correction to
availability, source code is not in public domain, submitted by Jim
Ellis at CERT. (V3) Paragraph D5 (MLS) - Changed to take a more
progressive stance toward MLS in current operating environments.
(V3) Additional information - Added address for the new Firewalls
mailing list.
------------------------NOTICE---DISCLAIMER------------------------
The contents of this paper do not necessarily reflect the opinions
of my employer or anyone else that I know. Nothing in this paper
should be construed as a product endorsement. No warranty is
expressed or implied. Any comments? Please send me e-mail.
-------------------------------------------------------------------
------------------------NOTICE---COPYRIGHT-------------------------
(c) Copyright 1992, Robert B. Reinhardt. This paper is freely
distributable as long as the paper is not modified in any way,
includes this notice, and is provided without guarantee or warranty
expressed or implied. E-mail comments to breinhar@access.digex.com
-------------------------------------------------------------------
/*****************/
From: IN%"pcl@neon.athena.ox.ac.uk" 7-JAN-1993 23:05:04.74
black.ox.ac.uk:/DOCS/security/*
black.ox.ac.uk:/src/security/*
black is 129.67.1.165
Paul
/*****************/
From: IN%"Marten.Sahlen@eua.ericsson.se" 7-JAN-1993 18:42:41.95
Hi!
I know of a few places that might be of interest. The best source to start
with is probably the NIST Computer Security FTP Archive at csrc.ncsl.nist.gov.
It contains a wide variety of articles, info, software etc. in the security
field.
Another place is ariel.unm.edu in the /ethics directory, which contain a lot
of examples on how security policies can be designed.
Thirdly, for network security and particulary the Kerberos system, try
aeneas.mit.edu under pub/Kerberos/doc.
I would be very interested in a summary of all the sources you get pointers
to.
Regards...
--
>>>>-----------------Marten Sahlen etxsahm@eua.ericsson.se-----------------<<<<
>>>-----Ellemtel Telecom Systems Lab, Box 1505, S-125 25 Alvsjo, Sweden------<<<
/*****************/
From: IN%"SPG@NEREID.SUNQUEST.COM" 7-JAN-1993 16:36:19.73
Rob,
I would really _really_ appreciate a summary/follow-up on anything that you
find.
In regards to PD VMS security stuff, you might try anonymous ftp to
spcvxa.spc.edu in the [.Madison] and [.Macro32] directories
and
ACF1.NYU.EDU in various places.
--
Steve (SPG6) spg@sunquest.com
/*****************/
From: IN%"spaf@cs.purdue.edu" 7-JAN-1993 15:42:37.46
To: IN%"xtasc@levels.unisa.edu.au"
CC:
Subj: RE: Security related Documentation sought.
I don't know if I responded to you already or not. If I did, my
apologies.
You might try taking a look at my book (for Unix and for networks,
passwords, etc). Canned blurb follows.
Cheers,
--spaf
"Practical Unix Security"
by Simson Garfinkel and Eugene Spafford
O'Reilly & Associates (the Nutshell Handbook people).
500 pages, 1991, $29.95.
ISBN 0-937175-72-2
Quotes from reviewers:
Cliff Stoll:
Worried about who's in your Unix system?
Losing sleep because someone might be messing with your computer?
Having headaches from obscure computer manuals?
Then _Practical_Unix_Security_ is for you.
This handy book tells you where the holes are and how to cork 'em up.
Moreover, you'll learn about how Unix security really works.
Spafford and Garfinkel show you how to tighten up your Unix system
without pain. No secrets here -- just solid computing advice.
Buy this book and save on aspirin.
Tom Christiansen, Convex Computer Corp:
This book is the first I've seen that actually seemed to
address the many security issues that I keep around on
my own little list, and it did so well.
Paul Clark, Trusted Information Systems:
The book could easily become a standard desktop reference for
anyone involved in system administration. In general, its
comprehensive treatment of Unix security issues
will enlighten anyone with an interest in the topic.
Matt Bishop, Dartmouth
...I liked the book; it covers a lot of material not
normally covered and provides practical instructions on how to do
things. This will be very useful for practitioners...This book is
far superior to any other I have seen on UNIX security.
Laurie Sefton, Apple:
Finally there is a UNIX security book that covers the BSD world as
well as the SYS V version...The other aspect of UNIX security books
that has been sorely lacking was the "rest of UNIX" security. All the
other books had a very thin overview of "down and dirty" security, as
if they were afraid of giving out too much information...As soon as
this is out, I'm ordering copies for all my people, and extra copies
for the library at Apple.
Orders: 800-998-9938 (US & Canada)
707-829-0515 (Europe)
nuts@ora.com (e-mail)
Table of Contents:
Preface
Scope of this Book
Which UNIX System?
Conventions Used in this Book
Acknowledgments
Three Final Notes
Chapter 1 Introduction
What's Computer Security?
What's an Operating System?
History of UNIX
Security and UNIX
Security and Networks
Types of Security
Risk Assessment
Assessing Your Risk
Reacting to an Emergency
Other Important Steps
The Problem with Security Through Obscurity
The First Step
Chapter 2 Users and Passwords
Usernames
The /etc/passwd File
The /etc/passwd File and Network Databases
Passwords
Why Use Passwords?
Entering Your Password
Changing Your Password
Checking Out Your New Password
UNIX'S Encrypted Password System
The crypt() Algorithm
What is Salt?
The Care and Feeding of Passwords
Bad Passwords: Open Doors
Good Passwords: Locked Doors
Passwords on Multiple Machines
Writing Down Passwords
Administrative Techniques
Assigning Passwords to Users
Password Generators
Shadow Password Files
Password Aging and Expiration
Algorithm Changes
Preventing Direct Logins to Accounts
Account Names Revisited
Summary
Chapter 3 Users, Groups, and the Superuser
Users and Groups
User Identifiers (UIDs)
Groups and Group Identifiers (GIDs)
Special Users
The Superuser
Other Special Users
Impact of the /etc/passwd and /etc/group Files on Security
The su(1) Command: Changing Who You Are
Becoming the Superuser
Restricting su
The Bad su Log
Other Uses of su
Summary
Chapter 4 The UNIX File System
Files
Using the ls(1) command
Understanding File Permissions
File Permissions in Detail
Using File Permissions
chmod: Changing a File's Permissions
Setting a File's Permissions
Calculating Octal File Permissions
Using Octal File Permissions
The umask
The umask command
Common umask Values
Using Directory Permissions
SUID
SUID, SGID, and Sticky Bits
Problems With SUID
Finding All of the SUID and SGID Files
Turning off SUID and SGID in Mounted File Systems
SGID and Sticky Bits on Directories
(Berkeley UNIX and Sun OS Only)
SGID Bit on Files (System V UNIX only)
chown: Changing a File's Owner
chgrp: Changing a File's Group
Chapter 5 Defending Your Accounts
Dangerous Accounts
Accounts Without Passwords
Default Accounts
Accounts That Run a Single Command
Open Accounts
Group Accounts
Dormant Accounts
Changing an Account's Password
Changing the Account's Login Shell
Finding Dormant Accounts
Protecting the Root Account Under Berkeley UNIX
Secure Terminals
The wheel Group
Chapter 6 Securing Your Data
File Backups
Why Make Backups?
What Should You Back up?
Kinds of Backups
How Long Should You Keep a Backup?
Security for Backups
Database Backups and Daily Checking
Integrity Checking and Checklists
Checklists
File Protection Modes
Read-Only Disks
Comparison Copies
Checklists
Signatures
Chapter 7 The UNIX Log Files
The /usr/adm/lastlog File
The /etc/utmp and /usr/adm/wtmp Files
Last Program
Pruning the wtmp File
The /usr/adm/acct File
The Berkeley System Log (syslog) Facility
The syslog.conf Configuration File
Where To Log
Chapter 8 Protecting Against Programmed Threats
Programmed Threats: Definitions
Back Doors and Trap Doors
Logic Bombs
Viruses
Worms
Trojan Horses
Bacteria and Rabbits
Damage
Authors
Entry
Protecting Yourself
Shell Features
Startup File Attacks
Abusing Automatic Mechanisms
Unexpected Interactions
Protecting Your System
File Protections
SUID and SGID Programs
Notes on Writing a SUID Program
SUID Shell Scripts
Chapter 9 Modems
Theory of Operation
Serial Interfaces
The RS-232 Serial Protocol
Originate and Answer
Modems and Security
Modems and UNIX
Hooking Up a Modem to Your Computer
Setting Up the UNIX Device
Checking Your Modem
Physical Protection
Additional Security for Modems
Chapter 10 UUCP
About UUCP
The uucp Command
The uux Command
The mail Command
How The uucp Commands Work
Versions of UUCP
UUCP and Security
Assigning Additional UUCP Logins
Establishing UUCP Passwords
Security of the L.sys and Systems Files
Security in Version 2 UUCP
USERFILE: Providing Remote File Access
A USERFILE Example
L.cmds: Providing Remote Command Execution
Security in BNU UUCP
The Permissions File
Permissions Commands
uucheck(1): Checking Your Permissions File
Additional Security Concerns
Mail Forwarding for UUCP
Automatic Execution of Cleanup Scripts
Early Security Problems with UUCP
Summary
Chapter 11 Networks and Security
The Internet
Internet Addresses
The /etc/hosts File
Network Hostname Service
Clients and Servers
TCP/IP
UDP/IP
UNIX Network Servers
The /etc/services File
Starting the Servers
The /etc/inetd Program
Network Services
TELNET
rlogin and rsh
rexec
finger
Electronic Mail
FTP
TFTP
The X Window System
Security Implications of Network Services
Monitoring Your Network with netstat
Summary
Chapter 12 Sun's NFS
NIS
Netgroups
Setting up Netgroups
NFS
How NFS Works
The /etc/exports File
The showmount Command
Authentication and NFS
Improving Basic NFS Security
Limiting Exported File Systems
Limit Exported Machines
Use Root Ownership
Export Read-only
Do Not Export Server Executables
The fsirand Program
Summary: Security Implications of NFS
Chapter 13 Kerberos and Secure RPC
The Problem
What's Wrong with LANs?
Minimizing the Problems
MIT's Kerberos
What's It Like to Use Kerberos?
How to Install Kerberos
What's Wrong with Kerberos?
Sun Microsystems' Secure RPC
How Secure RPC Works
What's It Like to Use Secure NFS?
How to Install Secure RPC
What's Wrong with Secure RPC?
Chapter 14 Firewall Machines
What's a Firewall?
Internal Firewalls
External Firewalls
Setting Up a Firewall
The Choke
Choosing the Choke's Protocols
Setting up the Gate
Name Service
Electronic Mail
Netnews
FTP
Other Services
An Alternate Method
Special Considerations
Chapter 15 Discovering a Break-in
Prelude
Discovering an Intruder
Catching One in the Act
What to Do When You Catch Somebody
Tracing a Connection
Getting Rid of the Intruder
The Log Files: Discovering an Intruder's Tracks
Cleaning Up After the Intruder
New Accounts
An Example
A Last Note: Never Trust Anything Except Hard Copy
Chapter 16 Denial of Service Attacks and Solutions
Destruction Attacks
Overload Attacks
Process Overload Attacks
Disk Attacks
Swap Space Attacks
Soft Process Limits: Preventing Accidental
Denial of Service
Network Denial of Service Attacks
Service Overloading
Message Flooding
Signal Grounding
Chapter 17 Computer Security and the U.S. Law
Legal Options After a Break-in
Criminal Prosecution
The Local Option
Federal Jurisdiction
Federal Computer Crime Laws
Hazards of Criminal Prosecution
If You or One of Your Employees is a
Target of an Investigation
Other Tips
Civil Actions
Privacy and The Electronic Communications Privacy Act
Chapter 18 Encryption
Who Needs Encryption?
Cryptographic Strength
Types of Encryption Systems
ROT13
crypt
Enigma
UNIX crypt
Ways of Improving the Security of crypt
Example
The Data Encryption Standard (DES)
DES Modes
Use and Export of DES
DES Strength
Sun's des command
RSA and Public Key Cryptography
How RSA Works
An RSA Example
Strength of RSA
Proprietary Encryption Systems
Protect Your Key!
Chapter 19 Physical Security
Protecting Computer Hardware
The Environment
Accidents
Physical Access
Vandalism
Acts of War and Terrorism
Theft
Related Concerns
Protecting Data
Eavesdropping
Backups
Local Storage
Unattended Terminals
Appendix A UNIX Security Checklist
Appendix B Important Files
System Files
Important Files in your Home Directory
SUID Files in Berkeley UNIX
SGID Files in Berkeley UNIX
SUID Files in System V R3.2 UNIX
SGID Files in System V UNIX
Appendix C UNIX Processes
Processes
Processes and Programs
The ps Command
Process Properties
Creating Processes
Signals
The kill Command
Starting Up UNIX and Logging In
Process #1: /etc/init
Letting Users Log In
Running the User's Shell
Appendix D How Kerberos Works
Kerberos's Parts
Using Kerberos
Using a Service
Appendix E Other Sources
References
General Computer Security
UNIX Security
Computer Viruses and Programmed Threats
Computer Crime and Law
Understanding the Computer Security 'Culture'
Understanding and Using Networks
Using and Programming UNIX
Security Products and Services Information
Miscellaneous References
Organizations
Association for Computing Machinery (ACM)
IEEE Computer Society
ASIS
Computer Security Institute (CSI)
NIST
Computer Emergency Response Team (CERT)
DOE's Computer Incident Advisory Capability (CIAC)
Software Resources
Getting Kerberos
Getting COPS
/*****************/
From: rob@panache.b17a.ingr.com (Rob Mount)
Try the book:
Practical UNIX Security
Simson Garfinkel and Gene Spafford
O'Reilly & Associates, Inc. 1991
which is available from:
Addison-Wesley Publishers, Pty. Ltd.
6 Byfield Street
North Ryde, N.S.W. 2113
Australia
Voice: 61-2-888-2733 Fax: 61-2-888-9404
This book contains a wealth of information and is destined to become
your primary source for UNIX security. Much of the information is
general enough to be applicable elsewhere though. Also has an excellent
bibliography!
The book mentioned above contains references to the COPS security package
for UNIX, including information on how to get it via ftp.
Regards,
Rob Mount, Intergraph Corporation +-----------------------------------+
Domain: rob@panache.b17a.ingr.com | I hate quotations. Tell me what |
UUCP: ...!ingr!b17a!panache!rob | you know. -- Ralph Waldo Emerson |
Voice: (205) 730-1518 FAX: -7296 +-----------------------------------+
/*****************/
From: Bob Dowling <rjd4@cus.cam.ac.uk>
I keep a few useful documents that I've found searching through the net
available for anonymous FTP. Take a look in /pub/security/ on ftp.cus.cam.ac.uk
for the documents I have there.
--------
Bob Dowling: UNIX Support,
University of Cambridge Computing Service,
rjd4@cus.cam.ac.uk New Museums Site, Pembroke Street,
+44 223 334728 Cambridge, UK. CB2 3QG.
/*****************/
From: XARJP@Levels.UniSA.Edu.Au
Here's some suggestions:
look in news.answers for comp.security FAQ
for unix - get "cops" and "crack" and shadow passwd suites from
an archive server (archie.au will point you in the right
direction)
for NIST documents, use anonymous ftp to "csrc.ncsl.nist.gov" and
gat the indices, ls-rl's etc etc
Good luck - be paranoid but happy.
Regards, Rob Potter (Secure Data Systems Pty Ltd (08) 271 6612 if you need help)
The End ....
Comments
Post a Comment