readme

基于TCP-WRAP原理的系统监控的c语言实现代码

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
%<letter> 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 <address> netmask <mask> up
    4.4 BSD:	ifconfig en0 alias <address> netmask <mask>

On other systems one has to increase the number of network interfaces:
either with hardware interfaces, or with pseudo interfaces like SLIP or
PPP.  The interfaces do not need to be attached to anything. They just
need to be up and to be assigned a suitable internet address and mask.

With the wrapper software, `daemon@host' access control patterns can be
used to distinguish requests by the network address that they are aimed
at.  Judicious use of the `twist' option (see the hosts_options.5 file,
`nroff -man' format) can guide the requests to the right server.  These
can be servers that live in separate chroot areas, or servers modified
to take additional context from the command line, or a combination.

Another way is to modify gopher or www listeners so that they bind to
only one specific network address. Multiple gopher or www servers can
then be run side by side, each taking requests sent to its respective
network address.

4.7 - Banner messages
---------------------

Some sites are required to present an informational message to users
before they attempt to login.  Banner messages can also be useful when
denying service:  instead of simply dropping the connection a polite
explanation is given first. Finally, banners can be used to give your
system a more personal touch.

The wrapper software provides easy-to-use tools to generate pre-login
banners for ftp, telnet, rlogin etc. from a single prototype banner
textfile.  Details on banners and on-the-fly %<letter> expansions are
given in the hosts_options.5 manual page (`nroff -man' format). An
example is given in the file Banners.Makefile.

In order to support banner messages the wrappers have to be built with
language extensions enabled. See the section on language extensions.

4.8 - Sequence number guessing
------------------------------

Recently, systems came under attack from intruders that exploited a
well-known weakness in TCP/IP sequence number generators.  This
weakness allows intruders to impersonate trusted hosts. Break-ins have
been reported via the rsh service. In fact, any network service can be
exploited that trusts the client host name or address.

A long-term solution is to stop using network services that trust the
client host name or address, and to use data encryption instead.

A short-term solution, as outlined in in CERT advisory CA-95:01, is to
configure network routers so that they discard datagrams from "outside"
with an "inside" source address. This approach is most fruitful when
you do not trust any hosts outside your local network.

The IDENT (RFC931 etc.) client username lookup protocol can help to
detect host impersonation attacks.  Before accepting a client request,
the wrappers can query the client's IDENT server and find out that the
client never sent that request.

When the client host provides IDENT service, a negative IDENT lookup
result (the client matches `UNKNOWN@host') is strong evidence of a host
impersonation attack.

A positive IDENT lookup result (the client matches `KNOWN@host') is
less trustworthy.  It is possible for an attacker to spoof both the
client request and the IDENT lookup connection, although doing so
should be much harder than spoofing just a client request. Another
possibility is that the client's IDENT server is lying.

Client username lookups are described in more detail in a previous
section. Pointers to IDENT daemon software are described in the section
on related software.

5 - Other works
---------------

5.1 - Related documents
-----------------------

The war story behind the tcp wrapper tools is described in:

    W.Z. Venema, "TCP WRAPPER, network monitoring, access control and
    booby traps", UNIX Security Symposium III Proceedings (Baltimore),
    September 1992. 

    ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript)
    ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text)

The same cracker is also described in:

    W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is
    Lured, Endured, and Studied", Proceedings of the Winter USENIX
    Conference (San Francisco), January 1992.

    research.att.com:/dist/internet_security/berferd.ps

An updated version of the latter paper appeared in:

    W.R. Cheswick, S.M. Bellovin, "Firewalls and Internet Security",