Standard IP access control lists use the source IP addresses for matching operations. The configuration command takes the following syntax:

access-list access-list-number {deny | permit} source [source-wildcard] [log]

In Example 10-1, a standard ACL is created and applied to the incoming Internet traffic interface. The ACL denies all inbound traffic from the Internet that contains a source address from known reserved RFC addresses and permits any other traffic from the Internet to the corporate campus. Only the invalid traffic is logged, because there should be minimal logging unless a potential attack is in progress. It is also good practice to precede any access list configuration with the no access-list access-list-number command to clear out any previously defined commands.

! clear out any previously defined list
no access-list 9
! source addresses from reserved address space defined in RFC 1918
access-list 9 deny  127.0.0.0 0.255.255.255 log
access-list 9 deny  10.0.0.0 0.255.255.255 log
access-list 9 deny  172.16.0.0 0.15.255.255 log
access-list 9 deny  192.168.0.0 0.0.255.255 log
access-list 9 permit any
! apply  access-list 9 to the incoming Internet interface
interface Serial 0/0
description to the Internet
ip address 161.71.73.33 255.255.255.248
ip access-list 9 in

Figure 10-3 shows the algorithm used to process a standard ACL. As a packet reaches an interface, a process occurs to determine whether an access list should be checked. If the answer is no, the packet is forwarded for processing. If the answer is yes, the list is sequentially checked to determine whether there is a source address match. When there is a match, the appropriate condition is applied (to drop the packet and send an Internet Control Message Protocol [ICMP] unreachable message or to forward the packet). The last entry of an ACL is always an implicit deny all.

Figure 10-3. Processing of a Standard Access List

Extended IP ACLs provide finer granularity of control for the type of traffic that is permitted or denied. They use a combination of source and destination IP addresses and optional protocol-type information for matching operations.

The following command defines an extended IP ACL number and its access conditions:

access-list access-list-number {deny | permit} protocol source source-wildcard
destination destination-wildcard [operator] [operand][precedence precedence]
[tos tos] [established] [log | log-input]

For IP extended ACLs, you can define a number of well-known protocols:

Router(config)#access-list 101 permit ?
<0-255>    An IP protocol number
eigrp      Cisco's Enhanced IGRP routing protocol
gre        Cisco's GRE tunneling
icmp       Internet Control Message Protocol
igmp       Internet Gateway Message Protocol
igrp       Cisco's IGRP routing protocol
ip         Any Internet protocol
ipinip     IP in IP tunneling
nos        KA9Q NOS-compatible IP over IP tunneling
ospf       OSPF routing protocol
tcp        Transmission Control Protocol
udp        User Datagram Protocol

The most common protocols to filter are the TCP and UDP protocols. For the TCP protocol, you can filter on the following parameters (operators):

Router(config)#access-list 101 permit tcp any any ?
eq             Match only packets on a given port number established
established    Match established connections
gt             Match only packets with a greater port number
log            Log matches against this entry
lt             Match only packets with a lower port number
neq            Match only packets not on a given port number
precedence     Match packets with a given precedence value
range          Match only packets in the given range of port numbers
tos            Match packets with the given TOS value

Here is a list of the more commonly used TCP port numbers (operands):

Router(config)#access-list 101 permit tcp any any eq ?
<0-65535>  Port number
bgp        Border Gateway Protocol (179)
chargen    Character generator (19)
cmd        Remote commands (rcmd, 514)
daytime    Daytime (13)
discard    Discard (9)
domain     Domain Name Service (53)
echo       Echo (7)
exec       Exec (rsh, 512)
finger     Finger (79)
ftp        File Transfer Protocol (21)
ftp-data   FTP data connections (used infrequently, 20)
gopher     Gopher (70)
hostname   NIC hostname server (101)
ident      Ident Protocol (113)
irc        Internet Relay Chat (194)
klogin     Kerberos login (543)
kshell     Kerberos shell (544)
login      Login (rlogin, 513)
lpd        Printer service (515)
nntp       Network News Transport Protocol (119)
pop2       Post Office Protocol v2 (109)
pop3       Post Office Protocol v3 (110)
smtp       Simple Mail Transport Protocol (25)
sunrpc     Sun Remote Procedure Call (111)
syslog     Syslog (514)
tacacs     TAC Access Control System (49)
talk       Talk (517)
telnet     Telnet (23)
time       Time (37)
uucp       UNIX-to-UNIX Copy Program (540)
whois      Nicname (43)
www        World Wide Web (HTTP, 80)

For UDP, here is a list of the more commonly used port numbers:

Router(config)#access-list 101 permit udp any any eq ?
<0-65535>      Port number
biff           Biff (mail notification, comsat, 512)
bootpc         Bootstrap Protocol (BOOTP) client (68)
bootps         Bootstrap Protocol (BOOTP) server (67)
discard        Discard (9)
dnsix          DNSIX security protocol auditing (195)
domain         Domain Name Service (DNS, 53)
echo           Echo (7)
mobile-ip      Mobile IP registration (434)
nameserver     IEN116 name service (obsolete, 42)
netbios-dgm    NetBios datagram service (138)
netbios-ns     NetBios name service (137)
ntp            Network Time Protocol (123)
rip            Routing Information Protocol (router, in.routed, 520)
snmp           Simple Network Management Protocol (161)
snmptrap       SNMP Traps (162)
sunrpc         Sun Remote Procedure Call (111)
syslog         System Logger (514)
tacacs         TAC Access Control System (49)
talk           Talk (517)
tftp           Trivial File Transfer Protocol (69)
time           Time (37)
who            Who service (rwho, 513)
xdmcp          X Display Manager Control Protocol (177)

Keep in mind the following few things when configuring ACLs on Cisco IOS devices:

Figure 10-4 shows the algorithm used for an IP extended ACL.

Figure 10-4. Processing of an IP Extended Access List

Example 10-2 shows the configuration commands of an extended IP ACL. It meets the following criteria:

! start with clearing out any previously established list
no access list 101
! create the access list
access-list 101 permit tcp any any established
access-list 101 permit tcp any host 144.254.1.4 eq ftp
access-list 101 permit tcp any host 144.254.1.4 eq ftp-data
access-list 101 permit tcp any host 144.254.1.3 eq www
access-list 101 deny ip any any log-input

! configure the Internet interface and apply the inbound access-list 101

interface Serial 0/0
description to the Internet
ip address 161.71.73.33 255.255.255.248
ip access-group 101 in

The order in which you create your ACL entries is important in Cisco IOS devices. When the router is deciding whether to forward or block a packet, the Cisco IOS Software tests the packet against each criteria statement in the order the statements were created. After a match is found, no more criteria statements are checked. From a performance standpoint, if you have the need for very long lists (for example, more than 100 entries), you should place the more common scenarios at the beginning of the list. If most of your incoming traffic is web related, for instance, you should place the criteria for web traffic at the top of the list. The other ordering criteria for statements is to go from the specific to the general. You need to be careful about reordering statements if the granularity differs for newer entries.

Turbo ACLs were introduced in Cisco IOS Software Release 12.1(6). A Turbo ACL is configured with the access-list compiled command. It is a technique that takes a standard or extended ACL, creates a set of data tables, and compiles them into fast lookup tables. The matching semantics are preserved while reducing the number of CPU operations to find a match. This allows for very large filter lists to be used without an increase in packet latency. The processing of Turbo ACLs takes a maximum of five steps, no matter what the size of the filter. This feature proves useful if you have filters that contain a large number of entries. (I recommend using it if you exceed 20 entries on any ACL.)

Named ACLs were introduced in Cisco IOS Software Release 11.0. You can identify IP ACLs with an alphanumeric string (a name) rather than a number (1 to 199). Named ACLs enable you to configure more than 99 standard IP (and 100 extended IP) ACLs in a router. Currently, only packet and route filters can use a named list.

The advantage of using a named ACL is that you can selectively remove entries. However, you still cannot selectively add ACL command lines to a specific ACL—subsequent additions are still placed at the end of the list.

Consider the following before configuring named ACLs:

An example of a named ACL is shown in the next section. (Reflexive ACLs require the use of extended named ACLs.)

Reflexive ACLs were introduced in Cisco IOS Software Release 11.3. They allow IP packets to be filtered based on upper-layer session information.

A common requirement for filtering is to permit IP traffic for sessions originating from within your network but to deny IP traffic for sessions originating from outside your network. Using basic extended ACLs, you can approximate session filtering by using the established keyword with the permit command. The established keyword filters TCP packets based on whether the ACK or RST bits are set. This method of using the established keyword is available only for the TCP upper-layer protocol. For the other upper-layer protocols (such as UDP, ICMP, and so forth), you have to either permit all incoming traffic or define all possible permissible source/destination host/port address pairs for each protocol.

Reflexive ACLs are much more suitable for true session filtering. After it has been configured, a reflexive ACL is triggered when a new IP upper-layer session (such as TCP or UDP) is initiated from inside your network, with a packet traveling to the external network. When triggered, the reflexive ACL generates a new, temporary entry. This entry permits traffic to enter your network if the traffic is part of the session, but does not permit traffic to enter your network if the traffic is not part of the session. The filter criterion is based on the ACK and RST bits as well as the source and destination addresses and port numbers. Session filtering uses temporary filters that are removed when a session is over, limiting the hacker's attack opportunity to a smaller time frame.

Temporary reflexive ACL entries are removed at the end of the session. For TCP sessions, the entry is removed 5 seconds after two set FIN bits are detected, or immediately after matching a TCP packet with the RST bit set. (Two set FIN bits in a session indicate that the session is about to end; the 5-second window allows the session to close gracefully. A set RST bit indicates an abrupt session close.) Alternatively, the temporary entry is removed after no packets of the session have been detected for a configurable length of time (called the timeout period).

For UDP and other protocols, the end of the session is determined differently than it is for TCP. Because other protocols are considered to be connectionless (sessionless) services, they have no session-tracking information embedded in their packets. Therefore, the end of a session is considered to be when no packets of the session have been detected for a configurable length of time (the timeout period).

Two restrictions apply to using the reflexive ACL feature:

The TCP-based application FTP is an example of an application with changing port numbers. With reflexive ACLs, if you start an FTP request from within your network, the request will not complete. Instead, you must use passive FTP when originating requests from within your network.

Figure 10-5 shows an example of how to use reflexive ACLs. Notice that the Ethernet interface connects to the internal corporate networks, and that the serial interface connects to the Internet. The configuration example permits both inbound and outbound TCP traffic on the serial interface—but only if the first packet in a given session originated from inside your corporate network.

Figure 10-5. Reflexive Access Lists

Example 10-3 shows the configuration commands for a reflexive ACL.

! Define the global idle timeout value for all reflexive access lists.
! If for 120 seconds there is no TCP traffic that is part of an
! established session, the corresponding reflexive access list
! entry will be removed.

ip reflexive-list timeout 120

! Define the outbound access list. This is the access list that
! evaluates all outbound traffic on interface Serial 1.

ip access-list extended outboundfilters
remark permit all outbound TCP traffic

! Define the reflexive access list tcptraffic. This entry permits all
! outbound TCP traffic and creates a new access list named tcptraffic.

permit tcp any any reflect tcptraffic

! Define the inbound access list. This is the access list
! that evaluates all inbound traffic on interface Serial 1.

ip access-list extended inboundfilters
remark permit routing but deny ICMP and check all TCP traffic

! Define the inbound access list entries. Permit BGP and EIGRP
! but deny ICMP. The last entry points to the reflexive access list.
! If a packet does not match the first three entries, the packet will
! be evaluated against all the entries in the reflexive access list
! named tcptraffic.

 permit bgp any any
 permit eigrp any any
 deny icmp any any
 evaluate tcptraffic

! Define the interface where the session-filtering configuration is
! to be applied and apply access lists to the interface, for inbound
! traffic and for outbound traffic.
interface Serial 1
 description Access to the Internet
 ip access-group inboundfilters in
 ip access-group outboundfilters out

For IP traffic using the TCP protocol, advanced packet session filtering inspects all IP and TCP headers in every packet based on a combination of the following fields:

These fields allow the monitoring of connection state information and provide a reasonable amount of certainty about when valid connections are in progress.

For IP traffic using the UDP protocol, advanced packet session filtering inspects all IP and UDP headers in every packet based on a combination of the following fields:

Because UDP is a connectionless service, there are no actual UDP “sessions” per se. Most systems approximate sessions by examining UDP packet information and determining whether the packet is similar to other UDP packets recently seen.

The World Wide Web has played a large role in making the Internet a place to conduct business. Chapter 2, “Security Technologies,” described technologies such as S-HTTP and SSL that enable you to secure web transactions. However, program languages, such as Java and JavaScript, that are used to write interactive programs for web applications remain a security issue. Some corporations also want to restrict specific URL sites from their employees because of the sites' possibly illegal content.

When World Wide Web users download a web page with embedded Java or JavaScript programs (called applets), there is no control over whether the applet has approved content or whether it contains a virus or malicious program. You must prevent users from inadvertently downloading destructive Java applets into your network. To protect against this risk, you could require all users to disable Java in their browser. If this is not an agreeable solution, you can use methods to filter Java applets at the firewall, allowing users to download only those applets residing within the firewall and trusted applets from outside the firewall.

The question of whether to use private addressing is becoming a part of network design for many corporate TCP/IP application users. The Internet has grown beyond anyone's expectations. With this growth came concerns about Internet address depletion and, more importantly, address-allocation procedures and their impact on the Internet routing system. There are a few reasons why private address space could and should be used (such as for environments where external connectivity may not be required or is extremely limited). Some examples include the following:

The cost of using private Internet address space is the potentially costly effort to renumber hosts and networks between public and private. If the company has any thought about opening up to global Internet access, it is recommended that the corporation start a transition plan for renumbering to a globally unique address if it is currently using private address space. The widespread use of Dynamic Host Configuration Protocol (DHCP) is making this process much easier and may help avoid possible future issues with non-NAT-able and non-proxy-able protocols.

If you decide to use private address space, however, you don't have to coordinate with IANA or an Internet registry. Addresses within this private address space are unique only within your network.

To use private address space, determine which hosts do not need to have network layer connectivity to the outside. These hosts are private hosts and will use private address space. Private hosts can communicate with all other hosts within the corporate network, both public and private, assuming that all addressing within the corporate network is unique. However, the private hosts cannot have IP connectivity to any host external to the corporate network without the use of NAT or proxies.

All public hosts use the globally unique address space assigned by an Internet registry. Public hosts can communicate with other hosts within the network and can have IP connectivity to external public hosts. Figure 10-10 shows the differences between public and private address spaces (assuming that NAT is not being used).

Because private addresses have no global meaning, routing information about private networks is not propagated on outside links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks that don't use private address space—especially those of Internet service providers—should be configured to reject (filter out) routing information about private networks.

With this scheme, many large networks need only a relatively small block of addresses from the globally unique IP address space. The Internet at large benefits through conservation of globally unique address space, and the corporate networks benefit from the increased flexibility provided by a relatively large private address space.

In its simplest configuration, NAT is performed in both directions on only one end of the communication and operates on the router or firewall connecting the inside corporate network to the outside Internet, as shown in Figure 10-11.

Figure 10-11. NAT on a Router or Firewall

The inside corporate network is addressed with private addresses that must be converted into legal addresses before packets can be forwarded to the outside Internet.

NAT functionality can become quite complex, depending on the applications it has to support. Here are some of the functionalities you should consider when opting for NAT for Internet access:

When using NAT, you should always ensure that all corporate applications that require Internet access are supported through the firewall. Typically, the following protocols and applications are supported:

Advanced packet session filtering in Cisco IOS Software is supported as of Release 11.2 with the CBAC feature. By default, Cisco routers pass all routable traffic between all router interfaces.

CBAC not only examines network layer and transport layer information, it also examines the application layer protocol information (such as FTP connection information) to learn about the state of the TCP or UDP session. In this way, CBAC allows support of protocols that involve multiple channels created as a result of negotiations in the control channel. Most of the multimedia protocols—and some other protocols (such as FTP, remote-procedure call [RPC], and SQL*Net)—involve multiple channels.

CBAC inspects traffic that travels through the firewall to discover and manage state information for TCP and UDP sessions. This state information is used to create temporary openings in the firewall's ACLs to allow return traffic and additional data connections for permissible sessions (sessions that originated from within the protected internal network).

In many cases, you will configure CBAC in one direction only at a single interface. This arrangement causes traffic to be permitted back into the internal network only if the traffic is part of a permissible (valid, existing) session.

To define a set of inspection rules, use the ip inspect name global configuration command:

ip inspect name inspection-name protocol [timeout seconds]

You can configure CBAC to inspect the following types of transport and application layer protocols:

When a protocol is configured for CBAC, the protocol's traffic is inspected, state information is maintained, and, in general, packets are allowed back through the firewall only if they belong to a permissible session.

access-list access-list-number {deny | permit} source [source-wildcard]
ip inspect name inspection-name http [java-list access-list] [timeout seconds]

CBAC does not provide intelligent filtering for all protocols; it works only for the protocols you specify. If you don't specify a certain protocol for CBAC, the existing ACLs determine how that protocol is filtered. No temporary openings are created for protocols that have not been specified for CBAC inspection.

CBAC also has mechanisms that can protect against denial-of-service (DoS) attacks. A number of commands control timeout and threshold values to manage session state information and help determine when to drop sessions that do not become fully established. Table 10-3 lists the configurable parameters and their associated default values.

In some instances, it may be necessary to modify the default values, but that will depend on what speeds your links are and how conservative you want to be.

There is also a command you can use to protect a specific host and set a maximum threshold for half-open TCP sessions. This can protect critical web servers explicitly. The command is as follows:

ip inspect max-incomplete host number block-time minutes

The default values are 50 half-open sessions and 0 minutes.

You can also address fragmentation attacks using CBAC by using the following command:

ip inspect name inspect-name fragment [max number timeout seconds]

Without this command, the first packet fragment is verified against any application layer CBAC checks, but any subsequent fragment can only be checked for IP layer information. When the fragment CBAC functionality is enabled, the Cisco IOS firewall maintains state information and checks the fragment sequence number, Offset field, and length to ensure that it is a valid fragment. The amount of memory dedicated to maintain the fragment state is limited by the max parameter to reduce the router becoming a victim of a potential DoS attack. To override the global timeouts for the specified protocol, specify the number of seconds for a different idle timeout.

Example 10-4 shows a sample firewall configuration that implements the following policy:

! Ensure all vty login, line, and username passwords are encrypted
! with minimal encryption (7) unless configured as a secret
! that uses MD5 encryption.

service password-encryption

! Disable access to minor TCP services such as echo,
! chargen, discard, and daytime.

no service udp-small-servers

! Disable access to minor UDP services such as echo,
! chargen, and discard.

no service tcp-small-servers

hostname imafirewall

! The enable secret

enable secret 5 $1$dLOD$QR.onv68q3326pzM.Zexj1

! Disable other unnecessary services.

no service finger
no service pad

no ip bootp server

! Set local database authentication.

username security_geeks  password 7 082C495C0012001E010F02

! Allow for subnet zero networks

ip subnet-zero

! Don't need source routing.

no ip source-route

! The following commands define the inspection rule "primaryfw",
! allowing the specified protocols to be inspected. Note that Java
! applets will be permitted according to access list 66, defined later
! in this configuration.

ip inspect name primaryfw cuseeme timeout 3600
ip inspect name primaryfw ftp timeout 3600
ip inspect name primaryfw http java-list 66 timeout 3600
ip inspect name primaryfw rcmd timeout 3600
ip inspect name primaryfw realaudio timeout 3600
ip inspect name primaryfw smtp timeout 3600
ip inspect name primaryfw tftp timeout 30
ip inspect name primaryfw udp timeout 15
ip inspect name primaryfw tcp timeout 3600

! The following interface configuration applies the "primaryfw"
! inspection rule to inbound traffic at Ethernet 0. Since this interface
! is connected to the internal corporate network side of the firewall,
! traffic entering Ethernet 0 is actually exiting the trusted internal
! network. Applying the inspection rule to this interface causes all
! traffic going from the corporate network to the
! Internet to be inspected; return traffic will only be
! permitted back through the firewall if it is part of a session that
! began from within the corporate network. Also note that access list
! 101 is applied to inbound traffic at Ethernet 0. Any traffic that
! passes the access list will be inspected by CBAC. (Traffic blocked by
! the access list will not be inspected.)
!
! Access list 108 prevents spoofing by allowing only the traffic destined to
! the corporate network to go out the Ethernet 0 interface.
interface Ethernet0
 description To Corporate Network
 ip address 144.254.1.1 255.255.255.0
 no ip directed-broadcast
 no ip proxy-arp
 ip inspect primaryfw in
 ip access-group 101 in
 ip access-group 108 out
 no ip route-cache
 no cdp enable

interface Ethernet 1
description DMZ for ftp and www servers
ip address 144.254.2.1 255.255.255.0
no ip directed broadcast
ip access-group 102 in
no ip route-cache
no cdp enable

interface Serial0
 description Frame Relay to Internet
 no ip address
 ip broadcast-address 0.0.0.0
 encapsulation frame-relay IETF
 no ip route-cache
 no arp frame-relay
 bandwidth 56
 service-module 56k clock source line
 service-module 56k network-type dds
 frame-relay lmi-type ansi

! Note that the following interface configuration applies access list
! 111 to inbound traffic at the external serial interface. (Inbound
! traffic is entering the network.) When CBAC inspection occurs on
! traffic exiting the network, temporary openings will be added to
! access list 111 to allow returning traffic that is part of existing
! sessions.

interface Serial0.1 point-to-point
 ip unnumbered Ethernet0
 ip access-group 111 in
 no ip route-cache
 bandwidth 56
 no cdp enable
 frame-relay interface-dlci 16

! set up default route.

ip classless
ip route 0.0.0.0 0.0.0.0 Serial0.1

! Filter such that only devices on this network have SNMP access.

access-list 6 permit 144.254.9.0 0.0.0.255



! The following access list defines "friendly" and "hostile" sites for
! Java applet blocking. Because Java applet blocking is defined in the
! inspection rule "primaryfw" and references access list 66, applets
! will be actively denied if they are from any of the "deny" addresses
! and allowed only if they are from either of the two "permit" networks.

access-list 66 deny   172.19.1.203
access-list 66 deny   172.19.2.147
access-list 66 permit 172.18.0.0 0.1.255.255
access-list 66 permit 192.168.1.0 0.0.0.255
access-list 66 deny   any

! The following access list 101 is applied to interface Ethernet 0
! above. This access list permits all traffic that should be CBAC
! inspected, and also provides antispoofing. The access list is
! deliberately set up to deny unknown IP protocols because no such
! unknown protocols will be in legitimate use.

access-list 101 permit tcp 144.254.0.0 0.0.255.255 any
access-list 101 permit udp 144.254.0.0 0.0.255.255 any
access-list 101 permit icmp 144.254.0.0 0.0.255.255 any
access-list 101 deny   ip any any

! Anti-spoof filters for my own network address

access-list 102 permit ip 144.254.2.0 0.0.0.255 any
access-list 108 permit ip any 144.254.0.0 0.0.255.255

! The following access list 111 is applied to interface Serial 0.1
! above. This access list filters traffic coming in from the external
! Internet side. When CBAC inspection occurs, temporary openings will be
! added to the beginning of this access list to allow return traffic
! back into the internal network. This access list should restrict
! traffic that will be inspected by CBAC.

! Antispoofing filters rfc1918 and my own network address

access-list 111 deny ip 127.0.0.0.0 0.255.255.255 any
access-list 111 deny ip 10.0.0.0 0.255.255.255 any
access-list 111 deny ip 172.16.0.0 0.15.255.255 any
access-list 111 deny ip 192.168.0.0 0.0.255.255 any
access-list 111 deny ip 144.254.0.0 0.0.255.255 any

! Allow Internet traffic for ftp, ftp-data and www to ftp server
! and www server on dmz.

access-list 111 permit ip any host 144.254.2.2   eq ftp
access-list 111 permit ip any host 144.254.2.2  eq ftp-data
access-list 111 permit ip any host 144.254.2.3  eq http

! Port 22 is used for SSH, i.e.encrypted, RSA-authenticated remote login. Can be
! used to securely access specified corporate host(s) from the Internet.

access-list 111 permit tcp any  144.254.9.0 0.0.0.255 eq 22

! Sometimes Enhanced IGRP is run on the Internet link. When you use
! an input access list, you have to explicitly allow control
! traffic. This could be more restrictive, but there would have to be
! entries for the Enhanced IGRP multicast as well as for the corporation's
! own unicast address.

access-list 111 permit eigrp any any

! These are the ICMP types actually used...
! administratively-prohibited is useful when you're trying to figure out
! why you can't reach something you think you should be able to reach.

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 administratively-prohibited

! This allows network admins who may be traveling or otherwise coming
! in through the Internet to ping hosts at the corporate
! office.

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 echo

! This allows outgoing pings

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 echo-reply

! Path MTU discovery requires too-big messages

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 packet-too-big

! Outgoing traceroute requires time-exceeded messages to come back

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 time-exceeded

! Incoming traceroute

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 traceroute

! Permits all unreachables because if you are trying to debug
! things from the corporate network, you want to see them.
! If no debugging was ever done from the network, it would be more
! appropriate to permit only port unreachables or no unreachables at
! all.

access-list 111 permit icmp any 144.254.0.0 0.0.255.255 unreachable


! Final deny all which logs all access list violations via syslog

access-list 111 deny ip any any log


no cdp run
snmp-server community public RO 6

! device access controls

line con 0
  exec-timeout 2 30
  login authentication security_geeks
line aux 0
  no exec
  transport input none
line vty 0 4
  exec-timeout 2 30
  login authentication security_geeks

! Logging commands
service timestamps log datetime localtime show-timezone

logging on
logging 144.254.5.5
logging console information

In many corporate environments, internal users are allowed access to all Internet resources, but traffic coming in from the Internet undergoes closer scrutiny. If your security policy requires that outside users access inside hosts and servers, use the static command to specify which IP addresses are visible on the outside interfaces. The command creates a permanent mapping (sometimes referred to as a translation slot or xlate) between a local IP address and a global IP address.

The static command must be followed by the conduit command (or access-list command in newer software versions) to specify which services outside users can access on the internal servers. These commands take the following form:

static [(internal_if_name, external_if_name)] global_ip local_ip
  [netmask network_mask] [max_conns [em_limit]] [norandomseq]

conduit permit|deny protocol global_ip global_mask [operator port [port]]
 foreign_ip foreign_mask [operator port [port]]

Together, a static and conduit (or access-list) statement pair create an exception to the PIX firewall adaptive security mechanism by permitting connections from one firewall network interface to access hosts on another.

The conduit command is being phased out in favor of the access-list command, which can take the following form:

access-list acl-ID permit|deny protocol {source_addr | local_addr}
    {source_mask | local_mask} [operator port [port]]
    {destination_addr | remote_addr} {destination_mask | remote_mask}
    [operator port [port]]

It is very similar to the Cisco IOS access-list command with one extremely important exception. The netmask is defined in the opposite way. For Cisco IOS ACLs, the netmask is represented by using 0s to represent the network number and 1s to represent the host number. For PIX firewall ACLs, the netmask is represented by what's referred to as the natural mask, where 1s are used to represent the network number and 0s are used to represent the host number. The following example shows the difference:

With the access-list command, greater functionality will be introduced in future PIX products; it would, therefore, be wise for you to convert to using them now. If you have more than 19 access list entries, you can use the command access-list compiled to more efficiently process ACLs. Note that this command is supported only for PIX firewall platforms that have 16 MB of Flash memory.

Outbound access control is accomplished using ACLs. The ACLs are created with the outbound command and are based on the following information:

An outbound command requires the use of the apply command. The apply command enables you to specify whether the ACL applies to inside users' ability to start outbound connections with the apply command's outgoing_src option, or whether the ACL applies to inside users' ability to access servers on the outside network with the apply command's outgoing_dest option.

The commands take the following form:

outbound list_ID permit|deny ip_address [netmask [java|port[-port]]] [protocol]
outbound list_ID except ip_address [netmask [java|port[-port]]] [protocol]
apply [(if_name)] list_ID outgoing_src|outgoing_dest

The outbound controls are typically used for the following situations:

Example 10-6 shows a configuration that permits only outbound HTTP traffic from a specified source address.

outbound 1 deny   0.0.0.0       0.0.0.0     0    tcp
outbound 1 except 192.168.0.2  255.255.255.255   http
apply (inside)   1   outgoing_src

Whenever you permit outside users access to your network, you should establish a user authentication and authorization system. The PIX has a feature called Cut-Thru-Proxy that enables authentication based on FTP, HTTP, or Telnet traffic and subsequent authorization for any allowed application traffic. The example in Figure 10-13 shows the use of this feature.

Figure 10-13. The PIX Cut-Thru Proxy Feature (FTP and HTTP)

In the figure, any outbound FTP or HTTP traffic must be successfully authenticated before the connection is established, as illustrated in Example 10-7.

aaa authentication ftp, http inbound 0.0.0.0 0.0.0.0 tacacs+
aaa authorization ftp, http inbound 0.0.0.0 0.0.0.0
tacacs-server host 144.254.5.9 sharedsecret

When an outside user tries to access the corporate FTP server, the following sequence of steps occur:

Example 10-8 shows a corresponding sample user profile on the TACACS+ server that authorizes an authenticated user to use FTP on 144.254.1.4 and HTTP on 144.254.1.3.

{
Profile_cycle = 11
Profile_id = 8
Password = clear "abcd"
Set Server current failed_login = 0
Service = Shell {
cmd = ftp {
permit 144.254.1.4
}
cmd = http {
permit 144.254.1.3
}
}
}

The PIX firewall has numerous advanced features, including the following:

It is beyond the scope of this book to describe the PIX firewall functionality in detail, and only a brief introduction has been offered to familiarize the reader with the most basic commands. The book Cisco Secure PIX Firewalls (Cisco Press, 2001), by David W. Chapman, Jr. and Andy Fox, provides a comprehensive description of the PIX firewall. Chapter 12 in this book describes VPN scenarios and shows configuration examples using IPsec that also include the PIX firewall.

In this scenario, the Cisco IOS router is used as the screening router to provide basic filtering of traffic coming from the Internet. The PIX firewall provides the more robust firewall features, as shown in Figure 10-14.

Figure 10-14. Sample Cisco PIX Firewall with Cisco IOS Screening Router

The sample configurations in Examples 10-9 and 10-10 depict the implementation of the following Internet access security policy:

! Ensure all vty login, line, and username passwords are encrypted
! with minimal encryption (7) unless configured as a secret
! that uses MD5 encryption.

service password-encryption

! Disable access to minor TCP services such as echo,
! chargen, discard, and daytime.

no service udp-small-servers

! Disable access to minor UDP services such as echo,
! chargen, and discard.

no service tcp-small-servers

hostname screen

enable secret 5 $1$dLOD$QR.onv68q3326pzM.Zexj1
no service finger
no service pad
no ip bootp server

no ip source-route

! Configure TACACS+ authentication as default - for users logging in as
! staff, there is a local database authentication in the event that the
! TACACS+ server is unavailable.

aaa new-model
aaa authentication login default tacacs+
aaa authentication login staff tacacs+ local
aaa authorization exec tacacs+  local

! Interim accounting records will be sent every time there is
! new information to report
! accounting for all exec terminal sessions.

aaa accounting update newinfo
aaa accounting exec start-stop tacacs+

! Set local database authentication.

username staff password 7 082C495C0012001E010F02

! Configure the interfaces.

interface Serial 0/0
description to the Internet
ip address 161.71.73.33 255.255.255.248
ip access-group 109 in

interface Ethernet1/0

 description To Corporate Network
 ip address 192.150.50.1 255.255.255.0
 no ip directed-broadcast
 no ip proxy-arp
 ip access-group 108 in
 no ip route-cache
 no cdp enable

! Antispoof filter for internal network

access-list 108 permit ip  192.150.50.0  0.0.0.255 any

! Antispoof filters for rfc1918 addresses.

access-list 109 deny ip 127.0.0.0 0.255.255.255 any
access-list 109 deny ip 10.0.0.0 0.255.255.255 any
access-list 109 deny ip 172.16.0.0 0.15.255.255 any
access-list 109 deny ip 192.168.0.0 0.0.255.255 any

! Allow any tcp traffic that has been established from the corporate network.

access-list 109 permit tcp any any established

! allow Internet traffic for ftp and ftp-data only from network 144.254.0.0

access-list 109 permit tcp 144.254.0.0 0.0.255.255  host 192.150.50.8  eq ftp
access-list 109 permit tcp 144.254.0.0 0.0.255.255  host 192.150.50.8  eq ftp-data

! Allow Internet traffic for smtp and www server to specific servers.

access-list 109 permit tcp any host 192.150.50.9  eq http
access-list 109 permit tcp any host 192.150.50.7  eq smtp

! Sometimes Enhanced IGRP is run on the Internet link. When you use
! an input access list, you have to explicitly allow control
! traffic. This could be more restrictive, but there would have to be
! entries for the Enhanced IGRP multicast as well as for the corporation's
! own unicast address.

access-list 109 permit eigrp any any

! These are the ICMP types actually used...
! administratively-prohibited is useful when you're trying to figure out
! why you can't reach something you think you should be able to reach.

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 administratively-prohibited

! This allows network admins who may be traveling or otherwise coming
! in through the Internet to ping hosts at the corporate
! office:

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 echo

! This allows outgoing pings.

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 echo-reply

! Path MTU discovery requires too-big messages.

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 packet-too-big

! Outgoing traceroute requires time-exceeded messages to come back.

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 time-exceeded

! Incoming traceroute

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 traceroute

! Permits all unreachables because if you are trying to debug
! things from the corporate network, you want to see them.
! If no debugging was ever done from the network, it would be more
! appropriate to permit only port unreachables or no unreachables at
! all.

access-list 109 permit icmp any 192.150.50.0 0.0.0.255 unreachable

! Final deny all which logs all access list violations via syslog

access-list 109 deny ip any any log

no cdp run

! configure tacacs+ parameters

tacacs-server host 192.150.50.10
tacacs-server key thisisakey

! configure device access.

line con 0
  exec-timeout 2 30
  login authentication staff

line aux 0
  no exec
  transport input none

line vty 0 4
  exec-timeout 2 30
  login authentication default

! Configure logging.
service timestamps log datetime localtime show-timezone

logging on
logging 192.150.50.11
logging console information

! Sets the security levels for each interface, specifies that each
! interface uses Ethernet, and assigns IP addresses and network
! masks.

nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto

ip address outside 192.150.50.3 255.255.255.255
ip address inside 10.0.0.1 255.255.255.0
ip address dmz 192.168.0.1 255.255.255.0

! Specifies the host name for the PIX firewall.

hostname pixfirewall

! Define enable password and Telnet password.

enable password BjeuCKspwqCc94Ss encrypted
passwd nU3DFZzS7jF1jYc5 encrypted


! The following performs defined protocol security checks.

fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol smtp 25
fixup protocol sqlnet 1521
!
! Enables use of text strings instead of IP addresses. This makes your
! configuration files more readable.

names

! Enables paging so that if 24 lines of information
! display, PIX firewall pauses the listing and prompts you
! to continue.

pager lines 24

! The logging host command specifies which host runs a syslog server.
! This command also causes the PIX firewall to start sending syslog
! messages to that host. The logging trap command sets syslog to send
! all possible messages to the syslog host. The no logging console
! command disables displaying messages to the console.

logging on
logging host 10.0.1.100
logging trap 7
logging facility 20
no logging console

! Sets the ARP timeout to 14,400 seconds (four hours).
! Entries are kept in the ARP table for four hours before
! they are flushed. Four hours is the standard default value
! for ARP timeouts.

arp timeout 14400

! Create a pool of addresses to be used with NAT.

global (outside) 1 192.150.50.15-192.150.50.250 netmask 255.255.255.0

! Enable IP communications between hosts on the 10.0.0.0 network and host on
! either the Internet or the 192.168.0.0 network. For communication to the
! Internet, the source IP address gets substituted with an address from the
! global pool.

nat (inside) 1 10.0.0.0 255.0.0.0 0 0

! Enables IP communications between hosts on the 192.168.0.0 network and
! the Internet. Any address starting with 192.168.0 will be substituted
! with an address from the global pool

nat (dmz) 1 192.168.0.0 255.255.255.0 0 0

! Define static translations for the FTP server, web server, SMTP server,
! TACACS+ server, and syslog server.

static (dmz, outside) 192.150.50.6 192.168.0.6 netmask 255.255.255.255 0 0
static (dmz, outside) 192.150.50.9 192.168.0.2 netmask 255.255.255.255 0 0
static (inside, outside) 192.150.50.7 10.0.1.99 netmask 255.255.255.255 0 0

static (inside, outside) 192.150.50.10 10.0.0.100 netmask 255.255.255.255 0 0
static (inside, outside) 192.150.50.11 10.0.6.50 netmask 255.255.255.255 0 0

! Allows packets from 10.0.0.0 network to go to the 192.168.0.0 network.

statix (inside, dmz) 10.0.0.0 192.168.0.0 netmask 255.0.0.0 0 0


! Enables www access to 192.168.0.2 - this command requires the static command
! above to know proper translated address.

conduit permit tcp host 192.150.50.9 eq www any

! Enables SMTP access to 10.0.1.99 - this command requires the static command
! above to know proper translated address.

conduit permit tcp host 192.150.50.7 eq smtp any

! Allow FTP access from hosts from 144.254.0.0 network.

conduit permit tcp host 192.150.50.6 eq ftp 144.254.0.0 255.255.0.0

! Sets RIP listening attributes. The three no rip interface passive lines
! cause the PIX firewall to not listen to RIP broadcasts on each interface.
! The no rip interface default lines causes PIX firewall to not
! broadcast a default route on any interface.

no rip inside passive
no rip outside passive
no rip dmz passive
no rip inside default
no rip outside default
no rip dmz default

! Sets the outside default route to the router attached to the Internet.

route outside 0.0.0.0 0.0.0.0 192.150.50.1 1

! Default values for the maximum duration that PIX firewall resources
! can remain idle until being freed. To improve system performance,
! you can set the xlate and conn timers from 24 hours to 1 hour.

timeout xlate 24:00:00 conn 12:00:00 udp 0:02:00
timeout rpc 0:10:00 h323 0:05:00 uauth 0:05:00

! Use WebSense server which has address 10.0.6.80 - all outbound URL requests are
! sent to the WebSense server.

url-server (inside) host 10.0.6.80 timeout 5
filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

! Authenticate FTP traffic via TACACS+.

tacacs--server host 10.0.6.50 thisisakey
aaa authentication ftp inbound 192.168.0.6 255.255.255.255 144.254.0.0 255.255.0.0

! Give Telnet access to PIX firewall console to inside hosts on 10.0.8.0 subnet.

telnet 10.0.8.0 255.255.255.0

! Sets the maximum transmission unit value for Ethernet access.

mtu outside 1500
mtu inside 1500
mtu dmz 1500