UnixFirewall\tcp_wrappers_7.6\miscd.c (3139, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\tcpd.c (3369, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\fromhost.c (1407, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\hosts_access.c (9636, 1997-02-12)
UnixFirewall\tcp_wrappers_7.6\shell_cmd.c (2121, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\tcpd.h (7874, 1996-03-19)
UnixFirewall\tcp_wrappers_7.6\tcpdmatch.c (9246, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\Makefile (32464, 1997-03-22)
UnixFirewall\tcp_wrappers_7.6\hosts_access.5 (15225, 1995-01-31)
UnixFirewall\tcp_wrappers_7.6\strcasecmp.c (3867, 1993-09-12)
UnixFirewall\tcp_wrappers_7.6\BLURB (1736, 1997-03-22)
UnixFirewall\tcp_wrappers_7.6\rfc931.c (4454, 1995-01-02)
UnixFirewall\tcp_wrappers_7.6\tcpd.8 (7022, 1996-02-21)
UnixFirewall\tcp_wrappers_7.6\eval.c (3673, 1995-01-31)
UnixFirewall\tcp_wrappers_7.6\hosts_access.3 (3602, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\hosts_ctl.c (1103, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\percent_x.c (2402, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\options.c (15497, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\clean_exit.c (1080, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\environ.c (4865, 1994-03-23)
UnixFirewall\tcp_wrappers_7.6\patchlevel.h (88, 1997-03-22)
UnixFirewall\tcp_wrappers_7.6\fix_options.c (3376, 1997-04-08)
UnixFirewall\tcp_wrappers_7.6\workarounds.c (7467, 1996-03-19)
UnixFirewall\tcp_wrappers_7.6\socket.c (6858, 1997-03-22)
UnixFirewall\tcp_wrappers_7.6\tli.c (9668, 1997-03-22)
UnixFirewall\tcp_wrappers_7.6\DISCLAIMER (792, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\fakelog.c (992, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\safe_finger.c (5102, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\hosts_options.5 (6655, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\CHANGES (19195, 1997-03-22)
UnixFirewall\tcp_wrappers_7.6\try-from.c (2058, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\update.c (2914, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\ptx.c (2710, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\vfprintf.c (3198, 1994-03-24)
UnixFirewall\tcp_wrappers_7.6\tli-sequent.c (4971, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\tli-sequent.h (411, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\misc.c (1613, 1996-02-12)
UnixFirewall\tcp_wrappers_7.6\diag.c (1466, 1994-12-29)
UnixFirewall\tcp_wrappers_7.6\ncr.c (2579, 1994-12-29)
... ...
@(#) README 1.30 97/03/21 19:27:21
This is the 7.6 version of the TCP/IP daemon wrapper package.
Thank you for using this program. If you like it, send me a postcard.
My postal address is at the bottom of this file.
Read the BLURB file for a brief summary of what is new. The CHANGES
file gives a complete account of differences with respect to previous
releases.
Announcements of new releases of this software are posted to Usenet
(comp.security.unix, comp.unix.admin), to the cert-tools mailing list,
and to a dedicated mailing list. You can subscribe to the dedicated
mailing list by sending an email message to majordomo@wzv.win.tue.nl
with in the body (not subject): subscribe tcp-wrappers-announce.
Table of contents
-----------------
1 - Introduction
2 - Disclaimer
3 - Tutorials
3.1 - How it works
3.2 - Where the logging information goes
4 - Features
4.1 - Access control
4.2 - Host name spoofing
4.3 - Host address spoofing
4.4 - Client username lookups
4.5 - Language extensions
4.6 - Multiple ftp/gopher/www archives on one host
4.7 - Banner messages
4.8 - Sequence number guessing
5 - Other works
5.1 - Related documents
5.2 - Related software
6 - Limitations
6.1 - Known wrapper limitations
6.2 - Known system software bugs
7 - Configuration and installation
7.1 - Easy configuration and installation
7.2 - Advanced configuration and installation
7.3 - Daemons with arbitrary path names
7.4 - Building and testing the access control rules
7.5 - Other applications
8 - Acknowledgements
1 - Introduction
----------------
With this package you can monitor and filter incoming requests for the
SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other
network services.
It supports both 4.3BSD-style sockets and System V.4-style TLI. Praise
yourself lucky if you don't know what that means.
The package provides tiny daemon wrapper programs that can be installed
without any changes to existing software or to existing configuration
files. The wrappers report the name of the client host and of the
requested service; the wrappers do not exchange information with the
client or server applications, and impose no overhead on the actual
conversation between the client and server applications.
Optional features are: access control to restrict what systems can
connect to what network daemons; client user name lookups with the RFC
931 etc. protocol; additional protection against hosts that pretend to
have someone elses host name; additional protection against hosts that
pretend to have someone elses host address.
The programs are very portable. Build procedures are provided for many
common (and not so common) environments, and guidelines are provided in
case your environment is not among them.
Requirements are that network daemons are spawned by a super server
such as the inetd; a 4.3BSD-style socket programming interface and/or
System V.4-style TLI programming interface; and the availability of a
syslog(3) library and of a syslogd(8) daemon. The wrappers should run
without modification on any system that satisfies these requirements.
Workarounds have been implemented for several common bugs in systems
software.
What to do if this is your first encounter with the wrapper programs:
1) read the tutorial sections for an introduction to the relevant
concepts and terminology; 2) glance over the security feature sections
in this document; 3) follow the installation instructions (easy or
advanced). I recommend that you first use the default security feature
settings. Run the wrappers for a few days to become familiar with
their logs, before doing anything drastic such as cutting off access or
installing booby traps.
2 - Disclaimer
--------------
The wrapper programs rely on source address information obtained from
network packets. This information is provided by the client host. It is
not 100 percent reliable, although the wrappers do their best to expose
forgeries.
In the absence of cryptographic protection of message contents, and of
cryptographic authentication of message originators, all data from the
network should be treated with sound scepticism.
THIS RESTRICTION IS BY NO MEANS SPECIFIC TO THE TCP/IP PROTOCOLS.
3 - Tutorials
-------------
The tutorial sections give a gentle introduction to the operation of
the wrapper programs, and introduce some of the terminology that is
used in the remainder of the document: client, server, the inetd and
syslogd daemons, and their configuration files.
3.1 - How it works
------------------
Almost every application of the TCP/IP protocols is based on a client-
server model. For example, when a user invokes the telnet command to
connect to one of your systems, a telnet server process is executed on
the target host. The telnet server process connects the user to a login
process. A few examples of client and server programs are shown in the
table below:
client server application
--------------------------------
telnet telnetd remote login
ftp ftpd file transfer
finger fingerd show users
The usual approach is to run one single daemon process that waits for
all kinds of incoming network connections. Whenever a connection is
established, this daemon (usually called inetd) runs the appropriate
server program and goes back to sleep, waiting for other connections.
The wrapper programs rely on a simple, but powerful mechanism. Instead
of directly running the desired server program, the inetd is tricked
into running a small wrapper program. The wrapper logs the client host
name or address and performs some additional checks. When all is well,
the wrapper executes the desired server program and goes away.
The wrapper programs have no interaction with the client user (or with
the client process). Nor do the wrappers interact with the server
application. This has two major advantages: 1) the wrappers are
application-independent, so that the same program can protect many
kinds of network services; 2) no interaction also means that the
wrappers are invisible from outside (at least for authorized users).
Another important property is that the wrapper programs are active only
when the initial contact between client and server is established. Once
a wrapper has done its work there is no overhead on the client-server
conversation.
The simple mechanism has one major drawback: the wrappers go away after
the initial contact between client and server processes, so the
wrappers are of little use with network daemons that service more than
one client. The wrappers would only see the first client attempt to
contact such a server. The NFS mount daemon is a typical example of a
daemon that services requests from multiple clients. See the section on
related software for ways to deal with such server programs.
There are two ways to use the wrapper programs:
1) The easy way: move network daemons to some other directory and fill
the resulting holes with copies of the wrapper programs. This
approach involves no changes to system configuration files, so there
is very little risk of breaking things.
2) The advanced way: leave the network daemons alone and modify the
inetd configuration file. For example, an entry such as:
tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot
When a tftp request arrives, inetd will run the wrapper program
(tcpd) with a process name `in.tftpd'. This is the name that the
wrapper will use when logging the request and when scanning the
optional access control tables. `in.tftpd' is also the name of the
server program that the wrapper will attempt to run when all is
well. Any arguments (`-s /tftpboot' in this particular example) are
transparently passed on to the server program.
For an account of the history of the wrapper programs, with real-life
examples, see the section below on related documents.
3.2 - Where the logging information goes
----------------------------------------
The wrapper programs send their logging information to the syslog
daemon (syslogd). The disposition of the wrapper logs is determined by
the syslog configuration file (usually /etc/syslog.conf). Messages are
written to files, to the console, or are forwarded to a @loghost. Some
syslogd versions can even forward messages down a |pipeline.
Older syslog implementations (still found on Ultrix systems) only
support priority levels ranging from 9 (debug-level messages) to 0
(alerts). All logging information of the specified priority level or
more urgent is written to the same destination. In the syslog.conf
file, priority levels are specified in numerical form. For example,
8/usr/spool/mqueue/syslog
causes all messages with priority 8 (informational messages), and
anything that is more urgent, to be appended to the file
/usr/spool/mqueue/syslog.
Newer syslog implementations support message classes in addition to
priority levels. Examples of message classes are: mail, daemon, auth
and news. In the syslog.conf file, priority levels are specified with
symbolic names: debug, info, notice, ..., emerg. For example,
mail.debug /var/log/syslog
causes all messages of class mail with priority debug (or more urgent)
to be appended to the /var/log/syslog file.
By default, the wrapper logs go to the same place as the transaction
logs of the sendmail daemon. The disposition can be changed by editing
the Makefile and/or the syslog.conf file. Send a `kill -HUP' to the
syslogd after changing its configuration file. Remember that syslogd,
just like sendmail, insists on one or more TABs between the left-hand
side and the right-hand side expressions in its configuration file.
Solaris 2.x note: the syslog daemon depends on the m4 macro processor.
The m4 program is installed as part of the software developer packages.
Trouble shooting note: when the syslogging does not work as expected,
run the program by hand (`syslogd -d') and see what really happens.
4 - Features
------------
4.1 - Access control
--------------------
When compiled with -DHOSTS_ACCESS, the wrapper programs support a
simple form of access control. Access can be controlled per host, per
service, or combinations thereof. The software provides hooks for the
execution of shell commands when an access control rule fires; this
feature may be used to install "booby traps". For details, see the
hosts_access.5 manual page, which is in `nroff -man' format. A later
section describes how you can test your access control rules.
Access control can also be used to connect clients to the "right"
service. What is right may depend on the requested service, the origin
of the request, and what host address the client connects to. Examples:
(1) A gopher or www database speaks native language when contacted from
within the country, otherwise it speaks English.
(2) A service provider offers different ftp, gopher or www services
with different internet hostnames from one host (section 4.6).
Access control is enabled by default. It can be turned off by editing
the Makefile, or by providing no access control tables. The install
instructions below describe the Makefile editing process.
The hosts_options.5 manual page (`nroff -man' format) documents an
extended version of the access control language. The extensions are
disabled by default. See the section below on language extensions.
Later System V implementations provide the Transport Level Interface
(TLI), a network programming interface that performs functions similar
to the Berkeley socket programming interface. Like Berkeley sockets,
TLI was designed to cover multiple protocols, not just Internet.
When the wrapper discovers that the TLI interface sits on top of a
TCP/IP or UDP/IP conversation it uses this knowledge to provide the
same functions as with traditional socket-based applications. When
some other protocol is used underneath TLI, the host address will be
some universal magic cookie that may not even be usable for access
control purposes.
4.2 - Host name spoofing
------------------------
With some network applications, such as RSH or RLOGIN, the client host
name plays an important role in the authentication process. Host name
information can be reliable when lookups are done from a _local_ hosts
table, provided that the client IP address can be trusted.
With _distributed_ name services, authentication schemes that rely on
host names become more problematic. The security of your system now may
depend on some far-away DNS (domain name server) outside your own
control.
The wrapper programs verify the client host name that is returned by
the address->name DNS server, by asking for a second opinion. To this
end, the programs look at the name and addresses that are returned by
the name->address DNS server, which may be an entirely different host.
If any name or address discrepancies are found, or if the second DNS
opinion is not available, the wrappers assume that one of the two name
servers is lying, and assume that the client host pretends to have
someone elses host name.
When compiled with -DPARANOID, the wrappers will always attempt to look
up and double check the client host name, and will always refuse
service in case of a host name/address discrepancy. This is a
reasonable policy for most systems.
When compiled without -DPARANOID, the wrappers by default still perform
hostname lookup. You can match hosts with a name/address discrepancy
with the PARANOID wildcard and decide whether or not to grant service.
Automatic hostname verification is enabled by default. Automatic
hostname lookups and verification can be turned off by editing the
Makefile. The configuration and installation section below describes
the Makefile editing process.
4.3 - Host address spoofing
---------------------------
While host name spoofing can be found out by asking a second opinion,
it is much harder to find out that a host claims to have someone elses
network address. And since host names are deduced from network
addresses, address spoofing is at least as effective as name spoofing.
The wrapper programs can give additional protection against hosts that
claim to have an address that lies outside their own network. For
example, some far-away host that claims to be a trusted host within
your own network. Such things are possible even while the impersonated
system is up and running.
This additional protection is not an invention of my own; it has been
present for at least five years in the BSD rsh and rlogin daemons.
Unfortunately, that feature was added *after* 4.3 BSD came out, so that
very few, if any, UNIX vendors have adopted it. Our site, and many
other ones, has been running these enhanced daemons for several years,
and without any ill effects.
When the wrapper programs are compiled with -DKILL_IP_OPTIONS, the
programs refuse to service TCP connections with IP source routing
options. -DKILL_IP_OPTIONS is not needed on modern UNIX systems
that can stop source-routed traffic in the kernel. Examples are
4.4BSD derivatives, Solaris 2.x, and Linux. See your system manuals
for details.
If you are going to use this feature on SunOS 4.1.x you should apply
patch 100804-03+ or 101790-something depending on your SunOS version.
Otherwise you may experience "BAD TRAP" and "Data fault" panics when
the getsockopt() system call is executed after a TCP RESET has been
received. This is a kernel bug, it is not the fault of the wrappers.
The feature is disabled by default. It can be turned on by editing the
Makefile. The configuration and installation section below describes
the Makefile editing process.
UDP services do not benefit from this additional protection. With UDP,
all you can be certain of is the network packet's destination address.
4.4 - Client username lookups
-----------------------------
The protocol proposed in RFC 931 provides a means to obtain the client
user name from the client host. The requirement is that the client
host runs an RFC 931-compliant daemon. The information provided by such
a daemon is not intended to be used for authentication purposes, but it
can provide additional information about the owner of a TCP connection.
The RFC 931 protocol has diverged into different directions (IDENT,
TAP, RFC 1413). To add to the confusion, they all use the same network
port. The daemon wrappers implement a common subset of the protocols.
There are some limitations: the number of hosts that run an RFC 931 (or
compatible) daemon is limited (but growing); client user name lookups
do not work for datagram (UDP) services. More seriously, client user
name lookups can cause noticeable delays with connections from non-UNIX
PCs. Recent PC software seem to have fixed this (for example NCSA
telnet). The wrappers use a 10-second timeout for RFC931 lookups, to
accommodate slow networks and slow hosts.
By default, the wrappers will do username lookup only when the access
control rules require them to do so (via user@host client patterns, see
the hosts_access.5 manual page) or when the username is needed for
%
expansions.
You can configure the wrappers to always perform client username
lookups, by editing the Makefile. The client username lookup timeout
period (10 seconds default) can be changed by editing the Makefile. The
installation sections below describe the Makefile editing process.
On System V with TLI-based network services, client username lookups
will be possible only when the underlying network protocol is TCP/IP.
4.5 - Language extensions
-------------------------
The wrappers sport only a limited number of features. This is for a
good reason: programs that run at high privilege levels must be easy to
verify. And the smaller a program, the easier to verify. There is,
however, a provision to add features.
The options.c module provides a framework for language extensions.
Quite a few extensions have already been implemented; they are
documented in the hosts_options.5 document, which is in `nroff -man'
format. Examples: changing the severity level at which a request for
service is logged; "allow" and "deny" keywords; running a customized
server instead of the standard one; many others.
The language extensions are not enabled by default because they
introduce an incompatible change to the access control language
syntax. Instructions to enable the extensions are given in the
Makefile.
4.6 - Multiple ftp/gopher/www archives on one host
--------------------------------------------------
Imagine one host with multiple internet addresses. These addresses do
not need to have the same internet hostname. Thus, it is possible to
offer services with different internet hostnames from just one host.
Service providers can use this to offer organizations a presence on the
"net" with their own internet hostname, even when those organizations
aren't connected to the Internet at all. To the end user it makes no
difference, because applications use internet hostnames.
There are several ways to assign multiple addresses to one machine.
The nice way is to take an existing network interface and to assign
additional internet addresses with the `ifconfig' command. Examples:
Solaris 2: ifconfig le0:1
近期下载者：
相关文件：
收藏者：