| The architecture of PIX Firewall is based on the Adaptive Security Algorithm (ASA), which maintains the state information and provides security to your connection. ASA is a set of rules and policies that the packet has to conform to while traversing the firewall. As mentioned before, PIX is a stateful firewall, which means it works based on connections, not on a per-packet basis. It remembers every connection through the firewall. ASA ASA has the following characteristics: ASA provides a stateful connection. ASA allows return packets for established connections. ASA tracks source and destination ports and addresses, Transmission Control Protocol (TCP) sequences, and additional TCP flags. TCP sequence numbers are randomized. The inside interface has a security level of 100. The outside interface has a security level of 0. Demilitarized zone (DMZ) interfaces have user-settable security levels from 1 through 99. Starting with PIX OS 5.2, users are allowed to change the default security levels of both the outside and inside interfaces, but it is not recommended. By default, the PIX allows traffic to pass from higher security interfaces to lower security interfaces, and in the case of TCP and User Datagram Protocol (UDP) connections, it allows the return traffic back through. The same does not hold for Internet Control Message Protocol (ICMP).
PIX Packet Processing Packet flow across the PIX firewall is depicted in Figure 3-1. Work through the following steps to understand the packet flow: 1. | Packets are received on the ingress interface
Packets arrive on the ingress interface, which is indicated by input counters of the interface.
| | | 2. | Existing connection checks
Packets go through the existing connection check. If the connection exists, the ACL check is bypassed. If there is no existing connection, TCP non-SYN packets will be dropped and logged. If PIX receives a TCP SYN or UDP request packet, packets are passed to ACL checks.
| 3. | Interface ACL check
The initial packet in the flow of packet is processed through interface ACLs. Packets that are denied by interface ACLs are dropped and logged.
| 4. | NAT check
The initial packet in the flow must match a translation rule. To perform NAT, it is important to know the egress interface. Hence a quick route lookup is performed. If the translation is turned off, the translation is skipped. If the NAT is configured and the translation rule is matched, the connection is created on the PIX firewall. If an overlapping NAT is configured, the following order of NAT operations is performed:
- a. nat 0 access-list (nat-exempt).
- b. Match existing xlates.
- c. Match static commands (first match). Static NAT with and without access-list is checked before Static PAT with and without an access-list.
- d. Match nat commands. nat <id> access-list is matched first. Then nat <id> <address> <mask> is checked. If the ID is 0, create an identity xlate. Use a global pool for dynamic NAT. Use a global pool for dynamic PAT.
| 5. | Inspection check
Inspections are applied to NAT embedded IPs in the payload. Commands in control channels are inspected for compliance and secondary data channels. Additional security checks are also applied to the packet with inspection.
| 6. | Perform NAT
Perform IP address or the port translation.
| 7. | Packets forwarded to egress interface
Packets are forwarded to the egress interface. The egress interface is determined by the translation rules first. If translation rules do not specify the egress interface, the global route lookup is performed to determine the egress interface.
| | | 8. | Interface route lookup
Once the packet is on the egress interface, an interface route lookup is performed. Only routes pointing out the egress interface are used to forward the packet. Remember that the translation rule can forward the packet to the egress interface, even though the routing table may point to a different interface.
| 9. | Layer 2 address lookup for the next-hop address
After the interface route lookup is performed, the next-hop address is identified. At this stage, ARP resolution is performed. Then the packets are put in the wire, and the interface counters are incremented.
|
Figure 3-1. PIX Firewall Packet Flow 
File System Overview When upgraded to PIX 7.0, PIX Flash memory is reformatted. The contents of the files are different than in the older versions. Table 3-1 shows the different files that go into Flash on PIX Firewall Version 6.3 and earlier, and on PIX Firewall Version 7.0 and later. Table 3-1. Different Files Go Into Flash On Different VersionsRelease 6.3 and Earlier | Release 7.0 and Later |
|---|
SW Image | SW Image | Config File | Config File | Private Data File | Private Data | PDM Image | ASDM Image | Crash Information | Backup Image (If disk and flash space are available) Backup config file (if disk and flash space are available) Virtual Firewall Config File Crash Info (Internal Only) 1M/ASA, 128K/PIX |
The Flash file system can be viewed with either the dir or show flash command as shown in Example 3-1. Example 3-1. Flash File System on PIX 7.0 PIX# dir Directory of flash:/ 3 -rw- 4902912 13:37:33 Nov 24 2004 cdisk.7.0.0.89 4 -rw- 6748932 13:21:13 Nov 24 2004 ASDM 16128000 bytes total (4472832 bytes free) PIX(config)# ! Boot [system | config} <url> is the command that needs to be used to define the file ! using which the system should boot. It is possible to store more than one system ! image and config file. Designate which system image and start-up config file to boot. PIX(config)# boot system flash:/cdisk.7.0.0.89 ! Verify the start-up System Image. Display the system boot image. PIX# show bootvar BOOT variable = flash:/cdisk.7.0.0.89 Current BOOT variable = flash:/cdisk.7.0.0.89 CONFIG_FILE variable = Current CONFIG_FILE variable = PIX#
|
Table 3-2 shows the commands available to work with the Flash File System CLI. Table 3-2. Commands Available for PIX Flash File SystemCommand | Meaning |
|---|
cd | Change the current working directory to the one specified. | delete | Deletes a file. If a path is not specified, the file would be deleted from the current working directory. When deleting files the user would be prompted with the filename and asked to confirm the delete. The /recursive option would delete files recursively. | dir | Displays the content of the current directory. | format | Formats the disk using File Allocation Table (FAT). | mkdir | Creates a new directory. | more | Displays the contents of a specified file. more [/ascii] [/binary][disk:][<path>] | rename | Renames a specified file. | rmdir | Removes a specified directory. Use will be prompted. | pwd | Shows the present working directory. | copy | Copies a file from flash: ftp, http, https, running and startup config tftp, system. |
Example 3-2 shows the debug command available for troubleshooting the Flash file system. Example 3-2. debug Command For Troubleshooting File System PIX# debug disk ? file file-verbose filesystem PIX# debug disk
|
You might receive the following warnings and errors related to file system misbehavior: Out of space, run fsck, filename too long, no such file. The solution for these is self evident. Access-List The implementation of access-list is same as before on the PIX firewall, with some additional features that are discussed in the sections that follow. time-range Keyword The time-range keyword provides a way for the Network Security Manager to specify a time interval when connectivity to the specified destinations is permitted or denied. Multiple time ranges can be defined. The command allows easy and routine control of traffic connectivity through the firewall device. The time-range keyword is used to control the execution of various features in the PIX/ASA. The time-range feature is available in access control and VPN access hours (an attribute of group policy). First, define a period of timestart/stop, certain days, and so on, that can be evaluated to a true/false condition when compared to the current appliance time. Then, place the keyword qualifier Time-Range with the name as one of the last parameters on an access-list statement that describes the connectivity path. The Time-Range keyword, when applied on an access-list statement, identifies a statement that is applied only when the current time of the security appliance clock is in the time period specified by the command (a true condition). Example 3-3 shows how to configure the time-range option. Example 3-3. Using the time-range Command ! Choose a time-range name: PIX(config)# time-range ? WORD < 64 char Time range name PIX(config)# time-range sevt PIX(config-time-range)# ? ! More than one periodic entry can be defined. Decide how to specify the time period: PIX(config-time-range)# ? Time range configuration commands: absolute absolute time and date (one per time-range) exit Exit from time-range configuration mode help Help for time-range configuration commands no Negate a command or set its defaults periodic periodic time and date (multiple are permitted) ! More than one TIME-RANGE entry can be made Absolute Time Start and End, or just start ! with no end, . . . or end with no start (immediate start) PIX(config-time-range)# absolute ? end ending time and date start starting time and date PIX(config-time-range)# periodic ? Friday Friday Monday Monday Saturday Saturday Sunday Sunday Thursday Thursday Tuesday Tuesday Wednesday Wednesday daily Every day of the week weekdays Monday thru Friday weekend Saturday and Sunday ! And finally a configuration . . . time-range BusinessHours absolute start 10 periodic weekdays 7 . . . access-list outside_mpc_in remark Only WWW traffic goes to DMZ access-list outside_mpc_in extended permit tcp any 1.1.1.0 255.255.255.0 eq www time-range BusinessHours . . . ! "show time-range", "show clock" and "show access-list" are useful debugging commands ! when trying to determine if a time-range or ACE is active at the current time. e.g ! (note the inactive label in the ace below): PIX# show access-list access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300 access-list ACL1; 2 elements access-list ACL1 line 1 extended permit ip any any time-range TR1 (hitcnt=0) (inactive) access-list ACL1 line 2 extended deny ip any any (hitcnt=0) PIX#
|
Enable/Disable Access Control Lists (ACLs) are common traffic control commands. PIX OS 7.0 provides more control, especially in troubleshooting, by providing an easy way to "turn on" or "turn off" the processing of a specific access policy (access-list entry). This aids greatly in troubleshooting. The keyword INACTIVE is applied at the end of an access-list entry to remove it from processing. The command syntax for applying the access-list is as follows: [View full width] access-list outside_access_in extended permit tcp any object-group mail-servers eq smtp  inactive
There are no debug commands, output, logging outputs, caveats, or limitations specifically related to this keyword. Debug information comes from the access-list command features. Outbound ACL PIX OS 7.0 provides more granular access control by allowing both "incoming at interface" and "outgoing at interface" access policies to be configured. The OUT keyword is applied on the access-group command. It identifies an access policy (access-list) that applies to outgoing traffic at the specified interface. The OUT keyword can reduce the number of commands in a configuration and make its logical interpretation easier. To bind an access-list to an interface, use the access-group command in global configuration mode. To unbind an access-list from the interface, use the "no" form of this command. access-group access-list {in | out} interface interface_name [per-user-override] no access-group access-list {in | out} interface interface_name
Example 3-4 shows how to use the access-list and apply that as outbound. Example 3-4. Using an Outbound ACL PIX# configure terminal PIX(config)# PIX(config)# names PIX(config)# name user_net 10.1.1.0 PIX(config)# name dev_net 20.1.1.0 PIX(config)# name 24mask 255.255.255.0 . . . PIX(config)# access-list acl_outbound permit tcp user_net 24mask any eq 80 PIX(config)# access-list acl_outbound deny tcp dev_net 24mask any . . . PIX(config)# access-group acl_outbound out interface outside . . .
|
Note The per-user-override option allows downloaded access-lists to override the access-list applied to the interface. If the per-user-override optional argument is not present, PIX preserves the existing filtering behavior. The per-user access list is governed by the timeout value specified by the uauth option of the timeout command, but it can be overridden by the AAA per-user session timeout value.
nat-control The PIX always has been a device supporting, even requiring, Network Address Translation (NAT) for maximum flexibility and security. NAT is introduced as an option in PIX OS 7.0. Configuring nat-control on the PIX forces the PIX firewall to require NAT for a source address (for outbound traffic) and for a destination address for inbound traffic. If you upgrade PIX firewall from 6.x to Version 7.x, nat-control is enabled on the PIX. For new configurations, nat-control is disabled by default. If no nat-control is specified, only hosts that require NAT need to have a NAT rule configured. The nat-control statement is valid in routed firewall mode and in single and multiple security context modes. No new NAT functionality is provided with this feature. All existing NAT functionality remains the same. If you have no nat-control configured, and if there is a nat matching, it will go through the NAT engine. Otherwise, the packet will go through without NATing. In PIX 6.3 and earlier, the packet is dropped if there is no NAT match. Table 3-3 shows the comparison between nat-control and no nat-control. Table 3-3. Comparison Between nat-control and no nat-control| | nat-control | no nat-control |
|---|
No inside nat rule No outside nat rule | Deny | Continue | No inside nat rule outside nat rule | Continue | Continue | No inside nat rule No outside nat rule | Deny | Continue |
The difference between the no nat-control command and the nat 0 (identity NAT) command is that identity NAT requires that traffic be initiated from the more secure interface. The no nat-control command does not have this requirement, nor does it require a static command to allow communication to inside hosts. It relies on access-policies. Modular Policy Framework (MPF) Objective There is a growing need to provide greater granularity and flexibility in configuring network policies. For example, it is extremely important to have the ability to include a destination IP address as one of the criteria to identify traffic for Network Address Translation, or the ability to create a timeout configuration that is specific to a particular TCP application, as opposed to the current timeout scheme, which applies a timeout value to all TCP applications, and so on. MPF provides the tools to meet these and other needs. MPF features are derived from quality of service (QoS) as implemented in IOS. Not all features have been carried across. MPF is built on three related CLI commands: class-map This command identifies the traffic that needs a specific type of control. Class-maps have specific names, which tie them into the policy-map. This just selects the traffic. policy-map This command describes the actions to be taken on the traffic described in the class-map. Class-maps are listed by name under the appropriate policy-map. Policy-maps have specific names too, which tie them into the service-policy. They specify what action needs to be taken. service-policy This command describes where the traffic should be intercepted for control. Only one service-policy can exist per interface. An additional service-policy, global-service-policy, is defined for traffic and general policy application. This policy applies to traffic on all interfaces. The command applies the policy. You can have only one service policy per interface.
PIX 7.0 has the following restrictions for match/policy and class statements. Number of Policy-map: 64. Number of Class-map: 255. Number of Classes in a policy-map: 63. Number of match statements in a class-map: 1. For match tunnel-group and default-inspect, allow two statements.
Transparent Firewall Transparent Firewall works based on Layer 2 information. This provides the ability to deploy a PIX firewall in a secure bridging mode. It provides rich Layer 2 through 7 security services as a Layer 2 device. Remember these points while implementing a Transparent Firewall on the PIX Firewall: One inside and outside interface is supported for the transparent firewall. Each directly connected network must be on the same subnet. A management IP address must be configured and should be on the same subnet as the connected network. This management IP address cannot be a default gateway for connected devices, so you should point to the other router's IP address as your default gateway. The PIX uses this IP address as the source address for packets that originate on the outside interface. You can pass non-IP traffic such as Internetwork Pack Exchange (IPX) traffic using an EtherType ACL to allow non-IP traffic through. Dynamic routing protocols will run on the device and will pass through the PIX. NAT is not supported. NAT is performed on the upstream router. You must use an extended ACL to allow Layer 3 traffic, such as IP traffic, through the PIX.
If you configure multiple contexts with Transparent Firewall, you must note the following points: A management IP address is required for each context, even if you do not intend to use Telnet to the context. For multiple context modes, each context must use different VLANs; you cannot share a virtual LAN (VLAN) across contexts. For multiple context mode, each context can use the same (overlapping) subnet or different subnets under different VLANs. Be sure that the upstream router performs NAT if you use overlapping subnets.
You might encounter several limitations with Transparent Firewall and VPN implementations: VPN tunnels are allowed only when configured for single (Routed) context mode. To-the-box IPsec traffic is supported. Through-the-box IPsec data, or data carried through a tunnel destined for the secure side of the transparent firewall, is not supported. Only static crypto maps are supported. The IP address configured for the management access is the VPN peer address. WebVPN is not supported while the device is operating in transparent mode. Only L2L tunnels are supported, and only one tunnel at a time. X-Auth and mode config attributes should not be used during tunnel negotiation, but are configurable. VPN tunnel cannot be initiated from the firewall (answer only). VPN Load Balancing and VPN Stateful Failover are not supported. QoS of VPN data is not supported. NAT over the tunnel is not supported.
| 