Start with 7 free days of training.

Gain instant access to our entire IT training library, free for your first week.
Train anytime on your desktop, tablet, or mobile devices.

Implementing Cisco Edge Network Security Solutions

This Implementing Cisco Edge Network Security Solutions (SENSS) course provides training on how to configure and implement security on Cisco network perimeter edge devices such as a switch, router, and ASA firewall....
This Implementing Cisco Edge Network Security Solutions (SENSS) course provides training on how to configure and implement security on Cisco network perimeter edge devices such as a switch, router, and ASA firewall.

In this course, you will learn how to implement and manage security on Cisco ASA firewalls, routers, and switches, as well as how to configure perimeter security solutions for mitigating threats against your network. As part of your studies regarding the ASA, it's also recommended that you watch the CBT Nuggets "CCNP Security Firewall" course for advanced ASA features including failover, transparent firewall, and multiple contexts.

Recommended Skills:
  • CCNA Route/Switch and CCNA Security certification (or equivalent knowledge and skills)
  • Knowledge of Microsoft Windows
  • CCNA Security is a pre-requisite for the CCNP Security certification
Recommended Equipment:
  • Switch, IOS and ASA. Emulated IOS and ASA may be used.
Related Certifications:
  • CCNP Security. This course (SENSS exam # 300-206) is part of the curriculum in the Cisco Certified Network Professional Security (CCNP© Security) certification
Related Job Functions:
  • Network Analyst
  • Network Engineer
  • Network Technician
  • Network Designer
  • Security Analyst
  • Security Auditor
  • Penetration Tester
  • Security Architect
  • Technical Manager
 show less
1. Welcome (7 min)
2. Port Security (25 min)
3. DHCP Snooping (29 min)
4. Dynamic ARP Inspection (DAI) (32 min)
5. Source Guard (15 min)
6. Storm Control (28 min)
7. Private VLANs (21 min)
8. Protected Ports (10 min)
9. VACLs, pACLs, and MACsec (15 min)
10. Remote Management (23 min)
11. RSA SSH Authentication (17 min)
12. SNMPv3 - CPPr (32 min)
13. iACLs (20 min)
14. uRPF (21 min)
15. NetFlow (27 min)
16. NAT and PAT (22 min)
17. Zone-Based Firewalls (42 min)
18. AAA (34 min)
19. Best Practices (26 min)
20. ASA CLI L3-4 (45 min)
21. ASA CLI L5-7 (25 min)
22. ASA Packet Capture (21 min)
23. Botnet Filtering (20 min)
24. Context Directory Agent (19 min)
25. Security Virtualization and IPS (15 min)
26. Management Tools (10 min)
27. IPv6 Security (12 min)


Port Security

DHCP Snooping

Dynamic ARP Inspection (DAI)

Source Guard

Storm Control

Private VLANs

Protected Ports

VACLs, pACLs, and MACsec

Remote Management

RSA SSH Authentication






Zone-Based Firewalls


The iOS zone-based firewall. Let's begin. One of the technical controls that you and I have at our disposal is the good old access control list, which we can create to permit or deny traffic. We can apply those inbound or outbound on any interface if we want to.


But having just static access list is kind of a problem. And that's because we have users like Bob. Bob has a burning desire to go out to the internet. So he's out at Google or Yahoo or whatever he's visiting, and what Bob expects to happen is when he goes out to that website, he expects the reply traffic to go ahead and come back in.


Well, the tricky part is this. How do we allow the website to reply to Bob and at the same time stop servers and hackers and other individuals on the internet? How do we stop them from being able to initiate traffic to get to Bob? You want to protect Bob and all of the resources in our company, and we don't want just any computer on the internet being able to reach our internal host.


And the solution that's been around for more than a decade is called stateful filtering. And one analogy that really works for a lot of people is the analogy of going to an amusement park. So here we have an amusement park. I'd like you to think about either a favorite park that you like to go to, like Disney World or Disneyland or what have you.


And I'd like you to imagine that you and I are at park, we're having a great time, riding the rides, seeing the sites. And then we realize, oh no, we forgot our mobile devices in the car. We don't want to get too hot. So what we do is we leave the park, but on the way out, we're stopped.


And they say, before you go out to your car, let me stamp your hand and also hang on your ticket stub so that you get back in without having to pay again. So we say thanks. We go out to our car. I think that's a car. We retrieve whatever it is we wanted to get.


We go back to the gate, and we simply show our hand with the stamp on it and we show our ticket stub, and the person at the gate says, you know what, this proves that you were already in the park. I'm going to go ahead and let you come back in. And that same kind of a process happens with a stateful filtering device like a router or a firewall.


Bob, as he goes out to the untrusted network, on the way out, the stateful firewall is going to remember the state of that session. Was it a TCP SYN request? Was it an echo request? If it was TCP-based, what's going on with the flags? What addresses were used?


What ports were used? And it remembers that. The reason it's remembering that information in the stateful databases is that if the server makes a reply coming back, the router is going to say, well, normally, I don't allow just anybody on the internet to forward traffic into Bob.


However, let me take a look at the stateful database and see if he's expecting any traffic exactly like what you're sending. And based on the stateful database, if the correct reply traffic is coming back, the ports are all correct for what they should be.


The TCP header information is exactly as it should be. The addresses involved are correct. If that all checks out, it's like this guy at the gate saying, go ahead, come back in. And that reply traffic is allowed to come back into Bob. That would be an example of a stateful filtering firewall.


The adaptive security appliance does that by default. However, the iOS router needs to be configured if we want to have it use that functionality. The current method of implementing stateful filtering on iOS router is called the zone-based firewalls.


You may be thinking, zone-based firewalls, that sounds really familiar to me. Why is that? Well, the reason why that may be is we went through that together in the CCNA security course, that 640-554. And specifically, if we go down to videos nine and 10, in video nine we took a look at iOS firewall fundamentals, and then video 10, we took a look at zone-based firewall implementation.


So what I would recommend to do if you have not yet been through CCNA security with me in the videos, or if you haven't seen it for like for six months, I would strongly recommend you pause this video, go jump into 640-554, take a look at videos nine and 10, and then join me back right here so we can take full advantage of that base knowledge that you learn in CCNA security.


One of the secrets for any good security design for either an iOS router acting as a firewall or for the ASA is to identify areas of your network and put them into specific zones. For example, we have here interface 2/0, and we can call that the in zone.


However, we could have like five or six interfaces that were inward-facing, and they could all be part of that in zone. We also have interface 3/0 that we have that's connected to a group of devices. We'll call that the DMZ zone. And then we have Gigabit 0/1 that's connected to the outside world such as the internet and places beyond.


And we can refer to that entire area as the out zone. The basic rules for zone-based firewalls is that interfaces that are in the same zone, by default, they are allowed to forward packets between them. So if we had five or six interfaces here in the in-zone, traffic between any of those five or six interfaces would be allowed.


With iOS 15.x and higher, there's also the ability, if you want to, to restrict traffic within a specific zone. For example, interface six, interface five, we could restrict what traffic is allowed between those in the same zone if you want to. But by default, interfaces that are connected to the same zone from the router's perspective are allowed to freely route packets back and forth based on the routing table with no restrictions.


On the other hand, with zone-based firewalls, any traffic that's trying to go between two interfaces that are in different zones, that traffic is going to be implicitly denied by default. So if we just set up these zones and put these interfaces in those zones, there would be no traffic allowed between the in zone and out zone, or vice versa, or between the DMZ and NE zone.


All traffic between zones is denied by default. There's also a special self zone that refers to the router itself. And by default , any traffic to the self zone or from the self phone-- for example, an SSH session to the router would be traffic going to the self zone-- all that traffic to or from the self zone is allowed by default.


However, if you want to, if we create a zone pair and we include the self as part of that zone pair, we can actually lock down what the router is able to send out as well as what's allowed to come into the router. In my humble opinion, using the self zone is a nightmare and should be avoided.


Because if we want to protect the router, we could use things like Control Plane Policing and Control Plane Protection. Those are much more elegant and easy-to-manage methods of protecting the router itself compared to actually using the self zone as part of zone-based firewalls.


If we look at our checklist, we're going to have zones which we've identified. And then we're going to create a special category of class maps called Inspect Class Maps. They're called Inspect Class Maps because they're used as part of zone-based firewalls-- not to be confused with a normal class map that doesn't have the keyword inspect involved.


For example, we may create a class map that says all traffic. Or we may have a class map that's looking just for HTTP traffic. And from our earlier discussions in this course regarding class maps, the purpose of a class step is to identify traffic. It really on its own power does nothing else except say, hey, that's traffic, and it matches this.


If we actually want to manipulate the traffic, we're going to use a policy map. So we have policy maps, in-zone based firewalls. And there's also a special type called Inspect Policy Maps. Let's say the action for a policy map says, if traffic matches class HTTP, which is this guy right there, then what I want to do is inspect that traffic.


And this action of inspecting is like the person at the gate at the amusement park who is stamping your hand so that when you come back, he can recognize that you've already been here and allow you to come in. For example, if we have Bob right here, and we set up a policy that any traffic going from in to out is going to be inspected, that would mean that on the way out, the router's going to take a look at Bob's traffic, put it in the stateful database, and when the reply traffic comes back from the server he was trying to visit, R1 says, well, normally I don't allow traffic between the out zone and the in zone.


However, because Bob's traffic got its hand stamped, got inspected on the way out, I'm going to dynamically allow that correct reply traffic to go back to Bob. So the secret is with stateful inspection, which is what this Inspect keyword is causing us to do.


If you don't want Bob to go to the internet, you'd better stop him on the way out, or don't inspect his traffic on the way out. Because if you let him go out to the internet and you inspect his traffic dynamically, that reply traffic from the internet is going to come back to Bob.


The next challenge is, how do we train the router that we do want to inspect traffic, for example, that's going from the in zone to the out zone? We do that with something called a zone pair. We might create a zone pair called in to out. We would define that it's traffic sourced from the in zone that's being routed to the out zone.


And when we go into Zone Pair Configuration for this zone pair that reflects in to out traffic, we simply apply the policy map with the service policy command. And if we apply this policy map-- which says, if it's HTTP traffic, I want to go and inspect it-- that's the magic of implementing zone-based firewalls.


And zone pairs are uni-directional. They are one way. For example, we have a zone pair maybe of in to out, or we could have a zone pair of out to DMZ, or a zone pair of in to DMZ. If you want to allow the initial traffic and you want that traffic inspected, you need to create a zone pair based on that initial flow traffic.


For our exercise right here, let's say we want to allow traffic from in to out. And let's say you want to allow all traffic. We're going to create a class map that says anything. We're going to create a policy map that says we want to inspect it. We're going to create a zone pair called in to out, and we're going to apply that policy map to that zone pair so that when Bob goes out to the internet, that traffic is inspected, and the reply traffic is allowed to come back.


This zone pair right here could be called in, to, out, or whatever we want to name it. So there's one zone pair. If we have this DMZ, and we have a web server, and we want people on the outside to be able to reach that web server, we're also going to create another zone pair from out to DMZ.


I'll label this as number two as our second zone pair. And we could call it out to DMZ. The naming convention is really up to you, what you want to call it. But if you name it respective to what it's doing, it'll be easier to see in the Config when you're reviewing all your zone pairs.


And for this zone pair, we might have a class map that says I'm looking for HTTP. And we'll have a policy map that says, if the class map that's looking for HTTP is matched, I want to go ahead and inspect that traffic. The primary purpose of the inspect is to put the entry for that initial traffic in the stateful database so that the reply traffic can come back.


By default, there's no traffic allowed from out to DMZ or from DMZ to out. However, if we create this class map looking for HTTP, we tell the policy map to use that class map. And if it does see HTTP, we tell it to inspect, which also, besides just inspecting the traffic and adding it to stateful database, allows that initial traffic to pass.


The basic actions that we could do on that traffic in a policy map would be inspect, which means put the entry in the stateful database regarding the details of that packet and let it through. There's an option for pass, which says, let the traffic through, but don't put it in the stateful database.


If we have packets that we only want to go in one direction and we weren't expecting a reply to come back for some reason, we could go ahead let it pass. And it would simply let the packet go, and wouldn't inspect it. We could say, I want to drop it.


You have certain traffic that you don't want to allow specifically. You could have a drop action, and there's also a log action as well. Back to our out to DMZ. We would create that zone pair called out to DMZ. We would use a service policy to apply that policy map to that zone pair so HTTP traffic would be allowed from device in the out zone as they tried to reach the DMZ.


And because that traffic is inspected, the reply traffic back from that DMZ server would be allowed back to the client. The other cool thing about it having the DMZ in the zone is that, let's say somebody does compromise our DMZ, and they start trying to attack the world from our DMZ.


Well, this zone doesn't have a zone pair that allows initial traffic to go out to the internet or out to the inside. And as a result, it's pretty much self-contained. The server is in this DMZ as it's currently configured with a zone pair from in to out and a zone pair from out to DMZ.


Because there's no zone pair from DMZ to out, no initial traffic would be allowed from that DMZ from any device to make it out to the internet, which is pretty darn cool. Because there are a lot of commands to implement this zone-based firewall, I'm going to include all the commands that I'm going to do in this demonstration.


I'll put them in a document and I'll make them part of the Nugget files for this course. So if you want to lab this up, you can get that document and follow through step by step with exactly what we did in this video. Our first step is to go into configuration mode, and we're going to create our three security zones.


In, out, and DMZ. Because we need those to go ahead and put the interfaces in, and then use those to create our zone pairs out of as well. We have the in zone identified. We have the out zone identified, and we have the DMZ zone identified. That's a great start.


Next, we'll go ahead into Interface Configuration Mode, and we'll put Gig 1/0 as a member of the security zone called out. And we'll have Interface Gig 2/0 as a member of the security zone called in. One little extra step I'm going to do for interface three 3/0, because I don't know that I've configure it yet as part of this lab.


So I'm going to go ahead and bring it out of a shut-down state if it's not already up, and I'm also going to give it an IP address of as well as tuck it right into the security zone called DMZ. So into interface Gig 3/0 we go with a no shut down.


We'll give the IP address of with a 24-bit mask. And we'll say zone-member security DMZ. Congratulations, Mr. Interface. You are now part of that zone. As of right now, no traffic is allowed between any of these zones by default. So Bob over here is going to have to wait a few minutes until we create the class maps, create the policy maps, create the zone pairs, and then apply the policy to the zone pair so he can then go out to the internet based on the policy we create.


It's important to verify as we go, so let's do a Show Zone Security just to validate what our zones are and that the interfaces are correctly in them. So if I scroll up just a little bit, the command is Show Zone Security, and it is correctly reflecting that each of the interfaces is in its intended zone.


And that's great. Inspect class maps, like regular class maps, have the ability to match on many things. One of those things they can match on is an access control list. To identify all traffic, let's create an access list. We use an access list called in-out-ACL.


And in this access control list, we're simply going to say, permit IP any any. And then in a moment, we'll create an inspect class map that points to that access list that basically is then looking for virtually all traffic. The class map type inspect, which is really important that we add, we have to use the inspect type of class map and the inspect type of policy map.


We're going to call it in-out-class, and we're going to say, please match on that access group that we just created. The reason I edited this match-all is I wanted to point out that there's two options we can use-- match-all or match-any. With a single match statement in our class map, a match-all or a match-any is not going to make any difference, because we only have one entry for matching on.


It's either going to match or it's not. However, if we have two or three or four entries, we want to be very careful if we're using match-all or match-any. If we had four entries and we said match-any, any one of those match statements, if it matches, would cause the class map to go positive with the match.


However, if we had four entries, and we said match-all, and three of them were matching but one was not, the class map as a whole would not be considered a match. So get into the habit when you do a class map type inspect to either explicitly say match-all or match-any based on what you want that class map to match on.


And if we're looking at somebody else's config and we simply want to look at the class map type inspects that exist on that system, we can simply ask it to show us with a Show class-map type inspect. Press Enter. It will show us all the inspect class maps that are on the system.


And in our case, it's the single inspect class map that we just created. Next, we're going to create a policy map. And it's not just any policy map. It's going to be a policy map type inspect that says, hey, I'm looking for traffic matching that class map that we just created.


And if I see traffic that matches that class map, what I'd like to do, says the policy map type inspect, I'd like to inspect the traffic. I'd like to go ahead and put information about that traffic in the stateful database on this zone-based firewall, and let the traffic go through.


And that's what we have happening right here. So our policy map type inspect is called in out policy. And I named it that so I can remember the name of the policy map to apply to the zone pair that we're going to create from in to out. It's calling on the class map that we just created, which is matching on all traffic based on the access list it's looking at.


And if it sees any traffic, it's going to go ahead and inspect it, get the hand stamp, and let Bob's traffic go out to the internet. This won't actually be effective until we create a zone pair and apply this policy map to that zone pair. If we were on a system where we didn't create the policy map type inspects and we wanted to look at what was configured, we could just do a Show, policy-map, type inspect, and it would show us all the policy map type inspects that were configured on the router.


In our case, it's the single policy map type inspect that we just created. Next, we're going to create this zone pair from in to out. And the syntax for this is actually really straightforward. We simply use the command, zone-pair security. The name of it, I'm going to call in-out-ZP.


You say what the source is with the keyword source. You specify the destinations zone with the keyword destination. And poof, we have a zone pair. So if we ever refer to the zone pair called in-out-ZP, it knows it's looking for traffic that's initiated in the in zone and is being routed out to the out zone.


That would represent traffic starting from here and going here. The zone pair all by itself without a policy map applied to it is pretty much worthless. So the final step to making this work is to take that beautiful policy map that we just created, and apply it using the service-policy command, type inspect, and then the name of our policy map.


So service policy is how we apply it. The keywords type inspect are referring to the fact that the policy map we're about to describe is in inspect policy map that's used with zone-based firewalls. And the in-out policy says if I find traffic that matches the in-out class, I'm going to go ahead and inspect it.


Effectively, because the in-out class says everything, any traffic that's sourced from the inside zone going out to the outside down will be inspected and allowed through. And it also implies that reply traffic coming back would be allowed in. Again, if this was a router that we did not configure, and we just want to see what the existing zone pairs are, there's a lot of commands we could issue.


One of them is Show zone-pair security. And that will tell us exactly what zone pairs have been created on this router. It's saying that there's a zone called in-out-ZP. The source is the in zone. The destination is the out zone, and the policy that's applied to it is in-out policy.


So if we went to this PC right now, and we tried to go out to the internet, it should work, presuming we have NAT and all the other details in place to translate the source address of 10.1 into a globally routable address as it goes out. And I do have network address translation operating on this little guy who's R2.


So let's test this. This virtualized XP machine represents this guy right here. And I'm currently at the console in V-Sphere of that XP device. So if we simply did a refresh right here, that's going to cause a lot of network activity to refresh that screen.


The traffic is being initiated right here. It's being routed out. Because that matches the zone pair, the inspect should be done. There should be entries in the stateful database. And because it actually refreshed and worked, that gives me great confidence that it's actually functioning.


A couple other commands that we could issue. One is show policy-map, type inspect, Space, and then the keyword zone-pair. That will give us information on our existing zone pairs. Here's the command show policy-map type inspect zone pair. It says, OK, you've got this zone pair right here called in out.


Here's the policy map that's applied to that zone pair. It's trying to match on this class of traffic called in out class. That class map itself is looking for the access control. It's called in-out ACL, which says permit everything. And if we scroll down, it has more information about that zone pair.


And that's pretty cool information. If we wanted to see more detail about the specific sessions that had been memorized, if you will, by the stateful engine of this zone-based firewall, we can use the command show, policy-map, type inspect, zone-pair, and then you just kick on the extra word of "sessions." And that will give us more information about the existing sessions currently in progress through the zone-based firewall.


If we scroll just a little bit, here's the command. And it's giving us the details about the sessions that are currently in progress. So we have Source port was 1484. It's going out to this server on port 80. And then below it, a whole bunch of additional session information all from that one device at


So that addresses customers on the inside going out with the zone pair and the policy map associated with that zone pair. What about the outside trying to go up to the DMZ? If we want to allow some traffic to go from the outside the DMZ, for example, to the server, we need to create a zone pair.


We need to have a policy map associated with that zone pair that says we're permitting or inspecting that traffic. That policy map would be calling on a class map specifying what type of traffic we're looking for. And so that would be our next step. And for this demonstration, let's say we're just looking for HTTP traffic.


We don't want to allow ICNP. We don't want to allow other types of protocols. Just HTTP between the outside and the DMZ. It's also possible to restrict that based on an access control list where that HTTP would be allowed to go. But for our demo, we'll say if it's HTTP, it's allowed from the outside to anywhere on the DMZ.


Part of the zone-based configuration is going to rely on port maps. If we do a show IP port-map in that pipe and say, only include output that has the word HTTP in it-- and the reason I do that is because of the huge, huge list-- there's a whole bunch of default mappings for well-known services.


For example, HTTP is port 80. HTTPS is port 443, and so forth. So when our class map type inspect that we're going to create to identify HTTP traffic, we don't have to use an access control list to point to port 80. We can just have the class map directly say, I want to match on HTTP.


And it knows that that's TCP destination port 80. So that's saving us a little step of having to create an access list and refer to the access list in the class map. Let's create a class map type inspect. We're going to say match any. Again, if we only have one match, you could say match all or match any.


It doesn't really matter. I just want to reinforce the concept that we need to be careful if you do have multiple matches. We're going to call this class map web-class, and we're simply going to tell it to match on protocol HTTP, which it knows means TCP port 80.


If we were on a new system that we didn't configure and we just want to take a look at any existing class map type inspects that exist, we could do a show, class-map, type inspect. And now we should have two class maps. We have the one we created earlier for traffic going from in to out, and we have this new class map called web-class, which is matching what we're looking for-- just HTTP traffic.


Next-- and this is just the same as it was before-- we're going to create a policy map type inspect. And in that policy map, we'll say, we're looking for traffic that matches the inspect class map called web-class. And if we see that traffic, we want to go ahead and inspect it, which implies putting the information into the stateful database on the firewall or on this router and allowing that traffic to go through to the other zone.


If we're on a new router or router that we didn't configure, we could do a Show policy-map type inspect just to see any existing policy maps that exist. In our case, we have the one we created just a few moments ago, and we have the new web policy map type inspect that we just created.


In order to use this policy map called web policy, we need to go ahead and create a zone pair from outside the DMZ, and then apply that policy with a service policy command to that zone pair. Our first step is to create the zone pair. We'll call it out-DMZ-ZP.


We'll say the source is out, the destination is DMZ. And we'll apply that web-policy policy map with the syntax service desk policy, type inspect, web-policy. And poof, we now have that policy map applied to that zone pair. And now customers on the outside should be able to reach resources on the DMZ from a security perspective, because the zone pair is allowing HTTP access in.


It just so happens that I've got a Windows 2012 server sitting off of interface 3/0. And its IP address is I also have a management computer right here. It happens to be the one that I'm actually recording from. And it has a route through router one, to get to that subnet.


There's also a return path back. What should be able to happen is, from this manifestation, I should be able to open up a browser session to because of the zone pair that exists and that policy map that is inspecting and allowing the traffic to be initiated.


And because my traffic was inspected on the way there by router one, the reply traffic would be allowed back dynamically. Even though there is no zone pair from DMZ to outside, the stateful inspection of the traffic on the inbound trip is going to allow that dynamic return traffic to come back to me.


Let's bring a browser. This is on my management machine right here. And currently I'm at Google. I believe I am live on the real internet. Sure enough, I'm on the live internet. What I'm going to do is go ahead and open up a browser to And that is the IP address of this server on the DMZ.


And we'll go. That was pretty easy. So there's IAS. We have access to it. I'll do refresh a couple times. If we go back to our command line and do a Show zone-pair security, we're going to have information on a couple of zone pairs-- in to out and the out to DMZ.


And if we want to look at the sessions that are involved in those zone pairs, we can do a Show policy-map, type inspect, zone-pair, sessions. And hopefully, our traffic from the outside to that DMZ server is still there. And sure enough, it is. So if we scroll just a little bit, here's our out to DMZ zone pair.


It's got the service policy of web policy attached to it. Web policy is usually in the class map called web class. Looking for HTTP. Number of established sessions, one. And there's my source address. That's my actual workstation, I use port 40,291 to start that session, or at least the one that's being recorded here.


And I was going to, port 80, the well known port for HTTP at that server. And that session is currently open. Up to this point, the zone-based firewall has been focused on layer three and layer four in the OSA reference model. And when I say we should kick it up a notch, I'm literally talking about kicking it up to the application layer.


And here's what I mean by that. These class map type inspects and these policy map type inspects are all about layer three and layer four traffic inspection. However, there's a whole other set of class maps, and a whole other set of policy maps that are special purpose for specific applications.


I'm going to take one of those as an example, and that's HTTP. We can create an HTTP type inspect class map, and we could create an HTTP type inspect policy map. And you might ask, well, what's the benefit? I mean, we already created class maps to identify traffic and policy maps, say what we're going to do, inspect it or drop it or whatever.


What's the benefit of an HTTP class map and an HTTP-specific policy map? And the answer is, these guys in this category can look for specifics in that application. For example, let's say we're looking for a protocol violation of some type in HTTP. So there's some standards in place, normal behavior of how HTTP should operate.


With an HTTP type inspect class map, we can tell it, look for protocol violations, things that are not part of the standard protocol. And that's what that HTTP type inspect class map would look for. We could also tell an HTTP inspect class map to look for a regular expression.


Case in point, let's say we don't want somebody using a browser to go to a website or put in a URL that involves dot com. As I wrote that out, I just realized, that probably wouldn't be a great thing to filter on and restrict. When I wrote dot com, I was thinking of if somebody was trying to run an executable program like a dot EXE or a dot com.


However, if we did create a regular expression that went something like this-- a period plus. The period represents a wild card, any single character, and the plus symbol following it says one or more of the previous characters. So effectively, these two together mean everything's going to match in a regular expression.


This slash right here indicates that the very next character needs to be taken literally. So if we put a dot right here, this dot really does represent a dot. Then if we didn't want to search for com, we could do this. We could say, I want to go ahead and search for upper or lowercase c, and put those in brackets.


Upper or lowercase o, and put that in brackets. And upper or lowercase m, and put that in brackets. So if we included a regular expression as part of an HTTP type inspect class map, and then we told the policy map, OK, go ahead and look for that specific traffic based on the class map, and if you find it, go ahead and do a TCP reset and log the traffic, that would be pretty bad.


Because I bet there's a lot of people who are actually going to be looking for something dot com. I suppose they could do dot gov, and we could go to dot edu and dot net. However, if we're searching for dot com in upper or lowercase, and somebody types that in as a URL, if the HTTP type inspect policy map had been trained to look for a class map that's looking for specifically that, and it's been trained to go do a reset and log, it's going to deny the customer's traffic.


So if we have this zone pair going from out to DMZ, and we attach these special HTTP type inspect policy maps to that zone pair, it can further restrict what the user is allowed to do based on granular inspection of the application layer-- in this case HTTP traffic-- and what's going on at the application layer.


Because we've already validated that I can get from the outside to that DMZ server, let's go ahead and create a regular expression. We'll create a HTTP type inspect class map. We'll link it to an HTTP type inspect policy map. And then we'll apply this new additional policy regarding the HTTP inspection and manipulation.


We'll apply that to our existing zone pair that's going from the outside to the DMZ. And it's almost like an afterthought. We're still going to want to inspect the traffic, but we're going to add on top of it the HTTP policy map to enforce the looking for protocol violations and a certain regular expression.


The first thing I'm going to do is create a parameter map type regular expression. I'm going to collect com. And I am going to put in the pattern of anything followed by dot com in upper or lowercase. It's also possible to do matches on a regular expressions right inside of a class map.


However, in this case, I'm simply creating this regular expression parameter map, and I'll call it from the class map for HTTP. Next, we'll create our class map type inspect HTTP. We're going to say match any, because I am going to have two entries here.


And I'm going to call it bad-HTTP-class. The two entries that we're going to put in-- and it could be three or four-- I'm going to put a match based on that regular expression that we just created. So I'm going to say match space request URI, regex, com, com being the name of that parameter map that we created.


And the second match is going to be based on any type of HTTP protocol violations based on what the zone-based firewall knows to be accepted and OK, functions and actions inside of HTTP. So if somebody is trying to specifically manipulate and change the different types of command instead of HTTP, if it doesn't jive with what the zone-based firewall thinks is OK, that would cause this class map type inspect for HTTP called bad-HTTP-class to fire off positive.


This is a match. If we were on somebody else's system, we hadn't created these special type of HTTP class maps, there's a Show command that we can use to see all these special types of class maps. Show, class-map type inspect HTTP. And that will show us literally any HTTP-specific class maps that exist on the box.


And there's the single one that we created. That's great news. Next, we're going to create a policy-map type inspect for HTTP. And I'm going to call it bad-HTTP-policy. And in this policy, I'm going to say, I'm looking for traffic that matches the class type inspect HTTP bad-HTTP-class.


That's the special HTTP class we just created. So effectively, this policy map, when applied, is going to go ahead and be looking for protocol violations or anything that has dot com in the URL. Now the question, says this policy map, is what should I do with this traffic if I do identify it and see it based on the class map matching.


And we can control that right here. Let's go ahead and say that we want to log that traffic, and we want to send a TCP reset. Because it's really important to be able to get information out of the box, if we hadn't yet created any type of HTTP type inspect policy maps or were on a different system, we can issue the command Show policy-map, type inspect, HTTP, and it will show us any existing HTTP type inspect policy maps.


Here's the one that we just created. It's specifying that the class of traffic it's looking for is bad-HTTP-class. And if it sees that traffic, it's going to generate a log message, and it's going to send a TCP reset. For some people, the tricky part is, how do we get this HTTP type inspect policy map integrated with our existing policy that's applied to the zone pair from out to DMZ?


And the first part of it is just like it was previously. Earlier, we did policy-map, type inspect, web policy, class type, inspect, web class, and inspect. These commands right here are identical to what we did previously when we originally set up the policy map from out to DMZ.


We set up traffic matches web class, which is matching on HTTP. Then we're going to go ahead and inspect that traffic. However, the secret is we're going use the service-policy command right here in this policy map, and we're going to apply the special HTTP policy map as a child or subsection, if you will, of the first policy map.


Using the command service-policy, HTTP, and the name of our HTTP type inspect policy map, that's how we inject it. So it's this normal-- I'll call it normal-- layer 3/4 type inspect policy map that's applied to the zone pair. And this policy map, which is our special HTTP type inspect-- I refer to it as a layer seven policy map-- that is now married to this policy map that's applied to the zone pair.


So when the zone pair has this web policy applied to it, it's also getting as part of that this layer seven policy, which is specific to HTTP. Again, I've got the full configs of what we've done together in this demo available for you as part of the Nugget lab files for this course.


Our next step is to try it out. This browser represents my management computer, which is at And let's do a refresh a couple of times. Let me also go to a bogus URL. There's a bogus URL. And this message is from the server back to me saying, I don't have a folder or file by that name.


Your fishing up the wrong string. Just to confirm that we still have some connectivity, let me go back to the main website at That works. But let's type in dot com at the end. So we'll go ahead and do a game dot com. I'm super excited to see if it's going to work or not.


What should happen is, when that request in this URL goes through the firewall because of the HTTP inspection, which is looking for one of two things-- HTTP protocol violations, which from a normal browser may be difficult to generate-- or, the other thing it's looking for is anything with a dot com in the URL.


And game dot com certainly will match on that. So let's go ahead and press Enter. And we have a message saying this page cannot be displayed. On the background, the really great news is that we have a log message as well. It's saying that the application firewall-- this is a level four message-- it's saying the HTTP URA reg-ex matched.


Here is the actual regular expression that it matched. And it sent a TCP reset to my IP address, which is The traffic was destined-- if it made it, which it didn't-- to on port 80. The layer 3/4 class map involved was web class, and the application layer class map that actually caught what we were doing with the dot com was called bad-HTTP-class.


That message is not only on our console, but if we're also sending log messages to our SYS log servers or SNMP traps, those messages are also at those locations as well. The action items that I would strongly recommend from the zone-based firewalls is three things.


Number one, I recommend going back to 640-554, which is the CCNA security. And I would review videos number nine and 10, because they deal with some of the history and evolution of zone-based firewalls on Cisco routers, and it also gives a slightly different perspective on implementing the zone-based firewall.


So that's number one. I would recommend you review those two videos. Number two, I would recommend that you practice in a test environment, setting out basic zone-based firewalls. And the third thing I'd recommend is I would take my notes that I've included in the Nugget lab files which says step by step all the configuration commands and all the verification commands that we did together in the video.


And those might come in really, really handy as you do your practice and your verification of implementing zone-based firewalls. And to practice this, you're going to want to have some emulation services like GNS3 or Live Gear. Either way is great. If you have a simulator, it's not very likely that the simulator is going to get everything right regarding zone-based firewalls.


And that's where the live gear or using a live iOS in GNS3 will be very helpful, because it'll give you real results based on real iOS. I have had a great time with you in this video. I'm so glad you joined me for it. I hope this has been informative for you.


I'd like to thank you for viewing.


Best Practices



ASA Packet Capture

Botnet Filtering

Context Directory Agent

Security Virtualization and IPS

Management Tools

IPv6 Security

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
Advanced 10 hrs 27 videos


Training Features

Practice Exams
These practice tests help you review your knowledge and prepare you for exams.

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

Offline Training
Our iOS and Android mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching
Develop and maintain a study plan with one-to-one assistance from coaches.

Supplemental Files
Files/materials that supplement the video training.

Speed Control
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Follow what the trainers are saying with ease.
Keith Barker
Nugget trainer since 2012