Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

TCP Wrappers

News

 Lecture Notes Recommended Books Recommended Links Configuration inetd services
Xinetd ssh &TCP Wrappers Sendmail & TCP wrappers Postfix and TCP wrappers vsftpd & TCP Wrappers  
tcpdchk tcpdmatch The try-from Utility Loggings Humor Etc

Note:

This page was created from Dr. 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.

Very few sysadmins know that TCP wrappers represents (for TCP-based protocols only) a 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. To determine if a service uses TCP wrapper use command 

ldd <binary-name> | grep libwrap

For example:

# ldd /usr/sbin/vsftpd | grep libwrap
        libwrap.so.0 => /lib64/libwrap.so.0 (0x00007feff3fdd000)
# ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /lib64/libwrap.so.0 (0x00007fe2fae99000)
# ldd /usr/sbin/sendmail | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f174eb3d000)

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.

TCP wrapper can limit connections to specific domain (and if you include ion the rule only the first level domain like .com, .edu, etc this prohibits connecting from a host without DNS name):

.subdomain.domain If the hostname field in the rule begins with a period (.), then this hostname field will be matched against DNS name of client that tries to connect. For success the latter should have the stated subdomain and domain

Another very useful option is PARANOID which matches any host for which double reverse-hostname/IP address translation does not match.  

# Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny
When a client connects to such host, the IP address of the client is examined by TCP Wrappers. While IP addresses can be spoofed, and DNS can be hacked, this examination provides one step in a multi-layered security process to help reduce the number of malicious connections. The process works like this:
  1. The client IP address (eg: 128.59.59.134) is determined.
  2. The numerical address is examined to determine the hostname (eg: aloha.cc.columbia.edu).
  3. The hostname is looked up to match the IP address obtained in step #1.
If step #3 fails, the connection is rejected. To learn more about wildcards and their associated functionality, see the hosts_access(5) manual page.

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 version of inetd (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: 

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:

You can use single file and include action (allow or deny as the last field of TCP wrapper configuration file directive (see above). Often this is more transparent approach as you see all directives in a single file.

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 TCP wrappers 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. Some ftp daemons can reject connections fro which there is no legit DNS name. TCP wrappers can do this too.

As for the ability to execute shutdown command, which is necessary for operators,  usually the best way to achieve this is via sudo.

The tcpd program can be used with  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:

  1. It opens the /etc/hosts.allow  file. This file contains access control rules and actions for each protocol.

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

  3. It executes the action(s) specified in the rule. If appropriate, control is then turned over to the network server.

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

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

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.

42.5. TCP Wrappers and xinetd

The TCP Wrappers package (tcp_wrappers) is installed by default and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP-wrapped service is one that has been compiled against the libwrap.a library.

When a connection attempt is made to a TCP-wrapped service, the service first references the host's access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages.

If a client is allowed to connect, TCP Wrappers release control of the connection to the requested service and take no further part in the communication between the client and the server.

In addition to access control and logging, TCP Wrappers can execute commands to interact with the client before denying or releasing control of the connection to the requested network service.

Because TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Red Hat Enterprise Linux are linked to the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.

Note

To determine if a network service binary is linked to libwrap.a, type the following command as the root user: 

ldd <binary-name> | grep libwrap

Replace <binary-name>  with the name of the network service binary.

If the command returns straight to the prompt with no output, then the network service is not linked to libwrap.a.

The following example indicates that /usr/sbin/sshd is linked to libwrap.a: 

[root@myserver ~]# ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00655000)
[root@myserver ~]#

 Advantages of TCP Wrappers

TCP Wrappers provide the following advantages over other network service control techniques:

TCP Wrappers Configuration Files

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

When a TCP-wrapped service receives a client request, it performs the following steps:

  1. It references /etc/hosts.allow. — The TCP-wrapped service sequentially parses the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule, it allows the connection. If not, it moves on to the next step.
  2. It references /etc/hosts.deny. — The TCP-wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule, it denies the connection. If not, it grants access to the service.

The following are important points to consider when using TCP Wrappers to protect network services:

Warning

If the last line of a hosts access file is not a newline character (created by pressing the Enter key), the last rule in the file fails and an error is logged to either /var/log/messages or /var/log/secure. This is also the case for a rule that spans multiple lines without using the backslash character. The following example illustrates the relevant portion of a log message for a rule failure due to either of these circumstances: 

warning: /etc/hosts.allow, line 20: missing newline or line too long

Formatting Access Rules

The format for both /etc/hosts.allow and /etc/hosts.deny is identical. Each rule must be on its own line. Blank lines or lines that start with a hash (#) are ignored.

Each rule uses the following basic format to control access to network services: 

<daemon list>: <client list> [: <option>: <option>: ...]

More information on the specialist terms above can be found elsewhere in this Guide:

The following is a basic sample hosts access rule: 

vsftpd : .example.com

This rule instructs TCP Wrappers to watch for connections to the FTP daemon (vsftpd) from any host in the example.com domain. If this rule appears in hosts.allow, the connection is accepted. If this rule appears in hosts.deny, the connection is rejected.

The next sample hosts access rule is more complex and uses two option fields: 

sshd : .example.com  \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny

Note that each option field is preceded by the backslash (\). Use of the backslash prevents failure of the rule due to length.

This sample rule states that if a connection to the SSH daemon (sshd) is attempted from a host in the example.com domain, execute the echo command to append the attempt to a special log file, and deny the connection. Because the optional deny directive is used, this line denies access even if it appears in the hosts.allow file. Refer to Section 42.5.2.2, “Option Fields” for a more detailed look at available options.

Wildcards

Wildcards allow TCP Wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.

The following wildcards are available:

Caution

The KNOWN, UNKNOWN, and PARANOID wildcards should be used with care, because they rely on functioning DNS server for correct operation. Any disruption to name resolution may prevent legitimate users from gaining access to a service.

Patterns

Patterns can be used in the client field of access rules to more precisely specify groups of client hosts.

The following is a list of common patterns for entries in the client field:

Important

When working in the IPv4 address space, the address/prefix length (prefixlen) pair declarations (CIDR notation) are not supported. Only IPv6 rules can use this format.

Other, lesser used, patterns are also accepted by TCP Wrappers. Refer to the hosts_access man 5 page for more information.

Warning

Be very careful when using hostnames and domain names. Attackers can use a variety of tricks to circumvent accurate name resolution. In addition, disruption to DNS service prevents even authorized users from using network services. It is, therefore, best to use IP addresses whenever possible.

Portmap and TCP Wrappers

Portmap's implementation of TCP Wrappers does not support host look-ups, which means portmap can not use hostnames to identify hosts. Consequently, access control rules for portmap in hosts.allow or hosts.deny must use IP addresses, or the keyword ALL, for specifying hosts.

Changes to portmap access control rules may not take effect immediately. You may need to restart the portmap service.

Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations.

Operators

At present, access control rules accept one operator, EXCEPT. It can be used in both the daemon list and the client list of a rule.

The EXCEPT operator allows specific exceptions to broader matches within the same rule.

In the following example from a hosts.allow file, all example.com hosts are allowed to connect to all services except cracker.example.com: 

ALL: .example.com EXCEPT cracker.example.com

In another example from a hosts.allow file, clients from the 192.168.0.x network can use all services except for FTP: 

ALL EXCEPT vsftpd: 192.168.0.

Note

Organizationally, it is often easier to avoid using EXCEPT operators. This allows other administrators to quickly scan the appropriate files to see what hosts are allowed or denied access to services, without having to sort through EXCEPT operators.

Option Fields

In addition to basic rules that allow and deny access, the Red Hat Enterprise Linux implementation of TCP Wrappers supports extensions to the access control language through option fields. By using option fields in hosts access rules, administrators can accomplish a variety of tasks such as altering log behavior, consolidating access control, and launching shell commands.

Logging

Option fields let administrators easily change the log facility and priority level for a rule by using the severity directive.

In the following example, connections to the SSH daemon from any host in the example.com domain are logged to the default authpriv syslog facility (because no facility value is specified) with a priority of emerg: 

sshd : .example.com : severity emerg

It is also possible to specify a facility using the severity option. The following example logs any SSH connection attempts by hosts from the example.com domain to the local0 facility with a priority of alert: 

sshd : .example.com : severity local0.alert

Note: In practice, this example does not work until the syslog daemon (syslogd) is configured to log to the local0 facility. Refer to the syslog.conf man page for information about configuring custom log facilities.

Access Control

Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.

For example, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com: 

sshd : client-1.example.com : allow
sshd : client-2.example.com : deny

By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some administrators consider this an easier way of organizing access rules.

Shell Commands

Option fields allow access rules to launch shell commands through the following two directives:

For more information about shell command options, refer to the hosts_options man page.

Expansions

Expansions, when used in conjunction with the spawn and twist directives, provide information about the client, server, and processes involved.

The following is a list of supported expansions:

The following sample rule uses an expansion in conjunction with the spawn command to identify the client host in a customized log file.

When connections to the SSH daemon (sshd) are attempted from a host in the example.com domain, execute the echo command to log the attempt, including the client hostname (by using the %h expansion), to a special file: 

sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
	: deny

Similarly, expansions can be used to personalize messages back to the client. In the following example, clients attempting to access FTP services from the example.com domain are informed that they have been banned from the server: 

vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"

For a full explanation of available expansions, as well as additional access control options, refer to section 5 of the man pages for hosts_access (man 5 hosts_access) and the man page for hosts_options.

Refer to Section 42.5.5, “Additional Resources” for more information about TCP Wrappers.

xinetd

The xinetd daemon is a TCP-wrapped super service  which controls access to a subset of popular network services, including FTP, IMAP, and Telnet. It also provides service-specific configuration options for access control, enhanced logging, binding, redirection, and resource utilization control.

When a client attempts to connect to a network service controlled by xinetd, the super service receives the request and checks for any TCP Wrappers access control rules.

If access is allowed, xinetd verifies that the connection is allowed under its own access rules for that service. It also checks that the service can have more resources allotted to it and that it is not in breach of any defined rules.

If all these conditions are met (that is, access is allowed to the service; the service has not reached its resource limit; and the service is not in breach of any defined rule), xinetd then starts an instance of the requested service and passes control of the connection to it. After the connection has been established, xinetd takes no further part in the communication between the client and the server.

xinetd Configuration Files

The configuration files for xinetd are as follows:

The /etc/xinetd.conf File

The /etc/xinetd.conf file contains general configuration settings which affect every service under xinetd's control. It is read when the xinetd service is first started, so for configuration changes to take effect, you need to restart the xinetd service. The following is a sample /etc/xinetd.conf file: 

defaults
{
         instances               = 60        
	 log_type                = SYSLOG	authpriv
	 log_on_success          = HOST PID
	 log_on_failure          = HOST
	 cps                     = 25 30
}
includedir /etc/xinetd.d

These lines control the following aspects of xinetd:

Note

Often, both the log_on_success and log_on_failure settings in /etc/xinetd.conf are further modified in the service-specific configuration files. More information may therefore appear in a given service's log file than the /etc/xinetd.conf file may indicate. Refer to Section 42.5.4.3.1, “Logging Options” for further information.

The /etc/xinetd.d/ Directory

The /etc/xinetd.d/ directory contains the configuration files for each service managed by xinetd and the names of the files correlate to the service. As with xinetd.conf, this directory is read only when the xinetd service is started. For any changes to take effect, the administrator must restart the xinetd service.

The format of files in the /etc/xinetd.d/ directory use the same conventions as /etc/xinetd.conf. The primary reason the configuration for each service is stored in a separate file is to make customization easier and less likely to affect other services.

To gain an understanding of how these files are structured, consider the /etc/xinetd.d/krb5-telnet file: 

service telnet
{
         flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 disable         = yes
}

These lines control various aspects of the telnet service:

Note

The REUSE flag is deprecated. All services now implicitly use the REUSE flag.

Refer to the xinetd.conf man page for more information about these options and their usage.

Altering xinetd Configuration Files

A range of directives is available for services protected by xinetd. This section highlights some of the more commonly used options.

Logging Options

The following logging options are available for both /etc/xinetd.conf and the service-specific configuration files within the /etc/xinetd.d/ directory.

The following is a list of some of the more commonly used logging options:

For a complete list of logging options, refer to the xinetd.conf man page.

Access Control Options

Users of xinetd services can choose to use the TCP Wrappers hosts access rules, provide access control via the xinetd configuration files, or a mixture of both. Refer to Section 42.5.2, “TCP Wrappers Configuration Files” for more information about TCP Wrappers hosts access control files.

This section discusses using xinetd to control access to services.

Note

Unlike TCP Wrappers, changes to access control only take effect if the xinetd administrator restarts the xinetd service.

Also, unlike TCP Wrappers, access control through xinetd only affects services controlled by xinetd.

The xinetd hosts access control differs from the method used by TCP Wrappers. While TCP Wrappers places all of the access configuration within two files, /etc/hosts.allow and /etc/hosts.deny, xinetd's access control is found in each service's configuration file in the /etc/xinetd.d/ directory.

The following hosts access options are supported by xinetd:

The only_from and no_access options can use a list of IP addresses or host names, or can specify an entire network. Like TCP Wrappers, combining xinetd access control with the enhanced logging configuration can increase security by blocking requests from banned hosts while verbosely recording each connection attempt.

For example, the following /etc/xinetd.d/telnet file can be used to block Telnet access from a particular network group and restrict the overall time range that even allowed users can log in: 

service telnet
{
         disable         = no
	 flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 no_access       = 172.16.45.0/24
	 log_on_success  += PID HOST EXIT
	 access_times    = 09:45-16:15
}

In this example, when a client system from the 10.0.1.0/24 network, such as 10.0.1.2, tries to access the Telnet service, it receives the following message: 

Connection closed by foreign host.

In addition, their login attempts are logged in /var/log/messages as follows: 

Sep  7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)

When using TCP Wrappers in conjunction with xinetd access controls, it is important to understand the relationship between the two access control mechanisms.

The following is the sequence of events followed by xinetd when a client requests a connection:

  1. The xinetd daemon accesses the TCP Wrappers hosts access rules using a libwrap.a library call. If a deny rule matches the client, the connection is dropped. If an allow rule matches the client, the connection is passed to xinetd.
  2. The xinetd daemon checks its own access control rules both for the xinetd service and the requested service. If a deny rule matches the client, the connection is dropped. Otherwise, xinetd starts an instance of the requested service and passes control of the connection to that service.

Important

Care should be taken when using TCP Wrappers access controls in conjunction with xinetd access controls. Misconfiguration can cause undesirable effects.

Binding and Redirection Options

The service configuration files for xinetd support binding the service to an IP address and redirecting incoming requests for that service to another IP address, hostname, or port.

Binding is controlled with the bind option in the service-specific configuration files and links the service to one IP address on the system. When this is configured, the bind option only allows requests to the correct IP address to access the service. You can use this method to bind different services to different network interfaces based on requirements.

This is particularly useful for systems with multiple network adapters or with multiple IP addresses. On such a system, insecure services (for example, Telnet), can be configured to listen only on the interface connected to a private network and not to the interface connected to the Internet.

The redirect option accepts an IP address or hostname followed by a port number. It configures the service to redirect any requests for this service to the specified host and port number. This feature can be used to point to another port number on the same system, redirect the request to a different IP address on the same machine, shift the request to a totally different system and port number, or any combination of these options. A user connecting to a certain service on a system may therefore be rerouted to another system without disruption.

The xinetd daemon is able to accomplish this redirection by spawning a process that stays alive for the duration of the connection between the requesting client machine and the host actually providing the service, transferring data between the two systems.

The advantages of the bind and redirect options are most clearly evident when they are used together. By binding a service to a particular IP address on a system and then redirecting requests for this service to a second machine that only the first machine can see, an internal system can be used to provide services for a totally different network. Alternatively, these options can be used to limit the exposure of a particular service on a multi-homed machine to a known IP address, as well as redirect any requests for that service to another machine especially configured for that purpose.

For example, consider a system that is used as a firewall with this setting for its Telnet service: 

service telnet
{
         socket_type		= stream
	 wait			= no
	 server			= /usr/kerberos/sbin/telnetd
	 log_on_success		+= DURATION USERID
	 log_on_failure		+= USERID
	 bind                    = 123.123.123.123
	 redirect                = 10.0.1.13 23
}

The bind and redirect options in this file ensure that the Telnet service on the machine is bound to the external IP address (123.123.123.123), the one facing the Internet. In addition, any requests for Telnet service sent to 123.123.123.123 are redirected via a second network adapter to an internal IP address (10.0.1.13) that only the firewall and internal systems can access. The firewall then sends the communication between the two systems, and the connecting system thinks it is connected to 123.123.123.123 when it is actually connected to a different machine.

This feature is particularly useful for users with broadband connections and only one fixed IP address. When using Network Address Translation (NAT), the systems behind the gateway machine, which are using internal-only IP addresses, are not available from outside the gateway system. However, when certain services controlled by xinetd are configured with the bind and redirect options, the gateway machine can act as a proxy between outside systems and a particular internal machine configured to provide the service. In addition, the various xinetd access control and logging options are also available for additional protection.

Resource Management Options

The xinetd daemon can add a basic level of protection from Denial of Service (DoS) attacks. The following is a list of directives which can aid in limiting the effectiveness of such attacks:

There are more resource management options available for xinetd. Refer to the xinetd.conf man page for more information.

Additional Resources

More information about TCP Wrappers and xinetd is available from system documentation and on the Internet.

Installed Documentation

The documentation on your system is a good place to start looking for additional configuration options for TCP Wrappers, xinetd, and access control.

Useful Websites

 

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Oct 29, 2011] TCP Wrappers

The TCP Wrappers product suite provides an enhanced security mechanism for services spawned by the Internet services daemon, inetd. TCP Wrappers is available on HP-UX 11i platform as a web upgrade. Please visit www.docs.hp.com for related product documentation.

Whenever a connection is established with inetd for a service, inetd runs tcpd, the wrapper program instead of running the service program directly. On inception, tcpd will perform some access control checks and execute the desired service program.

tcpd offers the following features:

- Complete Access control.
- Checks against host name / address spoofing.
- RFC931 lookup for remote user who owns the connection.
- Support for services that use XTI as well as sockets.
- Setting Traps
- Banner Messages.
The product suite also contains the utility programs : tcpdmatch, tcpdchk, try-from, and safe_finger.
It also contains a library, libwrap.a which has the host access control functions in it.

With TCP Wrappers, you can:

Useful Information

The following are the components of the TCP Wrappers software depot:
/usr/lbin/tcpd TCP Wrappers daemon program.
/usr/lib/libwrap.a TCP Wrappers library containing access control APIs, using /etc/hosts.allow and /etc/hosts.deny.
/usr/include/tcpd.h Header file for libwrap.a.
/usr/bin/tcpdchk Tool to examine the validity of configuration file entries.
/usr/bin/tcpdmatch Tool to simulate the Wrappers daemon program's i.e., tcpd's behaviour for a particular host and for a particular service.
/usr/bin/try-from A utility program that can be invoked from a remote shell to get connection end-points' information.
/usr/bin/safe_finger A secure finger client program.
/usr/newconfig/etc/tcpd.conf A sample configuration file for the TCP Wrappers daemon program.
/usr/newconfig/etc/hosts.allow A sample ACL file to specify hosts to be allowed.
/usr/newconfig/etc/hosts.deny A sample ACL file to specify hosts to be denied.
/usr/share/doc/TCPWRAP-RelNotes.pdf A detailed Release Notes explaining the features supported in this release.
The following product documentation is available with this release of TCP Wrappers:

Man Pages

Release Notes

The Release Notes is also available at,
http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services.
Additional product information
Version: -
Software specification: Workstation/Server, HP-UX11.11

[Oct 28, 2011] TCP Wrappers Configuration Files

ef12517-2.tu-sofia.bg

Wildcards allow TCP wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.

The following wildcards may be used:

Caution: The KNOWN, UNKNOWN, and PARANOID wildcards should be used with care as a disruption in name resolution may prevent legitimate users from gaining access to a service.

[Oct 28, 2011] Using TCP Wrappers to secure Linux All about Linux

linuxhelp.blogspot.com

Wildcards

You can use wildcards in the client section of the rule to broadly classify a set of hosts. These are the valid wildcards that can be used.

Patterns

You can also use patterns in the client section of the rule . Some examples are as follows:

ALL : .xyz.com
Matches all hosts in the xyz.com domain . Note the dot (.) at the beginning.
ALL : 123.12.
Matches all the hosts in the 123.12.0.0 network. Note the dot (.) in the end of the rule.
ALL : 192.168.0.1/255.255.255.0
IP address/Netmask can be used in the rule.
ALL : *.xyz.com
Asterisk * matches entire groups of hostnames or IP addresses.
sshd : /etc/sshd.deny
If the client list begins with a slash (/), it is treated as a filename. In the above rule, TCP wrappers looks up the file sshd.deny for all SSH connections.
sshd : ALL EXCEPT 192.168.0.15
If the above rule is included in the /etc/hosts.deny file, then it will allow ssh connection for only the machine with the IP address 192.168.0.15 and block all other connections. Here EXCEPT is an operator.

Note: If you want to restrict use of NFS and NIS then you may include a rule for portmap . Because NFS and NIS depend on portmap for their successful working. In addition, changes to portmap rules may not take effect immediately.

Suppose I want to log all connections made to SSH with a priority of emergency. See my previous post to know more on logging. I could do the following:

sshd : .xyz.com : severity emerg
Note: You can use the options allow or deny to allow or restrict on a per client basis in either of the files hosts.allow and hosts.deny 
in.telnetd : 192.168.5.5 : deny in.telnetd : 192.168.5.6 : allow

Enabling TCP Wrappers on Solaris 10

Glenn Brunette's Security Weblog
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

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

[****] Linux Security 101 Issue 14 By Kelley Spoon, [email protected] -- 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:

  1. Someone tries to use a service that tcpd is monitoring.
  2. tcpd wakes up, and makes a note of the attempt to the syslog.
  3. tcpd then looks hosts.allow
    • if it finds a match, tcpd goes back to sleep and lets the user access the service.
  4. tcpd now takes a look at hosts.deny
    • if it finds a match, tcpd closes the user's connection
  5. 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:

And finally, there are some wildcards you can use:

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:

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

By Trevor Warren <[email protected]>

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.

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)

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:

  1. Abandon telnet; use ssh instead.
  2. Fix your reverse DNS zones. Make the PTR records consistent with the A (address/host) records.
  3. 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).

Recommended Links

Internal

External

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019