Original Question (short form)
> Problem:
> tcpd won't exec rpc.ttdbserverd.
>
> System logs show messages that say:
> rpc.ttdbserverd[374]: warning: can't get client address:
> Primitive not supported by provider
Resolution:
The ToolTalk DB server is an RPC service of type "wait/tcp". It
does an accept() on the TCP connection after it has entered the
start process -- not in inetd -- so tcpd never has the address of
the 'far end' of the connection and cannot make an 'allow/deny'
decision.
I was referred to rpcbind_2.1 built with librwap.a (available at
www.porcupine.com) to offer some additional protection from RPC
service attacks, however, the benefit is limited since rpcbind_2.1
only limits access to its list of registered RPC port numbers. A
determined intruder would simply port-scan the system and find a
port that responds like a ttdbserverd should (or whatever service
is under attack) Bottom line, rpcbind_2.1 provides little more
than 'security through obscurity.'
Better overall protection can be had with a packet filtering tool
such as ipfilter:
http://cheops.anu.edu.au/~avalon/ip-filter.html
Thanks to:
Casper Dik, Andy Paton, Brad Young, Stuart Kendrick,
and Rafael Jesus Garcia Jimenez (in order of reply)
I include the following detailed description (courtesy "JESS" Rafael
Jesus Garcia Jimenez) of how tcpd does its work.
| This is how TCPWrapper works:
|
| When a request for a service arrives, it performs one or more
| of the following:
|
| + Optionally sends a "banner" to the connecting client.
|
| + Performs a double-reverse lookup of the IP address (if compiled
| PARANOID). This provides spoofing protection.
|
| + Compares the incoming hostname and requested service with an
| access control list (hosts.allow, hosts.deny). (This may be
| disabled too).
|
| + Optionally uses the ident protocol (RFC 1413) to determine the
| username associated with the incoming connection.
|
| + Logs the results with syslog. (default facility is MAIL - can
| be changed in compilation time)
|
| + Optionally runs a command.
|
| + Passes control of the connection to the "real" network daemon,
| or passes control to some other program.
|
| + Optionally Transfers to a jail or "faux" environment where you
| study the user's actions (hacker's jail).
|
| As you can see, point 2 is performing a double-reverse lookup, and
| this is where the incoming connection you are receiving is dropped.
|
| You can avoid this behavior by compiling tcpd without the PARANOID
| option. In any case, I do not recommend to do that on a machine that may
| receive incoming internet connections, because that way you loose the
| wrappper's anti-spoofing capabilities. Anyway, remember that TCPW is
| vulnerable to IP spoofing because it uses IP addresses for authentication.
|
| As I see you are trying to protect EVERY service on your inetd,
| be aware, also, of the following vulnerabilities:
|
| - Provides only limited support for UDP (or RPC/UDP) servers.
|
| May UDP servers linger around for a while after they have serviced
| a request, in case a new request comes in (the ones registered with
| 'wait' in inetd.conf). Only the request that started the daemon
| will be seen by TCPW.
|
| - TCPW are of little use with network daemons that service more than
| one client (e.g. NFS) because they go away after the initial contact
| between client and server processes.
|
| - TCPW do not work with RPC/TCP (e.g. rexec).
|
| I hope this helps.
|
| JESS
Michael Maciolek
Exodus Professional Services
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:05 CDT