readme

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

    Addison-Wesley, 1994.

Discussions on internet firewalls are archived on ftp.greatcircle.com.
Subscribe to the mailing list by sending a message to 

    [e-mail]

With in the body (not subject): subscribe firewalls.

5.2 - Related software
----------------------

Network daemons etc. with enhanced logging capabilities can generate
massive amounts of information: our 150+ workstations generate several
hundred kbytes each day. egrep-based filters can help to suppress some
of the noise.  A more powerful tool is the Swatch monitoring system by
Stephen E. Hansen and E. Todd Atkins. Swatch can process log files in
real time and can associate arbitrary actions with patterns; its
applications are by no means restricted to security.  Swatch is
available ftp.stanford.edu, directory /general/security-tools/swatch.

Socks, described in the UNIX Security III proceedings, can be used to
control network traffic from hosts on an internal network, through a
firewall host, to the outer world. Socks consists of a daemon that is
run on the firewall host, and of a library with routines that redirect
application socket calls through the firewall daemon.  Socks is
available from s1.gov in /pub/firewalls/socks.tar.Z.

For a modified Socks version by Ying-Da Lee ([e-mail]) try
ftp.nec.com, directory /pub/security/socks.cstc.

Tcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp
and telnet commands across a firewall. Unlike socks it can be used with
unmodified client software. Available from ftp.alantec.com, /pub/tcpr.

The TIS firewall toolkit provides a multitude of tools to build your
own internet firewall system. ftp.tis.com, directory /pub/firewalls.

Versions of rshd and rlogind, modified to report the client user name
in addition to the client host name, are available for anonymous ftp
(ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z).  These programs are
drop-in replacements for SunOS 4.x, Ultrix 4.x, SunOS 5.x and HP-UX
9.x. This archive also contains ftpd/rexecd/login versions that support
S/Key or SecureNet one-time passwords in addition to traditional UNIX
reusable passwords.

The securelib shared library by William LeFebvre can be used to control
access to network daemons that are not run under control of the inetd
or that serve more than one client, such as the NFS mount daemon that
runs until the machine goes down.  Available from eecs.nwu.edu, file
/pub/securelib.tar.

xinetd (posted to comp.sources.unix) is an inetd replacement that
provides, among others, logging, username lookup and access control.
However, it does not support the System V TLI services, and involves
much more source code than the daemon wrapper programs. Available
from ftp.uu.net, directory /usenet/comp.sources.unix.

netlog from Texas A&M relies on the SunOS 4.x /dev/nit interface to
passively watch all TCP and UDP network traffic on a network.  The
current version is on net.tamu.edu in /pub/security/TAMU.

Where shared libraries or router-based packet filtering are not an
option, an alternative portmap daemon can help to prevent hackers
from mounting your NFS file systems using the proxy RPC facility.
ftp.win.tue.nl:/pub/security/portmap-X.shar.Z was tested with SunOS
4.1.X Ultrix 3.0 and Ultrix 4.x, HP-UX 8.x and some version of AIX. The
protection is less effective than that of the securelib library because
portmap is mostly a dictionary service.

An rpcbind replacement (the Solaris 2.x moral equivalent of portmap)
can be found on ftp.win.tue.nl in /pub/security. It prevents hackers
from mounting your NFS file systems by using the proxy RPC facility.

Source for a portable RFC 931 (TAP, IDENT, RFC 1413) daemon by Peter
Eriksson is available from ftp.lysator.liu.se:/pub/ident/servers.

Some TCP/IP implementations come without syslog library. Some come with
the library but have no syslog daemon. A replacement can be found in
ftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Z.  The fakesyslog
library that comes with the nntp sources reportedly works well, too.

6 - Limitations
---------------

6.1 - Known wrapper limitations
-------------------------------

Many UDP (and rpc/udp) daemons linger around for a while after they
have serviced a request, just in case another request comes in.  In the
inetd configuration file these daemons are registered with the `wait'
option. Only the request that started such a daemon will be seen by the
wrappers.  Such daemons are better protected with the securelib shared
library (see: Related software).

The wrappers do not work with RPC services over TCP. These services are
registered as rpc/tcp in the inetd configuration file. The only non-
trivial service that is affected by this limitation is rexd, which is
used by the on(1) command. This is no great loss.  On most systems,
rexd is less secure than a wildcard in /etc/hosts.equiv.

Some RPC requests (for example: rwall, rup, rusers) appear to come from
the server host. What happens is that the client broadcasts its request
to all portmap daemons on its network; each portmap daemon forwards the
request to a daemon on its own system. As far as the rwall etc.  daemons
know, the request comes from the local host.

Portmap and RPC (e.g. NIS and NFS) (in)security is a topic in itself.
See the section in this document on related software.

6.2 - Known system software bugs
--------------------------------

Workarounds have been implemented for several bugs in system software.
They are described in the Makefile. Unfortunately, some system software
bugs cannot be worked around. The result is loss of functionality.

IRIX has so many bugs that it has its own README.IRIX file.

Older ConvexOS versions come with a broken recvfrom(2) implementation.
This makes it impossible for the daemon wrappers to look up the
client host address (and hence, the name) in case of UDP requests.
A patch is available for ConvexOS 10.1; later releases should be OK.

With early Solaris (SunOS 5) versions, the syslog daemon will leave
behind zombie processes when writing to logged-in users.  Workaround:
increase the syslogd threshold for logging to users, or reduce the
wrapper's logging severity.

On some systems, the optional RFC 931 etc. client username lookups may
trigger a kernel bug.  When a client host connects to your system, and
the RFC 931 connection from your system to that client is rejected by a
router, your kernel may drop all connections with that client.  This is
not a bug in the wrapper programs: complain to your vendor, and don't
enable client user name lookups until the bug has been fixed.

Reportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2
and later are OK.

Sony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug.
Reportedly, a fix for Ultrix is available (CXO-8919).

The following procedure can be used (from outside the tue.nl domain) to
find out if your kernel has the bug. From the system under test, do:

        % ftp 131.155.70.19

This command attempts to make an ftp connection to our anonymous ftp
server (ftp.win.tue.nl).  When the connection has been established, run
the following command from the same system under test, while keeping
the ftp connection open:

        % telnet 131.155.70.19 111

Do not forget the `111' at the end of the command. This telnet command
attempts to connect to our portmap process.  The telnet command should
fail with:  "host not reachable", or with a timeout error. If your ftp
connection gets messed up, you have the bug. If the telnet command does
not fail, please let me know a.s.a.p.!

For those who care, the bug is that the BSD kernel code was not careful
enough with incoming ICMP UNREACHABLE control messages (it ignored the
local and remote port numbers, and therefore zapped *all* connections
with the remote system). The bug is still present in the BSD NET/1
source release (1989) but apparently has been fixed in BSD NET/2 (1991). 

7 - Configuration and installation
----------------------------------

7.1 - Easy configuration and installation
-----------------------------------------

The "easy" recipe requires no changes to existing software or
configuration files.  Basically, you move the daemons that you want to
protect to a different directory and plug the resulting holes with
copies of the wrapper programs.

If you don't run Ultrix, you won't need the miscd wrapper program.  The
miscd daemon implements among others the SYSTAT service, which produces
the same output as the WHO command.

Type `make' and follow the instructions.  The Makefile comes with
ready-to-use templates for many common UNIX implementations (sun,
ultrix, hp-ux, aix, irix,...). 

IRIX has so many bugs that it has its own README.IRIX file.

When the `make' succeeds the result is five executables (six in case of
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 `safe_finger' command should be used when you implement booby
traps:  it gives better protection against nasty stuff that remote
hosts may do in response to your finger probes.

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 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.

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.

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).

Decide which services you want to monitor. Move the corresponding
vendor-provided daemon programs to the location specified by the
REAL_DAEMON_DIR constant in the Makefile, and fill the holes with
copies of the tcpd program. That is, one copy of (or link to) the tcpd
program for each service that you want to monitor. For example, to
monitor the use of your finger service:

    # mkdir REAL_DAEMON_DIR
    # mv /usr/etc/in.fingerd REAL_DAEMON_DIR
    # cp tcpd /usr/etc/in.fingerd

The example applies to SunOS 4. With other UNIX implementations the
network daemons live in /usr/libexec, /usr/sbin or in /etc, or have no
"in." prefix to their names, but you get the idea.

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.

Ultrix only:  If you want to monitor the SYSTAT service, move the
vendor-provided miscd daemon to the location specified by the
REAL_DAEMON_DIR macro in the Makefile, and install the miscd wrapper
at the original miscd location.

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

7.2 - Advanced configuration and installation
---------------------------------------------

The advanced recipe leaves your daemon executables alone, but involves
simple modifications to the inetd configuration file.

Type `make' and follow the instructions.  The Makefile comes with
ready-to-use templates for many common UNIX implementations (sun,
ultrix, hp-ux, aix, irix, ...). 

IRIX users should read the warnings in the README.IRIX file first.

When the `make' succeeds the result is five executables (six in case of