Foundation TopicsHow the PIX Firewall Handles TrafficThe term network security simply refers to the application of security principles to a computer network. To apply security to a network, you must first understand how networks function. It stands to reason that to secure how traffic flows across a network, you must first understand how that traffic flows. This chapter discusses end-to-end traffic flow and how that traffic is handled by the Cisco PIX Firewall. Interface Security Levels and the Default Security PolicyBy default, the Cisco PIX Firewall applies security levels to each interface. The more secure the network segment, the higher the security number. Security levels range from 0 to 100. By default, 0 is applied to Ethernet 0 and is given the default name outside ; 100 is applied to Ethernet 1 and is given the default name inside . Any additional interfaces are configured using the nameif command. The security level for these additional interfaces can be from 1 to 99. The Adaptive Security Algorithm (ASA) allows traffic from a higher security level to pass to a lower security level without a specific rule in the security policy that allows the connection as long as a nat/global or static command is configured for those interfaces. Any traffic that passes from a lower security level to a higher security level must be allowed by the security policy (that is, access lists or conduits). If two interfaces are assigned the same security level, traffic cannot pass between those interfaces (this configuration is not recommended). Transport ProtocolsTraffic that traverses a network always has a source and destination address. This communication is based on the seven layers of the OSI reference model. Layers 5 through 7 (the upper layers) handle the application data, and Layers 1 through 4 (lower layers) are responsible for moving the data from the source to the destination. The data is created at the application layer (Layer 7) on the source machine. Transport information is added to the upper-layer data, and then network information is added, followed by data-link information. At this point the information is transmitted across the physical medium as electronic signals. The upper-layer data combined with the transport information is called a segment . As soon as the network information is added to the segment, it is called a packet . The packet is encapsulated at the data link layer (Layer 2) with the addition of the source and destination MAC address, at which point it is called a frame. Figure 5-1 shows how the data is encapsulated at each layer of the OSI reference model. Figure 5-1. Encapsulation of Upper-Layer DataThe two transport protocols most commonly used by TCP/IP are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). These protocols are very different. Each has its strengths and weaknesses. For this reason, they are used in different ways to play on their strengths:
The upper layers determine which of the transport protocols is used when data is encapsulated at the source node. Figure 5-2 illustrates the TCP communication between nodes that do not have a firewall between them. The TCP "three-way handshake" is a four-step process that requires three different transmissions to negotiate the connection:
Figure 5-2. TCP Communication Between Nodes Without a PIX FirewallNow look at how this communication is handled by the Cisco PIX Firewall (see Figure 5-3). You first notice that the number of steps required for the same transaction has changed from four to eight and the number of transmissions has increased from three to six, although everything appears to be the same to both the source and destination. Figure 5-3. TCP Communication Between Nodes with a PIX FirewallThe following is a list of actions taken by the Cisco PIX Firewall when processing a TCP handshake and opening a TCP session (refer to Figure 5-3):
The process used by the PIX Firewall to handle UDP traffic is completely different from the process that it uses for TCP traffic. This is due to UDP''''s characteristics. UDP is a connectionless protocol that does not negotiate a connection. Without any setup or termination, it is very difficult to determine the state of a UDP session. Because of the inability to determine session state, it is very easy to spoof UDP packets and hijack a UDP session. Some applications use UDP rather than TCP for data transfer. Many of these are real-time applications or applications that either have no reliability requirements or have their reliability requirements handled by the application rather than by the transport protocol. These applications include network video, Common Internet File System (CIFS), NetBIOS, Domain Name System (DNS), and remote-procedure call (RPC) applications. The default security policy allows UDP packets to pass from a higher security level to a lower security level. For UDP packets to pass in the other direction, they must be allowed by the security policy. It is very important to restrict inbound UDP access as much as possible. Due to UDP''''s limitations, many applications that operate over UDP are targets for exploitation by hackers. The Cisco PIX Firewall handles UDP traffic in the following manner:
Address TranslationThe current Internet Protocol standard being used is version 4 (IPv4). IPv4 addresses consist of 32 bits, which represents approximately 4 billion individual IP addresses. This seems like a tremendous number of addresses, but the Internet continues to grow at an incredible rate, and with the current standard, available addresses will run out. Two solutions are being implemented to help conserve the public address space or increase the number of available public addresses. The first is Internet Protocol version 6 (IPv6), a total redesign of the Internet Protocol that is still in development. The second solution is the use of RFC 1918 addressing combined with Port Address Translation (PAT). RFC 1918 sets aside network space to be used for private networks, and PAT provides a method for hiding literally thousands of private addresses behind a single public address. This private address space is not accessible via the public Internet. Static Network Address Translation (NAT) is used to create a one-to-one relationship between public addresses and RFC 1918 addresses and allows external users to access internal resources. The Internet Assigned Numbers Authority (IANA) reserved the following address space for private networks:
RFC 1918 has had a tremendous impact on Internet addressing and the design of public and private networks. The challenge to RFC 1918 addressing is that private addresses cannot be publicly routed. Hence, address translation is implemented. Address translation provides not only a method of conserving public address space, but also an additional level of protection for internal nodes because there is no way to route to a private address from the Internet. Address translation is the method used by the Cisco PIX Firewall to give internal nodes with private IP addresses access to the Internet. The internal node addresses that are translated are called local addresses , and the addresses that are translated as well are called global addresses. nat and global commands are applied to specific interfaces. Most commonly, NAT takes place, translating internal addresses to external addresses, although the PIX Firewall is not limited to this configuration. It is possible to translate any address at one interface to another address at any other interface. Two types of NAT can be implemented on a Cisco PIX Firewall:
Translation CommandsChapter 6. Table 5-2 helps you understand the syntax of the commands given in the following examples.
Network Address TranslationNAT allows you to translate a large number of local addresses behind a limited number of global addresses. This lets you keep your internal network addressing scheme hidden from external networks. To configure NAT on a Cisco PIX Firewall, you simply need to define the local and global addresses. In Figure 5-4, all nodes on the internal network are being translated to a pool of addresses on the external network. Figure 5-4. Network Address TranslationTwo commands are required to complete this configuration:
Notice the id in both the nat and global commands. It enables you to assign specific addresses to translate. The addresses in the nat command translate to the addresses in the global command that contains the same ID. The only ID that cannot be used here is 0. The command nat 0 is used on the PIX Firewall to identify addresses that are not to be translated. The nat 0 command is commonly called the "no nat" command. Chapter 7, "Configuring Access." Port Address TranslationPAT enables you to translate your local addresses behind a single global address. The commands required to perform PAT are exactly the same as the commands to perform NAT. The only difference in defining PAT is that you define a single global address rather than a range. Figure 5-5 shows all local nodes behind a single global address being translated. Figure 5-5. Port Address TranslationThe correct syntax for configuring PAT uses the nat and global commands and is depicted here: LabPIX(config)# nat [ ( internal_if_name ) ] id local_ip network_mask The following is an example of the correct syntax for configuring the nat portion of PAT for an internal network consisting of 10.0.0.0 addresses: LabPIX(config)# nat (inside) 4 10.0.0.0 0.0.0.0 Here is the global command syntax: LabPIX(config)# global [ ( external_if_name ) ] id global_ip netmask network_mask The following is an example of the correct syntax for configuring the global portion of PAT for the external address 192.168.0.10: LabPIX(config)# global (outside) 1 192.168.0.10 netmask 255.255.255.255 Static TranslationAlthough static translation is not specifically defined as an exam topic, it is very important for you to know the commands and to understand how static translation works. Static translation maps a single local address to a single global address. It is most commonly used when the local node must be accessed from the public space (Internet).
LabPIX(config)# [ static ] ( local_if_name, global_if_name ) { global_ip /interface} local_ip
In the following command, the local node 10.10.10.9 is configured to have a global address of 192.168.0.9. Remember that the static command configures only the address translation. To allow access to the local node from a lower security level interface, you need to configure either a conduit or an access list: LabPIX(config)# static (inside, outside) 192.168.0.9 10.10.10.9 LabPIX(config)# conduit permit tcp host 192.168.0.9 eq www any or LabPIX(config)# access-list 101 permit tcp any host 192.168.0.9 eq www If you are using an access list, you need to create an access group to apply the access list to the correct interface: LabPIX(config)# access-group 101 in interface outside Chapter 7 discusses conduits and access lists in greater detail. This is the configuration used in Figure 5-6. Note that the node is now accessible from the Internet. Figure 5-6. Static TranslationUsing the static Command for Port RedirectionOne of the improvements of PIX OS Version 6.0 is that the static command can be used to redirect services to specific ports and to translate the host''''s address. This command enables the outside user to connect to a specific address/port and have the PIX Firewall redirect the traffic to the appropriate inside/DMZ server. The syntax for this command is as follows:
LabPIX(config)# [ static ] ( local_if_name, global_if_name ) { tcp | udp } { global_ip/
interface} local_ip local port netmask mask [ norandomseq ] [ max connections [ emb_limit ]]
For example: LabPIX(config)# static (inside, outside) tcp 192.168.0.9 ftp 10.10.10.9 2100 netmask 255.255.255.255 0 0 The configuration in the preceding example would redirect all traffic that hits the outside interface of the PIX Firewall for IP address 192.168.0.9 on TCP port 21 to 10.10.10.9 on TCP port 2100. Configuring Multiple Translation Types on the Cisco PIX FirewallIt is a good practice to use a combination of NAT and PAT. If you have more internal hosts than external IP addresses, you can configure both NAT and PAT. Your first group of hosts translates to the global addresses that are listed and the remaining hosts use PAT and translate to the single global address. PAT is configured separately from NAT. If NAT is configured without PAT, once the available global IP address range is depleted, additional translation attempts will be refused. If the location has any servers that need to be accessed from the Internet (web servers, mail servers, and so on), they must be configured for static translation. In the following examples, the internal network consisting of 254 hosts translates to 52 external addresses (192.168.0.10 to 192.168.0.62). This means that the remaining 202 hosts translate to 192.168.0.63. LabPIX(config)# nat [ ( local_interface ) ] id local_ip network_mask LabPIX(config)# nat (inside) 1 10.10.10.0 255.255.255.0 LabPIX(config)# [ global ] [( global_interface )] id global_ip [ netmask ] network_mask LabPIX(config)# global (outside) 1 192.168.0.10-192.168.0.62 netmask 255.255.255.192 LabPIX(config)# [ global ] [( global_interface )] id global_ip [ netmask ] network_mask LabPIX(config)# global (outside) 1 192.168.0.63 netmask 255.255.255.255 Note It is recommended that you segregate from the rest of the internal network any devices that have a static translation and are accessed from the Internet. These devices should be on a separate network segment that connects to an additional interface on the PIX Firewall. This is normally called a demilitarized zone (DMZ) segment. Note The addresses assigned for static translation cannot be part of the global IP pool. This is a one-to-one relationship between the outside address and the address being translated. Example 5-1 shows the commands for this type of configuration. Example 5-1. Configuring Multiple Translation TypesLabPIX(config)# nat (inside) 1 0.0.0.0 0.0.0.0 LabPIX(config)# global (outside) 1 192.168.0.10-192.168.0.61 netmask 255.255.255.192 LabPIX(config)# global (outside) 1 192.168.0.62 netmask 255.255.255.255 LabPIX(config)# static (DMZ, outside) 192.168.0.2 172.16.1.2 LabPIX(config)# static (DMZ, outside) 192.168.0.3 172.16.1.3 LabPIX(config)# static (DMZ, outside) 192.168.0.4 172.16.1.4 LabPIX(config)# access-list 101 permit tcp [ any ] host 192.168.0.2 eq smtp LabPIX(config)# access-list 101 permit tcp any host 192.168.0.3 eq www LabPIX(config)# access-list 101 permit udp [ any ] host 192.168.0.4 eq domain LabPIX(config)# access-group 101 in interface outside Figure 5-7 depicts the configuration shown in Example 5-1. Note that the traffic that is allowed inbound is routed to the DMZ rather than going to the internal network. Remember that static translation provides the mechanism for external hosts to connect to internal nodes, but because the connection is from a lower security level to a higher security level, there must be a rule in the security policy allowing the connection. Figure 5-7. Combined NAT, PAT, and Static TranslationBidirectional Network Address TranslationCisco PIX Firewall software version 6.2 allows NAT of external source IP addresses for packets traveling from the outside interface to an inside interface. All the functionality available with traditional nat, pat , and static commands is available bidirectionally. Translation Versus ConnectionConsider this scenario: A single user on a workstation located on the internal network is connecting to his web-based e-mail account, making an online stock purchase, researching a new software package that he intends to buy, and backing up a database at a remote branch office. How many connections does he have going from his workstation? It is difficult to tell because many of these tasks require multiple connections between the source and destination. How many translated sessions does he have going? One. Most configurations create a single translated session, and from that session the user can create multiple connections. It is possible to create multiple translated sessions. This normally occurs when the internal node is accessing resources via different network segments all attached to the firewall (such as outside, DMZ1, DMZ2, and so on). Translation occurs at the network layer (Layer 3) of the OSI reference model and deals only with packets. Connections, however, deal with the transport layer (Layer 4). Therefore, connections can be considered a subset of a single translation. It is possible to troubleshoot both translation and connection issues. It is recommended that you verify translation before attempting to troubleshoot a connection problem because the connection cannot be established if the translation has not occurred. The argument or keyword used to troubleshoot translations is xlate . You can see the translation table by using the command show xlate , or you can clear the table with clear xlate . Any time you make a change to the translation table, it is a good idea to use clear xlate . This forces the translation slots to drop, and the Cisco PIX Firewall rebuilds the translation table. If you do not run the clear xlate command, the system does not drop the translation slots until they time out, which is 3 hours by default. The following commands can make a change to the translation table:
Table 5-3 documents the options and arguments that are available with the show xlate and clear xlate commands. Table 5-4 lists the translation flags.
If you cannot clear xlate , it is possible (but not preferred) to clear the translation table by doing a reload or by rebooting the PIX Firewall. The command used to troubleshoot connections is show conn . This command displays the number and status of all active TCP connections for the specific options selected. Table 5-5 lists the many options for the show conn command. Table 5-6 lists the connection flags.
Configuring DNS SupportIt is not necessary to configure DNS support on the Cisco PIX Firewall. By default, the PIX Firewall identifies each outbound DNS request and allows only a single response to that request. The internal host can query several DNS servers for a response, and the PIX Firewall allows the outbound queries. However, the PIX Firewall allows only the first response to pass through the firewall. All subsequent responses to the original query are dropped. PIX Version 6.3(2) includes a DNS fixup protocol that enables you to configure a maximum packet length for connections to UDP port 53. The default value is 512 bytes. If you configure the DNS fixup protocol, the PIX Firewall drops all connections to UDP port 53 that exceed the configured maximum length. The command for this configuration is fixup protocol dns [ maximum length <512-65535>] |
![[View full size image]](/image/library/english/13782_05fig05_alt.gif;380136){kind=link}