This command shows what ports were available prior to reducing the available services. After reducing those services by shutting off the entries in inetd.conf and the startup files, the system now offers the following ports:

pc# ./portscan pc
21
23
pc#

With the host almost completely shut down from the network, the next step is to configure TIS Toolkit components.

Configuring TCP/IP

For TIS to be effective as a firewall, the system on which it is running must not perform routing. A system that has two or more network interfaces must be configured so that it does not automatically route packets from one interface to another. If this occurs, services that are being constructed with the TIS Toolkit will not be used.

IP Forwarding

To receive any real benefits from a firewall installation, you need to make sure IP forwarding has been disabled. IP forwarding causes the packets received on one interface to be retransmitted on all other applicable interfaces. To help illustrate IP forwarding, suppose you are considering setting up a firewall on the system in figure 6.2.

Figure 6.2  Multihomed machines.

This machine has two interfaces: one is for the local area network, which has an IP address of 204.191.3.150. The other interface is for the wide area network, and is a PPP link using an IP address of 198.53.166.62. When IP forwarding is enabled, any packets received on the LAN interface of this machine that are destined for a different network are automatically forwarded to the PPP link. The same is true for packets on the PPP link. If the packets received on the PPP link are for the rnet, they will be transmitted on the Ethernet interface in the machine.

This type of arrangement is unsuitable for a firewall. The reason is that the firewall will still pass unlogged and unauthenticated traffic from either direction. Consequently, there is little or no point to going through this exercise if you leave IP forwarding enabled.

Disabling IP forwarding usually requires that a new kernel be configured. The reason for this is that the process of IP disabling involves changing some kernel parameters. Table 6.1 lists parameters that must be changed for the identified operating systems.

After making the required changes to the kernel parameters, you need to build a new kernel, install it, and reboot. This removes any configured IP forwarding, and enables you to maximize the capabilities of the Toolkit. After IP forwarding is removed, all traffic requests either into or out from the private network need to be made through the proxy servers on the firewall.

The netperm Table

The netperm table, found in /usr/local/etc/netperm-table, is the master configuration file for all the components in the Trusted Firewall Toolkit (netacl, smap, smapd, ftp-gw, tn-gw, and plug-gw). When an application in the Toolkit starts, it reads its configuration and permissions information from netperm-table and stores it in an in-memory database. Saving the information in an in-memory database enables the information to be preserved, even after a chroot system call is used to reset the directory structure.

The permissions/configuration file is organized into rules. Each rule is the name of the application that rule applies to, followed by a colon. Multiple applications can be targeted by a single rule by separating the names with commas, or wildcarding them with an asterisk. When an application extracts its configuration information, it only extracts the rules that apply to it, preserving the order in which they appeared in the file. The following sequence lists a sample set of rules for the smap and smapd application.

# sample rules for smap
       smap, smapd:  userid 4
       smap, smapd:  directory /mail/inspool
       smap:         timeout 3600

---

Note:  Comments regarding the rules can be inserted in the configuration file by starting the line with “#” as the first character. As with any configuration file or program, the more comments that are used, the easier it is later to maintain the rules.

---

When an application has matched a rule, the rule is translated into whitespace delimited strings for later use. Typically, the application retrieves matching rules based on the first word in the rule; the remaining words serve as parameters for that particular clause. For the smap client and smapd server in the preceding example, the rules specify the userid to use when the application executes, the directory clause identifies the location of files, and the timeout clause indicates how long the server or client will wait before assuming that the remote end is “hung.”

Special modifiers are available for each clause. For example, if the clause begins with a permit- or deny- modifier, the rule is internally flagged as granting or revoking permission for that clause. This means that if an application retrieves all of its configuration clauses for “hosts,” the following will be returned:

     netacl-in.ftpd: permit-hosts 192.33.112.117 -exec /usr/etc/in.ftpd
     netacl-in.ftpd: permit-hosts 198.137.240.101 -exec /usr/etc/in.ftpd
     netacl-in.ftpd: deny-hosts unknown
     netacl-in.ftpd: deny-hosts *

Although this example may not seem clear, keep in mind that each application within the Toolkit has its own unique set of clauses. The default configuration for each of the application’s clauses and examples are presented with the application’s description.

When assembling your netperm-table file, you might want to consider a few conventions. These conventions promote consistency in the file, and help produce a more readable and maintainable rules list. When a hostname or host IP address is specified in the rule, matching is performed based on whether the pattern to which the address will be matched is all digits and decimal points, or other characters.

To better explain this process, consider this configuration rule:

netacl-in.ftpd: permit-hosts 192.33.112.117 -exec /usr/etc/in.ftpd