Protect Your PIX

By Cisco Press | Oct 3, 2001 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/897161/Protect-Your-PIX.htm

Cisco Secure Internet Security Solutions - Chapter 4
by Andrew Mason, Mark Newcomb

Cisco Secure PIX Firewall - Part 5
Cisco Secure Internet Security Solutions - click to go to publisher's site

Dual DMZ with AAA Authentication
This section introduces AAA authorization and creates two DMZs. This section focuses on the PIX configuration aspects of AAA. This section also introduces a failover PIX and access lists into this configuration.

Figure 4-8 shows how this network is configured. Notice that there are two PIX Firewalls, a primary and a failover. Should the primary PIX fail, the failover PIX takes over all of the duties of the primary PIX. You also have two DMZs, the public and the accounting DMZs. The accounting DMZ is used for clients on the Internet to access the accounting data for the services.

Figure 4-8: Dual DMZ Configuration

(Click image for larger view in a new window)

Although there is a failover cable that connects the serial ports on the firewalls, you also added a hub on the inside interfaces to allow connectivity between the firewalls and the interior router in order to save interfaces on the interior router. You did the same between the outside interfaces of the firewalls and the exterior router. Both PIX Firewalls must have connectivity to both DMZs for the failover PIX to operate correctly, should the primary fail.

The configuration of the primary PIX follows. This section discusses the changes made to this configuration after the listing. The blank lines were added for clarity.

 hostname pixfirewall

 enable password enablepass encrypted
 passwd password encrypted

 nameif ethernet0 outside security0
 nameif ethernet1 inside security100
 nameif ethernet2 public security 50
 nameif ethernet3 accounting security 60

 interface ethernet0 auto
 interface ethernet1 auto
 interface ethernet2 auto
 interface ethernet3 auto

 ip address outside 192.168.1.1 255.255.255.0
 ip address inside 172.30.1.2 255.255.255.248
 ip address public 192.168.2.1 255.255.255.0
 ip address accounting 10.200.200.1 255.255.255.0

 fixup protocol http 80
 fixup protocol http 10120
 fixup protocol http 10121
 fixup protocol http 10122
 fixup protocol http 10123
 fixup protocol http 10124
 fixup protocol http 10125
 fixup protocol ftp 21
 fixup protocol ftp 10126
 fixup protocol ftp 10127

 failover active
 failover link failover

 no rip inside passive
 no rip outside passive
 no rip public passive
 no rip accounting passive
 no rip inside default
 no rip outside default
 no rip public default
 no rip accounting default

 pager lines 24

 aaa-server TACACS+ (inside) host 10.1.1.41 thekey timeout 20
 aaa authentication include any outbound 0 0 0 0 TACACS+
 aaa authorization include any outbound 0 0 0 0 TACACS+
 aaa accounting include any outbound 0 0 0 0 TACACS+
 aaa authentication serial console TACACS+

 snmp-server community ourbigcompany
 snmp-server location Seattle
 snmp-server contact Mark Newcomb Andrew Mason
 snmp-server host inside 10.1.1.74
 snmp-server enable traps

 logging on
 logging host 10.1.1.50
 logging trap 7
 logging facility 20
 no logging console

 outbound limit_acctg deny 10.200.200.0 255.255.255.0
 outbound limit_acctg except 10.10.1.51
 outbound limit_acctg permit 10.200.200.66
 outbound limit_acctg permit 10.200.200.67
 apply (accounting) limit_acctg outgoing_dest

 access-list acct_pub permit host 10.200.200.52
 access-list acct_pub deny 10.200.200.0 255.255.255.0
 access-group acct_pub in interface public

 telnet 10.1.1.14 255.255.255.255
 telnet 10.1.1.19 255.255.255.255
 telnet 10.1.1.212 255.255.255.255

 url-server (inside) host 10.1.1.51 timeout 30
 url-server (inside) host 10.1.1.52
 filter url http 0 0 0 0

 global (outside) 1 192.168.1.50-192.168.1.253 255.255.255.0
 global (outside) 1 192.168.1.254 255.255.255.0
 nat (inside) 1 10.1.1.0 255.255.255.0 0 0
 nat (inside) 1 10.2.1.0 255.255.255.0 0 0
 nat (inside) 1 10.3.1.0 255.255.255.0 0 0
 nat (public) 1 192.168.2.1 255.255.255.0 0 0
 nat (accounting) 0 0 0

 static (public, outside) 192.168.1.30 192.168.2.30
 static (public, outside) 192.168.1.35 192.168.2.35
 static (public, outside) 192.168.1.49 192.168.2.49

 conduit permit tcp host 192.168.1.30 eq http any
 conduit permit tcp host 192.168.1.35 eq ftp any
 conduit permit tcp host 192.168.1.49 eq smtp any
 conduit permit tcp any eq sqlnet host 192.168.1.30

 route outside 0 0 192.168.1.2 1
 route inside 10.1.1.0 255.255.255.0 172.30.1.1 1
 route inside 10.2.1.0 255.255.255.0 172.30.1.1 1
 route inside 10.3.1.0 255.255.255.0 172.30.1.1 1
 route public 192.168.2.0 255.255.255.0 192.168.2.1
 route accounting 10.200.200.0 255.255.255.0 10.200.200.1 1

 arp timeout 7200

 mtu inside 1500
 mtu outside 1500
 mtu public 1500
 mtu accounting 1500

 clear xlate
 write mem
 write standby

The first change made to this configuration is the added nameif command for the accounting DMZ, assigning a security level of 60. The next change is that you enabled this interface with the interface command. You then assigned an IP address to the interface. Next, you configured the failover parameters.

failover Commands
The failover commands are relatively simple to use. Before discussing the commands, this section takes a few moments and discusses the requirements for a failover PIX, how the primary and secondary PIX are connected, and how the failover PIX is configured.

When purchasing a PIX, consider purchasing a failover PIX at the same time. When both are purchased together, there is a significant price reduction on the failover unit. Because the PIX is generally used as the primary device protecting your network, it usually makes sense from both service and fiscal points of view to make this a redundant system.

For a PIX to failover to another PIX after failure, both firewalls must have identical hardware and identical software versions. There is a proprietary cable made specifically for connecting between PIX Firewalls. On the back of each PIX is a port labeled failover. The cable ends are labeled primary and secondary. Once the primary PIX is configured, turn the secondary PIX's power off. Connect the cable, and restore power to the secondary PIX. After a few seconds, the secondary PIX acquires a copy of the configuration on the primary PIX. Should the primary PIX fail, the secondary PIX starts establishing connections. However, any connections that exist when the primary PIX fails are dropped and need to be reestablished. After the secondary PIX is powered on with the failover cable connected, changes should only be made to the primary PIX. One limitation of the failover system on the PIX is the length of the failover cable. The length of the cable cannot be extended, and the cable is required to be used. Therefore, you cannot use a primary PIX in one physical location and the secondary PIX in another location.

The first command used is the failover active command. This command, like all commands, should only be entered on the primary PIX. This command establishes that failover is configured and that the present PIX is the primary PIX. Using the no form of this command forces the current PIX to become the secondary PIX.

The second command shown is the failover link command. You have specified that the port used for the failover is the failover port. There is one more command used regarding failover. This command, write standby, is shown at the bottom of the configuration. The write standby command should be used after each time the configuration is changed. This causes the secondary PIX to receive a copy of the current configuration.

Understanding Failover
The failover features of the PIX are similar to those used with the Hot Standby Router Protocol (HSRP) in that the standby device remains inactive until the primary device fails. The standby device, on activation, assumes the IP and Media Access Control (MAC) address of the primary unit. Likewise, the previously active device assumes the IP and MAC addresses of the formerly standby device. Because network devices do not see any change in these addresses, no new ARP entries need to be made on the hosts using the PIX Firewall.

Starting with the PIX IOS 5.0 software release, stateful failovers are supported. Prior to this release, the PIX did not maintain a copy of the connection state in the standby unit. When the primary device failed, network traffic needed to reestablish previous connections. Stateful failovers overcome this issue by passing data about the state of connections between the primary and the standby devices within state update packets. A single packet traversing the PIX can establish a new connection state. Because each connection state changes on a per-packet basis, every packet received by the currently active device requires a state update packet to be relayed to the inactive device. Although this process works very well, there are some latency-sensitive applications that will time out before the failover process is completed. In these cases, a new session will need to be established.

IP states are supported, as are TCP states, except those using HTTP. Almost no UDP state tables are transferred between the active and standby devices. Exceptions to this include dynamically opened ports used with multichannel protocols, such as H.323. Because DNS resolves use a single channel port, the state of DNS requests is not transferred between devices.

A dedicated LAN interface between the two PIX devices is required to achieve stateful failover. State update packets are transmitted asynchronously in the background from the active device to the standby device over the dedicated LAN interface. There are also a few configurations changes required when using stateful failover. These changes are covered below in the section "Stateful Failover Configuration."

Several criteria are considered before a failover occurs. If the standby device detects that the active device is powered down, the standby device will take active control. If the failover cable is unplugged, a syslog entry is generated, but both devices maintain their present state. An exception to this is during the boot process. Should the failover cable be unplugged while the devices are booting, both devices will assume the same IP address, causing a conflict on your network. Even if you are configuring the PIX Firewalls for stateful failover using a dedicated LAN interface, the failover cable must be installed on both devices for failover to function properly.

Failover hello packets are expected on each interface every 15 seconds. When the standby device does not receive a failover hello packet within 30 seconds, the interface runs a series of tests to establish the state of the active device. If these tests do not reveal that the active device is present, the standby device assumes the active role.

A power failure on the active device is detected through the failover cable within 15 seconds. In this case, the standby device assumes the active role. A disconnected or damaged failover cable is detected within 15 seconds.

Stateful Failover Configuration
Only a few commands need to be added to a configuration to enable stateful failover. The following is a partial configuration, showing the commands necessary to enable stateful failover. After the configuration, the commands are discussed.

 nameif ethernet0 outside security0
 nameif ethernet1 inside security100
 nameif ethernet2 failover security 60

 ip address outside 192.168.1.1 255.255.255.0
 ip address inside 172.30.1.1 255.255.255.0
 ip address failover 10.200.200.1 255.255.255.0

 failover active
 failover ip address outside 192.168.1.2
 failover ip address inside 172.30.1.2
 failover ip address failover 10.200.200.2
 failover link failover
Notice that the interfaces are named failover, and a security level is assigned to the interface with the nameif command. You could have named this interface anything, but for clarity, it is named failover here. This is the interface you will be using to transfer state update packets between the active and the standby devices.

After assigning IP addresses and netmasks to each of the interfaces, you are ready to start on the failover commands. Start failover with the failover active command. Next, use the failover ip address command on all of the interfaces.

When using the failover ip address command, you need to remember two things. First, every interface needs the failover ip address command entered for that interface. If an interface does not have an associated failover ip address command and the state of that interface is changed to down, failover will not occur. For example, if you did not add the failover ip address command for the outside interface and the cable connecting that interface broke, all data intended to travel through that interface will be lost. This defeats the purpose of having a failover device, because a failover device should allow all services to continue after the primary device has failed. Additionally, because both devices must have the same hardware installed, there is no reason not to enable failover to check all interfaces. The second item that you need to remember is that the failover ip address needs to be on the same subnet but with a different IP address than that to which the interface is set.

The final configuration required is to assign a dedicated interface to failover. Using the failover link command with the interface name assigned by the nameif command, Ethernet2 has been assigned as the failover interface in this example.

rip Commands
You added commands to disable RIP on all interfaces. Notice that each interface has two lines associated with that interface: a no rip interface_name passive and a no rip interface_name default command. Each one of these commands accomplishes a different objective. The no rip interface_name passive command causes the PIX to stop listening to RIP updates. The no rip interface_name default command causes the PIX to stop broadcasting known routes through RIP.

RIPv1 and RIPv2 are both available on the PIX through the rip command. Use the no form of the rip command to disable a portion of RIP. Use the show rip command to show the current RIP entries and the clear rip command to clear RIP tables. The full syntax of this command is:

 rip interface_name default | passive [version [1 | 2]]
     [authentication [text | md5 key ( key_id)]]

The parameters and keyword meanings are listed in Table 4-2:

Command Description
interface_nameThe interface to which this command should be applied.
defaultBroadcasts a default route on the interface.
passiveEnables passive RIP (listening mode) and propagates the RIP tables based on these updates.
version</td>RIP version 1 or 2. Version 2 must be used if encryption is required.
authenticationEnables RIP version 2 authentication.
textSends RIP updates as clear text. This is not a recommended option.
md5Sends RIP update packets using MD5 encryption. Version 2 only.
keyThis is the key used to encrypt RIP updates for version 2.
key_idThe key identification value. Both sides must use the same key. Version 2 only.

pager lines Command
The pager lines command specifies how many lines are shown when a show config command is issued before a more prompt appears. Although this can be set to almost any value, 24 works well when using standard Telnet applications.

Cisco Secure Internet Security Solutions -- Click to go to publisher's site --
In our next installment of Cisco Secure Internet Security Solutions - Chapter 4, we will look at AAA commands, as well as additional Dual DMZ configuration considerations.