In the previous chapters, you’ve seen how you can design your firewall using the zone-based design concepts. In this chapter, you’ll find the Cisco IOS configuration commands that enable you to translate the firewall policy into a working router configuration. Throughout this chapter, we focus on the simple LAN-to-Internet firewall design described in the preceding chapter. Figure 3-1 outlines the addressing scheme used in the examples.
As you can see in the diagram, the inside LAN is using the private address space 10.0.0.0/24 that is translated using the Network Address Translation (NAT) functionality of Cisco IOS into the provider-allocated public address space 172.16.10.32/28. Because the public address space covers the needs of the inside clients, NAT overload is not used.
The ISP provides mail (SMTP and POP3) services on smtp.isp.com and DNS and Web services on dns.isp.com. The client computers will also access a third-party Web server at www.web.com.
Note
The configuration in Listing 3-1 is slightly abridged. (For example, vty and console configuration has been removed.) It has also not been properly secured. (For example, Finger and HTTP are enabled, and Telnet is used rather than SSH.)
Listing 3-1 shows the initial router configuration with basic IP addressing and NAT.
Example 3-1. Initial Router Configuration
hostname fw ! service finger ! ip dhcp pool LAN network 10.0.0.0 255.255.255.0 ! interface Loopback1 ip address 172.16.10.33 255.255.255.240 ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ip nat inside ! interface Serial0/0/0 no ip address encapsulation frame-relay ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252 ip nat outside frame-relay interface-dlci 100 ! ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100 ! ! ip http server no ip http secure-server ip nat pool Internet 172.16.10.34 172.16.10.46 prefix-length 28 ip nat source list InternalHosts pool Internet ip nat inside source list InternalHosts pool Internet ! ip access-list standard InternalHosts permit 10.0.0.0 0.0.0.255 ! end
Note
nmap, a public-domain program available from www.insecure.org, is used to perform the port scans. Printouts are abridged for clarity. Do not perform port scans on external IP hosts without the owner’s permission.
The configuration seems pretty secure by itself, because NAT should be able to hide inside hosts from potential intruders. An initial port scan done from the outside (results are shown in Listing 3-2) seems to confirm this assumption, because the potential intruder can reach only one IP host (the router itself).
Example 3-2. External Port Scan with No Active Host
External$ nmap --system-dns 172.16.10.32/28
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
23/tcp open telnet
79/tcp open finger
80/tcp open http
Nmap finished: 16 IP addresses (1 host up) scanned in 23.473 seconds
However, after an inside client establishes any session across the firewall router, its IP address becomes available to the outside world. Because the router offers no additional protection beyond address translation, the intruders have free access to the inside hosts, as documented in Listing 3-3. (Focus on the highlighted lines; the others are the publicly accessible router services.)
Example 3-3. External Port Scan with Active NAT Translations
External$ nmap --system-dns 172.16.10.32/28 Interesting ports on 172.16.10.33: (The 1671 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet 79/tcp open finger 80/tcp open http Interesting ports on 172.16.10.34: (The 1668 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 3389/tcp open ms-term-serv 5800/tcp open vnc-http 5900/tcp open vnc Nmap finished: 16 IP addresses (2 hosts up) scanned in 44.083 seconds
Obviously, additional protection is needed to change the initial setup into a real firewall.
Note
Class map definitions are mandatory unless you want to rely on the system-defined class-default class, which matches all traffic.
The zone-based policy firewall in Cisco IOS is configured in a modular fashion through these steps:
Use the new zone security command to define the zones in your firewall.
(Optional) Use the class-map type inspect global configuration commands to define the traffic classes based on specifications from the firewall design. A traffic class is a way of identifying a set of packets based on their content (for example, common application layer protocol).
Use the policy-map type inspect global configuration command to specify the firewall policy (what happens to each interesting traffic class defined previously with class-map type inspect commands).
Use the zone-pair security command to apply a predefined firewall policy to a pair of source (client) and destination (server) zones.
After the firewall policy is configured, assign the router interfaces to various security zones by using the zone-member security interface configuration command.
Our example has two security zones: inside and outside. Listing 3-4 shows the configuration commands used to create them. To help network administrators understand the router configuration, you can assign a description to each zone with the description zone configuration command.
The firewall policy in our design is very simple: All traffic is allowed from the inside zone to the outside zone, so we can use the class-default (match all) traffic class in the policy-map command. Similar to other modular CLI constructs in Cisco IOS, you have to specify what to do with the traffic matching the desired traffic class. You have the following options:
Pass the packets. This action is equivalent to an access-list permit statement and is thus unidirectional. There is no provision for return traffic, so you have to specify the handling of return traffic manually. This option is useful only for protocols such as IPsec-encrypted traffic.
Inspect the packet. This action is equivalent to the functionality of the ip inspect command of the Cisco IOS Firewall Stateful Inspection feature. It automatically provides conduits for return traffic and potential ICMP messages. For protocols requiring multiple parallel signaling and data sessions (for example, FTP or H.323), the inspect action also handles the proper establishment of data sessions.
Drop the packet. Equivalent to the access-list deny statement. Similar to the access lists, you can use the log option to log the rejected packets.
Police. Rate-limits the traffic of the specified class. Can be used only in conjunction with the inspect or pass command.
After the firewall policy has been configured, you can apply it to traffic between a pair of zones using the zone-pair security configuration command. In this command, you specify the source zone (in which the clients reside), the destination zone (where the servers are), and the policy for handling the traffic between them.
Listing 3-5 shows the InsideToOutside firewall policy and the corresponding zone-pair command used in our firewall.
After the firewall policy is complete, you can assign individual interfaces to security zones with the zone-member security configuration command, resulting in the final router configuration in Listing 3-6.
Example 3-6. Initial Zone-Based Policy Firewall Configuration
policy-map type inspect InsideToOutside class class-default inspect ! zone security Inside description Inside network zone security Outside description Outside network zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside ! interface FastEthernet0/0 zone-member security Inside ! interface Serial0/0/0.100 point-to-point zone-member security Outside
The first port scan results from an outside host are encouraging; after the firewall policy has been configured, the internal hosts are no longer visible to port scans from the outside, as shown in Listing 3-7. However, it’s obvious that the router itself is still vulnerable.
Example 3-7. Scanning the Protected LAN from the Outside
External$ nmap --system-dns 172.16.10.32/28
Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2006-07-29 23:41
Interesting ports on 172.16.10.33:
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
23/tcp open telnet
79/tcp open finger
80/tcp open http
Nmap finished: 16 IP addresses (1 host up) scanned in 64.964 seconds
Raw packets sent: 2581 (112.944KB) | Rcvd: 1677 (77.142KB)
On the other hand, a simple test (Listing 3-8) proves that the inside clients can reach any service or server on the Internet.
Example 3-8. Scanning an External Web Server from the Inside
Inside$ nmap -v --system-dns web.com
Interesting ports on web.com (172.18.25.10):
(The 1663 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1026/tcp open LSA-or-nterm
3389/tcp open ms-term-serv
5800/tcp open vnc-http
5900/tcp open vnc
Nmap finished: 1 IP address (1 host up) scanned in 277.339 seconds
Raw packets sent: 1958 (86.132KB) | Rcvd: 1685 (77.510KB)
Deploying a zone-based firewall has an additional unexpected benefit: Because all the traffic between zones is inspected, a port scan almost always triggers alerts and corresponding log messages (displayed in Listing 3-9).
Example 3-9. Alerts Generated by the Router During Port Scan
00:42:35: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcphalf-open connections (50) exceeded for host 172.18.25.10. 00:42:43: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp
In this section, we have used the commands summarized in Table 3-1 to create an initial firewall configuration.
Table 3-1. Basic Zone-Based Policy Firewall Configuration Commands
Command Syntax | Description |
|---|---|
zone security name | Creates a new security zone. |
description text | Optionally assigns a description to the selected security zone. |
policy-map type inspect name | Creates a new policy map or starts configuration of the existing policy map. The type inspect keywords are mandatory. |
class name | Within a policy map, starts configuring firewall actions for the specified traffic class. |
class class-default | Within a policy map, starts configuring firewall actions for all unclassified traffic. The class class-default command should be the last class specification in the policy map. |
inspect | Within a traffic class configuration, permits traffic and requests packet inspection to establish automatic conduits for return traffic (equivalent to the ip inspect command of Cisco IOS Firewall stateful inspection). |
pass | Within a traffic class configuration, permits traffic. You have to make manual provisions for return traffic handling. |
drop [log] | Drops the packets of the selected traffic class with optional logging to the router’s log. |
police rate bps burst burst-size | Rate-limits traffic within the specified traffic class to the specified bits-per-second rate with a specified maximum burst size. |
In the preceding section, we configured a simple firewall that protected the inside network while allowing the inside users to access any service on the Internet. In this section, we extend this design by limiting the services the inside users are allowed to access (the second design of the section “Simple LAN-to-Internet Firewall” in Chapter 2, “Typical Zone-Based Firewall Designs”). To reach that goal, we first have to define the traffic classes that will later be used in the policy-map commands to define the desired firewall policy. The traffic classes are defined with the well-known class-map command augmented with the type inspect keyword.
class-map can classify traffic based on source and destination addresses and Layer 4 port numbers using extended IP access lists, or based on well-known Layer 4 (TCP, UDP, ICMP, and so on) or Layer 7 (SMTP, HTTP, FTP, and so forth) protocols. Table 3-2 shows the syntax of the class-map command and the associated match commands.
Table 3-2. Syntax of the class-map type inspect and Associated match Commands
Command syntax | Description |
|---|---|
class-map type inspect [match-all |match-any] name | Starts configuration of the named class map. The traffic matched by the class map has to match all the specified match conditions (match-all option, also the default behavior) or any of them (match-any option, which has to be explicitly specified). |
match access-group {ACL-number | name ACL-name} | Matches traffic permitted by the specified access group. You can use numbered or named IP access lists. |
match protocol {tcp | udp | icmp} | Matches any packet of the specified Layer 4 protocol. |
match protocol protocol-name | Matches the specified Layer 7 protocol based on its Layer 4 port number (specified as the Layer 7 protocol name in the configuration). Protocols operating on nonstandard ports or user-defined protocols can be specified with the ip port-map command, covered in Chapter 5. |
match class-map name | Matches traffic specified by a previously defined class map. This command is useful when you want to extend a previous traffic definition (use the match-any option in the class-map command) or narrow it (with the match-all option in the class-map command). This command can also be used to implement complex logical conditions that cannot be specified with a single class map. |
match not condition | Matches all traffic not matching the specified condition. |
Note
Class maps using these parameters are known as Layer 4 class maps. Cisco IOS also supports deeper inspection of HTTP, IMAP, instant messaging (AOL, MSN, Yahoo!), and peer-to-peer (edonkey, fasttrack, gnutella, kazaa) protocols. Those class maps are called Layer 7 class maps and are covered in a later section.
To configure the desired firewall policy, we need to specify two traffic classes:
Traffic permitted to any destination on the Internet (HTTP, HTTPS, FTP, ICMP)
Traffic permitted to the Internet service provider’s (ISPs) servers (SMTP, POP3, DNS).
The configuration of the first traffic class is simple: Just use the class-map command with the match-any option and list all the desired protocols, as shown in Listing 3-10.
Note
You might be tempted to use the access list to match both IP addresses and TCP port numbers instead of using the match protocol commands. However, when a protocol uses control and data sessions (as FTP does), the match protocol command matches all relevant sessions, and the access list cannot do it. For example, match protocol ftp is not equivalent to permit tcp any any eq ftp.
The definition of traffic allowed toward the ISP servers is a bit more complex because we have to specify two conditions: a list of protocols (using the match-any keyword) toward a set of IP addresses (here we need a match-all keyword). Listing 3-11 contains the minimum configuration needed to achieve these goals.
Example 3-11. Matching Traffic Toward ISP Servers
class-map type inspect match-any ISPTraffic match protocol dns match protocol smtp match protocol pop3 ! class-map type inspect match-all ToISP match class-map ISPTraffic match access-group name ISPServers ! ip access-list extended ISPServers permit ip any host 172.16.0.1 permit ip any host 172.16.0.2
After defining the two traffic classes, you can specify the target firewall policy as follows:
Inspect all traffic in classes ToISP and InternetTraffic.
Drop and log all the other traffic.
Listing 3-12 shows the final firewall configuration.
Example 3-12. Final Simple LAN-to-Internet Firewall Configuration
class-map type inspect match-any ISPTraffic match protocol dns match protocol smtp match protocol pop3 class-map type inspect match-all ToISP match class-map ISPTraffic match access-group name ISPServers class-map type inspect match-any InternetTraffic match protocol http match protocol ftp match protocol icmp match protocol https ! ! policy-map type inspect InsideToOutside class type inspect ToISP inspect class type inspect InternetTraffic inspect class class-default drop log ! zone security Inside description Inside network zone security Outside description Outside network zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ip nat inside zone-member security Inside ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252 ip nat outside zone-member security Outside ! ip access-list extended ISPServers permit ip any host 172.16.0.1 permit ip any host 172.16.0.2
To verify the proper operation of your configuration, you can use a port-scanning program from an inside host. As Listing 3-13 shows, Internet services (FTP, HTTP) can be reached on the ISP servers together with the ISP-specific services (SMTP, POP3, DNS). On the other hand, only Internet services are available to inside clients on any other Internet host (Listing 3-14).
Example 3-13. Port Scan of the ISP Servers from the Inside
Inside$ nmap --system-dns 172.16.0.0/28
Interesting ports on dns.isp.com (172.16.0.1):
(The 1669 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
Interesting ports on smtp.isp.com (172.16.0.2):
(The 1669 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
25/tcp open smtp
53/tcp open domain
110/tcp open pop3
Nmap finished: 16 IP addresses (2 hosts up) scanned in 82.939 seconds
Example 3-14. Port Scan of an External Web Server from an Inside Host
Inside$ nmap --system-dns www.web.com
Interesting ports on web.com (172.18.25.10):
(The 1671 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https
Nmap finished: 1 IP address (1 host up) scanned in 26.047 seconds
As expected, the port scan generates a number of router alerts, as shown in Listing 3-15.
The firewall configuration in the previous section has successfully protected inside hosts from Internet attacks and limited the services the inside hosts can access on the Internet. The router itself, however, remains vulnerable because the traffic to and from the router itself is not restricted by the interzone policies (as shown in Listing 3-2 earlier in this chapter).
To protect the router, you could use incoming IP access lists on all interfaces. This approach (although commonly used in the past) has a number of severe drawbacks:
The access list has to include all IP addresses configured on the router.
Whenever the router participates in several security zones, a different access list has to be specified for each zone.
The access lists cannot restrict the traffic originating in the router. (The only way to influence outgoing traffic is through local policy routing.)
The zone-based policy firewall feature does not amend the access lists the way Cisco IOS Firewall stateful inspection does. Therefore, special precautions must be taken to ensure that there are no undesired side effects from applying access lists on interfaces assigned to security zones.
Zone-based policy firewall configuration in Cisco IOS offers a novel approach to this problem: The router itself can be defined as a separate security zone (with the predefined name self), and the incoming and outgoing sessions can be limited in the same way as the routed interzone traffic.
Note
A more complex router protection policy will be developed in the next chapter. A more security-conscious environment would also not allow full access from the router to the inside network.
Common router protection measures in a small LAN-to-Internet firewall might include the following:
No external access, apart from ping (icmp echo) and routing protocols (if needed)
No access to the Internet from the router (apart from the routing protocols, if needed)
Limited internal access (for example, ping, Telnet or SSH, SNMP, HTTP, and HTTP/HTTPS
Full access from the router to the inside network
To implement these protection measures, you need to configure, at minimum, the following:
Two IP access lists, one for external (ping only) traffic and one for internal traffic.
Two class maps and three policy maps. (The third policy map allows any traffic from the router to the inside zone.)
Several zone pairs.
Listing 3-16 shows the complete configuration needed to protect the router.
Example 3-16. Protecting the Router with the Self Zone
ip access-list extended ICMPEcho permit icmp any any echo ! class-map type inspect match-any ping match access-group name ICMPEcho ! policy-map type inspect OutsideToRouter class type inspect ping inspect class class-default drop log ! zone-pair security OutsideToRouter source Outside destination self service-policy type inspect OutsideToRouter ! ip access-list extended ManagementProtocols permit tcp any any eq telnet permit tcp any any eq 22 ! ssh permit tcp any any eq www permit tcp any any eq 443 ! https permit icmp any any echo ! class-map type inspect match-any RouterManagement match access-group name ManagementProtocols ! policy-map type inspect InsideToRouter class type inspect RouterManagement inspect class class-default ! policy-map type inspect RouterToInside class class-default inspect ! zone-pair security InsideToRouter source Inside destination self service-policy type inspect InsideToRouter zone-pair security RouterToInside source self destination Inside service-policy type inspect RouterToInside
Quick port scans from an inside (Listing 3-17) and outside (Listing 3-18) host verify that the configuration in Listing 3-16 does protect the router. The inside host can only access the services that we have specified in the RouterManagement access list, and the outside host cannot access the router at all (although it can still be pinged as –; see the “1 host up” message from nmap).
Example 3-17. Port Scan of a Protected Router from the Inside
Inside$ nmap --system-dns 10.0.0.1
Interesting ports on fw (10.0.0.1):
(The 1671 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
23/tcp open telnet
80/tcp open http
443/tcp closed https
Nmap finished: 1 IP address (1 host up) scanned in 22.552 seconds
As with every Cisco IOS features, a number of show and debug commands are available to network administrators to monitor and troubleshoot the zone-based configurations.
If you would like to see the summary of your zone configuration, the show zone security command is the one you’re looking for (Listing 3-19).
If you would like to see more details about the configured traffic classes and interzone policies, the obvious commands are show class-map type inspect, show policy-map type inspect, and show zone-pair security. They display the specified class map, policy map, or zone pair so that you don’t have to browse through the router configuration. More useful is the show policy-map type inspect zone-pair name command, which displays the traffic and usage statistics for a zone pair, as shown in Listing 3-20.
Example 3-20. Output of a show policy-map type inspect zone-pair Command
fw#show policy-map type inspect zone-pair InsideToOutside
Zone-pair: InsideToOutside
Service-policy inspect : InsideToOutside
Class-map: InternetTraffic (match-any)
Match: protocol http
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol ftp
3 packets, 84 bytes
30 second rate 0 bps
Match: protocol icmp
1 packets, 40 bytes
30 second rate 0 bps
Match: protocol https
0 packets, 0 bytes
30 second rate 0 bps
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [133:2363]
icmp packets: [0:8]
ftp packets: [46:0]
Session creations since subsystem startup or last reset 7
Current session counts (estab/half-open/terminating) [2:0:0]
Maxever session counts (estab/half-open/terminating) [2:1:1]
Last session created 00:00:13
Last session created 00:00:13
Last statistic reset never
Last session creation rate 1
Last half-open session total 0
... printout repeated for other classes of traffic ...
Warning
The per-protocol traffic counters displayed in the show policy-map type inspect zone-pair command can be misleading. For example, the counters for the FTP protocol list only the actual content packets (excluding the TCP setup packets) exchanged in the FTP control session and do not include the data transferred in the FTP data sessions.
The show policy-map type inspect zone-pair name sessions command gives an even more detailed printout. It includes all the open sessions, too (see Listing 3-21). The name parameter is optional; without it, the router displays all sessions it tracks.
Example 3-21. Sessions Established Between a Pair of Zones
fw#show policy-map type inspect zone-pair sessions Zone-pair: InsideToOutside Service-policy inspect : InsideToOutside Class-map: InternetTraffic (match-any) Match: protocol http 0 packets, 0 bytes 30 second rate 0 bps Match: protocol ftp 3 packets, 84 bytes 30 second rate 0 bps Match: protocol icmp 1 packets, 40 bytes 30 second rate 0 bps Match: protocol https 0 packets, 0 bytes 30 second rate 0 bps Inspect Established Sessions Session 478AF96C (172.16.0.1:20)=>(10.0.0.2:1053) ftp-data SIS_OPEN Created 00:04:30, Last heard 00:00:00 Bytes sent (initiator:responder) [1917424:0] Session 478AFC24 (10.0.0.2:1051)=>(172.16.0.1:21) ftp SIS_OPEN Created 00:06:04, Last heard 00:04:29 Bytes sent (initiator:responder) [98:247] ...rest of printout deleted ...
A few debugging command also support the zone-based policy firewall feature:
The debug zone security command is focused on zone security events (for example, interface assignments).
The debug ip inspect policy command gives you an in-depth view of individual packet classification. Listing 3-22 shows a printout associated with a single TCP SYN packet trying to open a Finger session to the router.
Example 3-22. Output of the debug ip inspect policy Command
00:36:29: CBAC-C3PL : Policy lookup for pak 0x4716467C [insp_c3pl_policy_lookup] 00:36:29: CBAC-C3PL : input i/f is FastEthernet0/0, output i/f is NULL
[insp_c3pl_validate_zoning]
00:36:29: CBAC-C3PL : Zone-pair and policy found [insp_c3pl_validate_zoning]
00:36:29: CBAC-C3PL : Packet L7 protocol is 59 L4 prot is 1 [insp_c3pl_classify_packet]
00:36:29: CBAC-C3PL : zeroing out prot_flag [insp_c3pl_packet_classify_class_based_common]
00:36:29: CBAC-C3PL : Checking if the packet(0x4716467C) matches with class RouterManagement
[insp_c3pl_packet_classify_class_based_common]
00:36:29: CBAC-C3PL : zeroing out prot_flag [insp_c3pl_packet_classify_class_based_common]
00:36:29: CBAC-C3PL : Checking if the packet(0x4716467C) matches with class class-default
[insp_c3pl_packet_classify_class_based_common]
00:36:29: CBAC-C3PL : Packet(0x4716467C) matched with class class-default
[insp_c3pl_packet_classify_class_based_common]
00:36:29: CBAC-C3PL : Classification returned protocol-id 0x0 classid 0
[insp_c3pl_classify_packet]
00:36:29: CBAC-C3PL : DROP action found in policy-map [insp_c3pl_process_actions_of_class]
00:36:29: CBAC-C3PL : Action processing returned code 1. [insp_c3pl_classify_packet]
00:36:29: CBAC-C3PL : classify processing returned 1 [insp_c3pl_policy_lookup]
Warning
Use debug ip inspect policy only on a lightly loaded router in a controlled environment (preferably with no logging to the router console); otherwise, you might easily overload its CPU.
Furthermore, because the zone-based firewall policy feature is closely linked to the Context-Based Access Control (CBAC) code, many debug ip inspect commands work as expected. For example, you might debug DNS and FTP inspection, resulting in the following printout when a user opens an FTP session from the inside to the outside zone (Listing 3-23).
Example 3-23. Debugging FTP and DNS Sessions
fw#debug ip inspect dns INSPECT DNS Inspection debugging is on fw#debug ip inspect ftp-cmd INSPECT FTP commands and responses debugging is on fw# 00:43:01: CBAC FUNC: insp_dns_sis_ext_create 00:43:01: CBAC FUNC: insp_handle_dns_control_stream 00:43:01: CBAC FUNC: insp_handle_dns_control_stream 00:43:01: CBAC FTP sis 478AFEDC FTP-Server: 220 sp IOS-FTP server (version 1.00) ready.~~ 00:43:06: CBAC FUNC: insp_dns_handle_inactivity 00:43:16: CBAC FTP sis 478AFEDC FTP-Client: USER myUser~~ 00:43:16: CBAC FTP sis 478AFEDC FTP-Server: 331 Password required for 'myUser'.~~ 00:43:18: CBAC FTP sis 478AFEDC FTP-Client: PASS xxxxxx 00:43:18: CBAC FTP sis 478AFEDC FTP-Server: 230 Logged in.~~ 00:43:18: CBAC sis 478AFEDC User authenticated
In this chapter, you’ve seen how you can do almost a one-to-one mapping between your zone-based firewall design and Cisco IOS configuration commands:
Traffic specifications described in your design are configured with class-map type inspect commands that can match individual transport layer or application layer protocols with the match protocol command or IP addresses (or port numbers) with the match access-group command. More complex logical conditions are also possible with the right combination of match-all or match-any keywords, sometimes combined with hierarchical class-maps.
Interzone policies are expressed as policy-map type inspect commands in Cisco IOS and are assigned to specific pairs of zones with the zone-pair security command. The two configuration layers allow you to use the same policy on multiple pairs of zones, thus further simplifying the configuration.
Interfaces are assigned to security zones with the zone-member security commands. All traffic entering or exiting these interfaces (apart from traffic to and from the router itself) is subject to security screening, additionally improving the security of the zone-based firewall in Cisco IOS.
Traffic to and from the router is not monitored (doing so by default would probably quickly kill routing protocols and network management in most implementations). To protect the router itself, you specify the interactions of the predefined zone self with other security zones.