|
0:00:13
|
In our next section we are going to look at some additional exceptions
|
|
0:00:16
|
to the zone based policy firewall configuration we have on router3
|
|
0:00:21
|
where again we have three different zones, we have the inside
|
|
0:00:25
|
that is on the connection
|
|
0:00:27
|
from router3 to router4
|
|
0:00:29
|
the connection to BB2 is the DMZ
|
|
0:00:33
|
the connection to router2 is the outside
|
|
0:00:38
|
specifically in the policy
|
|
0:00:41
|
for traffic that is going to the DMZ
|
|
0:00:45
|
or saying that if it is going to this destination address which is BB2
|
|
0:00:49
|
and it is telnet traffic
|
|
0:00:52
|
we are going to inspect it
|
|
0:00:55
|
for anything else which is not this traffic we are going to drop it
|
|
0:00:58
|
but also generate a log
|
|
0:01:02
|
this policy to the DMZ policy is then called from two different parents
|
|
0:01:06
|
the inside to DMZ and the outside to DMZ
|
|
0:01:11
|
the third policy, inside to outside policy
|
|
0:01:15
|
says that the device is on the inside
|
|
0:01:18
|
can either telnet
|
|
0:01:19
|
or send ICMP traffic to the outside
|
|
0:01:23
|
this is being inspected
|
|
0:01:24
|
which means that
|
|
0:01:25
|
it is not allowed back in automatically
|
|
0:01:32
|
So next we are going to look at two additional configurations
|
|
0:01:35
|
the first one
|
|
0:01:36
|
is how do we now control traffic that is going to
|
|
0:01:39
|
router3 itself
|
|
0:01:41
|
or coming from router3 itself
|
|
0:01:44
|
then additionally what do we do when we have any type of non standard applications
|
|
0:01:49
|
they cannot be matched by an inspection engine
|
|
0:01:54
|
Now again if we look at the routing design
|
|
0:01:57
|
we have router3 running two different routing protocols
|
|
0:02:01
|
we have EIGRP on the inside
|
|
0:02:05
|
we have OSPF on the DMZ
|
|
0:02:09
|
and on the outside
|
|
0:02:13
|
So if we are going to filter any traffic that is going to router3 or coming from router3
|
|
0:02:18
|
the first thing that we need to do
|
|
0:02:21
|
is to make an exception for any of the control plane protocols
|
|
0:02:26
|
So I don't want to break my IGRP routing or my BGP routing
|
|
0:02:30
|
by filtering traffic as it is going to router3
|
|
0:02:34
|
Now I am going to configure two different policies here
|
|
0:02:38
|
one that is from the inside to self
|
|
0:02:44
|
which is going to control traffic as its coming from router4 going to 3
|
|
0:02:49
|
and a second policy that is from
|
|
0:02:52
|
the outside
|
|
0:02:54
|
to self
|
|
0:02:56
|
and from the DMZ to self
|
|
0:03:01
|
where essentially these are the untrusted networks, the outside and the DMZ
|
|
0:03:06
|
going to the router itself
|
|
0:03:08
|
where I am going to allow the OSPF traffic there
|
|
0:03:10
|
but I am not going to allow anything else
|
|
0:03:13
|
from the inside to router3
|
|
0:03:17
|
I am going to allow the EIGRP traffic
|
|
0:03:20
|
I am going to allow people to ping router3
|
|
0:03:22
|
to telnet to router3 and SSH to router3
|
|
0:03:26
|
but no other traffic flows are going to be allowed
|
|
0:03:30
|
So just like any of our previous policies
|
|
0:03:33
|
the first thing that we need to do
|
|
0:03:34
|
is characterize, what is the traffic
|
|
0:03:37
|
that we want to match
|
|
0:03:39
|
and this is going to be accomplished with the class map type inspect
|
|
0:03:44
|
so on router3 we are going to have class map type inspect
|
|
0:03:47
|
this is going to be the inside to self class
|
|
0:03:53
|
where the inside to self class
|
|
0:03:56
|
remember that these class maps will actually have the match all
|
|
0:04:00
|
logic by default
|
|
0:04:01
|
So I am gonig to change this, so it says class map type inspect
|
|
0:04:05
|
match
|
|
0:04:08
|
match any
|
|
0:04:11
|
So I can use this for any of my exceptions
|
|
0:04:14
|
okay specifically in this case, I am going to
|
|
0:04:18
|
match protocol EIGRP
|
|
0:04:22
|
match protocol
|
|
0:04:23
|
telnet and ICMP
|
|
0:04:27
|
Now notice here that the
|
|
0:04:30
|
application level match doesn't have
|
|
0:04:33
|
an entry for EIGRP
|
|
0:04:35
|
some of these are not going to listed, like if I would say match protocol OSPF
|
|
0:04:39
|
match protocol BGP
|
|
0:04:41
|
BGP is
|
|
0:04:44
|
available but EIGRP and OSPF is not
|
|
0:04:47
|
So now if I want to classify this traffic, I am going to need to call an access list as well
|
|
0:04:54
|
So what else say here is match access group with a name
|
|
0:04:58
|
of inside to self ACL
|
|
0:05:03
|
where IP access list extended
|
|
0:05:06
|
inside to self ACL
|
|
0:05:09
|
will say permit EIGRP any any
|
|
0:05:14
|
but since I am calling the class with the match any logic
|
|
0:05:19
|
if we show run section class map
|
|
0:05:27
|
if its telnet, if its ICMP or if it is
|
|
0:05:31
|
whatever is matching this access list
|
|
0:05:33
|
then its going to be
|
|
0:05:35
|
match by the particular policy
|
|
0:05:38
|
Now the policy likewise, policy map type inspect
|
|
0:05:42
|
is now going to be the inside to self policy
|
|
0:05:49
|
for class inside to self class
|
|
0:05:54
|
we don't have the option for inspect
|
|
0:05:57
|
when we are dealing with the self zone
|
|
0:06:00
|
if we want to manually allow the traffic in
|
|
0:06:04
|
we have to use the pass action
|
|
0:06:08
|
Now we will see in a minute when we go to send non standard application through
|
|
0:06:13
|
the different zones
|
|
0:06:14
|
So from inside to outside or from inside to outside
|
|
0:06:18
|
the pass action is going to work a little bit differently
|
|
0:06:20
|
then it is with the self zone
|
|
0:06:23
|
if I am passing traffic
|
|
0:06:25
|
from the inside to myself
|
|
0:06:29
|
but if I do not have a zone pairing that goes from the self back to inside
|
|
0:06:35
|
it means that the traffic is automatically going to be passed back
|
|
0:06:40
|
Now I can not inspect the traffic here I have to pass it
|
|
0:06:46
|
then lastly I am going to create the zone pairing, so I will say
|
|
0:06:50
|
zone pair security
|
|
0:06:52
|
is going to be inside to self, is the name
|
|
0:06:55
|
this is coming from
|
|
0:06:57
|
the source zone inside
|
|
0:06:59
|
the destination zone is myself
|
|
0:07:02
|
which is using the service policy type inspect
|
|
0:07:06
|
that is the inside to self policy
|
|
0:07:12
|
Now again to make this a little bit clear, lets say show run section policy map
|
|
0:07:20
|
in the class default
|
|
0:07:25
|
of this policy, I am going to say, not only should the traffic be dropped
|
|
0:07:28
|
but I am going to log it
|
|
0:07:30
|
so now for something that is being denied
|
|
0:07:34
|
we should generate a log message
|
|
0:07:37
|
Now on router3, lets look at the show ip eigrp neighbours
|
|
0:07:42
|
we see we have an adjacency with router4
|
|
0:07:45
|
and I am going to do is clear the adjacency, we will say clear ip eigrp neighbors
|
|
0:07:51
|
Now if that policy is working in a inspections policy
|
|
0:07:55
|
when I look at the neighbours I should see that the traffic is allowed back in
|
|
0:08:01
|
and we could see that there is log messages that
|
|
0:08:04
|
this traffic is being allowed, these packets were passed
|
|
0:08:08
|
if we show ip route eigrp
|
|
0:08:11
|
we could see that we do have routes being learned from the inside
|
|
0:08:15
|
So the eigrp packets are not getting dropped
|
|
0:08:19
|
Now likewise if were to go to 4
|
|
0:08:22
|
and ping router3
|
|
0:08:25
|
or telnet to router3
|
|
0:08:30
|
these packets should be allowed, these are being passed
|
|
0:08:36
|
Now if I were to configure router3 for SSH access
|
|
0:08:41
|
lets say the IP domain name
|
|
0:08:44
|
is ine.com
|
|
0:08:47
|
and we need to generate a RSA key
|
|
0:08:49
|
So crypto key generate
|
|
0:08:53
|
RSA
|
|
0:08:56
|
for the general keys
|
|
0:08:59
|
I want to make sure that the size of the key is atleast 768
|
|
0:09:04
|
which is going to allow us to
|
|
0:09:06
|
to enable SSH version 2
|
|
0:09:13
|
So from the inside
|
|
0:09:16
|
if I now SSH to router3, it will SSH
|
|
0:09:19
|
with a log in of cisco
|
|
0:09:22
|
which is pre configured, that username
|
|
0:09:25
|
and I am SSHing to router3
|
|
0:09:29
|
3 should generate a log message saying that this traffic was dropped
|
|
0:09:34
|
because in class default we found the drop action
|
|
0:09:39
|
but if I were to do the same thing here from the outside
|
|
0:09:43
|
if I were to go to router2 and say SSH
|
|
0:09:46
|
with a log in cisco
|
|
0:09:48
|
to the outside interface of router3
|
|
0:09:54
|
we could see that this traffic is allowed
|
|
0:09:57
|
because I did not yet defined
|
|
0:10:00
|
the outside to self pairing
|
|
0:10:05
|
So for the self zone
|
|
0:10:06
|
as long as the pairing is not manually configured
|
|
0:10:09
|
it means that all of the traffic is going to be allowed
|
|
0:10:12
|
as soon as I configured that pairing that was going from inside to self
|
|
0:10:16
|
it means that anything that I am not manually matching in the class
|
|
0:10:20
|
So anything that falls bound to class default
|
|
0:10:22
|
those calls are going to be dropped
|
|
0:10:27
|
Now if I did want to permit this
|
|
0:10:30
|
the only thing that I would need to do on router3
|
|
0:10:32
|
is when we look at the show run section class map
|
|
0:10:37
|
would be to go to the inside to self class
|
|
0:10:42
|
and add that protocol
|
|
0:10:45
|
match protocol SSH
|
|
0:10:51
|
So you could see, just based on the modularity of the config
|
|
0:10:55
|
its much easier to maintain this policy
|
|
0:10:59
|
when you compare it to the CBAC
|
|
0:11:02
|
because with the CBAC rules, you need see how they are applied to the interfaces
|
|
0:11:05
|
in which directions
|
|
0:11:07
|
what are the manual access list that you have
|
|
0:11:10
|
doing exceptions to the filter, or manual denies to the filter
|
|
0:11:14
|
it can get very complicated
|
|
0:11:16
|
when you have three or more zones
|
|
0:11:19
|
and you are trying to manage this with the Content Based Access Control
|
|
0:11:22
|
But with the zone based policy firewall
|
|
0:11:25
|
since we have this very strictly defined logic
|
|
0:11:28
|
of what is the traffic that is being inspected
|
|
0:11:33
|
and then what is the association
|
|
0:11:35
|
of the interfaces, so the inside to outside
|
|
0:11:38
|
or the inside of the DMZ or the outside of the DMZ
|
|
0:11:43
|
even though the resulting syntax is much larger than using CBAC
|
|
0:11:47
|
the final result is easier to manage and its much easier to troubleshoot
|
|
0:11:52
|
if you are dropping some sort of flow
|
|
0:11:54
|
that you don't want to
|
|
0:11:56
|
Okay, so now lets do it this in the reverse direction as well
|
|
0:12:00
|
we are going to have the traffic that is coming from the
|
|
0:12:02
|
outside going to myself
|
|
0:12:10
|
Now before I configure any of the traffic classes
|
|
0:12:13
|
I am going to skip to the next step which is to define the policy map
|
|
0:12:17
|
type inspect
|
|
0:12:19
|
we call this, outside to self policy
|
|
0:12:23
|
that says simply for the class, class-defualt
|
|
0:12:26
|
drop and log the packets
|
|
0:12:30
|
and the reason that I may want to do this
|
|
0:12:32
|
is similar to the examples, we say before with the CBAC
|
|
0:12:36
|
or with the relflexive access list or the Basic Access LIst
|
|
0:12:40
|
did if I dropped all the traffic and log it
|
|
0:12:43
|
I would then know what are the individual flows that I need to permit later
|
|
0:12:50
|
So depending on whats going on in the rest of the network
|
|
0:12:53
|
where in this case we have
|
|
0:12:55
|
OSPF routing coming
|
|
0:12:57
|
in on the
|
|
0:12:58
|
outside interface
|
|
0:13:00
|
in on the DMZ
|
|
0:13:03
|
then may be we have some
|
|
0:13:06
|
VPN traffic, lets say router3 is setup as an easyVPN server
|
|
0:13:11
|
then we have one of the VPN
|
|
0:13:13
|
clients trying to connect to router3
|
|
0:13:16
|
if this traffic flow is dropped without logging it
|
|
0:13:20
|
then its going to be a little bit more difficult to troubleshoot
|
|
0:13:23
|
to figure out why exactly is this flow not working
|
|
0:13:28
|
So if we say drop log in the class default
|
|
0:13:31
|
its going to give us a little bit more visibility as to exactly whats going on
|
|
0:13:36
|
So I have the policy map outside to self policy, that is for class default
|
|
0:13:40
|
drop the traffic and log it
|
|
0:13:43
|
Now we will have the
|
|
0:13:45
|
zone pair security
|
|
0:13:47
|
outside, actually I would just say
|
|
0:13:50
|
thats right, outside to self
|
|
0:13:53
|
that is from source outside
|
|
0:13:56
|
to destination self
|
|
0:14:01
|
thats using the service policy type inspect
|
|
0:14:04
|
that is outside to self
|
|
0:14:07
|
policy
|
|
0:14:17
|
Okay, additionally I have the
|
|
0:14:19
|
pairing that is from the DMZ to myself
|
|
0:14:32
|
DMZ to myself
|
|
0:14:33
|
and this is going to have the policy that is the
|
|
0:14:39
|
DMZ to self policy
|
|
0:14:43
|
says firewall service policy attachment, policy DMZ to self policy does not exist
|
|
0:14:51
|
okay for a minute here lets say logging console at level 6 and logging
|
|
0:14:56
|
buffereed at, actually logging console at 5
|
|
0:15:01
|
because I want to remove somebodies messages from the console
|
|
0:15:05
|
okay I will clear the log buffer
|
|
0:15:07
|
what that meant here
|
|
0:15:08
|
is that when I tried to apply that policy
|
|
0:15:12
|
I didn't actually defined it first
|
|
0:15:16
|
So if we show run
|
|
0:15:18
|
section policy map
|
|
0:15:22
|
I want the
|
|
0:15:24
|
DMZ to self
|
|
0:15:27
|
that essentially is going to do the same thing here
|
|
0:15:30
|
So I will say this is
|
|
0:15:33
|
policy map type inspect
|
|
0:15:36
|
DMZ to self
|
|
0:15:40
|
that says
|
|
0:15:44
|
drop and log everything
|
|
0:15:47
|
then under the pairing
|
|
0:15:54
|
I have the policy, service policy type inspect
|
|
0:15:57
|
is DMZ to self policy
|
|
0:16:04
|
Now if we look at the show log to see the buffer
|
|
0:16:07
|
what we should see
|
|
0:16:09
|
is that router3 is telling us that there were packets being dropped
|
|
0:16:12
|
that were going to
|
|
0:16:14
|
224.0.0.5
|
|
0:16:18
|
from
|
|
0:16:19
|
the outside, from router2
|
|
0:16:22
|
and then eventually we will also see these
|
|
0:16:25
|
being dropped from the DMZ
|
|
0:16:30
|
where here this was a BGP pairing that this was dropped
|
|
0:16:34
|
and eventually also we will see this 224.0.0.5
|
|
0:16:37
|
this the OSPF controlled plane
|
|
0:16:41
|
and we could see now since these
|
|
0:16:43
|
flows are being dropped
|
|
0:16:45
|
the OSPF adjacencies are down
|
|
0:16:48
|
if I now look at the routing table
|
|
0:16:51
|
I will see that those OSPF routes are lost
|
|
0:16:58
|
So again you technically don't have to do this
|
|
0:17:02
|
with the policy map where you say log the class under the default class
|
|
0:17:08
|
but just for troubleshooting and for verification
|
|
0:17:11
|
makes a little bit easier to see exactly what flows are being denied to the network
|
|
0:17:19
|
So now if I wanted to allow this
|
|
0:17:21
|
I would need to manually match the traffic
|
|
0:17:24
|
we will say ip access list extended
|
|
0:17:27
|
we have
|
|
0:17:29
|
two
|
|
0:17:31
|
self ACL
|
|
0:17:35
|
its two different
|
|
0:17:36
|
separate ACLs, one is outside to self
|
|
0:17:40
|
that says permit OSPF
|
|
0:17:42
|
one DMZ to self
|
|
0:17:45
|
where we could see it, it makes the configuration very modular again
|
|
0:17:49
|
but its lot of syntax in order to piece it together
|
|
0:17:53
|
then I have two different class, class map type inspect
|
|
0:17:57
|
that says match any
|
|
0:17:59
|
outside to self
|
|
0:18:02
|
class
|
|
0:18:04
|
which says match access group with the name
|
|
0:18:09
|
outside to self acl
|
|
0:18:13
|
a another class that is DMZ to self class
|
|
0:18:20
|
lets say the DMZ to self ACL
|
|
0:18:25
|
and then finally
|
|
0:18:26
|
these classes
|
|
0:18:28
|
are going to be called from teh inspection policies
|
|
0:18:31
|
So if we show run section policy map
|
|
0:18:37
|
this will be the the outside to self policy
|
|
0:18:40
|
and the DMZ to self policy
|
|
0:18:46
|
Now just like the Modular Quality of Service
|
|
0:18:49
|
the order that the classes are called from the policies is significant
|
|
0:18:55
|
or its going to call it in a top down fashion just like the QoS policy
|
|
0:19:01
|
so here have my
|
|
0:19:04
|
DMZ to self policy, this says for class, DMZ to self class
|
|
0:19:09
|
pass this traffic
|
|
0:19:11
|
then likewise the
|
|
0:19:18
|
outside to self policy
|
|
0:19:21
|
says for clas
|
|
0:19:24
|
outside to self class
|
|
0:19:27
|
and you will see if you make an error here
|
|
0:19:30
|
it is case sensitive, so it will tell you, if the class does or does not exist
|
|
0:19:35
|
So for this traffic, I want to pass it
|
|
0:19:40
|
what we should see now, is that if we look at the show ip ospf neighbors
|
|
0:19:44
|
that router3 should be able to reestablish the ospf adjacencies
|
|
0:19:49
|
on both the DMZ
|
|
0:19:51
|
and on the outside interfaces
|
|
0:19:56
|
if we look at the show policy map
|
|
0:20:03
|
show policy map type inspect
|
|
0:20:07
|
for the zone pair sessions
|
|
0:20:10
|
and I could put the specific varying name there
|
|
0:20:14
|
like if I were to say
|
|
0:20:16
|
zone pair outside to self
|
|
0:20:18
|
sessions
|
|
0:20:24
|
I should see eventually that this is outside to sub class
|
|
0:20:28
|
is going to start getting packets
|
|
0:20:30
|
that is going to pass the traffic
|
|
0:20:34
|
so next lets turn logging back on and see if these packets are
|
|
0:20:37
|
still getting dropped
|
|
0:20:39
|
lets say login console 7
|
|
0:20:44
|
we see there is a log here, it says packets were dropped
|
|
0:20:48
|
dropping an unknown layer 4 session from
|
|
0:20:51
|
192.10.9.254 going to 224.0.0.5
|
|
0:20:56
|
on zone pair, DMZ to self
|
|
0:20:58
|
because class default says there is a drop action
|
|
0:21:06
|
and the same is from
|
|
0:21:09
|
same again, still can occur here from
|
|
0:21:13
|
DMZ to self
|
|
0:21:15
|
then likewise from outside to self
|
|
0:21:17
|
So now lets look at the config I want to know
|
|
0:21:20
|
why is that exception that I tried to configure
|
|
0:21:23
|
not actually working
|
|
0:21:33
|
where I have the outside to self class
|
|
0:21:37
|
says to pass the traffic
|
|
0:21:41
|
and the DMZ to self class, likewise says to pass the traffic
|
|
0:21:47
|
the outside to self class is calling the outside to self acl
|
|
0:21:52
|
DMZ to self class is calling the DMZ to self acl
|
|
0:21:55
|
So lets look at what the access list say
|
|
0:21:59
|
Show run section access list
|
|
0:22:12
|
we have DMZ to self acl, says to permit ospf
|
|
0:22:18
|
the same is true with the outside to self
|
|
0:22:26
|
so it looks like that this should be allowed
|
|
0:22:34
|
So lets try this, lets try shedding down the interfaces
|
|
0:22:45
|
then when we bring them up
|
|
0:22:48
|
I want to make sure that this is not a problem in the order of operation of the config
|
|
0:23:12
|
So now we can see on router3 that the ospf adjacencies are back
|
|
0:23:16
|
notice that I did reload the configuration
|
|
0:23:19
|
the router, that was nothing else like change in the configuration
|
|
0:23:22
|
So as a side note here, do not exclude
|
|
0:23:25
|
reloading as part of your troubleshooting process
|
|
0:23:28
|
if everything in your configuration looks to be solid
|
|
0:23:31
|
you tried removing the config, put it back and it is still not working
|
|
0:23:34
|
reload, comeback in a couple of minutes and see if that made any changes
|
|
0:23:37
|
sometimes when you are constantly adding or removing features
|
|
0:23:41
|
especially in a lot of these security topics
|
|
0:23:44
|
you can run into problems, where the router is simply denying the traffic where the feature is not working
|
|
0:23:49
|
and if you reload, when the router re initializes the
|
|
0:23:53
|
process in the order that it wants
|
|
0:23:56
|
then you may see that it starts being functional
|
|
0:24:01
|
Okay, so if we look at our configuration again here
|
|
0:24:04
|
the exceptions that we made
|
|
0:24:06
|
is that now we are inspecting traffic
|
|
0:24:09
|
as it is going from the
|
|
0:24:13
|
inside to myself
|
|
0:24:15
|
from the outside to myself, and from the DMZ to myself
|
|
0:24:20
|
where from the inside
|
|
0:24:22
|
router4 is now allowed to
|
|
0:24:25
|
to ping the router itself, router3 to firewall
|
|
0:24:28
|
but if we were to do this from the outside
|
|
0:24:32
|
we would see that these traffic flows are going to be denied
|
|
0:24:35
|
the only thing that is being allowed from the DMZ
|
|
0:24:38
|
to the router
|
|
0:24:39
|
and from the outside to the router, which is outside to self, DMZ to self
|
|
0:24:43
|
is the OSPF routing control plane
|
|
0:24:47
|
Now again if we were terminating VPN sessions on router3
|
|
0:24:51
|
it could have using it as an easyVPN server
|
|
0:24:54
|
we would need to account for that traffic going from the outside to self
|
|
0:24:59
|
so it would be things like our UDP port 500
|
|
0:25:03
|
which is for our ISAKMP
|
|
0:25:07
|
then either for the ESP or the AH
|
|
0:25:11
|
depending on how we are doing our tunnelling
|
|
0:25:13
|
may be we are doing transparent tunnelling with NAT reversal
|
|
0:25:17
|
which would be our UDP
|
|
0:25:19
|
4500 traffic
|
|
0:25:21
|
or may be we are doing transparent tunnelling over TCP 10000
|
|
0:25:26
|
but the key is that we would need to take this into account
|
|
0:25:29
|
because now those packets are locally destined to itself
|
|
0:25:33
|
that once the router recieves the ipsec tunnel and does the decapsulation
|
|
0:25:38
|
then its going to be treated as transit traffic
|
|
0:25:42
|
but if the tunnel is terminating on the router itself
|
|
0:25:45
|
we would need to take that into account
|
|
0:25:47
|
in the outside to self or the inside to self policy
|
|
0:25:53
|
Now the other example I want to show here
|
|
0:25:56
|
is what happens if we have any type of non standard application
|
|
0:26:00
|
that were trying to pass through the inspection engine
|
|
0:26:05
|
where we saw previously from router
|
|
0:26:07
|
4 on the inside
|
|
0:26:09
|
I said that it is traffic goes from the inside to out
|
|
0:26:13
|
were allowing ICMP, and we are allowing telnet
|
|
0:26:20
|
lets additionally say that now from router 4
|
|
0:26:22
|
I want to allow traceroute
|
|
0:26:27
|
and we saw this same type of problem when we were dealing with the reflexive access list
|
|
0:26:31
|
or contect based access control
|
|
0:26:33
|
where with a traceroute
|
|
0:26:36
|
the outbound request
|
|
0:26:38
|
is different than the inbound response
|
|
0:26:42
|
where the outbound flows
|
|
0:26:44
|
are going to be the UDP echoses
|
|
0:26:49
|
where essentially there are UDP packets, going to random high courts
|
|
0:26:52
|
but then the inbound return traffic
|
|
0:26:56
|
is going to be either an icmp time
|
|
0:26:59
|
exceeded
|
|
0:27:01
|
or TTL expires or time exceeded
|
|
0:27:05
|
or
|
|
0:27:07
|
the ISAKMP port
|
|
0:27:09
|
unreachable
|
|
0:27:11
|
where the port unreachable is coming from the final destination that we are trying to trace you
|
|
0:27:16
|
and the ICMP time exceeded is coming from the individual hops
|
|
0:27:19
|
from the source to the destination
|
|
0:27:23
|
Now to make this a little bit clear
|
|
0:27:25
|
exactly what types of flows that we need to allow
|
|
0:27:29
|
what I am going to o here
|
|
0:27:32
|
is when we look at
|
|
0:27:34
|
router3
|
|
0:27:36
|
and we see
|
|
0:27:39
|
the
|
|
0:27:40
|
inside to outside pairing
|
|
0:27:44
|
go to inside to outside pairing, it says
|
|
0:27:46
|
call the policy that is the inside to outside policy
|
|
0:27:51
|
if we show run section
|
|
0:27:54
|
inside to outside policy
|
|
0:27:59
|
this says it going to be, if its the outside, inside to outside
|
|
0:28:05
|
otherwise drop
|
|
0:28:07
|
So this means when traffic is going the reverse direction
|
|
0:28:10
|
the outside to inside
|
|
0:28:13
|
we are going to look at the CBAC state table
|
|
0:28:17
|
if an entry is there
|
|
0:28:18
|
the packet should be allowed
|
|
0:28:22
|
Now notice that I do not have an outside to inside pairing
|
|
0:28:27
|
if I do not have an outside to inside pairing, it means that all other
|
|
0:28:30
|
flows that are not already inspected
|
|
0:28:33
|
are going to be dropped
|
|
0:28:35
|
where we saw this previously like on router2
|
|
0:28:39
|
we are not able to ping
|
|
0:28:41
|
to devices on the inside, we are not able to ping router4
|
|
0:28:45
|
but the problem is now, since 3 does not have
|
|
0:28:49
|
a specific outside to inside policy
|
|
0:28:52
|
its not going to generate log message for these dropped packets
|
|
0:28:57
|
So before going any further
|
|
0:28:59
|
to make it a little bit clearer exactly, what we need to manually allow
|
|
0:29:04
|
I am going to
|
|
0:29:06
|
first I am going to lower the console login, lets lower this to 5
|
|
0:29:10
|
then I am going to create an explicit outside to inside pairing
|
|
0:29:15
|
where I will say that from policy map outside to
|
|
0:29:20
|
outside to inside policy
|
|
0:29:24
|
says for class, class - [dash] default
|
|
0:29:30
|
class default drop and log
|
|
0:29:44
|
okay, next we have the pairing
|
|
0:29:47
|
which is the zone pair
|
|
0:29:51
|
zone pair security
|
|
0:29:52
|
this is going to be outside to inside pairing
|
|
0:29:58
|
which is then going to call outside to inside policy
|
|
0:30:01
|
So outside to inside pairing
|
|
0:30:05
|
says the source of the traffic
|
|
0:30:06
|
is the outside zone
|
|
0:30:09
|
the destination is the inside zone
|
|
0:30:13
|
the service policy type inspect
|
|
0:30:15
|
is the outside to inside policy
|
|
0:30:21
|
so this firewall policy attachment failed, policy outside to inside policy does not exist
|
|
0:30:28
|
where it is referenced here
|
|
0:30:32
|
by what do I leave out
|
|
0:30:37
|
should say policy map type inspect
|
|
0:30:41
|
and actually should I realize that because thats why it didn't take the
|
|
0:30:44
|
the drop and log option
|
|
0:30:47
|
where this policy here, this is an MQC policy
|
|
0:30:51
|
for QoS
|
|
0:30:52
|
I need to say this is policy map of
|
|
0:30:56
|
type inspect
|
|
0:30:58
|
it says for class, class-default
|
|
0:31:00
|
drop and log
|
|
0:31:03
|
So now under the
|
|
0:31:06
|
the outside to inside pairing
|
|
0:31:15
|
policy map type, or not, policy map service policy
|
|
0:31:19
|
service policy type inspect, outside to inside policy
|
|
0:31:23
|
okay, now thats attached
|
|
0:31:25
|
Now if were to turn logging back on
|
|
0:31:29
|
logging console of level 7
|
|
0:31:31
|
and go to someone on the outside
|
|
0:31:36
|
which is router2 here and I am going ping to router4
|
|
0:31:40
|
the packet is still going to be denied like it was before
|
|
0:31:43
|
the only difference is that now router3 is generating a log message for
|
|
0:31:48
|
because the outside to inside pairing, says the class default drop the traffic and log
|
|
0:31:54
|
however for the other flows
|
|
0:31:57
|
that are coming from the inside
|
|
0:31:59
|
out and are inspected
|
|
0:32:02
|
these will not be denied by the outside to inside policy
|
|
0:32:09
|
So its an issue of the order of operations here
|
|
0:32:12
|
where whats happening is that
|
|
0:32:15
|
3 says its packets come in on inside
|
|
0:32:19
|
and go out outside
|
|
0:32:22
|
make a copy of these in the state table
|
|
0:32:29
|
Now when packets return and they are going from the outside to inside
|
|
0:32:34
|
before I actually look at the outside to inside pairing
|
|
0:32:38
|
the first thing I am going to do is check the state table
|
|
0:32:41
|
if the session already exists, allow it in
|
|
0:32:45
|
if the session does not exist
|
|
0:32:47
|
then look at the specific pairing that is going from outside to inside
|
|
0:32:51
|
to see do we have a manual exception
|
|
0:32:54
|
or do we have a manual inspection
|
|
0:32:57
|
or I could inspect traffic as its going from the outside to in
|
|
0:33:01
|
because the policy is completely upto me
|
|
0:33:03
|
depending on how I am configuring the pairing and then how I am configuring the policy map
|
|
0:33:09
|
but the point here is that even though I am telling router3 to drop all traffic
|
|
0:33:14
|
as it goes from outside to inside
|
|
0:33:16
|
its going to be those flows with the exception
|
|
0:33:20
|
of whats already been
|
|
0:33:21
|
being inspected inside to out
|
|
0:33:25
|
so we see that router4 can telnet to 2
|
|
0:33:30
|
but 2 is not going to be able to telnet to 4
|
|
0:33:33
|
because there is no entry in this state table
|
|
0:33:36
|
which means this falls back to the outside
|
|
0:33:39
|
to inside pairing
|
|
0:33:42
|
and a class default that says drop the traffic
|
|
0:33:49
|
So next lets look at our traceroute packets
|
|
0:33:54
|
now from router4, we should be able to reach anyone
|
|
0:33:57
|
on the outside network
|
|
0:33:59
|
and lets say we were to go as far as
|
|
0:34:03
|
router1
|
|
0:34:06
|
where we are trying to get traffic from 4 to 3
|
|
0:34:09
|
3 to 2 , 2 to 1
|
|
0:34:12
|
and then to return back
|
|
0:34:17
|
from router4
|
|
0:34:19
|
if we were to telnet to 200.0.0.1
|
|
0:34:23
|
we could see that there is nothing wrong with this flow because it is being inspected
|
|
0:34:27
|
however if I were to traceroute
|
|
0:34:30
|
to router1
|
|
0:34:33
|
even though the ICMP flows are being inspected
|
|
0:34:37
|
the issue is that the outbound flow
|
|
0:34:41
|
is different than the return
|
|
0:34:44
|
inbound flow
|
|
0:34:47
|
and says here that the packets are being dropped
|
|
0:34:50
|
it doesn't tell us exactly what the packets are
|
|
0:34:53
|
just that they are being denied
|
|
0:34:57
|
now if we were to look at a detail of the bug, like to bug ip packet detail, or to bug ip packet dump
|
|
0:35:02
|
we would see those return
|
|
0:35:04
|
packets coming in on the outside and then being denied
|
|
0:35:09
|
Now if we look at the show
|
|
0:35:11
|
policy map type inspect
|
|
0:35:16
|
zone pair sessions
|
|
0:35:20
|
and specifically I am looking for the
|
|
0:35:22
|
the inside to the outside
|
|
0:35:32
|
for the inside to the outside policy
|
|
0:35:35
|
it says that if the traffic is not in, the inside to outside class
|
|
0:35:40
|
its going to get dropped
|
|
0:35:44
|
so one thing I actually may want to change here is
|
|
0:35:49
|
in the inside to outside class
|
|
0:35:52
|
likewise drop the traffic and log it
|
|
0:35:57
|
and again the only reason we are doing this is for visibility of the config, to figure out exactly
|
|
0:36:02
|
what holes do we need to poke in the firewall
|
|
0:36:06
|
okay, router3 says I am dropping an UDP sessions
|
|
0:36:10
|
it came from router4, its trying to get to router1
|
|
0:36:14
|
this is the outbound portion of the traceroute
|
|
0:36:20
|
Now even if I were to allow this packet out
|
|
0:36:25
|
the issue is that when it returns from the outside back in
|
|
0:36:29
|
the flow is going to be different
|
|
0:36:33
|
because for a traceroute the outbound flow is UDP
|
|
0:36:36
|
the return inbound flow is an ICMP time exceeded
|
|
0:36:39
|
and an ICMP port unreachable
|
|
0:36:42
|
so to fix this, I am going to have to make two
|
|
0:36:46
|
separate unidirectional exceptions with the pass keyword
|
|
0:36:50
|
specifically
|
|
0:36:53
|
I am going to have to match traffic that is going from in to out
|
|
0:36:58
|
and say if it is the UDP packets that are
|
|
0:37:03
|
the traceroute requests
|
|
0:37:07
|
I need to pass this
|
|
0:37:10
|
Now I am not going to send them through the inspection engine
|
|
0:37:13
|
because if I were to inspect them, the router would
|
|
0:37:17
|
try to receive the, in the reverse direction
|
|
0:37:21
|
the mere image of the reply
|
|
0:37:24
|
but the problem here is that we traceroute the request and response of two different protocols
|
|
0:37:28
|
so instead of inspecting it, I need to pass it
|
|
0:37:31
|
then I am going to other direction, I am going from out
|
|
0:37:34
|
to in
|
|
0:37:36
|
I need to say that if it is an ICMP
|
|
0:37:40
|
time exceeded or ttl expired
|
|
0:37:43
|
or ICMP port
|
|
0:37:48
|
port unreachable
|
|
0:37:52
|
that likewise I need to pass this
|
|
0:37:56
|
so this is the case where you would want to use the pass option
|
|
0:37:59
|
that you have some sort of non standard protocol
|
|
0:38:02
|
that cannot be matched by the inspection engine
|
|
0:38:05
|
but you still need to manually allow it through
|
|
0:38:10
|
but again the key here is that it passes only one direction
|
|
0:38:14
|
if I pass the traffic inside out
|
|
0:38:16
|
does not mean that the traffic is automatically passed on the outside back in
|
|
0:38:22
|
So now to make these changes, lets look at whats the current configuration of the policy
|
|
0:38:28
|
So on 3 again lets say logging console at level 5
|
|
0:38:32
|
then show run, lets just look at the full policy
|
|
0:38:39
|
and you could see the syntax is starting to get pretty big
|
|
0:38:43
|
even though the overall logic of the policies here
|
|
0:38:47
|
are pretty straight forward
|
|
0:38:49
|
So this is definitely one of those configurations
|
|
0:38:51
|
that you probably want to do in notepad or your text editor
|
|
0:38:54
|
to try to keep
|
|
0:38:57
|
a close eye on exactly what the
|
|
0:38:59
|
the flows are we are trying to do, trying to match
|
|
0:39:03
|
Hey, so I need the inside to outside
|
|
0:39:07
|
and the outside
|
|
0:39:10
|
to inside traffic
|
|
0:39:13
|
so there is, inside to outside
|
|
0:39:17
|
then I have inside to outside
|
|
0:39:23
|
I already have the zone pairing setup, so I don't need to change that
|
|
0:39:32
|
what I now need to change is
|
|
0:39:34
|
exactly whats matched in
|
|
0:39:36
|
the policy thats going from in to out and from out back in
|
|
0:39:41
|
essentially what I need to do
|
|
0:39:44
|
is from in to out
|
|
0:39:47
|
I would need to have another class, will say class type inspect
|
|
0:39:51
|
that is going to be inside
|
|
0:39:53
|
to outside exceptions
|
|
0:39:58
|
inside to outside exceptions class
|
|
0:40:01
|
where for this class I am going to pass the traffic
|
|
0:40:08
|
where this is different
|
|
0:40:10
|
than the
|
|
0:40:12
|
other classes that were doing the inspections
|
|
0:40:16
|
and on the outside to inside I am going to do the same thing
|
|
0:40:19
|
what this is going to allow me to do
|
|
0:40:22
|
is that if I want to make a change later
|
|
0:40:25
|
that is doing another manual exception
|
|
0:40:28
|
the only thing I would now need to do
|
|
0:40:32
|
is add the match to that particular class
|
|
0:40:35
|
and this classes are going to say match any
|
|
0:40:39
|
or I have now the inside to outside exceptions
|
|
0:40:44
|
and the reverse directions
|
|
0:40:48
|
the outside to inside exceptions
|
|
0:40:52
|
and you could see just by looking side by side in the text editor
|
|
0:40:56
|
makes it a little bit clear as to exactly what we are trying to do
|
|
0:41:00
|
Okay, from these classes I am trying to match access list
|
|
0:41:03
|
match access group name
|
|
0:41:06
|
inside to outside
|
|
0:41:08
|
exceptions acl
|
|
0:41:12
|
where in the reverse direction
|
|
0:41:15
|
it is
|
|
0:41:17
|
the opposite, this is the outside
|
|
0:41:20
|
to inside exceptions acl
|
|
0:41:24
|
where now I have the actual access list
|
|
0:41:27
|
IP access list extended
|
|
0:41:31
|
inside to outside exceptions acl, that says permit
|
|
0:41:36
|
UDP
|
|
0:41:38
|
any any in the range of
|
|
0:41:41
|
and we could see this from router3 what we could match
|
|
0:41:53
|
its somewhere in the 33000 range
|
|
0:41:56
|
Now we could math these ports exactly
|
|
0:41:59
|
but its kind of a fuzzy match, here lets just say anything thats from 33000
|
|
0:42:05
|
to lets say 35000
|
|
0:42:08
|
So that should account for any of my outbound traceroute request
|
|
0:42:12
|
now on the reverse direction
|
|
0:42:17
|
the outside
|
|
0:42:19
|
to inside
|
|
0:42:21
|
this is going to match
|
|
0:42:23
|
ICMP
|
|
0:42:25
|
any any time exceeded
|
|
0:42:28
|
and
|
|
0:42:29
|
any any port unreachable
|
|
0:42:35
|
Now the additional thing that I have to account for when I actually
|
|
0:42:38
|
apply this configuration
|
|
0:42:40
|
is that I need to make sure in the policies
|
|
0:42:43
|
that are these two down here
|
|
0:42:47
|
I need to make sure the order of these are correct
|
|
0:42:51
|
because remember just like the Modular Quality of Service
|
|
0:42:54
|
these policies are processed in the top down directions
|
|
0:43:01
|
So on router3 lets see if its going to take these syntax
|
|
0:43:08
|
because of the syntax looks good, lets look at the result of it
|
|
0:43:12
|
I need to make sure that this policy map that is saying pass
|
|
0:43:17
|
that this is happening before the class default, which is good
|
|
0:43:22
|
Now I may acutally want to reorder these, where the
|
|
0:43:25
|
may be the inside to outside exceptions goes before the exceptions class
|
|
0:43:30
|
really depends on
|
|
0:43:31
|
on if the matches overlap with to begin with
|
|
0:43:36
|
So lets try this out now, on router4 lets do the traceroute
|
|
0:43:47
|
and on 3 lets turn the logging back on
|
|
0:43:49
|
So logging console 7
|
|
0:43:54
|
and router3 says that it is dropping
|
|
0:44:00
|
outside to inside traffic based on class default
|
|
0:44:07
|
Now we didn't match the
|
|
0:44:09
|
inside to outside, so lets look at that on a
|
|
0:44:11
|
reverse direction, lets say show run
|
|
0:44:14
|
section
|
|
0:44:20
|
outside to inside
|
|
0:44:27
|
Now I have the outside to inside policy
|
|
0:44:32
|
that says for
|
|
0:44:36
|
outside to inside exceptions class
|
|
0:44:40
|
pass the traffic
|
|
0:44:42
|
outside to inside exceptions class says match
|
|
0:44:44
|
outside to inside exceptions ACL
|
|
0:44:48
|
outside to inside exception acl says permit the ICMP time exceeded in the port unreachable
|
|
0:44:53
|
So I actually should be allowing the traffic in
|
|
0:44:56
|
most likely what it means
|
|
0:44:58
|
is that I need to remove the firewall policy
|
|
0:45:01
|
and the try to reapply it
|
|
0:45:03
|
so lets do this, lets take this portion out
|
|
0:45:07
|
the zone pairing
|
|
0:45:16
|
then reapply this
|
|
0:45:24
|
where now its working
|
|
0:45:26
|
So again when you are making changes to the firewall policies
|
|
0:45:29
|
and the same is going to be true with a lot of IPSec configurations, when we get to that
|
|
0:45:34
|
its very sensitive to the order of operations
|
|
0:45:37
|
they typically with an IPSec config
|
|
0:45:40
|
if you make change you need to remove the cryptomap
|
|
0:45:43
|
and then reapply it
|
|
0:45:45
|
or in the case of, like a tunnel interface we would need to
|
|
0:45:47
|
to remove the tunnel protection and then put it back
|
|
0:45:49
|
or shut the link down and bring it back up
|
|
0:45:51
|
same is true here with the firewall policy
|
|
0:45:55
|
the only thing that changed from here to here
|
|
0:45:58
|
is that I removed the policy and reapplied it
|
|
0:46:01
|
I didn't changed in the actual configuration
|
|
0:46:04
|
what we can see now, when we look at the
|
|
0:46:07
|
the show
|
|
0:46:10
|
policy map type inspect
|
|
0:46:14
|
zone pair
|
|
0:46:16
|
I should see therefore the inside to outside
|
|
0:46:20
|
there are matches on
|
|
0:46:24
|
the exceptions class
|
|
0:46:28
|
so these 49 packets that were passed, these were the UDP packets going out
|
|
0:46:33
|
then for the outside back inside
|
|
0:46:42
|
outside to inside
|
|
0:46:44
|
says with this exception class
|
|
0:46:47
|
six packets were passed
|
|
0:46:49
|
these were the ICMP time exceeded and the ICMP port unreachables
|
|
0:46:56
|
So we could see from the configuration, the final result of this is much more complicated
|
|
0:47:01
|
from an implementation point of view
|
|
0:47:03
|
when we compare it to the Content Based Access Control to the CBAC syntax
|
|
0:47:08
|
but again the advantage
|
|
0:47:10
|
is that it makes the configuration much more modular
|
|
0:47:13
|
and then if there are three or more zones
|
|
0:47:17
|
so inside outside DMZ
|
|
0:47:19
|
or may be inside1 and inside2, outside1 outside2
|
|
0:47:24
|
it makes it much more manageable to control
|
|
0:47:26
|
how is the traffic going to be processed when we go from the inside to outside
|
|
0:47:30
|
versus inside to DMZ or vice versa
|
