CCSP Cisco Secure PIX Firewall Advanced Exam Certification Guide, Second Edition [Electronic resources] نسخه متنی

Foundation Topics

How the PIX Firewall Handles Traffic

The 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 Policy

By 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 Protocols

Traffic 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.

The 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:

• TCP A connection-oriented transport protocol that is responsible for reliability and efficiency of communication between nodes. TCP completes these tasks by creating connections as virtual circuits that act as two-way communications between the source and destination. TCP is very reliable and guarantees the delivery of data between nodes. TCP also can dynamically modify a connection''''s transmission variables based on changing network conditions. TCP sequence numbers and TCP acknowledgment numbers are included in the TCP header. These features allow the source and destination to verify the correct, orderly delivery of data. Unfortunately, the overhead required for TCP can make it slow and keeps it from being the optimum transport protocol for some connections.

• UDP A connectionless transport protocol that is used to get the data to the destination. UDP provides no error checking, no error correction, and no verification of delivery. UDP defers the reliability issues to the upper-layer protocols and simply sends the data without verifying delivery. UDP is a very simple and very fast protocol.

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:

1. The source sends a segment to the destination, asking to open a TCP session. A TCP flag is set to SYN, indicating that the source wants to initiate synchronization or a handshake. The source generates a random TCP sequence number. In this example we will use 125.

2. The destination receives the request and sends back a reply with the TCP flags ACK and SYN set, indicating an acknowledgment of the SYN bit (receive flow) and initiation of the transmit flow. It generates and sends its own random TCP sequence number, 388, and replies to the original TCP sequence number by adding 1, sending back a sequence number of 126. The source receives the SYN/ACK and sends back an ACK to indicate the acknowledgment of the SYN for the setup of the receive flow. It adds 1 to the value of the TCP sequence number generated by the destination and sends back the number 389.

3. The acknowledgment is received, the handshake is complete, and the connection is established. Note in Figure 5-2 that the source begins to send data to the destination as soon as the connection is established.

Now 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.

The 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):

1. The source machine initiates the connection by sending a packet with the SYN flag set. It is received by the Cisco PIX Firewall en route to the destination. The PIX Firewall verifies the connection against the running configuration to determine if translation is to be completed. The running configuration is stored in memory, so this process occurs very quickly. The PIX Firewall checks whether the inside address, 10.10.10.10, is to be translated to an outside addressin this case, 192.168.1.10. If the translation is to be completed, the PIX Firewall creates a translation slot if one does not already exist for this connection.

2. All the session information is written to the state table, and the Cisco PIX Firewall randomly generates a new TCP sequence number. This connection slot is marked in the state table as an embryonic (half-open) connection.

3. After the connection is verified against the security policy, the PIX Firewall allows the connection outside using the translated source address and the newly generated TCP sequence number.

4. The destination receives the connection request (SYN) and replies with an SYN ACK.

5. The PIX Firewall verifies the SYN ACK from the destination and matches the acknowledgment number against the randomly generated sequence number. It verifies the connection slot and forwards the connection back to the source using the original source address and original sequence number plus 1.

6. Any packets that do not match the session object exactly are dropped and logged.

7. The source completes the connection by responding with an ACK. The acknowledgment number is not randomized as it passes through the PIX Firewall, and the connection slot is marked as active-established.

8. The embryonic counter is reset, and data is transmitted between the nodes.

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:

1. The source machine initiates the UDP connection. It is received by the PIX Firewall en route to the destination. The PIX Firewall applies the default rule and any necessary translation, creates a session object in the state table, and allows the connection to pass to the outside interface.

2. Any return traffic is matched with the session object, and the session timeout is applied. The session timeout is 2 minutes by default. If the response does not match the session object or is not within the timeout, the packet is dropped. If everything matches, the response is allowed through to the requesting source.

3. Any inbound UDP sessions from a lower security level to a higher security level must be allowed by the security policy, or the connection is dropped.

Address Translation

The 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:

10.0.0.0 through 10.255.255.255: 16,777,214 hosts

172.16.0.0 through 172.31.255.255: 1,048,574 hosts

192.168.0.0 through 192.168.255.255: 65,534 hosts

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:

• Dynamic address translation Translates multiple local addresses into a limited number of global public addresses or possibly a single global address. This is called dynamic address translation because the firewall selects the first available global address and assigns it when creating an outbound connection. The internal source retains the global address for the duration of the connection. Dynamic address translation is broken into two types:

  - Network Address Translation (NAT) Translating multiple local addresses to a pool of global addresses.

  - Port Address Translation (PAT) Translating multiple local addresses to a single global address. This method is called Port Address Translation because the firewall uses a single translated source address but changes the source port to allow multiple connections via a single global address. The limitation for PAT is approximately 64,000 hosts because of the limited number of available ports (65,535) and the number of ports already assigned to specific services. Some applications do not work through PAT because they require specific source and destination ports.

• Static translation Allows for a one-to-one translation of local to global addresses. Static translation is commonly used when the internal node must be accessed from the Internet. Web servers and mail servers must have static addresses so that users on the Internet can connect to them via their global address.

Translation Commands

Chapter 6. Table 5-2 helps you understand the syntax of the commands given in the following examples.

Network Address Translation

NAT 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.

Two commands are required to complete this configuration:

• nat Defines the addresses to be translated:

  
  LabPIX(config)#  nat  [ (  internal_if_name  ) ]  id local_ip  [ network_mask ]
  

  Here is an example:

  
  LabPIX(config)#  nat (inside) 1 0.0.0.0 0.0.0.0 
  

• global Defines the pool of addresses to translate to:

  
  LabPIX(config)# global [ (  external_if_name  ) ]  id  { global_ip[-global_ip ] [ netmask 
   network_mask ]| interface }
  

  Here is an example:

  
  LabPIX(config)#  global (outside) 1 192.168.0.10-192.168.0.62 netmask   255.255.255.192 
  

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 Translation

PAT 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.

The 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 Translation

Although 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.

Using the static Command for Port Redirection

One 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 Firewall

It 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 Types

LabPIX(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.

Bidirectional Network Address Translation

Cisco 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 Connection

Consider 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:

• nat Identifies the internal address that should be translated.

• global Identifies the external address or addresses to which internal addresses translate.

• static Allows external users to connect to specific addresses and have the PIX Firewall redirect that connection specific internal/DMZ address. The static command also can be used for port redirection.

• route Provides routing functionality for traffic that is traversing the PIX Firewall.

• alias Was used to translate addresses between overlapping networks but now is used infrequently because of the recent improvements in the functionality of the nat and static commands.

• conduit Configures the firewall to apply specific rules based on conduits to the traffic. Conduits are not commonly used because of the increased performance and functionality of ACLs.

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 Support

It 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>]