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

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

The TCP Wrappers access configuration language


Lecture Notes TCP Wrappers Recommended Books Recommended Links xnetd Humor   Etc

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

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

daemon_list : client_host_list : option [ : option ...]

in which:


Specifies the TCP daemon (e.g., telnetd). More than one daemon can be specified by separating them with blanks or commas. The reserved keyword "ALL" matches all daemons; "ALL EXCEPT" matches all daemons except for the specific one mentioned (e.g., "ALL EXCEPT in.ftpd").


Specifies the hostname or IP address of the incoming connection. More than one host can be specified by separating them with blanks or commas. Incomplete hostnames and IP addresses can be used for wildcarding . The keyword ALL matches all clients;

option [ : option ...]

Specifies one or more options that are executed for the particular service.

 If TCP Wrappers is compiled with the -DPROCESS_OPTIONS flag, shell commands must be specified with the spawn option. A limited amount of token expansion is available within the shell command;

 Syntax for the "hosts" field in the tcpwrappers /etc/hosts.allow and /etc/hosts.deny files
Hostname as it appears in the /etc/hosts.allow or /etc/hosts.deny file Has the following effect
ALL Matches all hosts.
KNOWN Matches any host where the hostname or DNS-name and host address are known or where the user is known.
UNKNOWN Matches any host that does not have DNS name and is not listed in /etc/hosts or any other name servers
LOCAL Matches any host that is resolved to a name that does not have a period (.) in its name such as localhost.  Usually this is the case for all hosts listed in /etc/hosts.  Fore example

in.ftpd : local, .my.domain

PARANOID Matches any host for which double reverse-hostname/IP address translation does not match.


host.domainhost.subdomain Matches the specific hostname.
.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
111.222.333.444 Matches the specific IP address 111.222.333.444, for example



If the hostname ends with a period (.), the hostname is interpreted as the beginning of an IP address. The string "18." will match any host with an IP address of through The string "192.168.1." will match any host with an IP address of through
a pattern EXCEPT another pattern Matches any host that is matched by a pattern except those that also match another pattern.

The EXCEPT operator may also be used for specifying an Internet service.

 Options available for TCP Wrappers when compiled with -DPROCESS_OPTIONS

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

Token expansion available for the TCP Wrappers shell command

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

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

TCP Wrappers does not support  UDP protocol as it does not have the initial handshake. 

Making sense of your TCP Wrappers configuration files

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

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

% tcpdchk
warning: /etc/hosts.allow, line 24: ipop3d: no such process name in /etc/inetd.conf
warning: /etc/hosts.allow, line 39: sshd: no such process name in /etc/inetd.conf

We'll explore these "warnings" one at a time.

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

ipop3d : ALL : ALLOW

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

# example entry for the optional pop3 server
pop3    stream  tcp  nowait root /usr/local/libexec/ipop3d       popper

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

popper : ALL : ALLOW

Now let's rerun the tcpdchk program:

r2# tcpdchk
warning: /etc/hosts.allow, line 24: popper: service possibly not wrapped
warning: /etc/hosts.allow, line 39: sshd: no such process name in /etc/inetd.conf

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

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

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

r2# tcpdmatch
usage: tcpdmatch [-d] [-i inet_conf] daemon[@host] [user@]host
        -d: use allow/deny files in current directory
        -i: location of inetd.conf file
r2# tcpdmatch sshd [email protected]
warning: sshd: no such process name in /etc/inetd.conf
client:   hostname K1.VINEYARD.NET
client:   address
client:   username simsong
server:   process  sshd
matched:  /etc/hosts.allow line 39
option:   allow 
access:   granted

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

sshd : ALL : allow

Programs such as tcpdchk and tcpdmatch are very useful for testing non-trivila configurations. Wietse Venema should be complimented for writing and including them in his TCP Wrappers release

For more detailed on what TCP Wrappers is and how you can use it, see tcpd(1M).

TCP wrappers are availble for all major flavours of Unix

Several popular daemons that are not running via inted come with libtcp buirary compiled in. Among them are Postfix, Sendmail, vsftpd, sshd.

TCP Wrappers support in sshd Shell was always enabled since Secure Shell always called the TCP Wrapper function host_access(3) to determine if a connection attempt should proceed. If TCP Wrappers was not configured on that system, access, by default, would be granted. Otherwise, the rules as defined in the hosts.allow and hosts.deny files would apply.

For more information on these files, see hosts_access(4). Note that this and all of the TCP Wrappers manual pages a stored under /usr/sfw/man in Solaris 10. To view this manual page, you can use the following command:

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

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

New usage of TCP Wrappers in Solaris 10

In Solaris 10, two new services were wrapped: sendmail and rpcbind.

To enable TCP Wrappers support for inetd-based services:

# inetadm -M tcp_wrappers=true
# svcadm refresh inetd

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

# inetadm -l telnet | grep tcp_wrappersdefault tcp_wrappers=TRUE

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

# svcprop -p defaults inetd
defaults/tcp_wrappers boolean true

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

# svccfg -s inetd setprop defaults/tcp_wrappers=true
# svcadm refresh inetd

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

# inetadm -p | grep tcp_wrappers

# 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

# inetadm -l telnet | grep tcp_wrappers

# 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

Top Visited
Past week
Past month


Old News ;-)

[Oct 29, 2011] TCP Wrappers
Suppose that a situation occurs where a connection should be denied yet a reason should be sent to the individual who attempted to establish that connection. How could it be done? That action can be made possible by using the twist option. When a connection attempt is made, twist will be called to execute a shell command or script. An example already exists in the hosts.allow file:
# The rest of the daemons are protected.
        : severity \
        : twist /bin/echo "You are not welcome to use %d from %h."

This example shows that the message, "You are not allowed to use daemon from hostname." will be returned for any daemon not previously configured in the access file. This is extremely useful for sending a reply back to the connection initiator right after the established connection is dropped. Note that any message returned must be wrapped in quote " characters; there are no exceptions to this rule.

Warning: It may be possible to launch a denial of service attack on the server if an attacker, or group of attackers could flood these daemons with connection requests.

Another possibility is to use the spawn option in these cases. Like twist, the spawn option implicitly denies the connection and may be used to run external shell commands or scripts. Unlike twist, spawn will not send a reply back to the individual who established the connection. For an example, consider the following configuration line:

# We do not allow connections from
ALL : \
    : spawn (/bin/echo %a from %h attempted to access %d >> \
      /var/log/connections.log) \
    : deny

This will deny all connection attempts from the * domain; simultaneously logging the hostname, IP address and the daemon which they attempted to access in the /var/log/connections.log file.

Aside from the already explained substitution characters above, e.g. %a, a few others exist. See the hosts_access(5) manual page for the complete list. Wildcard Options

Thus far the ALL option has been used continuously throughout the examples. Other options exist which could extend the functionality a bit further. For instance, ALL may be used to match every instance of either a daemon, domain or an IP address. Another wildcard available is PARANOID which may be used to match any host which provides an IP address that may be forged. In other words, PARANOID may be used to define an action to be taken whenever a connection is made from an IP address that differs from its hostname. The following example may shed some more light on this discussion:

# Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny

In that example all connection requests to sendmail which have an IP address that varies from its hostname will be denied.

Caution: Using the PARANOID wildcard may severely cripple servers if the client or server has a broken DNS setup. Administrator discretion is advised.

To learn more about wildcards and their associated functionality, see the hosts_access(5) manual page.

Before any of the specific configuration lines above will work, the first configuration line should be commented out in hosts.allow. This was noted at the beginning of this section

[Sep 30, 2007] How to Secure Your RHEL5 Server Power Systems IBM Systems Magazine by Ken Milberg


How exactly can we secure RHEL5? Let's start with xinetd. xinetd is an Internet service daemon that's more secure than its predecessor, inetd, which is no longer used in Linux. Instead of having many different servers running at the same time, only xinetd is loaded, and it handles all requests and starts up the appropriate server. It verifies the connection is allowed and can even ensure that the services don't consume more than the allotted amount of system resources. It's commonly referred to as a super-service of sorts, as it controls access to all network services, including telnet and ftp. The xinet.conf is the global configuration file.

Here is a snapshot of it, taken from an RHEL5 partition on a System p platform.

[root@172_29_138_30 etc]# more xinetd.conf
# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.

# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
# enabled =
# disabled =

# Define general logging characteristics.
log_type = SYSLOG daemon info
log_on_failure = HOST
log_on_success = PID HOST DURATION EXIT

# Define access restriction defaults
# no_access =
# only_from =
# max_load = 0
cps = 50 10
instances = 50
per_source = 10

# Address and networking defaults
# bind =
# mdns = yes
v6only = no

# setup environmental attributes
# passenv =
groups = yes
umask = 002

The /etc/xinetd.d directory contains the configuration files for all services managed by the xinetd daemon. This example shows a configuration for a kerberized telnet server:

[root@172_29_138_30 xinetd.d]# ls
chargen-dgram daytime-stream echo-stream klogin rsync
chargen-stream discard-dgram eklogin krb5-telnet tcpmux-server
cvs discard-stream ekrb5-telnet kshell time-dgram
daytime-dgram echo-dgram gssftp ktalk time-stream
[root@172_29_138_30 xinetd.d]# more ekrb5-telnet
# default: off
# description: The kerberized telnet server accepts only telnet sessions, \
# which use Kerberos 5 authentication and encryption.
service telnet
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
server_args = -e
log_on_failure += USERID
disable = yes

If you want to turn ftp on, you'll need to change disable to no, start your ftp services and then restart your xinetd daemon.

TCP Wrappers

Implementation of TCP wrappers is a much more effective way of denying access to services than anything you can do without it. This can help you send special security-type banners and also warn of impending attacks by specific host machines. The logging features are also advanced. TCP wrappers make use out of the /etc/hosts.allow and /etc/hosts.deny file. When TCP wrappers are configured, only authorized systems may utilize the services of the host machine. TCP wrappers provide transparency to the client and to the wrapped network service, as both are unaware that TCP wrappers are in use. Because they operate separately from the actual services they protect, they allow many applications to share this common set of configuration files, making easier to manage.

Recommended Links

Using TCP Wrappers to secure Linux

Forward-confirmed reverse DNS - Wikipedia, the free encyclopedia



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


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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


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


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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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. 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


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: July 28, 2019