7. inetd, TCP/IP Wrappers, Portmapper and xinetd

7.1. TCP Wrappers

In short, TCP-wrappers allow connections to the machine on which they are running to be restricted to those coming from approved domains or machines, e.g., if you would prefer that only telnet requests from within umist.ac.uk should be accepted then use TCP-wrappers!

Let me quote from the blurb that comes with these: TCP/IP Wrappers help you to monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services.

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.

TCP-Wrappers are not installed on Solaris 8 as part of the distribution from Sun.

7.1.1. Getting and Building/Compiling

The main site (or more accurately page) is:
From here you can download a gzipped, tarred source distribution. In my experience this compiles "out of the box" using gcc: read the README, edit the Makefile as appropriate (the only mandatory edit is to choose a value for REAL_DAEMON_DIR --- a default of /usr/sbin is given for Solaris and this is correct for Solaris 2.8) and
Five excutable binaries are produced: safe_finger, tcpd, tcpdchk, tcpdmatch and try-from.

7.1.2. Installing

The best way to install the TCP-wrapper is as follows. Copy the utilties you have built into /usr/sbin, then edit (create) two text files. The following examples can be used as a model:

    in.telnetd: ALL
    in.ftpd: ALL
    in.rexecd: ALL
    in.rlogind: ALL
    in.rshd: ALL
This prevents anyone from anywhere making remote telnet, ftp, rexec, rsh and rlogin connections, except those specifically listed in hosts.allow.

    in.telnetd: .umist.ac.uk, .mcc.ac.uk, .liv.ac.uk
    in.ftpd: .umist.ac.uk, .mcc.ac.uk
    in.rshd: .umist.ac.uk 
The entries in this file override those within /etc/hosts.deny. This permits telnet connections from within UMIST, Manchester Computing and Liverpool University; FTP connections from within the first two of these; and rsh connections from within only UMIST.

Finally edit /etc/inetd/conf so that requests for connections are handled by tcpd instead of the daemons installed as part of Solaris; if a connection satisfies the constraints defined by the hosts.allow|deny files, the connection is handed over to the Solaris daemons to handle. (The middle of) my /etc/inetd/conf looks like this (the comments explain the changes made after the Solaris installation). That's it --- no reboot necessary!

7.1.3. The Other Utilities

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.

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.

Installation on (RedHat) Linux

Obtain the RPMs for both Port Sentry and Log Check from any RedHat mirror, within the contrib directory, or at rpmfind.net, or its UK mirror at www.mirror.ac.uk. Then install them in the usual way, i.e., as root, rpm -Uvh <file>.rpm. This process installs the necessary files, starts the daemons and ensures the necessary entries are placed in the initialisation tables so that the daemons are started on subsequent boots.

Installation on Solaris

Download the .tar.gz file from Psionic's site (see above).


There are two files, /etc/hosts.allow and /etc/hosts.deny.

If a mostly-closed configuration is desired, then hosts.deny should consist of simply
which means all services are denied from all IP addresses by default. An example of a corresponding hosts.allow file is given below:

# hosts.allow	This file describes the names of the hosts which are
#		allowed to use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
# in.telnetd: .liv.ac.uk : ALLOW

###ALL : .liv.ac.uk
###ALL : .umist.ac.uk

ALL : talby.csu.umist.ac.uk

ALL : boiler.csu.umist.ac.uk
ALL : pinback.csu.umist.ac.uk

in.telnetd : cosmos.umist.ac.uk 
ALL : rcpc.csu.umist.ac.uk 
ALL : listserv.umist.ac.uk

If a mostly-open configuration is desired the /etc/hosts.allow consists of simply ALL: ALL so that hosts are allowed to connect by default and /etc/hosts.deny will list services and corresponding IP addresses which should be denied access, for example:
in.telnetd : knownoffender.domain
ALL : .dodgy.domain

7.2. portmap/rpcbind

Whilst many services run by listening on "well known" ports, others such as NIS and NFS use RPC (Remote Procedure Call). Instead an arbitrary port is chosen on initialisation and this is then registered with a Portmapper service running on the same machine. Only the Portmapper needs to run on the "well-known" port; when clients want access to the service, they first contact the Portmapper, and it tells them which port they should then contact in order to reach the service. This second port may be for TCP or UDP access, depending on the client.

On Linux, portmap provides the portmapper service. Whilst it runs separately from inetd, Version 4 (and above), written by Wietse Venema, provides TCP Wrappers-style access-control via the same hosts.allow and hosts.deny files. On Solaris rpcbind provides the portmapping service; an enhanced version is available and which provides access control.

7.2.1. Obtaining, Building and Installing portmap

Most Linux distibutions come with portmap. If it is unavailable with your distribution dowbload the source code from coast.cs.perdue.edu or ftp.porcupine.org. Before compilation, edit the Makefile to reflect your choice of value for the various flags (these include where to log events, the location of libwrap.a, the TCP Wrappers library which must be installed first) then build and install in the usual way.

7.2.2. Configuring portmap

portmap uses the same files as TCP Wrappers, /etc/hosts.allow and /etc/hosts.deny. To taste the flavour of configuration consider the following example entries in hosts.allow:
    # -- hosts.allow :  
    portmap: deny
    portmap:, spawn (/usr/sbin/safe_finger \
            -lp @%a | logger -p local5.warn)&

    # -- allow the rest of our internal network :
    portmap: 172.17.
    # deny everyone else :
    portmap: ALL: deny
Respectively, these entries: deny portmap services to addresses from to; allow illegal broadcast addresses, but log such events; allow the rest of our network; and deny every one else portmap services.

7.2.3. portmap Logging

By default only failed requests are logged. If successful requests are to be logged invoke portmap with the -v option.

7.2.4. rcpbind

The source code for the replacement rcpbind which includes access control may be obtained from ftp.porcupine.com.

7.2.5. More

7.3. xinetd

RedHat 6.2 and earlier versions of Linux handle internet sockets through inetd. When running, inetd listens for connections on certain internet sockets. When a connection is found on one of its sockets, it looks up which service the socket corresponds to, and invokes a program (server) to service the request. In recent versions of Linux inetd has been replaced with xinetd.

xinetd provides: access-control similar to that offered by inetd with TCP Wrappers --- one can control both tcp and udp unlike Wrappers; improved logging compared to inetd; improved defense against denial of service attacks --- in addition to specifying the rate of connections to a service that is permitted, one can specify the maximum number accepted.

xinetd can provide access-control for both inetd-style services and RPC services.

7.3.1. Starting and Restarting (Reconfiguring) xinetd

In starting xinetd you can specify both the configuration file and the file to be used for logging. For example
    /usr/sbin/xinetd -filelog /var/log/xinetd.log -f /etc/xinetd.conf
If at anytime the configuration file is changed xinetd will need to be restarted to reflect these changes. One can do this by signalling the xinetd process:
    prompt>ps -ax | grep xinetd
    root  644  0.0  0.7  2240  956  ?  S  08:57  0:00 xinetd -pidfile...
    prompt>kill -SIGUSR1 644
or by using the initialisation script
    /etc/init.d/xinetd restart
N.B. kill -HUP will terminate the xinetd process.

7.3.2. The Configuration File: Upgrading from inetd; Services; Access Control

The configuration file is usually /etc/xinetd.conf. One can either modify the supplied file or create one from an inetd.conf file using itox or xconv.pl (supplied --- the latter is to succeed the former).

Each service controlled by xinetd has a corresponding section in the configuration file. Each section looks something like this:

    service ssh1
        socket_type    = stream
        protocol       = tcp
        instances      = 10
        nice           = 10
        wait           = no
        user           = root
        server         = /usr/local/sbin/sshd1
        server_args    = -i
        log_on_failure += USERID
        only_from      =
        no_access      =
        no_access      +=
TCP-wrappers-like access control is given by the only_from and no_access directives; the maximum number of instances of the server which can run simultaneously is given by instances (preventing DoS attacks).

On some systems, including RedHat 7.1, there is a master configuration file, /etc/xinetd.conf, which includes the line
    includedir /etc/xinetd.d
and within this directory a file for each service which runs under xinetd, such as /etc/xinetd.d/telnet:

    # default: on
    # description: The telnet server serves telnet sessions; it uses \
    #	unencrypted username/password pairs for authentication.
    service telnet
       flags           = REUSE
       socket_type     = stream        
       wait            = no
       user            = root
       server          = /usr/sbin/in.telnetd
       log_on_failure += USERID
       disable         = no
       only_from       =
       only_from      +=

7.3.3. Logging

Using logging directives (e.g., log_on_failure += USERID) one can log various attrributes of attempted connections including process-id, remote host and duration of session; one can specify distinct directives for success and failure, for example, one can log the reason why a connection failed.

7.3.4. More

8. Intrusion Detection (Tripwire)

No system is impregnable. Intrusion Detection systems provide a final safety net which will help minimise damage from a successful root crack of your system. The principle used is simple: often a system cracker, after "rooting" will install their own versions of system utilities such as ls, ps and netstat, in order to hide their activities --- these new versions will fail to list particular files, processes or connections. Intrusion detection systems (integrity checkers) create databases of hashes/checksums of important utilities and configuration files. By periodically checking those files against the checker's database we should be able to spot such activity.

8.1. FCheck

FCheck is an open source PERL script providing intrusion detection and policy enforcement of Windows 95/98/NT/3.x and Unix server administration through the use of comparative system snapshots. FCheck can provide notification of any differences found through use of your event management system, printer, and/or email when any monitored files or directories are altered, including any additions and/or deletions.

FCheck has been tested and is known to run on the following platforms with Perl installed:

8.2. Tripwire

Let me quote from the RPM: Tripwire answers the fundamental question: "Is my system the same today as it was yesterday?" Tripwire creates a cryptographically-secured database of files and their characteristics based on the specifications of your configurable policy file. This database is then used to determine if any unauthorized changes have been made to your system.

Obtaining Tripwire

There three versions of Tripwire:

Installing Tripwire

We describe the configuration of the version of Tripwire that comes with RedHat Linux 7.1.

Most distributions of Linux come with an rpm. After installing the rpm (rpm -ivh tripwire-<version>.rpm) Tripwire is not yet configured. To do this:

  1. First, edit twpol.txt, the policy file which describes which system files to keep check on.
  2. Run tripwire.sh to generate cryptographic keys and set passwords. (Amongst other things, this calls twadmin to generate the encrypted form of the policy file, tw.pol by default.
  3. Run tripwire --init to initialize the database.
Check the information supplied with the RPM (rpm -q --info tripwire) for any changes to this procedure.

If you wish to subsequently change the use the twadmin utility:

  1. Edit the clear-text policy file, twpol.txt by default.
  2. Run twadin --create-polfile twpol.txt to create the encrypted version.
  3. Run tripwire --init to recreate the Tripwire database.

Example: A Very Simple Example Configuration File

This example should give the flavour of Tripwire. For details, see the resources given below.

    BINS = $(ReadOnly) ;

    SEC_INVARIANT = +tpug ;
    SIG_MED       = 66 ;

    # Simon's web rules:
      rulename = "MickWeb"
      severity = $(SIG_MED)
      emailto = simon.hood@umist.ac.uk
      $(TWPOL)           -> $(ReadOnly) ;
      $(WEBROOT)         -> $(ReadOnly) (recurse=1) ;
      !$(WEBROOT)/guestbook.html ;
      $(CGIBINS)         -> $(BINS) ;
      /var/log/httpd     -> $(Growing) ;

The first four lines of this script set some variables in a similar way to scripting under most shells. The fifth line sets a synonym for a pre-defined mask. A mask defines what properties should not change, such as file owner, time-stamp and file size.

SEC_INVARIANT = +tpug defines a mask for directories that should not change permissions or ownership (t: file type, p: permissions, u: file owner's user ID, g: file owner's group ID).

SIG_MED = 66 defines a severity level of the rule.

The remainder of the example defines a group of rules: first the name and severity are set; then the action to take (email to simon.hood). This rule group consists of 5 rules: the first says that TWPOL must be readonly; the second that WEBROOT should be readonly, including one level of subdirectories; the third (beginning with an exclamation mark) tells tripwire to ignore changes to guestbook.html; the fourth sets the cgi-bin scripts to be readonly; and the last says that the web-server log file is expected to grow (monotonically).

Installing and Configuring Tripwire --- Continued

A good way to use Tripwire is to have it compare files on your system to its database on a regular basis and email you the results. This is easily done: ensure part of /etc/tripwire/twcfg.txt looks like this:
    MAILPROGRAM =/usr/sbin/sendmail -oi -t
and set up a cron job to do the rest, for example, /etc/cron.daily/tripwire-check:
  HOST_NAME=`uname -n`
  if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
    echo "**    Error: Tripwire database for ${HOST_NAME} not found.    **"
    echo "** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". **"
    test -f /etc/tripwire/tw.cfg &&  /usr/sbin/tripwire --check
The RedHat v7.1 RPM does this for you.


HostSentry...Psionic (cf. LogSentry, PortSentry)...

8.3. Advanced Intrusion Detection Environment

From the web site:

AIDE (Advanced Intrusion Detection Environment) is a free replacement for Tripwire. It does the same things as the semi-free Tripwire and more.

It creates a database from the regular expression rules that it finds from the config file. Once this database is initialized it can be used to verify the integrity of the files. It has several message digest algorithms (md5, sha1, rmd160, tiger, haval, etc.) that are used to check the integrity of the file. More algorithms can be added with relative ease. All of the usual file attributes can also be checked for inconsistencies.

AIDE has been tested running on:

8.4. CVS

The Concurrent Versions System was designed to be used by software developers to organise source code. It can also be used as an intrusion detection tool with advavantages over and above Tripwire, the most commonly used tool.

Tripwire and similar tools tend to report a larger number of false positives; Tripwire reports only that a file has changed, not details of the change. This combination of features can mean a lot of work for system administrators. On the other hand CVS will report exactly how a text file has changed. CVS can also be used to compare the output of commands (e.g., ls -l my_dir) since these can be redirected to files. These advantages can save time and yield details about an intrusion which Tripwire does not. (On the other hand, CVS cannot handle binary files.)

For details of how CVS can be used (with a little Perl glue) see Veryifying Filesystem Integrity with CVS, Linux Journal, Feburary, 2002.

8.5. chkrootkit

From the README:

 chkrootkit is a tool to locally check for signs of a rootkit.  It

 * chkrootkit: a shell script that checks system binaries for
   rootkit modification.  The following tests are made:

   aliens asp bindshell lkm rexedcs sniffer wted z2 amd basename biff
   chfn chsh cron date du dirname echo egrep env find fingerd gpm grep
   hdparm su ifconfig inetd inetdconf identd killall ldsopreload login
   ls lsof mail mingetty netstat named passwd pidof pop2 pop3 ps
   pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd
   top telnetd timed traceroute write

 * ifpromisc.c: checks if the network interface is in promiscuous

 * chklastlog.c: checks for lastlog deletions.

 * chkwtmp.c: checks for wtmp deletions.

 * check_wtmpx.c: checks for wtmpx deletions.  (Solaris only)

 * chkproc.c: checks for signs of LKM trojans.

...previousup (conts)next...

About this document:

Produced from the SGML: /home/isd/public_html/_unix_security/_reml_grp/unix_security_survey.reml
On: 10/11/2004 at 9:49:32
Options: reml2 -i noindex -l long -o html -p multiple