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

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

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

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

The TCP Wrappers 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 ...]

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

                     daemon_list : client_host_list [: shell_command]

in which:

For examples of using TCP Wrappers, see Section 12.5 at the end of this chapter.

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 simsong@k1.vineyard.net 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 simsong@k1.vineyard.net
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 excellent complements to the security program TCP Wrappers because they help you head off security problems before they happen. Wietse Venema should be complimented for writing and including them in his TCP Wrappers release; other programmers should follow his example.

This section describes the ipfw host-based firewall that is part of BSD-based systems such as FreeBSD and Mac OS X. Although the commands discussed are specific to ipfw, the concepts are applicable to any host-based packet firewall system.

The firewall consists of code that is linked into the BSD kernel and a series of rules that are loaded into the kernel’s memory space at runtime. Each rule consists of a rule number, a filter specification, and an action. Rules are applied to all packets, whether the packets are passed from one interface to another (in the case of a Unix system that is acting as a router or gateway) or are passed from an interface to an application program (in the case of a Unix system that is acting as a network client or server).

Rules are evaluated in order until a matching rule is found, at which time the rule’s action is executed. Some actions terminate the rule search for a particular packet, while other actions cause the system to look for the next matching rule.

Rules are controlled using the ipfw command. Typical commands are:

There are many more commands beyond these. What’s more, the syntax and subcommands of the ipfw command vary slightly from system to system. For this reason, it is vital that you consult the ipfw (or iptables or ipchains) manpage for your operating system for a complete list. Furthermore, you should always have physical access to a computer on which you are running the ipfw command and be in a position where you can reboot the computer without any hesitation. By typing the wrong command, it is very easy to leave the computer in a state such that it is unable to send or receive packets on the network.

Filters for the ipfw command can be constructed using any or all of the following criteria:

Some typical actions are shown in Table 12-4.

Rules can also be assigned a probability so that they will be invoked only a certain percentage of the time. Although this is not tremendously useful for security applications, it can be useful in simulating conditions of heavy network congestion.^[143]

Example 12-3 shows a typical script that starts up a simple ipfwl script that is used on a computer that has two Ethernet interfaces—one on the organization’s internal network, one on the external Internet. (Despite the fact that the computer has two Ethernet interfaces, it is not configured to forward packets from one interface to another.) In this example, the internal network is the subnet 192.168.1.0/24. Note that all actual Internet addresses have been replaced with Net 10. addresses to protect the privacy of the guilty.

The 300-series rules open the firewall so that any packet to or from the organization’s internal network is allowed to pass freely.

The 400-series rules are filters that have been added to block Internet traffic from hosts that, in the opinion of the site’s operator, have shown a history of bad actions. In one case, one of the blocked sites was responsible for large amounts of unwanted email. In another case, computers at the IP address launched a series of attacks against one of the organization’s nameservers in an attempt to appropriate a valuable domain name. Rather than continually reading about these attacks in the system logs, it was easier to block their packets.

The 500-series rules allow a select number of protocols from anywhere else on the Internet. Note that the packets from the hosts mentioned in the 400-series rules will not be accepted because the 400-series rules execute before the 500-series rules.

The remaining rules specify a variety of policies for the site in question. Of particular interest are rules 1001 and 1002, which allow remote database connections from a particular subnet but nowhere else on the Internet, and rule 2001, which blocks all incoming TCP connections that are not specifically allowed by the other rules in the firewall ruleset. The net effect of rule 2001 is that any attacker who sets up a rogue TCP/IP server will find that his service is blocked by the system’s kernel. (Of course, a knowledgeable attacker who achieves superuser status can use the ipfw command to remove rule 2001; if you have a knowledgeable attacker who has achieved superuser status, you have bigger problems to worry about.)

case $1 in
start)
#
# Allow anything from internal network.
    ipfw add 301 allow ip from 192.168.1.0/24 to any
#
# General stuff to block specific attackers out there
    ipfw add 460 deny ip from 10.101.236.0/24 to any
    ipfw add 461 deny ip from 10.192.228.15 to any
    ipfw add 462 deny ip from 10.211.39.250 to any
    ipfw add 463 deny ip from 10.20.20.1 to any
    ipfw add 464 deny ip from 10.60.89.18 to any

# Allow SSH, SMTP, HTTP, HTTPS, and POP in from anywhere else.
    ipfw add 500 allow tcp from any to any 22,25,80,443,110

# Allow DNS from anywhere else.
    ipfw add 510 allow tcp from any to any 53
    ipfw add 510 allow udp from any to any 53

# Deny syslog.
    ipfw add 600 deny  udp from any to any 514

# Allow only X to our friends.
    ipfw add 700 allow tcp from 10.7.15.234/28 to any 6000-6063
    ipfw add 701 allow tcp from 10.175.193.176/28 to any 6000-6063
    ipfw add 702 deny  tcp from any to any 6000-6063

# MySQL clients from a particular site on the network
    ipfw add 1001 allow tcp from 199.175.193.176/28 to any 3306
    ipfw add 1002 deny tcp from any to any 3306

# LPD defenses
    ipfw add 1010 deny tcp from any to any 515

# SunRPC defenses
    ipfw add 1020 deny tcp from any to any 111

# imap only from internal network
    ipfw add 1030 deny tcp from any to any 143
    
# imaps, pops, and smtps from any network
    ipfw add 1100 allow tcp from any to any 465,993,995

# rtsp from any network
     ipfw add 1101 allow tcp from any to any 554
     ipfw add 1101 allow udp from any to any 554

# Allow any outgoing packet from this host.
    ipfw add 2000 allow tcp from any to any out

# Deny all other incoming TCP setup packets.
    ipfw add 2001 deny tcp from any to any setup

    ;;
  stop)
    ;;
esac