Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

TCP Wrappers

News	Lecture Notes	Recommended Books	Recommended Links	Configuration	inetd services	Xinetd
tcpdchk	tcpdmatch	The try-from Utility	safe_finger	Loggings	Humor	Etc

From Nikolai Bezroukov's Lecture Notes (Partially based on O'Reilly Practical Unix Security book)

TCP wrappers is a classic security tool available on most flavors of Unix including AIX, HP-UX, Linux and Solaris). Sadly despite being a classic tool it is extremely underutilized and widely misunderstood tool. few people know that TCP wrappers represents (for TCP-based protocols only) an lightweight alternative to firewall (which is actually a heavyweight, obtuse and CPU intensive tool). Some capabilities of TCP wrappers cannot be emulated using firewall.

Wikipedia describes TCP wrappers in the following way:

TCP Wrapper is a host-based Networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) operating systems such as Linux or BSD. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes.
The original code was written by Wietse Venema at the Eindhoven University of Technology, The Netherlands, between 1990 and 1995. As of June 1, 2001 the program is released under its own BSD-style license.

The tarball includes a library named libwrap that implements the actual functionality. Initially, only services that were spawned for each connection from a super-server (such as inetd) got wrapped, utilizing the tcpd program. However most common network service daemons today can be linked against libwrap directly. This is used by daemons that operate without being spawned from a super-server, or when a single process handles multiple connections. Otherwise, only the first connection attempt would get checked against its ACLs.

When compared to host access control directives often found in daemons' configuration files, TCP Wrappers have the benefit of runtime ACL reconfiguration (i.e. services don't have to be reloaded or restarted) and a generic approach to network administration.

This makes it easy to use for anti-Worm scripts, such as BlockHosts, DenyHosts or Fail2ban, to add and expire client-blocking rules, when excessive connections and/or many failed login attempts are encountered.

While originally written to protect TCP and UDP accepting services, examples of usage to filter on certain ICMP packets (such as 'pingd' – the userspace ping request responder) exist too

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. Initially TCP_wrappers were used to "wrap" itself around TCP-based services defined in inetd.conf. But now many non-inetd services like ssh, sendmail and portmap are compiled with libwrap library which provides TCP Wrappers functionality.I

Standalone implementation of TCP Wrappers is a single program called "tcpd". The behavior of the program is controlled by two 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. One such implementation of inetd is xinetd.

Tcp_wrappers can 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 DNS, 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. For example:

telnet stream tcp nowait root in.telnetd in.telnetd

With TCP wrappers installed the only difference that you call wrapper first with the service as a parameter:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

In this case the new connection has to first go through the logging and access control mechanisms enforced by tcp_wrappers before it is allowed to proceed to actual daemon. As you can see it's natural to integrate TCP wrappers into inetd and many OSes (Linux, Solaris 10) are using such vatinat of inter (called xinetd) by default.

Tcp_wrappers is an excellent security tool with functionality more convenient, in some respects more powerful and less intrusive than a regular firewall:

you can use the improved access logging facility provided by tcp_wrappers even for services (such as rlogin) which traditionally do not have a good logging mechanism. These logs are extremely useful in tracking unauthorized break-ins.
You can have fine-grained control over who can and cannot access Unix boxes that belong to "critical infrastructure". Access control can be enforced differently for each wrapped service. For example, you can limit Telnet access to a specific subnet but allow wide open access for FTP (with improved logging).

To determine if a client machine is allowed to connect to a service, TCP wrappers reference the following two files, which are commonly referred to as hosts access files:

/etc/hosts.allow
/etc/hosts.deny

If you only want trusted networks/machine to be able to start telnet, you add them into hosts.allow and turn off everyone else with hosts.deny. (There's quite an interesting article about TCPwrappers in the August 1997 edition of Linux Journal Wrap a Security Blanket Around Your Computer )

You can also limit users to ftp with the /etc/ftpusers file. As for the shut down, I usually set up a shutdown group and set up scripts to to call shutdown for the members.

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.

Package content

Sun Feb 24 21:38:16 2008 422 etc/defaults/etc/hosts.allow Sun Feb 24 21:38:16 2008 225 etc/defaults/etc/hosts.deny Sun Feb 24 21:38:17 2008 164 etc/postinstall/tcp_wrappers.sh Sun Feb 24 21:38:17 2008 365 etc/preremove/tcp_wrappers.sh Sun Feb 24 21:38:19 2008 6656 usr/sbin/safe_finger.exe Sun Feb 24 21:38:19 2008 5120 usr/sbin/tcpd.exe Sun Feb 24 21:38:19 2008 15872 usr/sbin/tcpdchk.exe Sun Feb 24 21:38:19 2008 13312 usr/sbin/tcpdmatch.exe Sun Feb 24 21:38:20 2008 5120 usr/sbin/try-from.exe Sun Feb 24 21:38:16 2008 1736 usr/share/doc/tcp_wrappers-7.6/BLURB Sun Feb 24 21:38:16 2008 19195 usr/share/doc/tcp_wrappers-7.6/CHANGES Sun Feb 24 21:38:16 2008 792 usr/share/doc/tcp_wrappers-7.6/DISCLAIMER Sun Feb 24 21:38:17 2008 48215 usr/share/doc/tcp_wrappers-7.6/README Sun Feb 24 21:38:16 2008 2002 usr/share/doc/tcp_wrappers-7.6/README.Debian Sun Feb 24 21:38:16 2008 2634 usr/share/doc/tcp_wrappers-7.6/README.IRIX Sun Feb 24 21:38:16 2008 6680 usr/share/doc/tcp_wrappers-7.6/README.NIS Sun Feb 24 21:38:17 2008 0 usr/share/doc/Cygwin/ Sun Feb 24 21:38:17 2008 4646 usr/share/doc/Cygwin/tcp_wrappers-7.6.README Sun Feb 24 21:38:17 2008 0 usr/share/man/man5/ Sun Feb 24 21:38:15 2008 6362 usr/share/man/man5/hosts_access.5.gz Sun Feb 24 21:38:15 2008 3054 usr/share/man/man5/hosts_options.5.gz Sun Feb 24 21:38:18 2008 0 usr/share/man/man8/ Sun Feb 24 21:38:15 2008 652 usr/share/man/man8/safe_finger.8.gz Sun Feb 24 21:38:15 2008 3042 usr/share/man/man8/tcpd.8.gz Sun Feb 24 21:38:15 2008 1171 usr/share/man/man8/tcpdchk.8.gz Sun Feb 24 21:38:15 2008 1415 usr/share/man/man8/tcpdmatch.8.gz Sun Feb 24 21:38:15 2008 465 usr/share/man/man8/try-from.8.gz

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:

It opens the /etc/hosts.allow file. This file contains access control rules and actions for each protocol.
It scans through the file, line by line, until it finds a rule that matches the particular protocol and source host that has connected to the server.
It executes the action(s) specified in the rule. If appropriate, control is then turned over to the network server.
If no matching action is found, the file /etc/hosts.deny is opened and sequentially read line by line. If a matching line is found, access is denied and the corresponding action performed.
If no match is found in either the /etc/hosts.allow or the /etc/hosts.deny file, then the connection is allowed by default.

The complexity of having two two files can be lessened by using mainly /etc/hosts.allow .

Your /etc/hosts.deny can contain only a single rule "ALL:ALL" to deny all access by default. Keeping all the rules in a single file simplifies maintenance. Using /etc/hosts.allow, which has priority over /etc/hosts.deny, ensures that if someone else accidentally modifies the wrong file, it won't override your rules.

The actions implemented by TCP Wrappers are quite sophisticated:

Compare the incoming hostname and requested service with an access control list to see if this host or this combination of host and service has been explicitly denied. If either is denied, TCP Wrappers drops the connection.
Log the results with syslog.
Use the ident protocol (RFC 1413) to determine the username associated with the incoming connection. RFC 1413 superseded RFC 931, but the define in the code has not changed.
Optionally send a "banner" to the connecting client. Banners are useful for displaying legal messages or advisories.
Optionally run an auxiliary command. (For example, you can have TCP Wrappers run finger to get a list of users on a computer that is trying to contact yours.)
Perform a double reverse lookup of the IP address, making sure that the DNS entries for the IP address and hostname match. If they do not, this fact is logged. (By default, TCP Wrappers is compiled with the -DPARANOID option, so the program will automatically drop the incoming connection if the two do not match under the assumption that something somewhere is being hacked.)
Pass control of the connection to the "real" network daemon, or pass control to some other program that can take further action.

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.

Notes:

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Google Search
Open directory	Research Index

Old News ;-)

Glenn Brunette's Security Weblog Enabling TCP Wrappers on Solaris 10

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!

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 wrapable 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/ #

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

Compilation
Many Unix flavors are supported by TCP wrappers, so you shouldn't have any trouble building from source. There are, however, a few decisions to make at compile time. Features, for example, can be turned on or off through definitions. Here is a list, with default values shown where appropriate:

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

Some definitions are given that work around system bugs (just the basics here; see makefile for details). The standard define is BUGS = -DGETPEERNAME_BUG -DBROKEN_FGETS - DLIBC_CALLS_STRTOK.

Having set the options to your requirements, type make sys-type, with sys-type being one of the following:

generic (includes most bsd-ish systems that have sys5 compatibility)


		386bsd 
		aix 
		freebsd 
		hpux 
		linux 
		machten 
		mips<(untested) 
		ncrsvr4 
		netbsd 
		next 
		osf 
		power_unix_211 
		ptx-2.x 
		ptx-generic 
		pyramid 
		sco 
		sco-nis 
		sco-od2 
		sco-os5 
		sinix 
		sunos4 
		sunos40 
		sunos5 
		sysv4 
		tandem 
		ultrix 
		unicos7 
		unicos8 
		unixware1 
		unixware2 
		uts215

uxp

In the unlikely event that none of these match your system, you'll have to edit the system dependencies sections in the makefile and do a make other.

There are two ways to install the software -- the easy way and the advanced way.

... ... ...

And here is the same record after modification to support TCP wrappers:

telnet     stream  tcp     nowait  root    /sbin/tcpd          /sbin/in.telnetd

After editing this file, remember to tell inetd to reread it with kill -1.

Access control
The core idea behind TCP wrappers is that of an access control policy. The policy rules are held in two files: /etc/hosts.allow and etc/hosts.deny. These are the default pathnames, which can be changed in the makefile.

Access can be controlled per host, per service, or in combinations thereof. Access control can also be used to connect clients to particular services, depending on the requested service, the origin of the request, and the host address to which the client connects. For example, a www daemon might be set to serve documents in French when contacted from within the France, but otherwise respond in English.

The format of these files is described in detail by hosts_access(5). Basically, each file consists of a set of rules, which are searched for first in hosts.allow and then hosts.deny. The search stops at the first match, so if a host is granted access in host.allow it doesn't matter if it's then blocked in hosts.deny. Remember, the first rule matched determines what action the system will take.

There are two basic keywords, allow and deny. Both are used in conjunction with either specific hostnames or a wildcard from the list below.

A string beginning with . matches all hostnames that conclude with that string. For example, .example.com would match dunne.example.com. A string ending with . matches all hosts whose IP addresses begin with that sequence. For example, 192.168. would match all addresses in the range 192.168.xxx.xxx. A string beginning with @ is treated as an NIS netgroup name. A string of the formn.n.n.n/m.m.m.m is treated as a network/mask pair.

There are also some special shorthand names:

ALL: Always matches
LOCAL: Matches any host whose name doesn't contain a dot character
UNKNOWN: Matches a user whose name is unknown, and matches any host whose name or address is unknown
KNOWN: Matches a user whose name is known, and matches any host whose name and address is known
PARANOID: Matches any host whose name doesn't match its address

There is also a set of symbolic names that expand to various information about the client and server. The full list of such expansions is shown in the table below.

**Symbolic names**
`%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 `%`

Examples

There are several typical forms of access control that provide examples of using the access control files. Explicitly authorized hosts are listed in hosts.allow, while most other rules are put in hosts.deny.

To deny all access, leave hosts.allow blank and put this in hosts.deny.

/etc/hosts.deny:
ALL: ALL

To allow all access, simply leave both files blank. To allow controlled access, add rules to hosts.allow and hosts.deny as appropriate. The simplest way to do this is to list banned sites in hosts.deny.

/etc/hosts.deny:
evilcrackers.com: ALL

On the other hand, you can also deny access to all save selected sites:

/etc/hosts.allow:
example.com: ALL
/etc/hosts.deny:
ALL:ALL

Remember, the first match is the important one -- the ALL in hosts.deny won't block example.com.

Booby traps
A useful feature is the ability to trigger actions on the host which are based on attempted connections. For example, should you detect a remote site attempting to use your TFTP server, the following rule in /etc/hosts.deny not only rejects the attempt, but notifies the system administrator:

in.tftpd: ALL: finger -l @%h 2>&1 | mail -s 'remote tftp attempt' sysadm

Note that use of this feature relies on the PROCESS_OPTIONS option. This option also provides some other useful features:

spawn <shell_command> -- Run the specified shell command as a child process.
twist <shell_command> -- Replace the current process by the specified shell command.
banners <pathname> -- Copy the contents of the file in <pathname> to the client. This is useful for sites that are required to display a site policy banner to all users.

See the host_options(5) man page for full details of these and other options.

Logging
Log records are written to the syslog daemon, syslogd, with facility and level as specified in the makefile at compile time. What happens to the logs there is determined by the syslogd config file, /etc/syslog.conf. If PROCESS_OPTIONS has been defined, the facility and level can be changed at runtime, using the keyword severity. For example severity mail.info specifies logging with facility mail at level info. An undotted argument is understood as a level.

... ... ...

A good account of the thinking that led to the creation of the TCP wrappers is the paper "TCP Wrapper: Network Monitoring, Access Control, and Booby Traps," which is available from the same FTP site as the TCP wrappers software. Look for tcp_wrapper.<format>.Z.

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

[****] Linux Security 101 Issue 14 By Kelley Spoon, mars@loeffel.txdirect.net -- very good discussion of tcpd

There's a daemon that's probably been installed on your machine that you don't know about. Or at least, you're not aware of what it can do. It's called tcpd, and it's how we shut off access to some of the basic services that the Bad Guys can use to get on our system.

Since tcpd can be pretty complex, I'm not going to go into all the details and tell you how to do the fancy stuff. The goal here is to keep the mischievous gibbons from knocking down what it took so long for use to set up.

tcpd is called into action from another daemon, inetd, whenever someone tries to access a service like in.telnetd, wu.ftpd, in.fingerd, in.rshd, etc. tcpd's job is to look at two files and determine if the person who is trying to access the service has permission or not.

The files are /etc/hosts.allow and /etc/hosts.deny. Here's how it all works:

Someone tries to use a service that tcpd is monitoring.

tcpd wakes up, and makes a note of the attempt to the syslog.

tcpd then looks hosts.allow

if it finds a match, tcpd goes back to sleep and lets the user access the service.

tcpd now takes a look at hosts.deny

if it finds a match, tcpd closes the user's connection

If it can't find a match in either file, or if both files are empty, tcpd shrugs, guesses it's OK to let the user on, and goes back to sleep.

Now, there are a couple of things to note here. First, if you haven't edited hosts.allow or hosts.deny since you installed Linux, then tcpd assumes that you want to let everyone have access to your machine. The second thing to note is that if tcpd finds a match in hosts.allow, it stops looking. In other words, we can put an entry in hosts.deny and deny access to all services from all machines, and then list ``friendly'' machines in the hosts.allow file.

Let's take a look at the man page. You'll find the info you need by typing man 5 hosts_access (don't forget the 5 and the underscore).
       daemon_list : client_list

       daemon_list is a list of one or more daemon process  names
         or wildcards

       client_list  is  a  list  of  one or more host names, host
         addresses, patterns or wildcards  that will  be matched
         against the remote host name or address. 
       
       List elements should be separated by blanks and/or commas.
Now, if you go take a look at the man page, you'll notice that I didn't show you everything that was in there. The reason for that is because the extra option (the shell_command) can be used to do some neat stuff, but *most Linux distributions have not enabled the use of this option in their tcpd binaries*. We'll save how to do this for an article on tcpd itself.

If you absolutely have to have this option, get the source from here and recompile.

Back to business. What the above section from the hosts_access man page was trying to say is that the format of hosts.[allow|deny] is made up of a list of services and a list of host name patterns, separated by a ``:''

You'll find the name of the services you can use by looking in your /etc/inetd.conf...they'll be the ones with /usr/sbin/tcpd set as the server path.

The rules for determining host patterns are pretty simple, too:

if you want to match all hosts in a domain, put a ``.'' at the front.

Ex: .bar.com will match "foo.bar.com", "sailors.bar.com", "blue.oyster.bar.com", etc.

if you want to match all IPs in a domain, put a "." at the end.

Ex: 192.168.1. will match "192.168.1.1", "192.168.1.2", "192.168.1.3", etc.

And finally, there are some wildcards you can use:

ALL matches everything. If in daemon_list, matches all daemons; if in client_list, it matches all host names.

Ex: ALL : ALL would match any machine trying to get to any service.

LOCAL matches host names that don't have a dot in them.

Ex: ALL : LOCAL would match any machine that is inside the domain or search aliases given in your /etc/resolv.conf

except isn't really a wildcard, but it comes in useful. It excludes a pattern from the list.

Ex: ALL : ALL except .leetin-haxor.org would match all services to anyone who is not from ``*.leetin-haxor.org''

Ok. Enough technical stuff. Let's get to some examples.

Let's pretend we have a home LAN, and a computer for each member of the family.

Our home network looks like this:
    linux.home.net      192.168.1.1
    dad.home.net	192.168.1.2
    mom.home.net	192.168.1.3
    sis.home.net	192.168.1.4
    bro.home.net        192.168.1.5
Now, since no one in the family is likely to try and ``hack root,'' we can assume they're all friendly. But....we're not so sure about the rest of the people on the Internet. Here's how we go about setting things up so people on home.net have full access to our machine, but no one else does. In /etc/hosts.allow:
# /etc/hosts.allow for linux.home.net

ALL: .home.net
And in /etc/hosts.deny
# /etc/hosts.deny for linux.home.net

ALL : ALL
Since tcpd looks at hosts.allow first, we can safely deny access to all services for everybody. If tcpd can't match the machine sending the request to ``*.home.net'', the connection gets refused.

Now, let's pretend that Mom has been reading up on how Unix stuff works, and she's started doing some unfriendly stuff on our machine. In order to deny her access to our machine, we simply change the line in hosts.allow to:
ALL: .home.net except mom.home.net
Now, let's pretend a friend from....uh....friend.com wants to get something off our ftp server. No problem, just edit hosts.allow again:
# /etc/hosts.allow for linux.home.net

ALL: .home.net except mom.home.net
wu.ftpd: .friend.com
Things are looking good. The only problem is that the name server for home.net is sometimes down, and the only way we can identify someone as being on home.net is through their IP address. Not a problem:
# /etc/hosts.allow for linux.home.net

ALL: .home.net except mom.home.net
ALL: 192.168.1. except 192.168.1.3
ALL: .friend.com
And so on....

I have found that's it's easier to deny everybody access, and list your friends in hosts.allow than it is to allow everybody access, and deny only the people who you know are RBG's. If you are running a private machine, this won't really be a problem, and you can rest easy.

However, if you're trying to run a public service (like an ftp archive of Tetris games for different OS's) and you can't afford to be this paranoid, then you need shouldn't put anything in hosts.allow, and just put all of the people you don't want touching your machine in hosts.deny

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

Tip of the Month: Enabling TCP Wrappers in Solaris 10

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

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!

TCP Wrappers and xinetd

Controlling access to network services can be a challenge. Firewalls are useful for controlling access in and out of a particular network, but they can be difficult to configure. TCP wrappers and xinetd control access to services by hostname and IP addresses. In addition, these tools also include logging and utilization management capabilities that are easy to configure.
Purpose of TCP Wrappers
Many modern network services, such as SSH, Telnet, and FTP, make use of TCP wrappers, a program that is designed to stand between an incoming request and the requested service. TCP wrappers is installed by default with a server-class installation of Red Hat Linux, providing many advantages over running a variety of different services, each with their own access control methods.

The idea behind TCP wrappers is that, rather than allowing an incoming client connection to communicate directly with a network service daemon running as a separate process on a server system, the target of the request is "wrapped" by another program, allowing a greater degree of access control and logging of who is attempting to use the service.

The functionality behind TCP wrappers is provided by libwrap.a, a library that network services, such as xinetd, sshd, and portmap, are compiled against. Additional network services, even networking programs you may write, can be compiled again libwrap.a to provide this functionality. Red Hat Linux bundles the necessary TCP wrapper programs and library in the tcp_wrappers-<version> RPM file.
TCP Wrapper Advantages
When someone attempts to access a network service using TCP wrappers, a small wrapper program reports the name of the service requested and the client's host information. The wrapper program does not directly send any information back to the client, and after the access control directives are satisfied, the wrapper gets out of the way, not placing any additional overhead on the communication between the client and server.

TCP wrappers provide two basic advantages over other network service control techniques:

The connecting client is unaware that TCP wrappers are in use. Legitimate users will not notice anything different, and attackers never receive any additional information about why their attempted connections failed.

TCP wrappers operate in a manner that is separate from the applications the wrapper program protects. This allows many applications to share a common set of configuration files for simpler management.

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

By Trevor Warren <trevor@freeos.com>

This tool has been successfully used for shielding off systems and for detection of cracker activity. It has no impact on legal computer users, and does not require any change to existing systems software or configuration files. The tool has been installed world-wide on numerous UNIX systems without any source code change. Such is the beauty of TCP Wrappers.
Almost every application of the TCP/IP protocols is based on a client-server model. For example, when someone uses the telnet command to connect to a host, a telnet server process is started on the target host. The server process connects the user to a login process. A few examples are shown in table 1.

client server application
________________________________
telnet telnetd remote login
ftp ftpd file transfer
finger fingerd show users
systat systatd show users

Table 1. Examples of TCP/IP client-server pairs and
their applications.

The usual approach is to run one daemon process that waits for all kinds of incoming network connections. Whenever a connection is established this daemon (usually called inetd on our Linux boxes) runs the appropriate server program and goes back to sleep, waiting for other connections. See the example as illustrated below.

client server application
________________________________
telnet telnetd remote login
(foo1.bar) (foo2.bar)

We are on a client Linux box called foo1.bar and want to connect to a remote Linux box called foo2.bar which resides on a remote network. We then use the telnet client application from my box i.e foo1.bar to connect to the remote telnet server box foo2.bar. Have a look at the graphical illustrations as given below.
              -------------------      -----------------    -----------
foo1.bar---| client(ftp,telnet..) |---------| INETD server |--------| login |
            --------------------      -----------------    -----------
Figure 1. The inetd daemon process listens on the ftp,
telnet etc. network ports and waits for incoming con-
nections. The figure shows that a user has connected to
the ftp/telnet port.
            -----------------      -----------------    ---------
     user---| telnet client |--------| telnet server |--------| login |
            -----------------      -----------------    ---------
                   (foo1.bar)                           (foo2.bar) 
Figure 2. The inetd process has started a telnet
server process that connects the user to a login pro-
cess. Meanwhile, inetd waits for other incoming con-
nections. This illustrates an unprotected machine.
Fortunately, the author of TCP wrapper came up with a simple solution that did not require any change to existing software, and that turned out to work on all UNIX systems that were ever tried it on. The trick was to make a swap. Move the vendor-provided network server programs to another place, and install a trivial program in the original place of the network server programs. Whenever a connection was made, the trivial program would just record the name of the remote host, and then run the original network server program.
            -----------------      -----------------
     user---| telnet client |---------|  tcp wrapper  |----> logfile
            -----------------      -----------------
               (foo1.bar)                                (foo2.bar)
Figure 3. The original telnet server program has been
moved to some other place, and the tcp wrapper has tak-
en its place. The wrapper logs the name of the remote
host to a file. This illustrates a protected machine.
            -----------------      -----------------    ---------
     user---| telnet client |---------| telnet server |-------| login |
            -----------------      -----------------    ---------
                   (foo1.bar)                            (foo2.bar)
Figure 4. The tcp wrapper program has started the real
telnet server and no longer participates. The user can-
not notice any difference.
Lets look at the logs capable of being generated by our TCP wrapper application.

May 22 14:43:29 tuegate: systatd: connect from monk.rutgers.edu
May 22 15:08:30 tuegate: systatd: connect from monk.rutgers.edu
May 22 15:09:19 tuewse: fingerd: connect from monk.rutgers.edu
May 22 15:14:27 tuegate: telnetd: connect from cumbic.bmb.columbia.edu
May 22 15:23:06 tuegate: systatd: connect from cumbic.bmb.columbia.edu
May 22 15:23:56 tuewse: fingerd: connect from cumbic.bmb.columbia.edu

Some of the first cracker connections observed with the tcp wrapper program by the author. Each connection is recorded with: time stamp, the name of the local host, the name of the requested service (actually, the network server process name), and the name of the remote host.

Automatic reverse fingers had proven useful in the authors fight against the cracker, so he decided to integrate the "ad hoc" reverse finger tool with TCP Wrappers. To this end, the access control language was extended so that arbitrary shell commands could be specified.

/etc/hosts.allow:

in.tftpd: LOCAL, .foo.bar

/etc/hosts.deny:

in.tftpd: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail wswietse

This is an example of a booby trap on the tftp service. The entry in the first access control file says that tftp connections from hosts within its own domain are allowed. The entry in the second file causes the TCP Wrapper to perform a reverse finger in all other cases. The "%h" sequence is replaced by the actual remote host name. The result is sent to the administrator by email.

Our discussion till now gives only a limited illustration of the use of booby traps. Booby traps can be much more useful when installed on firewall systems, whose primary purpose is to separate an organizational network from the rest of the world. A typical firewall system provides only a limited collection of network services to the outer world. For example, telnet and smtp. By placing booby traps on the remaining network ports one can implement an effective early-warning system.

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

April, 2005 (BigAdmin)

First let's first provide a little background. TCP Wrappers has been around for many, many years (see Wietse Venema's FTP archive). It is used to restrict access to TCP services based on host name, IP address, network address, and so on. For more details on what TCP Wrappers is and how you can use it, see tcpd(1M). TCP Wrappers was integrated into the Solaris Operating System starting in the Solaris 9 release, 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 are stored under /usr/sfw/man in the Solaris 10 OS. 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 the Solaris 9 OS, 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.

In the Solaris 10 OS, 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 Facility (SMF). Similarly, inetd was modified to use a SMF property to control whether TCP Wrappers is enabled for inetd-based services.

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)

Commentor: Casper Dik
Added: September 7, 2004
Comment:

It is rather pointless to install TCP wrappers for Solaris 9 and later as the version included in the OS is exactly the same as the one available on porcupine. That version has also been reved twice because of bugs we ran into. Solaris 9 SSH already has libwrap support compiled on. In S10 and later we also provide rpcbind linked with libwrap.

The Linux Gazette 56 The Answer Gang (TWDT)

was looking at this issue:- http://tech.buffalostate.edu/LDP/LDP/LG/issue38/tag/32.html, and I did not understand your solution correctly.

Can you please let me know what I need to do in order for telnet to work without any pause?

I happen to see similar problem for FTP also.

Thanks Hari Koalsani
If you look at some of the other back issues (search on the string "tcpd" you can see that I've tried to explain the issue a few times and at great length.
Basically there are three ways to approach this:

Abandon telnet; use ssh instead.

Fix your reverse DNS zones. Make the PTR records consistent with the A (address/host) records.

Remove TCP Wrappers protection from the telnet service on this host. Change the line in the /etc/inetd.conf file that reads something like:
telnet	stream	tcp	nowait	telnetd.telnetd	/usr/sbin/tcpd	/usr/sbin/in.telnetd
to look more like:
telnet	stream	tcp	nowait	telnetd.telnetd	/usr/sbin/in.telnetd in.telnetd
Personally I suggest that you use both methods 1 and 2. Use ssh, which USUALLY doesn't use tcpd or libwrap, the library which implements tcpd access controls, AND fix your DNS zones so that your hosts have proper PTR records.

As I said, I've written many pages on this topic. I'm not going to re-hash it again. Hopefully this summary will get you on the right track. If you still can't understand what is going on and how to do this you should consider calling a tech support service (Linuxcare does offer single-incident tech support calls, though they are a bit expensive; there may be other companies still doing this), or hire a Linux consultant in your area (look in the Linux Consultants HOWTO http://www.linuxdoc.org/HOWTO/Consultants-HOWTO.html for one list of them).

They can provide hand holding services. A good consultant can and will show you how to handle these sorts of things for yourself, and will ask some questions regarding your needs, and recommend comprehensive solutions.

I would ask about why you are using telnet, who needs access to the system, what level and form of access they need, etc. I can simply answer questions, but a good consultant will ask more questions than he or she answers --- to make sure that you're getting the right answers. Given my constraints here, I don't have the luxury of doing in-depth requirements analysis for this column. (Also note that I'm not currently available for consulting contracts, Starshine Technical Services is currently in hiatus).

TCP Wrappers

Package content

What TCP Wrappers does

Old News ;-)

Glenn Brunette's Security Weblog Enabling TCP Wrappers on Solaris 10

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

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

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

The Linux Gazette 56 The Answer Gang (TWDT)

Recommended Links

Internal

External