Access Lists
Access Lists
An access list typically consists of multiple access control entries (ACE) organized internally
by Security Appliance as a linked list. When a packet is subjected to access list control, the
Cisco Security Appliance searches this linked list linearly to find a matching element. The
matching element is then examined to determine if the packet is to be transmitted or
dropped. By default, all access-list commands have an implicit deny unless you explicitly
specify permit. In other words, by default, all access in an access list is denied unless you
explicitly grant access using a permit statement.
The general syntax of the access-list command is as follows:
access-list id [line line-num] deny|permit {protocol |
object-group prot-obj-grp-id} {source-addr source-mask} |
object-group netw-grp-grp-id [operator port [port] | interface if-name
| object-group service-obj-grp-id ]
{destination-addr destination-mask} | object-group new-obj-grp-id |
[operator port [port] | object-group service-obj-grp-id]}
[log [disable | default] | [level]]
Table 7-3 describes the parameters for the access-list command.
NOTE Policy NAT does not support SQL*Net, which is supported by regular NAT.
Table 7-3 access-list Command Parameters
Parameter Description
id Name of an access list. You can use either a name or number.
line-num The line number at which to insert a remark or an ACE.
deny The deny option does not allow a packet to traverse the PIX
Firewall.
permit The permit option selects a packet to traverse the PIX Firewall.
protocol Name or number of an IP protocol. It can be one of the
keywords icmp, ip, tcp, or udp, or an integer in the range of 1 to
254 representing an IP protocol number. To match any Internet
protocol, including ICMP, TCP, and UDP, use the keyword ip.
object-group Specifies an object group.
source-addr Address of the network or host from which the packet is being
sent.
source-mask Netmask bits (mask) to be applied to source-addr, if the source
address is for a network mask.
continues
An access list typically consists of multiple access control entries (ACE) organized internally
by Security Appliance as a linked list. When a packet is subjected to access list control, the
Cisco Security Appliance searches this linked list linearly to find a matching element. The
matching element is then examined to determine if the packet is to be transmitted or
dropped. By default, all access-list commands have an implicit deny unless you explicitly
specify permit. In other words, by default, all access in an access list is denied unless you
explicitly grant access using a permit statement.
The general syntax of the access-list command is as follows:
access-list id [line line-num] deny|permit {protocol |
object-group prot-obj-grp-id} {source-addr source-mask} |
object-group netw-grp-grp-id [operator port [port] | interface if-name
| object-group service-obj-grp-id ]
{destination-addr destination-mask} | object-group new-obj-grp-id |
[operator port [port] | object-group service-obj-grp-id]}
[log [disable | default] | [level]]
Table 7-3 describes the parameters for the access-list command.
NOTE Policy NAT does not support SQL*Net, which is supported by regular NAT.
Table 7-3 access-list Command Parameters
Parameter Description
id Name of an access list. You can use either a name or number.
line-num The line number at which to insert a remark or an ACE.
deny The deny option does not allow a packet to traverse the PIX
Firewall.
permit The permit option selects a packet to traverse the PIX Firewall.
protocol Name or number of an IP protocol. It can be one of the
keywords icmp, ip, tcp, or udp, or an integer in the range of 1 to
254 representing an IP protocol number. To match any Internet
protocol, including ICMP, TCP, and UDP, use the keyword ip.
object-group Specifies an object group.
source-addr Address of the network or host from which the packet is being
sent.
source-mask Netmask bits (mask) to be applied to source-addr, if the source
address is for a network mask.
continues
Policy NAT
nat 0 Command
As mentioned earlier in the text, one can configure access to higher-security subnets by using
the nat 0 command. For instance, if you have a host with a public address on the inside
network and the outside network needs access to this host, you can use nat 0, which disables
address translation so that inside IP addresses are visible to the outside. The following short
example demonstrates the use of the nat 0 command:
nat (inside) 0 192.168.1.10 255.255.255.255
This can also be configured as follows:
access-list 121 permit 192.168.1.10 255.255.255.255 any
nat (inside) 0 access-list 121
184 Chapter 7: Configuring Access
Policy NAT
Policy NAT provides additional capabilities in configuring address translation. The Policy
NAT feature lets you identify local traffic for address translation by specifying the source and
destination addresses (or ports), whereas regular NAT uses only ports/source addresses. In
other words, the same local traffic for address translation can have multiple “global”
translations depending on the destination IP address or port. This is aptly demonstrated in
Figure 7-1.
Figure 7-1 Identifying Multiple External Addresses Using Policy NAT
The translation configuration for Figure 7-1 is as follows:
pixfw(config)#access-list 120 permit ip 10.10.100.0
255.255.255.0 172.16.1.10 255.255.255.255
pixfw(config)#access-list 130 permit ip 10.10.100.0
255.255.255.0 172.16.22.67 255.255.255.255
pixfw(config)#nat (inside) 1 access-list 120
pixfw(config)#global (outside) 1 192.168.100.62 255.255.255.255
pixfw(config)#nat (inside) 2 access-list 130
pixfw(config)#global (outside) 2 192.168.100.25 255.255.255.255
There are constraints of which you have to be aware when configuring Policy NAT:
■ A global address cannot be used concurrently for NAT and PAT.
■ Access lists for Policy NAT cannot contain deny statements. Access lists must contain
only permit statements.
As mentioned earlier in the text, one can configure access to higher-security subnets by using
the nat 0 command. For instance, if you have a host with a public address on the inside
network and the outside network needs access to this host, you can use nat 0, which disables
address translation so that inside IP addresses are visible to the outside. The following short
example demonstrates the use of the nat 0 command:
nat (inside) 0 192.168.1.10 255.255.255.255
This can also be configured as follows:
access-list 121 permit 192.168.1.10 255.255.255.255 any
nat (inside) 0 access-list 121
184 Chapter 7: Configuring Access
Policy NAT
Policy NAT provides additional capabilities in configuring address translation. The Policy
NAT feature lets you identify local traffic for address translation by specifying the source and
destination addresses (or ports), whereas regular NAT uses only ports/source addresses. In
other words, the same local traffic for address translation can have multiple “global”
translations depending on the destination IP address or port. This is aptly demonstrated in
Figure 7-1.
Figure 7-1 Identifying Multiple External Addresses Using Policy NAT
The translation configuration for Figure 7-1 is as follows:
pixfw(config)#access-list 120 permit ip 10.10.100.0
255.255.255.0 172.16.1.10 255.255.255.255
pixfw(config)#access-list 130 permit ip 10.10.100.0
255.255.255.0 172.16.22.67 255.255.255.255
pixfw(config)#nat (inside) 1 access-list 120
pixfw(config)#global (outside) 1 192.168.100.62 255.255.255.255
pixfw(config)#nat (inside) 2 access-list 130
pixfw(config)#global (outside) 2 192.168.100.25 255.255.255.255
There are constraints of which you have to be aware when configuring Policy NAT:
■ A global address cannot be used concurrently for NAT and PAT.
■ Access lists for Policy NAT cannot contain deny statements. Access lists must contain
only permit statements.
TCP Intercept Feature
TCP Intercept Feature
Before version 5.2, the Cisco PIX Firewall Security Appliance offered no mechanism to
protect systems that could be reached using a static and TCP conduit from TCP SYN attacks.
When the embryonic connection limit was configured in a static command statement, the
earlier PIX versions simply dropped new connection attempts as soon as the embryonic
threshold was reached. A mild TCP SYN attack could potentially create service disruption
to the server in question. For static command statements without an embryonic connection
Configuring Inbound Access Through a Cisco Security Appliance 183
limit, PIX Firewall passes all traffic. If the affected system does not have TCP SYN attack
protection (most operating systems do not offer sufficient protection), the affected system’s
embryonic connection table overloads, and all traffic stops.
With the TCP intercept feature, as soon as the optional embryonic connection limit is
reached, and until the embryonic connection count falls below this threshold, every SYN
bound for the affected server is intercepted. For each SYN, a Security Appliance, such as the
PIX Firewall, responds on behalf of the server with an empty SYN/ACK segment. The
Security Appliance retains pertinent state information, drops the packet, and waits for the
client’s acknowledgment. If the ACK is received, a copy of the client’s SYN segment is sent
to the server, and a TCP three-way handshake is performed between the Security Appliance
and the server. If this three-way handshake completes, the connection resumes as normal. If
the client does not respond during any part of the connection phase, Security Appliance
retransmits the necessary segment.
In addition to the TCP intercept feature, software version 6.3 and later introduced SYN
cookies as a means to stop a SYN flood from filling the SYN queue and causing dropped
connections. SYN cookies use a cryptographic method to create the initial TCP sequence
numbers for a TCP flow. This new method helps the Security Appliance manage the TCP
queue by responding to TCP connections with a SYN+ACK when the SYN queue fills up.
The Security Appliance will wait for an ACK from the remote device, and verifies the ACK
with the assigned 24-bit secret. The Security Appliance will then rebuild the SYN queue
based on this information. This allows the SYN queue to become larger, but never to a size
that will cause dropped backs, and removes the biggest effect of a SYN flood attack, which
is to disable large windows.
Before version 5.2, the Cisco PIX Firewall Security Appliance offered no mechanism to
protect systems that could be reached using a static and TCP conduit from TCP SYN attacks.
When the embryonic connection limit was configured in a static command statement, the
earlier PIX versions simply dropped new connection attempts as soon as the embryonic
threshold was reached. A mild TCP SYN attack could potentially create service disruption
to the server in question. For static command statements without an embryonic connection
Configuring Inbound Access Through a Cisco Security Appliance 183
limit, PIX Firewall passes all traffic. If the affected system does not have TCP SYN attack
protection (most operating systems do not offer sufficient protection), the affected system’s
embryonic connection table overloads, and all traffic stops.
With the TCP intercept feature, as soon as the optional embryonic connection limit is
reached, and until the embryonic connection count falls below this threshold, every SYN
bound for the affected server is intercepted. For each SYN, a Security Appliance, such as the
PIX Firewall, responds on behalf of the server with an empty SYN/ACK segment. The
Security Appliance retains pertinent state information, drops the packet, and waits for the
client’s acknowledgment. If the ACK is received, a copy of the client’s SYN segment is sent
to the server, and a TCP three-way handshake is performed between the Security Appliance
and the server. If this three-way handshake completes, the connection resumes as normal. If
the client does not respond during any part of the connection phase, Security Appliance
retransmits the necessary segment.
In addition to the TCP intercept feature, software version 6.3 and later introduced SYN
cookies as a means to stop a SYN flood from filling the SYN queue and causing dropped
connections. SYN cookies use a cryptographic method to create the initial TCP sequence
numbers for a TCP flow. This new method helps the Security Appliance manage the TCP
queue by responding to TCP connections with a SYN+ACK when the SYN queue fills up.
The Security Appliance will wait for an ACK from the remote device, and verifies the ACK
with the assigned 24-bit secret. The Security Appliance will then rebuild the SYN queue
based on this information. This allows the SYN queue to become larger, but never to a size
that will cause dropped backs, and removes the biggest effect of a SYN flood attack, which
is to disable large windows.
Static NAT
Configuring Inbound Access Through a Cisco Security Appliance
A two-step approach lets connections initiated from lower-security interfaces access highersecurity
interfaces:
Step 1 Network Address Translation
Step 2 Access lists
Static NAT
Static NAT creates a permanent, one-to-one mapping between an address on an internal
network (a higher-security-level interface) and an external network (a lower-security-level
interface) in all Security Appliance versions. For an external host to initiate traffic to an inside
host, a static translation rule needs to exist for the inside host. Without the persistent
translation rule, the translation cannot occur.
The syntax for the static command is as follows:
static [(prenat-interface, postnat-interface)] {mapped-address | interface}
real-address [dns] [netmask mask] [max-conns [emb-limit]] [norandomseq]
Table 7-2 describes the static command parameters.
A two-step approach lets connections initiated from lower-security interfaces access highersecurity
interfaces:
Step 1 Network Address Translation
Step 2 Access lists
Static NAT
Static NAT creates a permanent, one-to-one mapping between an address on an internal
network (a higher-security-level interface) and an external network (a lower-security-level
interface) in all Security Appliance versions. For an external host to initiate traffic to an inside
host, a static translation rule needs to exist for the inside host. Without the persistent
translation rule, the translation cannot occur.
The syntax for the static command is as follows:
static [(prenat-interface, postnat-interface)] {mapped-address | interface}
real-address [dns] [netmask mask] [max-conns [emb-limit]] [norandomseq]
Table 7-2 describes the static command parameters.
Sample Security Appliance Configuration
Sample Security Appliance Configuration
Examples 6-15 and 6-16 show sample output for a Security Appliance configuration in
routed and transparent mode. Included are some of the commands discussed in this chapter.
Example 6-15 Sample PIX Configuration in Routed Mode
pix# show config
: Saved
: Written by deguc at 11:29:39.859 EDT Fri Aug 8 2005
PIX Version 7.0(4)
interface Ethernet 0
nameif outside
security-level 0
speed 100
duplex full
ip address 192.168.1.1 255.255.255.224
interface Ethernet 1
nameif inside
security-level 100
speed 100
duplex full
interface Ethernet 2
nameif dmz
security-level 20
speed 100
duplex full
enable password GgtfiV2tiXAndr3w encrypted
passwd kP3Eex5gnkza7.lan encrypted
Sample Security Appliance Configuration 171
hostname pix
domain-name axum.com clock timezone EST -5
clock summer-time EDT recurring
class-map ips_class
match access-list IPS
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect dns maximum length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect sunrpc
inspect rsh
inspect rtsp
inspect sip
inspect skinny
inspect esmtp
inspect sqlnet
inspect tftp
inspect xdmcp
inspect icmp
class ips-class
ips promiscuous fail-close
service-policy global_policy global
Hyphenate in command, as for “service-policy”?
access-list IPS permit ip any any
pager lines 24
no logging on
ip audit info action alarm
ip audit attack action alarm no failover
route outside 0.0.0.0 0.0.0.0 192.168.1.3 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00
sip 0:30:00 sip-media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 10.10.10.14 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
Example 6-16 Sample PIX Configuration in Transparent Mode
pix# show config
: Saved
: Written by deguc at 11:49:39.859 EDT Fri Aug 8 2005
PIX Version 7.0(4)
interface Ethernet 0
nameif outside
security-level 0
speed 100
duplex full
interface Ethernet 1
nameif inside
security-level 100
speed 100
duplex full
interface Ethernet 2
speed 100
duplex full
shutdown
enable password GgtfiV2tiXAndr3w encrypted
passwd kP3Eex5gnkza7.lan encrypted
firewall transparent
hostname pix
domain-name axum.com clock timezone EST -5
clock summer-time EDT recurring
ip address 192.168.1.1 255.255.255.0
route outside 0.0.0.0 0.0.0.0 192.168.1.3 1
telnet 10.10.10.14 255.255.255.255 inside
arp outside 198.168.1.1 0009.7cbe.2100
arp-inspection outside enable
access-list ACLIN permit icmp 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list ETHER ethertype permit ipx
access-group ETHER in interface inside
access-group ETHER in interface outside
access-group ACLIN in interface inside
access-group ACLIN in interface outside
pager lines 24
no logging on
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00
sip 0:30:00 sip-media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
telnet timeout 5
terminal width 80
Cryptochecksum:62a73076955b1060644fdba1da64b15f
Example 6-16
Examples 6-15 and 6-16 show sample output for a Security Appliance configuration in
routed and transparent mode. Included are some of the commands discussed in this chapter.
Example 6-15 Sample PIX Configuration in Routed Mode
pix# show config
: Saved
: Written by deguc at 11:29:39.859 EDT Fri Aug 8 2005
PIX Version 7.0(4)
interface Ethernet 0
nameif outside
security-level 0
speed 100
duplex full
ip address 192.168.1.1 255.255.255.224
interface Ethernet 1
nameif inside
security-level 100
speed 100
duplex full
interface Ethernet 2
nameif dmz
security-level 20
speed 100
duplex full
enable password GgtfiV2tiXAndr3w encrypted
passwd kP3Eex5gnkza7.lan encrypted
Sample Security Appliance Configuration 171
hostname pix
domain-name axum.com clock timezone EST -5
clock summer-time EDT recurring
class-map ips_class
match access-list IPS
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect dns maximum length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect sunrpc
inspect rsh
inspect rtsp
inspect sip
inspect skinny
inspect esmtp
inspect sqlnet
inspect tftp
inspect xdmcp
inspect icmp
class ips-class
ips promiscuous fail-close
service-policy global_policy global
Hyphenate in command, as for “service-policy”?
access-list IPS permit ip any any
pager lines 24
no logging on
ip audit info action alarm
ip audit attack action alarm no failover
route outside 0.0.0.0 0.0.0.0 192.168.1.3 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00
sip 0:30:00 sip-media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 10.10.10.14 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
Example 6-16 Sample PIX Configuration in Transparent Mode
pix# show config
: Saved
: Written by deguc at 11:49:39.859 EDT Fri Aug 8 2005
PIX Version 7.0(4)
interface Ethernet 0
nameif outside
security-level 0
speed 100
duplex full
interface Ethernet 1
nameif inside
security-level 100
speed 100
duplex full
interface Ethernet 2
speed 100
duplex full
shutdown
enable password GgtfiV2tiXAndr3w encrypted
passwd kP3Eex5gnkza7.lan encrypted
firewall transparent
hostname pix
domain-name axum.com clock timezone EST -5
clock summer-time EDT recurring
ip address 192.168.1.1 255.255.255.0
route outside 0.0.0.0 0.0.0.0 192.168.1.3 1
telnet 10.10.10.14 255.255.255.255 inside
arp outside 198.168.1.1 0009.7cbe.2100
arp-inspection outside enable
access-list ACLIN permit icmp 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list ETHER ethertype permit ipx
access-group ETHER in interface inside
access-group ETHER in interface outside
access-group ACLIN in interface inside
access-group ACLIN in interface outside
pager lines 24
no logging on
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00
sip 0:30:00 sip-media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
telnet timeout 5
terminal width 80
Cryptochecksum:62a73076955b1060644fdba1da64b15f
Example 6-16
Monitoring in Transparent Mode
Monitoring in Transparent Mode
All traffic flows based on MAC address lookup via bridging. MAC addresses are either
statically assigned by the administrator or dynamically learned through traffic over an
interface. The Security Appliance lists all known MAC addresses in the MAC address table.
This table is used by the Security Appliance to switch traffic that passes through it, based on
any filters applied to each interface. To display the current MAC address table, you can use
the show mac-address-table command in privileged mode, as shown in Example 6-14.
Table 6-17 arp-inspection ethertype Command Parameters
Parameter Description
interface_name The interface on which you want ARP inspection.
enable Enables ARP inspection.
flood (Default) Specifies that packets not matching any element of a static ARP
entry are flooded out of all interfaces except the originating interface. If a
mismatch occurs between the MAC address, IP address, or interface, the
Security Appliance drops the packet.
no-flood (Optional) Specifies that packets not exactly matching a static ARP entry
are dropped.
Example 6-14 show mac-address-table Command Output
pix# show mac-address-table
interface mac address type Age(min)
inside 0010.7cbe.6101 static
inside 0008.e3bc.5ee0 dynamic 5
outside 0050.8DFB.19C2 dynamic 5
The Security Appliance will learn MAC addresses from the interface by default. This can be
a dangerous setting to allow on a secured network. If a malicious user spoofed (faked) the
MAC address of a network device already connected to the network, or just used a random
MAC address, that user could gain access to the secured network. The Security Appliance
would see the new MAC address and add it to the MAC table, giving the user access to that
part of the network. You can disable the Security Appliance’s ability to learn new MAC
addresses using the mac-learn command in global-configuration mode:
mac-learn interface_name disable
This will allow only static MAC addresses into the MAC address table. If the same malicious
user attempted to spoof the MAC address of an entry in the static table but on the wrong
interface, or tried to use a random MAC address not in the table, the MAC address and all
packets from that user would be dropped. An administrator can assign static MAC addresses
through the following command:
mac-address-table static interface_name mac_address
All traffic flows based on MAC address lookup via bridging. MAC addresses are either
statically assigned by the administrator or dynamically learned through traffic over an
interface. The Security Appliance lists all known MAC addresses in the MAC address table.
This table is used by the Security Appliance to switch traffic that passes through it, based on
any filters applied to each interface. To display the current MAC address table, you can use
the show mac-address-table command in privileged mode, as shown in Example 6-14.
Table 6-17 arp-inspection ethertype Command Parameters
Parameter Description
interface_name The interface on which you want ARP inspection.
enable Enables ARP inspection.
flood (Default) Specifies that packets not matching any element of a static ARP
entry are flooded out of all interfaces except the originating interface. If a
mismatch occurs between the MAC address, IP address, or interface, the
Security Appliance drops the packet.
no-flood (Optional) Specifies that packets not exactly matching a static ARP entry
are dropped.
Example 6-14 show mac-address-table Command Output
pix# show mac-address-table
interface mac address type Age(min)
inside 0010.7cbe.6101 static
inside 0008.e3bc.5ee0 dynamic 5
outside 0050.8DFB.19C2 dynamic 5
The Security Appliance will learn MAC addresses from the interface by default. This can be
a dangerous setting to allow on a secured network. If a malicious user spoofed (faked) the
MAC address of a network device already connected to the network, or just used a random
MAC address, that user could gain access to the secured network. The Security Appliance
would see the new MAC address and add it to the MAC table, giving the user access to that
part of the network. You can disable the Security Appliance’s ability to learn new MAC
addresses using the mac-learn command in global-configuration mode:
mac-learn interface_name disable
This will allow only static MAC addresses into the MAC address table. If the same malicious
user attempted to spoof the MAC address of an entry in the static table but on the wrong
interface, or tried to use a random MAC address not in the table, the MAC address and all
packets from that user would be dropped. An administrator can assign static MAC addresses
through the following command:
mac-address-table static interface_name mac_address
Traffic Management in Transparent Mode
Traffic Management in Transparent Mode
Now that you have transparent mode enabled on the Security Appliance, you must allow
more than just ARP traffic through the firewall. Extended access lists must be configured for
each traffic type you wish to allow through the firewall. For non-IP traffic, you must
configure EtherType access lists. Both types of access lists, once configured, must be assigned
to one of the two interfaces, or both, to be enabled. The syntax for extended access lists is
the same as those used in nontransparent mode, and detailed configuration of these access
lists can be found in Chapter 7, “Configuring Access.” EtherType access lists are used when
non-IP traffic is required to pass through the firewall. EtherType access lists are connectionless
and must be applied to both interfaces to operate correctly. To create an EtherType access
list, use the ethertype attribute with the access-list command:
access-list id ethertype {deny | permit}{ipx | bpdu | mpls-unicast | mpls-multica
Table 6-16 describes the parameters for the access-list ethertype command.
Example 6-13 Assigning an IP Address to Management Ports in Multiple-Context Mode
Pix/admin(config)# ip address 10.10.10.1 255.255.255.0
Pix/admin(config)# changeto context1
Pix/context1(config)# ip address 10.10.11.1 255.255.255.0
Pix/context1(config)# changeto context2
Pix/context2(config)# ip address 10.10.12.1 255.255.255.0
Table 6-16 access-list ethertype Command Parameters
Parameter Description
id Name or number of an access list.
deny Denies access if the conditions are matched.
permit Permits access if the conditions are matched.
ipx Specifies access to IPX.
npdu Specifies access to bridge protocol data units.
mpls-unicast Specifies access to MPLS unicast.
mpls-multicast Specifies access to MPLS multicast.
any Specifies access to anyone.
hex_number A 16-bit hexadecimal number greater than or equal to 0x600 by which an
EtherType can be identified.
NOTE In transparent mode, the Security Appliance relies on EtherTypes to determine
traffic selection. This forces the Security Appliance to only pass Ethernet II frames, due to
802.3 frames requiring a length field instead of EtherType.
Remember that the Security Appliance defaults do not allow any non-ARP traffic through
the firewall.
You can manage the ARP traffic through inspection on the Security Appliance. Inspection
can help restrict malicious users from attempting ARP floods on or through the firewall or
connected networks. Using the arp-inspection command in global-configuration mode, you
can check each request to flood ARP requests through an interface for mismatched IP
addresses, MAC addresses, or fake interfaces, and you can drop the request packets before
they can cause problems. The full command syntax for the arp-inspection command is as
follows:
arp-inspection interface_name enable [flood | no-flood]
Table 6-17 describes the parameters for the arp-inspection ethertype command.
Table 6-17 arp-inspection ethertype Command Parameters
Parameter Description
interface_name The interface on which you want ARP inspection.
enable Enables ARP inspection.
flood (Default) Specifies that packets not matching any element of a static ARP
entry are flooded out of all interfaces except the originating interface. If a
mismatch occurs between the MAC address, IP address, or interface, the
Security Appliance drops the packet.
no-flood (Optional) Specifies that packets not exactly matching a static ARP entry
are dropped.
Now that you have transparent mode enabled on the Security Appliance, you must allow
more than just ARP traffic through the firewall. Extended access lists must be configured for
each traffic type you wish to allow through the firewall. For non-IP traffic, you must
configure EtherType access lists. Both types of access lists, once configured, must be assigned
to one of the two interfaces, or both, to be enabled. The syntax for extended access lists is
the same as those used in nontransparent mode, and detailed configuration of these access
lists can be found in Chapter 7, “Configuring Access.” EtherType access lists are used when
non-IP traffic is required to pass through the firewall. EtherType access lists are connectionless
and must be applied to both interfaces to operate correctly. To create an EtherType access
list, use the ethertype attribute with the access-list command:
access-list id ethertype {deny | permit}{ipx | bpdu | mpls-unicast | mpls-multica
Table 6-16 describes the parameters for the access-list ethertype command.
Example 6-13 Assigning an IP Address to Management Ports in Multiple-Context Mode
Pix/admin(config)# ip address 10.10.10.1 255.255.255.0
Pix/admin(config)# changeto context1
Pix/context1(config)# ip address 10.10.11.1 255.255.255.0
Pix/context1(config)# changeto context2
Pix/context2(config)# ip address 10.10.12.1 255.255.255.0
Table 6-16 access-list ethertype Command Parameters
Parameter Description
id Name or number of an access list.
deny Denies access if the conditions are matched.
permit Permits access if the conditions are matched.
ipx Specifies access to IPX.
npdu Specifies access to bridge protocol data units.
mpls-unicast Specifies access to MPLS unicast.
mpls-multicast Specifies access to MPLS multicast.
any Specifies access to anyone.
hex_number A 16-bit hexadecimal number greater than or equal to 0x600 by which an
EtherType can be identified.
NOTE In transparent mode, the Security Appliance relies on EtherTypes to determine
traffic selection. This forces the Security Appliance to only pass Ethernet II frames, due to
802.3 frames requiring a length field instead of EtherType.
Remember that the Security Appliance defaults do not allow any non-ARP traffic through
the firewall.
You can manage the ARP traffic through inspection on the Security Appliance. Inspection
can help restrict malicious users from attempting ARP floods on or through the firewall or
connected networks. Using the arp-inspection command in global-configuration mode, you
can check each request to flood ARP requests through an interface for mismatched IP
addresses, MAC addresses, or fake interfaces, and you can drop the request packets before
they can cause problems. The full command syntax for the arp-inspection command is as
follows:
arp-inspection interface_name enable [flood | no-flood]
Table 6-17 describes the parameters for the arp-inspection ethertype command.
Table 6-17 arp-inspection ethertype Command Parameters
Parameter Description
interface_name The interface on which you want ARP inspection.
enable Enables ARP inspection.
flood (Default) Specifies that packets not matching any element of a static ARP
entry are flooded out of all interfaces except the originating interface. If a
mismatch occurs between the MAC address, IP address, or interface, the
Security Appliance drops the packet.
no-flood (Optional) Specifies that packets not exactly matching a static ARP entry
are dropped.
6-12 Assigning an IP Address to Management Port in Single-Context Mode
6-12 Assigning an IP Address to Management Port in Single-Context Mode
Pix(config)# ip address 10.10.10.1 255.255.255.0
Pix(config)# exit
Pix# show ip address
Management System IP Address:
ip address 10.10.10.1 255.255.255.0
Management Current IP Address:
ip address 10.10.10.1 255.255.255.0
168 Chapter 6: Getting Started with the Cisco Security Appliance Family of Firewalls
Traffic Management in Transparent Mode
Now that you have transparent mode enabled on the Security Appliance, you must allow
more than just ARP traffic through the firewall. Extended access lists must be configured for
each traffic type you wish to allow through the firewall. For non-IP traffic, you must
configure EtherType access lists. Both types of access lists, once configured, must be assigned
to one of the two interfaces, or both, to be enabled. The syntax for extended access lists is
the same as those used in nontransparent mode, and detailed configuration of these access
lists can be found in Chapter 7, “Configuring Access.” EtherType access lists are used when
non-IP traffic is required to pass through the firewall. EtherType access lists are connectionless
and must be applied to both interfaces to operate correctly. To create an EtherType access
list, use the ethertype attribute with the access-list command:
access-list id ethertype {deny | permit}{ipx | bpdu | mpls-unicast | mpls-multicast | any
| hex_number}
Table 6-16 describes the parameters for the access-list ethertype command.
Example 6-13 Assigning an IP Address to Management Ports in Multiple-Context Mode
Pix/admin(config)# ip address 10.10.10.1 255.255.255.0
Pix/admin(config)# changeto context1
Pix/context1(config)# ip address 10.10.11.1 255.255.255.0
Pix/context1(config)# changeto context2
Pix/context2(config)# ip address 10.10.12.1 255.255.255.0
Pix(config)# ip address 10.10.10.1 255.255.255.0
Pix(config)# exit
Pix# show ip address
Management System IP Address:
ip address 10.10.10.1 255.255.255.0
Management Current IP Address:
ip address 10.10.10.1 255.255.255.0
168 Chapter 6: Getting Started with the Cisco Security Appliance Family of Firewalls
Traffic Management in Transparent Mode
Now that you have transparent mode enabled on the Security Appliance, you must allow
more than just ARP traffic through the firewall. Extended access lists must be configured for
each traffic type you wish to allow through the firewall. For non-IP traffic, you must
configure EtherType access lists. Both types of access lists, once configured, must be assigned
to one of the two interfaces, or both, to be enabled. The syntax for extended access lists is
the same as those used in nontransparent mode, and detailed configuration of these access
lists can be found in Chapter 7, “Configuring Access.” EtherType access lists are used when
non-IP traffic is required to pass through the firewall. EtherType access lists are connectionless
and must be applied to both interfaces to operate correctly. To create an EtherType access
list, use the ethertype attribute with the access-list command:
access-list id ethertype {deny | permit}{ipx | bpdu | mpls-unicast | mpls-multicast | any
| hex_number}
Table 6-16 describes the parameters for the access-list ethertype command.
Example 6-13 Assigning an IP Address to Management Ports in Multiple-Context Mode
Pix/admin(config)# ip address 10.10.10.1 255.255.255.0
Pix/admin(config)# changeto context1
Pix/context1(config)# ip address 10.10.11.1 255.255.255.0
Pix/context1(config)# changeto context2
Pix/context2(config)# ip address 10.10.12.1 255.255.255.0
Enabling Transparent Mode
Enabling Transparent Mode
When you decide to enable transparent mode, ensure that your configuration has been
backed up. When this feature is enabled, it will clear the current configuration to avoid any
command conflicts that may exist with the currently deployed configuration. To enable
transparent mode, use the firewall transparent command in the global configuration mode.
If you are using multiple contexts, you must execute this command in the system
configuration mode, which will affect all configured contexts. Use the show firewall
command in privileged mode to verify that the firewall has accepted the new transparent
mode, as shown in Example 6-11.
The last configuration required to enable transparent mode is to assign an IP address to an
interface for management access to the Security Context:
ip address ip_address [netmask]
This will allow you to manage the Security Appliance remotely. The IP address will also be
used as the source address for any traffic that originates from the Security Appliance, or for
syslog and Simple Network Management Protocol (SNMP) alarm messages. If you are using
multiple contexts, you must assign an IP address for each context configured. To configure
an IP address, use the ip address command in global-configuration mode. The IP address used
must be in the same subnet as a network directly connected to the Security Appliance. You
can display the current management-port configuration using the show ip address command
in privileged mode, as shown in Example 6-12. Example 6-13 uses the same process but in
multicontext mode.
Example 6-11 Enabling Transparent Mode Output
Pix(config)# firewall transparent
Pix(config)# exit
Pix# show firewall
Firewall mode: Transparent
When you decide to enable transparent mode, ensure that your configuration has been
backed up. When this feature is enabled, it will clear the current configuration to avoid any
command conflicts that may exist with the currently deployed configuration. To enable
transparent mode, use the firewall transparent command in the global configuration mode.
If you are using multiple contexts, you must execute this command in the system
configuration mode, which will affect all configured contexts. Use the show firewall
command in privileged mode to verify that the firewall has accepted the new transparent
mode, as shown in Example 6-11.
The last configuration required to enable transparent mode is to assign an IP address to an
interface for management access to the Security Context:
ip address ip_address [netmask]
This will allow you to manage the Security Appliance remotely. The IP address will also be
used as the source address for any traffic that originates from the Security Appliance, or for
syslog and Simple Network Management Protocol (SNMP) alarm messages. If you are using
multiple contexts, you must assign an IP address for each context configured. To configure
an IP address, use the ip address command in global-configuration mode. The IP address used
must be in the same subnet as a network directly connected to the Security Appliance. You
can display the current management-port configuration using the show ip address command
in privileged mode, as shown in Example 6-12. Example 6-13 uses the same process but in
multicontext mode.
Example 6-11 Enabling Transparent Mode Output
Pix(config)# firewall transparent
Pix(config)# exit
Pix# show firewall
Firewall mode: Transparent
Configuring Transparent Mode
Configuring Transparent Mode
With the release of Security software version 7.0, a Security Appliance can run as a Layer 2
firewall. Standard firewalls act in a similar fashion as a router, routing packets through the
firewall instead of switching them. This creates an extra hop in the IP path that a user can
detect. With transparent firewall enabled, the Security Appliance will act as a Layer 2 filtering
bridge, switching the packets instead of routing them, and the user will not see an additional
hop within the IP path. This allows the Security Appliance to bridge packets from one
interface to another, instead of routing them. These interfaces are usually on the same VLAN
or IP subnet.
Because transparent firewalls perform MAC address lookup instead of routing, a Security
Appliance with this feature enabled can be placed in a network without a need to reconfigure
any part of the network, including NAT or IP readdressing. With the change from routing to
switching, enabling transparent firewalling removes or restricts support for several Security
Appliance features:
■ Interface limits—A Security Appliance with transparent firewalls enabled can only use
two interfaces. Each interface must be on a different VLAN to support transparent
firewalls. This restriction is based on a single context. If multiple contexts have been
enabled, each context created can use only two interfaces. These interfaces can only be
used by one context and cannot be shared between multiple contexts in transparent
mode.
■ NAT—NAT does not apply when the Security Appliance is running in a Layer 2 mode.
NAT would be done by a Layer 3 device in this design.
■ Dynamic routing protocols—Because the Security Appliance is set to be a bridge,
dynamic routing protocols are not needed, as they are used in an environment to assist
in routing packets. Static routes can be configured for traffic that may originate from the
Security Appliance.
■ IPv6—IPv6 is not supported due to transparent mode working at Layer 2 and not Layer 3.
■ DHCP relay—The Security Appliance cannot act as a DHCP relay, although it can act
as a DHCP server.
■ Quality of service (QoS)—Most QoS options rely on the TCP header, which is not used
in transparent mode.
■ Multicast—Multicast traffic is not supported by default in transparent mode. To pass
multicast traffic through the Security Appliance in transparent mode, you must use
extended access lists.
■ VPN termination for through traffic—The Security Appliance with transparent firewalls
enabled can only support site-to-site VPN tunnels for the management connections.
A Security Appliance in transparent mode can still run virtual firewalls. Each context must
be configured with an IP address to use for management access. This IP address assigned to
the port must be part of the connecting network, since the Security Appliance cannot route
a subnet that is not directly connected. Additionally, each connecting network must reside in
the same subnet to be supported in transparent mode.
The bridging of traffic by the Security Appliance does not work like a normal switch by
default. A Security Appliance in transparent mode will only pass ARP traffic between the two
interfaces until an extended access list or EtherType access list is configured. With either of
these access lists configured, you can allow Layer 3 traffic to pass through the Security
Appliance.
NOTE A Security Appliance can be set to either transparent or router mode. If multiple
contexts are enabled, all contexts must be set to the same mode.
With the release of Security software version 7.0, a Security Appliance can run as a Layer 2
firewall. Standard firewalls act in a similar fashion as a router, routing packets through the
firewall instead of switching them. This creates an extra hop in the IP path that a user can
detect. With transparent firewall enabled, the Security Appliance will act as a Layer 2 filtering
bridge, switching the packets instead of routing them, and the user will not see an additional
hop within the IP path. This allows the Security Appliance to bridge packets from one
interface to another, instead of routing them. These interfaces are usually on the same VLAN
or IP subnet.
Because transparent firewalls perform MAC address lookup instead of routing, a Security
Appliance with this feature enabled can be placed in a network without a need to reconfigure
any part of the network, including NAT or IP readdressing. With the change from routing to
switching, enabling transparent firewalling removes or restricts support for several Security
Appliance features:
■ Interface limits—A Security Appliance with transparent firewalls enabled can only use
two interfaces. Each interface must be on a different VLAN to support transparent
firewalls. This restriction is based on a single context. If multiple contexts have been
enabled, each context created can use only two interfaces. These interfaces can only be
used by one context and cannot be shared between multiple contexts in transparent
mode.
■ NAT—NAT does not apply when the Security Appliance is running in a Layer 2 mode.
NAT would be done by a Layer 3 device in this design.
■ Dynamic routing protocols—Because the Security Appliance is set to be a bridge,
dynamic routing protocols are not needed, as they are used in an environment to assist
in routing packets. Static routes can be configured for traffic that may originate from the
Security Appliance.
■ IPv6—IPv6 is not supported due to transparent mode working at Layer 2 and not Layer 3.
■ DHCP relay—The Security Appliance cannot act as a DHCP relay, although it can act
as a DHCP server.
■ Quality of service (QoS)—Most QoS options rely on the TCP header, which is not used
in transparent mode.
■ Multicast—Multicast traffic is not supported by default in transparent mode. To pass
multicast traffic through the Security Appliance in transparent mode, you must use
extended access lists.
■ VPN termination for through traffic—The Security Appliance with transparent firewalls
enabled can only support site-to-site VPN tunnels for the management connections.
A Security Appliance in transparent mode can still run virtual firewalls. Each context must
be configured with an IP address to use for management access. This IP address assigned to
the port must be part of the connecting network, since the Security Appliance cannot route
a subnet that is not directly connected. Additionally, each connecting network must reside in
the same subnet to be supported in transparent mode.
The bridging of traffic by the Security Appliance does not work like a normal switch by
default. A Security Appliance in transparent mode will only pass ARP traffic between the two
interfaces until an extended access list or EtherType access list is configured. With either of
these access lists configured, you can allow Layer 3 traffic to pass through the Security
Appliance.
NOTE A Security Appliance can be set to either transparent or router mode. If multiple
contexts are enabled, all contexts must be set to the same mode.
Configuring Login Banners on the Cisco Security Appliance
PIX Firewall version 6.3 introduced support for message-of-the-day (MOTD), EXEC, and
login banners, similar to the feature included in Cisco IOS Software. Banner size is limited
only by available system memory or Flash memory.
You can create a message as a warning for unauthorized use of the firewall. In some
jurisdictions, civil and/or criminal prosecution of crackers who break into your system are
made easier if you have incorporated a warning banner that informs unauthorized users that
their attempts to access the system are in fact unauthorized. In other jurisdictions, you may
be forbidden to monitor the activities of even unauthorized users unless you have taken steps
to notify them of your intent to do so. One way of providing this notification is to put the
information into a banner message configured with the Security Appliance banner command.
Legal notification requirements are complex and vary in each jurisdiction and situation. Even
within jurisdictions, legal opinions vary, and this issue should be discussed with your own
legal counsel. In cooperation with counsel, you should consider which of the following
information should be put into your banner:
■ A notice that the system can be logged in to or used only by specifically authorized
personnel, and perhaps information about who may authorize use
■ A notice that any unauthorized use of the system is unlawful and may be subject to civil
and/or criminal penalties
■ A notice that any use of the system may be logged or monitored without further notice
and that the resulting logs may be used as evidence in court
■ Specific notices required by specific local laws
From a security, rather than a legal, point of view, your login banner usually should not
contain any specific information about your router, its name, its model, what software it is
running, or who owns it; such information may be abused by crackers.
The banner messages can be displayed when a user enters privileged EXEC mode, upon line
activation, on an incoming connection to a virtual terminal, or as a MOTD. To create a
banner message, use the following command:
banner {exec | login | motd} text
Table 6-15 describes the parameters of the banner command.
Table 6-15 banner Command Parameters
Parameter Description
exec Configures the system to display a banner before displaying the enable prompt.
Login Configures the system to display a banner before the password login prompt
when accessing the firewall using Telnet.
motd Configures the system to display a MOTD banner.
text Specifies the line of message text to be displayed in the firewall command-line
interface. Subsequent text entries are added to the end of an existing banner
unless the banner is cleared first. The tokens $(domain) and $(hostname) are
replaced with the host name and domain name of the firewall.
Spaces are allowed, but tabs cannot be entered using the CLI. You can dynamically add the
host name or domain name of the Security Appliance by including $(hostname) and
$(domain) in the string. Example 6-10 shows a sample configuration using the banner
command.
To replace a banner, use the no banner command before adding the new lines. The no banner
{exec | login | motd} command removes all the lines for the banner option specified. The no
banner command removes all the lines for the banner option specified and does not
selectively delete text strings. The clear banner command removes all the banners.
login banners, similar to the feature included in Cisco IOS Software. Banner size is limited
only by available system memory or Flash memory.
You can create a message as a warning for unauthorized use of the firewall. In some
jurisdictions, civil and/or criminal prosecution of crackers who break into your system are
made easier if you have incorporated a warning banner that informs unauthorized users that
their attempts to access the system are in fact unauthorized. In other jurisdictions, you may
be forbidden to monitor the activities of even unauthorized users unless you have taken steps
to notify them of your intent to do so. One way of providing this notification is to put the
information into a banner message configured with the Security Appliance banner command.
Legal notification requirements are complex and vary in each jurisdiction and situation. Even
within jurisdictions, legal opinions vary, and this issue should be discussed with your own
legal counsel. In cooperation with counsel, you should consider which of the following
information should be put into your banner:
■ A notice that the system can be logged in to or used only by specifically authorized
personnel, and perhaps information about who may authorize use
■ A notice that any unauthorized use of the system is unlawful and may be subject to civil
and/or criminal penalties
■ A notice that any use of the system may be logged or monitored without further notice
and that the resulting logs may be used as evidence in court
■ Specific notices required by specific local laws
From a security, rather than a legal, point of view, your login banner usually should not
contain any specific information about your router, its name, its model, what software it is
running, or who owns it; such information may be abused by crackers.
The banner messages can be displayed when a user enters privileged EXEC mode, upon line
activation, on an incoming connection to a virtual terminal, or as a MOTD. To create a
banner message, use the following command:
banner {exec | login | motd} text
Table 6-15 describes the parameters of the banner command.
Table 6-15 banner Command Parameters
Parameter Description
exec Configures the system to display a banner before displaying the enable prompt.
Login Configures the system to display a banner before the password login prompt
when accessing the firewall using Telnet.
motd Configures the system to display a MOTD banner.
text Specifies the line of message text to be displayed in the firewall command-line
interface. Subsequent text entries are added to the end of an existing banner
unless the banner is cleared first. The tokens $(domain) and $(hostname) are
replaced with the host name and domain name of the firewall.
Spaces are allowed, but tabs cannot be entered using the CLI. You can dynamically add the
host name or domain name of the Security Appliance by including $(hostname) and
$(domain) in the string. Example 6-10 shows a sample configuration using the banner
command.
To replace a banner, use the no banner command before adding the new lines. The no banner
{exec | login | motd} command removes all the lines for the banner option specified. The no
banner command removes all the lines for the banner option specified and does not
selectively delete text strings. The clear banner command removes all the banners.
Cisco Security Appliance System Clock
Cisco Security Appliance System Clock
The second method of configuring the time setting on the Security Appliance is by using the
system clock. The system clock is usually set when you answer the initial setup interview
question when you are configuring a new Cisco Security Appliance. You can change it later
using the clock set command:
clock set hh:mm:ss month day year
Three characters are used for the month parameter. The year is a four-digit number. For
example, to set the time and date to 17:51 and 20 seconds on April 9, 2003, you would enter
the following:
clock set 17:51:20 apr 9 2003
Cisco PIX Firewall version 6.2 included improvements to the clock command. The clock
command now supports daylight saving (summer) time and time zones. To configure daylight
saving time, enter the following command:
clock summer-time zone recurring [week weekday month hh:mm week weekday
month hh:mm [offset]]
Table 6-14 describes the parameters for the clock command.
Table 6-14 clock Command Parameters
Command Parameter Description
summer-time Automatically switches to summer time (for display purposes only).
zone Specifies the name of the time zone.
recurring Indicates that summer time should start and end on the days
specified by the values that follow this keyword. The summer time
rule defaults to the United States rule.
Configuring Login Banners on the Cisco Security Appliance 163
Time zones are set only for display. Setting a time zone does not change the internal Security
Appliance time, which is kept according to Coordinated Universal Time (UTC). To set the
time zone, use the clock timezone command. The syntax for the command is as follows:
clock timezone zone hours [minutes]
The following clock summer-time command specifies that summer time starts on the first
Sunday in April at 2 A.M. and ends on the last Sunday in October at 2 A.M.:
pix(config)# clock summer-time PDT recurring 1 Sunday April 2:00 last Sunday
October 2:00
You can check your clock configuration by simply entering the show clock command as
shown in Example 6-9.
Configuring Login Banners on the Cisco Security Appliance
PIX Firewall version 6.3 introduced support for message-of-the-day (MOTD), EXEC, and
login banners, similar to the feature included in Cisco IOS Software. Banner size is limited
only by available system memory or Flash memory.
Command Parameter Description
week Specifies the week of the month. The week is 1 through 4.
week day Sets the day of the week (Sunday, Monday).
month Specifies the full name of the month, such as April.
hh:mm Specifies the time in 24-hour clock format.
offset Specifies the number of minutes to add during summer. The default
is 60 minutes.
Example 6-9 show clock Sample Output
PIXFW# show clock
10:04:06.334 PDI Thu Feb 13 2004
NOTE In 2007, the United States will be extending Daylight Savings Time (DST) by a
month. Starting in 2007, DST will start on the second Sunday in March and will end on
the first Sunday in November. The following clock command will set the Security
Appliance to the new DST setting (to be precise, summer begins on June 21, or
thereabouts):
pix(config)# clock summer-time PDT recurring 2 Sunday March 2:00 1 Sunday
November 2:00
The second method of configuring the time setting on the Security Appliance is by using the
system clock. The system clock is usually set when you answer the initial setup interview
question when you are configuring a new Cisco Security Appliance. You can change it later
using the clock set command:
clock set hh:mm:ss month day year
Three characters are used for the month parameter. The year is a four-digit number. For
example, to set the time and date to 17:51 and 20 seconds on April 9, 2003, you would enter
the following:
clock set 17:51:20 apr 9 2003
Cisco PIX Firewall version 6.2 included improvements to the clock command. The clock
command now supports daylight saving (summer) time and time zones. To configure daylight
saving time, enter the following command:
clock summer-time zone recurring [week weekday month hh:mm week weekday
month hh:mm [offset]]
Table 6-14 describes the parameters for the clock command.
Table 6-14 clock Command Parameters
Command Parameter Description
summer-time Automatically switches to summer time (for display purposes only).
zone Specifies the name of the time zone.
recurring Indicates that summer time should start and end on the days
specified by the values that follow this keyword. The summer time
rule defaults to the United States rule.
Configuring Login Banners on the Cisco Security Appliance 163
Time zones are set only for display. Setting a time zone does not change the internal Security
Appliance time, which is kept according to Coordinated Universal Time (UTC). To set the
time zone, use the clock timezone command. The syntax for the command is as follows:
clock timezone zone hours [minutes]
The following clock summer-time command specifies that summer time starts on the first
Sunday in April at 2 A.M. and ends on the last Sunday in October at 2 A.M.:
pix(config)# clock summer-time PDT recurring 1 Sunday April 2:00 last Sunday
October 2:00
You can check your clock configuration by simply entering the show clock command as
shown in Example 6-9.
Configuring Login Banners on the Cisco Security Appliance
PIX Firewall version 6.3 introduced support for message-of-the-day (MOTD), EXEC, and
login banners, similar to the feature included in Cisco IOS Software. Banner size is limited
only by available system memory or Flash memory.
Command Parameter Description
week Specifies the week of the month. The week is 1 through 4.
week day Sets the day of the week (Sunday, Monday).
month Specifies the full name of the month, such as April.
hh:mm Specifies the time in 24-hour clock format.
offset Specifies the number of minutes to add during summer. The default
is 60 minutes.
Example 6-9 show clock Sample Output
PIXFW# show clock
10:04:06.334 PDI Thu Feb 13 2004
NOTE In 2007, the United States will be extending Daylight Savings Time (DST) by a
month. Starting in 2007, DST will start on the second Sunday in March and will end on
the first Sunday in November. The following clock command will set the Security
Appliance to the new DST setting (to be precise, summer begins on June 21, or
thereabouts):
pix(config)# clock summer-time PDT recurring 2 Sunday March 2:00 1 Sunday
November 2:00
NTP
NTP
The NTP is used to implement a hierarchical system of servers that provide a source for a
precise synchronized time among network systems. It is important to maintain a consistent
time throughout all network devices, such as servers, routers, and switches. When analyzing
network events, logs are an important source of information. Analyzing and troubleshooting
network events can be difficult if there is a time inconsistency between network devices on
the network. Furthermore, some time-sensitive operations, such as validating certificates and
certificate revocation lists (CRLs), require precise time stamps.
Cisco PIX Firewall version 6.2 and later, as well as ASA Security version 7.0, enable you
obtain the system time from NTP version 3 servers.
The syntax to enable an NTP client on the Security Appliance is as follows:
ntp server ip-address [key number] source if-name [prefer]
Table 6-13 describes the parameters of the ntp command.
Table 6-13 ntp Command Parameters
Command Parameter Description
ip-address Specifies the IP address of the time server with which the Security
Appliance synchronizes.
key This keyword indicates that you are configuring the NTP client to
use the specified authentication key (identified by number) when
sending packets to the NTP server.
number Specifies the authentication key. This value is useful when you use
multiple keys and multiple servers for identification purposes.
source Specifies the interface. If the source keyword is not specified, the
routing table is used to determine the interface.
if-name Specifies the interface name used to send packets to the NTP server.
prefer Specifies the preferred time server. This option reduces switching
back and forth between servers by making the specified server the
preferred time server.
Communication of messages between the Security Appliance and the NTP servers can be
authenticated to prevent the Security Appliance from synchronizing time with rogue NTP
servers. The three commands used to enable NTP authentication are as follows:
ntp authenticate
ntp authentication-key number md5 value
ntp trusted-key number
The ntp authenticate command enables NTP authentication and refuses synchronization
with an NTP server unless the server is configured with one of the authentication keys
specified using the ntp trusted-key command.
The ntp authentication-key command is used to define authentication keys for use with other
NTP commands to provide a higher degree of security. The number parameter is the key
number (1 to 4,294,967,295). The md5 option is the encryption algorithm. The value
parameter is the key value (an arbitrary string of up to 32 characters).
The ntp trusted-key command is used to define one or more key numbers that the NTP server
is required to provide in its NTP packets for the Security Appliance to accept synchronization
with that NTP server. The Cisco Security Appliance requires the NTP server to provide this
key number in its NTP packets, which provides protection against synchronizing the Security
Appliance system clock with an NTP server that is not trusted.
NTP configuration on the Security Appliance can be verified and viewed by using the
following show commands:
■ The show ntp command displays the current NTP configuration.
■ The show ntp associations [detail] command displays the configured network time server
associations.
■ The show ntp status command displays the NTP clock information.
To remove the NTP configuration, use the clear ntp command.
The NTP is used to implement a hierarchical system of servers that provide a source for a
precise synchronized time among network systems. It is important to maintain a consistent
time throughout all network devices, such as servers, routers, and switches. When analyzing
network events, logs are an important source of information. Analyzing and troubleshooting
network events can be difficult if there is a time inconsistency between network devices on
the network. Furthermore, some time-sensitive operations, such as validating certificates and
certificate revocation lists (CRLs), require precise time stamps.
Cisco PIX Firewall version 6.2 and later, as well as ASA Security version 7.0, enable you
obtain the system time from NTP version 3 servers.
The syntax to enable an NTP client on the Security Appliance is as follows:
ntp server ip-address [key number] source if-name [prefer]
Table 6-13 describes the parameters of the ntp command.
Table 6-13 ntp Command Parameters
Command Parameter Description
ip-address Specifies the IP address of the time server with which the Security
Appliance synchronizes.
key This keyword indicates that you are configuring the NTP client to
use the specified authentication key (identified by number) when
sending packets to the NTP server.
number Specifies the authentication key. This value is useful when you use
multiple keys and multiple servers for identification purposes.
source Specifies the interface. If the source keyword is not specified, the
routing table is used to determine the interface.
if-name Specifies the interface name used to send packets to the NTP server.
prefer Specifies the preferred time server. This option reduces switching
back and forth between servers by making the specified server the
preferred time server.
Communication of messages between the Security Appliance and the NTP servers can be
authenticated to prevent the Security Appliance from synchronizing time with rogue NTP
servers. The three commands used to enable NTP authentication are as follows:
ntp authenticate
ntp authentication-key number md5 value
ntp trusted-key number
The ntp authenticate command enables NTP authentication and refuses synchronization
with an NTP server unless the server is configured with one of the authentication keys
specified using the ntp trusted-key command.
The ntp authentication-key command is used to define authentication keys for use with other
NTP commands to provide a higher degree of security. The number parameter is the key
number (1 to 4,294,967,295). The md5 option is the encryption algorithm. The value
parameter is the key value (an arbitrary string of up to 32 characters).
The ntp trusted-key command is used to define one or more key numbers that the NTP server
is required to provide in its NTP packets for the Security Appliance to accept synchronization
with that NTP server. The Cisco Security Appliance requires the NTP server to provide this
key number in its NTP packets, which provides protection against synchronizing the Security
Appliance system clock with an NTP server that is not trusted.
NTP configuration on the Security Appliance can be verified and viewed by using the
following show commands:
■ The show ntp command displays the current NTP configuration.
■ The show ntp associations [detail] command displays the configured network time server
associations.
■ The show ntp status command displays the NTP clock information.
To remove the NTP configuration, use the clear ntp command.
Configuring Time Settings on the Cisco Security Appliance
Configuring Time Settings on the Cisco Security Appliance
The Security Appliance obtains its time setting information in two ways:
■ By Network Time Protocol (NTP) server
■ By system cloc
The Security Appliance obtains its time setting information in two ways:
■ By Network Time Protocol (NTP) server
■ By system cloc
Configuring the Security Appliance DHCP Client
Configuring the Security Appliance DHCP Client
DHCP client support on the Cisco Security appliance is designed for use in SOHO
environments in which digital subscriber line (DSL) and cable modems are used. The DHCP
client can be enabled only on the outside interface of the Security Appliance. When the
DHCP client is enabled, DHCP servers on the outside provide the outside interface with an
IP address.
The DHCP client feature on a Security Appliance is enabled by the ip address dhcp
command:
ip address dhcp [setroute] [retry retry-cnt]
The setroute option tells the Cisco Security Appliance to set its default route using the default
gateway parameter that the DHCP server returns. Do not configure a default route when
using the setroute option.
To view current information about the DHCP lease, enter the following command:
show ip address outside dhcp
The partial configuration in Example 6-8 demonstrates how to use three new features that
are associated with each other: DHCP server, DHCP client, and PAT using the interface IP
address to configure a Security Appliance in a SOHO environment with the inside interface
as the DHCP server.
DHCP client support on the Cisco Security appliance is designed for use in SOHO
environments in which digital subscriber line (DSL) and cable modems are used. The DHCP
client can be enabled only on the outside interface of the Security Appliance. When the
DHCP client is enabled, DHCP servers on the outside provide the outside interface with an
IP address.
The DHCP client feature on a Security Appliance is enabled by the ip address dhcp
command:
ip address dhcp [setroute] [retry retry-cnt]
The setroute option tells the Cisco Security Appliance to set its default route using the default
gateway parameter that the DHCP server returns. Do not configure a default route when
using the setroute option.
To view current information about the DHCP lease, enter the following command:
show ip address outside dhcp
The partial configuration in Example 6-8 demonstrates how to use three new features that
are associated with each other: DHCP server, DHCP client, and PAT using the interface IP
address to configure a Security Appliance in a SOHO environment with the inside interface
as the DHCP server.
Configuring Dynamic Host Configuration Protocol on the Cisco
Configuring Dynamic Host Configuration Protocol on the Cisco
Security Appliance
The Cisco Security Appliance can be configured as either of the following:
■ DHCP server
■ DHCP client
Using the Cisco Security Appliance DHCP Server
The DHCP server is usually used in, but not limited to, SOHO environments. The address
pool of a Cisco Security Appliance DHCP server must be within the same subnet of the
Security Appliance interface that is enabled, and you must specify the associated Security
Appliance interface with if- name. In other words, the client must be physically connected to
the subnet of a Security Appliance interface. The size of the pool is limited to 32 addresses
with a 10-user license and 128 addresses with a 50-user license on the PIX 501. The
unlimited user license on the PIX 501 and all other Security Appliance platforms supports
256 addresses. To configure DHCP on a Security Appliance, use the dhcpd command. The
following is the syntax for the dhcpd command:
dhcpd address ip1[-ip2] if-name
dhcpd auto-config [outside]
dhcpd dns dns1 [dns2]
dhcpd wins wins1 [wins2]
dhcpd lease lease-length
dhcpd domain domain-name
dhcpd enable if-name
dhcpd option 66 ascii {server-name | server-ip-str}
dhcpd option 150 ip server-ip1 [ server-ip2]
dhcpd ping-timeout timeout
debug dhcpd event
debug dhcpd packet
Table 6-12 describes the different dhcpd command parameters.
dhcpd Command Parameters
Parameter Description
address ip1- [ip2] Specifies the IP pool address range.
auto-config Enables the Security Appliance to configure DNS, Windows Internet
Naming Service (WINS), and domain name values automatically
from the DHCP client to the DHCP server. If the user also specifies
DNS, WINS, and domain parameters, the command-line interface
(CLI) parameters overwrite the auto-config parameters.
binding Specifies the binding information for a given server IP address and its
associated client hardware address and lease length.
code Specifies the DHCP option code, either 66 or 150.
dns dns1 [dns2] Specifies the IP addresses of the DNS servers for the DHCP client.
domain domain-name Specifies the DNS domain name; for example, cspfa2.com.
if-name Specifies the interface on which to enable the DHCP server.
lease lease-length Specifies the length of the lease, in seconds, granted to the DHCP
client from the DHCP server. The lease indicates how long the client
can use the assigned IP address. The default is 3600 seconds. The
minimum lease length is 300 seconds, and the maximum lease length
is 2,147,483,647 seconds.
option 150 Specifies the Trivial File Transfer Protocol (TFTP) server IP
address(es) designated for Cisco IP Phones in dotted-decimal format.
DHCP option 150 is site-specific; it gives the IP addresses of a list of
TFTP servers.
option 66 Specifies the TFTP server IP address designated for Cisco IP Phones
and gives the IP address or the host name of a single TFTP server.
outside Specifies the outside interface of the firewall.
ping-timeout Specifies the timeout value of a ping, in milliseconds, before an IP
address is assigned to a DHCP client.
server-ip(1,2) Specifies the IP address(es) of a TFTP server.
rameter Description
server-ip-str Specifies the TFTP server in dotted-decimal format, such as 1.1.1.1,
which is treated as a character string by the Security Appliance
DHCP server.
server-name Specifies an American Standard Code for Information Interchange
(ASCII) character string representing the TFTP server.
statistics Provides statistical information, such as address pool, number of
bindings, malformed messages, sent messages, and received
messages.
wins wins1 [wins2] Specifies the IP addresses of the Microsoft NetBIOS name servers
(Windows Internet Naming Service servers). The second server
address is optional.
Table 6-12
In addition to supporting a DHCP client and DHCP server configuration, the Security
Appliance also supports a DHCP relay configuration. The DHCP relay configuration enables
the Security Appliance to assist in dynamic configuration of IP device hosts on any Ethernet
interface. When the Cisco Security Appliance receives a request from a host on an interface,
it forwards the request to a user-configured DHCP server on another interface. The DHCP
relay agent is a feature that is provided by security software version 6.3.
A Security Appliance allows any number of integrated DHCP servers to be configured, and
on any interface. The DHCP client can be configured only on the outside interface, and the
DHCP relay agent can be configured on any interface. The DHCP server and DHCP relay
agent cannot be configured concurrently on the same Security Appliance, but the DHCP
client and DHCP relay agent can be configured concurrently.
As with all other DHCP servers, DNS, Windows Internet Naming Service (WINS), IP address
lease time, and domain information on the Security Appliance can be configured. The
following six steps are required to enable the DHCP server feature on the Security Appliance:
Step 1 Enable the DHCP daemon on the Cisco Security Appliance to listen to
DHCP requests from clients:
pix(config)#dhcpd enable inside
Step 2 Specify the IP address range that the Security Appliance DHCP server
assigns:
pix(config)#dhcpd address 10.10.10.15-10.10.10.100 inside
Step 3 Specify the lease length to grant to the client (the default is 3600
seconds):
pix(config)#dhcpd lease 2700
Configuring Dynamic Host Configuration Protocol on the Cisco Security Appliance 159
Step 4 Specify a DNS server (optional):
pix(config)#dhcpd dns 192.168.10.68 192.168.10.73
Step 5 Specify a WINS server (optional):
pix(config)#dhcpd wins 192.168.10.66
Step 6 Configure the domain name the client will use (optional):
pix(config)#dhcpd domain axum.com
Security Appliance
The Cisco Security Appliance can be configured as either of the following:
■ DHCP server
■ DHCP client
Using the Cisco Security Appliance DHCP Server
The DHCP server is usually used in, but not limited to, SOHO environments. The address
pool of a Cisco Security Appliance DHCP server must be within the same subnet of the
Security Appliance interface that is enabled, and you must specify the associated Security
Appliance interface with if- name. In other words, the client must be physically connected to
the subnet of a Security Appliance interface. The size of the pool is limited to 32 addresses
with a 10-user license and 128 addresses with a 50-user license on the PIX 501. The
unlimited user license on the PIX 501 and all other Security Appliance platforms supports
256 addresses. To configure DHCP on a Security Appliance, use the dhcpd command. The
following is the syntax for the dhcpd command:
dhcpd address ip1[-ip2] if-name
dhcpd auto-config [outside]
dhcpd dns dns1 [dns2]
dhcpd wins wins1 [wins2]
dhcpd lease lease-length
dhcpd domain domain-name
dhcpd enable if-name
dhcpd option 66 ascii {server-name | server-ip-str}
dhcpd option 150 ip server-ip1 [ server-ip2]
dhcpd ping-timeout timeout
debug dhcpd event
debug dhcpd packet
Table 6-12 describes the different dhcpd command parameters.
dhcpd Command Parameters
Parameter Description
address ip1- [ip2] Specifies the IP pool address range.
auto-config Enables the Security Appliance to configure DNS, Windows Internet
Naming Service (WINS), and domain name values automatically
from the DHCP client to the DHCP server. If the user also specifies
DNS, WINS, and domain parameters, the command-line interface
(CLI) parameters overwrite the auto-config parameters.
binding Specifies the binding information for a given server IP address and its
associated client hardware address and lease length.
code Specifies the DHCP option code, either 66 or 150.
dns dns1 [dns2] Specifies the IP addresses of the DNS servers for the DHCP client.
domain domain-name Specifies the DNS domain name; for example, cspfa2.com.
if-name Specifies the interface on which to enable the DHCP server.
lease lease-length Specifies the length of the lease, in seconds, granted to the DHCP
client from the DHCP server. The lease indicates how long the client
can use the assigned IP address. The default is 3600 seconds. The
minimum lease length is 300 seconds, and the maximum lease length
is 2,147,483,647 seconds.
option 150 Specifies the Trivial File Transfer Protocol (TFTP) server IP
address(es) designated for Cisco IP Phones in dotted-decimal format.
DHCP option 150 is site-specific; it gives the IP addresses of a list of
TFTP servers.
option 66 Specifies the TFTP server IP address designated for Cisco IP Phones
and gives the IP address or the host name of a single TFTP server.
outside Specifies the outside interface of the firewall.
ping-timeout Specifies the timeout value of a ping, in milliseconds, before an IP
address is assigned to a DHCP client.
server-ip(1,2) Specifies the IP address(es) of a TFTP server.
rameter Description
server-ip-str Specifies the TFTP server in dotted-decimal format, such as 1.1.1.1,
which is treated as a character string by the Security Appliance
DHCP server.
server-name Specifies an American Standard Code for Information Interchange
(ASCII) character string representing the TFTP server.
statistics Provides statistical information, such as address pool, number of
bindings, malformed messages, sent messages, and received
messages.
wins wins1 [wins2] Specifies the IP addresses of the Microsoft NetBIOS name servers
(Windows Internet Naming Service servers). The second server
address is optional.
Table 6-12
In addition to supporting a DHCP client and DHCP server configuration, the Security
Appliance also supports a DHCP relay configuration. The DHCP relay configuration enables
the Security Appliance to assist in dynamic configuration of IP device hosts on any Ethernet
interface. When the Cisco Security Appliance receives a request from a host on an interface,
it forwards the request to a user-configured DHCP server on another interface. The DHCP
relay agent is a feature that is provided by security software version 6.3.
A Security Appliance allows any number of integrated DHCP servers to be configured, and
on any interface. The DHCP client can be configured only on the outside interface, and the
DHCP relay agent can be configured on any interface. The DHCP server and DHCP relay
agent cannot be configured concurrently on the same Security Appliance, but the DHCP
client and DHCP relay agent can be configured concurrently.
As with all other DHCP servers, DNS, Windows Internet Naming Service (WINS), IP address
lease time, and domain information on the Security Appliance can be configured. The
following six steps are required to enable the DHCP server feature on the Security Appliance:
Step 1 Enable the DHCP daemon on the Cisco Security Appliance to listen to
DHCP requests from clients:
pix(config)#dhcpd enable inside
Step 2 Specify the IP address range that the Security Appliance DHCP server
assigns:
pix(config)#dhcpd address 10.10.10.15-10.10.10.100 inside
Step 3 Specify the lease length to grant to the client (the default is 3600
seconds):
pix(config)#dhcpd lease 2700
Configuring Dynamic Host Configuration Protocol on the Cisco Security Appliance 159
Step 4 Specify a DNS server (optional):
pix(config)#dhcpd dns 192.168.10.68 192.168.10.73
Step 5 Specify a WINS server (optional):
pix(config)#dhcpd wins 192.168.10.66
Step 6 Configure the domain name the client will use (optional):
pix(config)#dhcpd domain axum.com
DNS Reply Modification Using Outside NAT
DNS Reply Modification Using Outside NAT
Configuring Dynamic Host Configuration Protocol on the Cisco
Security Appliance
The Cisco Security Appliance can be configured as either of the following:
■ DHCP server
■ DHCP client
Using the Cisco Security Appliance DHCP Server
The DHCP server is usually used in, but not limited to, SOHO environments. The address
pool of a Cisco Security Appliance DHCP server must be within the same subnet of the
Security Appliance interface that is enabled, and you must specify the associated Security
Appliance interface with if- name. In other words, the client must be physically connected to
the subnet of a Security Appliance interface. The size of the pool is limited to 32 addresses
with a 10-user license and 128 addresses with a 50-user license on the PIX 501. The
unlimited user license on the PIX 501 and all other Security Appliance platforms supports
256 addresses. To configure DHCP on a Security Appliance, use the dhcpd command. The
following is the syntax for the dhcpd command:
dhcpd address ip1[-ip2] if-name
dhcpd auto-config [outside]
dhcpd dns dns1 [dns2]
Web Server
www.cisco.com
10.1.13.3
5. HTTP request to
10.1.13.3.
DNS Server
4. The Security Appliance applies
address translation.
198.133.216.25 10.1.13.3
3. DNS server replies with
198.133.219.25.
1. Request for www.cisco.com
goes out to Security Appliance.
Workstation
User
10.1.13.126
2. Security Appliance
translates the non-routable
source address in the IP
header and forwards the
request to the ISP network
on its outside interface.
Configuring Dynamic Host Configuration Protocol on the Cisco
Security Appliance
The Cisco Security Appliance can be configured as either of the following:
■ DHCP server
■ DHCP client
Using the Cisco Security Appliance DHCP Server
The DHCP server is usually used in, but not limited to, SOHO environments. The address
pool of a Cisco Security Appliance DHCP server must be within the same subnet of the
Security Appliance interface that is enabled, and you must specify the associated Security
Appliance interface with if- name. In other words, the client must be physically connected to
the subnet of a Security Appliance interface. The size of the pool is limited to 32 addresses
with a 10-user license and 128 addresses with a 50-user license on the PIX 501. The
unlimited user license on the PIX 501 and all other Security Appliance platforms supports
256 addresses. To configure DHCP on a Security Appliance, use the dhcpd command. The
following is the syntax for the dhcpd command:
dhcpd address ip1[-ip2] if-name
dhcpd auto-config [outside]
dhcpd dns dns1 [dns2]
Web Server
www.cisco.com
10.1.13.3
5. HTTP request to
10.1.13.3.
DNS Server
4. The Security Appliance applies
address translation.
198.133.216.25 10.1.13.3
3. DNS server replies with
198.133.219.25.
1. Request for www.cisco.com
goes out to Security Appliance.
Workstation
User
10.1.13.126
2. Security Appliance
translates the non-routable
source address in the IP
header and forwards the
request to the ISP network
on its outside interface.
User Obtaining DNS Resolution from the Outside
User Obtaining DNS Resolution from the Outside
Before the release of version 7.0, you would use the alias command to modify DNS server
replies. As for version 7.0, this feature has been integrated into the translation commands,
such as the static command. Using the example shown in Figure 6-2, you would use the
following command to create the DNS reply modification:
Pix(config)# static (inside,outside) 198.133.219.25 10.1.33.3 netmask 255.255.255.255
You can use DNS doctoring to manipulate the DNS replies for servers that exist outside your
network, with Outside NAT enabled. Using this process will allow you to restrict your users
to only destination IP addresses that reside on the Inside subnet, shielding them from the
possibility of relying on outside DNS problems. Using the example shown in Figure 6-3, you
would use the following command to create the DNS reply modification:
Pix(config)# static (outside,inside) 10.1.33.3 198.133.219.25 netmask
255.255.255.255
Web Server
www.cisco.com
10.1.13.3
5. HTTP request to
10.1.13.3.
DNS Server
4. The Security Appliance applies
address translation to the
destination address and to
the embedded IP address
of the web server.
198.133.216.25 10.1.13.3
3. DNS server replies with
198.133.219.25.
1. Request for www.cisco.com
goes out to Security Appliance.
Workstation
User
10.1.13.126
2. Security Appliance
translates the non-routable
source addressin the IP
header and forwards the
request to the ISP network
on its outside interface.
Before the release of version 7.0, you would use the alias command to modify DNS server
replies. As for version 7.0, this feature has been integrated into the translation commands,
such as the static command. Using the example shown in Figure 6-2, you would use the
following command to create the DNS reply modification:
Pix(config)# static (inside,outside) 198.133.219.25 10.1.33.3 netmask 255.255.255.255
You can use DNS doctoring to manipulate the DNS replies for servers that exist outside your
network, with Outside NAT enabled. Using this process will allow you to restrict your users
to only destination IP addresses that reside on the Inside subnet, shielding them from the
possibility of relying on outside DNS problems. Using the example shown in Figure 6-3, you
would use the following command to create the DNS reply modification:
Pix(config)# static (outside,inside) 10.1.33.3 198.133.219.25 netmask
255.255.255.255
Web Server
www.cisco.com
10.1.13.3
5. HTTP request to
10.1.13.3.
DNS Server
4. The Security Appliance applies
address translation to the
destination address and to
the embedded IP address
of the web server.
198.133.216.25 10.1.13.3
3. DNS server replies with
198.133.219.25.
1. Request for www.cisco.com
goes out to Security Appliance.
Workstation
User
10.1.13.126
2. Security Appliance
translates the non-routable
source addressin the IP
header and forwards the
request to the ISP network
on its outside interface.
Support for Domain Name System Messages
Support for Domain Name System Messages
Security Appliance fully supports NAT and PAT Domain Name System (DNS) messages
originating from either a more secure interface or less secure interfaces. This means that if a
client on an inside network requests DNS resolution of an inside address from a DNS server
on an outside interface, the DNS record is translated correctly. To illustrate this point, Figure
6-2 shows a user from inside obtaining DNS resolution from the outside (maybe from an
Internet service provider) for a web server on the inside. This process is called DNS reply
modification or DNS doctoring.
Security Appliance fully supports NAT and PAT Domain Name System (DNS) messages
originating from either a more secure interface or less secure interfaces. This means that if a
client on an inside network requests DNS resolution of an inside address from a DNS server
on an outside interface, the DNS record is translated correctly. To illustrate this point, Figure
6-2 shows a user from inside obtaining DNS resolution from the outside (maybe from an
Internet service provider) for a web server on the inside. This process is called DNS reply
modification or DNS doctoring.
Saving Your Configuration
Saving Your Configuration
Configuration changes that you have made stay in the random access memory (RAM) of the
Security Appliance unless you save them to Flash memory. If for any reason the Security
Appliance must be rebooted, the configuration changes you made are lost. So, when you
finish entering commands in the configuration, save the changes to Flash memory by using
the write memory command, as follows:
Pix# write memory
You are now finished configuring the Cisco Security Appliance. This basic configuration lets
protected network users start connections and prevents users on unprotected networks from
accessing (or attacking) protected hosts.
Use the write terminal or show running-config command to view your current configuration.
Configuration changes that you have made stay in the random access memory (RAM) of the
Security Appliance unless you save them to Flash memory. If for any reason the Security
Appliance must be rebooted, the configuration changes you made are lost. So, when you
finish entering commands in the configuration, save the changes to Flash memory by using
the write memory command, as follows:
Pix# write memory
You are now finished configuring the Cisco Security Appliance. This basic configuration lets
protected network users start connections and prevents users on unprotected networks from
accessing (or attacking) protected hosts.
Use the write terminal or show running-config command to view your current configuration.
Testing Your Configuration
Testing Your Configuration
Making sure that the configuration you entered works is an important part of the
configuration process. At this point, you test basic connectivity from the inside interface out
to the other interfaces. Use the ping and debug commands to test your connectivity.
The ping command sends an Internet Control Message Protocol (ICMP) echo request
message to the target IP address and expects an ICMP echo reply. By default, the Security
Appliance denies all inbound traffic through the outside interface. Based on your network
security policy, you should consider configuring the Security Appliance to deny all ICMP
traffic to the outside interface, or any other interface you deem necessary, by entering the
icmp command. The icmp command controls ICMP traffic that terminates on the Security
Appliance. If no ICMP control list is configured, the Security Appliance accepts all ICMP
traffic that terminates at any interface (including the outside interface). For example, when
you first configure a PIX Firewall, it is a good idea to be able to ping an interface and get a
response. The following makes that possible for the outside interface:
The icmp permit any any outside command is used during the testing/debugging phase of
your configuration process. Make sure that you change it so it does not respond to ping
requests after you complete testing. It is a security risk to leave it set to accept and respond
to ICMP packets.
After the icmp permit command has been configured, you can ping the outside interface on
your Cisco Security Appliance and ping from hosts on each firewall interface. For example:
ping outside 192.168.1.1
You also can monitor ping results by starting debug icmp trace. The debug command will
display messages that contain icmp type values. Table 6-11 describes the icmp-type values
supported in version 7.0.
Table 6-11 icmp Type Values
Type Values Description
0 Echo-reply
3 Unreachable
4 Source-quench
5 Redirect
6 Alternate-address
8 Echo
9 Router-advertisement
10 Router-solicitation
11 Time-exceeded
12 Parameter-problem
13 Timestamp-request
14 Timestamp-reply
15 Information-request
16 Information-reply
17 Mask-request
18 Mask-reply
31 Conversion-error
32 Mobile-redirect
Making sure that the configuration you entered works is an important part of the
configuration process. At this point, you test basic connectivity from the inside interface out
to the other interfaces. Use the ping and debug commands to test your connectivity.
The ping command sends an Internet Control Message Protocol (ICMP) echo request
message to the target IP address and expects an ICMP echo reply. By default, the Security
Appliance denies all inbound traffic through the outside interface. Based on your network
security policy, you should consider configuring the Security Appliance to deny all ICMP
traffic to the outside interface, or any other interface you deem necessary, by entering the
icmp command. The icmp command controls ICMP traffic that terminates on the Security
Appliance. If no ICMP control list is configured, the Security Appliance accepts all ICMP
traffic that terminates at any interface (including the outside interface). For example, when
you first configure a PIX Firewall, it is a good idea to be able to ping an interface and get a
response. The following makes that possible for the outside interface:
The icmp permit any any outside command is used during the testing/debugging phase of
your configuration process. Make sure that you change it so it does not respond to ping
requests after you complete testing. It is a security risk to leave it set to accept and respond
to ICMP packets.
After the icmp permit command has been configured, you can ping the outside interface on
your Cisco Security Appliance and ping from hosts on each firewall interface. For example:
ping outside 192.168.1.1
You also can monitor ping results by starting debug icmp trace. The debug command will
display messages that contain icmp type values. Table 6-11 describes the icmp-type values
supported in version 7.0.
Table 6-11 icmp Type Values
Type Values Description
0 Echo-reply
3 Unreachable
4 Source-quench
5 Redirect
6 Alternate-address
8 Echo
9 Router-advertisement
10 Router-solicitation
11 Time-exceeded
12 Parameter-problem
13 Timestamp-request
14 Timestamp-reply
15 Information-request
16 Information-reply
17 Mask-request
18 Mask-reply
31 Conversion-error
32 Mobile-redirect
Routing Information Protocol
Routing Information Protocol
The Routing Information Protocol (RIP) can be enabled to build the Cisco Security
Appliance routing table. RIP configuration specifies whether the Security Appliance updates
its routing tables by passively listening to RIP traffic and whether the interface broadcasts
itself as a default route for network traffic on that interface. When using RIP version 2 with
Security Appliance software versions earlier than 5.3, it is important to configure the router
providing the RIP updates with the network address of the Security Appliance interface. The
default version is 1 if not explicitly specified. The syntax to enable RIP is as follows:
rip if-name default | passive [version [1 | 2]] [authentication [text | md5
key (key-id)]]
Table 6-10 describes the rip command parameters.
The Routing Information Protocol (RIP) can be enabled to build the Cisco Security
Appliance routing table. RIP configuration specifies whether the Security Appliance updates
its routing tables by passively listening to RIP traffic and whether the interface broadcasts
itself as a default route for network traffic on that interface. When using RIP version 2 with
Security Appliance software versions earlier than 5.3, it is important to configure the router
providing the RIP updates with the network address of the Security Appliance interface. The
default version is 1 if not explicitly specified. The syntax to enable RIP is as follows:
rip if-name default | passive [version [1 | 2]] [authentication [text | md5
key (key-id)]]
Table 6-10 describes the rip command parameters.
route Command
route Command
The route command tells the Cisco Security Appliance where to send information that is
forwarded on a specific interface and that is destined for a particular network address. You
add static routes to the Security Appliance using the route command.
Table 6-9 describes the route command parameters, the syntax of which is as follows:
route if-name ip-address netmask gateway-ip [metric | tunneled]
The route command tells the Cisco Security Appliance where to send information that is
forwarded on a specific interface and that is destined for a particular network address. You
add static routes to the Security Appliance using the route command.
Table 6-9 describes the route command parameters, the syntax of which is as follows:
route if-name ip-address netmask gateway-ip [metric | tunneled]
global Command
global Command
The global command is used to define the address or range of addresses into which the
addresses defined by the nat command are translated. It is important that the nat-id be
identical to the nat-id used in the nat command. The nat-id pairs the IP address defined by
the global and nat commands so that network translation can take place. The syntax of the
global command is as follows:
global (if-name) nat-id global-ip | global-ip-global-ip [netmask netmask]
Table 6-8 describes the parameters and options for the global command.
The global command is used to define the address or range of addresses into which the
addresses defined by the nat command are translated. It is important that the nat-id be
identical to the nat-id used in the nat command. The nat-id pairs the IP address defined by
the global and nat commands so that network translation can take place. The syntax of the
global command is as follows:
global (if-name) nat-id global-ip | global-ip-global-ip [netmask netmask]
Table 6-8 describes the parameters and options for the global command.
nat-control Command
nat-control Command
The nat-control command is used to enforce address hinding on the inside and outside
interfaces of a Security Appliance. With nat-control enabled, all packets that flow through
the Security Appliance require a NAT rule, or the packets will be denied access through the
appliance. If an inside NAT policy is enabled on an interface, each inside address must have
an inside NAT rule configured or communication will not be permitted through the Security
Appliance. Additionally, if an outside NAT policy is enabled on an interface, all outside
addresses must have an outside NAT rule configured or communication will not be permitted
through the Security Appliance.
The nat-control command is not enabled by default, requiring that only hosts that undergo
NAT need a NAT rule.
The nat-control command is used to enforce address hinding on the inside and outside
interfaces of a Security Appliance. With nat-control enabled, all packets that flow through
the Security Appliance require a NAT rule, or the packets will be denied access through the
appliance. If an inside NAT policy is enabled on an interface, each inside address must have
an inside NAT rule configured or communication will not be permitted through the Security
Appliance. Additionally, if an outside NAT policy is enabled on an interface, all outside
addresses must have an outside NAT rule configured or communication will not be permitted
through the Security Appliance.
The nat-control command is not enabled by default, requiring that only hosts that undergo
NAT need a NAT rule.
duplex Command
duplex Command
The duplex command is used to set an interfaces duplex mode. The duplex for an interface
can be set manually by defining if the interface should be in half-duplex or full-duplex mode.
Additionally, you can set the interface to autodetect the duplex from the line connected to
the interface.
Table 6-7 describes the command parameters for the duplex command, which must be used
in the interface configuration mode. The syntax for the duplex command is as follows:
duplex {auto | full | half}
The duplex command is used to set an interfaces duplex mode. The duplex for an interface
can be set manually by defining if the interface should be in half-duplex or full-duplex mode.
Additionally, you can set the interface to autodetect the duplex from the line connected to
the interface.
Table 6-7 describes the command parameters for the duplex command, which must be used
in the interface configuration mode. The syntax for the duplex command is as follows:
duplex {auto | full | half}
speed Command
speed Command
The speed command is used to set the communication speed of the interface. The speed
setting is only used on copper Ethernet interfaces (RJ-45), with the fiber Gigabit Ethernet
interfaces set to a speed of 1000 Mbps by default using the nonegotiate syntax. You can use
the speed command to set the speed on the interface to 10 Mbps or 100 Mbps. Additionally,
you can set the speed command to autodetect the speed of the interface from the line
connected to the interface using the auto syntax. Table 6-6 describes the command
parameters for the speed command, which must be used in the interface configuration mode.
The syntax for the speed command is as follows:
speed {auto | 10 | 100 | nonegotiate}
The speed command is used to set the communication speed of the interface. The speed
setting is only used on copper Ethernet interfaces (RJ-45), with the fiber Gigabit Ethernet
interfaces set to a speed of 1000 Mbps by default using the nonegotiate syntax. You can use
the speed command to set the speed on the interface to 10 Mbps or 100 Mbps. Additionally,
you can set the speed command to autodetect the speed of the interface from the line
connected to the interface using the auto syntax. Table 6-6 describes the command
parameters for the speed command, which must be used in the interface configuration mode.
The syntax for the speed command is as follows:
speed {auto | 10 | 100 | nonegotiate}
Configuring Port Address Translation
Configuring Port Address Translation
Port Address Translation (PAT) can be configured using the same command as NAT. PAT
maps a single global IP address to many local addresses. PAT extends the range of available
outside addresses at your site by dynamically assigning unique port numbers to the outside
address as a connection is requested. A single IP address has up to 65,535 ports available for
making connections. For PAT, the port number uniquely identifies each connection.
PAT translates a group of local addresses to a single global IP address with a unique source
port (above 1024). When a local host accesses the destination network, the Firewall services
module assigns it the global IP address and then a unique port number. Each host receives
the same IP address, but because the source port numbers are unique, the responding traffic,
which includes the IP address and port number as the destination, can be assigned to the
correct host. It is highly unlikely that you would run out of addresses in PAT configuration
because there are more than 64,000 ports available.
PAT enables you to use a single global address, thus conserving routable addresses. You can
even use the destination actual interface IP address as the PAT IP address (this type of
configuration is used, but not limited to, the outside interface). PAT does not work with
multimedia applications that have an inbound data stream different from the outgoing
control path.
In large enterprise environments, to use NAT, you must have a large number of routable
addresses in the global pool. If the destination network requires registered addresses, such as
the Internet, you might encounter a shortage of usable addresses. This can be a disadvantage.
PAT does not work with applications that have an inbound data stream on one port and the
outgoing control path on another, such as multimedia applications. For those situations, it is
more advantageous to use NAT. Example 6-5 shows a sample configuration for PAT.
Example 6-4 Sample Configuration for the nat Command
nat (inside) 1 10.10.10.0 255.255.255.0 0 0
nat (inside) 2 172.16.1.0 255.255.255.0 0 0
Example 6-5 Sample Configuration for Configuring PAT on the Inside Interface
nat (inside) 1 10.10.30.0 255.255.255.0
Port Address Translation (PAT) can be configured using the same command as NAT. PAT
maps a single global IP address to many local addresses. PAT extends the range of available
outside addresses at your site by dynamically assigning unique port numbers to the outside
address as a connection is requested. A single IP address has up to 65,535 ports available for
making connections. For PAT, the port number uniquely identifies each connection.
PAT translates a group of local addresses to a single global IP address with a unique source
port (above 1024). When a local host accesses the destination network, the Firewall services
module assigns it the global IP address and then a unique port number. Each host receives
the same IP address, but because the source port numbers are unique, the responding traffic,
which includes the IP address and port number as the destination, can be assigned to the
correct host. It is highly unlikely that you would run out of addresses in PAT configuration
because there are more than 64,000 ports available.
PAT enables you to use a single global address, thus conserving routable addresses. You can
even use the destination actual interface IP address as the PAT IP address (this type of
configuration is used, but not limited to, the outside interface). PAT does not work with
multimedia applications that have an inbound data stream different from the outgoing
control path.
In large enterprise environments, to use NAT, you must have a large number of routable
addresses in the global pool. If the destination network requires registered addresses, such as
the Internet, you might encounter a shortage of usable addresses. This can be a disadvantage.
PAT does not work with applications that have an inbound data stream on one port and the
outgoing control path on another, such as multimedia applications. For those situations, it is
more advantageous to use NAT. Example 6-5 shows a sample configuration for PAT.
Example 6-4 Sample Configuration for the nat Command
nat (inside) 1 10.10.10.0 255.255.255.0 0 0
nat (inside) 2 172.16.1.0 255.255.255.0 0 0
Example 6-5 Sample Configuration for Configuring PAT on the Inside Interface
nat (inside) 1 10.10.30.0 255.255.255.0
nat Command
nat Command
The nat (Network Address Translation) command lets you dynamically translate a set of IP
addresses (usually on the inside) to a global set of IP addresses.
The nat command is always paired with a global command, with the exception of the nat 0
command. Table 6-5 describes the command parameters for the nat command, the syntax of
which is as follows:
nat (if-name) nat-id local-ip [netmask] [dns] [[tcp] tcp_max_conns [emb_limit]
[norandomseq]]] [udp udp_max_conns]
1 NAT = Network Address Translation
2 DNS = Domain Name System
3 UDP = User Datagram Protocol
NOTE PIX version 6.2 and later support bidirectional translation of inside network IP
addresses to global IP addresses and translation of outside IP addresses to inside network
IP addresses.
Table 6-5 nat Command Parameters
Command Parameter Description
(if-name) Specifies the internal network
The nat (Network Address Translation) command lets you dynamically translate a set of IP
addresses (usually on the inside) to a global set of IP addresses.
The nat command is always paired with a global command, with the exception of the nat 0
command. Table 6-5 describes the command parameters for the nat command, the syntax of
which is as follows:
nat (if-name) nat-id local-ip [netmask] [dns] [[tcp] tcp_max_conns [emb_limit]
[norandomseq]]] [udp udp_max_conns]
1 NAT = Network Address Translation
2 DNS = Domain Name System
3 UDP = User Datagram Protocol
NOTE PIX version 6.2 and later support bidirectional translation of inside network IP
addresses to global IP addresses and translation of outside IP addresses to inside network
IP addresses.
Table 6-5 nat Command Parameters
Command Parameter Description
(if-name) Specifies the internal network
ip address Command
ip address Command
All the interfaces on a Security Appliance that will be used must be configured with an IP
address. The IP address can be configured manually or through Dynamic Host Configuration
Protocol (DHCP). The DHCP feature is usually used on Cisco Security Appliance small
office/home office (SOHO) models. DHCP is discussed later in this chapter.
The ip address command, while in interface configuration mode, is used to configure IP
addresses on the Security Appliance interfaces. The ip address command binds a logical
address (IP address) to the hardware ID. Additionally, you can use the ip address command
to assign a standby IP address for a Security Appliance that will be used during a failover
situation. Table 6-4 describes the parameters for the ip address command, the syntax of
which is as follows:
ip address ip-address [netmask] [standby ip_address]
Example 6-3 shows configuration of the inside interface with an IP address of 10.10.10.14/24.
In addition to manually assigned IP addresses, the Security Appliance can act as a DHCP
client. With version 7.0, the ip address command can use dhcp as an entry instead of an IP
address.
This will allow a DHCP server to assign an IP address and netmask to the interface. A default
gateway will also be assigned to the Security Appliance if it is required. You can flush and
renew the IP address assignment through the DHCP server by reentering the ip address dhcp
command.
Use the show ip command to view the configured IP address on a Security Appliance
interface.
Table 6-4 ip address Command Parameters
Command Parameter Description
ip-address Specifies the IP address of the interface.
netmask Specifies the appropriate network mask. If the mask value is
not entered, the firewall assigns a classful network mask.
standby ip_address Specifies the IP address for the standby unit for failover.
All the interfaces on a Security Appliance that will be used must be configured with an IP
address. The IP address can be configured manually or through Dynamic Host Configuration
Protocol (DHCP). The DHCP feature is usually used on Cisco Security Appliance small
office/home office (SOHO) models. DHCP is discussed later in this chapter.
The ip address command, while in interface configuration mode, is used to configure IP
addresses on the Security Appliance interfaces. The ip address command binds a logical
address (IP address) to the hardware ID. Additionally, you can use the ip address command
to assign a standby IP address for a Security Appliance that will be used during a failover
situation. Table 6-4 describes the parameters for the ip address command, the syntax of
which is as follows:
ip address ip-address [netmask] [standby ip_address]
Example 6-3 shows configuration of the inside interface with an IP address of 10.10.10.14/24.
In addition to manually assigned IP addresses, the Security Appliance can act as a DHCP
client. With version 7.0, the ip address command can use dhcp as an entry instead of an IP
address.
This will allow a DHCP server to assign an IP address and netmask to the interface. A default
gateway will also be assigned to the Security Appliance if it is required. You can flush and
renew the IP address assignment through the DHCP server by reentering the ip address dhcp
command.
Use the show ip command to view the configured IP address on a Security Appliance
interface.
Table 6-4 ip address Command Parameters
Command Parameter Description
ip-address Specifies the IP address of the interface.
netmask Specifies the appropriate network mask. If the mask value is
not entered, the firewall assigns a classful network mask.
standby ip_address Specifies the IP address for the standby unit for failover.
nameif Command Parameters
Table 6-3 nameif Command Parameters
Command Parameter Description
hardware-id Indicates the interface’s physical location on the Cisco Security
Appliance.
if-name Specifies the name by which you refer to this interface. The name
cannot have any spaces and must not exceed 48 characters.
Example 6-2 Sample Configuration for the nameif Command
nameif ethernet0 outside
nameif ethernet1 inside
nameif ethernet2 dmz
Command Parameter Description
hardware-id Indicates the interface’s physical location on the Cisco Security
Appliance.
if-name Specifies the name by which you refer to this interface. The name
cannot have any spaces and must not exceed 48 characters.
Example 6-2 Sample Configuration for the nameif Command
nameif ethernet0 outside
nameif ethernet1 inside
nameif ethernet2 dmz
nameif Command
nameif Command
As the name intuitively indicates, the nameif command is used to name an interface. The
outside and inside interfaces are named by default and have default security values of 0 and
100, respectively. By default, the interfaces have their hardware ID. Ethernet 0 is the outside
interface, and Ethernet 1 is the inside interface. The names that are configured by the nameif
command are user-friendly and are easier to use for advanced configuration later.
To assign a name for an interface, use the command in interface configuration mode. The
syntax of the nameif command is as follows:
nameif hardware-id if-name
As the name intuitively indicates, the nameif command is used to name an interface. The
outside and inside interfaces are named by default and have default security values of 0 and
100, respectively. By default, the interfaces have their hardware ID. Ethernet 0 is the outside
interface, and Ethernet 1 is the inside interface. The names that are configured by the nameif
command are user-friendly and are easier to use for advanced configuration later.
To assign a name for an interface, use the command in interface configuration mode. The
syntax of the nameif command is as follows:
nameif hardware-id if-name
security-level Command
security-level Command
The security-level value controls how hosts/devices on the different interfaces interact with
each other. By default, hosts/devices connected to interfaces with higher-security levels can
access hosts/devices connected to interfaces with lower-security interfaces. Hosts/devices
connected to interfaces with lower-security interfaces cannot access hosts/devices connected
to interfaces with higher-security interfaces without the assistance of access lists. The
security-level command is new to version 7.0 and replaces the older nameif command feature
that assigned the security level for an interface. Two interfaces, the inside and outside
interfaces, have set security levels but can be overridden using this command. The inside
interface has a default security level of 100; the outside interface has a default security level
of 0. Newly added interfaces receive a default security level of 0. To assign a new security
level to an interface, use the security-level command in the interface command mode. The
syntax of the security-level command is as follows:
security-level number
where number can be a numerical value from 1 to 99 indicating the security level.
interface has a default security level of 100; the outside interface has a default security level
of 0. Newly added interfaces receive a default security level of 0. To assign a new security
level to an interface, use the security-level command in the interface command mode. The
syntax of the security-level command is as follows:
security-level number
where number can be a numerical value from 1 to 99 indicating the security level.
The security-level value controls how hosts/devices on the different interfaces interact with
each other. By default, hosts/devices connected to interfaces with higher-security levels can
access hosts/devices connected to interfaces with lower-security interfaces. Hosts/devices
connected to interfaces with lower-security interfaces cannot access hosts/devices connected
to interfaces with higher-security interfaces without the assistance of access lists. The
security-level command is new to version 7.0 and replaces the older nameif command feature
that assigned the security level for an interface. Two interfaces, the inside and outside
interfaces, have set security levels but can be overridden using this command. The inside
interface has a default security level of 100; the outside interface has a default security level
of 0. Newly added interfaces receive a default security level of 0. To assign a new security
level to an interface, use the security-level command in the interface command mode. The
syntax of the security-level command is as follows:
security-level number
where number can be a numerical value from 1 to 99 indicating the security level.
interface has a default security level of 100; the outside interface has a default security level
of 0. Newly added interfaces receive a default security level of 0. To assign a new security
level to an interface, use the security-level command in the interface command mode. The
syntax of the security-level command is as follows:
security-level number
where number can be a numerical value from 1 to 99 indicating the security level.
interface Command
interface Command
The interface command identifies the interface hardware card and enables the interface allin-
one command. All interfaces on a Cisco Security Appliance are shut down by default and
are explicitly enabled by the interface command. The basic syntax of the interface command
is as follows:
interface physical_interface[.subinterface] | mapped_name[shutdown]*
The interface command identifies the interface hardware card and enables the interface allin-
one command. All interfaces on a Cisco Security Appliance are shut down by default and
are explicitly enabled by the interface command. The basic syntax of the interface command
is as follows:
interface physical_interface[.subinterface] | mapped_name[shutdown]*
Configuring a Cisco Security Appliance
Configuring a Cisco Security Appliance
Eight important commands are used to produce a basic working configuration for a Security
Appliance:
■ interface
■ security-level
■ nameif
■ ip address
■ nat
■ nat-control
NOTE PIX version 6.2 and later, as well as ASA Security Appliance version 7.0 and later,
supports 16 privilege levels. This feature enables you to assign Cisco Security Appliance
commands to one of the 16 levels. These privilege levels can also be assigned to users. This
is discussed in detail in Chapter 4, “System Management/ Maintenance.”
142 Chapter 6: Getting Started with the Cisco Security Appliance Family of Firewalls
■ global
■ route
Before you use these commands, it can prove very useful to draw a diagram of your Cisco
Security Appliance with the different security levels, interfaces, and Internet Protocol (IP)
addresses. Figure 6-1 shows one such diagram that is used for the discussion in this chapter.
Eight important commands are used to produce a basic working configuration for a Security
Appliance:
■ interface
■ security-level
■ nameif
■ ip address
■ nat
■ nat-control
NOTE PIX version 6.2 and later, as well as ASA Security Appliance version 7.0 and later,
supports 16 privilege levels. This feature enables you to assign Cisco Security Appliance
commands to one of the 16 levels. These privilege levels can also be assigned to users. This
is discussed in detail in Chapter 4, “System Management/ Maintenance.”
142 Chapter 6: Getting Started with the Cisco Security Appliance Family of Firewalls
■ global
■ route
Before you use these commands, it can prove very useful to draw a diagram of your Cisco
Security Appliance with the different security levels, interfaces, and Internet Protocol (IP)
addresses. Figure 6-1 shows one such diagram that is used for the discussion in this chapter.
Dynamic address translation
■ Dynamic address translation—Is broken into two categories:
— Network Address Translation (NAT)—Multiple local hosts translate to a
pool of global addresses.
— Port Address Translation (PAT)—Multiple local hosts translate to a single
global address.
■ Static translation—A single local address translates to a single global address. Static rules
provide the translation to allow connection from a lower security level to a higher
security level, but this connection must be allowed in the security policy. This connection
can be allowed using either the conduit or access-list command. Access lists must be part
of an access group and must be configured to a specific interface.
■ show xlate—Displays translation slot information. Many options are available to
display specific information about the address translations.
■ clear xlate—Clears the translation table. Again, many options enable you to clear
specific portions of the translation table.
A single command with numerous options is used to troubleshoot connections:
■ show conn—Displays the number of and information about the active connections for
the options specified.
— Network Address Translation (NAT)—Multiple local hosts translate to a
pool of global addresses.
— Port Address Translation (PAT)—Multiple local hosts translate to a single
global address.
■ Static translation—A single local address translates to a single global address. Static rules
provide the translation to allow connection from a lower security level to a higher
security level, but this connection must be allowed in the security policy. This connection
can be allowed using either the conduit or access-list command. Access lists must be part
of an access group and must be configured to a specific interface.
■ show xlate—Displays translation slot information. Many options are available to
display specific information about the address translations.
■ clear xlate—Clears the translation table. Again, many options enable you to clear
specific portions of the translation table.
A single command with numerous options is used to troubleshoot connections:
■ show conn—Displays the number of and information about the active connections for
the options specified.
Configuring DNS Support
Configuring DNS Support
It is not necessary to configure DNS support on Cisco Security Appliance. By default, the
Security Appliance 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
Security Appliance allows the outbound queries. However, the Security Appliance 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 Security Appliance 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>]
It is not necessary to configure DNS support on Cisco Security Appliance. By default, the
Security Appliance 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
Security Appliance allows the outbound queries. However, the Security Appliance 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 Security Appliance 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>]
Translation Versus Connection
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.
10.10.10.10
10.10.10.1
Internet
192.168.0.1
Perimeter Router
192.168.0.2
Mail
172.16.1.2
10.10.10.11
10.10.10.12
All internal nodes will be NAT to 192.168.0.10 to
192.168.0.61 and then PAT to 192.168.0.62.
All devices on the DMZ segment will have a static
translation to 192.168.0.3 (mail) .4 (web) .5(DNS).
Web
172.16.1.3
DNS
172.16.1.4
Translation Versus Connection 127
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 Security Appliance 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 Security
Appliance 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.
Table 5-3 show/clear xlate Command Options
Command Option Description
detail If specified, displays the translation type and interface
information
[global | local ip1[-ip2] [netmask mask] Displays active translations by global IP address or local
IP address using the network mask to qualify the IP
address
interface if1 [,if2] [,ifn] Displays active translations by interface
lport | gport port [-port] Displays active translations by local and global ports
state Displays active translations by state (use the translation
flags listed in Table 5-4)
Table 5-4 Translation Flags
Flag Description
s Static translation slot
d Dumps the translation slot on the next cleaning cycle
r Port map translation (PAT)
n No randomization of TCP sequence number
o Outside address translations
i Inside address translations
D DNS A Resource Record rewrite
I Identity translation from nat0
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.
Table 5-5 show conn Command Options
Command Option Description
count Displays the number of used connections (its accuracy
depends on the volume and type of traffic)
detail Displays the specified translation type and interface
information
foreign | local ip [-ip2] netmask mask Displays active connections by foreign or local IP address
and qualifies connections by network mask
fport | lport port1 [-port2] Displays foreign or local active connections by port
protocol tcp | udp | protocol Displays active connections by protocol type
state Displays active connections by their current state (see
Table 5-6)
Table 5-6 Connection Flags
Flag Description
U Up
f Inside FIN
F Outside FIN
r Inside acknowledged FIN
R Outside acknowledged FIN
s Awaiting outside SYN
S Awaiting inside SYN
M SMTP data
T TCP SIP connection
I Inbound data
O Outbound data
q SQL*Net data
d Dump
continues
Support
It is not necessary to configure DNS support on Cisco Security Appliance. By default, the
Security Appliance 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
Security Appliance allows the outbound queries. However, the Security Appliance 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 Security Appliance 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>]
P Inside back connection
E Outside back connection
G Group
a Awaiting outside ACK to SYN
A Awaiting inside ACK to SYN
B Initial SYN from outside
R RPC
H H.323
T UDP SIP connection
m SIP media connection
t SIP transient connection
D DNS
Table 5-6
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.
10.10.10.10
10.10.10.1
Internet
192.168.0.1
Perimeter Router
192.168.0.2
172.16.1.2
10.10.10.11
10.10.10.12
All internal nodes will be NAT to 192.168.0.10 to
192.168.0.61 and then PAT to 192.168.0.62.
All devices on the DMZ segment will have a static
translation to 192.168.0.3 (mail) .4 (web) .5(DNS).
Web
172.16.1.3
DNS
172.16.1.4
Translation Versus Connection 127
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 Security Appliance 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 Security
Appliance 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.
Table 5-3 show/clear xlate Command Options
Command Option Description
detail If specified, displays the translation type and interface
information
[global | local ip1[-ip2] [netmask mask] Displays active translations by global IP address or local
IP address using the network mask to qualify the IP
address
interface if1 [,if2] [,ifn] Displays active translations by interface
lport | gport port [-port] Displays active translations by local and global ports
state Displays active translations by state (use the translation
flags listed in Table 5-4)
Table 5-4 Translation Flags
Flag Description
s Static translation slot
d Dumps the translation slot on the next cleaning cycle
r Port map translation (PAT)
n No randomization of TCP sequence number
o Outside address translations
i Inside address translations
D DNS A Resource Record rewrite
I Identity translation from nat0
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.
Table 5-5 show conn Command Options
Command Option Description
count Displays the number of used connections (its accuracy
depends on the volume and type of traffic)
detail Displays the specified translation type and interface
information
foreign | local ip [-ip2] netmask mask Displays active connections by foreign or local IP address
and qualifies connections by network mask
fport | lport port1 [-port2] Displays foreign or local active connections by port
protocol tcp | udp | protocol Displays active connections by protocol type
state Displays active connections by their current state (see
Table 5-6)
Table 5-6 Connection Flags
Flag Description
U Up
f Inside FIN
F Outside FIN
r Inside acknowledged FIN
R Outside acknowledged FIN
s Awaiting outside SYN
S Awaiting inside SYN
M SMTP data
T TCP SIP connection
I Inbound data
O Outbound data
q SQL*Net data
d Dump
continues
Support
It is not necessary to configure DNS support on Cisco Security Appliance. By default, the
Security Appliance 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
Security Appliance allows the outbound queries. However, the Security Appliance 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 Security Appliance 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>]
P Inside back connection
E Outside back connection
G Group
a Awaiting outside ACK to SYN
A Awaiting inside ACK to SYN
B Initial SYN from outside
R RPC
H H.323
T UDP SIP connection
m SIP media connection
t SIP transient connection
D DNS
Table 5-6
Bidirectional NAT
Bidirectional NAT
Cisco PIX Firewall software version 6.2, as well as ASA Security Appliance software version
7.0, 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.
Cisco PIX Firewall software version 6.2, as well as ASA Security Appliance software version
7.0, 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.
Configuring Multiple Translation Types on the Cisco Security Appliance
Configuring Multiple Translation Types on the Cisco Security Appliance
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
! !!
Address Translation 125
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
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
! !!
Address Translation 125
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
Using the static Command for Port Redirection
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 a Security Appliance 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 Security Appliance for IP address 192.168.0.9 on TCP port 21 to 10.10.10.9
on TCP port 2100.
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 a Security Appliance 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 Security Appliance for IP address 192.168.0.9 on TCP port 21 to 10.10.10.9
on TCP port 2100.
Static Translation
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
This is the configuration used in Figure 5-6. Note that the node is now accessible from the
Internet.
NOTE Chapter 7 discusses conduits and access lists in greater detail.
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
This is the configuration used in Figure 5-6. Note that the node is now accessible from the
Internet.
NOTE Chapter 7 discusses conduits and access lists in greater detail.
Network Address Translation
Network Address Translation
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 Security Appliance to identify addresses that are not to be
translated. The nat 0 command is commonly called the “no nat” command.
! ""
" #
"
$ "" #$
%
" & &
122 Chapter 5: Understanding Cisco Security Appliance Translation and Connection
PIX Firewall OS Version 6.3(2) incorporated the ability to configure a policy NAT. This
provides the functionality to enable translations to occur on a specific source and destination
basis. The policy NAT is configured with the access control lists and will be discussed in
greater detail in Chapter 7, “Configuring Access.”
PAT
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.
Figure 5-5 PAT
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
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 Security Appliance to identify addresses that are not to be
translated. The nat 0 command is commonly called the “no nat” command.
! ""
" #
"
$ "" #$
%
" & &
122 Chapter 5: Understanding Cisco Security Appliance Translation and Connection
PIX Firewall OS Version 6.3(2) incorporated the ability to configure a policy NAT. This
provides the functionality to enable translations to occur on a specific source and destination
basis. The policy NAT is configured with the access control lists and will be discussed in
greater detail in Chapter 7, “Configuring Access.”
PAT
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.
Figure 5-5 PAT
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
NAT
NAT
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 Security Appliance, 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.
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 Security Appliance, 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.
Translation Commands
Translation Commands
Table 5-2 describes the commands and arguments used to configure NAT, PAT, and static
translation on a Cisco Security Appliance. All the Security Appliance commands are covered
in much greater detail in Chapter 6. Table 5-2 helps you understand the syntax of the
commands given in the following examples.
Table 5-2 describes the commands and arguments used to configure NAT, PAT, and static
translation on a Cisco Security Appliance. All the Security Appliance commands are covered
in much greater detail in Chapter 6. Table 5-2 helps you understand the syntax of the
commands given in the following examples.
Static translation
■ 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.
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.
Dynamic address translation
■ 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.
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.
Address Translation
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-toone
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
Security Appliance:
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-toone
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
Security Appliance:
A Cisco Security Appliance handles UDP traffic in the following manner:
A Cisco Security Appliance handles UDP traffic in the following manner:
1. The source machine initiates the UDP connection. It is received by the Security Appliance
en route to the destination. The Security Appliance 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.
1. The source machine initiates the UDP connection. It is received by the Security Appliance
en route to the destination. The Security Appliance 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.
Encapsulation of Upper-Layer Data
Encapsulation of Upper-Layer Data
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.
Application Data
Data
Data
Data Transport Header
Transport Header Logical
Data Addressing
Transport Header Logical
Addressing
Physical Addressing
Data Error Checking
Transport Header Logical
Addressing
Physical Addressing
Data Error Checking
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.
Figure 5-2 TCP Communication Between Nodes Without a PIX Firewall
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.
Application Data
Data
Data
Data Transport Header
Transport Header Logical
Data Addressing
Transport Header Logical
Addressing
Physical Addressing
Data Error Checking
Transport Header Logical
Addressing
Physical Addressing
Data Error Checking
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.
Figure 5-2 TCP Communication Between Nodes Without a PIX Firewall
Transport Protocols
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
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
Interface Security Levels and the Default Security Policy
Interface Security Levels and the Default Security Policy
By default, a Cisco Security Appliance 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).
By default, a Cisco Security Appliance 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).
How the Cisco Security Appliance Handles Traffic
How the Cisco Security Appliance 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 Security Appliance.
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 Security Appliance.
Subscribe to:
Posts (Atom)