Translations and Connections
Translations and Connections
In this section, you see the details of the translation process and the resulting connections. The better these concepts are understood, the easier it is to understand the PIX security algorithms (ASA) and how they work.
To understand how ASA can perform stateful analysis and recognize common attack attempts, it’s necessary to review the data encapsulation/deencapsulation process introduced in any basic networking course. Figure 19-4 shows a common depiction of the process, with each layer’s encapsulation becoming the next layer’s payload. The TCP/IP model combines the top three layers into a single step.
Figure 19-4: OSI model encapsulation process
Remember, the little “header” blocks in the diagram are, in fact, multiple binary bits that convey information about the payload. The obvious examples are the bits’ desig- nating source and destination IP addresses in the network layer header. But there’s additional information that a savvy programmer with a strong algorithm could use to make determinations about what’s happening in the communication session. Figure 19-5 shows the IP header information from a packet capture using the Fluke Network Optiview Protocol Expert.
Figure 19-5: IP header information
While some of the information, such as the IP addresses, was converted to decimal form, other information, such as the fragmentation bits and Type of Service (TOS) bits, shows the type of detail carried in every IP header. Note that the Protocol ID, converted to decimals, indicates the payload is a TCP segment.
Figure 19-6 shows the TCP header fields from the previous captured packet. Clearly visible are the decimal equivalents of the sequence and acknowledgment numbers used to ensure proper data order and to show no segments are missed. The flag bits are used in the TCP session setup, data exchange, and tear-down processes.
Figure 19-6: TCP header information showing flag bits and other fields
The Source port—139—indicates this is a NetBIOS session service packet. Looking at the session layer information, not shown, reveals the packet is a Session Keepalive Packet. The upper-layer headers, OSI layers 5 to 7, or the TCP/IP application layer can either be quite simple or complex. Figure 19-7 shows only a small portion of an SNMP frame header. The more that ASA programming can interpret these pieces of information, the more granular and powerful it can be in maintaining its “state” table and allowing legitimate traffic flows.
Figure 19-7: TCP/IP application layer header for SNMP data
ASA has both the capability to look at these upper-layer fields in the packet and is programmed to recognize appropriate values. This allows ASA to accept packets where an address/port combination might vary from the current state table entry because the upper-layer field entries are consistent with a known possible change.
Transport Protocols
The PIX Firewall can inspect a variety of protocols at Layer 3 and above. For example, in discovering ICMP packets, ASA automatically blocks them, unless ACLs were created to allow that specific ICMP message type.
Two of the most common protocols are the transport layer protocols TCP and UDP. ASA, such as the PIX IOS CBAC feature, have special processes and techniques for managing traffic flows for each. The differences between these two protocols should be familiar from CCNA studies. The implications for firewall filtering are
-
Transmission Control Protocol (TCP), being connection-oriented with well-defined session setup, data transfer, and tear-down characteristics, this is relatively easy to inspect and monitor.
-
User Datagram Protocol (UDP), being connectionless and, by definition, somewhat unpredictable in that it simply shows up, this is much more difficult to inspect and monitor.
Transport Control Protocol
TCP traffic, because of its predictable setup, data transfer, and tear-down sequence, allows the PIX firewall to add additional security by substituting a randomized sequence number to make it more difficult for someone eavesdropping on the traffic to insert or replay traffic. In addition, monitoring for an excessive number of half-open, or embryonic, sessions is possible, which could indicate a form of denial of service (DoS) attack is underway.
Figure 19-8 shows an outgoing packet to host 10.2.2.45 before and after the PIX NAT has translated the source IP address and the PIX has created a randomized sequence number. Note that the SYN bit, from Figure 19-6, is the only flag bit set, indicating the first packet of a new session. This information is used by the PIX to create a new xlate table entry, if necessary, and a new state entry in the state table.
Figure 19-8: First step of the TCP setup handshake
Figure 19-9 shows the first returning packet from host 10.2.2.45. The state table is checked for an existing session, and the field details are confirmed as consistent with an expected packet. The PIX retranslates the destination address to the correct local address using the xlate table. The acknowledgment number is the original sequence number incremented, and then is translated before passing into the local network. TCP uses forward acknowledgment, meaning the acknowledgement number is the next sequence number expected. The actual acknowledgement number then reflects the “window” increment used for flow control.
Figure 19-9: Second step of the TCP setup handshake
Note that both the SYN and ACK flag bits are on, which indicates this is the second step in the handshake. If both the SYN and ACK flag bits aren’t on, the packet will be dropped for not being the next expected step. The SYN bit is on because host 10.2.2.45 is supplying its synchronization number to the local host.
The next exchange and all exchanges during data transfer would have only the ACK bit set because each exchange acknowledges the last transmission from the other party. The NAT translations would continue as they are. The sequence and acknowledgement fields would be appropriately incremented.
Any packet traffic that doesn’t match the key fields of the state table or appears out of order is dropped. Even if the source and destination address/port number combinations are correct, if the packet doesn’t fit, the expected step could mean the packet has been manipulated or replayed by someone running a “man-in-the-middle” attack.
FIN and RST Bits
If the session is interrupted, a packet with the RST (reset) bit set turned on could be received or, if either host wants to stop the session, the FIN (finish) bit would be turned on. In either case, the PIX device knows the session is ending and removes any related xlate and state table entries, thereby reducing the vulnerability to unauthorized use.
Unauthorized Return Traffic
If host 10.2.2.45 were to attempt to send additional packets, even a packet with the SYN bit on and ACK bit off, indicating a new session, the attempt would be blocked because no existing state table entry would be available. Because the original translation was done with NAT (or PAT), there wouldn’t be a static entry allowing the unsolicited data.
Authorized Inbound Traffic
Assuming the inbound traffic is destined to a shared server, the static address translation is in the xlate table and an enabling access control list allows the unsolicited inbound packet. The SYN bit is on and the ACK bit is off. A state table entry is made, and any necessary translation is performed before the packet passes into the more secure network, typically DMZ, but it could be inside. This state table entry is an “embryonic” TCP session, indicating it’s incomplete. The state table entry remains in this state until the three-way handshake is complete and ACK packets are being exchanged.
The inside host then performs Step 2 in the TCP handshake and things progress, as described earlier. Each exchange in both directions is reviewed and the state table is updated as necessary.
SYN Attacks
A common form of DoS attack is some variation of a SYN attack where large numbers of SYN packets are received by the inside device and appropriate reply exchanges are prepared and sent. Unfortunately, the sender has no intention of completing these sessions, so the final step of the handshake is never completed. If you recall from Chapter 1, this type of attack can be successful by either overloading the target host or by congesting the link to the target host. Either way, legitimate traffic and activity can’t get service.
PIX Firewalls can monitor both the number of embryonic sessions and the time it takes to complete them. This information can be used by the PIX to trigger discarding embryonic sessions to keep the host from being buried. Unfortunately, while the PIX can protect the target device from too many half-open sessions, it might need assistance from an upstream Internet service provider (ISP) to keep the link from becoming clogged.
User Datagram Protocol
Because UDP doesn’t establish a connection-oriented session, it’s harder to protect. The PIX creates a state table entry any time a UDP packet is sent from a secure interface to a less-secure interface. This entry can only have the basic source, and destination addresses and port numbers. Any UDP traffic arriving from the less-secure interface that matches the state table entries is allowed to pass through.
Common UDP datagrams, such as DNS and NFS, are frequent targets of attacks, so it’s important that UDP connections be restricted. PIX units have a feature that only allows one DNS server to respond to a DNS query. Any additional responses are discarded. This reduces the likelihood of an attacker submitting a bogus response and directing output to a bad destination. To reduce exposure further, the state table entries created from the outgoing UDP datagrams have default lives of only two minutes, configurable, to see returning traffic before they’re removed.
Static Translations
The PIX static command creates a persistent, one-to-one address translation rule to add to the xlate table. This entry is called a static translation slot or xlate. In its simplest form, the command maps a local IP address to a global IP address. This is often referred to as a static NAT translation.
Static address mappings are created to provide outside access to shared resources, such as web servers. These shared resources must be available to outside users or servers without an originating request from within the more secure interfaces of the firewall. Static mappings shouldn’t normally be used with user hosts because their mappings should be added on in an as-needed basis by standard NAT translations. The NAT translations exist only for the time needed and then are removed from the xlate table. Static mappings, on the other hand, stay in the xlate table permanently.
The command syntax includes the interfaces, highest then lowest, followed by the addresses that are reversed to be lowest then highest. Figure 19-10 shows an example of a DMZ server that needs to be accessed from the outside. The next lines show the basic syntax, followed by a simple example translating a protected server—192.168.2.3—to be accessible from the outside as 10.1.1.7. Yes, in real life, this wouldn’t be another private address.
Figure 19-10: Protected DMZ server that must be accessed from the outside
Pix(config)# static (hi_interface, lo_interface) lo_ip_address hi_ip_address
Pix(config)# static (dmz, outside) 10.1.1.7 192.168.2.3
Remember the following about static mappings:
-
After changing or removing a static command statement, use the clear xlate command to make sure the xlate table entries are valid.
-
Static mappings always take precedence over mappings created using the NAT command.
-
Never use an address in a global address pool for static mapping.
Static Alone Is Not Enough
Note that the xlate table translation created by the static command, by itself, won’t allow outside traffic to access the server. While the static command created a valid global address that could be used, ASA blocks traffic from lower security areas to higher. Enabling the inbound traffic by creating an access-list is still necessary. The static command creates the mapping and the access list allows users to use the static command mapping. The additional lines required to finish the previous example might look like this:
Pix(config)# static (static, outside) 10.1.1.7 192.168.2.3
Pix(config)# access-list acl_server permit tcp any host 10.1.1.7
Pix(config)# access-group acl_server in interface outsidePix(config)# clear xlate
The access list command is covered in the section “Access Control Lists,” and it won’t be included in the remaining static command examples, but remember, the static command is only part of the solution.
Static Command Options
The static command creates a persistent or permanent one-to-one address translation entry in the xlate table. When the translation is between a local IP address and a global IP address, it’s called static NAT. When the translation is between local and global ports, it is called static PAT. The Static Command options might not all be supported on all PIX Firewall OS versions. The following Syntax options are from version 6.2.
Static NAT
Use the following form of the static command to perform one-to-one address translation. Use the no form of the command to remove the static translation.
Pix(config)# static [(hi_interface, lo_interface)] global_ip local_ip [netmask mask] [norandomseq] [max_conn [em_limit]]
Pix(config)# no static [(hi_interface, lo_interface)] global_ip local_ip [netmask mask] [norandomseq] [max_conn [em_limit]]
|
hi_interface |
The higher security-level interface between the two. |
|
lo_interface |
The lower security-level interface between the two. |
|
global_ip |
The real global address the local_ip is translated to. |
|
local_ip |
The internal address to be mapped. |
|
netmask |
The key word required before defining a network mask. |
|
mask |
This network mask applies to both the global_ip and local_ip addresses. Use 255.255.255.255 for host addresses. For a network or subnet address, use the appropriate mask, for example, 255.255.255.240. |
|
norandomseq |
Turns off the randomized TCP/IP packet’s sequence number feature for this translation because another firewall is also randomizing sequence numbers and the two together are scrambling the data. Opens a security hole in the firewall. |
|
max_conn |
Maximum simultaneous connections permitted through the static. Default is 0, which allows unlimited connections. |
|
em_limit |
The embryonic or half-open TCP connection limit. Setting this limit can prevent a common type of DoS attack. Default is 0, which allows unlimited connections. |
Mapping a Range of Static Translations
While the Netmask Mask option is relatively common to see using 255.255.255.255 for host translations, it might not be obvious that using another mask would define multiple translations. The resulting range of static translations is known as net statics. In the following example, the addresses 192.168.2.33 to 192.168.2.46 will be translated to 10.1.1.33 to 10.1.1.46. Figure 19-11 shows a pool of shared servers in the DMZ that need to be mapped to global addresses.
Pix(config)# static (inside,outside) 10.1.1.32 192.168.2.32 netmask 255.255.255.240 Pix(config)# clear xlate
Figure 19-11: Pool of DMZ servers that need to be mapped to global IP addresses
The PIX Firewall won’t allow inbound traffic translations that would result in IP addresses identified as either network or broadcast addresses. When the static command is used with the Netmask Mask netmask mask option, the PIX Firewall uses the global IP address and mask to determine network and/or broadcast addresses. If a global IP address is a network or broadcast as defined by the mask, the PIX won’t allow the xlate table entry. In the previous example, 10.1.1.32 (network) and 10.1.1.47 (broadcast) weren’t allowed.
Static PAT
Use the following form of the static command to perform one-to-one port translation. Use the no form of the command to remove the static translation.
Pix(config)# static [(hi_interface, lo_interface)] {tcp | udp}{global_ip | interface}
global_port local_ip local_port [netmask mask][max_conn] [em_limit] [norandomseq]
Pix(config)# no static [(hi_interface, lo_interface)] {tcp | udp}{global_ip | interface}
global_port local_ip local_port [netmask mask][max_conn] [em_limit] [norandomseq]
|
global_ip |
The real global address the local_ip is translated to |
|
global_port |
The real global port the local_port is translated to |
|
interface |
Overload the global address from interface |
|
local_ip |
The internal address to be mapped |
|
local_port |
The internally assigned port to be mapped |
In the following example, outside FTP requests to the translated global address 10.1.1.7 are translated to the internal FTP server at 192.168.1.5.
Pix(config)# static (inside, outside) tcp 10.1.1.7 ftp 192.168.1.5 ftp
No Translation Required
If real global addresses are used in one or more of the DMZs, then translating those addresses isn’t necessary. In this case, use the following form of static command where the interface IP addresses are the same to literally translate the address to itself. Use the no form of the command to remove the xlate entry.
Pix(config)# static (hi_interface, lo_interface) ip_address ip_address
Pix(config)# static (dmz, outside) 10.1.1.7 10.1.1.7
Pix(config)# static (dmz, outside) 10.1.1.32 10.1.1.32 netmask 255.255.255.240
Pix(config)# clear xlate
The first example translated a single server to itself, while the second example used a network ID and a subnet mask to define a block of addresses to be mapped to themselves. Figure 19-12 shows the pool of DMZ servers mapped in the previous example.
Figure 19-12: A pool of DMZ servers that already have global IP addresses
TCP Intercept Feature
Since version 5.3 of the PIX OS, PIX Firewalls offer a TCP intercept feature. This feature allows the PIX Firewall to step in as a form of proxy for a server being buried by embryonic TCP session requests.
To use the TCP intercept feature, the Embryonic Connection Limit (the previous em_limit ) option must be configured to something larger than the default 0. Leaving the embryonic connection limit set to 0 directs the PIX Firewall to pass through all new TCP session requests. If the destination server doesn’t have TCP SYN attack protection, and most OSs offer only limited protection, then the system’s embryonic connection table overloads and all traffic stops. This is a common component of many DoS attacks.
The following example leaves the maximum connection setting unrestricted (0), but sets the embryonic connection limit to 100.
Pix(config)# static (inside, outside) 10.1.1.7 192.168.1.3 0 100
| Note? |
The previous example is intended for demonstration purposes only and shouldn’t be considered a model for use. Setting either the maximum connections or the maximum embryonic connections can have serious repercussions for the server. Too-high values can provide no protection, while too-low values could unnecessarily restrict access to the device. The actual limits should be set based on the server’s performance capabilities. SYN attacks are addressed in the next chapter. |
Once the embryonic connection limit is reached, and until the count falls below this limit, every SYN packet (new session request) bound for the mapped server (192.168.1.3) is intercepted by the PIX Firewall. The PIX then responds on behalf of the server with a SYN/ACK (Step 2) packet attempting to complete the connection. The PIX creates a state table entry with the pertinent information from the received packet. The original packet is dropped and the PIX waits for the client’s acknowledgment.
If the expected ACK is received (Step 3), completing the three-way handshake, a copy of the client’s SYN packet is sent to the local server, and the TCP three-way handshake is performed between the PIX Firewall and the server. If this three-way handshake is completed successfully, then the connection between the client and the server resumes as normal.
If, for any reason, the client doesn’t respond during the connection phase, then PIX Firewall retransmits the necessary segment using exponential back-offs, just as the server would and, eventually, discards the information.
Prior to version 5.3, if the embryonic connection limit was configured and the level was exceeded, the PIX Firewall simply dropped all new connection attempts. While this might have been better than nothing, the result was that the server was no longer available, which could have been the purpose of the attack.
Network Address Translation
While static address mappings allow permanent outside access to inside resources like servers, users also require address translation to venture into less secure networks, such as the outside. To reduce the window of vulnerability that permanent static mappings introduce, users generally use the nat/global command combination to create temporary mappings while they’re in the less-secure area. These mappings are removed after the session ends.
NAT syntax and operation were covered in Chapter 17. This section concentrates on those options and implications that might not have been covered earlier. The nat and global commands are always used together, the nat command defining the local host(s) that can be translated to travel to less-secure networks. The global command identifies the pool of “real” global IP addresses that can provide access to the less-secure network. The nat_id identifies the pool of global addresses that can be accessed by the nat command. The two basic command syntaxes are
Pix(config)# global (if_name) nat_id {global_ip [-global_ip] [netmask global_mask] | interface}
Pix(config)# nat (if_name) nat_id local_ip [netmask]
The following example creates a global address\pool, nat_id = 1, that contains all the class C network 215.1.2.0, plus the 31 host addresses included in 1.1.1.1-1.1.1.30. The nat command allows all hosts on the 192.168.1.0 inside network to start outbound connections.
Pix(config)# global (outside) 1 215.1.2.0 Pix(config)# global (outside) 1 1.1.1.1-1.1.1.30 netmask 255.255.255.224 Pix(config)# nat (inside) 1 192.168.1.0 255.255.255.0
Remember the following about global/nat address mappings:
-
After changing or removing a nat command statement, use the clear xlate command.
-
You can define up to 256 global pools of addresses.
-
Never use an address in a global address pool for static mapping.
-
Static mappings always take precedence over mappings created using the nat command.
An All Hosts Option
The next examples show a handy shorthand to allow all inside hosts to use NAT to create outbound connections. The 0 0 is a short notation for the local_ip /netmask combination 0.0.0.0 0.0.0.0.
Pix(config)# nat (inside) 1 0 0
Additional NAT Options
The nat command lets you enable or disable address translation for one or more internal addresses. Some of the options available, such as norandomseq, conn_limit, and em_limit, are the same as covered in the static command section. To enable NAT for an address or group of addresses, use the following syntax. Use the no command to turn off the feature.
Pix(config)# nat (if_name) nat_id ip_address [netmask] [outside] [dns] [norandomseq]
[timeout hh:mm:ss] [conn_limit] [em_limit]
Pix(config)# no nat (if_name) nat_id address [netmask] [outside]
To disable NAT for an address or group of addresses, use the following syntax. Use the no command to turn off the feature.
Pix(config)# nat (if_name) 0 access-list acl_name
Pix(config)# no nat (if_name) 0 [access-list acl_name]
|
nat_id |
Values can be 0, 0 access-list acl_name, or a number greater than zero. See the following explanation of the choices. |
|
outside |
Enable or disable address translation for the external addresses. Introduced in v6.2 to support access control, IPSec, and AAA that use the real outside address. |
|
dns |
Any DNS replies that match the xlate are translated. |
|
timeout hh:mm:ss |
Sets an idle timer for the translation slot. |
|
access-list acl_name |
Used with the nat 0 command to exempt traffic that matches the access list from NAT processing. |
NAT_ID Options
The nat_id option in the nat command can have serious implications for how the NAT process works. The next paragraphs offer an explanation and examples of each choice.
NAT 0
The nat 0 turns off NAT translation for the defined address(es). The result is called identity translation, which is a translation that maps an address to itself. This command assumes the host address is a valid global address that can be used out in the Internet.
At first glance, this seems like the Static Command option of using the current IP address for both addresses. The difference between this command and the Static option is that this option requires that any resulting traffic must be initiated from an inside host, while the Static Command option allows outside hosts to precipitate access to inside resources. So, if you want the addresses to be visible to the outside, use the static command.
In the following example, the first entry shows an identity translation using the nat 0 command, while the second uses the more public static command.
Pix(config)# nat (dmz) 0 1.1.1.15
Pix(config)# static (dmz, outside) 1.1.1.15 1.1.1.15
The next examples show the same commands using a class C size group of hosts. The first would be used to allow a group of user hosts with valid global IP addresses to travel the Internet without translation. The second would be used to make a large pool of shared servers available to the outside world, assuming appropriate ACLs are created.
Pix(config)# nat (dmz) 0 1.1.2.0 255.255.255.0
Pix(config)# static (dmz, outside) 1.1.2.0 1.1.2.0 netmask 255.255.255.0
NAT 0 Access-List ACL_Name
The NAT 0 Access-List acl_name command variation uses an access control list to specify the traffic to exempt from NAT processing. This is particularly useful in VPN configuration where traffic needs to be exempted from NAT. This command assumes the host address is a valid global address that can be used out in the Internet.
The following example demonstrates using this Command option to permit the internal host 1.1.1.15 to bypass NAT when connecting to outside host 1.1.2.19.
Pix(config)# access-list skip-nat permit ip host 1.1.1.15 host 1.1.2.19
Pix(config)# nat (inside) 0 access-list skip-nat
NAT_ID Greater Than 0
This is normal NAT with the nat_id greater than zero (0), indicating a pool of global IP addresses specified by the global command. The same nat_id in a nat command and global command links the two together.
The following example demonstrates using the global command to create a global address pool (9) with 508 addresses. The nat command allows the hosts on LAN network 192.168.1.0 to access that pool. The net_id, which is 9 in all three commands, links them together.
Pix(config)# global (outside) 9 1.1.2.1-1.1.2.254 Pix(config)# global (outside) 9 1.1.3.0 netmask 255.255.255.0 Pix(config)# nat (inside) 9 192.168.1.0 255.255.255.0
No Network or Broadcast IDs Allowed
ASA won’t allow network or broadcast IDs to be included in the xlate table entries. If the Netmask global_mask option is used with a network ID to define a pool of addresses, the PIX automatically excludes the host ID and broadcast addresses from the pool available for translations.
ASA specifies a subnet mask, for example, 255.255.255.128 specifies one half of a class C network. If a specified address range in the global_ip-global_ip overlaps subnets defined by the netmask global_mask statement, the global pool won’t use any broadcast or network addresses included in the pool of global addresses. In the following global command, the pool is the first 16 addresses on the 10.1.1.0 network (10.1.1.0-15).
Pix(config)# global (outside) 1 10.1.1.0 netmask 255.255.255.240 Pix(config)# nat (inside) 1 192.168.1.0 255.255.255.0
Because 10.1.1.0 is the network and 10.1.1.15 is the broadcast address for the network, they’ll be excluded from the actual pool, leaving 10.1.1.1 to 10.1.1.14. Another way this could be defined is the following:
Pix(config)# global (outside) 1 10.1.1.1-10.1.1.14 Pix(config)# nat (inside) 1 192.168.1.0 255.255.255.0
Confirm NAT/Global Configuration
To display the results of the global and nat commands, use the following commands:
-
show global
-
show nat
-
write terminal
-
show xlate
Port Address Translations (PAT)
PAT is a variation of NAT that allows multiple inside hosts to use the same global IP address. Having to maintain a large pool of global addresses can be expensive and puts increased pressure on addresses that are in short supply worldwide. PAT combined with using private addresses within the network can save money and preserve real IP addresses.
The alternative is to have the NAT feature create a unique xlate for each session by using a single global IP address and appending a unique port number, such as 1.1.1.1:1540. While over 64,000 usable port numbers exist (65,536-1,023 reserved), the effective limit is much lower, usually estimated at about 4,000. PAT is often a viable solution when an ISP can’t allocate enough unique IP addresses for the organization’s outbound connections.
PAT can be enabled by entering a single IP address with the global command or by using the Interface option with the same command. The Interface option specifies that the named interface IP address is the one to be used.
Pix(config)# global (if_name) nat_id {global_ip [-global_ip] [netmask global_mask] | interface}
The first example creates a global address pool with only one “real” address, and then allows all LAN hosts to use the PAT translations.
Pix(config)# global (outside) 5 1.1.1.25
Pix(config)# nat (inside) 5 0 0
The next example uses the firewall outside interface IP address as the only PAT address, and then allows all LAN hosts to use the PAT translations. This could literally be the DSL or the cable modem connection address for a small network. This is the implementation requiring the smallest number of real IP addresses.
Pix(config)# global (outside) 7 interface
Pix(config)# nat (inside) 7 0 0
Remember the following about PAT implementations:
-
After changing or removing a nat command statement, use the clear xlate command.
-
An IP address used for PAT can’t be used in another global or static address pool.
-
PAT doesn’t work with H.323 applications and caching nameservers.
-
Don’t use PAT when multimedia applications need to be run through the PIX Firewall. Multimedia applications can conflict with port mappings provided by PAT.
-
PAT doesn’t work with the TCP ACL “established” option.
-
PAT does work with DNS, HTTP, URL filtering, e-mail, FTP, passive FTP, Telnet, outbound traceroute, and the UNIX RPC and rshell protocols.
Using NAT and PAT Together
The pool of available “real” addresses can be made up of multiple global statements. To augment a pool of global addresses with a PAT option, use the same nat_id in the global statements. When the pool contains both a global pool and a PAT designation, first the addresses from the global pool are used, and then the next connection uses the PAT address. Whenever a global pool address becomes available, the next connection takes that address.
In this example, a class C-sized global pool is augmented by a PAT argument using the outside interface IP address. All traffic that can’t be handled by the 1.1.3.0/24 network will be translated using PAT.
Pix(config)# global (outside) 3 1.1.3.0 netmask 255.255.255.0
Pix(config)# global (outside) 3 interfacePix(config)# nat (inside)3 0 0
Names and Name Commands
You can create and use text names for IP addresses in much the same way the IP Host command can be used on conventional routers. The name command is used to associate a single IP address and a text name. The names created become a host table local to that specific PIX Firewall only. You must first use the names command before immediately using the name command. Both the names command and any name statements created are saved in the configuration. The syntax is
Pix(config)# names
Pix(config)# name ip_address name
The clear names command clears the list of names from the PIX Firewall configuration. The no names command disables the use of the text names, but doesn’t remove them from the configuration. The show names command lists the name command statements in the configuration. The following output shows the commands to create three names, the show names command, and the result of a write terminal command.
Pix(config)# names Pix(config)# name 1.1.1.1 pix_out Pix(config)# name 192.168.1.1 pix_in Pix(config)# name 192.168.2.1 pix_dmz Pix(config)# Pix(config)# show names name 1.1.1.1 pix_out name 192.168.1.1 pix_in name 192.168.2.1 pix_dmz Pix(config)# Pix(config)# write t Building configuration... ??(output omitted) names name 1.1.1.1 pix_out name 192.168.1.1 pix_in name 192.168.1.1 pix_in ??(output omitted) Pix(config)#
The next output shows using the name with the ping command, instead of the IP address.
Pix(config)# ping pix_in ???????pix_in response received -- 0ms ???????pix_in response received -- 0ms ???????pix_in response received -- 0ms Pix(config)#
The next output shows the PIX Firewall assumes you prefer the name and substitutes the name for the address(es) whenever appropriate.
Pix(config)# show ip addresses System IP Addresses: ???????ip address outside pix_out 255.255.255.0 ???????ip address inside pix_in 255.255.255.0 ???????ip address dmz pix_dmz 255.255.255.0 Current IP Addresses: ???????ip address outside pix_out 255.255.255.0 ???????ip address inside pix_in 255.255.255.0 ???????ip address dmz pix_dmz 255.255.255.0 Pix(config)#
Remember the following about name implementations:
-
Only one name can be associated with an IP address.
-
Names can use the characters a to z, A to Z, 0 to 9, the dash, and the underscore, but no spaces. The name can’t be longer than 16 characters or start with a number.
-
One reason to create names is to make life easier. Make sure the names you create don’t add another level of complexity. The previous names could have been out, in, and dmz. Before you create names, make sure they won’t look like keywords or instructions.
Configuring DNS Support
Use the DNS option on the static command to create a one-to-one address translation only if the reply is a DNS reply. Use the no form of the command to remove the translation.
Pix(config)# static (hi_interface, lo_interface) global_ip local_ip [dns] [netmask mask]
[norandomseq] [max_conn [em_limit]]
Pix(config)# no static (hi_interface, lo_interface) global_ip local_ip [dns] [netmask mask]
[norandomseq] [max_conn [em_limit]]
The following output is an example of creating the translation for a DNS server in the network depicted in Figure 19-13.
Pix(config)# static (dmz, outside) 1.1.1.3 192.168.128.3 dns
Figure 19-13: Static translation for a DNS server on a DMZ network
Because of the high number of attacks on DNS services, PIX Firewalls now only allow the first DNS reply to pass through, and then they drop all others. This prevents man in the middle attacks, where the attacker sends a second DNS reply, creating a bogus domain name resolution that would direct the browser to the wrong site. Unfortunately, DNS service would accept the later reply and update its table.
The following static PAT translation would direct any DNS traffic directed to the PIX Firewall outside interface to be redirected to the inside DNS server at 192.168.128.3.
Pix(config)# static (dns, outside) udp interface domain 192.168.128.3 domain
