In the last article, we began with the configuration of our Lab #4 which deals with Zone Based Firewall. We configured the 1st and 2nd tasks before we stopped. In this article, we will review the configuration made by CCP and then complete the lab tasks.
Our network diagram is shown below:
Let’s refresh our memory with the configuration tasks for the lab:
- Using the Basic Firewall Configuration Wizard, configure Zone Based Firewall on RTR1 using two zones: inside and outside. Interface Fa0/1 should be the outside (untrusted) interface and Fa0/0 should be the trusted interface. Leave all other interfaces unmarked.
- Inspect TCP, UDP and other protocols from the inside zone to the outside zone.
- Allow ONLY ICMP traffic from the outside zone to inside zone.
- Test your configuration:
- *Telnet traffic from the CCP host (10.0.0.100) to RTR2’s Lo0 interface (220.127.116.11) should be allowed and inspected;
- * RTR2’s Lo0 interface should be able to ping the CCP Host;
- * Assume you have an HTTP server running on the CCP Host. RTR2’s Lo0 should not be able to access that HTTP server. The logs should reveal the denial.
Your entire configuration should be done through the Cisco Configuration Professional tool.
Configuration solutions Cont’d
I suppose you are already familiar with the Zone-based firewall so I will just run through the configuration now. For better understanding, I will break the configuration down into different segments that are not necessarily in the order we saw in the last article.
zone security in-zone zone security out-zone ! interface FastEthernet0/1 zone-member security out-zone exit interface FastEthernet0/0 zone-member security in-zone exit
The configuration above creates two zones: in-zone and out-zone. The names are logical enough although you may be used to inside and outside; whatever works for you. Also, the interfaces are assigned to their respective zones: Fa0/0 to in-zone and Fa0/1 to out-zone.
ip access-list extended SDM_EIGRP remark CCP_ACL Category=1 permit eigrp any any exit ! class-map type inspect match-any SDM_EIGRP match access-group name SDM_EIGRP exit class-map type inspect match-any SDM_EIGRP_TRAFFIC match class-map SDM_EIGRP exit class-map type inspect match-all SDM_EIGRP_PT match class-map SDM_EIGRP_TRAFFIC exit ! policy-map type inspect ccp-permit class type inspect SDM_EIGRP_PT no drop pass exit class class-default exit ! zone-pair security ccp-zp-out-self source out-zone destination self service-policy type inspect ccp-permit exit
The configuration section above deals with permitting EIGRP between the outside zone and the self zone. First, an ACL was created matching EIGRP traffic (permit eigrp any any). That ACL was then matched in an inspect-type class map which was in turn matched in another class map and then another class map. Whew. CCP is an automated tool so it gets the job done even though some of the things are unnecessary. We only need the first class map to get it to work; the other two (SDM_EIGRP_TRAFFIC and SDM_EIGRP_PT) are unnecessary. A policy of pass is then configured for the class map and this policy is applied to the zone-pair ccp-zp-out-self i.e. between the outside and the self zone. Remember that zone-pairs are unidirectional, therefore outside to self is NOT the same as self to outside.
If we were doing the configuration manually, we can remove the unnecessary statements and have something like:
ip access-list extended SDM_EIGRP remark CCP_ACL Category=1 permit eigrp any any exit ! class-map type inspect match-any SDM_EIGRP match access-group name SDM_EIGRP exit ! policy-map type inspect ccp-permit class type inspect SDM_EIGRP no drop pass exit class class-default exit ! zone-pair security ccp-zp-out-self source out-zone destination self service-policy type inspect ccp-permit exit
Let’s move on with the review now. The next section we will consider is the self zone to outside zone.
class-map type inspect match-any ccp-cls-icmp-access match protocol icmp match protocol tcp match protocol udp exit class-map type inspect match-all ccp-icmp-access match class-map ccp-cls-icmp-access exit ! policy-map type inspect ccp-permit-icmpreply class type inspect ccp-icmp-access no drop inspect exit class class-default no drop pass exit exit ! zone-pair security ccp-zp-self-out source self destination out-zone service-policy type inspect ccp-permit-icmpreply exit
According to CCP, it would add policy to inspect router-generated ICMP traffic.
Router-generated in zone-based firewall language simply means the self zone. However, the configuration above does not only inspect ICMP traffic, it also inspects TCP and UDP traffic. It seems we found a bug in the CCP configuration. In the next article, we will check that indeed the configuration is inspecting TCP, UDP and ICMP instead of just ICMP traffic.
Let’s now move on to the final piece of the configuration. I saved the best, or rather the bulkiest, for the last.
access-list 100 remark CCP_ACL Category=128 access-list 100 permit ip host 255.255.255.255 any access-list 100 permit ip 127.0.0.0 0.255.255.255 any access-list 100 permit ip 192.168.12.0 0.0.0.255 any ! class-map type inspect match-any ccp-h225ras-inspect match protocol h225ras exit class-map type inspect match-all ccp-protocol-http match protocol http exit class-map type inspect match-all ccp-invalid-src match access-group 100 exit class-map type inspect match-any ccp-cls-insp-traffic match protocol cuseeme match protocol dns match protocol ftp match protocol https match protocol icmp match protocol imap match protocol pop3 match protocol netshow match protocol shell match protocol realmedia match protocol rtsp match protocol smtp extended match protocol sql-net match protocol streamworks match protocol tftp match protocol vdolive match protocol tcp match protocol udp exit class-map type inspect match-all ccp-insp-traffic match class-map ccp-cls-insp-traffic exit class-map type inspect match-any ccp-h323-inspect match protocol h323 exit class-map type inspect match-any ccp-sip-inspect match protocol sip exit class-map type inspect match-any ccp-skinny-inspect match protocol skinny exit ! policy-map type inspect ccp-inspect class type inspect ccp-invalid-src drop log exit class type inspect ccp-protocol-http no drop inspect exit class type inspect ccp-insp-traffic no drop inspect exit class type inspect ccp-h323-inspect no drop inspect exit class type inspect ccp-h225ras-inspect no drop inspect exit exit ! zone-pair security ccp-zp-in-out source in-zone destination out-zone service-policy type inspect ccp-inspect exit !
The ACL 100 matches traffic with invalid source addresses. We also have class maps that match voice traffic and another class map that matches most of the protocols to be inspected (ccp-cls-insp-traffic). Also notice that there are two class maps that are configured above but not used under any policy: ccp-skinny-inspect and ccp-sip-inspect. I wonder what they are doing there.
In the policy map, a drop and log action is configured for the class map that matches traffic with invalid source addresses; all other class maps have the inspect action configured. The policy map is then applied to the ccp-zp-in-out zone-pair i.e. traffic from the inside zone to the outside zone.
We can now continue with the lab tasks. From the above configuration, notice that there is no zone-pair for outside zone to inside zone – we only have an inside zone to outside zone zone-pair. By default, traffic will not flow between zones without a configured policy. This means that all traffic initiated from the outside zone to the inside zone will be denied. We can do a quick test for this: I will ping the CCP host (10.0.0.100) from RTR2 which is in the outside zone.
Note that I can ping successfully in the reverse direction as shown below:
Task #3 requires us to allow only ICMP traffic from the outside zone to the inside zone. To do this, we have to edit the firewall policy we have configured.
The Add a Rule screen shows up which allows me to choose/create the source and destination zones and also select what service(s) I want to match and thus configure the policy to be applied: inspect, allow or deny.
You will find ICMP under the Network Management protocol group. An easier way may be to show the services in alphabetical order and then select the service(s) you want to match. At the end of my configuration, I have a screen similar to what is shown below:
The configuration to be sent to the router is as shown below:
class-map type inspect match-any allow-icmp match protocol icmp exit policy-map type inspect ccp-policy-allow-icmp class type inspect allow-icmp no drop pass exit exit zone-pair security sdm-zp-out-zone-in-zone source out-zone destination in-zone service-policy type inspect ccp-policy-allow-icmp exit
The rule now shows up in the firewall policy screen:
Finally, we are at the fun part – testing. Zone-based firewall is one of those configurations that may easily be misconfigured but since we did it through the wizard, we should be fine. The first test already succeeded as we saw above. The CCP host can ping RTR2 on its loopback interface.
We can use the show command to see that the session is actually being inspected.
The second test should succeed if we correctly configured Task #3. I will ping from 18.104.22.168 to 10.0.0.100.
For the last test, we can simulate an HTTP connection using Telnet to port 80. Notice from the show output above that the class-default is still “0 packets.” Our HTTP simulation should generate some packets which should be dropped.
It’s cool to see things work. Before we end this article, let us use the monitoring interface of the CCP tool to look at what is happening with our firewall. I will navigate to Monitor > Security > Firewall Status.
I will initiate a continuous ping from 10.0.0.100 to 22.214.171.124 which is the ccp-zp-in-out zone-pair and click on Monitor Policy.
You can try the same thing for the other tests.
This brings us to the end of this article on the CCP Lab #4. However, we are not yet done with the zone-based firewall as the next lab will also consider more configurations on ZFW. In this article, we have configured basic ZFW on RTR1 with one inside zone (and interface) and one outside zone. We did this using the Basic Firewall Configuration Wizard provided by CCP. We also added a new rule from the Edit Firewall Policy screen to allow ICMP traffic from the outside to the inside zone.
I hope you have found this article insightful. The next article will focus on the ZFW self zone. I look forward to the next article in the series.
Zone-Based Policy Firewall Design and Application Guide: http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.html
CCNA Security Certification Series – #1 Cisco Firewall Technologies: http://resources.intenseschool.com/ccna-security-certification-series-1-cisco-firewall-technologies/