153
machine on the Internet was found to exhibit the exact same behavior. The Cisco PIX firewall provides a level of protection right out of the box without complex configuration, testing, or
troubleshooting.
By using the conduit andor static commands covered later in this chapter, we can set up
special configurations that allow inbound connections to occur through the firewall. Thus, our mail server, web server, and FTP server can be contacted and deliver information to or from
the outside world.
Before we foray further into the practice of punching holes in the PIX firewall, we will take our sample configuration and add some more restrictions to our inside Ethernet hosts. Lets
say that we have decided, in our role as the network administrators, that we wish to deny outbound web access from the single internal host 192.168.2.100 and from the range of hosts
from 192.168.2.128 to 192.168.2.254. Further, we have deemed the telnet protocol to be troublesome and wish to deny all hosts on the inside network telnet access, except our own
workstation 192.168.2.2. The following configuration parameters accomplish these tasks:
outbound 11 deny 192.168.2.100 255.255.255.255 80 outbound 11 deny 192.168.2.128 255.255.255.128 80
outbound 11 permit 192.168.2.2 255.255.255.255 23 outbound 11 deny 192.168.2.0 255.255.255.0 23
apply inside 11 outgoing_src
The 11 following the
outbound
command refers to the access list used to group the firewall instructions. The masks following the IP addresses, such as the 255.255.255.128 following
192.168.2.128, refer to a netmask, or a whole range of hosts, rather than just to an individual node.
Some immediate differences appear when you compare the preceding access lists to those that would be found on any ordinary Cisco routing product running IOS. Most noticeable is that
PIX Firewall uses a single hostnetwork pair to control access, whereas IOS uses a double hostnetwork pair. For example, you might find something like the following on an Internet-
connected serial interface on a Cisco 7500 to produce the same results as the first line in our PIX firewall:
access-list 101 deny tcp 192.168.2.100 0.0.0.0 0.0.0.0 255.255.255.255 eq 80
Also, the PIX uses the
apply
keyword to activate or deactivate the access control provided by the
outbound
directives. In addition to checking where packets come from, as in our example, we can check the
destinations of our packets. To illustrate, lets say that site 1.1.1.1 on the Internet has unsavory materials on it and you wish to block all access to this site from your network. The following
configuration accomplishes this:
outbound 12 deny 1.1.1.1 255.255.255.255 apply inside 12 outgoing_dest
Youll notice a couple of things. First, we used another outbound access list numbered 12 to handle the new configuration. We feel it best to separate the outgoing destinations firewalls
from the outgoing source destinations. Although not required, it does help keep things more
154
orderly when these access lists get large, which is certainly going to happen over time. Second, we left off the port parameter. By doing so, we effectively cut all communication
attempts with host 1.1.1.1 on any port.
By using the principles we illustrated in the two firewall configuration examples, you can construct large and sometimes complicated firewalls, granting access and denying access to as
granular or as wide an audience as you desire. Keep in mind that the shorter the list of access items, the faster the machinery handles packets, and the easier it will be for you when a
problem with the firewall eventually explodes. Remember to use as large a network as possible grouping related machines in a single network, so that there is no need to enter 32
separate commands where one would have sufficed.
9.3.4 Testing, Tracing, and Debugging
To facilitate debugging and testing, the PIX firewall comes with a suite of test utilities. We will cover in brief the operation of the major ones.
9.3.4.1 debug
The debug command can be used to test the configuration of the PIX firewall and to check the ongoing operation of the unit whenever you suspect a connectivity problem. To enable the
tracing function, execute the command
debug trace on
to the PIX firewall. Results will be echoed to the console as ICMP packets are received or transmitted. For instance, using a
machine on our inside network 192.168.2.2 to ping a machine on our outside network 1.251.174.155 produced the following output:
1.251.174.155 - 2.241.11.254 192.168.2.2 1.251.174.155 - 2.241.11.254 192.168.2.2
Each ping packet is represented by a pair of log entries: one for the initial ICMP request and one for the returning response.
Pinging from the inside network to the outside PIX interface address will not produce a response, nor will pinging from a machine on the
outside network to the PIXs inside interface address. This is normal behavior. Using our sample networks, if we were to ping from
192.168.2.2 to 1.251.174.156, we would not get a response. Likewise, pinging from 1.251.174.155 to 192.168.2.2 or 2.241.11.254 will fail.
9.3.4.2 xlate
The xlate command stands for translate, and displays the current assignments of the inside network addresses to the global pool of addresses. Since these assignments are temporary and
will eventually disappear, the status reported by xlate can be different from minute to minute. The command is of great assistance when debugging problems with connectivity across the
PIX firewall. It provides some very comprehensive output, including the idle time of a connection, the bytes transferred, and the ports used to build it. Heres some output after we
started a telnet session across the PIX as well as launching Netscape Navigator:
155
sh xlate Global 2.241.11.254 Local 192.168.2.2 nconns 10 econns 0 flags pvA
TCP out 3.96.12.2-80 in 192.168.2.2-1700 idle 0:00:17 Bytes 365 Flags E TCP out 3.96.12.2-80 in 192.168.2.2-1699 idle 0:00:18 Bytes 365 Flags E
TCP out 3.96.12.2-80 in 192.168.2.2-1698 idle 0:00:19 Bytes 365 Flags E TCP out 3.96.12.2-80 in 192.168.2.2-1697 idle 0:00:19 Bytes 365 Flags E
TCP out 3.96.12.2-80 in 192.168.2.2-1696 idle 0:00:22 Bytes 370 Flags E TCP out 3.96.12.2-80 in 192.168.2.2-1695 idle 0:00:22 Bytes 371 Flags E
TCP out 3.96.12.2-80 in 192.168.2.2-1694 idle 0:00:22 Bytes 367 Flags E TCP out 3.96.12.2-80 in 192.168.2.2-1693 idle 0:00:22 Bytes 371 Flags E
TCP out 3.96.12.2-80 in 192.168.2.2-1692 idle 0:00:30 Bytes 323 Flags E TCP out 3.96.12.2-23 in 192.168.2.2-2049 idle 0:00:03 Bytes 1086 Flags
UFHIO
As you can see, there were a ton of port 80 connections established. Most of these are single graphic files located at the web servers main page 3.96.12.2. Netscape, as with most of the
other popular browsers, initiates many requests for each graphic after it has pulled down the contents of the main HTML page. The last line of the output is our telnet session, as
evidenced by the port 23 hanging on the end of the address.
9.3.4.3 arp
Sometimes when debugging network configurations, such as those involving the PIX firewall, you need to determine what the PIX can see. Using the address resolution protocol, which
handles the translation of Ethernet addressing into IP addresses, the PIX provides a fine tool for tracking down the physical machinery to which the PIX firewall is talking. The arp
command, logically enough, provides a list of Ethernet and IP addresses for both of the PIXs interfaces. When things get confused as to what host is doing what on the network, and what
access permissions it should be allowed to have through the PIX to the Internet, the arp command becomes helpful.
Heres an example of the output of our rather tiny example world detailed earlier in the chapter:
sh arp outside 4.96.12.9 00:34:08:93:1b:76
outside 4.241.10.209 00:77:70:62:5b:ee outside 4.96.12.100 00:05:02:65:27:fb
outside 2.96.12.1 00:00:0c:65:de:10 outside 2.96.12.2 00:20:af:67:8c:77
outside 2.96.12.62 00:e0:1e:33:33 outside 2.96.12.43 00:32:9a:00:33:9f
outside 2.96.12.23 00:32:97:0e:23:56 outside 3.96.12.33 08:00:07:4f:23:c5
inside 192.168.128.1 00:10:4b:45:1b:12 inside 192.168.129.2 00:40:22:33:3a:3d
inside 192.168.129.3 00:a0:22:4c:c6:23 inside 192.168.128.4 00:05:f2:28:23:7b
inside 192.168.129.5 00:40:32:31:33:1c inside 192.168.129.6 00:de:08:bf:ec:05
inside 192.168.129.7 00:60:8c:dd:c0:89
9.3.4.4 show interface
To check the physical Ethernet interfaces on the PIX, the
show interface
command provides some summary information. Here is the output of the command for illustration:
