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

The TCP Wrappers access configuration language

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

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

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

in which:

daemon_list

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").

client_host_list

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;

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

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
r2#

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  204.17.195.90
client:   username simsong
server:   process  sshd
matched:  /etc/hosts.allow line 39
option:   allow 
access:   granted
r2#

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

• 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.
• HP-US has precomplied version availbale directly from HP
• Linux has built-in functionlity in xinetd replacement of inetd
• AIX has them downloadable from IBM too.

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.

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

To enable TCP Wrappers support for inetd-based services:

# inetadm -M tcp_wrappers=true
# svcadm refresh inetd

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

# inetadm -l telnet | grep tcp_wrappersdefault tcp_wrappers=TRUE

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

# svcprop -p defaults inetd
defaults/tcp_wrappers boolean true

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

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

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

# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

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

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

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

# inetadm -m telnet tcp_wrappers=TRUE

Let's check out settings again:

# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
tcp_wrappers=TRUE

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

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

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

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

This change can be verified by running:

# svcprop -p config/enable_tcpwrappers rpc/bind
true

NEWS CONTENTS

• 20111029 : TCP Wrappers ( freebsd.org )
• 20070930 : How to Secure Your RHEL5 Server Power Systems IBM Systems Magazine by Ken Milberg ( How to Secure Your RHEL5 Server Power Systems IBM Systems Magazine, Sep 30, 2007 )

Old News ;-)

[Oct 29, 2011] TCP Wrappers

freebsd.org

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.
ALL : ALL \
        : severity auth.info \
        : 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 example.com:
ALL : .example.com \
    : spawn (/bin/echo %a from %h attempted to access %d >> \
      /var/log/connections.log) \
    : deny

This will deny all connection attempts from the *.example.com 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.

15.6.2.2 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

xinetd

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.

defaults
{
# 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

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

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