TCP Wrappers

Originally, BSD Unix set a different server program running for every network service. As the number of services grew in the mid 1980s, Unix systems started having more and more server programs sleeping in the background, waiting for network connections. Although the servers were sleeping, they nevertheless consumed valuable system resources such as process table entries and swap space. Perhaps more importantly, configuring these servers was somewhat difficult, as each server was started up in a different way and had a different syntax for defining which port they should bind to and which UID they should use when running.

Today's Unix systems use the Internet daemon, inetd, to centralize the handling of lightweight Internet services. The Internet daemon listens and accepts connections on many network ports at the same time. When a connection is received, inetd automatically starts up the appropriate TCP-based or UDP-based server running under the appropriate UID. The Internet daemon also simplifies the writing of application-specific daemons themselves, as each daemon can be written so that it reads from the network on standard input and writes back to the network on standard output—no special calls from the Berkeley socket library are required.

The inetd daemon is run at boot time as part of the startup procedure. When inetd starts executing, it examines the contents of the /etc/inetd.conf file to determine which network services it is supposed to manage. The program will reread its configuration file if it is sent a HUP signal

A sample inetd.conf file

Each line of the inetd.conf file contains at least six fields, separated by spaces or tabs:

Some services, like echo, time, and discard, are listed as "internal." These services are so trivial that they are handled internally by inetd rather than requiring a special program to be run. Although these services are useful for testing, they can also be used for denial of service attacks. You should therefore disable them.

You should routinely check the entries in the /etc/inetd.conf file and verify that you understand why each of the services in the file is being offered to the Internet. Sometimes, when attackers break into systems, they create new services to make future break-ins easier. If you cannot explain why a service is being offered at your site, you may wish to disable it until you know what purpose it serves. In many circumstances, it is better to disable a service that you are not sure about than it is to leave it enabled in an effort to find out who is using it at a later point in time: if somebody is using the service, they are sure to let you know! One easy way to list all of the services that are enabled is:

Because of the importance of the /etc/inetd.conf file, you may wish to track changes to this file using a source code control system such as RCS or CVS. You may also wish to use a consistency-checking tool such as Tripwire or detached PGP signatures to verify that all changes to the file are authorized and properly recorded.

The idea of TCP Wrappers as controlling layer for Inetd

TCP Wrappers is a package developed by Wietse Venema (who also wrote the SATAN security package) at the Eindhoven University of Technology as a countermeasure against attacks on their university systems. TCP_wrappers is an IP packet filtering and network access logging facility for inetd. TCP_wrappers is usually configured to "wrap" itself around TCP-based services defined in inetd.conf.

Tcp Wrappers is a single program called "tcpd". Unfortunately, it is distributed under the plural name of "TCP wrappers". It is a program and 2 configuration files. Paraphrased from the readme: With this package you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services. The package provides a tiny daemon wrapper program that can be installed without any changes to existing software or to existing configuration files. The wrapper reports the name of the client host and of the requested service; the wrapper does not exchange information with the client or server applications, and imposes no overhead on the actual conversation between the client and server applications. Optional features are: access control to restrict what systems can connect to what network daemons; client user name lookups with the RFC 931 etc. protocol; additional protection against hosts that pretend to have someone elses host name; additional protection against hosts that pretend to have someone else's host address.

The TCP Wrappers program can log incoming connections via syslog—whether or not the actual Internet daemon provides logging. TCP Wrappers also allows different server executables to be invoked for a given service depending on the source IP address of the incoming connection.

While TCP Wrappers can be run as a standalone program, today it is most commonly used as a library (libwrap) that is linked into the inetd program. By using a modern inetd program, your system will automatically honor the /etc/hosts.allow and /etc/hosts.deny files, which are described later.

Tcp_wrappers are designed to verify a remote hostname with its IP number before allowing a connection to be established. If a workstation's IP number and hostname do not match when checked against the domain tables maintained by the Internet Service Provider providing Internet connectivity for that workstation, tcp_wrappers will close the session before the user enters a username or password. The original tcp_wrappers work in tandem with inetd can can control all programs launched by inetd like telnet and ftp using the hosts.allow & host.deny files. If you only want trusted networks/machine to be able to start telnet, you just add them into hosts.allow and turn off everyone else with hosts.deny.

TCP wrappers can monitor and filter incoming requests for telnet, ftp, rlogin, rsh, finger, talk, and just about anything else that run out of inetd.conf.

The tcpd program can be set up to monitor incoming requests for


telnet

, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other services that have a one-to-one mapping onto executable files.

Operation is as follows: whenever a request for service arrives, the inetd daemon is tricked into running the tcpd program instead of the normal server. tcpd logs the request and does some additional checks. When all is well, tcpd runs the appropriate server program and goes away.

Optional features include pattern-based access control, client username lookups with the RFC 931 protocol, protection against hosts that pretend to have someone else's host name, and protection against hosts that pretend to have someone else's network address.

Utilities (tcpdchk and tcpdmatch) are included to aid writing of /etc/hosts.allow and /etc/hosts.deny files. tcpdmatch does not understand '?' syntax in /etc/inet.conf, so it may generate spurious warnings noting that optional servers were not found.

What TCP Wrappers does

The TCP Wrappers system gives the system administrator a high degree of control over incoming TCP connections. The system is invoked after a remote host connects to your computer. It is invoked either through a subroutine library that is linked into the Internet server or through a standalone program started up through inetd. Once running, the TCP Wrappers system performs the following steps:

If this seems overly complicated to you, you are right—it is. The reason for having two files, /etc/hosts.allow and /etc/hosts.deny, is to allow for backward compatibility with previous versions of TCP Wrapperss that did not provide for different kinds of actions on each line of the file. These earlier versions simply had a list of allowed hosts for each protocol in the file /etc/hosts.allow and a list of hosts to deny for each protocol in the file /etc/hosts.deny. These days, TCP Wrapperss is compiled with the -DPROCESS_OPTIONS option, which causes the advanced rules to be properly interpreted. Unfortunately, as is often the case, the complexity of having two incompatible modes of operation remains to allow for backward compatibility.

The actions implemented by TCP Wrappers are quite sophisticated. Specifically, options can:

The TCP Wrappers system allows you to make up for many deficiencies in other network daemons. You can add logging to services that are not otherwise logged, add sophisticated and easily changeable access control lists, and even substitute different versions of a service daemon depending on the calling host. These are some of the reasons that the TCP Wrappers system has become standard on both free and commercial Unix offerings in recent years.

The TCP Wrappers configuration language

The TCP Wrappers system has a simple but powerful language and a pair of configuration files that allow you to specify whether incoming connections should be accepted.

If TCP Wrappers is compiled with the -DPROCESS_OPTIONS flag, then each line of the /etc/hosts.allow and /etc/hosts.deny files have the following format:

Alternatively, if TCP Wrappers is compiled without the -DPROCESS_OPTIONS flag, then each line in the /etc/hosts.allow and /etc/hosts.deny files has the following format:^[10]

Theoretically the TCP Wrappers are vulnerable to IP spoofing because it uses IP addresses for authentication. In practice, this is not a significant concern, because TCP protocols as a rule require bidirectional communications to do anything useful. Furthermore, most TCP/IP implementations now use unpredictable sequence numbers, significantly reducing the chances of a successful spoofing attack.

TCP Wrappers also provides only limited support for UDP servers, because once the server is launched, it will continue to accept packets over the network, even if those packets come from "blocked" hosts, unless the UDP server is linked with the TCP Wrappers library and has been specially written to consult the TCP Wrappers access control lists after each new request is received.

Making sense of your TCP Wrappers configuration files

Syntax for the "hosts" field in the tcpwrappers /etc/hosts.allow and /etc/hosts.deny files
Hostname as it appears in the /etc/hosts.allow or /etc/hosts.deny file	Has the following effect
ALL	Matches all hosts.
KNOWN	Matches any IP address that has a corresponding hostname; also matches usernames when the ident service is available.
LOCAL	Matches any host that does not have a period (.) in its name.
PARANOID	Matches any host for which double reverse-hostname/IP address translation does not match.
UNKNOWN	Matches any IP address that does not have a corresponding hostname; also matches usernames when the ident service is not available.
host.domainhost.subdomain	Matches the specific hostname.
.subdomain.domain	If the hostname begins with a period (.), the hostname will match any host whose hostname ends with the hostname (in this case, ".subdomain.domain").
111.222.333.444	Matches the specific IP address 111.222.333.444, for example 10.1.1.1
kkk.lll.mmm. kkk.lll. kkk.	If the hostname ends with a period (.), the hostname is interpreted as the beginning of an IP address. The string "18." will match any host with an IP address of 18.0.0.1 through 18.255.255.254. The string "192.168.1." will match any host with an IP address of 192.168.1.0 through 192.168.1.255.
a pattern EXCEPT another pattern	Matches any host that is matched by a pattern except those that also match another pattern.

Options available for TCP Wrappers when compiled with -DPROCESS_OPTIONS
Option	Effect
allow	Allows the connection.
deny	Denies the connection.
Options for dealing with sub-shells
nice `±nn`	Changes the priority of the process to `±nn`. Use numbers such as +4 or +8 to reduce the amount of CPU time allocated to network services.
setenv `name value`	Sets the environment variable `name` to `value` for the daemon.
spawn `shell_command`	Runs the `shell_command`. The streams stdin, stdout, and stderr are connected to /dev/null to avoid conflict with any communications with the client.
twist `shell_command`	Runs the `shell_command`. The streams stdin, stdout, and stderr are connected to the remote client. This allows you to run a server process other than the one specified in the file /etc/inetd.conf. (Note: this will not work with most UDP services.)
umask `nnn`	Specifies the `umask` that should be used for sub-shells. Specify it in octal.
user `username`	Assumes the privileges of `username`. (Note: TCP Wrappers must be running as root for this option to work.)
user `username.groupname`	Assumes the privileges of `username` and sets the current group to be `groupname`.
Options for dealing with the network connection
banners `/some/directory/`	Specifies a directory that contains banner files. If a filename is found in the banner directory that has the same name as the network server (such as telnetd), the contents of the banner file are sent to the client before the TCP connection is turned over to the server. This process allows you to send clients messages—for example, informing them that unauthorized use of your computer is prohibited.
keepalive	Causes the Unix kernel to periodically send a message to a client process; if the message cannot be sent, the connection is automatically broken.
linger `seconds`	Specifies how long the Unix kernel should spend trying to send a message to the remote client after the server closes the connection.
rfc931 `[timeout in seconds]`	Specifies that the ident protocol should be used to attempt to determine the username of the person running the client program on the remote computer. The `timeout`, if specified, is the number of seconds that TCP Wrappers should spend waiting for this information.

Token expansion available for the TCP Wrappers shell command
Token	Mnemonic	Expands to
`%a`	Address	The IP address of the client
`%A`	Address	The IP address of the server (useful if the server system has more than one network interface)
`%c`	Client info	username@hostname (if username is available); otherwise, only hostname or IP address
`%d`	Daemon name	The name of the daemon (argv[0])
`%h`	Hostname	The hostname of the client (IP address if hostname is unavailable)
`%H`	Hostname	The hostname of the server (IP address if hostname is unavailable)
`%p`	Process	The process ID of the daemon process
`%s`	Server info	daemon@host
`%u`	User	The client username (or unknown)
`%%`	Percent	Expands to the "%" character

The configuration files we have shown so far are simple; unfortunately, sometimes things get more complicated. The TCP Wrappers system comes with a utility called tcpdchk that can scan through your configuration file and report on a wide variety of potential configuration errors. This is important because the TCP Wrappers system relies on many configuration files (/etc/services, /etc/inetd.conf, /etc/hosts.allow, and /etc/hosts.deny) and requires that the information between these files be consistent.

Here is an example of using the tcpdchk program; each line in this example represents a potential security problem:

The first line of output refers us to line 24 of the file /etc/hosts.allow, which is shown here:

To understand the error no such process name in /etc/inetd.conf, we need to now refer to the file /etc/inetd.conf. This file has a line for the ipop3d daemon, but as the warning from tcpdchk implies, the process is not named ipop3d—it is named popper:

We must either change line 24 to refer to the process name popper, or change the entry in /etc/inetd.conf to use the name ipop3d. We'll change the file /etc/hosts.allow and rerun the tcpdchk program. Here is the new line 24:

We are now told that the service is "possibly not wrapped." This is because tcpdchk is reading through the /etc/inetd.conf file and looking for "tcpd," the name of the TCP Wrappers executable. Because support for TCP Wrappers is compiled into the version of inetd that this computer is using, tcpd is not used, so tcpdchk reports a warning (which we ignore).

The second warning is that there is a rule in the /etc/hosts.allow file for the sshd service, but there is no matching daemon listed in the /etc/inetd.conf file. This is actually not an error: the sshd service is started up directly at boot time, not by inetd. Nevertheless, the program is linked with the TCP Wrappers library and honors the commands in the /etc/hosts.allow file.

The TCP Wrappers system comes with another utility program called tcpdmatch, which allows you to simulate an incoming connection and determine if the connection would be permitted or blocked with your current configuration files. In the following example, we will see if the user simsong@k1.vineyard.net is allowed to ssh into our machine:

Ignoring the warning in the first line, we can see that permission would be granted by line 39 of the /etc/hosts.allow file. This line reads:

Programs such as tcpdchk and tcpdmatch are excellent complements to the security program TCP Wrappers because they help you head off security problems before they happen. Wietse Venema should be complimented for writing and including them in his TCP Wrappers release; other programmers should follow his example.

Before answering this question, let's first provide a little background. TCP Wrappers has been around for many, many years. It is used to restrict access to TCP services based on host name, IP address, network address, etc. For more detailed on what TCP Wrappers is and how you can use it, see tcpd(1M). TCP Wrappers was integrated into Solaris starting in Solaris 9 where both Solaris Secure Shell and inetd-based (streams, nowait) services were wrapped. Bonus points are awarded to anyone who knows why UDP services are not wrapped by default.

TCP Wrappers support in Secure Shell was always enabled since Secure Shell always called the TCP Wrapper function host_access(3) to determine if a connection attempt should proceed. If TCP Wrappers was not configured on that system, access, by default, would be granted. Otherwise, the rules as defined in the hosts.allow and hosts.deny files would apply. For more information on these files, see hosts_access(4). Note that this and all of the TCP Wrappers manual pages a stored under /usr/sfw/man in Solaris 10. To view this manual page, you can use the following command:

$ man -M /usr/sfw/man -s 4 hosts_access

inetd-based services use TCP Wrappers in a different way. In Solaris 9, to enable TCP Wrappers for inetd-based services, you must edit the /etc/default/inetd file and set the ENABLE_TCPWRAPPERS parameter to YES. By default, TCP Wrappers was not enabled for inetd.

New usage of TCP Wrappers in Solaris 10

To enable TCP Wrappers support for inetd-based services:

# inetadm -M tcp_wrappers=true

# svcadm refresh inetd

This will enable TCP Wrappers for inetd-based (streams, nowait) services like telnet, rlogin, and ftp (for example):

# inetadm -l telnet | grep tcp_wrappersdefault tcp_wrappers=TRUE

You can see that this setting has taken effect for inetd by running the following command:

# svcprop -p defaults inetd

defaults/tcp_wrappers boolean true

Note that you can also use the svccfg(1M) command to enable TCP Wrappers for inetd-based services.

# svccfg -s inetd setprop defaults/tcp_wrappers=true

# svcadm refresh inetd

Whether you use inetadm(1M) or svccfg is really a matter of preference. Note that you can also use inetadm or svccfg to enable TCP Wrappers on a per-service basis. For example, let's say that we wanted to enable TCP Wrappers for telnet but not for ftp. By default, both the global and per-service settings for TCP Wrappers are disabled:

# inetadm -p | grep tcp_wrappers

tcp_wrappers=FALSE



# inetadm -l telnet | grep tcp_wrappers

default tcp_wrappers=FALSE



# inetadm -l ftp | grep tcp_wrappers

default tcp_wrappers=FALSE

To enable TCP Wrappers for telnet, use the following command:

# inetadm -m telnet tcp_wrappers=TRUE

Let's check out settings again:

# inetadm -p | grep tcp_wrappers

tcp_wrappers=FALSE



# inetadm -l telnet | grep tcp_wrappers

tcp_wrappers=TRUE



# inetadm -l ftp | grep tcp_wrappers

default tcp_wrappers=FALSE

As you can see, TCP Wrappers has been enabled for telnet but none of the other inetd-based services. Pretty cool, eh?

You can enable TCP Wrappers support for rpcbind by running the following command:

# svccfg -s rpc/bind setprop config/enable_tcpwrappers=true

# svcadm refresh rpc/bind

This change can be verified by running:

# svcprop -p config/enable_tcpwrappers rpc/bind

true

Old News ;-)

Before answering this question, let's first provide a little background. TCP Wrappers has been around for many, many years. It is used to restrict access to TCP services based on host name, IP address, network address, etc. For more detailed on what TCP Wrappers is and how you can use it, see tcpd(1M). TCP Wrappers was integrated into Solaris starting in Solaris 9 where both Solaris Secure Shell and inetd-based (streams, nowait) services were wrapped. Bonus points are awarded to anyone who knows why UDP services are not wrapped by default.

TCP Wrappers support in Secure Shell was always enabled since Secure Shell always called the TCP Wrapper function host_access(3) to determine if a connection attempt should proceed. If TCP Wrappers was not configured on that system, access, by default, would be granted. Otherwise, the rules as defined in the hosts.allow and hosts.deny files would apply. For more information on these files, see hosts_access(4). Note that this and all of the TCP Wrappers manual pages a stored under /usr/sfw/man in Solaris 10. To view this manual page, you can use the following command:
$ man -M /usr/sfw/man -s 4 hosts_access
inetd-based services use TCP Wrappers in a different way. In Solaris 9, to enable TCP Wrappers for inetd-based services, you must edit the /etc/default/inetd file and set the ENABLE_TCPWRAPPERSparameter to YES. By default, TCP Wrappers was not enabled for inetd.

In Solaris 10, two new services were wrapped: sendmail and rpcbind. sendmail works in a way similar to Secure Shell. It always calls the host_access function and therefore TCP Wrappers support is always enabled. Nothing else needs to be done to enable TCP Wrappers support for that service. On the other hand, TCP Wrappers support for rpcbind must be enabled manually using the new Service Management Framework ("SMF"). Similarly, inetd was modified to use a SMF property to control whether TCP Wrappers is enabled for inetd-based services.

Let's look at how to enable TCP Wrappers for inetd and rpcbind...

To enable TCP Wrappers support for inetd-based services, you can simply use the following commands:
# inetadm -M tcp_wrappers=true
# svcadm refresh inetd
This will enable TCP Wrappers for inetd-based (streams, nowait) services like telnet, rlogin, and ftp (for example):
# inetadm -l telnet | grep tcp_wrappers
default  tcp_wrappers=TRUE
You can see that this setting has taken effect for inetd by running the following command:
# svcprop -p defaults inetd
defaults/tcp_wrappers boolean true
Note that you can also use the svccfg(1M) command to enable TCP Wrappers for inetd-based services.
# svccfg -s inetd setprop defaults/tcp_wrappers=true
# svcadm refresh inetd
Whether you use inetadm(1M) or svccfg is really a matter of preference. Note that you can also use inetadm or svccfg to enable TCP Wrappers on a per-service basis. For example, let's say that we wanted to enable TCP Wrappers for telnet but not for ftp. By default, both the global and per-service settings for TCP Wrappers are disabled:
# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
default  tcp_wrappers=FALSE

# inetadm -l ftp | grep tcp_wrappers
default  tcp_wrappers=FALSE
To enable TCP Wrappers for telnet, use the following command:
# inetadm -m telnet tcp_wrappers=TRUE
Let's check out settings again:
# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
         tcp_wrappers=TRUE

# inetadm -l ftp | grep tcp_wrappers
default  tcp_wrappers=FALSE
As you can see, TCP Wrappers has been enabled for telnet but none of the other inetd-based services. Pretty cool, eh?

You can enable TCP Wrappers support for rpcbind by running the following command:
# svccfg -s rpc/bind setprop config/enable_tcpwrappers=true
# svcadm refresh rpc/bind
This change can be verified by running:
# svcprop -p config/enable_tcpwrappers rpc/bind
true
That is all that there is to it! Quick, easy and painless! As always, let me know what you think!

Take care!

Technorati Tag: OpenSolaris Solaris security

Apr 06 2005, 04:30:38 PM EDT Permalink

3 Comments

Trackback URL: http://blogs.sun.com/roller/trackback/gbrunett/Weblog/tcp_wrappers_on_solaris_10

Comments:

Just wondering if using IP filter would not be a better way of blocking/allowing machines to connect to services? I used to use TCP Wrappers all the time, but find now, that I rarely use them in favor of using ipfilter? Is there some advantage to using both? Just curious....
Posted by Jason Grove on April 07, 2005 at 11:58 PM EDT #

Jason,
Thank you for your question. In my opinion, I agree with you - I too would rarely use TCP Wrappers in favor of IP Filter. The reasons for this are simple - IP Filter simply has a more rich feature set and offers greater flexibility for defining filtering policy. Further, if you use Solaris containers, keep in mind that the IP Filter policy is defined in the global zone (versus TCP Wrappers which is done per container). The benefit of configuring IP Filter from the global zone is that if a local zone is breached, an attacker (even with root privileges) will not be able to alter the firewall policy or touch the firewall logs since they are safely protected in the global zone.

That said, TCP Wrappers was designed to protect TCP services and it does that very well. Further it offers an easy to understand and use interface for configuring policy. The choice to use IP Filter or TCP Wrappers will likely depend on your experience and comfort level with these tools as well as on your filtering requirements. If you are looking for a more comprehensive host-based firewall solution however, I would certainly recommend IP Filter.

Thanks again!

Glenn

Posted by Glenn Brunette (192.18.128.12) on April 08, 2005 at 01:17 PM EDT
Website: http://blogs.sun.com/gbrunett/ #

Nice article. To answer the bonus question, the UDP services are not wrappered because they are stateless so there is no connection to manage. As the first comment said, IP filter can manage services, including UDP, because it is low enough in the protocol stack to cover both UDP and TCP.
Posted by Ben Strother on August 17, 2005 at 08:20 PM EDT
Website: http://www.livejournal.com/~wr4th/ #

`STYLE = -DPROCESS_OPTIONS`:	Enable language extensions. This is disabled by default.
`FACILITY = LOG_MAIL`:	Where do log records go? I prefer to set this to `LOG_DAEMON` so that everything goes to `/var/log/daemon`.
`SEVERITY = LOG_INFO`:	Indicates what level to give to the log message. The default, `LOG_INFO`, is fine.
`HOSTS_ACCESS`:	When compiled with this option, wrapper programs support a simple form of access control. Because this is the raison d'être of the suite, it's defined by default.
`PARANOID`:	When compiled with `-DPARANOID`, wrappers will always try to look up and double-check the client hostname, and will always refuse service in the case of a discrepancy between hostname and IP address. This is a reasonable policy for most systems. When compiled without `-DPARANOID`, wrappers still perform hostname lookup; however, where such lookups give conflicting results for hostname and IP address, hosts are not automatically rejected. They can be matched with the `PARANOID` wildcard in the access files, and a decision is made on whether or not to grant access.
`DOT = -DAPPEND_DOT`:	This appends a dot to every domain name -- transforming `example.com` into `example.com.` for instance. This is done because on many Unix systems the resolver will append substrings of the local domain and try to look up those hostnames before trying to resolve the name it has actually been given. Use of the `APPEND_DOT` feature stops this waste of time and resources. It is off by default.
`AUTH = -DALWAYS_RFC931`:	Will cause the system to always try to look up the remote username. For this to be of any use, the remote host must run a daemon that supports the finger protocol. Such lookups aren't possible for UDP-based connections. By default, this is turned off and the wrappers look up the remote username only when the access control rules specify such behavior.
`RFC931_TIMEOUT = 10`:	Sets the username lookup timeout.
`-DDAEMON_UMASK = 022`:	This is the default file permissions mask for processes run under the control of the wrappers.
`ACCESS = -DHOSTS_ACCESS`:	Sets host access control. This feature can also be turned off at runtime by providing no, or empty, access control tables. Enabled by default.
`TABLES = -DHOSTS_DENY=\"/etc/hosts.deny\" --DHOSTS_ALLOW=\"/etc/hosts.allow\"`:	Sets the pathnames for the access control tables.
`HOSTNAME = -DALWAYS_HOSTNAME`:	Sets the system to always attempt to look up the client hostname. If this is disabled, the client hostname lookup is postponed until the name is required by an access control rule or by a `%letter` expansion. If this is what you want, note that `PARANOID` mode must be disabled as well. This is on by default.
`-DKILL_IP_OPTIONS`:	This is for protection against hosts that pretend they have someone else's host address --i.e., host address spoofing. This option isn't needed on modern Unix systems that can stop source-routed traffic in the kernel -- e.g., Linux, Solaris 2.x, 4.4 BSD and derivatives.
`-DNETGROUP`:	Determines whether or not your system has NIS support. This is used only in conjunction with host access control, so if you're not using that, don't bother about this in any case. Off by default.

`%a`	The client IP address
`%c`	Client information: user@host, user@IP, etc
`%d`	`argv[0]` from the daemon process
`%h`	Client host name or IP address
`%n`	Client host name
`%p`	Process id of the daemon
`%s`	Server information
`%u`	Client username
`%%`	Literal `%`

TCP Wrappers

Intetd "superdaemon"

A sample inetd.conf file

The idea of TCP Wrappers as controlling layer for Inetd

What TCP Wrappers does

The TCP Wrappers configuration language

Syntax for the "hosts" field in the tcpwrappers /etc/hosts.allow and /etc/hosts.deny files

Options available for TCP Wrappers when compiled with -DPROCESS_OPTIONS

Token expansion available for the TCP Wrappers shell command

Making sense of your TCP Wrappers configuration files

New usage of TCP Wrappers in Solaris 10

Old News ;-)

Securing your network: An introduction to TCP wrappers By Paul Dunne

Linux.com TCP Wrappers for Security - May 27th, 1999 by Michael J. Wise

Recommended Links

[Jun 4, 2006] Glenn Brunette's Security Weblog/ Enabling TCP Wrappers on Solaris 10

TCP Wrappers and xinetd

Network monitoring, access control & booby traps using TCP Wrappers Part 1

[Jan 7, 2005] BigAdmin - Submitted Tech Tip Enabling TCP Wrappers in the Solaris 10 Operating System Glenn Brunette, April, 2005

Installing, configuring, and using tcp wrapper to log unauthorized connection attempts on systems running Solaris 2.x

Installing TCP Wrappers on Solaris 7

[Sep 7, 2004 ] BigAdmin - Submitted Tech Tip Configuring TCP Wrappers for the Solaris Operating System

Solaris 9 SSH already has libwrap support compiled on. In S10 and later rpcbind is linked with libwrap so TCP Wrapper style controls are available for all RPC-based protocols (NIS, NFS etc)