|
0:00:13
|
In our next security section we're going to look at the
|
|
0:00:15
|
zone based policy firewall which again is using the same
|
|
0:00:19
|
CBAC engine that we previously saw with the ip inspect command
|
|
0:00:24
|
but the syntax is going to change so that we are using
|
|
0:00:26
|
the class map and policy map logic similar to the module of
|
|
0:00:29
|
the quality of service to make it a little bit easier to define
|
|
0:00:33
|
policy rules when we have more than two interfaces that we're
|
|
0:00:37
|
trying to do the inspection on. Now one of the main changes that
|
|
0:00:40
|
we'll see with the zone based policy firewall is that the inspection
|
|
0:00:44
|
engine is not directly applied to the interface where instead
|
|
0:00:48
|
the physical or logical interface is applied to a
|
|
0:00:51
|
security zone, then we define how traffic is going to
|
|
0:00:55
|
be inspected depending on what particular zones it is
|
|
0:00:58
|
transiting between.
|
|
0:01:00
|
Now by default, traffic is going to be allowed inside the same zone
|
|
0:01:05
|
so if we have multiple interfaces that are in the inside zone
|
|
0:01:08
|
or multiple interfaces that are in the outside zone
|
|
0:01:12
|
there is no limit as to what traffic can transit between
|
|
0:01:14
|
those links inside the zone, but inter zone communication
|
|
0:01:19
|
is going to be dropped.
|
|
0:01:22
|
So this means from the inside zone to the outside zone or
|
|
0:01:25
|
from the inside to the DMZ that is not going to be allowed
|
|
0:01:29
|
by default. An additional key point here is that for any interface
|
|
0:01:34
|
that is not in a zone, we will not be able to send traffic
|
|
0:01:38
|
to from an interface that is in a zone.
|
|
0:01:42
|
So essentially this means that generally all interfaces would have
|
|
0:01:46
|
to have zone assignments or the router would behave as if they
|
|
0:01:50
|
were separate interfaces that would not be able to send
|
|
0:01:55
|
traffic to each other, so if we were to look at this
|
|
0:01:58
|
within the scope of our particular topology where previously we were
|
|
0:02:02
|
configuring Router 5 to have the Fast Ethernet 0/0
|
|
0:02:06
|
interface assigned as the inside
|
|
0:02:10
|
and the serial 0/0/0 as the outside. If the point to point
|
|
0:02:16
|
link to Router 4 and the Fast Ethernet 0/1 were not
|
|
0:02:19
|
assigned to zones, they would be able to send traffic to each other
|
|
0:02:24
|
but they would not be able to send traffic to either the outside
|
|
0:02:27
|
zone interface or the inside zone interface.
|
|
0:02:32
|
So again, in general you would usually apply all interfaces to a zone
|
|
0:02:38
|
to make sure that we can allow traffic to transit between
|
|
0:02:40
|
the links.
|
|
0:02:43
|
Additionally, there's going to be a separate zone that is
|
|
0:02:45
|
defined for the router's locally generated traffic or traffic
|
|
0:02:49
|
that is destined to the router which is known as the self-zone
|
|
0:02:53
|
where by default, traffic is allowed to go from any zone
|
|
0:02:56
|
to self or from self to any zone.
|
|
0:03:01
|
So in implementation change, we'll see with the zone based
|
|
0:03:04
|
policy firewall is that we do not need to manually account for the
|
|
0:03:08
|
control plane traffic
|
|
0:03:10
|
that the router is sending out its interfaces or receiving
|
|
0:03:13
|
inbound, so in our previous cases with both the reflexive access list
|
|
0:03:18
|
and the content based access control, we need in the ACL
|
|
0:03:22
|
in on the outside interface exceptions that we're allowing
|
|
0:03:26
|
the EIGRP routing traffic in.
|
|
0:03:30
|
But in the case of the zone based policy firewall
|
|
0:03:32
|
since this is now going to be represented by the self-zone
|
|
0:03:35
|
and traffic is not modified as it's going to that zone
|
|
0:03:39
|
we do not need to manually specify an exception.
|
|
0:03:43
|
We'll see that we can specify a policy that is going to be
|
|
0:03:47
|
specific to the self zone if we want to limit the traffic
|
|
0:03:51
|
so for example if we want to stop people from telnetting to
|
|
0:03:53
|
the router or ping the router, we can manually apply that to
|
|
0:03:57
|
the self zone, but by default nothing is going to be filtered.
|
|
0:04:02
|
Once we define what is the membership of the individual
|
|
0:04:04
|
interfaces, then we are going to assign a zone paring
|
|
0:04:10
|
that ultimately controls how traffic is going to be inspected
|
|
0:04:13
|
when it is moving between interfaces.
|
|
0:04:18
|
Again, the zone based policy firewall is going to use the
|
|
0:04:21
|
module of the quality of service logic
|
|
0:04:24
|
in order to define classification with class maps
|
|
0:04:28
|
then define policy maps to control whether we
|
|
0:04:31
|
are either dropping the traffic, inspecting the traffic
|
|
0:04:34
|
or passing it which essentially is allowing it without putting it
|
|
0:04:39
|
through the inspection engine.
|
|
0:04:43
|
Additionally, we can reference the content based access control
|
|
0:04:46
|
with the match protocol this would be the equivalent
|
|
0:04:49
|
of the IP inspect name command where we are matching
|
|
0:04:53
|
protocols like Http or FTP or TFTP.
|
|
0:04:58
|
We'll see that with the zone based firewall,
|
|
0:05:01
|
there is a more granular option that we can apply
|
|
0:05:03
|
to the individual protocol inspections
|
|
0:05:07
|
because there are separate policy maps that apply separately
|
|
0:05:10
|
to the web browsing traffic versus the DNS versus the
|
|
0:05:15
|
mail traffic.
|
|
0:05:16
|
So for each of the individual inspection engines, the router's
|
|
0:05:19
|
going to support different policy maps that are type
|
|
0:05:22
|
inspect and different parameter maps that are specific to that
|
|
0:05:27
|
individual protocol.
|
|
0:05:30
|
So for example, a parameter map that is talking about web traffic
|
|
0:05:33
|
could match the Http header size where a parameter map
|
|
0:05:37
|
that is matching send mail which is SMTP
|
|
0:05:41
|
it could control how many recipients do you have in
|
|
0:05:43
|
the actual mail header
|
|
0:05:46
|
or for a DNS request we could say what is the length of the
|
|
0:05:50
|
domain that you're trying to get the URL to resolve for.
|
|
0:05:53
|
So we're not going to go through all of the details
|
|
0:05:56
|
of the individual applications, I would say most likely that
|
|
0:06:00
|
most of that stuff is going to be outside of the scope of routing and switching
|
|
0:06:03
|
as long as you understand how the general process is tied together
|
|
0:06:07
|
you should be able to use the documentation for any advanced
|
|
0:06:10
|
type of matches that you need to use.
|
|
0:06:14
|
Just like the content based access control, zone based policy
|
|
0:06:17
|
firewall is also using the IP or excuse me the
|
|
0:06:20
|
TCP intercept inspection engine that is used to prevent the TCP
|
|
0:06:25
|
SYN flooding attacks.
|
|
0:06:28
|
For particular server or particular type of traffic
|
|
0:06:31
|
we can manually modify these parameters inside the parameter
|
|
0:06:36
|
map type inspect which would be things like the
|
|
0:06:40
|
maximum incomplete sessions, the maximum low sessions
|
|
0:06:45
|
the one-minute high, the one-minute low
|
|
0:06:47
|
similar to we did with the TCP intercept and with the content based
|
|
0:06:50
|
access control.
|
|
0:06:53
|
So we'll see at the end result of the zone based policy firewall
|
|
0:06:56
|
it has the same inspection capabilities as CBAC
|
|
0:07:02
|
but the syntax is going to make it a little bit easier
|
|
0:07:04
|
for us to figure out exactly how the different interfaces
|
|
0:07:07
|
are treated because we are decoupling the
|
|
0:07:10
|
inspection directly from the interface and we are then
|
|
0:07:14
|
instead applying it to the zone.
|
|
0:07:16
|
We'll see another action that is not available in the content
|
|
0:07:20
|
based access control that we can do with the zone based
|
|
0:07:22
|
policy firewall is the traffic policing similar to what we saw
|
|
0:07:28
|
in the module of the quality of service where with CBAC you
|
|
0:07:32
|
could technically apply a separate QoS policy that is doing
|
|
0:07:35
|
policing on a per interface basis, but with the zone based
|
|
0:07:40
|
policy firewall, this can be applied separately to
|
|
0:07:43
|
the individual inspection class maps that we are defining.
|
|
0:07:48
|
So we can apply a policing that is related to web traffic
|
|
0:07:52
|
differently than DNS or mail or TFTP.
|
|
0:07:57
|
So the key is that this is applying in the inspection
|
|
0:08:01
|
policy that is then referencing the individual class.
|
|
0:08:06
|
Now just like in the module of the quality of service
|
|
0:08:09
|
our first step then for the zone based policy firewall
|
|
0:08:11
|
would be to classify the traffic.
|
|
0:08:14
|
And we are going to do this with a class map
|
|
0:08:16
|
but the syntax difference is that this is a class map type
|
|
0:08:20
|
inspect as opposed to just a normal class map.
|
|
0:08:25
|
Just like in the module of the quality of service, we have the logic of the
|
|
0:08:28
|
match all versus the match any
|
|
0:08:31
|
where match any is a logical Or where a match all is a
|
|
0:08:36
|
logical And
|
|
0:08:38
|
so if we are saying match all and we are matching protocol
|
|
0:08:42
|
in addition to an access list, it would be doing a CBAC application
|
|
0:08:47
|
level match, but then we could also limit this to specific
|
|
0:08:50
|
senders or specific receivers like a server that we're trying to
|
|
0:08:54
|
protect its DNS inspection or its web browsing inspection.
|
|
0:09:02
|
Now for the inspection engine to work, it assumes that we are
|
|
0:09:05
|
matching a specific protocol, otherwise, we are going to
|
|
0:09:09
|
fallback to our default TCP, UDP or ICMP inspections
|
|
0:09:14
|
that are not specific to the individual application.
|
|
0:09:18
|
So similar to in CBAC where I said the IP
|
|
0:09:21
|
inspect name had the list name, then we were matching
|
|
0:09:24
|
TCP, UDP and ICMP those are just general inspections
|
|
0:09:29
|
that would not account for any non-standard
|
|
0:09:33
|
TCP or UDP based applications.
|
|
0:09:36
|
So things like our Voice over IP phone calls there's going to be a
|
|
0:09:40
|
problem using the default UDP inspection versus the specific
|
|
0:09:45
|
application inspection that is going to match the protocol.
|
|
0:09:48
|
Then additionally we do need to take into account
|
|
0:09:52
|
that the router is treating its locally generated traffic
|
|
0:09:54
|
differently in the zone based policy firewall versus the CBAC
|
|
0:09:59
|
whereas CBAC we need to tell it specifically what to
|
|
0:10:02
|
inspect from the local router. With the zone based policy firewall
|
|
0:10:06
|
it does not do any inspections by default, so it's going to permit
|
|
0:10:10
|
all traffic to the interfaces of the router and it's going to permit
|
|
0:10:13
|
all traffic locally generated from the router.
|
|
0:10:20
|
Now for some reason we want to filter this out if we
|
|
0:10:22
|
want to limit people from being able to ping the router
|
|
0:10:25
|
or telnet or SSH to it, we can end up in a logic
|
|
0:10:29
|
error where we try to apply an access list directly to the interface
|
|
0:10:33
|
and there's an order of operations problem
|
|
0:10:36
|
with the ACL applied on the link versus the inspection
|
|
0:10:40
|
in the zone based policy firewall.
|
|
0:10:43
|
So in general, if you want to apply a normal access list
|
|
0:10:47
|
exception to the zone based firewall, you should not apply
|
|
0:10:51
|
this to the interface, you should apply it inside the
|
|
0:10:54
|
policy map and use the pass action to allow the
|
|
0:10:59
|
traffic through without hitting the inspection engine.
|
|
0:11:05
|
So in the end, the syntax becomes more complicated
|
|
0:11:07
|
when we're doing the zone based policy firewall
|
|
0:11:09
|
but it makes more logical sense when we look at how
|
|
0:11:12
|
it's tied together.
|
|
0:11:16
|
So for this example, we're going to use the same inside and outside
|
|
0:11:19
|
interfaces on Router 5, but what I'm going to do now is
|
|
0:11:23
|
on Router 4 shut down it's connection to the VLAN 146
|
|
0:11:29
|
and it's connection to the frame relay.
|
|
0:11:32
|
So this portion of the network that Router 5 is using to connect to
|
|
0:11:36
|
Router 4, this is essentially going to be the DMZ
|
|
0:11:42
|
where the inside network is connecting to switch 2
|
|
0:11:46
|
and then the outside network is connecting to the frame relay.
|
|
0:11:53
|
So what we're going to have at a minimum three different zones
|
|
0:11:58
|
which means that we're going to have multiple
|
|
0:11:59
|
parings between them which define how the traffic is going to be
|
|
0:12:03
|
inspected. Specifically we would need to define how is traffic
|
|
0:12:08
|
going to go from the inside out, how is traffic going to go
|
|
0:12:13
|
from the inside to the DMZ
|
|
0:12:16
|
and then from outside to the DMZ.
|
|
0:12:21
|
If we wanted to control how traffic is going to Router 5 itself
|
|
0:12:25
|
locally, we would then need to put separate inspections
|
|
0:12:29
|
from the outside to self or from DMZ to self or from self
|
|
0:12:33
|
to outside from self to DMZ.
|
|
0:12:37
|
So let's look at Router 5's configuration currently with
|
|
0:12:39
|
the CBAC.
|
|
0:12:40
|
If we look at the show run include inspect
|
|
0:12:46
|
at the interface level we have the IP inspect role applied
|
|
0:12:51
|
so this is the frame relay interface where the inspection role
|
|
0:12:54
|
is applied outbound. Specifically this is matching TCP, UDP, ICMP
|
|
0:12:59
|
FTP and TFTP and it's also creating the audit trail
|
|
0:13:04
|
which is doing the logs for the session setup and the session tear down.
|
|
0:13:11
|
When we look at the show access list
|
|
0:13:13
|
on that frame relay interface we have the ACL that has
|
|
0:13:16
|
CBAC outside inbound
|
|
0:13:19
|
that is allowing the EIGRP control plane traffic
|
|
0:13:25
|
in addition to the ICMP trace route responses
|
|
0:13:28
|
which are the port unreachable and the time exceeded
|
|
0:13:31
|
then anything besides that we are going to deny.
|
|
0:13:37
|
So this means that this access list here
|
|
0:13:39
|
is going to affect not only traffic that is transiting
|
|
0:13:42
|
through Router 5, but that is locally generated
|
|
0:13:46
|
to Router 5
|
|
0:13:48
|
So if I were to go outside of the network
|
|
0:13:52
|
let's say I was to go to Router 1
|
|
0:13:55
|
and ping the interface address of Router 5
|
|
0:13:59
|
we would see that this is denied based on the incoming
|
|
0:14:03
|
access list on the outside interface.
|
|
0:14:06
|
But with the zone based policy firewall, since the self zone
|
|
0:14:10
|
is not filtered, we should see this is going to change
|
|
0:14:13
|
and Router 1 would be able to ping the outside interface of Router 5
|
|
0:14:17
|
so to make this a little bit clearer, let's remove all of the
|
|
0:14:20
|
previous access lists and the inspection that's configured
|
|
0:14:24
|
on the interface, so I'll say show run include access list
|
|
0:14:33
|
include access list or inspect
|
|
0:14:39
|
I want to remove access list CBAC outside in
|
|
0:14:44
|
then the previous two outside inbound and the outside outbound
|
|
0:14:48
|
these were the ones that were used for the reflexive list
|
|
0:14:52
|
where again, the reflexive list does not have application level inspections
|
|
0:14:56
|
it cannot deal with any non-standard applications.
|
|
0:15:01
|
Then lastly, I'll remove the IP inspection rule.
|
|
0:15:07
|
So if we look at the interface level of the frame relay
|
|
0:15:12
|
it has the ACL still applied in on the interface.
|
|
0:15:16
|
But since the access list does not exist
|
|
0:15:19
|
it's not actually affecting anything.
|
|
0:15:22
|
You do need to be careful about the order of operations here though
|
|
0:15:26
|
because if I have applied the access list before it's created
|
|
0:15:30
|
it means that once I put the very first line in the ACL
|
|
0:15:35
|
everything else besides that is going to be dropped as it comes
|
|
0:15:38
|
in the interface because remember the ACL always has an implicit deny
|
|
0:15:44
|
at the end, so if I were actually managing Router 5 from this
|
|
0:15:47
|
interface, so if I had telnetted in or SSHed in
|
|
0:15:51
|
once I start to define the ACL, it's most likely going to cut off
|
|
0:15:55
|
my management session that's going to the router itself.
|
|
0:15:58
|
Now in our case within the scope of the lab exam
|
|
0:16:00
|
we have access to the console, so it's not that big of an issue
|
|
0:16:03
|
but you do want to be aware of this for real world
|
|
0:16:06
|
deployments that any time you're modifying the access lists
|
|
0:16:10
|
or filtering remotely, you need to make sure that
|
|
0:16:12
|
you're not going to filter out your own management session.
|
|
0:16:20
|
So now on Router 5 if we look at the show ip interface brief
|
|
0:16:24
|
the link to Router 4 is shut down, so right now I'll bring this back up
|
|
0:16:29
|
then on Router 4, I'm going to isolate this from the rest of
|
|
0:16:31
|
the internal network.
|
|
0:16:35
|
So I'm disabling Fast Ethernet 0/1 and its serial 0/0/0
|
|
0:16:44
|
The end result of this should be that when we look at any
|
|
0:16:48
|
of the routes that are coming from the backbone router
|
|
0:16:53
|
so these 30 and 31 networks
|
|
0:16:55
|
if I were now to go anywhere else in the topology
|
|
0:16:58
|
and do a trace route to these, so let's say from switch 3
|
|
0:17:04
|
we should see that this traffic needs to go
|
|
0:17:05
|
to Router 5 first
|
|
0:17:08
|
then from Router 5 it's going to go over that
|
|
0:17:10
|
point to point interface that goes to Router 4
|
|
0:17:15
|
so essentially Router 5 is going to be the central
|
|
0:17:18
|
point of transit that's going up to the DMZ
|
|
0:17:21
|
or going to the inside network.
|
|
0:17:31
|
So next on Router 5 let's configure the basic rules
|
|
0:17:34
|
so that we're going to allow traffic to come from the
|
|
0:17:37
|
inside interface go to the outside interface
|
|
0:17:41
|
then have those traffic flows return
|
|
0:17:45
|
but we will not allow unsolicited requests to come from the outside
|
|
0:17:48
|
in. Once we have those two zones working, then we'll
|
|
0:17:52
|
add the DMZ and look at how it's going to work with
|
|
0:17:55
|
three or more interfaces or three or more zones.
|
|
0:18:00
|
So now on Router 5 we're going to define what are the
|
|
0:18:03
|
zones that we're going to apply.
|
|
0:18:06
|
These are the zone security
|
|
0:18:09
|
and their names.
|
|
0:18:11
|
So you could technically put anything here.
|
|
0:18:14
|
For clarity I'm going to put this in all capital and specify this is the inside
|
|
0:18:19
|
the outside and the DMZ
|
|
0:18:24
|
Pretty much the only other option that you could put here
|
|
0:18:26
|
is just a description for documentation of the config.
|
|
0:18:29
|
I don't really need to do that, I can tell just based on the
|
|
0:18:32
|
name, specifically what these zones are designed to do.
|
|
0:18:37
|
So if I were to name them zone security 1, 2 and 3
|
|
0:18:40
|
then it's going to be less obvious as to what that
|
|
0:18:42
|
particular zone is using to accomplish.
|
|
0:18:47
|
Next I'm going to specify what are the particular
|
|
0:18:49
|
protocols that I'm trying to inspect.
|
|
0:18:52
|
This is going to be with a class map that is type inspect.
|
|
0:18:59
|
Now again, we do have the option of match all versus
|
|
0:19:03
|
match any but to keep the inspection a little bit clearer
|
|
0:19:07
|
I'm going to separate these into separate policies
|
|
0:19:10
|
or separate class maps
|
|
0:19:12
|
where one of them is going to be for TCP, another one for
|
|
0:19:15
|
UDP and then a third one for ICMP.
|
|
0:19:18
|
If I then wanted application specific matches like
|
|
0:19:22
|
Http or pop3 for get mail, smtp for send mail
|
|
0:19:28
|
then I can specify those application inspections.
|
|
0:19:34
|
So here I'll say class map type inspect is TCP
|
|
0:19:37
|
From here I'm going to do a match.
|
|
0:19:40
|
It could be another class map which is for nested matches
|
|
0:19:44
|
the ACL that is going to be used for filtering on a per
|
|
0:19:48
|
source basis like if I wanted to say one server's traffic is going
|
|
0:19:52
|
to be inspected differently than another or the protocol
|
|
0:19:57
|
that is used for the application match.
|
|
0:20:00
|
So in this case, I'll just say match protocol TCP.
|
|
0:20:04
|
Then likewise I'll have another inspection that is for UDP
|
|
0:20:10
|
and a third inspection that is for ICMP
|
|
0:20:16
|
match protocol icmp
|
|
0:20:20
|
so now I know what is the traffic that I'm going to watch
|
|
0:20:23
|
as it's coming from the inside and going to the outside.
|
|
0:20:28
|
Now the classification is done, I need to figure out what am I
|
|
0:20:31
|
actually going to do with the traffic once the policy matches it.
|
|
0:20:34
|
This is what the policy map type inspect is for.
|
|
0:20:42
|
Now generally it's a good idea to have a descriptive name here
|
|
0:20:46
|
that tells you what type of zone paring this is going to
|
|
0:20:50
|
be applied to
|
|
0:20:52
|
because typically, a different policy is going to be applied
|
|
0:20:57
|
to each individual zone paring.
|
|
0:20:59
|
The only time that the same policy is applied to multiple
|
|
0:21:03
|
parings would be like in our case where we have the DMZ
|
|
0:21:07
|
if I wanted the same policy that goes from outside to
|
|
0:21:11
|
in, the same policy that goes from outside to in versus
|
|
0:21:16
|
or excuse me from outside to DMZ versus inside to DMZ
|
|
0:21:19
|
then I could apply the same policy there twice to the pairing.
|
|
0:21:25
|
But if I wanted three separate inspections, so one inside out
|
|
0:21:30
|
one outside DMZ and one inside DMZ, then I would want to
|
|
0:21:34
|
specify three separate policy maps.
|
|
0:21:41
|
So to start, this is going to be for traffic coming from the
|
|
0:21:45
|
inside interface or the inside zone more specifically
|
|
0:21:48
|
going to the outside zone.
|
|
0:21:50
|
So I'll say policy map type inspect. This is the inside
|
|
0:21:54
|
to outside policy.
|
|
0:21:58
|
And you'll see why I'm using these descriptive naming
|
|
0:22:01
|
namings because at the end, the syntax can get really confusing
|
|
0:22:05
|
if you're just saying this is policy map 1 matching class map 2
|
|
0:22:09
|
for zone pairing 3, then really you're going to have no idea what's
|
|
0:22:12
|
going on with the syntax, so try to make this as
|
|
0:22:15
|
descriptive as possible, so basically the configuration is
|
|
0:22:19
|
self-documenting.
|
|
0:22:23
|
From here, just like in a QoS policy we are going to reference
|
|
0:22:26
|
the classes, so I have class TCP, UDP and ICMP.
|
|
0:22:33
|
Now I need to figure out what am I actually going to with
|
|
0:22:35
|
these different classes. Do I want to simply
|
|
0:22:38
|
deny the traffic which would be to drop it?
|
|
0:22:40
|
Do I want to inspect it so that's going to send it to CBAC?
|
|
0:22:45
|
Pass it would be to allow it without inspecting it
|
|
0:22:49
|
or police it is going to be to limit it.
|
|
0:22:52
|
Ok, there's another option for doing a service policy.
|
|
0:22:55
|
This is going to be for a specific application inspection.
|
|
0:23:01
|
This is where we would have the policy map type
|
|
0:23:05
|
inspect for that individual application.
|
|
0:23:08
|
So we'll come back to this again, normally you're
|
|
0:23:11
|
probably not going to have to do this for the routing and switching exam
|
|
0:23:14
|
but you can use the configuration guide as a reference as to how you
|
|
0:23:17
|
would actually need to do this. Depack an inspection basically
|
|
0:23:20
|
means that you're doing your web inspection differently
|
|
0:23:23
|
than your mail or your peer to peer file applications.
|
|
0:23:31
|
So for TCP traffic I'm going to inspect it.
|
|
0:23:36
|
Then for UDP, I'll inspect it
|
|
0:23:41
|
for ICMP I'm going to inspect it as well.
|
|
0:23:46
|
Now I could inspect it and police it.
|
|
0:23:50
|
I could also
|
|
0:23:55
|
drop the traffic and log it
|
|
0:23:58
|
so we'll come back to this when we want to make
|
|
0:24:00
|
an exception to the policy to not allow the traffic to go
|
|
0:24:03
|
through, but currently I'm saying for these three different classes
|
|
0:24:07
|
TCP, UDP and ICMP I am inspecting it.
|
|
0:24:10
|
So now I know how is the inspection going to occur.
|
|
0:24:13
|
Let's look at the running configuration up to this point.
|
|
0:24:19
|
I have the three class maps that's matching the traffic
|
|
0:24:22
|
ICMP, UDP and TCP
|
|
0:24:24
|
It's pretty self-explanatory based on the naming what they're matching.
|
|
0:24:28
|
But if I said class map type inspect match all
|
|
0:24:32
|
one, then that's really not going to tell me what's going on.
|
|
0:24:37
|
Now I have the policy that is applying to these three different classes.
|
|
0:24:39
|
Specifically this is the one that is going from the inside to the outside.
|
|
0:24:46
|
Next I need to make the association between the inside and the outside zone
|
|
0:24:51
|
and then apply that inspection policy.
|
|
0:24:55
|
This is where the zone paring is going to come in.
|
|
0:24:59
|
So I give the zone paring a name, I'll say that this is the
|
|
0:25:02
|
inside to outside paring.
|
|
0:25:08
|
The source of traffic is going to be the zone
|
|
0:25:12
|
named inside
|
|
0:25:14
|
where the destination of the traffic is the zone named outside.
|
|
0:25:20
|
For traffic that is coming from inside going to outside
|
|
0:25:23
|
I want to inspect it with the service policy
|
|
0:25:26
|
that is called inside to outside policy.
|
|
0:25:32
|
Service policy is output
|
|
0:25:36
|
or let's see service policy service policy type inspect
|
|
0:25:41
|
is inside to outside policy.
|
|
0:25:47
|
So now I have the zone defined.
|
|
0:25:51
|
I have the class maps doing the classification.
|
|
0:25:53
|
The policy map telling me what I'm doing with those
|
|
0:25:56
|
classes. The pairing from the inside to the outside zone
|
|
0:26:00
|
and the service policy applied to that pairing.
|
|
0:26:04
|
The very final step would then be to assign the interfaces
|
|
0:26:07
|
to the different zones.
|
|
0:26:11
|
Now before I do that, I want to do a basic connectivity test
|
|
0:26:14
|
to make sure that there's no filtering from inside to
|
|
0:26:17
|
out or inside to DMZ or outside to DMZ.
|
|
0:26:22
|
So from switch 4,
|
|
0:26:25
|
I'm going to ping 30.0.0.1
|
|
0:26:29
|
and trace to this destination
|
|
0:26:31
|
we should see this goes to Router 5 and then up to
|
|
0:26:33
|
Router 4, so that's fine.
|
|
0:26:37
|
Then I want to know can I reach switch 3
|
|
0:26:44
|
which I can, so I'm allowed to go from inside to DMZ
|
|
0:26:47
|
inside to outside
|
|
0:26:51
|
then the opposite direction if we trace 30.0.0.1
|
|
0:26:57
|
there's no problem from outside to DMZ
|
|
0:27:02
|
and there should be no problem from outside to inside.
|
|
0:27:07
|
So right now there's no filtering because there's no
|
|
0:27:09
|
access list applied on any of the routers' interfaces.
|
|
0:27:11
|
Now I'm going to apply the zones to the links.
|
|
0:27:16
|
So on the frame relay interface this is a zone member
|
|
0:27:21
|
this belongs to the zone called outside.
|
|
0:27:26
|
Fast Ethernet 0/0
|
|
0:27:32
|
This is a zone member of inside.
|
|
0:27:38
|
This means that I have a couple other interfaces
|
|
0:27:40
|
that are not part of zones.
|
|
0:27:42
|
Specifically these are Fast Ethernet 0/1
|
|
0:27:46
|
serial 0/1/0 and my loopback 0
|
|
0:27:52
|
This now means that from the inside network
|
|
0:27:54
|
I should no longer be able to reach BB3
|
|
0:28:00
|
because traffic cannot come from an interface assigned to a zone
|
|
0:28:05
|
and then go to an interface that is not in a zone.
|
|
0:28:11
|
If I were to ping to the outside network
|
|
0:28:15
|
this should be allowed because Router 5 has the
|
|
0:28:19
|
inspection policy to say that ICMP is going to be inspected
|
|
0:28:23
|
as it comes from inside to out.
|
|
0:28:27
|
Now the final verification on Router 5 the syntax is kind of difficult
|
|
0:28:31
|
here. It's show policy map type inspect
|
|
0:28:38
|
zone pair sessions
|
|
0:28:42
|
so this is now the equivalent of the show ip inspect sessions.
|
|
0:28:45
|
It says for the specific pairing which is going to be in my case
|
|
0:28:49
|
outside or inside to outside pairing, I want to look at
|
|
0:28:52
|
the active sessions
|
|
0:28:55
|
and we should see that it's going to be the ICMP traffic.
|
|
0:28:59
|
So if we were to go to switch 4 and set a high
|
|
0:29:03
|
repeat count under these pings
|
|
0:29:05
|
we should see on Router 5 that there's going to be a session
|
|
0:29:08
|
that shows up
|
|
0:29:10
|
which it is.
|
|
0:29:11
|
It says there's echo requests
|
|
0:29:13
|
coming from this source going to this destination.
|
|
0:29:18
|
When switch 4 stops doing the pings
|
|
0:29:22
|
we should see that Router 5 is going to delete this session.
|
|
0:29:28
|
It says it last heard the session four seconds ago
|
|
0:29:33
|
and then it's removed.
|
|
0:29:35
|
So it's not like the reflexive access list where it just lets it
|
|
0:29:38
|
time out after five minutes. The router's now actively
|
|
0:29:41
|
managing the connection.
|
|
0:29:45
|
So likewise, if I were to go from the inside interface
|
|
0:29:48
|
and then telnet to the outside.
|
|
0:29:51
|
I telnet to switch 3 this is allowed.
|
|
0:29:54
|
On Router 5 if I look at the show policy map type inspect zone
|
|
0:29:58
|
pair sessions
|
|
0:30:00
|
it says there's a TCP session coming from switch 4 going to
|
|
0:30:04
|
switch 3, it's going to port 23
|
|
0:30:06
|
right now the connection is open.
|
|
0:30:10
|
If switch 4 exits which is going to generate
|
|
0:30:14
|
a TCP Fin
|
|
0:30:18
|
we see that Router 5 is removing the session from the
|
|
0:30:21
|
state table
|
|
0:30:23
|
or essentially the session list for that particular zone pairing.
|
|
0:30:31
|
If I now try to go in the opposite direction
|
|
0:30:34
|
if I go to switch 3 and try to get to switch 4
|
|
0:30:37
|
this is going to be denied as it gets to Router 5
|
|
0:30:42
|
because I did not define what here.
|
|
0:30:50
|
Traffic is being dropped as it comes from switch 3
|
|
0:30:55
|
to Router 5's interface
|
|
0:30:58
|
because why?
|
|
0:31:00
|
Because I didn't put a manual zone pairing that goes from
|
|
0:31:03
|
outside to inside.
|
|
0:31:06
|
I did do a pairing that is from inside to out
|
|
0:31:09
|
which means the reply from the outside will be able to
|
|
0:31:12
|
go in, but since I did not inspect or pass anything
|
|
0:31:17
|
from out to in, that is all going to be
|
|
0:31:19
|
denied by default.
|
|
0:31:23
|
However, the self zone which is Router 5
|
|
0:31:26
|
itself, this is not going to be limited to any traffic.
|
|
0:31:30
|
So if I were to go to switch 3 who's on the outside
|
|
0:31:34
|
I should be able to ping Router 5
|
|
0:31:37
|
I should be able to telnet to Router 5
|
|
0:31:39
|
there's going to be no limitation as to this
|
|
0:31:41
|
traffic flow.
|
|
0:31:45
|
But in general, you probably would not want this.
|
|
0:31:47
|
If Router 5 is your border router that's connecting to the
|
|
0:31:50
|
internet, there's no reason that people should be pinging its
|
|
0:31:53
|
outside interface or telneting or sending any other traffic to it.
|
|
0:31:59
|
So generally, the transit interface is the router itself.
|
|
0:32:02
|
You would want to stop people from sending traffic to that
|
|
0:32:06
|
unless it were your management stations doing SSH
|
|
0:32:09
|
or maybe your network management station doing SNMP or NetFlow
|
|
0:32:14
|
or syslog collections.
|
|
0:32:18
|
But normally, unsolicited requests from the outside we would want
|
|
0:32:21
|
to drop those.
|
|
0:32:24
|
So in order to do this, I would then need to manually
|
|
0:32:27
|
define an inspection
|
|
0:32:29
|
that is from the outside to self.
|
|
0:32:33
|
So let's now say that I want to allow switch 1
|
|
0:32:38
|
specifically to ping Router 5
|
|
0:32:42
|
but everything else should be dropped and when it is
|
|
0:32:45
|
dropped I want to generate a log message.
|
|
0:32:48
|
Specifically at the address I'm going to allow the pings from
|
|
0:32:51
|
is going to be 155.28.7.7
|
|
0:32:56
|
this should be able to ping Router 5
|
|
0:32:58
|
everything else on the outside should be denied
|
|
0:33:01
|
and that should all be logged.
|
|
0:33:05
|
So now what I want to do is specify a separate policy
|
|
0:33:10
|
that is going to go from the outside to self.
|
|
0:33:16
|
Now there's a question here, "How would that overlap with
|
|
0:33:18
|
then the control plane protection in the control plane policing?"
|
|
0:33:22
|
The zone firewall is going to be processed first
|
|
0:33:24
|
Because if the traffic is filtered out, then there's no reason
|
|
0:33:28
|
the control plane needs to police it.
|
|
0:33:31
|
So CLPP doesn't actually come into effect until the router is
|
|
0:33:34
|
going to allow that traffic.
|
|
0:33:36
|
So if I'm denying telnet from the outside to self, then control
|
|
0:33:40
|
plane policing is never going to come in.
|
|
0:33:42
|
So the key is that it's an order of operations issue.
|
|
0:33:45
|
This is one of the reasons why you would generally not want to
|
|
0:33:48
|
apply an access list directly to the interface.
|
|
0:33:52
|
So let's say we did that. Let's go to Router 5
|
|
0:33:55
|
and let's create just access list 100
|
|
0:33:59
|
that says deny icmp any any
|
|
0:34:04
|
and access list 100 permit ip any any
|
|
0:34:11
|
then on the serial link I'll say ip access group 100
|
|
0:34:18
|
ip access group 100 in
|
|
0:34:23
|
Now the parser doesn't give me any error, it's allowing me to
|
|
0:34:25
|
apply both the zone based policy firewall and the access
|
|
0:34:28
|
list at the same time, but now the question is
|
|
0:34:32
|
what's the order that it's processes in?
|
|
0:34:35
|
Does the zone firewall be processed first?
|
|
0:34:38
|
which means that ping traffic would be allowed to Router 5
|
|
0:34:42
|
or does the access list get processed first?
|
|
0:34:44
|
which would say that pings to or through Router 5 should
|
|
0:34:48
|
be denied.
|
|
0:34:50
|
So let's go to the outside and let's try this on switch 3
|
|
0:34:54
|
can we ping Router 5?
|
|
0:34:56
|
No we can’t.
|
|
0:34:57
|
So this now means that the ACL is being processed
|
|
0:35:00
|
before the zone based firewall.
|
|
0:35:04
|
If I want to ping through the device though
|
|
0:35:06
|
let's say on Switch 4 I tried to ping
|
|
0:35:09
|
switch 3
|
|
0:35:11
|
notice now that this is also dropped.
|
|
0:35:16
|
So even though the traffic was inspected by the
|
|
0:35:19
|
zone based policy firewall
|
|
0:35:21
|
now this access list is overriding it.
|
|
0:35:27
|
So you could technically do this, but it's probably a bad idea
|
|
0:35:30
|
because it's an order of operations issue
|
|
0:35:32
|
and you don't really know which one is going to be
|
|
0:35:34
|
processed before the other ones unless you basically
|
|
0:35:37
|
try out every single possible combination.
|
|
0:35:40
|
So we don't know is the outbound order different than the
|
|
0:35:43
|
inbound order. Does matter whether you're coming from the
|
|
0:35:47
|
inside zone versus the outside zone. It's too many
|
|
0:35:49
|
variables to take into account.
|
|
0:35:51
|
So to fix this order of operations
|
|
0:35:54
|
we'll now just do all of our filtering in the zone based
|
|
0:35:57
|
policy firewall syntax because then we'll know exactly what the order is.
|
|
0:36:02
|
The order is going to be based on how I manually
|
|
0:36:04
|
match the class maps inside of the policy map.
|
|
0:36:08
|
So it will be processed top-down just like a normal QoS policy is.
|
|
0:36:14
|
So now on Router 5, I want to remove this ACL that's
|
|
0:36:16
|
going to get in the way here. We'll say no access list 100
|
|
0:36:25
|
So now what I want to do is match the traffic that is going to
|
|
0:36:28
|
come in from switch 1
|
|
0:36:30
|
These are the pings that I want to allow in.
|
|
0:36:34
|
We'll say ip access list extended
|
|
0:36:37
|
is going to permit ICMP
|
|
0:36:40
|
from 155.28.7.7
|
|
0:36:44
|
and I don't care what address it's going to.
|
|
0:36:47
|
It could be going to any of my local addresses.
|
|
0:36:50
|
But it specifically should be an echo.
|
|
0:36:53
|
So this should say ip access list extended
|
|
0:36:58
|
let's call this pings from switch 1
|
|
0:37:02
|
that permits that
|
|
0:37:07
|
permits that host
|
|
0:37:09
|
I now need to match this in a class map.
|
|
0:37:12
|
So I'll say class map type inspect.
|
|
0:37:16
|
I'll name it the same thing. Probably what I should have said
|
|
0:37:19
|
here was like ping from switch 1 ACL
|
|
0:37:22
|
then I'll call this ping from switch 1 class
|
|
0:37:25
|
just to give it a little bit of separation
|
|
0:37:28
|
but here I'm just going to name them the same thing.
|
|
0:37:32
|
So this class is going to match the access group
|
|
0:37:35
|
that has a name of ping from switch 1
|
|
0:37:42
|
So now I have the traffic classified. Next thing is going to be to
|
|
0:37:45
|
define the policy map. This is going to be my
|
|
0:37:48
|
outside to self policy.
|
|
0:37:53
|
I already have the class that is ping from switch 1
|
|
0:37:58
|
Now I want to -- it says class of type inspect is not
|
|
0:38:02
|
allowed in policy of type default.
|
|
0:38:06
|
So what I should have said is that this policy map
|
|
0:38:08
|
it's not a QoS policy
|
|
0:38:11
|
it's an inspection policy, so policy map type inspect
|
|
0:38:15
|
outside to self
|
|
0:38:18
|
class ping from switch 1
|
|
0:38:24
|
Now I'm not going to inspect this, I'm simply going to pass it
|
|
0:38:29
|
because it's going to the router itself. If it was
|
|
0:38:32
|
going to a transit interface, then I would want to inspect it
|
|
0:38:36
|
but since it's going to the router itself, I can just say
|
|
0:38:39
|
pass the traffic.
|
|
0:38:41
|
So it means don't drop it, but don't necessarily inspect it.
|
|
0:38:49
|
For everything else inside this policy which is going to be
|
|
0:38:53
|
class class-default
|
|
0:38:56
|
just like inside the QoS policies
|
|
0:38:59
|
I'm going to drop the traffic
|
|
0:39:01
|
and I'm going to log it.
|
|
0:39:05
|
So now I have the policy map defined. If we show
|
|
0:39:07
|
policy map type show policy map type
|
|
0:39:12
|
inspect
|
|
0:39:16
|
this outside to self policy is going to call the class called
|
|
0:39:19
|
ping from switch 1, pass that traffic whatever's being matched
|
|
0:39:22
|
drop everything else and log it.
|
|
0:39:26
|
So I now need a new pairing that is going to be from the
|
|
0:39:30
|
outside to the self zone.
|
|
0:39:34
|
Again, this is configured with the zone pairing.
|
|
0:39:38
|
Zone pairing is going to be from the outside zone.
|
|
0:39:43
|
Actually this the pairing name, so I'll say that this is the
|
|
0:39:47
|
outside to self pairing
|
|
0:39:53
|
which is coming from the outside zone
|
|
0:39:56
|
and again, this is case-sensitive outside zone
|
|
0:39:59
|
and the destination is myself.
|
|
0:40:07
|
For this specific traffic, I want to apply the service policy
|
|
0:40:10
|
that is type inspect.
|
|
0:40:12
|
This is called outside to self policy.
|
|
0:40:19
|
If we now look at the show zone pair
|
|
0:40:29
|
show zone pair security
|
|
0:40:33
|
Ok, this shows what the actual pairings are
|
|
0:40:35
|
what are the associations. If we show zone pair security
|
|
0:40:39
|
source, I can specify the individual source zone
|
|
0:40:42
|
to the destination zone, probably what I want to look at instead here
|
|
0:40:45
|
is what's going on with the actual traffic.
|
|
0:40:48
|
This is going to be the show policy map type inspect
|
|
0:40:54
|
for the zone pairing which is the -- I want to see what is the
|
|
0:41:01
|
outside to self.
|
|
0:41:07
|
So specifically that one.
|
|
0:41:12
|
So I can now see that the ping from switch 1
|
|
0:41:14
|
that's not being matched at all
|
|
0:41:16
|
but class default is dropping packets.
|
|
0:41:20
|
And we saw based on the log this is what type of traffic
|
|
0:41:25
|
that's being dropped here.
|
|
0:41:28
|
This is our now our EIGRP control plane.
|
|
0:41:33
|
So since I have now defined a specific outside to self policy
|
|
0:41:39
|
it means that the router is dropping inbound the EIGRP
|
|
0:41:44
|
hellos and the EIGRP unicasts that are going to come in from
|
|
0:41:47
|
routers 1, 2 and 3 on the outside interface.
|
|
0:41:50
|
The end result is when I look at the show ip eigrp neighbors
|
|
0:41:53
|
I do not have an adjacency
|
|
0:41:55
|
with routers 1, 2 and 3 on that link.
|
|
0:42:00
|
So what do I need to do now in order to make sure
|
|
0:42:02
|
that the EIGRP adjacency is not broken?
|
|
0:42:05
|
I need to make an exception to this outside to self policy.
|
|
0:42:12
|
Now I could do these with separate class maps
|
|
0:42:14
|
I could do just one class map that's going to group all
|
|
0:42:17
|
of my exceptions together
|
|
0:42:20
|
so to do that I could say -- and let's say no service
|
|
0:42:25
|
no service timestamps that'll clean up the logs a little bit.
|
|
0:42:28
|
I'm going to define a class map type inspect
|
|
0:42:32
|
but I'll say that this is match any
|
|
0:42:37
|
and this is going to be my outside to self exceptions.
|
|
0:42:44
|
So essentially this is going to match anything that I do
|
|
0:42:46
|
not want to drop. In this particular case,
|
|
0:42:49
|
this is EIGRP.
|
|
0:42:53
|
Since match protocol doesn't support this, it then means
|
|
0:42:57
|
I need to match this in an access list.
|
|
0:43:00
|
Some of the protocols are going to be matched here
|
|
0:43:03
|
like if we could say match protocol BGP
|
|
0:43:06
|
match protocol ospf is not listed there.
|
|
0:43:11
|
So I would need an ACL for that.
|
|
0:43:13
|
Let's say ip access list extended eigrp
|
|
0:43:17
|
permits any eigrp
|
|
0:43:21
|
or ip access list extended eigrp first
|
|
0:43:27
|
It says permit eigrp any any
|
|
0:43:31
|
then under the class map, since this is a match
|
|
0:43:34
|
match any
|
|
0:43:36
|
I can do as many match statements as I need.
|
|
0:43:40
|
Match any outside to self exceptions.
|
|
0:43:48
|
I want match access group name eigrp
|
|
0:43:53
|
then under the policy map that's doing the inspections
|
|
0:43:57
|
let's say do show run include policy
|
|
0:44:02
|
This is going to be the service policy type inspect
|
|
0:44:07
|
or no, the policy map type inspect
|
|
0:44:10
|
policy map type inspect outside to self
|
|
0:44:17
|
I need to say for class
|
|
0:44:23
|
outside to self exceptions
|
|
0:44:26
|
I want to pass these.
|
|
0:44:30
|
So now additionally, I need to make sure that the order of
|
|
0:44:32
|
this is processed correctly inside of the policy map.
|
|
0:44:36
|
So if we show run section policy map
|
|
0:44:43
|
notice that the ping is listed first before the exceptions.
|
|
0:44:48
|
So if I was dropping something here that overlapped on the
|
|
0:44:51
|
EIGRP, that's going to be an issue
|
|
0:44:53
|
because just like the QoS policy, it's going to be
|
|
0:44:56
|
processed top down.
|
|
0:44:59
|
But now since I was allowing the EIGRP if I look at
|
|
0:45:02
|
the show ip eigrp neighbors
|
|
0:45:04
|
I do have the adjacencies.
|
|
0:45:09
|
So the final result now of the outside to self policy
|
|
0:45:12
|
should be that I am no longer allowed to ping Router 5
|
|
0:45:18
|
which is correct, this is what I would want
|
|
0:45:21
|
but if I source it from 155.28.7.7
|
|
0:45:26
|
this is allowed.
|
|
0:45:31
|
This other packet here, this previous ping, this one should have been logged
|
|
0:45:38
|
which is this last one.
|
|
0:45:40
|
Two packets were dropped from 67.7 that's switch 1
|
|
0:45:45
|
going to Router 5's outside interface.
|
|
0:45:48
|
Now likewise, I should be able to reach any of the
|
|
0:45:51
|
interfaces of Router 5
|
|
0:45:54
|
if I match the 58.5
|
|
0:45:59
|
so even though this link, 58.5, is a member of the zone
|
|
0:46:04
|
inside, since it's locally assigned to the router
|
|
0:46:09
|
it's not really part of inside, it's actually part of self.
|
|
0:46:13
|
The transit traffic that comes in that link is part of the inside
|
|
0:46:16
|
but not the actual interface address itself. That's part of
|
|
0:46:20
|
self zone.
|
|
0:46:24
|
So now let's look at our full policy now.
|
|
0:46:26
|
And you'll see as the complexity of the policy starts to grow
|
|
0:46:30
|
the syntax can just get really really bong for this.
|
|
0:46:34
|
So if you were doing this in the lab exam,
|
|
0:46:37
|
I would highly recommend to keep track of this config
|
|
0:46:40
|
in Notepad, so you can have an idea of exactly how it
|
|
0:46:43
|
ties together.
|
|
0:46:48
|
So let's look at this full config here.
|
|
0:46:54
|
First I have the zone definitions.
|
|
0:47:00
|
This is zone security inside, outside and DMZ
|
|
0:47:04
|
so this is define the zones.
|
|
0:47:08
|
Then I have classify the traffic.
|
|
0:47:16
|
These are the class maps.
|
|
0:47:18
|
We have ones that are exceptions from the outside
|
|
0:47:21
|
to self, we have basic ICMP, basic UDP, basic TCP
|
|
0:47:26
|
then the pings that are coming from switch 1
|
|
0:47:31
|
Next I have the inspection policies.
|
|
0:47:35
|
So define inspection policy.
|
|
0:47:42
|
There's a separate policy that's going from
|
|
0:47:44
|
inside to outside
|
|
0:47:47
|
and a separate policy that's going from outside to self.
|
|
0:47:54
|
Now I need to associate the zones.
|
|
0:47:58
|
This is the zone pairings
|
|
0:48:01
|
where ultimately I apply the inspection to the pairings.
|
|
0:48:06
|
So associate the zones and then apply the policy.
|
|
0:48:14
|
Then our last step is to assign the zone membership.
|
|
0:48:23
|
So on the Ethernet, this is on the inside
|
|
0:48:28
|
on the frame relay, this is the outside.
|
|
0:48:34
|
But now what's nice about this policy if I want to add
|
|
0:48:37
|
a new interface, the only thing I need to do is make
|
|
0:48:40
|
it a member of that zone and it doesn't affect
|
|
0:48:44
|
any of the rest of the configuration.
|
|
0:48:46
|
If we were to do this in CBAC for every new interface that
|
|
0:48:50
|
we define, it needs a whole separate set of inspection
|
|
0:48:53
|
policies, but now I would see that Fast Ethernet 0/0
|
|
0:48:58
|
and Fast Ethernet 0/1 are basically treated the same
|
|
0:49:02
|
because they're both part of the inside zone.
|
|
0:49:07
|
So any traffic would be able to transit between them
|
|
0:49:09
|
on modified
|
|
0:49:11
|
but when I go from the inside to out, it's going to follow that
|
|
0:49:15
|
policy that is applied to that specific zone pairing.
|
|
0:49:21
|
So all this configuration up to this point, this is just to get
|
|
0:49:23
|
the basic, same result as what we did with the
|
|
0:49:27
|
reflexive access list or with the CBAC.
|
|
0:49:32
|
But now let's look at what if we have a third zone
|
|
0:49:34
|
the DMZ and we want to apply a more specific
|
|
0:49:38
|
policy, so what I want to do specifically
|
|
0:49:43
|
is allow devices to connect to the web service of Router 4
|
|
0:49:48
|
So on Router 4, I'll say ip http server
|
|
0:49:55
|
and I want them to be able to download files from
|
|
0:49:59
|
Router 4
|
|
0:50:02
|
So on Router 4, first thing I'm going to do
|
|
0:50:05
|
is stage the web service I'll say ip http server
|
|
0:50:09
|
ip http path is flash
|
|
0:50:15
|
I have user name cisco password cisco
|
|
0:50:19
|
user name cisco is privilege 15
|
|
0:50:24
|
so they'll be able to use the web service.
|
|
0:50:25
|
The actual file that I'm going to get
|
|
0:50:29
|
I'll say copy -- or not copy -- let's say show run and I want to
|
|
0:50:35
|
redirect this to flash let's say test.htm
|
|
0:50:45
|
If I say more flash:/test.htm
|
|
0:50:50
|
we can see this is a copy of the running config.
|
|
0:50:52
|
So this is the file that Router 4 is going to be serving.
|
|
0:50:59
|
What should happen when I'm done with the final
|
|
0:51:01
|
inspection policy is that I should be able to go to
|
|
0:51:04
|
someone on the outside or on the inside
|
|
0:51:08
|
and say copy
|
|
0:51:11
|
http ciso:cisco at Router 4's address
|
|
0:51:17
|
so let's say 150.28.4.4/test.htm and I'll just send this to null.
|
|
0:51:31
|
We can see right now the http service is being denied
|
|
0:51:35
|
because Router 5 is dropping this.
|
|
0:51:38
|
I'm not going to actually see that Router 5 is dropping this
|
|
0:51:41
|
though unless I were to configure the logging
|
|
0:51:46
|
but for the inside to outside -- or excuse me, the outside
|
|
0:51:50
|
to DMZ, right now I don't have any association.
|
|
0:51:53
|
And specifically even that link it's not even in a zone
|
|
0:51:56
|
so all of the traffic is going to be denied regardless.
|
|
0:52:05
|
So what would be my next step here?
|
|
0:52:08
|
If I want to control how traffic is going out to the
|
|
0:52:11
|
DMZ, I could potentially apply the same type of
|
|
0:52:16
|
policy that is going from outside to DMZ and
|
|
0:52:19
|
from inside to DMZ
|
|
0:52:21
|
if I want those users to have the same exact access.
|
|
0:52:25
|
If I want them to get to the Http server maybe they
|
|
0:52:28
|
can get to the mail server on that interface
|
|
0:52:31
|
but I also want to do some specific application inspections.
|
|
0:52:39
|
So I have the DMZ zone already defined
|
|
0:52:42
|
next thing I'm going to classify the traffic.
|
|
0:52:47
|
So let's say that we're going to match Router 4
|
|
0:52:50
|
as the web server, but I want to do some
|
|
0:52:53
|
protection mechanisms against them as well.
|
|
0:52:56
|
So I'll have an ip access list extended that is R4
|
|
0:53:00
|
web server ACL
|
|
0:53:03
|
this says permit tcp any that's going to Router 4's address
|
|
0:53:10
|
I don't need to match the port here because I'm going to match this
|
|
0:53:12
|
in the protocol, then I'm going to have a class map
|
|
0:53:18
|
class map that is type inspect.
|
|
0:53:22
|
But in this case, specifically this is an http class.
|
|
0:53:26
|
This is going to be Router 4 as the web server
|
|
0:53:32
|
I'll call this the application class.
|
|
0:53:37
|
The APP class.
|
|
0:53:40
|
Here I'm going to say match the request
|
|
0:53:44
|
and you'd have to know the specific application format
|
|
0:53:49
|
for this Http, so if I were to say the
|
|
0:53:57
|
the URI -- you could get into a regular expression
|
|
0:53:59
|
here, you can get really really complicated for
|
|
0:54:01
|
the individual application.
|
|
0:54:04
|
Now off hand, I don't know exactly what the syntax is for
|
|
0:54:07
|
http so I'm not going to use this. What you could say
|
|
0:54:11
|
though is things like match the method and -- or match
|
|
0:54:19
|
match request method
|
|
0:54:26
|
would be let's say post
|
|
0:54:29
|
so http post is when you're trying to upload a file over the
|
|
0:54:33
|
web. If I don't want my users to be able to do this
|
|
0:54:37
|
I can match this in a class now do an inspection and then
|
|
0:54:41
|
drop this traffic or maybe I'm going to reset the TCP session.
|
|
0:54:49
|
So the key here is that this specific class is specific to
|
|
0:54:52
|
an http inspection. If I were to look at the other options
|
|
0:54:56
|
like class map type inspect let's say smtp
|
|
0:55:00
|
this is a mail inspection
|
|
0:55:02
|
I could say match the recipient
|
|
0:55:09
|
count
|
|
0:55:11
|
if there's greater than 50 addresses in the to field
|
|
0:55:16
|
then I could drop this mail.
|
|
0:55:20
|
So I could basically prevent my SMTP server being used as a
|
|
0:55:23
|
spam relay.
|
|
0:55:26
|
So again, within the scope of the routing and switching exam
|
|
0:55:29
|
they're probably not going to get this detailed
|
|
0:55:32
|
something like this would be more reserved for the security exam
|
|
0:55:35
|
because it's more testing on the actual application understanding
|
|
0:55:38
|
not really the networking type configuration of it.
|
|
0:55:44
|
So what I want to do now instead is not really match
|
|
0:55:46
|
a specific inspection class that's about Router 4
|
|
0:55:50
|
I just want a generic class for them.
|
|
0:55:53
|
So I'll remove this application class.
|
|
0:55:57
|
I want a class map that is just a regular R4 web server class
|
|
0:56:04
|
which is saying match protocol http
|
|
0:56:12
|
match access group name
|
|
0:56:17
|
then the access list here
|
|
0:56:22
|
is Router 4 web server ACL
|
|
0:56:27
|
but let's say I now want to change how Router 4 is
|
|
0:56:30
|
being protected based on the TCP intercept engine.
|
|
0:56:35
|
So to do this, when I say match protocol http
|
|
0:56:38
|
I'm going to specify a specific parameter map.
|
|
0:56:42
|
So I'll say parameter map
|
|
0:56:47
|
is type inspect
|
|
0:56:50
|
I'll say that this is Router 4
|
|
0:56:54
|
web server
|
|
0:56:58
|
parameters
|
|
0:57:05
|
I want to control what is the TCP SYN wait time
|
|
0:57:12
|
or the maximum number of incomplete sessions
|
|
0:57:16
|
window scale enforcement would be for the TCP sliding
|
|
0:57:21
|
windows ignoring invalid window scale option for TCP packets.
|
|
0:57:25
|
So of these are specific application attacks that the router's trying to prevent
|
|
0:57:32
|
where I could say icmp idle time that would be for
|
|
0:57:40
|
like your ping responses how long do you wait
|
|
0:57:42
|
but let's say I want to change just the maximum number
|
|
0:57:45
|
of incompletes
|
|
0:57:48
|
and I also want to do auditing.
|
|
0:57:52
|
So max incomplete
|
|
0:57:55
|
the high number if there's more than ten half open sessions
|
|
0:58:02
|
I'm going to start resetting them and I'll say once they go
|
|
0:58:06
|
below five, then I'm going to stop, so this
|
|
0:58:09
|
would be a really aggressive threshold. In a real production
|
|
0:58:13
|
design, you'd have to look at what's the traffic
|
|
0:58:15
|
pattern of your particular server.
|
|
0:58:18
|
So these are kind of just any random values
|
|
0:58:20
|
then I want to say I want to turn the audit trail on.
|
|
0:58:25
|
Ok, so now I have that particular parameter map
|
|
0:58:30
|
I need to now call this from the inspection class.
|
|
0:58:33
|
So I need to go back to class map type inspect
|
|
0:58:41
|
when I say match protocol http
|
|
0:58:45
|
it's going to be from this specific parameter map.
|
|
0:58:50
|
Parameter map R4 web server parameter's not found
|
|
0:59:09
|
I may need to call this from the policy map.
|
|
0:59:14
|
So let's try this, let's say policy map type
|
|
0:59:19
|
inspect
|
|
0:59:20
|
This is going to be the two DMZ policy.
|
|
0:59:26
|
So I'm not saying where it's coming from because it's going to be
|
|
0:59:28
|
both for the inside and the outside.
|
|
0:59:32
|
I want the for the class
|
|
0:59:37
|
that is Router 4 web server class
|
|
0:59:45
|
I want to inspect this and here is where I'm calling the parameter map.
|
|
0:59:49
|
So R4 web server parameters.
|
|
0:59:54
|
The other one that is called here, this is for the application
|
|
1:00:00
|
specific parameter map
|
|
1:00:03
|
which basically means that it would be for things like the
|
|
1:00:09
|
http header size the number of the mail recipients
|
|
1:00:17
|
that we were looking at, so that's called as the parameter map
|
|
1:00:20
|
when we're doing the individual inspection.
|
|
1:00:22
|
So it's kind of complicated it's a recursive logic
|
|
1:00:25
|
where from the class, you're calling another class
|
|
1:00:28
|
as a parameter map and then they're being inspected
|
|
1:00:31
|
under the policy map, so again, unless you have some
|
|
1:00:34
|
overall visibility of this feature like looking at the
|
|
1:00:37
|
config in Notepad, it's really easy to get lost as to what you're doing.
|
|
1:00:43
|
So let's tie this final piece together now, so I have the policy map
|
|
1:00:47
|
that's doing the inspection now, so it's inspecting the traffic
|
|
1:00:53
|
then for class class-default let's say drop and log
|
|
1:01:00
|
then this is going to apply to the zone pairing
|
|
1:01:07
|
zone pairing security that is outside to DMZ
|
|
1:01:13
|
where the source is outside
|
|
1:01:15
|
and the destination is DMZ
|
|
1:01:19
|
service policy type inspect is the to DMZ policy
|
|
1:01:31
|
but this is also going to be the same for the inside
|
|
1:01:41
|
the inside to the DMZ
|
|
1:01:43
|
so same policy is applied twice.
|
|
1:01:46
|
Then last thing on the link we have zone member security
|
|
1:01:50
|
is DMZ
|
|
1:01:53
|
so now if everything is tied together properly
|
|
1:01:56
|
I should be able to go back to switch 3
|
|
1:01:58
|
and then download this file which I can.
|
|
1:02:01
|
If I were to look at let's say a larger file, let's look at Router 4's
|
|
1:02:07
|
IOS image dir flash
|
|
1:02:15
|
so here's the image name. If I were to copy that from
|
|
1:02:18
|
switch 1 or actually from switch 3
|
|
1:02:29
|
so it should be downloading it now. On Router 5 if we look
|
|
1:02:32
|
at the show policy map type inspect
|
|
1:02:41
|
zone pair sessions
|
|
1:02:43
|
I should see that for outside to DMZ
|
|
1:02:49
|
I have this inspection.
|
|
1:02:54
|
For anything else, those should be dropped
|
|
1:02:57
|
and also we noticed before Router 5 did generate the audit log.
|
|
1:03:06
|
So this was switch 3 trying to download the files from Router 4
|
|
1:03:16
|
So now let's look at the very full final config.
|
|
1:03:49
|
So again, we have the in this case I now have the parameters
|
|
1:03:53
|
those parameters are for Router 4's inspection
|
|
1:04:00
|
This says the maximum number of incompletes is ten.
|
|
1:04:06
|
If they go above ten, then we're going to start to reset them
|
|
1:04:08
|
until they get down to five.
|
|
1:04:10
|
I have the different class maps
|
|
1:04:13
|
the one that's matching Router 4 specifically is this
|
|
1:04:15
|
one, so it's saying match all of these parameters. It has to be http
|
|
1:04:19
|
and it has to be that particular ACL.
|
|
1:04:23
|
Once this is true, I'm then inspecting them with the
|
|
1:04:29
|
policy map that is inside to outside or to the DMZ
|
|
1:04:38
|
or outside to self.
|
|
1:04:40
|
I have the three zones.
|
|
1:04:44
|
-- different pairings and then the policy is applied.
|
|
1:04:47
|
But notice the two that are going to the DMZ these
|
|
1:04:50
|
are referencing the same policy.
|
|
1:04:53
|
So this is the reason you could have a one policy
|
|
1:04:55
|
that's common between the different zones.
|
|
1:05:00
|
But if I look at -- and then we have finally the
|
|
1:05:02
|
the assignments of the links to the zones.
|
|
1:05:06
|
But if I were now to go to Router 4
|
|
1:05:07
|
from Router 4, I'm not going to be able to go
|
|
1:05:11
|
anywhere else in the network.
|
|
1:05:13
|
So the DMZ it's prevented from sending any traffic out
|
|
1:05:18
|
the only thing it's allowed to do is receive the requests
|
|
1:05:23
|
in from the outside
|
|
1:05:28
|
or in from the inside and then reply.
|
|
1:05:33
|
So if I took the same exact syntax that I did
|
|
1:05:36
|
on switch 3
|
|
1:05:46
|
which was this copy.
|
|
1:05:48
|
And I did this from the inside network let's say
|
|
1:05:51
|
from switch 4
|
|
1:05:53
|
We can see that's matching it as well.
|
|
1:05:56
|
So the traffic both from the outside and the inside
|
|
1:06:00
|
going to the DMZ is then the inspected by the same policy.
|
|
1:06:03
|
So again, the key points to remember about this
|
|
1:06:06
|
is that it's ultimately referencing the same inspection as CBAC
|
|
1:06:09
|
the only thing the zone based policy firewall is doing is changing
|
|
1:06:12
|
the syntax.
|
|
1:06:14
|
So unless there's an association between the zones, the traffic is
|
|
1:06:18
|
going to be dropped.
|
|
1:06:19
|
The router's zone itself the self zone
|
|
1:06:23
|
is going to allow all traffic.
|
|
1:06:25
|
If we wanted to filter that out, we would have to apply
|
|
1:06:28
|
a specific inspection to the self zone
|
|
1:06:31
|
which then means we would have to account for
|
|
1:06:33
|
the control plane protocols as well.
|
