|
0:00:13
|
In our next security section we're going to talk about the
|
|
0:00:15
|
reflexive access lists which have more functionality
|
|
0:00:20
|
versus the establish keyword in the ACL that we used previously
|
|
0:00:24
|
but it does not have an application level inspection
|
|
0:00:28
|
that both the CBAC and the zone based policy firewall do.
|
|
0:00:34
|
Now the basic logic for the reflexive access list
|
|
0:00:36
|
is that we are going to watch traffic as it leaves the
|
|
0:00:39
|
network and generally in an outbound access list is going
|
|
0:00:44
|
to trigger a mirrored entry to appear in a state table.
|
|
0:00:49
|
So a state table just like an ASA firewall would or
|
|
0:00:52
|
like the network address translation process would.
|
|
0:00:55
|
So the router's keeping track of the traffic as it leaves the network.
|
|
0:01:00
|
As traffic returns back inbound, a check occurs
|
|
0:01:04
|
against the state table to see if the returning
|
|
0:01:07
|
traffic is the opposite of what the leaving traffic was.
|
|
0:01:15
|
Now again, the limitation to this feature is that it is
|
|
0:01:18
|
only going to work with standard TCP and UDP based
|
|
0:01:21
|
applications. If there's any difference in what the outbound
|
|
0:01:25
|
flow is versus the inbound flow, reflexive ACL is not
|
|
0:01:29
|
going to be able to deal with that.
|
|
0:01:32
|
So applications like SIP for Voice over IP or trace route
|
|
0:01:38
|
would be a good example where the outbound
|
|
0:01:40
|
traffic flow is different than the inbound traffic flow
|
|
0:01:44
|
or active FTP where the client connects to the server and then the
|
|
0:01:48
|
server is doing an unsolicited connection request back to the
|
|
0:01:51
|
client, those would not be able to be permitted
|
|
0:01:54
|
dynamically or automatically based on the reflexive access list.
|
|
0:01:58
|
So we'd have to go a little bit further out of the way
|
|
0:02:01
|
to do some manual exceptions for those particular types of
|
|
0:02:04
|
applications.
|
|
0:02:09
|
So in our case here, we're going to do the same configuration on
|
|
0:02:12
|
Router 5 as we did before
|
|
0:02:15
|
where we want to say that the link to Switch 2
|
|
0:02:19
|
this is going to be the inside network and the link to the
|
|
0:02:22
|
frame relay is going to be the outside network.
|
|
0:02:26
|
So the ultimate goal is that we want traffic to come from the
|
|
0:02:28
|
inside and go out and then return, but we do not
|
|
0:02:34
|
want unsolicited requests to come from the outside
|
|
0:02:37
|
and go in.
|
|
0:02:41
|
So ultimately once our configuration is done, Switch 4 should be able to
|
|
0:02:45
|
telnet to anyone on the outside or ping or trace route to
|
|
0:02:48
|
anyone on the outside, but Switch 1 is not going to be able to
|
|
0:02:52
|
ping Switch 4 or to telnet to Switch 4
|
|
0:02:56
|
So inside to out and then return is going to be allowed
|
|
0:02:59
|
but not from outside to in.
|
|
0:03:02
|
So configuration wise, the first thing we need to do is create
|
|
0:03:05
|
our reflexive access list that is going to watch the traffic
|
|
0:03:10
|
as it is leaving the network where in this case we're saying
|
|
0:03:14
|
watch any TCP traffic and we're going to keep track of it
|
|
0:03:17
|
in a state table that is named stateful.
|
|
0:03:22
|
For the access list that comes back inbound, we are going to
|
|
0:03:26
|
evaluate the state table to see if the traffic already
|
|
0:03:29
|
left the network and if there is an active entry in
|
|
0:03:33
|
there, it's going to be allowed.
|
|
0:03:37
|
So the order of the statements in the inbound access list is going to
|
|
0:03:41
|
be significant.
|
|
0:03:44
|
Now one of the considerations for the reflexive ACL
|
|
0:03:47
|
is that the local traffic is not going to be classified by the
|
|
0:03:50
|
outbound access list.
|
|
0:03:53
|
And this isn't necessarily a problem with reflexive access lists
|
|
0:03:56
|
again, it's just in general that outbound ACLs do not affect the
|
|
0:04:00
|
locally generated traffic.
|
|
0:04:03
|
So this means any of our routing control plane
|
|
0:04:06
|
whether this is IGP, BGP, PIM
|
|
0:04:10
|
or the local pings, local telnet, local trace route that's not going
|
|
0:04:14
|
to be matched by the reflexive ACL.
|
|
0:04:17
|
So we'll see a couple different possible solutions. The easiest way
|
|
0:04:22
|
is to simply do a manual exception
|
|
0:04:24
|
for the inbound traffic in the access list
|
|
0:04:28
|
or a further workaround would be to do local policy
|
|
0:04:31
|
routing which is going to force the router to treat its
|
|
0:04:34
|
own traffic as if it was transit traffic.
|
|
0:04:40
|
So the second option is kind of like a stupid router trick
|
|
0:04:42
|
but you can get it to treat its own locally generated
|
|
0:04:45
|
traffic as transit which means it would be subject to the
|
|
0:04:49
|
outbound ACL classification.
|
|
0:04:52
|
So on Router 5, our first step is to classify the traffic
|
|
0:04:54
|
as it is leaving the network.
|
|
0:04:57
|
We're going to say this is going to be for all TCP
|
|
0:04:59
|
UDP and ICMP flows.
|
|
0:05:07
|
So on Router 5, let's configure ip access list extended
|
|
0:05:15
|
this is on the outside interface out.
|
|
0:05:21
|
Ok, I'll say outside interface outbound.
|
|
0:05:23
|
So we know what particular interface it's being applied to
|
|
0:05:25
|
and what is the direction.
|
|
0:05:29
|
I'm going to permit any TCP traffic
|
|
0:05:33
|
and reflect it to whatever the state table is, so this is
|
|
0:05:37
|
some name that I'm creating.
|
|
0:05:40
|
The same for all of my UDP flows.
|
|
0:05:45
|
And for ICMP
|
|
0:05:50
|
but again, the key is that we cannot do application level
|
|
0:05:55
|
inspections, so other things like ESP or AH for IPSec tunnels
|
|
0:06:01
|
they would not properly work through a reflexive access list.
|
|
0:06:10
|
Now on the reverse path that is going to be the
|
|
0:06:11
|
outside interface inbound, so ip access list extended
|
|
0:06:16
|
outside inbound
|
|
0:06:20
|
I want to evaluate that state table.
|
|
0:06:25
|
So if the entries already exist in there, they are going
|
|
0:06:29
|
to be permitted.
|
|
0:06:31
|
But in addition to this, I need to make sure to allow my
|
|
0:06:33
|
control plane traffic.
|
|
0:06:35
|
So I'm going to permit EIGRP any any
|
|
0:06:39
|
and for everything else, I'm going to deny it
|
|
0:06:41
|
and then log it.
|
|
0:06:45
|
Normally the last step you would not need to do because the
|
|
0:06:48
|
router's going to have an implicit deny on the access list.
|
|
0:06:52
|
Also you normally wouldn't want to log a deny for everything
|
|
0:06:57
|
because again, the logging is going to cause the router to
|
|
0:07:00
|
process switch the traffic.
|
|
0:07:05
|
So now I have these two access lists.
|
|
0:07:07
|
One is going to be applied on the frame relay outbound.
|
|
0:07:11
|
So ip access group outside outbound is applied out
|
|
0:07:19
|
access group outside inbound
|
|
0:07:22
|
is applied in.
|
|
0:07:26
|
If we look at the show access list
|
|
0:07:29
|
we see that there are hits on the EIGRP packets coming
|
|
0:07:33
|
in so that is properly allowing our control plane traffic
|
|
0:07:39
|
then if we were to go behind Router 5
|
|
0:07:41
|
let's say from Switch 4
|
|
0:07:44
|
and Switch 4 does a ping
|
|
0:07:48
|
out to anywhere else in the network
|
|
0:07:57
|
we should ideally see that this is going to be allowed
|
|
0:07:59
|
in and Router 5 is going to keep a copy of this.
|
|
0:08:04
|
Now notice that Router 5 did create the entry in the state table
|
|
0:08:07
|
but the packet was still dropped
|
|
0:08:10
|
and I believe this is because of Router 6
|
|
0:08:13
|
the previous filter that we were doing.
|
|
0:08:17
|
So within the scope of this exam, you have to be careful
|
|
0:08:20
|
with your filtering policies because it can break a lot of
|
|
0:08:24
|
your other configurations.
|
|
0:08:26
|
So your previous IGP configuration or BGP
|
|
0:08:30
|
multicast IPv6 all of that stuff is going to be subject to
|
|
0:08:34
|
any filtering in the data plane.
|
|
0:08:38
|
One way that you can make sure that you don't run into a
|
|
0:08:41
|
problem with this is any time you apply an access
|
|
0:08:44
|
list on an interface
|
|
0:08:46
|
just take a note of it in the diagram.
|
|
0:08:49
|
So I would then know I have ACL 105
|
|
0:08:53
|
in on Router 6
|
|
0:08:55
|
So if I have some sort of problem later with traffic transiting
|
|
0:09:00
|
I could look at Router 6 and figure out is that particular
|
|
0:09:02
|
access list dropping the traffic.
|
|
0:09:05
|
But in our case now, I'm just going to remove this on
|
|
0:09:07
|
Router 6 to skip over that list.
|
|
0:09:12
|
We can see now the pings are being allowed through
|
|
0:09:16
|
and Router 6 should be or Router 5 excuse me
|
|
0:09:19
|
Router 5 should be keeping track of this in its state table
|
|
0:09:22
|
which it is.
|
|
0:09:25
|
If we were to telnet from Switch 4 out to Switch 3
|
|
0:09:33
|
we can see likewise that's allowed.
|
|
0:09:36
|
Router 5 should be keeping this in the state table.
|
|
0:09:41
|
It says on the return trip, I'm going to permit any
|
|
0:09:46
|
TCP that came from Switch 3 that is sourced from port 23
|
|
0:09:54
|
going to Switch 4 at the destination port 43922
|
|
0:10:02
|
so source port 23 that's our well known port
|
|
0:10:05
|
destination 43922 this is the random port that they negotiated.
|
|
0:10:10
|
If we were to go outside of the network, let's say
|
|
0:10:13
|
on Switch 3 and try to telnet to Switch 4
|
|
0:10:19
|
this is going to be denied.
|
|
0:10:22
|
If we look at Router 5, we should see that the access
|
|
0:10:24
|
list log entry comes up it says this hit our last
|
|
0:10:28
|
statement which it was denied.
|
|
0:10:32
|
So currently the filter's working. It's allowing traffic to
|
|
0:10:35
|
come from the inside and go out and then return
|
|
0:10:39
|
but it is not allowing traffic from the outside unsolicited
|
|
0:10:42
|
to be sent inbound.
|
|
0:10:49
|
Now again, the two issues we run into here are that the
|
|
0:10:53
|
locally generated traffic is not going to be matched by the
|
|
0:10:56
|
access list and we're not going to be able to support any
|
|
0:11:00
|
non-standard TCP or UDP based applications.
|
|
0:11:04
|
So non-standard means anything that has a different traffic flow
|
|
0:11:08
|
outbound than is inbound.
|
|
0:11:11
|
So we would not be able to do Voice over IP calls
|
|
0:11:15
|
through the access list or we would not be able to do
|
|
0:11:19
|
normal active FTP downloads.
|
|
0:11:24
|
If on Switch 4, we tried to do a trace route
|
|
0:11:29
|
to switch 3
|
|
0:11:36
|
we see the trace route dies once it goes past Router 5
|
|
0:11:40
|
Specifically if we look at Router 5 it says that
|
|
0:11:42
|
ICMP packets are being denied inbound
|
|
0:11:46
|
that are coming from Router 3
|
|
0:11:50
|
Switch 1
|
|
0:11:53
|
and Switch 3
|
|
0:11:57
|
This number here, this is the type and the code.
|
|
0:12:03
|
So this is ICMP type 11 code 0
|
|
0:12:06
|
ICMP type 3 code 3
|
|
0:12:10
|
The problem is based on this, we really don't know
|
|
0:12:12
|
what exactly those code numbers are unless we
|
|
0:12:15
|
memorize them.
|
|
0:12:18
|
So let's look this up here. Let's search for the ICMP type codes.
|
|
0:12:28
|
Where again, this was type 11 code 0
|
|
0:12:33
|
where type 11 is time exceeded
|
|
0:12:37
|
type 3 is destination unreachable
|
|
0:12:43
|
and if we look at inside type 3
|
|
0:12:46
|
the sub code 3 is port unreachable.
|
|
0:12:53
|
So essentially what this means is that when we are
|
|
0:12:55
|
sending the trace route requests outbound
|
|
0:12:59
|
Switch 4 is sending a UDP packet
|
|
0:13:04
|
that is going out.
|
|
0:13:07
|
This UDP packet has a destination address
|
|
0:13:10
|
of whatever we were tracing here which in this case was
|
|
0:13:17
|
155.28.9.9
|
|
0:13:19
|
so the destination is 155.28.9.9
|
|
0:13:24
|
with a time to live of one.
|
|
0:13:29
|
This means that when Switch 2 receives the packet
|
|
0:13:32
|
the TTL is decremented to zero
|
|
0:13:34
|
and it replies back with icmp time exceeded.
|
|
0:13:39
|
That was the first message that we saw that was dropped
|
|
0:13:43
|
in the ACL, so this is ICMP type 11
|
|
0:13:45
|
this is the time exceeded or the TTL expired.
|
|
0:13:51
|
The TTL is then going to increase on a hop by hop basis
|
|
0:13:56
|
until we get all the way to the final destination
|
|
0:14:03
|
which in the case the final hop looks at whatever the
|
|
0:14:07
|
UDP port is, so it's going to be some random value
|
|
0:14:12
|
and unless they're actually listening at this port number with
|
|
0:14:15
|
a service, they are going to reply back with port unreachable.
|
|
0:14:22
|
So the problem with trace route and the active firewall
|
|
0:14:25
|
is that it is a non-standard application. The outbound flow
|
|
0:14:29
|
is different than the inbound flow.
|
|
0:14:32
|
If we were to look at Router 5's access list
|
|
0:14:36
|
Router 5 thinks that it should be allowing back in UDP packets
|
|
0:14:42
|
from the final destination going back to Switch 4
|
|
0:14:47
|
and we could see these port numbers are essentially random
|
|
0:14:50
|
values that the router is trying to generate in order to
|
|
0:14:53
|
get the trace route response.
|
|
0:14:56
|
But the trace route response is not going to be UDP
|
|
0:15:00
|
it's going to be an ICMP type code.
|
|
0:15:04
|
So again, any time the outbound flow is not
|
|
0:15:07
|
an exact mirror image of the inbound flow
|
|
0:15:10
|
reflexive ACL is not going to be able to deal with it.
|
|
0:15:17
|
In order to manage this particular trace route, the only thing that we can do
|
|
0:15:20
|
on Router 5 is to manually allow the flow back inbound.
|
|
0:15:26
|
So if we show run section access list
|
|
0:15:31
|
for access list outside in
|
|
0:15:35
|
because again, this is the one that is denying the traffic
|
|
0:15:40
|
I would need to say before the deny let's say sequence
|
|
0:15:44
|
number 1 is to permit icmp any any that is
|
|
0:15:49
|
time exceeded.
|
|
0:15:52
|
So either time exceeded or TTL expired
|
|
0:15:58
|
or TTL exceeded, it's basically the same type code.
|
|
0:16:01
|
So time exceeded or TTL exceeded
|
|
0:16:04
|
then port unreachable.
|
|
0:16:10
|
So I need to match both of these.
|
|
0:16:12
|
Time exceeded and port unreachable.
|
|
0:16:15
|
If we look at the show access list on Router 5
|
|
0:16:19
|
we should get hits on both entry number one and two.
|
|
0:16:25
|
So from Switch 4, let's do the trace route out
|
|
0:16:27
|
we see now the responses are allowed back in.
|
|
0:16:32
|
On Router 5, when we look at the show access list
|
|
0:16:36
|
these are the time exceeded from the hops in the middle
|
|
0:16:40
|
and then the port unreachable from the final destination.
|
|
0:16:44
|
Additionally, if we were to send traffic locally from
|
|
0:16:47
|
Router 5, we would not be able to ping to any destination
|
|
0:16:52
|
because this is being denied as it comes in on the outside
|
|
0:16:56
|
interface and we would not be able to telnet or trace route
|
|
0:17:01
|
basically do any locally generated traffic
|
|
0:17:06
|
because the outbound ACL is not classifying this local traffic
|
|
0:17:11
|
and I do not have a manual entry that is allowing it back inbound.
|
|
0:17:16
|
So again, there's basically two possible ways to solve this.
|
|
0:17:20
|
I could just edit the access list that's going to allow the local
|
|
0:17:24
|
traffic to go back into Router 5
|
|
0:17:28
|
or I could use local policy routing in order to get
|
|
0:17:31
|
Router 5 to treat its own locally generated traffic
|
|
0:17:35
|
as if it was transit traffic.
|
|
0:17:38
|
Now generally, you wouldn't want to do the second solution
|
|
0:17:41
|
in a real design because it's basically a hack on the process
|
|
0:17:44
|
and you could break other control plane protocols
|
|
0:17:48
|
but for the purpose of the lab exam, you could technically do this.
|
|
0:17:51
|
Now the way to do it on Router 5 would be to create
|
|
0:17:55
|
a route map that is for the local policy route
|
|
0:17:59
|
and I'll simply say set interface loopback 0
|
|
0:18:05
|
so I'm going to loop the traffic back to myself
|
|
0:18:11
|
then I'll say ip policy or ip local policy
|
|
0:18:20
|
ip local policy the route map is local policy route
|
|
0:18:28
|
if we debug ip policy
|
|
0:18:32
|
and now from Router 5 I'll do a ping
|
|
0:18:37
|
it says the source is local this was policy routed
|
|
0:18:42
|
to the loopback
|
|
0:18:44
|
then it was received in on the loopback and treated as
|
|
0:18:48
|
transit traffic which then was hit by the access list.
|
|
0:18:55
|
So I'm essentially sending the traffic out of Router 5 looping it back
|
|
0:18:58
|
in and then it can be classified by the ACL.
|
|
0:19:04
|
So now likewise, if I were to telnet to any destinations
|
|
0:19:09
|
that's going to be allowed because the access list is matched.
|
|
0:19:16
|
and if we were to put any type of packet counter for the
|
|
0:19:20
|
outside outbound lists, we would see Router 5's local traffic.
|
|
0:19:25
|
We can see the first entry here this is the telnet that came
|
|
0:19:28
|
from Router 5 where the second entry is the
|
|
0:19:32
|
ping traffic that came from five.
|
|
0:19:34
|
You can also see that these entries have an idle timer
|
|
0:19:37
|
configured automatically
|
|
0:19:40
|
where it says for this entry here the time left is a 121
|
|
0:19:44
|
versus 118, so eventually these entries will time out.
|
|
0:19:49
|
If you want to change the default timers,
|
|
0:19:52
|
you could do this with the ip reflexive list timeout command.
|
|
0:19:58
|
So on Router 5 if we said ip reflexive list timeout
|
|
0:20:02
|
if I said it was five seconds
|
|
0:20:05
|
now I look at the show access list
|
|
0:20:09
|
we should see that these entries are going to get deleted.
|
|
0:20:15
|
Now the timer, the five second, that may include just the new
|
|
0:20:18
|
entries that we create
|
|
0:20:20
|
so on Router 5 let's do some pings
|
|
0:20:24
|
then show access list
|
|
0:20:31
|
probably what I would need to do is remove the reflexive list and
|
|
0:20:34
|
then reapply it.
|
|
0:20:37
|
But otherwise, that reflexive timeout is going to affect
|
|
0:20:40
|
what the idle timers for these entries are.
|