|
0:00:13
|
In today's class, we're going to be talking about security
|
|
0:00:15
|
on the IOS, then later this afternoon we'll also be talking
|
|
0:00:19
|
about Layer 2 security on the Catalyst switches
|
|
0:00:23
|
but for the IOS security, mainly we're going to focus on the
|
|
0:00:26
|
operation of access lists both standard and extended lists
|
|
0:00:29
|
the different type of applications that we can use these for whether it's
|
|
0:00:33
|
related to traffic filtering or controlling access to the router
|
|
0:00:37
|
for the VTY or AUX port of console lines.
|
|
0:00:41
|
We'll also look at the reflexive access list and
|
|
0:00:44
|
dynamic access list to add a little bit of application layer information
|
|
0:00:48
|
to the normal access list filtering.
|
|
0:00:51
|
We'll look at TCP intercept that's used to defend against
|
|
0:00:55
|
TCP denial of service attacks specifically the TCP SYN attack
|
|
0:00:59
|
then the content based access control and zone based policy
|
|
0:01:04
|
firewall that add application level inspection to the
|
|
0:01:08
|
the firewall feature set.
|
|
0:01:11
|
We'll also spend a little bit of time talking about AAA
|
|
0:01:13
|
and local authorization and the role based access control
|
|
0:01:17
|
but within the scope of the routing and switching exam
|
|
0:01:19
|
you won't see an actual AAA server in the exam
|
|
0:01:24
|
so we don't really need to focus on a lot of the details
|
|
0:01:26
|
behind RADIUS and TACACS as most of this is going to be
|
|
0:01:30
|
done locally on the router.
|
|
0:01:33
|
Now before we get into the specifics of any of these topics
|
|
0:01:35
|
I want to spend a few minutes going over the documentation
|
|
0:01:38
|
and talk about what specific topics will or will not be with the
|
|
0:01:42
|
scope of the routing and switching security section.
|
|
0:01:47
|
So from the 12.4 T configuration guides, if you go down to the
|
|
0:01:52
|
security section, you'll see that it's broken up into four
|
|
0:01:55
|
different portions where we have secure connectivity,
|
|
0:01:58
|
securing the control plane, securing the data plane and then
|
|
0:02:01
|
securing user services.
|
|
0:02:04
|
Now secure connectivity this is mainly going to be
|
|
0:02:08
|
focused on IPSec VPNs and SSL VPNs.
|
|
0:02:11
|
So the vast majority of this is not going to be within the
|
|
0:02:14
|
scope of routing and switching.
|
|
0:02:16
|
Most of this is going to be reserved for the security exam.
|
|
0:02:20
|
So you don't need to worry about ESP, AH, DNVPN
|
|
0:02:24
|
Easy VPN, SSL VPNs that stuff is not going to be within the scope.
|
|
0:02:28
|
Now of course it doesn't hurt to know it for
|
|
0:02:31
|
real-world design, but you can pretty much guarantee that you're not
|
|
0:02:35
|
going to be tested on IPSec in this exam.
|
|
0:02:37
|
It's one of those topics that's too large that if they were to
|
|
0:02:41
|
add it to routing and switching, it's going to be way too time consuming
|
|
0:02:44
|
and there's going to have to be too many points that are dedicated to it.
|
|
0:02:49
|
So the security CCIE exam probably 60-70 percent of it is
|
|
0:02:52
|
related specifically to IPSec and its different variations.
|
|
0:02:57
|
So I would say it's very very very unlikely that you would
|
|
0:03:00
|
see this within the scope of routing and switching.
|
|
0:03:04
|
The second one securing the control plane
|
|
0:03:06
|
you do want to be aware of these type of features
|
|
0:03:10
|
the neighbor router authentication most of this we already talked about
|
|
0:03:14
|
in the IGPs and BGP
|
|
0:03:17
|
how we can do MD5 authentication with OSPF, EIGRP and BGP
|
|
0:03:22
|
then how we can do clear text authentication
|
|
0:03:24
|
with RIP and OSPF
|
|
0:03:28
|
The other topic here control plane policing
|
|
0:03:31
|
this is used to protect the router's CPU itself
|
|
0:03:34
|
against denial of service attacks.
|
|
0:03:38
|
So this is a pretty straightforward topic. I'm not going to spend that much
|
|
0:03:41
|
time talking about it today. We're not really going to go through
|
|
0:03:45
|
any examples, but if you basically just take a look at
|
|
0:03:47
|
the configuration examples that they show here
|
|
0:03:53
|
it says configuring control plane policing on output ICMP traffic.
|
|
0:03:58
|
Following example shows how to apply a QoS policy for aggregate
|
|
0:04:01
|
control plane services to telnet traffic transmitted from the
|
|
0:04:04
|
control plane. Trusted networks with source addresses 10.0.0.0
|
|
0:04:09
|
and 10.0.0.1 receive ICMP port unreachable responses
|
|
0:04:12
|
without constraint while allowing all remaining ICMP port unreachable
|
|
0:04:16
|
responses to be dropped.
|
|
0:04:19
|
So basically, we're doing a classification with an access list
|
|
0:04:22
|
that's then called from a class map.
|
|
0:04:25
|
So similar to what we saw yesterday with QoS
|
|
0:04:28
|
we're doing classification to the type of traffic, but then
|
|
0:04:31
|
where this is applied is a policy map that goes under the
|
|
0:04:35
|
control plane sub configuration mode.
|
|
0:04:40
|
So it's the same type of logic as a QoS policy
|
|
0:04:43
|
except it's applying to the router's locally generated
|
|
0:04:46
|
control plane traffic.
|
|
0:04:48
|
The likewise the previous one it says if we wanted to limit
|
|
0:04:51
|
telnet traffic inbound, so we're policing this to 80 kilobits per second
|
|
0:04:56
|
and if telnet traffic goes above that rate, then
|
|
0:04:59
|
the router is going to drop it.
|
|
0:05:03
|
So the key here is that this type of policy is not bound
|
|
0:05:06
|
directly to any interface.
|
|
0:05:08
|
It's overall to the router's CPU itself.
|
|
0:05:11
|
So regardless whether you are locally generating a telnet
|
|
0:05:14
|
session or someone is trying to telnet into you
|
|
0:05:17
|
then this is going to prevent against basically too much
|
|
0:05:20
|
utilization on the exec process itself.
|
|
0:05:23
|
The third section here is securing the data plane
|
|
0:05:27
|
is mainly what we're going to spend most of our time talking about today.
|
|
0:05:30
|
This is going to be things like standard and extended access lists.
|
|
0:05:34
|
The IP session filtering is the reflexive access list
|
|
0:05:38
|
that's going to be the first variation of adding stateful
|
|
0:05:42
|
inspection to access control lists.
|
|
0:05:45
|
The configuring lock and key security for dynamic ACLs
|
|
0:05:49
|
this is going to be used to temporarily punch a hole
|
|
0:05:53
|
in an access list
|
|
0:05:55
|
for either outbound traffic or inbound traffic
|
|
0:05:58
|
then content based access control
|
|
0:06:01
|
this is going to be the application in aware inspections for the router.
|
|
0:06:07
|
So this is similar to the logic of the ASA firewall
|
|
0:06:11
|
uses the application level inspections to control
|
|
0:06:15
|
things like send mail different than DNS
|
|
0:06:18
|
or web browsing.
|
|
0:06:20
|
So depending on the individual IOS version that you're working with
|
|
0:06:24
|
generally the newer versions are going to support newer
|
|
0:06:27
|
inspections for things like SIP for IP phone calls
|
|
0:06:32
|
or URL filtering stateful failover so you could do this
|
|
0:06:40
|
similar to the ASAs where you can have one device backing up
|
|
0:06:42
|
another one. Now a lot of the advanced stuff here is really not
|
|
0:06:46
|
going to be within the scope of routing and switching
|
|
0:06:48
|
but we do want to understand the logic of how the CBAC
|
|
0:06:51
|
system works and then how to reference its syntax
|
|
0:06:54
|
from the zone based policy firewall.
|
|
0:06:58
|
So generally, CBAC on its own is pretty simple
|
|
0:07:00
|
syntax to implement as long as we're only dealing with
|
|
0:07:04
|
maybe two or three interfaces
|
|
0:07:06
|
but once we try to scale the policy, it quickly gets out of
|
|
0:07:09
|
control how we need to do the inspections.
|
|
0:07:12
|
So this is what the zone based policy firewall is going to
|
|
0:07:14
|
solve which essentially is just a syntax wrapper
|
|
0:07:18
|
for the CBAC inspection engine.
|
|
0:07:21
|
So it's still using the IP inspects that are coming
|
|
0:07:24
|
from CBAC. It's just a different way that we can reference the syntax.
|
|
0:07:31
|
Then things like the intrusion prevention system
|
|
0:07:33
|
I really wouldn't spend too much time with this
|
|
0:07:36
|
for routing and switching. You may want to just try
|
|
0:07:38
|
it out once and see how it works, then if you were
|
|
0:07:41
|
to be tested on this, just make sure you know where it's
|
|
0:07:43
|
located in the documentation.
|
|
0:07:47
|
Flexible packet matching is going to be used basically
|
|
0:07:51
|
to define custom protocols.
|
|
0:07:55
|
So something like this I doubt would be tested in the lab
|
|
0:07:58
|
exam or if it was, it's going to be something pretty basic
|
|
0:08:01
|
from the configuration examples that you could change around.
|
|
0:08:05
|
So for example it says here configuring flexible packet
|
|
0:08:08
|
matching for slammer packets
|
|
0:08:12
|
which essentially means that you would need to know
|
|
0:08:14
|
inside the actual payload of the packet
|
|
0:08:19
|
so if we look at in
|
|
0:08:21
|
detail what this says here
|
|
0:08:23
|
it says, 'Match on the destination port that has this particular
|
|
0:08:26
|
hex code, then the IP payload length would have to be greater than
|
|
0:08:32
|
this' then it says, 'Start at the offset 224 and then the next
|
|
0:08:41
|
four bytes are going to be equal to this.'
|
|
0:08:44
|
So it's basically like an application level signature
|
|
0:08:47
|
that you're manually defining on the router.
|
|
0:08:51
|
So I highly doubt that they would test on something like this.
|
|
0:08:54
|
Again, if they did, it's going to be something really basic that
|
|
0:08:56
|
you could get from the configuration guide
|
|
0:08:58
|
but you do want to know that that is a potential available
|
|
0:09:01
|
feature on the router.
|
|
0:09:05
|
Then our last one configuring secure user services
|
|
0:09:09
|
this is going to be things like controlling the login
|
|
0:09:12
|
access to the routers whether this is from local authorization
|
|
0:09:16
|
local authentication, remote authorization and authentication
|
|
0:09:20
|
with AAA using either RADIUS or TACACS and then an additional
|
|
0:09:25
|
feature we'll look at today which is the role based
|
|
0:09:27
|
CLI which allows us to do essentially a light-weight
|
|
0:09:32
|
version of command authorization without having to have a remote
|
|
0:09:38
|
TACACS server in order to do that
|
|
0:09:42
|
because most of the time if you want to control
|
|
0:09:44
|
what particular commands a user can run
|
|
0:09:46
|
you need to send each request to the TACACS server
|
|
0:09:49
|
and then TACACS either says yes or no, you can or cannot
|
|
0:09:53
|
run this command.
|
|
0:09:54
|
So role-based CLI is a much more straightforward version of that
|
|
0:10:00
|
where we simply say this particular user is allowed to
|
|
0:10:03
|
run commands XYZ and that's it.
|
|
0:10:07
|
So it's not as scalable as AAA because it's only going to be
|
|
0:10:10
|
locally significant to the router, but I would
|
|
0:10:13
|
probably expect more of that type of configuration within the
|
|
0:10:16
|
routing and switching exam versus the AAA type stuff
|
|
0:10:19
|
because again, you're not going to have actual AAA
|
|
0:10:22
|
servers in order to do the actual testing in routing and switching.
|
|
0:10:25
|
So again, our first topic here is going to be
|
|
0:10:28
|
the access list usage on the IOS
|
|
0:10:31
|
and we spent a bunch of time doing this so far
|
|
0:10:34
|
for things like route filtering and different applications
|
|
0:10:38
|
in things like multicast or QoS for doing classification
|
|
0:10:44
|
so there's a lot of different uses for access lists other than just
|
|
0:10:46
|
security, but in the case of security for using the ACLs
|
|
0:10:51
|
for traffic filters, we know that we can match not only
|
|
0:10:54
|
on the Layer 3 information, but the Layer 4 information.
|
|
0:10:58
|
So with a standard access list versus an extended access list
|
|
0:11:02
|
standard ACL is only going to be matching on the
|
|
0:11:05
|
source address
|
|
0:11:07
|
where extended access list can match on the IP protocol
|
|
0:11:09
|
number, so for example 88 for EIGRP or 89 for OSPF
|
|
0:11:17
|
Now, there's two different ways if for some reason you
|
|
0:11:19
|
needed to know what the protocol numbers are
|
|
0:11:21
|
there's two ways that you could figure some of this out
|
|
0:11:24
|
within the actual exam time.
|
|
0:11:27
|
One is going to be based on a documentation page
|
|
0:11:29
|
that is inside of the ASA firewall.
|
|
0:11:34
|
So if we were to go to the main documentation
|
|
0:11:38
|
then to products, security
|
|
0:11:43
|
firewall
|
|
0:11:45
|
firewall appliance
|
|
0:11:47
|
ASA 5500
|
|
0:11:51
|
then configuration guides
|
|
0:11:54
|
and essentially any version, so let's say 8.4 is the newest one.
|
|
0:12:01
|
So as long as you get to basically any configuration guide
|
|
0:12:03
|
for the ASA software, then go down towards the very bottom
|
|
0:12:07
|
under reference
|
|
0:12:09
|
and there's this document that has addresses, protocols
|
|
0:12:12
|
and ports.
|
|
0:12:16
|
So under here, you'll see some useful information that's not
|
|
0:12:19
|
just related to traffic filtering and security. Things like the
|
|
0:12:23
|
IP version 4 address formats
|
|
0:12:25
|
it shows what's the class A versus class B, class C
|
|
0:12:29
|
addresses. The RFC 1918 it shows the ten network
|
|
0:12:33
|
172.16 to 31 192.168
|
|
0:12:38
|
There's also a reference table for subnetting
|
|
0:12:42
|
what's the number of hosts and what's the bit notation
|
|
0:12:46
|
and the dotted decimal notation for the different
|
|
0:12:49
|
mask lengths.
|
|
0:12:52
|
You'll see some information about IP version 6 as well
|
|
0:12:56
|
like what's the unicast versus multicast and loopback or
|
|
0:13:00
|
unspecified format, but the main thing it's useful in this
|
|
0:13:03
|
document if you scroll down towards the end
|
|
0:13:06
|
is that there's a list of the IP protocol numbers
|
|
0:13:10
|
and also some of the common port numbers.
|
|
0:13:14
|
So for example it says EIIGRP is 88
|
|
0:13:17
|
where OSPF is 89
|
|
0:13:20
|
and a GRE tunnel would be 47
|
|
0:13:26
|
so again, this is what we're matching when we are
|
|
0:13:28
|
calling an access list and saying access list 100
|
|
0:13:32
|
permit the keyword.
|
|
0:13:34
|
So if we say access list 100 permit ospf
|
|
0:13:37
|
we're really saying match IP protocol number 89
|
|
0:13:42
|
Now additionally you can use the IOS itself to figure out
|
|
0:13:45
|
some of these numbers.
|
|
0:13:46
|
If you were to go to one of the router's consoles
|
|
0:13:49
|
and simply define an access list
|
|
0:13:53
|
and instead of saying permit ip or permit tcp, permit udp
|
|
0:13:58
|
say permit the number like permit 1 any any
|
|
0:14:02
|
permit 2 any any
|
|
0:14:04
|
3 any any etc.
|
|
0:14:06
|
so you could take this in Notepad and basically
|
|
0:14:10
|
write all of the numbers 1 through 255
|
|
0:14:12
|
then when you look at the show access list
|
|
0:14:15
|
you'll see that any numbers that the router already has
|
|
0:14:18
|
a shortcut for
|
|
0:14:20
|
it's going to show up there in the running config
|
|
0:14:22
|
and in the show access list output.
|
|
0:14:28
|
So what this is telling us is that protocol number 1 for IP
|
|
0:14:31
|
is ICMP where protocol number 2 is IGMP for joining multicast groups.
|
|
0:14:38
|
Protocol 4 would be IP in IP which is an alternative to the
|
|
0:14:44
|
GRE tunneling.
|
|
0:14:48
|
Then likewise if we were to say things like access list
|
|
0:14:50
|
100 permit 47 or permit 88, permit 89
|
|
0:14:57
|
these are going to have well-known keywords as well.
|
|
0:15:01
|
So not all of these values are going to be listed in there
|
|
0:15:04
|
but a good amount of them are. The only other alternative to
|
|
0:15:08
|
this would be basically to look up what's the official
|
|
0:15:11
|
list of what the port and protocol assignments are.
|
|
0:15:15
|
So specifically this is allocated by IANA
|
|
0:15:18
|
If you were to search for the IANA protocol assignments
|
|
0:15:24
|
there's a page that shows you the protocol numbers
|
|
0:15:26
|
and then also one for the well-known ports
|
|
0:15:31
|
so we can see protocol 1 is ICMP, protocol 2 is IGMP
|
|
0:15:37
|
protocol 4 is IPV4 encapsulation so this would be
|
|
0:15:39
|
an IP in IP tunnel.
|
|
0:15:42
|
But also what's useful about this is that it links to this specific
|
|
0:15:44
|
RFC that defines that individual protocol.
|
|
0:15:50
|
So if we were to go down like to 89 for OSPF
|
|
0:15:54
|
it says check RFC 1583
|
|
0:15:57
|
Now when you actually open some of these up
|
|
0:15:59
|
you may see that there's a new one that is updating it.
|
|
0:16:04
|
When you look on the IETF website, a lot of the times
|
|
0:16:06
|
it's going to link to what the newer one is.
|
|
0:16:09
|
But if it doesn't actually show this, what you could do
|
|
0:16:13
|
is take the number in this case it's 1583 which was the
|
|
0:16:16
|
original definition of OSPF
|
|
0:16:18
|
if you go to rfc-editor.org
|
|
0:16:24
|
and then search for that specific number
|
|
0:16:26
|
say rfc 1583
|
|
0:16:30
|
you can see in the more info field, it shows you which
|
|
0:16:32
|
ones are updating it or which ones are replacing it.
|
|
0:16:38
|
So not directly within the scope of security here
|
|
0:16:40
|
but it is kind of useful to know if you need to figure out
|
|
0:16:43
|
more information like packet level details about a particular
|
|
0:16:47
|
protocol, then this page here on IANA is going to link to the
|
|
0:16:50
|
individual RFCs.
|
|
0:16:53
|
So once we specify the protocol number, we can choose both the
|
|
0:16:57
|
source address and the destination address
|
|
0:16:59
|
where we're using that address and wildcard
|
|
0:17:02
|
mask, so with the access list that is different than
|
|
0:17:06
|
a prefix list, we can essentially match on any random binary logic
|
|
0:17:10
|
that we want.
|
|
0:17:13
|
So when we look at the wildcard mask, we can
|
|
0:17:15
|
send it to any value that is going to control whether we
|
|
0:17:19
|
are checking or ignoring the bit values that are
|
|
0:17:22
|
inside of the address.
|
|
0:17:26
|
So when we look at the specific format of this
|
|
0:17:29
|
if we were to say access list 100
|
|
0:17:35
|
permit IP from any source to the destination host 1234
|
|
0:17:46
|
When we look at the binary address and wildcard
|
|
0:17:49
|
pairs, the first one for any means that in the
|
|
0:17:53
|
first octet we're matching against 0000 0000
|
|
0:17:59
|
so this is the address.
|
|
0:18:01
|
And then wildcard would be all 1s.
|
|
0:18:03
|
1111 1111
|
|
0:18:08
|
So a wildcard value of 1 means that we are going to
|
|
0:18:11
|
ignore that bit place where a wildcard of 0 means that we're
|
|
0:18:15
|
going to check it.
|
|
0:18:17
|
So in the case of the exact host match for host 1234
|
|
0:18:22
|
in the first octet we would have 1 which is 0000 0001
|
|
0:18:29
|
so this is the address field, then in the wildcard we have
|
|
0:18:32
|
0000 0000
|
|
0:18:37
|
so it's essentially saying that all of these bits in the address field
|
|
0:18:40
|
it has to be an exact match for them.
|
|
0:18:47
|
So I'm not going to get into a lot of examples of advanced binary
|
|
0:18:51
|
matches. You'll see there are some examples of that on
|
|
0:18:54
|
our blog website if you go to blog.ine.com and just search
|
|
0:18:59
|
for binary math or wildcards access list, that type of stuff
|
|
0:19:04
|
you'll see a bunch of different resources for that
|
|
0:19:08
|
but I would doubt that they're going to get really complicated with
|
|
0:19:10
|
this in the exam because it's more of a binary
|
|
0:19:13
|
math issue, it's not really a networking protocol understanding
|
|
0:19:17
|
per se. Next in addition to the source and destination addresses
|
|
0:19:21
|
would be the protocol specific options.
|
|
0:19:24
|
So for TCP, this would be things like the port number
|
|
0:19:27
|
whether it's equal to that port, not equal to the port
|
|
0:19:31
|
and then ranges whether it's less than, greater than
|
|
0:19:34
|
or a specific range.
|
|
0:19:36
|
So we could say UDP ports in the range of 16384
|
|
0:19:41
|
to 32767
|
|
0:19:43
|
so for example, that would be matching our voice payload
|
|
0:19:46
|
the actual voice bearer call
|
|
0:19:49
|
of a phone call
|
|
0:19:52
|
where in TCP, if we wanted to say I want to match
|
|
0:19:54
|
not web traffic, we could say permit TCP any any
|
|
0:19:59
|
that is neq, so not equal to 80
|
|
0:20:05
|
Now when you do this, keep in mind that the source and
|
|
0:20:07
|
destination port are going to change depending on
|
|
0:20:10
|
whether we're dealing with a standard TCP application
|
|
0:20:13
|
or a non-standard TCP application
|
|
0:20:17
|
and we'll see once we get to reflexive access list
|
|
0:20:19
|
versus the CBAC and the zone based policy firewall
|
|
0:20:23
|
there are going to be some cases where it does make a
|
|
0:20:25
|
difference whether the TCP and UDP application
|
|
0:20:27
|
are standard versus non-standard.
|
|
0:20:30
|
Now what I mean by this a standard TCP application
|
|
0:20:36
|
as it goes through the 3-way handshake
|
|
0:20:41
|
the client or the source of the session
|
|
0:20:45
|
the first thing it's going to do is send the TCP SYN
|
|
0:20:51
|
to the server, so to the destination.
|
|
0:20:55
|
In this packet, the source address is going to be
|
|
0:20:59
|
random or excuse me the source port number
|
|
0:21:02
|
source port number is going to be random
|
|
0:21:04
|
where the destination port is going to be the well-known
|
|
0:21:08
|
port value.
|
|
0:21:11
|
So if this were telnet, the destination would be 23
|
|
0:21:14
|
if this were BGP, the destination would be 179
|
|
0:21:17
|
If it was web browsing, it's going to be port 80
|
|
0:21:20
|
Now when the destination replies in the second portion
|
|
0:21:25
|
where we're sending the SYN and the ACK
|
|
0:21:29
|
so the destination is acknowledging that the
|
|
0:21:31
|
sender wants to open the session and it's saying
|
|
0:21:34
|
I also want to open the session, so it's replying with a SYN
|
|
0:21:38
|
In this step, the port numbers are going to be
|
|
0:21:41
|
swapped, so now the source port is going to be the well-known
|
|
0:21:47
|
port where the destination port is going to be the
|
|
0:21:51
|
the random one.
|
|
0:21:55
|
Then finally, when the source fully opens the session
|
|
0:21:59
|
so it replies back with the acknowledgement
|
|
0:22:01
|
then all traffic from the sender to the receiver or from the source
|
|
0:22:04
|
to the destination is going to use the source port of random that they
|
|
0:22:07
|
negotiated and the well-known destination port.
|
|
0:22:13
|
Now the reason that this is important is that any time
|
|
0:22:17
|
we're dealing with an application level filter or any type of stateful
|
|
0:22:20
|
firewall, the device that is actually permitting
|
|
0:22:24
|
or denying the traffic is going to need to know
|
|
0:22:27
|
what is the source port, what's the destination port
|
|
0:22:30
|
what's the source address, what's the destination address
|
|
0:22:32
|
and what's the protocol number.
|
|
0:22:35
|
Now for some reason when the traffic goes out
|
|
0:22:39
|
we can't accurately predict what the return path is going to be.
|
|
0:22:44
|
The stateful firewall is going to have some issues with this
|
|
0:22:46
|
unless it has a specific application level inspection engine
|
|
0:22:51
|
or an application level gateway sometimes it's called an ALG
|
|
0:22:56
|
that is specific to that individual protocol.
|
|
0:23:00
|
So we'll see when we get to the reflexive access lists
|
|
0:23:03
|
reflexive ACLs are not going to support non-standard
|
|
0:23:05
|
protocols where CBAC or zone based policy firewall
|
|
0:23:09
|
would assuming that they have an individual inspection
|
|
0:23:12
|
for that individual application.
|
|
0:23:15
|
So we can do some of this basic logic just with an extended
|
|
0:23:18
|
access list like setting the 'establish' keyword in the ACL
|
|
0:23:23
|
which typically 'establish' is going to be traffic that is coming
|
|
0:23:27
|
from the destination back to the client after the client
|
|
0:23:31
|
originated the first TCP SYN.
|
|
0:23:35
|
So in this particular diagram when the destination sends the
|
|
0:23:39
|
traffic back to the source in step number 2
|
|
0:23:42
|
this is going to have the establish flag
|
|
0:23:44
|
so if there's a router that is filtering the inbound traffic
|
|
0:23:48
|
and we were to say permit only traffic that has established
|
|
0:23:53
|
then this would be a basic way that we could check
|
|
0:23:55
|
whether the source originated from the inside network or from the
|
|
0:23:59
|
outside network.
|
|
0:24:04
|
Now the issue with this though is that it's fairly easy to spoof
|
|
0:24:06
|
the establish flag. The only thing we do is have to just set
|
|
0:24:10
|
that bit in the TCP header
|
|
0:24:12
|
so there's no real application level checking that goes along with
|
|
0:24:16
|
it, but this would be considered the most basic iteration
|
|
0:24:21
|
of any type of stateful filtering.
|
|
0:24:26
|
So if we were to look at our specific topology
|
|
0:24:29
|
let's say that on Router 5 we want to protect the
|
|
0:24:33
|
inside network
|
|
0:24:36
|
that is connecting to Switch 2, we want to protect this from
|
|
0:24:40
|
the outside network.
|
|
0:24:42
|
And to simplify this a little bit, I'm going to shut down the link that
|
|
0:24:45
|
Router 5 uses to connect to Router 4
|
|
0:24:49
|
so Router 5's going to have one outside interface which
|
|
0:24:51
|
is the link to the frame relay and the inside interface
|
|
0:24:55
|
which is Fast Ethernet 0/0
|
|
0:24:59
|
So what I want to do is allow traffic to initiate
|
|
0:25:01
|
from the inside, so let's say on VLAN 10
|
|
0:25:05
|
we have a client that is sending a web request
|
|
0:25:09
|
to a server that's on VLAN 7
|
|
0:25:11
|
The server should be able to reply back to the client
|
|
0:25:17
|
so this should be allowed
|
|
0:25:19
|
but if there's an unsolicited request let's say that
|
|
0:25:22
|
someone on VLAN 9 sends a ping or some TCP session
|
|
0:25:28
|
to VLAN 10, this one we want to deny
|
|
0:25:33
|
as it's coming inbound on Router 5's connection to the frame relay network.
|
|
0:25:39
|
So we'll look at the same type of example using just the
|
|
0:25:42
|
extended access lists then the reflexive lists
|
|
0:25:45
|
the dynamic access list, the content based access control
|
|
0:25:49
|
and the zone based policy firewall and we'll see both the
|
|
0:25:53
|
configuration differences and then the design advantages of
|
|
0:25:56
|
using one versus the other.
|
|
0:25:58
|
So let's take a look at the command line here.
|
|
0:26:00
|
And on Router 5, the first thing I'm going to do is take that additional
|
|
0:26:05
|
link that goes to Router 4 and shut that down
|
|
0:26:09
|
so now when we look in the routing table
|
|
0:26:12
|
essentially the only other path to the rest of the network
|
|
0:26:15
|
is going to be via serial 0/0/0
|
|
0:26:20
|
so if I were to go to Switch 4
|
|
0:26:22
|
which is behind Router 5
|
|
0:26:24
|
and let's say that I do a trace to the VLAN at 9
|
|
0:26:31
|
interface of Switch 3
|
|
0:26:36
|
so this is going to be from Switch 4 behind Router 5
|
|
0:26:39
|
all the way out to Switch 3 we should see that this
|
|
0:26:42
|
traffic is going to transit over the frame relay interface of Router 5
|
|
0:26:47
|
So once it gets to Router 5, then it's being sent to Router 3
|
|
0:26:52
|
from Router 5's perspective, this second hop this is the
|
|
0:26:56
|
one that we're going to treat as the inside interface
|
|
0:26:59
|
and the one below that is what we're going to treat as
|
|
0:27:02
|
the outside interface, so I want traffic to be able to originate
|
|
0:27:06
|
from the inside and go out, then return
|
|
0:27:11
|
but I do not want unsolicited traffic to come from the outside
|
|
0:27:14
|
and enter inbound.
|
|
0:27:17
|
Now we'll see that any time we're doing these filters
|
|
0:27:19
|
today, we do need to take into account what are the control
|
|
0:27:23
|
plane protocols that are transiting from the router
|
|
0:27:26
|
itself out the interface and then from the other
|
|
0:27:31
|
attached neighbors back inbound
|
|
0:27:33
|
because when we apply an outbound access list
|
|
0:27:37
|
that is not going to affect the locally generated traffic on the
|
|
0:27:41
|
router and there's an easy way to test this. If I were to go to
|
|
0:27:44
|
Router 5 and simply say access list 100 deny ip any any
|
|
0:27:53
|
then on serial 0/0/0
|
|
0:27:55
|
I'll say ip access group 100 out
|
|
0:28:00
|
so normally this is supposed to deny all traffic
|
|
0:28:03
|
but we're not going to have any problems
|
|
0:28:06
|
pinging to that VLAN 9 interface of Switch 3
|
|
0:28:11
|
or doing a trace route out to that.
|
|
0:28:17
|
So even though the access list is saying deny everything
|
|
0:28:19
|
out on the interface, that is not going to affect the locally
|
|
0:28:22
|
generated traffic on the router.
|
|
0:28:25
|
It's only going to affect traffic that is transiting between
|
|
0:28:28
|
different interfaces.
|
|
0:28:30
|
So next on Router 5 let me remove that access list.
|
|
0:28:33
|
no ip access group 100 out
|
|
0:28:38
|
I want to figure out how can I classify the incoming
|
|
0:28:41
|
traffic to figure out whether it was originated from the
|
|
0:28:45
|
inside network to begin with.
|
|
0:28:48
|
And again, the most basic iteration of this
|
|
0:28:51
|
would be inside the access list if we were to say
|
|
0:28:54
|
access list 101 permit tcp any any that has
|
|
0:29:02
|
the established flag.
|
|
0:29:07
|
So typically this means that the session already came from
|
|
0:29:10
|
the inside of the network it went out
|
|
0:29:13
|
then the session that is returning is the response
|
|
0:29:16
|
it's not an unsolicited request.
|
|
0:29:23
|
Now in addition to this, I would also need to account for
|
|
0:29:26
|
any control plane protocols which in this particular case
|
|
0:29:29
|
is going to be EIGRP routing
|
|
0:29:33
|
so I'll say permit EIGRP any any
|
|
0:29:35
|
and if I was running BGP or PIM or MSDP
|
|
0:29:39
|
I would need to take all of those additional protocols
|
|
0:29:42
|
into account.
|
|
0:29:43
|
But in this particular case, the only thing I'm using for
|
|
0:29:46
|
routing is EIGRP
|
|
0:29:52
|
So on the serial interface, I'll say ip access group 101
|
|
0:29:56
|
out or excuse me, 101 in
|
|
0:29:59
|
not 101 out
|
|
0:30:02
|
so now Router 5's going to check packets as they come inbound
|
|
0:30:05
|
if they're not either the TCP packets with the establish flag
|
|
0:30:10
|
or EIGRP, they are going to get denied.
|
|
0:30:14
|
So if we were to go to Switch 3,
|
|
0:30:16
|
and ping the LAN interface of Switch 4
|
|
0:30:21
|
so that VLAN 10 interface
|
|
0:30:23
|
we see that we're getting ICMP unreachable.
|
|
0:30:27
|
If I were to try to telnet to this address
|
|
0:30:31
|
it's going to get denied.
|
|
0:30:35
|
Now specifically, if we look at the debug
|
|
0:30:38
|
ip icmp on Switch 3
|
|
0:30:41
|
then send either these pings or these telnets
|
|
0:30:44
|
we'll see that the response is coming back in from Router 5
|
|
0:30:49
|
are the ICMP unreachable that is administratively
|
|
0:30:53
|
prohibited.
|
|
0:30:56
|
So administratively prohibited basically means that the
|
|
0:30:58
|
packet is being dropped based on an access list.
|
|
0:31:03
|
So any time the router's doing any type of firewall filtering
|
|
0:31:07
|
if we are denying the packet, normally it's going to generate
|
|
0:31:09
|
an ICMP unreachable. Now a lot of the times we wouldn't really
|
|
0:31:13
|
want the router to do that because not only is it processer
|
|
0:31:16
|
intensive to generate the unreachables
|
|
0:31:20
|
it's also going to give the hosts information about the
|
|
0:31:22
|
router's firewall filtering policy.
|
|
0:31:26
|
So we would be able to figure out what particular
|
|
0:31:28
|
traffic it does or does not allow
|
|
0:31:30
|
based on the responses of ICMP unreachable.
|
|
0:31:34
|
So we could configure the router not to do this
|
|
0:31:37
|
either globally we could simply say no ip icmp
|
|
0:31:44
|
that should be at the interface level
|
|
0:31:46
|
the frame relay no ip
|
|
0:31:55
|
no ip unreachables
|
|
0:31:57
|
so this is going to disable ICMP unreachable
|
|
0:32:01
|
for that particular interface. If I were to now go back to
|
|
0:32:05
|
Switch 3 and do that ping again
|
|
0:32:10
|
we see now essentially that the packets are silently being dropped.
|
|
0:32:14
|
So again, this is based on the incoming access list
|
|
0:32:18
|
that Router 5 has applied on the interface.
|
|
0:32:22
|
Now since the ACL is matching the establish flag though
|
|
0:32:25
|
so if we show access list 101
|
|
0:32:30
|
if I were to go behind Router 5
|
|
0:32:34
|
so let's say from Switch 4 and I were to telnet
|
|
0:32:39
|
to the same destination
|
|
0:32:42
|
we should see that this traffic is going to be allowed.
|
|
0:32:48
|
This traffic flow is allowed because as it returns back
|
|
0:32:51
|
inbound, the establish flag is going to be set.
|
|
0:32:55
|
However, from the other side if we were to go to
|
|
0:32:58
|
Switch 3 and to telnet to Switch 4
|
|
0:33:04
|
this is going to be denied.
|
|
0:33:08
|
So simply based on that one simple flag inside the ACL
|
|
0:33:12
|
we're essentially allowing traffic from the inside to
|
|
0:33:15
|
go out and then return, but we're not allowing traffic to go
|
|
0:33:18
|
from the outside in.
|
|
0:33:24
|
Now in reality, you wouldn't want to do this though because
|
|
0:33:27
|
it's very easy to spoof the establish flag
|
|
0:33:29
|
generally, you would want a more intelligent matching
|
|
0:33:32
|
on the router to figure out whether the session did actually
|
|
0:33:35
|
originate from the inside or the outside.
|
|
0:33:39
|
So any other fields that we previously talked about
|
|
0:33:41
|
like the Layer 3 type of service markings with the
|
|
0:33:45
|
DSCP or the IP precedence we can match them in there.
|
|
0:33:48
|
We could also tell whether the packet is being fragmented
|
|
0:33:50
|
or not with the fragments keyword
|
|
0:33:53
|
so for some reason, if we do not want the routers
|
|
0:33:56
|
to perform Layer 3 fragmentation, we can deny the fragments
|
|
0:34:00
|
because there are some potential issues with mail
|
|
0:34:03
|
formed fragment attacks.
|
|
0:34:06
|
But whether we need the fragments or not is really
|
|
0:34:08
|
going to depend on the Layer 3 MTU along the transit path
|
|
0:34:12
|
so if we're doing any type of GRE tunneling or
|
|
0:34:16
|
IPSec or PPP over Ethernet, PPP over other medias
|
|
0:34:21
|
we could potentially have the problem
|
|
0:34:23
|
where the MTU of the transit path is lower than
|
|
0:34:26
|
what the end host is requesting
|
|
0:34:28
|
in that case we would need to enable or would need to
|
|
0:34:32
|
allow the fragments to come in the interface.
|
|
0:34:35
|
The next feature we have that is in access lists
|
|
0:34:38
|
is to log the entries
|
|
0:34:41
|
where we could say either log or log input
|
|
0:34:45
|
where both of them are going to generate a syslog message
|
|
0:34:47
|
that either is going to go to the console to the buffer
|
|
0:34:50
|
or to remote syslog
|
|
0:34:52
|
the difference is that the log input keyword
|
|
0:34:55
|
is going to include the incoming interface
|
|
0:34:59
|
and also the Layer 2 address of the device that forwarded that
|
|
0:35:02
|
onto the segment.
|
|
0:35:06
|
Now one thing that is important to note about access list logging
|
|
0:35:09
|
is that it will cause the traffic to be process switched.
|
|
0:35:14
|
So if there's a large amount of traffic that we are logging
|
|
0:35:17
|
potentially we could have very high CPU utilization on the
|
|
0:35:20
|
router because it's skipping over the normal CEF forwarding path
|
|
0:35:24
|
or the CEF switching path.
|
|
0:35:27
|
So if we look at the show CPU or show proc CPU history
|
|
0:35:31
|
or show proc CPU and we see very high utilization
|
|
0:35:35
|
if it's from the IP input process, then that's a good indication
|
|
0:35:39
|
that it's based on the process switching.
|
|
0:35:43
|
Now this also means that by logging particular traffic
|
|
0:35:47
|
in an access list, we would be allowed to debug that
|
|
0:35:51
|
because it is no longer being process switched.
|
|
0:35:57
|
So let's say for example if we were to look at Router 5
|
|
0:36:00
|
and on its connection that comes into Fast Ethernet 0/0
|
|
0:36:08
|
so on the inside network
|
|
0:36:11
|
let's say that we have an access list that comes
|
|
0:36:13
|
in that interface that is permitting all TCP traffic
|
|
0:36:17
|
and we're going to log it.
|
|
0:36:21
|
Now it's not going to be used to deny the traffic, it's just going to be
|
|
0:36:23
|
used to log so we'll say access list 102
|
|
0:36:28
|
permit tcp any any log
|
|
0:36:31
|
and I'll also say log input so it's going to include the Layer 2 information.
|
|
0:36:42
|
Then additionally I'll permit all other IPs so access list 102
|
|
0:36:45
|
permit ip any any
|
|
0:36:48
|
then on Fast Ethernet 0/0 ip access group 102 in
|
|
0:36:54
|
so if I now look at the debug ip packet detail on Router 5
|
|
0:37:00
|
and I were to do a telnet that goes through
|
|
0:37:04
|
Router 5, so I'll telnet from Switch 4 to Switch 3
|
|
0:37:09
|
if we look at Router 5, we should see that particular
|
|
0:37:13
|
traffic flow
|
|
0:37:15
|
so coming from
|
|
0:37:25
|
let's see and this is going to be a lot of traffic because
|
|
0:37:27
|
it's now being
|
|
0:37:31
|
process switched. What I should see is protocol is tcp
|
|
0:37:36
|
and let's undebug here. If you are doing this
|
|
0:37:39
|
within the scope of the lab exam, probably what you want to do is
|
|
0:37:42
|
send this to the log buffer because then you're going to
|
|
0:37:45
|
prevent the case where you could potentially
|
|
0:37:47
|
lock yourself out of the console.
|
|
0:37:48
|
So I may actually need to reboot Router 5 after doing this
|
|
0:37:53
|
log or we could just let it eventually flush out all the
|
|
0:37:56
|
messages
|
|
0:38:00
|
because it's essentially overrunning the console.
|
|
0:38:03
|
So if we look through this, we should see the
|
|
0:38:08
|
it might be closer towards the top here
|
|
0:38:14
|
which would be this one, so it says the source is
|
|
0:38:17
|
155.28.108.10
|
|
0:38:22
|
that's going to 155.28.9.9
|
|
0:38:27
|
and this is an acknowledgement and a push basically saying I want
|
|
0:38:30
|
more data from -- for port number 23
|
|
0:38:34
|
Now additionally, notice that the log message here is
|
|
0:38:38
|
including the source that forwarded it onto the link.
|
|
0:38:44
|
This is based on the log input feature
|
|
0:38:50
|
so now it looks like Router 5's console is going to be hung.
|
|
0:38:53
|
What you could do in this type of case if you do accidentally
|
|
0:38:57
|
lock yourself out, I could go to another router in the topology
|
|
0:39:00
|
let's say I just go to Switch 2
|
|
0:39:02
|
and from Switch 2, I'm going to telnet into Router 5
|
|
0:39:15
|
then assuming I can get into enable mode
|
|
0:39:17
|
I'll clear out the console, so clear line con 0
|
|
0:39:23
|
so when the exec session is deleted
|
|
0:39:26
|
it also means that the debug is automatically
|
|
0:39:28
|
going to be removed.
|
|
0:39:31
|
So if I look at the show proc cpu history now
|
|
0:39:38
|
we can see that that debug was basically taken almost a 100 percent
|
|
0:39:41
|
of the CPU on Router 5
|
|
0:39:43
|
so generally, you would not want to do this because
|
|
0:39:46
|
it's going to be process switched and it's going to be very
|
|
0:39:48
|
CPU intensive
|
|
0:39:49
|
but if you have no other option if you have like a network down
|
|
0:39:52
|
emergency and you need to figure out what the problem is
|
|
0:39:55
|
then it's a possibility that maybe debugging the traffic
|
|
0:39:59
|
flow is going to be your only potential option.
|
|
0:40:04
|
Now even if you're not doing the debugging
|
|
0:40:06
|
it still is going to be processor intensive because any time you're
|
|
0:40:09
|
doing a log, it is doing process switching.
|
|
0:40:14
|
Now if we look on -- so Router 5 is still logging here
|
|
0:40:17
|
let's try this on one of the other routers in the transit path.
|
|
0:40:20
|
Let's say on -- let's see what hop this goes to
|
|
0:40:25
|
so from Switch 2 or Switch 4 here I'm going to trace to Switch 3
|
|
0:40:31
|
so this goes to Router 5
|
|
0:40:34
|
and -- actually, I have the access list that's denying it
|
|
0:40:37
|
so I'm not going to be able to see this. Let's say from
|
|
0:40:41
|
let's try this from Router 4 from Router 4, let's trace to
|
|
0:40:46
|
155.28.9.9
|
|
0:40:50
|
so we're going through Router 6 here.
|
|
0:40:53
|
So on Router 6, I'm basically going to do the same thing.
|
|
0:40:57
|
I'll say access list 100 permit ip any any log input
|
|
0:41:04
|
then on the link that is connecting to the Ethernet
|
|
0:41:08
|
segment to Router 6
|
|
0:41:09
|
I'll say ip access group
|
|
0:41:12
|
100 inbound
|
|
0:41:17
|
Now since I already have logging to the console on
|
|
0:41:21
|
we can see that the log messages start to appear
|
|
0:41:25
|
that in this case I'm receiving EIGRP which is
|
|
0:41:27
|
protocol number 88
|
|
0:41:29
|
in from 155.28.146.1
|
|
0:41:33
|
and 146.4
|
|
0:41:36
|
but the difference between the normal log and the log input
|
|
0:41:40
|
is that it shows the incoming interface and the Layer 2
|
|
0:41:43
|
address that did the forwarding.
|
|
0:41:47
|
So this potentially could be used to track down some
|
|
0:41:49
|
end host maybe that's doing a denial of service attack
|
|
0:41:53
|
or is infected with some sort of worm or virus
|
|
0:41:57
|
so you would know not only what interface the traffic is
|
|
0:42:00
|
leaving out, but the interface that it came in from to
|
|
0:42:04
|
begin with and who is the Layer 2 address that
|
|
0:42:07
|
forwarded the packet onto the segment.
|
|
0:42:11
|
Now again, since we are process switching the traffic
|
|
0:42:14
|
with the log or either the log input
|
|
0:42:16
|
the issue is that generally we would want to limit
|
|
0:42:18
|
the amount of log messages that we are going to generate.
|
|
0:42:23
|
So there's three different ways that we could do this.
|
|
0:42:25
|
We could do it globally that is related just to logging
|
|
0:42:28
|
messages in general, so if we say logging rate limit
|
|
0:42:31
|
that's going to apply to the console, the VTY, the AUX port
|
|
0:42:35
|
the buffer and to the syslog trapping.
|
|
0:42:40
|
If we want to limit just the access list logging
|
|
0:42:44
|
we could set the logging interval or the log update threshold
|
|
0:42:48
|
where the logging interval basically is just going to say
|
|
0:42:51
|
how often do I want to generate the logs
|
|
0:42:55
|
so if we say ip access list logging interval
|
|
0:43:03
|
so if I only generate a log every 10,000 milliseconds
|
|
0:43:07
|
or basically ten seconds
|
|
0:43:10
|
then it's not going to be as overwhelming to the
|
|
0:43:12
|
CPU. Now the other option would be to change the
|
|
0:43:16
|
log update threshold
|
|
0:43:20
|
which basically says how many hits do I need on the
|
|
0:43:23
|
ACL before I actually generate the log message.
|
|
0:43:28
|
So let's say that we'll specify the threshold as
|
|
0:43:30
|
25 packets.
|
|
0:43:33
|
If I were then to go to Router 4
|
|
0:43:36
|
and let's say that we ping this address
|
|
0:43:41
|
and we ping it with a 100 packets
|
|
0:43:44
|
if Router 6 says the log update threshold is
|
|
0:43:47
|
25 packets, it means that those subsequent logs
|
|
0:43:54
|
were only generating once 25 hits have occurred.
|
|
0:44:01
|
So if I do this again,
|
|
0:44:03
|
we're sending a 100 packets
|
|
0:44:05
|
we see that there's four log messages that are generated by
|
|
0:44:08
|
Router 6. It's saying that 25 packets
|
|
0:44:12
|
were basically aggregated together into one single log
|
|
0:44:15
|
and then this was happening four times.
|
|
0:44:18
|
The other option that we have that is relatively new
|
|
0:44:21
|
here is known as the syslog correlation that allows us
|
|
0:44:26
|
to put a tag value whether it's just a generic ascii string that we
|
|
0:44:31
|
define or basically an MD5 hash that the router is generating
|
|
0:44:37
|
so we could figure out not only what is the
|
|
0:44:39
|
individual access list entry that generated the log
|
|
0:44:44
|
but what particular device or what particular interface
|
|
0:44:47
|
was that located on.
|
|
0:44:49
|
So one of the potential issue is that when we have
|
|
0:44:52
|
a centralized syslog server and we're trying to do
|
|
0:44:55
|
some sort of auditing of the logs
|
|
0:44:57
|
it could be difficult to figure out not only what device
|
|
0:45:02
|
did the log message come from, what interface
|
|
0:45:05
|
was the log related to and then what was the
|
|
0:45:07
|
particular entry that generated that log message.
|
|
0:45:10
|
So this is what the correlation
|
|
0:45:13
|
tag is designed to fix.
|
|
0:45:15
|
So now let's say on Router 6
|
|
0:45:18
|
this access list I'm going to make it a little bit more specific.
|
|
0:45:21
|
So I'll remove access list 100 and instead I'm going to
|
|
0:45:25
|
have access list 101 that has a couple different
|
|
0:45:27
|
entries.
|
|
0:45:28
|
One of them is going to be for ICMP echo packets.
|
|
0:45:35
|
I'm going to generate a log message for this
|
|
0:45:38
|
but I'm going to set a cookie or basically a tag value
|
|
0:45:42
|
onto the access log entry
|
|
0:45:44
|
that says icmp pings.
|
|
0:45:51
|
Then access list 101 says permit tcp any any
|
|
0:45:55
|
equal to 23
|
|
0:45:57
|
log and I'll say telnet sessions.
|
|
0:46:02
|
Then access list 101 it's going to permit anything else.
|
|
0:46:07
|
So now at the link level when I apply this inbound
|
|
0:46:10
|
ip access group 101 in
|
|
0:46:14
|
if Router 4 is sending a ping
|
|
0:46:19
|
I should see that Router 6 generates the log with that
|
|
0:46:22
|
string at the end of it
|
|
0:46:27
|
which is separate versus the telnet logging message.
|
|
0:46:40
|
So this is one way to do it by manually defining
|
|
0:46:43
|
what is the tag that you're putting onto the log entry
|
|
0:46:46
|
the other option is to have the router automatically
|
|
0:46:49
|
generate an MD5 hash
|
|
0:46:50
|
which is with the command ip access list logging hash generation
|
|
0:46:57
|
so if we apply this in global config ip access list logging
|
|
0:47:03
|
has generation
|
|
0:47:05
|
then if we show run
|
|
0:47:08
|
do show run include access list 101
|
|
0:47:14
|
Let's take the same list, but now recreate it
|
|
0:47:19
|
without specifying the string at the end.
|
|
0:47:23
|
So I have the ICMP messages that are being logged
|
|
0:47:26
|
the telnet messages that are being logged and then
|
|
0:47:28
|
everything else is permitted without being logged.
|
|
0:47:33
|
Then at the LAN interface, ip access group 100 in
|
|
0:47:36
|
we could see what's happening so at the end of the log
|
|
0:47:40
|
it's generating a hash message that is specific to
|
|
0:47:43
|
that individual entry.
|
|
0:47:48
|
So it's essentially accomplishing the same thing.
|
|
0:47:50
|
It's just that the router is automatically generating
|
|
0:47:53
|
its own value there.
|
|
0:47:55
|
So if we wanted to be more informational
|
|
0:47:58
|
then probably the tag would be better to use
|
|
0:48:01
|
but technically, you could do it either way.
|
|
0:48:03
|
So we talked about a couple of the different
|
|
0:48:05
|
applications for the access list. The main one that we're
|
|
0:48:09
|
going to use for traffic filtering is the IP access group
|
|
0:48:13
|
in or out of the interface.
|
|
0:48:15
|
Again, the key point to remember here is that when we
|
|
0:48:17
|
apply this outbound, it is not going to affect
|
|
0:48:21
|
the router's locally generated traffic.
|
|
0:48:24
|
So even if I'm saying deny ip any any
|
|
0:48:27
|
and then apply that outbound
|
|
0:48:29
|
it's still not going to affect the router's local pings or
|
|
0:48:31
|
telnet or the routing protocol traffic.
|
|
0:48:39
|
The other key application for the access list is going to be
|
|
0:48:41
|
for traffic classification.
|
|
0:48:43
|
We looked at this through the QoS policies
|
|
0:48:46
|
but we'll also look at it again today when we're doing
|
|
0:48:48
|
the zone based policy firewall with the class maps
|
|
0:48:52
|
of type inspect.
|
|
0:48:58
|
We saw previously in the different IGPs and BGP
|
|
0:49:01
|
that we could also use the access list for route filtering
|
|
0:49:04
|
in either a distribute list directly applied onto the
|
|
0:49:08
|
neighbor or called from a route map
|
|
0:49:12
|
where again, remember that the extended access list
|
|
0:49:15
|
is going to behave differently
|
|
0:49:17
|
depending on which protocol that we are applying it onto
|
|
0:49:22
|
where in the case of BGP and an extended ACL means
|
|
0:49:25
|
the address and the subnet mask, where in the case of EIGRP
|
|
0:49:30
|
and RIP it means the source address of who the routing update is coming from
|
|
0:49:36
|
and the particular address of the route.
|
|
0:49:39
|
So it's not matching the subnet mask in that case, it's saying
|
|
0:49:42
|
who is the route coming from and what is the specific address
|
|
0:49:45
|
field of the route.
|
|
0:49:46
|
Then another important application here is going to be
|
|
0:49:48
|
the access class on the line.
|
|
0:49:51
|
So this would control who can telnet to the router or
|
|
0:49:54
|
who can SSH to the router and if we were to apply this
|
|
0:49:58
|
outbound, it's going to affect when we're locally in the
|
|
0:50:02
|
exec process on the router
|
|
0:50:04
|
who can we generate a telnet session to
|
|
0:50:08
|
or who can we generate an SSH session to.
|
|
0:50:14
|
So if we were to look at this on Router 6
|
|
0:50:18
|
Let's say that on Router 6 we only want to allow telnet
|
|
0:50:21
|
sessions to come in
|
|
0:50:23
|
when they're being sourced from this VLAN 79 interface
|
|
0:50:27
|
of Switch 3
|
|
0:50:30
|
but then when someone is connected to the exec process itself
|
|
0:50:33
|
on Router 6, we only want Router 6 to be able to telnet
|
|
0:50:37
|
to Router 1's loopback
|
|
0:50:41
|
so it'll be two separate directions
|
|
0:50:43
|
the one to Router 1, that's going to be the access class out on the line
|
|
0:50:48
|
where the one that is affecting Switch 3 being able telnet to Router 6
|
|
0:50:52
|
that would be the access class in.
|
|
0:50:54
|
Now we can apply this with both extended access list and
|
|
0:50:58
|
standard access lists
|
|
0:50:59
|
if we only care about what the source address is, then
|
|
0:51:03
|
we can use just a standard ACL
|
|
0:51:05
|
so on Router 6, let's say access list 1 permit 155.28.79.9
|
|
0:51:13
|
so this is Switch 3's address that's connected to that VLAN 79
|
|
0:51:20
|
Then under the VTY lines which is going to be for
|
|
0:51:23
|
telnet and SSH
|
|
0:51:25
|
if we say access class 1 inbound
|
|
0:51:30
|
this is now going to control who can telnet to Router 6
|
|
0:51:33
|
or who can SSH to Router 6
|
|
0:51:40
|
If we were to go to Switch 1 and telnet to 150.28.6.6
|
|
0:51:46
|
so this is the loopback of Router 6
|
|
0:51:49
|
it says connection is refused.
|
|
0:51:51
|
But if I were to do the same thing from Switch 3
|
|
0:51:55
|
this should be allowed
|
|
0:51:56
|
which it is.
|
|
0:52:01
|
So the difference in the application here of the
|
|
0:52:04
|
access class versus the access group at the interface level
|
|
0:52:08
|
is that the access class is not affecting an individual
|
|
0:52:13
|
interface. It's applied to the exec process itself on the router.
|
|
0:52:19
|
So we would have gotten the same effect if we were
|
|
0:52:21
|
to configure an extended ACL
|
|
0:52:23
|
that says permit traffic from that particular
|
|
0:52:25
|
source going to Router 6's addresses that are equal to
|
|
0:52:28
|
telnet, but then we would need to apply that inbound
|
|
0:52:32
|
on all of the interfaces of Router 6.
|
|
0:52:35
|
So the serial 0/0/0
|
|
0:52:38
|
Fa 0/0.67 and 146
|
|
0:52:43
|
Instead applying it to the VTY line itself, that doesn't matter
|
|
0:52:48
|
what physical interface the packet is coming inbound.
|
|
0:52:51
|
Then the opposite of this would be the outbound
|
|
0:52:53
|
access class
|
|
0:52:55
|
so if I want to control who Router 6 can telnet to
|
|
0:52:59
|
locally when someone is actually logged into the exec
|
|
0:53:03
|
process of Router 6 I could say access list 2 permit 150.28.1.1
|
|
0:53:10
|
so this is Router 1's loopback
|
|
0:53:13
|
then under the console, I'll say access class 2 out
|
|
0:53:20
|
this now means that I should be able to telnet to Router 1
|
|
0:53:25
|
which I can
|
|
0:53:28
|
but I should not be able to telnet to Router 2
|
|
0:53:32
|
or to Router 3
|
|
0:53:37
|
so when this log message appears it says connections to that
|
|
0:53:40
|
host is not permitted from this terminal. It means there's
|
|
0:53:42
|
an access class outbound
|
|
0:53:45
|
that is denying that on the individual line.
|
|
0:53:52
|
Now what's interesting about this though since I have the
|
|
0:53:54
|
access class applied just to the console
|
|
0:53:58
|
so if we show run begin line
|
|
0:54:02
|
access class 2 is applied out on the console
|
|
0:54:05
|
it would allow Switch 3 to telnet into Router 6
|
|
0:54:12
|
then from there, telnet out to Router 2
|
|
0:54:18
|
or in that case Router 5 it looks like it's still dropping packets
|
|
0:54:27
|
so let's say we telnet to 6
|
|
0:54:30
|
then from 6 we telnet to 3
|
|
0:54:35
|
we see this is allowed
|
|
0:54:38
|
because the access class on Router 6 it's not applied
|
|
0:54:40
|
to the VTY line, it's applied to the console.
|
|
0:54:47
|
So when you're thinking about where to apply the
|
|
0:54:48
|
access class, you need to think about where is the
|
|
0:54:51
|
exec session terminating to begin with.
|
|
0:54:54
|
If someone is telnetting to the router, it means the exec session
|
|
0:54:58
|
is terminating in on the VTY
|
|
0:55:02
|
If someone is already on the VTY line so they telnetted
|
|
0:55:05
|
into Router 6 and then they're going to telnet back out
|
|
0:55:10
|
that would be filtered based on an access class out on the VTY.
|
