|
0:00:13
|
In our next section here we are going to talk about the zone based policy firewall configuration
|
|
0:00:19
|
and what are the individual pieces that are going to be built together
|
|
0:00:22
|
in order to get the final functional configuration
|
|
0:00:25
|
then we will look at some example of this on the command line interface
|
|
0:00:29
|
and to see how do we actually
|
|
0:00:31
|
configure and verify that the policy is actually working
|
|
0:00:35
|
Now the configuration overall
|
|
0:00:37
|
we can break this down into six separate steps
|
|
0:00:40
|
where the first of which is going to be to define what are the zones
|
|
0:00:45
|
specifically this is with the zone security command
|
|
0:00:48
|
this is where we would define what is the inside zone
|
|
0:00:52
|
the outside zone, DMZ
|
|
0:00:54
|
this is just where we are giving them names
|
|
0:00:58
|
next step we would define what is the type of traffic
|
|
0:01:02
|
that we want to match in one of our policies
|
|
0:01:05
|
just like the Modular Quality Service again
|
|
0:01:07
|
this is going to be done with the class map
|
|
0:01:10
|
So with our class map type inspect this is where we would say, match web traffic, match ftp traffic, match telnet traffic etc.
|
|
0:01:19
|
Once we know what the particular type of traffic we want is
|
|
0:01:23
|
then we are going to define our filtering policy
|
|
0:01:25
|
which is done with the policy map of type inspect
|
|
0:01:29
|
from inside the policy, this is where we would be referencing the class map
|
|
0:01:33
|
and then specifying what is the action
|
|
0:01:36
|
So do we want to inspect the traffic
|
|
0:01:39
|
do we want to drop the traffic and generate a log message
|
|
0:01:42
|
do we want to police the traffic
|
|
0:01:44
|
or do we want to call in more specific
|
|
0:01:47
|
application level inspection
|
|
0:01:50
|
which is then defined in a layer 7
|
|
0:01:53
|
class map and policy map
|
|
0:01:56
|
but in this example we will look at just the basic layer3, layer4 class maps
|
|
0:02:00
|
and policies, then we will come back later and look at the application specific
|
|
0:02:05
|
inspections
|
|
0:02:07
|
So now we know what are the zones
|
|
0:02:09
|
whats the type of traffic, whats the policy we want to apply under the traffic
|
|
0:02:14
|
next would be to define
|
|
0:02:16
|
how are the zones going to be associated with each other
|
|
0:02:19
|
or what is the zone pairing
|
|
0:02:21
|
this is where we would say
|
|
0:02:23
|
I have a zone pair security
|
|
0:02:25
|
that is for inside to outside flows
|
|
0:02:28
|
or from outside to the DMZ
|
|
0:02:32
|
once we define what the pairing is
|
|
0:02:35
|
then we actually apply a policy
|
|
0:02:38
|
which just like again like the Modular Quality of Service is going to be with the service policy command
|
|
0:02:45
|
Now the key point that is different here
|
|
0:02:48
|
again between the content based access control and the zone based policy firewall
|
|
0:02:53
|
is that since we are applying the service policy to the zone pairing
|
|
0:02:58
|
we are de coupling it from the actual interface assignment
|
|
0:03:02
|
this would then bring us to our final step
|
|
0:03:04
|
which is to actually apply the zones to the interfaces
|
|
0:03:07
|
which is with the zone member security
|
|
0:03:15
|
is that since the service policy is applied to the zone pairing
|
|
0:03:19
|
the zone pairing is calling different zone security like inside or outside
|
|
0:03:23
|
it means that if I want to add an additional outside interface later
|
|
0:03:28
|
the only thing I need to do is the very last step
|
|
0:03:31
|
which is to assign the zone to the interface
|
|
0:03:34
|
then its automatically going to inherit
|
|
0:03:37
|
whatever the service policy that is applied
|
|
0:03:39
|
particular zone pairing is
|
|
0:03:42
|
So lets take a look at our topology here
|
|
0:03:45
|
and in this particular example, we are going to be applying the zone based policy firewall on router3
|
|
0:03:52
|
where we have three different interfaces
|
|
0:03:54
|
and likewise we are going to have three different zones
|
|
0:03:57
|
where router3's connection to router4, this is going to be
|
|
0:04:01
|
inside zone
|
|
0:04:03
|
the connection on vlan 192 to back on to this is going to be the DMZ
|
|
0:04:10
|
and the frame relay linked to router2, this is going to be considered the outside zone
|
|
0:04:17
|
Now the overall logic of the inspection
|
|
0:04:20
|
is that we want to watch the traffic
|
|
0:04:22
|
as it is moving from the inside to the outside network
|
|
0:04:26
|
then selectively choose what is going to return from the outside back in
|
|
0:04:32
|
then likewise we are going from the inside to the DMZ
|
|
0:04:37
|
and the DMZ's traffic is returning
|
|
0:04:39
|
and from the outside to the DMZ and returning
|
|
0:04:46
|
So once we are done, we are going to have three separate zone pairings
|
|
0:04:50
|
which are going to be calling three separate policies
|
|
0:04:52
|
the first of which is going to be the in
|
|
0:04:55
|
to out pairing
|
|
0:04:58
|
we will then have the in to DMZ pairing
|
|
0:05:03
|
and lastly the out to DMZ pairing
|
|
0:05:08
|
where on the DMZ we are assuming this is where we would be hosting our public services
|
|
0:05:12
|
like our public web server our public mail server
|
|
0:05:15
|
So that we want to make sure that device is on the trusted network on the inside
|
|
0:05:19
|
and the untrusted network on the outside are able to reach them
|
|
0:05:24
|
Now for any other pairing
|
|
0:05:27
|
that we do not manually configure
|
|
0:05:30
|
which in this case would be DMZ
|
|
0:05:33
|
inside
|
|
0:05:35
|
or from DMZ
|
|
0:05:37
|
to outside
|
|
0:05:39
|
since we are not going to manually define this
|
|
0:05:42
|
it means that this traffic is automatically going to be dropped
|
|
0:05:47
|
where again for any intra zone communication
|
|
0:05:51
|
so from one zone to a separate zone
|
|
0:05:54
|
the traffic is only going to be allowed, if we have a manual policy defined
|
|
0:05:59
|
which is telling us exactly how we are going to process the traffic
|
|
0:06:02
|
So are we inspecting it, are passing it, are we policing it etc
|
|
0:06:07
|
So next lets look at the command line
|
|
0:06:10
|
and before we actually apply any of the inspections or any of the zone based firewall configuration
|
|
0:06:16
|
lets make sure that without any of the firewall filtering
|
|
0:06:19
|
we have basic reachability throughout the network
|
|
0:06:23
|
So if we were to look at router3
|
|
0:06:25
|
and lets look at the show ip interface brief
|
|
0:06:29
|
I just want to make sure that there is nothing wrong with the basic connected segments
|
|
0:06:33
|
where I should be able to reach on the inside network
|
|
0:06:36
|
router4 which is 172.16.34.4
|
|
0:06:40
|
on the outside network, I have the connection to router2
|
|
0:06:43
|
which is 200.0.23.2
|
|
0:06:47
|
then on the vlan 192 segment
|
|
0:06:50
|
I have the connection to the DMZ which is going to be 192.10.9.254
|
|
0:06:58
|
additionally if we look at the routing table
|
|
0:07:01
|
we have routes that have been learned from the outside network
|
|
0:07:05
|
which is running ospf, I have routes that have been learned from the
|
|
0:07:10
|
inside network
|
|
0:07:12
|
which is eigrp
|
|
0:07:13
|
and then separate routes that are being learned from the DMZ
|
|
0:07:18
|
which likewise is OSPF
|
|
0:07:22
|
Now if we were to go to the router4 who is on the inside
|
|
0:07:25
|
and look at the routing table here
|
|
0:07:27
|
I should be able to reach any of those devices that are on the
|
|
0:07:30
|
outside or on the DMZ
|
|
0:07:33
|
So for example if I were to telnet
|
|
0:07:35
|
to router2's address
|
|
0:07:39
|
we can see that we do have connectivity
|
|
0:07:41
|
likewise if I were to telnet to the
|
|
0:07:44
|
the BB2 router which is on the DMZ
|
|
0:07:49
|
we can see that there is no problem with the traffic flows
|
|
0:07:52
|
likewise if I were to ping router2
|
|
0:07:58
|
or I were to ping BB2
|
|
0:08:00
|
which is 192.10.9.254
|
|
0:08:04
|
we can see that none of the flows are being filtered
|
|
0:08:07
|
likewise if I were to go to the outside
|
|
0:08:10
|
if I were to go to router2 and ping
|
|
0:08:12
|
172.16.34.4
|
|
0:08:16
|
which is router4's address
|
|
0:08:18
|
or if I were to
|
|
0:08:19
|
to telnet to this
|
|
0:08:23
|
this is telling us
|
|
0:08:24
|
with basic connectivity to start
|
|
0:08:26
|
there is nothing being filtered
|
|
0:08:28
|
on any of the traffic flows
|
|
0:08:31
|
Now once our configuration is complete
|
|
0:08:34
|
what we should see is that these outside to inside flows
|
|
0:08:38
|
like router1 pinging router4
|
|
0:08:41
|
this should be denied
|
|
0:08:44
|
Now likewise if I were to go to BB2
|
|
0:08:48
|
from BB2 if I were to ping
|
|
0:08:51
|
router4 172.16.34.4
|
|
0:08:58
|
or if I were to ping router2
|
|
0:09:00
|
200.0.0.2
|
|
0:09:02
|
I could see that both of these flows are allowed
|
|
0:09:05
|
so once our filtering is complete, the DMZ traffic to the inside
|
|
0:09:10
|
which would be this flow
|
|
0:09:11
|
or the DMZ traffic to the outside
|
|
0:09:14
|
this is going to be denied
|
|
0:09:15
|
unless we have a manual zone pairing between the zones
|
|
0:09:20
|
that is saying these individual flows are allowed or they are inspected
|
|
0:09:27
|
So now on router3, again our first step
|
|
0:09:30
|
of the six step process is going to be to define the zones
|
|
0:09:35
|
So in global config, we will have the zone security
|
|
0:09:38
|
and define the names, I will say these are inside
|
|
0:09:42
|
outside
|
|
0:09:47
|
outside and DMZ
|
|
0:09:49
|
where under this zone security sub configuration mode
|
|
0:09:53
|
pretty much the only thing that you will do here is just specify the description
|
|
0:09:57
|
so I will say description public
|
|
0:10:00
|
web servers is the DMZ
|
|
0:10:06
|
Next step is that we are going to define
|
|
0:10:08
|
what are the different traffic flows
|
|
0:10:11
|
that we would want to inspect
|
|
0:10:14
|
Now there is a couple of different ways that you could piece this logic together
|
|
0:10:18
|
we can have a single class map
|
|
0:10:20
|
that is matching multiple flows
|
|
0:10:23
|
or we could have individual class maps
|
|
0:10:25
|
class maps that are calling individual that are calling individual flows
|
|
0:10:28
|
really it simply depends on how much that do we want to keep the configuration
|
|
0:10:33
|
So in this case I am going to start with doing just a single class map
|
|
0:10:38
|
that is matching the overall flows that I want
|
|
0:10:41
|
and if we want to later, we can come back and change this
|
|
0:10:44
|
depending on the class map definitions and the
|
|
0:10:46
|
policy map definitions
|
|
0:10:49
|
Now the key point here though is going to be
|
|
0:10:52
|
that if we want to keep our configuration
|
|
0:10:55
|
manageable afterwards
|
|
0:10:57
|
we want to make sure that the names of the class maps
|
|
0:11:00
|
of the policy maps, of the access lists, of the zones
|
|
0:11:04
|
we want them to be as descriptive as possible
|
|
0:11:07
|
so that just by looking at the running config
|
|
0:11:09
|
or the show
|
|
0:11:11
|
service policy for the zone pair
|
|
0:11:13
|
we can pretty much tell exactly what we are trying to do
|
|
0:11:17
|
and now the that I am going to do this
|
|
0:11:19
|
is by naming the class maps
|
|
0:11:21
|
which are of type inspect
|
|
0:11:24
|
I will say that this is going to be the
|
|
0:11:26
|
inside to outside class
|
|
0:11:32
|
Now from in here, we are going to call
|
|
0:11:34
|
what are the type of traffic flows
|
|
0:11:35
|
that we want to allow from the inside to the outside
|
|
0:11:39
|
and again generally there is going to be
|
|
0:11:41
|
two different matches that we would do here
|
|
0:11:43
|
we would say generally match an access group
|
|
0:11:46
|
or match a protocol
|
|
0:11:49
|
where we could see additionally that we could nest multiple classes together
|
|
0:11:54
|
we want to reference one class map from another one
|
|
0:11:56
|
this user group here
|
|
0:11:59
|
this is for
|
|
0:12:00
|
things like 802.1x authentication
|
|
0:12:04
|
where from the AAA server
|
|
0:12:06
|
when a user authenticates
|
|
0:12:08
|
with something like .1x, or something like authentication proxy
|
|
0:12:12
|
we got to assign them to a user group
|
|
0:12:14
|
which would allow them to essentially have
|
|
0:12:16
|
authentication based firewalls
|
|
0:12:20
|
So depending on what particular user logging into the network
|
|
0:12:22
|
we are going to give them access to different
|
|
0:12:24
|
types of applications
|
|
0:12:27
|
So in our case here, lets say match protocol
|
|
0:12:30
|
and we could see that not only do we have basic layer3
|
|
0:12:33
|
or layer4 matches
|
|
0:12:35
|
like BGP would be saying match TCP port 179
|
|
0:12:39
|
but we also have some of these application
|
|
0:12:41
|
level matches
|
|
0:12:42
|
like bit torrent
|
|
0:12:44
|
or AOL instant messenger
|
|
0:12:47
|
that is going to be calling
|
|
0:12:48
|
more information inside of the
|
|
0:12:50
|
payload than just the layer3 or the layer4 header
|
|
0:12:55
|
so here just for basic testing from the
|
|
0:12:57
|
inside to the outside
|
|
0:13:00
|
I am going to say that we want to allow telnet
|
|
0:13:03
|
and we want to allow
|
|
0:13:05
|
ICMP
|
|
0:13:09
|
So these are going to be our basic
|
|
0:13:11
|
telnet flows and our basic ping
|
|
0:13:15
|
Now if we look at the result of this
|
|
0:13:16
|
we show run section
|
|
0:13:18
|
class map
|
|
0:13:21
|
we can see that the default
|
|
0:13:22
|
action
|
|
0:13:25
|
for the match logic is match
|
|
0:13:27
|
all for the class
|
|
0:13:30
|
Now on this case this is not going to work for us
|
|
0:13:32
|
because it doesn't make sense
|
|
0:13:33
|
that a packet is going to be both telnet
|
|
0:13:35
|
and ICMP at the same time
|
|
0:13:39
|
So if I were to have a general
|
|
0:13:40
|
class that is matching multiple options
|
|
0:13:43
|
most of the time I am going to need
|
|
0:13:44
|
to change this so that it says match any
|
|
0:13:46
|
as opposed to match all
|
|
0:13:50
|
so lets remove this class
|
|
0:13:53
|
and we are going to rebuild it
|
|
0:13:56
|
we will say class map
|
|
0:13:57
|
type inspect match any
|
|
0:14:00
|
inside to outside class
|
|
0:14:02
|
where I still going to match the telnet and the ICMP flows
|
|
0:14:07
|
So essentially now its saying either, or, its either telnet or its ICMP
|
|
0:14:12
|
So now we know what is the traffic that we are trying to match
|
|
0:14:15
|
next thing we need to do is figure out what do we actually want to do with this
|
|
0:14:19
|
this what the
|
|
0:14:20
|
policy map type inspect is going to be used for
|
|
0:14:25
|
So policy map type inspect
|
|
0:14:28
|
and we could see just like the previous
|
|
0:14:30
|
class maps
|
|
0:14:31
|
if I want to say class map type inspect
|
|
0:14:34
|
there are individual classes
|
|
0:14:37
|
and individual policies
|
|
0:14:39
|
that are going to be calling separate
|
|
0:14:41
|
CBAC inspection engine
|
|
0:14:43
|
where for example one of them is
|
|
0:14:45
|
for web traffic
|
|
0:14:47
|
another one we have is
|
|
0:14:49
|
for get mail with POP3
|
|
0:14:51
|
or getmail with imap
|
|
0:14:54
|
another one would be for sendmail with SMTP
|
|
0:14:59
|
So for the normal layer3 layer4 class maps and policy maps
|
|
0:15:04
|
this is where we are simply saying
|
|
0:15:06
|
policy map type inspect
|
|
0:15:07
|
and then giving it a name
|
|
0:15:09
|
or class map type inspect and then giving it a name
|
|
0:15:13
|
if I wanted to
|
|
0:15:14
|
If I wanted to do a web
|
|
0:15:16
|
specific application inspection
|
|
0:15:18
|
I would need to create a class map type inspect of http
|
|
0:15:23
|
call whatever specific
|
|
0:15:24
|
http options I wanted
|
|
0:15:26
|
then reference this from a policy map type inspect that was http
|
|
0:15:33
|
So again we will come back later
|
|
0:15:36
|
to talk about the application specific matches
|
|
0:15:38
|
but in this case we are just doing just a basic layer3 layer4 policy
|
|
0:15:43
|
So we will say policy map type inspect
|
|
0:15:46
|
this is going to be the inside
|
|
0:15:49
|
to outside
|
|
0:15:50
|
policy
|
|
0:15:52
|
So just like I named the previous class, the inside to outside class
|
|
0:15:56
|
the inside to outside policy
|
|
0:15:59
|
is then going to be called from the
|
|
0:16:01
|
inside to outside pairing
|
|
0:16:04
|
where the inside to outside pairing is going to be the association of the inside traffic going to the outside
|
|
0:16:11
|
where I could say a policy map type inspect 1
|
|
0:16:14
|
or policy map type inspect policy 1
|
|
0:16:17
|
but the problem is there
|
|
0:16:19
|
since you can't really tell just based on the name what you are trying to do
|
|
0:16:23
|
its going to make the configuration a little bit more difficult to read
|
|
0:16:27
|
versus what I am doing here
|
|
0:16:31
|
So now from out policy map type inspect
|
|
0:16:34
|
this is where we are going to reference the classes
|
|
0:16:37
|
where it says
|
|
0:16:38
|
you could either call the class map name
|
|
0:16:41
|
call the class default
|
|
0:16:44
|
or call a class that is in type inspect
|
|
0:16:47
|
this would be for calling the application level matches
|
|
0:16:52
|
where in our case, we are not doing application matching, we are just doing layer3, layer4
|
|
0:16:57
|
so the class
|
|
0:16:59
|
is going to be the inside to outside class
|
|
0:17:06
|
Now if these matches are true
|
|
0:17:08
|
which again are either the telnet
|
|
0:17:10
|
or the ICMP flows
|
|
0:17:12
|
what do I want to do with it
|
|
0:17:14
|
Do I want to inspect the traffic
|
|
0:17:17
|
which would allow it to go from the inside to the outside and then return
|
|
0:17:22
|
do I want to simply deny the packets with a drop
|
|
0:17:26
|
Do I want to manually allow them through without inspecting them
|
|
0:17:31
|
Do I want to police the traffic, so limit it to a specific rate
|
|
0:17:35
|
or call another service policy
|
|
0:17:38
|
which would then be for our layer7 policy maps
|
|
0:17:44
|
So for here I want to allow this traffic, so I am going to inspect it
|
|
0:17:50
|
Now if we look at the result of this, lets
|
|
0:17:52
|
just look at the show run
|
|
0:17:57
|
we have the zone definitions
|
|
0:18:00
|
So inside, outside and DMZ
|
|
0:18:03
|
we have the traffic that is going to match
|
|
0:18:05
|
from the inside to the outside
|
|
0:18:08
|
and we have the policy that is going to be applied from the inside to the outside
|
|
0:18:12
|
inside outside policy says that if this traffic class is true
|
|
0:18:16
|
then I am going to inspect
|
|
0:18:19
|
those flows
|
|
0:18:23
|
Next thing we would need to do
|
|
0:18:24
|
is create the association
|
|
0:18:26
|
or the pairing from the inside to the outside
|
|
0:18:30
|
this is going to be with the
|
|
0:18:33
|
zone pair
|
|
0:18:34
|
security
|
|
0:18:36
|
and in the pairings name
|
|
0:18:38
|
Hey, just like the other
|
|
0:18:39
|
configurations I want to make this as descriptive as possible
|
|
0:18:42
|
So I will say this is the inside to outside
|
|
0:18:45
|
pairing
|
|
0:18:48
|
the source of traffic is going to be from the inside zone
|
|
0:18:52
|
the destination of the traffic is going to be the outside zone
|
|
0:18:58
|
So traffic is moving from inside to outside
|
|
0:19:00
|
I want to then call
|
|
0:19:02
|
the service policy
|
|
0:19:05
|
which is the service policy type inspect
|
|
0:19:08
|
that I previously created
|
|
0:19:11
|
which was called our inside to outside policy
|
|
0:19:24
|
So again now the zone pairing is the association
|
|
0:19:27
|
of the traffic flows between the interfaces
|
|
0:19:30
|
if any thing comes from an interface
|
|
0:19:32
|
an interface that is assigned to the inside zone
|
|
0:19:35
|
and it goes through the outside zone
|
|
0:19:38
|
then we are going to call the policy - inside to outside policy
|
|
0:19:43
|
then our final step would be to actually apply these to the interfaces
|
|
0:19:47
|
where again in our particular case
|
|
0:19:50
|
the inside zone
|
|
0:19:53
|
is going to be applied on
|
|
0:19:58
|
router3's fast ethernet0/1
|
|
0:20:02
|
this is the inside zone
|
|
0:20:06
|
the outside zone is going to be on this
|
|
0:20:08
|
serial sub interface for frame relay
|
|
0:20:11
|
thats the outside
|
|
0:20:17
|
So lets go to our first interface fast ethernet0/1 will say that the zone membership
|
|
0:20:23
|
is zone member security and this is the inside zone
|
|
0:20:28
|
then if we look at the serial sub interface which is serial1/0.23
|
|
0:20:34
|
the zone level security is the outside zone
|
|
0:20:41
|
Now once these are applied
|
|
0:20:44
|
and we go to test the actual traffic flows
|
|
0:20:47
|
we need to look at the equivalent
|
|
0:20:49
|
of what would be the show
|
|
0:20:51
|
ip inspect sessions
|
|
0:20:55
|
or again show ip inspect sessions
|
|
0:20:57
|
is for content based access control
|
|
0:20:59
|
to show us exactly what are the flows that are moving between interfaces
|
|
0:21:03
|
and are they being allowed or are they being denied
|
|
0:21:07
|
with the zone based firewall the syntax is a little bit more complex here
|
|
0:21:11
|
we need to say show
|
|
0:21:16
|
first we can say show zone security
|
|
0:21:19
|
this is where they show what are the defined zones
|
|
0:21:23
|
or we have the user defined zones plus the self zone
|
|
0:21:27
|
which again is for the locally originated or locally destined traffic
|
|
0:21:32
|
we have the show zone pairing
|
|
0:21:36
|
show zone pair security
|
|
0:21:39
|
where the pairing from the inside to the outside that is calling the inside to outside policy
|
|
0:21:45
|
then the
|
|
0:21:48
|
show policy map
|
|
0:21:51
|
type inspect zone pair
|
|
0:21:55
|
where this shows me
|
|
0:21:58
|
the equivalent to the show policy map interface from the Modular Quality of Service
|
|
0:22:03
|
So it says I have the policy that is called the inside to outside policy
|
|
0:22:09
|
that is called from the pairing, inside to outside pairing
|
|
0:22:13
|
inside this policy I have the inside to outside class
|
|
0:22:16
|
that is calling either the telnet or the ICMP flows
|
|
0:22:20
|
I am inspecting them
|
|
0:22:23
|
I then additionally have my class default which says for any other flows those are going to be dropped
|
|
0:22:31
|
So again the show policy map type inspect zone pair
|
|
0:22:34
|
this is going to show us the packet couters
|
|
0:22:37
|
if we want to see the actual sessions
|
|
0:22:40
|
we need to say show policy map type inspect zone pair sessions
|
|
0:22:45
|
this will show us the actual flows in real time as they are moving through the interfaces
|
|
0:22:53
|
So now lets actually test this, lets go to the inside
|
|
0:22:56
|
which is router4
|
|
0:22:58
|
and we should see that the pings
|
|
0:23:00
|
the ICMP ping should be able to go from the inside to the outside and then return
|
|
0:23:06
|
likewise for any telnet flows that go from inside to outside and then return
|
|
0:23:12
|
but anything that is originated on router2 on the outside going back in, this is going to be denied
|
|
0:23:19
|
likewise anything that is going from the outside
|
|
0:23:22
|
to the DMZ
|
|
0:23:25
|
or from the inside to the DMZ
|
|
0:23:28
|
because we did not specifically defined a zone pairing
|
|
0:23:32
|
and a policy for the zone
|
|
0:23:37
|
because again remember the inter zone communication like inside to DMZ, inside to outside
|
|
0:23:43
|
that is going to be dropped by default, that is denied
|
|
0:23:46
|
it is only going to be allowed if we manually define the policy map
|
|
0:23:50
|
and then apply it as the inspection on to that particular pairing
|
|
0:23:58
|
So again from router4 on the inside
|
|
0:24:00
|
if we were to do the ping to router2 this should be allowed
|
|
0:24:06
|
if we were to ping to the DMZ though, this is going to be denied
|
|
0:24:11
|
because I don't have a specific
|
|
0:24:13
|
inside to DMZ pairing
|
|
0:24:19
|
Now if I continue to send this pings
|
|
0:24:22
|
from the inside to the outside
|
|
0:24:24
|
then go to router2
|
|
0:24:26
|
excuse me router3 and look at the
|
|
0:24:28
|
the show policy map type inspect zone pair sessions
|
|
0:24:32
|
we will see specifically from the inside to the outside
|
|
0:24:36
|
I have an inspection that is from router4
|
|
0:24:39
|
going to router2
|
|
0:24:40
|
its an echo request
|
|
0:24:42
|
which means that the router is
|
|
0:24:44
|
assuming that an echo reply is going to come back in
|
|
0:24:49
|
Now likewise if we were to try to telnet to router2
|
|
0:24:55
|
to 200.0.0.2
|
|
0:24:58
|
this should be allowed
|
|
0:25:06
|
On router3, if we look at the show
|
|
0:25:07
|
policy map type inspect zone pair sessions
|
|
0:25:11
|
it says that there is a TCP
|
|
0:25:13
|
connection that is telnet
|
|
0:25:15
|
So its using port 23
|
|
0:25:17
|
its coming from router4
|
|
0:25:19
|
going to router2
|
|
0:25:24
|
Now we could see nothing has now matched the class default
|
|
0:25:28
|
because the only two traffic flows that I have tried
|
|
0:25:30
|
with the two that we were inspecting
|
|
0:25:33
|
if I were to try to go to router4
|
|
0:25:36
|
and lets say we telnet
|
|
0:25:38
|
to router2 at port 80
|
|
0:25:41
|
this is then going to hit the class default
|
|
0:25:45
|
and these packets are denied
|
|
0:25:48
|
So again essentially anything else that I not
|
|
0:25:51
|
already inspecting, thats going to be dropped
|
|
0:25:55
|
If we are to go to the reverse direction, go to router2 and try to ping router4
|
|
0:26:01
|
or try to telnet to router4, those packets are going to be dropped
|
|
0:26:06
|
and again the reason why when we look at the
|
|
0:26:09
|
the show zone pair security
|
|
0:26:11
|
we only have a pairing from the inside to the outside
|
|
0:26:16
|
we don't have a pairing from the outside back to the inside
|
|
0:26:20
|
So lets like look at our final configuration now for this
|
|
0:26:27
|
So again we have our three different zone definitions - inside, outside and DMZ
|
|
0:26:31
|
We have a class map that is saying match telnet and ICMP
|
|
0:26:35
|
that is the inside to outside class
|
|
0:26:39
|
inside to outside class is reference from the inside to outside policy
|
|
0:26:42
|
that says these flows will be inspected
|
|
0:26:45
|
everything else is going to be dropped
|
|
0:26:48
|
then we have our pairing, which is the inside to outside pairing
|
|
0:26:52
|
says if traffic comes from the inside and goes out
|
|
0:26:55
|
we are going to use this policy
|
|
0:26:58
|
then lastly on the LAN interface fast ethernet 0/1, this is on the inside zone
|
|
0:27:04
|
and WAN interface, the frame relay is on the outside zone
|
|
0:27:09
|
which again is the final result of this is that from the inside
|
|
0:27:13
|
we can telnet to the outside
|
|
0:27:17
|
we can ping to the outside
|
|
0:27:21
|
but we cannot ping from the inside to the DMZ
|
|
0:27:27
|
from the DMZ
|
|
0:27:29
|
we cannot send traffic to the inside
|
|
0:27:38
|
where router4 again is 172.16.34.4
|
|
0:27:46
|
so we cannot get from the DMZ to the inside
|
|
0:27:48
|
and then likewise we cannot get from the outside to the inside
|
|
0:27:57
|
So now lets say we want to add a little bit more detail to this policy
|
|
0:28:01
|
where again we have the three different zones, we have the inside
|
|
0:28:05
|
we have the outside
|
|
0:28:08
|
and we have the DMZ
|
|
0:28:11
|
what I now want to allow, is
|
|
0:28:14
|
what we are previously matching which is the pings
|
|
0:28:16
|
and the telnet
|
|
0:28:18
|
So ICMP and telnet
|
|
0:28:22
|
and this is going to go from the inside to the outside
|
|
0:28:26
|
then from the inside to the DMZ
|
|
0:28:30
|
and from the outside to the DMZ
|
|
0:28:34
|
I want people to be able to telnet
|
|
0:28:37
|
but specifically just to
|
|
0:28:41
|
BB2's address
|
|
0:28:42
|
which is 192.10.9.254
|
|
0:28:49
|
traffic is not going to be allowed from the DMZ out, from the DMZ in
|
|
0:28:55
|
then finally we are going to look at filtering traffic, that is going to
|
|
0:28:58
|
or coming from router3 itself
|
|
0:29:03
|
where on the outside interface
|
|
0:29:06
|
router3 is running OSPF
|
|
0:29:09
|
as is on the DMZ
|
|
0:29:12
|
on the inside interface we are running EIGRP
|
|
0:29:17
|
where without a pairing that is going from the self
|
|
0:29:20
|
zone to outside or self to inside
|
|
0:29:23
|
or vice-versa, from inside to self, outside to self
|
|
0:29:26
|
these traffic flows are all going to be allowed
|
|
0:29:30
|
So if were to go to router4
|
|
0:29:33
|
and ping the firewall itself
|
|
0:29:36
|
172.16.34.3
|
|
0:29:39
|
we could see this flow is allowed
|
|
0:29:42
|
but likewise if I were to go from the outside
|
|
0:29:46
|
on the outside if I ping 200.0.23.3
|
|
0:29:50
|
or to telnet to that
|
|
0:29:56
|
we could see the outside traffic to the router itself, this is being allowed
|
|
0:30:01
|
the same will be true if we came in from the
|
|
0:30:03
|
the DMZ, if we ping
|
|
0:30:07
|
router3 itself
|
|
0:30:11
|
or telnet to router3 itself
|
|
0:30:15
|
we would see that these flows are allowed
|
|
0:30:18
|
where typically in a real design, this is not what you would want
|
|
0:30:22
|
you don't want people sending packets to the firewall itself
|
|
0:30:25
|
and thats may be its for SSH
|
|
0:30:27
|
management, or its for management from the web interface
|
|
0:30:32
|
but the key here, is that, with the self zone, those traffic flows are automatically allowed
|
|
0:30:39
|
So next lets create our next pairing, which is going to be from the inside of the DMZ
|
|
0:30:43
|
and from the outside to the DMZ
|
|
0:30:47
|
Now there is two different ways that we can apply this logic here
|
|
0:30:52
|
if on the DMZ
|
|
0:30:54
|
I know my particular services, may be I have a
|
|
0:30:58
|
web server, I have a mail server
|
|
0:31:01
|
and I want to allow traffic from the inside to the web server
|
|
0:31:06
|
and from the outside to the web server
|
|
0:31:09
|
and likewise from the inside and the outside to the mail server
|
|
0:31:13
|
I basically have two different options
|
|
0:31:16
|
I could create a single policy
|
|
0:31:19
|
that says this is just to
|
|
0:31:21
|
the DMZ
|
|
0:31:24
|
then apply this to the pairing that is from in
|
|
0:31:27
|
to DMZ
|
|
0:31:31
|
and apply it from the out to DMZ
|
|
0:31:37
|
So essentially the same policies apply to two different pairings
|
|
0:31:40
|
the only disadvantage of this
|
|
0:31:43
|
is that if I want to separate the flows that going from the inside to the DMZ
|
|
0:31:47
|
or from the outside to the DMZ
|
|
0:31:49
|
I would have no way to do that
|
|
0:31:52
|
Now I could create a separate policy that says
|
|
0:31:55
|
in to the DMZ policy
|
|
0:32:00
|
then in to the DMZ policy is applied from in to DMZ
|
|
0:32:04
|
pairing
|
|
0:32:09
|
then likewise I can have the out
|
|
0:32:12
|
to the DMZ policy
|
|
0:32:17
|
which is then called from the
|
|
0:32:19
|
the out to the DMZ pairing
|
|
0:32:25
|
So you could technically do the configuration either way
|
|
0:32:28
|
it just depends on how Modular you want to keep the policy
|
|
0:32:31
|
the more Modular solution would be to do it
|
|
0:32:34
|
on the right hand portion where we have two separate policies calling from two different pairings
|
|
0:32:39
|
but if we want to make the configuration just a little bit more straight forward
|
|
0:32:43
|
we could have a single policy that just says its to the DMZ
|
|
0:32:46
|
and then its called from this two separate pairings, in to the DMZ and out to the DMZ
|
|
0:32:52
|
So in our case we are going to do it with a single policy
|
|
0:32:57
|
that single policy says, that I am going to allow telnet
|
|
0:33:01
|
but specifically just to the 192.10.9.254 address
|
|
0:33:07
|
where right now if we were to go to
|
|
0:33:11
|
to router3, lets look at the show ip route
|
|
0:33:14
|
and I want to look at routes that are coming in that outside interface
|
|
0:33:18
|
so lets say, show ip route include
|
|
0:33:21
|
fast ethernet 0/0
|
|
0:33:26
|
or I have two different addresses
|
|
0:33:29
|
if I telnet to this 51 address
|
|
0:33:35
|
this is a loop back interface that BB2 is advertising
|
|
0:33:39
|
likewise if I telnet to the
|
|
0:33:41
|
the 192.10.9.254 address
|
|
0:33:45
|
this is the actual interface address of BB2
|
|
0:33:48
|
So once the policy is complete
|
|
0:33:51
|
from the inside
|
|
0:33:52
|
or the outside to the DMZ
|
|
0:33:55
|
this telnet session should be allowed
|
|
0:33:57
|
but this one is going to be denied
|
|
0:34:01
|
because we are going to match multiple criteria, not only is it the telnet protocol
|
|
0:34:06
|
but its also going to that particular address
|
|
0:34:09
|
Now the way we are going to do this is simply by
|
|
0:34:11
|
classifying the traffic with an access list
|
|
0:34:14
|
and calling the protocol from inside of the class map
|
|
0:34:19
|
So now I will have an access list
|
|
0:34:22
|
IP access list extended that is the
|
|
0:34:26
|
to the DMZ acl
|
|
0:34:31
|
or to DMZ acl says
|
|
0:34:34
|
permit IP any host 192..10.9.254
|
|
0:34:43
|
So its traffic going to that particular address
|
|
0:34:51
|
next time I am going to have a class map that is type inspect
|
|
0:34:54
|
that is to the DMZ class
|
|
0:34:59
|
Now remember the class by default
|
|
0:35:02
|
is a match all class
|
|
0:35:04
|
So if I were to say match access group
|
|
0:35:08
|
to the DMZ acl
|
|
0:35:12
|
and also
|
|
0:35:14
|
match access group name
|
|
0:35:16
|
to DMZ acl
|
|
0:35:18
|
but then also match protocol telnet
|
|
0:35:23
|
it means that it has to be
|
|
0:35:25
|
traffic to this address but it also has to be telnet at the same time
|
|
0:35:30
|
so its a logical AND match
|
|
0:35:32
|
both matches must be true, in order for the class to be true
|
|
0:35:38
|
Hey, so now we have
|
|
0:35:39
|
the particular traffic classifier
|
|
0:35:42
|
Now we need to know what is the policy
|
|
0:35:45
|
So for policy map
|
|
0:35:46
|
to the DMZ policy
|
|
0:35:49
|
for class to DMZ class
|
|
0:35:54
|
I want to inspect this
|
|
0:36:01
|
says class to DMZ class of type inspect is not allowed in policy map
|
|
0:36:05
|
to DMZ policy of type default
|
|
0:36:09
|
now what this error message means
|
|
0:36:12
|
is that this policy map I created
|
|
0:36:15
|
this is a QoS policy map
|
|
0:36:18
|
and the reason why, what I should have said instead of
|
|
0:36:21
|
policy map to DMZ policy
|
|
0:36:23
|
I need to say policy map is type inspect
|
|
0:36:29
|
So it has to be specifically for the
|
|
0:36:31
|
zone based policy firewall
|
|
0:36:35
|
Hey, so next we are going to call the
|
|
0:36:37
|
the class thats to the DMZ class
|
|
0:36:42
|
and we are going to inspect this traffic
|
|
0:36:46
|
again we could drop the traffic, we could
|
|
0:36:48
|
pass it, which is the manual exception
|
|
0:36:51
|
police it or call the Deep packet
|
|
0:36:54
|
inspection, which going to be for the layer 7 policies
|
|
0:36:59
|
So now I know what is the traffic
|
|
0:37:02
|
what is the policy
|
|
0:37:03
|
next thing I need to do is configure my pairing
|
|
0:37:07
|
So I have the zone pair security
|
|
0:37:10
|
this is
|
|
0:37:12
|
the inside
|
|
0:37:14
|
to DMZ pairing
|
|
0:37:17
|
or I am watching traffic is that comes in from the inside zone
|
|
0:37:21
|
the destination is the DMZ zone
|
|
0:37:24
|
where the service policy type inspect is the
|
|
0:37:28
|
to DMZ policy
|
|
0:37:32
|
but additionally here I am going to do a second pairing
|
|
0:37:35
|
the second pairing is from
|
|
0:37:37
|
the outside
|
|
0:37:41
|
So there are two separate pairings
|
|
0:37:45
|
inside to DMZ and outside to DMZ
|
|
0:37:47
|
but they are going to call the same policy
|
|
0:37:50
|
which again means now that if I change the policy
|
|
0:37:54
|
it changes both of these inspections
|
|
0:37:56
|
traffic coming from the inside interfaces, going to the DMZ
|
|
0:37:59
|
or from the outside interfaces, going to the DMZ
|
|
0:38:03
|
Now since I already have the zone
|
|
0:38:06
|
membership applied to the interfaces, if we show zone
|
|
0:38:15
|
show zone pair security and show zone
|
|
0:38:19
|
security
|
|
0:38:22
|
since the DMZ is
|
|
0:38:24
|
actually DMZ is not applied here, DMZ needs to be on
|
|
0:38:28
|
fastethernet0/0
|
|
0:38:31
|
So zone member security is DMZ
|
|
0:38:36
|
Now a quick point about this, notice that
|
|
0:38:39
|
for this link I did not
|
|
0:38:40
|
previously applied the zone
|
|
0:38:42
|
or I did applied them to the
|
|
0:38:44
|
the fastethernet0/1 and the serial link
|
|
0:38:49
|
when you have one interface that is in a zone
|
|
0:38:53
|
and another interface that is not in a zone
|
|
0:38:57
|
traffic will be denied between them
|
|
0:39:02
|
So essentially if you have some interfaces that are running the zone policy firewall
|
|
0:39:06
|
in other interfaces that are not
|
|
0:39:08
|
there is no communication between them
|
|
0:39:11
|
this means that in the vast majority of cases, you would want either
|
|
0:39:14
|
all interfaces to be in zones
|
|
0:39:17
|
or none of the interfaces to be in zones
|
|
0:39:20
|
So if there are all in zones, then we can mandatorily define the policy
|
|
0:39:23
|
of how the traffic is going to be inspected between them
|
|
0:39:29
|
okay, now lets test this out, if we look at the
|
|
0:39:32
|
the show
|
|
0:39:34
|
show policy map
|
|
0:39:36
|
type inspect
|
|
0:39:39
|
zone pair sessions
|
|
0:39:41
|
I want to look at the
|
|
0:39:44
|
inside to the DMZ
|
|
0:39:46
|
and the outside to the DMZ policies
|
|
0:39:51
|
if we were to go to router4
|
|
0:39:54
|
and try to ping 192.10.9.254
|
|
0:39:58
|
this should be denied
|
|
0:40:01
|
where we would see this packet counter go up
|
|
0:40:04
|
should be in the inside to DMZ class
|
|
0:40:07
|
or, excuse me, the inside to DMZ policy
|
|
0:40:10
|
its going to be matched in class default
|
|
0:40:18
|
or here we have class default
|
|
0:40:20
|
inside to DMZ, we can see these packets are being dropped
|
|
0:40:25
|
Now to make this a little bit clear, exactly whats going on
|
|
0:40:28
|
I am going to make one change here to the policy map
|
|
0:40:32
|
where the policy map is to the DMZ policy
|
|
0:40:35
|
I going to say that for the default traffic
|
|
0:40:39
|
I not only want to drop the traffic, but also generate a log message
|
|
0:40:47
|
So now if I were to go to router4
|
|
0:40:49
|
and ping BB2
|
|
0:40:52
|
router3 says, I am dropping the ICMP sessions
|
|
0:40:56
|
on the inside to DMZ pairing
|
|
0:40:59
|
because the class default says to drop the traffic
|
|
0:41:04
|
likewise if I were to go to router2
|
|
0:41:07
|
who is on the outside
|
|
0:41:10
|
and from the outside then I am going to
|
|
0:41:13
|
lets say telnet to 51.51.51.51
|
|
0:41:21
|
router3 should generate a log here
|
|
0:41:25
|
that says these packets are going to be denied
|
|
0:41:27
|
from the outside to the DMZ
|
|
0:41:32
|
So this is correct, because the class default
|
|
0:41:35
|
which is matching this uncategorized flows
|
|
0:41:38
|
that has the drop action automatically
|
|
0:41:42
|
However if I were to go to router2
|
|
0:41:45
|
and change this destination to 192.10.9.254
|
|
0:41:54
|
we see this flow is now allowed
|
|
0:41:57
|
likewise if I went to router4
|
|
0:42:00
|
and did a telnet to this
|
|
0:42:03
|
telnet 192.10.9.254
|
|
0:42:07
|
this is allowed
|
|
0:42:09
|
if we show
|
|
0:42:11
|
policy map type inspect zone
|
|
0:42:13
|
zone pair sessions
|
|
0:42:15
|
we should see two sessions
|
|
0:42:18
|
in the state table
|
|
0:42:19
|
one of them is for the
|
|
0:42:21
|
inside to DMZ pairing
|
|
0:42:24
|
which is router4 telnet to BB2
|
|
0:42:29
|
then we have from the outside to the DMZ
|
|
0:42:36
|
Now again if I were to go to BB2, which is on the DMZ
|
|
0:42:40
|
and try to send packets to the inside
|
|
0:42:43
|
those are going to be dropped
|
|
0:42:45
|
likewise if I go from DMZ to outside
|
|
0:42:51
|
So the overall key of this implementation
|
|
0:42:54
|
again its using the same inspection engines behind the scenes, as we were in the Content Based Access Control
|
|
0:43:01
|
except it gives us more granular control
|
|
0:43:03
|
of how the policy is actually applied
|
|
0:43:07
|
because not only do we get to specify what are the individual classes of traffic
|
|
0:43:12
|
what are we going to do with them, are we going to inspect them
|
|
0:43:15
|
are we going to drop them, police them, just manually pass them
|
|
0:43:19
|
but more importantly we define the zone pairings
|
|
0:43:23
|
which are then defining what is the associations of the interfaces
|
|
0:43:28
|
and what are the particular policies that are being applied
|
