CCNA Security 15

In the previous article, we have three interfaces: OUTSIDE, DMZ and INSIDE. If that boggles your mind, think about how you would go about implementing a double INSIDE and double DMZ topology that looks like this:

In this topology, there are two routers leading to WebServer subnets, and two routers leading to User subnets. A total of 5 interfaces need to be taken care of. What ZPF allows us to do is to actually group the interfaces together. In this case, we can group both the WebServer routers into a single logical DMZ security zone, and both the User routers into an INSIDE zone. Finally, the OUTSIDE interface can be in its own OUTSIDE zone. The router will then be in a SELF zone which we will only briefly go through.

To begin configuration of a ZPF, we have to create zones. To do this, go into global configuration and type:
zone security OUTSIDE
zone security DMZ
zone security INSIDE

Now that we have the three zones we want, we can begin grouping the interfaces. To do this, go into the interfaces and apply them like this:
in s0/0
zone sec DMZ
in s0/1
zone sec DMZ
in s1/0
zone sec INSIDE
in s1/1
zone sec INSIDE
in f0/0
zone sec OUTSIDE

Once an interface is in a zone, traffic is denied until explicitly permitted. An exception is the SELF zone where traffic is permitted unless explicitly denied. Here is a breakdown of what's going to happen when:
-A host in a zone communicates with a host in another zone - Denied
-A host in a zone communicates with a host in no zone - Denied
-A host in no zone communicates with a host in no zone - Permitted

Now, like in the previous scenario, we'll write out our requirements:
-OUTSIDE should be able to HTTP/S to DMZ
-INSIDE should be able to Ping, Telnet and HTTP/S to DMZ and OUTSIDE
-DMZ should be able to HTTP/S to INSIDE (to simulate database access, we'll make use HTTP access through WebVPN)

Now let's begin with the implementation. We'll begin with a whole bunch of class-maps. These class-maps are similar to the ones we use in QoS, except that we have to insert the "type inspect" during creation. We'll create a few generic class-maps to match various traffic groups required by the scenario (since traffic is denied by default, it makes sense to only define those that are to be permitted):
class-map type inspect MATCHICMP
match protocol icmp
class-map type inspect MATCHTELNET
match protocol telnet
class-map type inspect match-any MATCHWWW
match protocol http
match protocol https

Notice that we have a "match-any" for the MATCHWWW declaration. The default behavior is to only take action when all matches are positive (match-all). Since it's not very possible that the same packet would be using both HTTP and HTTPS at the same time, we'll need to change it to match-any (like an OR operation, as opposed to an AND operation).

Now that we have defined the traffic we should look out for, it's time to group them into policy-maps. Policy-maps allow grouping of multiple class-maps and is similar in operation to an access-list. It is matched starting from the first entry and an action can be taken. The most commonly used actions are:
-INSPECT - Perform stateful inspection
-PASS - Similar to an ACL permit
-DROP - Similar to an ACL deny

Here is a policy-map that we create for OUTSIDE to DMZ HTTP/s communication:
policy-map type inspect INSPECTWWW
class type inspect MATCHWWW
inspect

The above map matches the HTTP/S protocol. If it matches, stateful inspection is applied on it and it is allowed to flow. While we're here, we'll create another one for INSIDE to DMZ and OUTSIDE communications (excuse the horrible naming convention):
policy-map type inspect INSPECTICMPTELNETWWW
class type inspect MATCHICMP
inspect
class type inspect MATCHTELNET
inspect
class type inspect match-any MATCHWWW
inspect

Now that we have what we want to match, and what actions to take for the matched traffic, we can start allowing traffic to flow by creating zone-pairs. Zone-pairs have a source and destination zone, and a policy-map can be activated upon matching interesting traffic. We'll start by allowing OUTSIDE to access the DMZ through HTTP/S:
zone-pair security WWWOUTSIDEDMZ source OUTSIDE dest DMZ
service-policy type inspect INSPECTWWW

At this point, an OUTSIDE host should be able to access the DMZ servers.

Now to simulate the DMZ to INSIDE access, we'll allow HTTP/S from DMZ to INSIDE:
zone-pair security WWWDMZINSIDE source DMZ dest INSIDE
service-policy type inspect INSPECTWWW

We'll then allow INSIDE to have ICMP, Telnet and HTTP/S access to all interfaces:
zone-pair security ICMPTELNETWWWINSIDEOUTSIDE source INSIDE dest OUTSIDE
service-policy type inspect INSPECTICMPTELNETWWW
zone-pair security ICMPTELNETWWWINSIDEDMZ source INSIDE dest DMZ
service-policy type inspect INSPECTICMPTELNETWWW

There we go. The firewall is completed. Now to test if DMZ hosts can really access INSIDE hosts through HTTP/S, we'll run WebVPN on a DMZ host, then attempt to connect inside. On either WebServer or WebServer2, create a cert by typing:
crypto pki trustpoint LOCAL
enroll self-signed
crypto pki enroll LOCAL

Next, enable WebVPN through:
webvpn gateway GATEWAY
ip interface Serial0/0
ssl trustpoint LOCAL
inservice
webvpn context CONTEXT
gateway GATEWAY
inservice
user cisco pass cisco

Now attempt to connect to the WebVPN through a host in the OUTSIDE network and you should be able to initiate a HTTP/S connection to a host in the INSIDE. At this point you can throw in services like NAT/PAT/VPN and it will still behave as you would expect!