In the preceding chapter, you saw the mandatory configuration commands used to configure the zone-based policy firewall feature of Cisco IOS. In this chapter, we use those commands to develop a complete configuration of a firewall with a perimeter network shown in Figure 4-1. The policy rules used by this firewall are documented in Table 2-3 (Restrictive Policy of a Firewall with a Perimeter Network) of Chapter 2 “Typical Zone-Based Firewall Designs.”,
To include the perimeter network in the existing firewall configuration (Listing 3-1) discussed in Chapter 3, “Configuring Zone-Based Policy Firewalls in Cisco IOS,” we need to do the following:
Configure a separate interface to which the public web server will be connected. If you’re limited by the router’s physical setup (for example, if it has only one Fast Ethernet interface), the best approach is to create a subinterface in a different virtual LAN (VLAN).
Configure the IP subnet on the perimeter interface. We’ll use subnet 192.168.0.0/24 from the private IP address range.
Fix the network address translation configuration. We reduce the size of the IP address pool (to gain a public IP address for the web server) and establish a static inside-to-outside mapping for the web server.
Note
Using VLANs to connect interfaces in public and private zones on the same physical interface of a firewall should be done only as a last resort. Any misconfiguration of the switch to which these devices are attached could cause a security breach.
Listing 4-1 shows the corresponding router configuration.
Example 4-1. Changes in IP Routing Configuration of the Firewall Router
interface FastEthernet0/0.100 description public Web server encapsulation dot1Q 100 ip address 192.168.0.1 255.255.255.0 ip nat inside ! ip nat pool Internet 172.16.10.38 172.16.10.46 prefix-length 28 ip nat inside source static 192.168.0.2 172.16.10.34
The first step in firewall policy configuration is defining traffic classes. We start by defining class maps matching the basic protocol sets (ping, web traffic, mail delivery, and network management) encountered in this firewall (Listing 4-2).
Note
Within this case study, we optimize the class definitions by grouping similar protocols in the same traffic class. When deploying application-level packet inspection, each protocol has to be defined as a separate traffic class (see the next chapter for more details), increasing the complexity of the configuration. It’s therefore mandatory that you understand the final firewall requirements before you start configuring the router.
Example 4-2. Configuring Basic Protocol Sets
class-map type inspect match-any ping match access-group name IcmpEcho ! ip access-list extended IcmpEcho permit icmp any any echo permit icmp any any echo-reply ! ! Note: Web traffic also includes ability to ping ! class-map type inspect match-any WebTraffic match protocol http match protocol https match class-map ping ! class-map type inspect FileTransfer match protocol ftp ! class-map type inspect match-any PublicManagement match protocol ftp match protocol ssh match protocol snmp ! class-map type inspect match-any SMTP match protocol smtp extended ! class-map type inspect match-any DNS match protocol dns
Within the firewall policy, we also need refined traffic class definitions where a specific protocol (for example, SMTP) will be allowed on only a specific server (for example, the inside mail server). For convenience, we also define a broader traffic class covering all public services offered by the perimeter server: SMTP, HTTP, and DNS and ping for troubleshooting purposes. The perimeter server is the authoritative server for the organization’s domain and a caching DNS server for the internal clients.
Listing 4-3 shows the refined and extended traffic classes.
Example 4-3. Additional Traffic Class Definitions
class-map type inspect match-all MailDelivery match class-map SMTP match access-group name InternalServer ! ip access-list extended InternalServer permit ip any host 10.0.0.10 ! class-map type inspect match-any PublicProtocols match class-map SMTP match class-map WebTraffic match class-map DNS match class-map ping ! class-map type inspect match-all PublicTraffic match class-map PublicProtocols match access-group name PerimeterServer ! ip access-list extended PerimeterServer permit ip any host 192.168.0.2
Note
The configuration of service policies and zone pairs seems highly verbose. You will see where you can benefit from this modularity when configuring more-complex firewall policies later in this chapter.
Next, we configure the individual zones and the policies between pairs of zones. Finally, individual interfaces are assigned to the configured security zones (Listing 4-4).
Example 4-4. Firewall Policies and Zone Definitions
zone security Inside zone security Perimeter zone security Outside ! policy-map type inspect InsideToOutside class type inspect WebTraffic inspect class type inspect FileTransfer inspect ! policy-map type inspect InsideToPerimeter class type inspect PublicTraffic inspect class type inspect PublicManagement inspect ! policy-map type inspect PerimeterToOutside class type inspect DNS inspect class type inspect SMTP inspect class type inspect ping inspect ! policy-map type inspect OutsideToPerimeter class type inspect PublicTraffic inspect ! policy-map type inspect PerimeterToInside class type inspect MailDelivery inspect ! zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside zone-pair security InsideToPerimeter source Inside destination Perimeter service-policy type inspect InsideToPerimeter zone-pair security PerimeterToInside source Perimeter destination Inside service-policy type inspect PerimeterToInside zone-pair security PerimeterToOutside source Perimeter destination Outside service-policy type inspect PerimeterToOutside zone-pair security OutsideToPerimeter source Outside destination Perimeter service-policy type inspect OutsideToPerimeter ! interface FastEthernet0/0 description Inside LAN zone-member security Inside ! interface FastEthernet0/0.100 description Perimeter network zone-member security Perimeter ! interface Serial0/0/0.100 point-to-point description Link to the Internet zone-member security Outside
We complete the firewall configuration with the router-protection measures. Obviously, the only traffic allowed from the outside or the perimeter network to the router is ICMP echo (ping). The router itself can only perform DNS queries, ping, and traceroute to external networks. To monitor potential intrusion activities, the router should log all other connection-establishment attempts.
Note
There might be additional public services the router itself needs to access (for example, the Network Time Protocol [NTP] service).
Because you cannot match any other protocol except TCP, UDP, and H323 in class maps used in conjunction with the self zone, we need to define a completely new set of traffic classes based exclusively on extended IP access lists.
Note
Note that the same policy map is used twice to specify firewall policies between the router and the outside and perimeter zones.
Cisco IOS is using UDP packets to perform the traceroute function. The initial destination UDP port number is 33434 (unless modified with the extended traceroute command); the port number is increased in every probe to allow the router to match probes with ICMP replies. Therefore, the IP access list matching traceroute traffic defines a wide range of target UDP ports.
Furthermore, because the router cannot properly handle ICMP responses to the UDP packets sent with the traceroute command, we need to include special provisions for ICMP replies arriving from the public network.
The configuration commands used to define firewall policy for inbound traffic from perimeter and outside networks are shown in Listing 4-5. (Class map ping is defined in Listing 4-2.) Listing 4-6 contains commands defining the outbound firewall policy. (IP access list IcmpEcho is defined in Listing 4-2.)
Example 4-5. Firewall Policy for Inbound Traffic from Perimeter and Outside Zones
class-map type inspect match-all ICMPreply match access-group name ICMPreply ! ip access-list extended ICMPreply permit icmp any any host-unreachable permit icmp any any port-unreachable permit icmp any any ttl-exceeded permit icmp any any packet-too-big ! policy-map type inspect PublicToRouter class type inspect ping inspect class type inspect ICMPreply pass class class-default drop log ! zone-pair security PerimeterToRouter source Perimeter destination self service-policy type inspect PublicToRouter zone-pair security OutsideToRouter source Outside destination self service-policy type inspect PublicToRouter
Example 4-6. Firewall Policy for Traffic from the Router Toward the Perimeter and Outside Zones
class-map type inspect match-any RouterPublicTraffic match access-group name traceroute match access-group name domainLookup match access-group name IcmpEcho ! ip access-list extended domainLookup permit udp any any eq domain ip access-list extended traceroute permit udp any range 32768 65535 any range 33434 33523 ! policy-map type inspect RouterToPublic class RouterPublicTraffic inspect ! zone-pair security RouterToPerimeter source self destination Perimeter service-policy type inspect RouterToPublic zone-pair security RouterToOutside source self destination Outside service-policy type inspect RouterToPublic
The permitted traffic between the internal hosts and the firewall router shall obviously include ping and traceroute (as above) as well as network management access to the firewall.
Ideally, the internal hosts would be allowed to open Telnet and SSH sessions to the router and perform router management with SNMP while the router would send syslog, TFTP, and FTP traffic to the internal server. However, because Cisco IOS Release 12.4 does not perform in-depth inspection of router-generated traffic, FTP or TFTP to or from the router cannot be handled properly. (The router cannot identify the data sessions.) There are three ways to resolve this problem:
Full IP connectivity shall be allowed between the router and the internal server. This solution is not recommended because anyone getting access to the firewall router would have full access to the internal server.
Use SSH or SCP (SSH-based Secure Copy) to download router configurations to the management station. You can also use SCP to upgrade a router’s software.
Use HTTPS (preferred) or HTTP to download new software to the router and store router configurations to the internal server.
Listing 4-7 shows the configuration commands defining the firewall policy between the firewall router and the inside network.
Example 4-7. Securing Inside Access to the Router
! ! Define inside-to-router policy ! class-map type inspect RouterManagement match access-group name RouterManagement ! ip access-list extended RouterManagement permit tcp any any eq telnet permit tcp any any eq 22 ! SSH permit udp host 10.0.0.10 host 10.0.0.1 eq snmp ! Network management ! policy-map type inspect InsideToRouter class type inspect ping inspect class type inspect RouterManagement inspect class type inspect ICMPreply pass class class-default drop log ! zone-pair security InsideToRouter source Inside destination self service-policy type inspect InsideToRouter ! ! Define router-to-inside policy ! class-map type inspect RouterFileTransfer match access-group name RouterFileTransfer ! ip access-list extended RouterDataTransfer permit tcp host 10.0.0.1 host 10.0.0.10 eq 22 ! SSH/SCP permit tcp host 10.0.0.1 host 10.0.0.10 eq www ! Web (http) permit tcp host 10.0.0.1 host 10.0.0.10 eq 443 ! SSL (https) permit udp host 10.0.0.1 host 10.0.0.10 eq snmp ! SNMP traps permit udp host 10.0.0.1 host 10.0.0.10 eq syslog ! SYSLOG messages ! policy-map type inspect RouterToInside class type inspect RouterPublicTraffic inspect class type inspect RouterDataTransfer inspect ! zone-pair security RouterToInside source self destination Inside service-policy type inspect RouterToInside
In this chapter, you’ve seen how you can use the basic configuration commands supported by the zone-based policy firewall feature of Cisco IOS to configure a firewall with public servers in a perimeter network. The configuration by itself is sufficient for smaller organizations where you would not expect heavy load on the public servers; otherwise, the router parameters have to be tuned to differentiate expected traffic load from denial-of-service attacks. In addition, this configuration does not detect applications that hide within the HTTP protocol (for example, instant messaging or peer-to-peer protocols). In the next chapter, you’ll see the advanced configuration commands that address these issues.