readme

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

Ultrix).

You can use the `tcpdchk' program to identify the most common problems
in your wrapper and inetd configuration files.  

With the `tcpdmatch' program you can examine how the wrapper would
react to specific requests for service.  

The `try-from' program tests the host and username lookup code.  Run it
from a remote shell command (`rsh host /some/where/try-from') and it
should be able to figure out from what system it is being called.

The `safe_finger' command should be used when you implement a booby
trap:  it gives better protection against nasty stuff that remote hosts
may do in response to your finger probes.

The tcpd program can be used to monitor the telnet, finger, ftp, exec,
rsh, rlogin, tftp, talk, comsat and other tcp or udp services that have
a one-to-one mapping onto executable files.

With System V.4-style systems, the tcpd program can also handle TLI
services. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides
the same functions as with socket-based applications. When some other
protocol is used underneath TLI, functionality will be limited (no
client username lookups, weird network address formats).

The tcpd program can also be used for services that are marked as
rpc/udp in the inetd configuration file, but not for rpc/tcp services
such as rexd.  You probably do not want to run rexd anyway. On most
systems it is even less secure than a wildcard in /etc/hosts.equiv.

Install the tcpd command in a suitable place. Apollo UNIX users will
want to install it under a different name because the name "tcpd" is
already taken; a suitable name would be "frontd".  

File protections: the wrapper, all files used by the wrapper, and all
directories in the path leading to those files, should be accessible
but not writable for unprivileged users (mode 755 or mode 555). Do not
install the wrapper set-uid.

Then perform the following edits on the inetd configuration file
(usually /etc/inetd.conf or /etc/inet/inetd.conf):

    finger  stream  tcp     nowait  nobody  /usr/etc/in.fingerd     in.fingerd
                                            ^^^^^^^^^^^^^^^^^^^
becomes:

    finger  stream  tcp     nowait  nobody  /usr/etc/tcpd           in.fingerd
                                            ^^^^^^^^^^^^^
Send a `kill -HUP' to the inetd process to make the change effective.
Some IRIX inetd implementations require that you first disable the
finger service (comment out the finger service and `kill -HUP' the
inetd) before you can turn on the modified version. Sending a HUP
twice seems to work just as well for IRIX 5.3, 6.0, 6.0.1 and 6.1.

AIX note: you may have to execute the `inetimp' command after changing
the inetd configuration file.

The example applies to SunOS 4. With other UNIX implementations the
network daemons live in /usr/libexec, /usr/sbin, or /etc, the network
daemons have no "in." prefix to their names, or the username field in
the inetd configuration file may be missing.

When the finger service works as expected you can perform similar
changes for other network services. Do not forget the `kill -HUP'.

The miscd daemon that comes with Ultrix implements several network
services. It decides what to do by looking at its process name. One of
the services is systat, which is a kind of limited finger service.  If
you want to monitor the systat service, install the miscd wrapper in a
suitable place and update the inetd configuration file:

    systat  stream  tcp     nowait  /suitable/place/miscd      systatd

Ultrix 4.3 allows you to specify a user id under which the daemon will
be executed. This feature is not documented in the manual pages.  Thus,
the example would become:

    systat  stream  tcp     nowait  nobody /suitable/place/miscd    systatd

Older Ultrix systems still run all their network daemons as root.

In the absence of any access-control tables, the daemon wrappers
will just maintain a record of network connections made to your system.

7.3 - Daemons with arbitrary path names
---------------------------------------

The above tcpd examples work fine with network daemons that live in a
common directory, but sometimes that is not practical. Having soft
links all over your file system is not a clean solution, either.

Instead you can specify, in the inetd configuration file, an absolute
path name for the daemon process name.  For example,

    ntalk   dgram   udp     wait    root    /usr/etc/tcpd /usr/local/lib/ntalkd

When the daemon process name is an absolute path name, tcpd ignores the
value of the REAL_DAEMON_DIR constant, and uses the last path component
of the daemon process name for logging and for access control.

7.4 - Building and testing the access control rules
---------------------------------------------------

In order to support access control the wrappers must be compiled with
the -DHOSTS_ACCESS option. The access control policy is given in the
form of two tables (default: /etc/hosts.allow and /etc/hosts.deny).
Access control is disabled when there are no access control tables, or
when the tables are empty.

If you haven't used the wrappers before I recommend that you first run
them a couple of days without any access control restrictions. The
logfile records should give you an idea of the process names and of the
host names that you will have to build into your access control rules.

The syntax of the access control rules is documented in the file
hosts_access.5, which is in `nroff -man' format. This is a lengthy
document, and no-one expects you to read it right away from beginning
to end.  Instead, after reading the introductory section, skip to the
examples at the end so that you get a general idea of the language.
Then you can appreciate the detailed reference sections near the
beginning of the document.

The examples in the hosts_access.5 document (`nroff -man' format) show
two specific types of access control policy:  1) mostly closed (only
permitting access from a limited number of systems) and 2) mostly open
(permitting access from everyone except a limited number of trouble
makers). You will have to choose what model suits your situation best.
Implementing a mixed policy should not be overly difficult either.

Optional extensions to the access control language are described in the
hosts_options.5 document (`nroff -man' format).

The `tcpdchk' program examines all rules in your access control files
and reports any problems it can find. `tcpdchk -v' writes to standard
output a pretty-printed list of all rules. `tcpdchk -d' examines the
hosts.access and hosts.allow files in the current directory. This
program is described in the tcpdchk.8 document (`nroff -man' format).

The `tcpdmatch' command can be used to try out your local access
control files.  The command syntax is:

    tcpdmatch process_name hostname (e.g.: tcpdmatch in.tftpd localhost)

    tcpdmatch process_name address  (e.g.: tcpdmatch in.tftpd 127.0.0.1)

This way you can simulate what decisions will be made, and what actions
will be taken, when hosts connect to your own system. The program is
described in the tcpdmatch.8 document (`nroff -man' format).

Note 1: `tcpdmatch -d' will look for hosts.{allow,deny} tables in the
current working directory. This is useful for testing new rules without
bothering your users.

Note 2: you cannot use the `tcpdmatch' command to simulate what happens
when the local system connects to other hosts.

In order to find out what process name to use, just use the service and
watch the process name that shows up in the logfile.  Alternatively,
you can look up the name from the inetd configuration file. Coming back
to the tftp example in the tutorial section above:

    tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd -s /tftpboot

This entry causes the inetd to run the wrapper program (tcpd) with a
process name `in.tftpd'.  This is the name that the wrapper will use
when scanning the access control tables. Therefore, `in.tftpd' is the
process name that should be given to the `tcpdmatch' command. On your
system the actual inetd.conf entry may differ (tftpd instead of
in.tftpd, and no `root' field), but you get the idea.

When you specify a host name, the `tcpdmatch' program will use both the
host name and address. This way you can simulate the most common case
where the wrappers know both the host address and the host name.  The
`tcpdmatch' program will iterate over all addresses that it can find
for the given host name.

When you specify a host address instead of a host name, the `tcpdmatch'
program will pretend that the host name is unknown, so that you can
simulate what happens when the wrapper is unable to look up the client
host name.

7.5 - Other applications
------------------------

The access control routines can easily be integrated with other
programs.  The hosts_access.3 manual page (`nroff -man' format)
describes the external interface of the libwrap.a library.

The tcpd program can even be used to control access to the mail
service.  This can be useful when you suspect that someone is trying
out some obscure sendmail bug, or when a remote site is misconfigured
and keeps hammering your mail daemon.

In that case, sendmail should not be run as a stand-alone network
listener, but it should be registered in the inetd configuration file.
For example:

    smtp    stream  tcp     nowait  root    /usr/etc/tcpd /usr/lib/sendmail -bs

You will still need to run one sendmail background process to handle
queued-up outgoing mail. A command like:

    /usr/lib/sendmail -q15m

(no `-bd' flag) should take care of that. You cannot really prevent
people from posting forged mail this way, because there are many
unprotected smtp daemons on the network.

8 - Acknowledgements
--------------------

Many people contributed to the evolution of the programs, by asking
inspiring questions, by suggesting features or bugfixes, or by
submitting source code.  Nevertheless, all mistakes and bugs in the
wrappers are my own.

Thanks to Brendan Kehoe (cs.widener.edu), Heimir Sverrisson (hafro.is)
and Dan Bernstein (kramden.acf.nyu.edu) for feedback on an early
release of this product.  The host name/address check was suggested by
John Kimball (src.honeywell.com).  Apollo's UNIX environment has some
peculiar quirks: Willem-Jan Withagen (eb.ele.tue.nl), Pieter
Schoenmakers (es.ele.tue.nl) and Charles S. Fuller (wccs.psc.edu)
provided assistance.  Hal R.  Brand (addvax.llnl.gov) told me how to
get the client IP address in case of datagram-oriented services, and
suggested the optional shell command feature.  Shabbir Safdar
(mentor.cc.purdue.edu) provided a first version of a much-needed manual
page.  Granville Boman Goza, IV (sei.cmu.edu) suggested to use the
client IP address even when the host name is available.  Casper H.S.
Dik (fwi.uva.nl) provided additional insight into DNS spoofing
techniques.  The bogus daemon feature was inspired by code from Andrew
Macpherson (BNR Europe Ltd).  Steve Bellovin (research.att.com)
confirmed some of my suspicions about the darker sides of TCP/IP
insecurity. Risks of automated fingers were pointed out by Borja Marcos
(we.lc.ehu.es). Brad Plecs (jhuspo.ca.jhu.edu) was kind enough to try
my early TLI code and to work out how DG/UX differs from Solaris.

John P.  Rouillard (cs.umb.edu) deserves special mention for his
persistent, but constructive, nagging about wrong or missing things,
and for trying out and discussing embryonic code or ideas.

Last but not least, Howard Chu (hanauma.jpl.nasa.gov), Darren Reed
(coombs.anu.edu.au), Icarus Sparry (gdr.bath.ac.uk), Scott Schwartz
(cs.psu.edu), John A. Kunze (violet.berkeley.edu), Daniel Len Schales
(engr.latech.edu), Chris Turbeville (cse.uta.edu), Paul Kranenburg
(cs.few.eur.nl), Marc Boucher (cam.org), Dave Mitchell
(dcs.shef.ac.uk), Andrew Maffei, Adrian van Bloois, Rop Gonggrijp, John
C. Wingenbach, Everett F. Batey  and many, many others provided fixes,
code fragments, or ideas for improvements.

        Wietse Venema ([e-mail])
        Department of Mathematics and Computing Science
        Eindhoven University of Technology
        P.O. Box 513
        5600 MB Eindhoven
        The Netherlands

	Currently visiting IBM T.J. Watson Research, Hawthorne NY, USA.