- So in this video, we're gonna take a look at
another type of an access list called
an extended access list.
In a previous video, we looked at standard access lists.
We looked at they're pretty easy to configure,
because really all you have the ability to match on
is the source IP address of an IP version
four packet and that's it.
And we saw that fundamentally, you configure the
access list with a number.
Do you remember what the range of numbers was
for a standard access list?
It was from one to 99.
And then there was an expanded range above that.
So you configured access-list.
The number, permit, or deny.
And then all you had left after that was some 32 bit number
to match the source IP address.
And then a wildcard mask to match against
that 32 bit number.
So now with an extended access list, we're gonna have
a much broader range of things that we can match against.
So just like a standard access list, with an extended
access list if you wanted to, you could just match
on a source address.
But you've gotta lot of other things as well,
including various fields in the layer four header as well.
So if you want to check on anything,
if you wanna classify or identify a packet
on anything other than the source IP address,
this would be your option, the extended access list.
And notice that you can even check on
layer four port numbers.
So if you wanna match only on Telnet traffic
or web browsing traffic, you've got that kind
of flexibility with this.
Now with a standard access list, I mentioned in the last
video that that was ideally placed as close
to the destination of the traffic as possible.
Because if you place the standard access list
close to the source and you're trying to
prevent that source from going somewhere,
well because you couldn't specify the destination,
that would prevent that source from going anywhere.
So if it was close to the source, the source wouldn't
be able to get to legitimate resources.
As well as not being able to get to the destination
that you did not want it to get to.
That's why a standard access list was placed
as close as possible to the destination device,
prevent the traffic from getting to it,
just before it gets to the destination.
That way the source can get to everything else it needs to.
Well with an extended access list, just the opposite is true
because we do have the flexibility of now specifying
source and destination, ideally you would implement
your extended access list as close to the source
of the traffic as possible.
And I'll show you that on the whiteboard
in just a moment.
So extended access lists are in the range of 100 through 199
you should memorize that.
And just like with standard access lists,
there's another range of numbers that Cisco iOS recognizes
as extended ACLs, this is called the expanded range,
if you run out of numbers here.
The expanded range is 2000 through 2699,
that's 2000 through 2699.
And like I mentioned, extended access lists
are capable of transport header inspection.
So an example just real quickly here,
you know, why would it be beneficial for us to put it
as close to the source as possible?
Let's say we had the exact same requirement
that we had previously.
Where we want R1 to be able to send packets
anywhere other than here.
We don't want R1 to be able to send any IP packets
to that destination, 2.4.2.4.
Okay well with an extended access list,
we very well could put it right here on this interface.
We could've put it outbound.
Remember, an extended access list doesn't do anything,
unless you pair it up with some sort of feature
that's using it.
And in the last video we talked about the IP access-group
interface feature, that's an interface level feature
which acted like a crude firewall.
Like just blocking or permitting traffic.
And the IP access group feature was directional,
you applied it on an interface and you'd had to tell it,
is it for packets going out the interface
or is it for packets coming into the interface?
Well certainly we could replicate our exact same lab
in the last video, this time with an extended ACL
matching a source this time of that host
if we wanted to, 1111.
And this time with an extended ACL, we could also match
on the destination, which is 2424.
And there's nothing preventing us from
using the IP access group feature to reference that ACL.
And the ACL would say deny.
And then placing it outbound here.
And it would work.
Here's the downside to this.
The idea is if a packet is ultimately gonna be dropped
somewhere in the network due to some security restriction,
does it really make sense that we should consume
bandwidth on all sorts of cables to transport that packet?
Consume a little bit of processing time on various
routers and switches to look it up and forward it,
if ultimately it's gonna be destroyed anyway.
Because if we put our access group outbound here,
remember only one frame can go on a wire at a time.
So when one frame is on a wire, no other frames
can use that wire.
So that's time that's lost for other legitimate traffic.
So while R1 is putting his frame right here,
nobody else can use that cable.
And then when switch one processes it,
once again, that switch one's looking up that frame,
he does not have the capability of looking up
any other frame, so that's time that's lost.
And then when it gets to switch two
and then it's using up some bandwidth on this cable.
When it gets to switch two, it's using up some
of his processing time.
And the finally, it's dropped right here.
That's why they say it's better to put an extended access
list that's going to be dropping or modifying traffic
in some way as close to the source as possible.
So in this particular case, it would make more sense
for us to put our extended access list right here
in the inbound direction.
That way any traffic that's gonna be dropped,
well yeah it's gonna use up a little bit of bandwidth
on this cable, but it's not gonna bother anybody else
in the network, it'll be dropped long before
it consumes any resources anywhere else in the network.
That's why an extended ACL, if you can, is best
to place closest to the source.
Okay so where can an extended access list look?
What types of things can you check with an extended ACL?
Well now you can certainly check the source
and destination IP address.
You can check the protocol number.
And as a matter of fact, when you configure
an extended ACL, you have to put something
in the field that checks protocol.
Now you have some choices here.
So in the standard access list, if I go back here
for a moment, let me just configure
a little bit larger font.
So we just typed, so I'll just say Standard ACL.
You just type access-list and then
you gave it some number.
Typically from one to 99.
And that's what you put right here.
And then after that, you just simply said permit or deny.
And that applied against any kind of IP traffic,
didn't matter what it was.
TCP, UDP, all IP traffic would match against this.
And then you had your source.
And I'll just put it underneath here
'cause I sort of run out of room.
Your wildcard mask.
Now with an extended access list,
I'm gonna abbreviate it here a little bit.
So with an extended ACL, you're still gonna
start with access-list and then a number.
So both of these are considered numbered access lists.
In this case, it's probably gonna be 100 through 199,
is most likely the range that you're gonna put right here.
And you're still gonna say right after that,
either permit or deny.
But now there's a new field you have to put in
before you put in your source and your wildcard.
This right here, you have a choice of a variety of things.
Basically what goes right there is imagine,
well it's just better to show it to you
than try to describe it.
'Cause I'm not exactly sure what logic they use there
for that, but let me just demonstrate it real quick.
Access-list 101 deny?.
Okay so you can deny all IP packets
if that's still your desire.
So you gotta put something here.
You could deny IP or you could select
a protocol that IP carries.
For example, TCP, that's protocol number six
in the IP header field.
UDP, right, that's protocol number 17,
so by selecting one of these two things,
you are now having it match on this field right here.
By selecting IP, you're ignoring that field.
And you're just saying, all IP packets.
So all of these other things here, other than IP,
all this other stuff match up with various numbers
that go into this protocol field right here.
And there's a lot more things that go in here
than just what you see, so if there's a particular
protocol that you know of that's not in this list,
but you do the number of the protocol,
you can just select the number instead.
And then once you select that and you have to put something
there, then you can put your source and your wildcard.
And once again, maybe you say, well I don't care
about the source, all I really wanna match on
is where these packets are going.
Okay well if you don't care about the source,
just put the keyword any.
And then after the source and the wildcard,
I'm gonna go ahead and continue on here.
I'm just gonna wrap the line around.
Then optionally, so I'll put that in brackets
and it says optional, source layer four port.
And then you would have the destination
IP and a wildcard.
So the source layer four port, depending on the direction
of the traffic, that could be difficult to match on.
But let me show you a use case where you might
decide you wanna do that.
So let's say we had this topology right here.
I'll just make it real simple.
Here's a PC, here's a server, here's a router in the middle.
We'll just put a line through 'em.
And let's say this PC is 1.1.1.1.
And this server is 2.2.2.2.
Okay, and let's say that this PC is trying to
issue some sort of web browsing connection.
So HTTP session to the server.
Okay so we know that in this direction,
if we look at the traffic in that direction,
source IP will be 1.1.1.1.
Destination IP will be 2.2.2.2.
Layer four protocol will equal TCP
because we're talking about HTTP.
And then down here, the source TCP port number
will be, we have no idea.
And then the destination TCP port number
will be 80 for HTTP.
So notice that when traffic is being initiated
from whoever is starting the conversation,
remember that the layer four source port number,
most of the time not always, is what we call
an ephemeral port number.
We have no idea what it's gonna be at layer four.
This device says, okay I've got a tab open
in Internet Explorer or a tab open in Google Chrome.
So in order to keep track of this as an individual
unique TCP session, I'll just come up
with some random port number.
And then if I open up another tab in Google Chrome
or another tab in Internet Explorer, well the
destination port number will be the same because
they're both going to HTTP.
So I need to come up with another unique random port number.
So if you are trying to match on this traffic
going from left to right and you're trying to match on
the source TCP port number in this field right here,
that would be next to impossible.
Because there's really no way you could predict
what it would be.
But we're matching on the source port number,
would be possible, is in the return traffic.
Because if we think about when that server is responding
back in that HTTP response, now the source
will be 2.2.2.2, destination's going back to that host.
Layer four protocol is still TCP.
But get this, the source TCP port is now 80
because it was going to 80 and now 80 is responding back.
And the destination TCP port is whatever
that random port number was.
So technically if you said, well I wanna block Telnet
sessions from this host to this PC,
most of the time the way people would do that
is they would create their extended access list.
They would apply it inbound, right there on that interface,
and what they would be blocking would be
the IP information and the destination TCP port of 80
because we can match on that.
But theoretically if you wanted to, you could still
kill this connection, prevent it from completing,
by instead putting the access group command
on this interface in the inbound direction
and then matching on this.
And matching on a source port of 80.
Now you might think to yourself,
well why would I wanna do that?
Well, here's a particular reason.
Let's say that I'm the person who's in charge of this server
and I say well this particular web server
is only for people in my payroll department.
Nobody else in my company should even be trying
to get to this web server.
As a matter of fact, they shouldn't even know
that it exists.
So anybody who's not in payroll,
I wanna block them if they try to get to this web server.
Now here's the thing, I want to know if anybody
in the company is trying to get to the web server.
I wanna keep some statistics on that.
So I actually, on the web server, wanna have some
program running that's tracking all incoming HTTP requests
regardless of where they're coming from.
Now if they're not coming from payroll, I wanna kill 'em.
So when the web server goes to reply to those requests
from HR or marketing or engineering,
I want the router to stop that.
I want them stopped, but I do want them to get to the server
so my software program can track that information.
And so I can see, hey Joe over there in marketing
keeps trying to bring up this payroll website.
He's not even supposed to know that it exists.
Why is he trying to do that?
And now I can do some investigation.
But if I block that traffic inbound on the router,
the server never even would've received it.
There would be no way for me tracking the statistics
or accountability or anything like that.
So that might be one reason why you might
want the traffic to get to the destination
and kill it on the return path.
So just an idea, I don't know if anybody
out there in the actual real world does that,
but that was an idea I had.
So you can see, you can also match on the
source and destination TCP or UDP port numbers.
You could even match on the TCP control flags.
An example of matching on the TCP control flags
and this is going a little bit more higher
than the CCNA level, but I like to explain, you know,
why they made these things like this.
So we know that in every TCP session before
any TCP data is transferred, the endpoints have to verify
their existence right?
And there's something that happens at the beginning
of every TCP session, what do we call that process?
That's called the TCP three way handshake.
So the initiator sends a TCP SYN,
we get a SYN plus an ACK and then an ACK.
Now at that point, all of the other TCP traffic
that goes back and forth is always gonna have
the ACK bit set.
Everything in either direction 'cause they're both
gonna be acknowledging each other on every single TCP
segment that flies back and forth.
So sometimes what people do, is they say well,
I only want to allow TCP sessions.
Maybe you say okay, this part of my network
is the safe and secure part of my network.
This is the part of the network that should be
initiating TCP sessions.
They should always be starting this way.
So if traffic's always starting this way
and I don't want this side to initiate,
this side is maybe the public internet.
And I don't want traffic coming in from the public
internet if it's being initiated from the internet.
It should just be in response to something in my company.
Well if it's always being initiated here,
that means every single TCP segment coming from this
direction will always have the ACK bit set won't it?
This will be the only frame, the very first TCP segment
will have the SYN bit set.
After that, everything else will have the ACK bit set.
So I could say, okay I'm gonna apply my access list
inbound right here and I'm only gonna allow TCP
segments that have the ACK bit set.
If the ACK bit is set, that means these guys are
responding to something that was initiated here.
If they try to initiate something with a SYN,
that will be dropped.
Because the ACK bit won't be turned on there.
And that's called an established session.
A TCP established session is one that has the ACK bit set.
So that's how sometimes people use those control flags.
They say match on any TCP session as long as
the ACK bit is turned on.
And that's one way of enforcing that kind of thing.
Okay and so we've already looked
a little bit at configuring this.
So let's just do a quick lab on this.
I'm gonna use the exact same topology that we used
in the previous lab for the standard access list.
And like I said, whenever you're working up a lab
for yourself at the very beginning,
you should always identify what your objective is,
what you're trying to accomplish with this lab.
So in my objective, I'm gonna write up here.
Objective, test extended ACL functionality
by denying any Telnet traffic sourced from
the 1.1.1.x/24 subnet destined for
the 2.4.2.0 subnet and allowing
all other traffic types.
So that's what I'm gonna try to do.
That's gonna be my objective.
Alright so let's think about this.
First of all, let's go ahead and create
what the access list is gonna look like.
And then we'll figure out where we want to apply it.
So we'll say, access-list and typically I'll just
use the first number there, 100.
And I want to deny and I'm talking about Telnet traffic.
Now remember, I have to put something right here.
I either put IP, now if I put IP,
that's gonna deny everything.
If you put IP in this field, at that point you've lost
the ability to match on any layer four information.
Once you put IP right here, Cisco iOS at that point,
won't give you any ability to match on
any layer four stuff.
So if I wanna match on, on layer four information,
I have to figure out what's the layer four protocol.
Well in this case, it would be TCP.
'Cause Telnet is carried in TCP.
And then in my source, I will put the subnet.
And I have to put a wildcard mask that matches that.
And then I put the destination in the wildcard mask.
And then here, I could put EQ23,
because Telnet is TCP port 23.
Now if I just leave it like that,
wherever I apply this, everything will be dropped.
Because remember, at the end of every access list,
is that implicit deny all that you can't see.
So now I need to create one more line
that will permit everything else.
IP from any source to any destination.
So that's how my access list could be created.
Now we said the best way to do this is to place
it as close to the source as possible.
So I think we should place that access list
inbound right on this interface.
So I'll say, access-group 100 inbound
and that's where I'm gonna put it.
It's actually IP access group to be technically precise.
So that's what I'm gonna do.
So in order to test this to begin with,
I need to enable a couple of these routers,
R4 and maybe one other device for Telnet.
Which means I have to go into my VTY lines
and configure some passwords, so let me do that
on R3 and R4.
Line VTY 04 and we'll just say, password INE.
I'll type in the full command for you.
Okay now if I try to Telnet to the device
I'll have to supply a password of INE.
And in router four, I'll do the exact same thing.
Okay and now I will go to router one
and verify that I can ping and Telnet both devices.
So let's try router three first, 2323.
Ping 2.3.2.3, yes I can ping it.
Let's see if I can initiate a Telnet session to it.
Yes I can.
Okay, now let's verify I can do the same thing
to router four, 2424.
Ahh, we still have our access list
from the previous lab on the switch,
that's why that is not working.
So I need to go to switch two.
Review question, what is the command I type,
I wanna delete this access list, but I don't remember
what the number was that I configured.
Other than doing show run, we could always do show run,
what other command could I type in to view
what access lists are currently configured on this box?
Well hopefully you said show IP access-list.
Okay so it's access list one.
Now another thing I wanna figure out.
Clearly this access list is being used
by the IP access-group command.
Which is on some interface and that's why my ping failed.
But this does not show me which interface
has that IP access-group command.
Any ideas as to what show command
I could issue to see that?
Well what I would start by doing is looking
at my topology diagram.
Clearly wherever it is, it's not on this interface.
'Cause this interface would be irrelevant,
that would never prevent the traffic.
So it's either gotta be on fast ethernet 010
or fast ethernet 0-4, one of those two.
So I'm gonna check those.
You can do the show IP interface
and then fast ethernet 0/10.
And what you're looking for in here, is this section.
So this says that on this interface there are
no access lists applied.
So let's take a look at the other interface.
And there we go, outgoing access list is one.
So technically I don't have to delete access list one.
All I really have to delete is the access group command
that's actually on this interface.
'Cause once I remove that, the access list won't even
be used by anything.
So interface fast ethernet 0/4 no IP access-group one,
and it says it's outgoing, so it would be out.
Now I'm gonna ahead and delete the access list.
Let me show you one other very important
point about access lists.
First of all, let's take a look at the current
access list, I think it's pretty short.
I think it's only got like two lines in it.
Okay yeah, so it's got two lines.
Let me just add two random lines
so I can show you what I'm about to demonstrate here.
Just gonna make something up.
And that's good enough.
Okay so let's take a look at my access list.
Okay there it is.
Now let's say I said, oh this line was a mistake.
I didn't mean to put that in there,
I wanna get rid of that line.
Alright so let's get rid of it here.
Alright that should do it, Enter.
Okay now remember where the access list was,
it was sort of right below my rip stuff right?
Let's look at my access list now.
Alright so it's right below the rip configuration,
right around there, let's see.
And oh, where is it?
It's gone!
That is the point I want to make.
With a numbered access list, when you delete any
of the lines, it deletes all of them all at once.
Very important point.
So in hindsight, what I should've done is if I really
want to delete just this one line,
I should have copied this entire access list
into a text editor like WordPad or Notepad or something.
Deleted the line there and then when I knew
that nobody was on my network,
'cause I'm gonna have a temporary security hole here
by doing this for like a second or two,
so like six AM in the morning or three AM in the morning,
log in to this device, delete the entire access list.
'Cause that's the only way you can do it.
Delete it all and then very quickly copy and paste in
the revised version.
That would be the only way to do it.
I shouldn't say that's the only way to do it.
There are more complicated ways, but at the CCNA level,
that's what they want you to take away from this.
Okay so now that I've done that,
let's go back to router one.
He should now be able to do his ping to router four, he can.
He should now be able to do his Telnet
to router four and he can.
Alright so now let's go ahead and implement this access list
and I'm gonna do it inbound on switch one
on his fast ethernet 0/1 interface.
Okay so access-list 100 deny TCP,
the source subnet from where the traffic's gonna come from.
The destination subnet of where the traffic's going.
And you can see here if I do a question mark,
there's actually quite a few things here I could do.
You can even do a time range.
But you could say I wanna match on any port numbers
that are greater than a certain port number.
Or less than a certain port number.
But in this particular case, I wanna match on
a specific port number, port number 23 which is Telnet.
So I'm gonna say equal, match only packets on
this given port number.
So I'll say EQ and then if I do the question mark,
actually you can see, it already is aware.
I could type EQ Telnet, that would work.
A little hint though, when you take the CCNA exam,
they will expect you to know a lot of these port numbers.
Not all of them, this is a monstrous list here.
Let me tell you what some of the port numbers
are that you should have memorized going into the exam.
At least as far as TCP is concerned.
You wanna know that BGP is 179.
You want to know that FTP uses 20 and 21,
those are important.
You wanna know that SMTP is port 25.
You wanna know that Telnet is port 23.
And you wanna memorize that web browsing
or HTTP is port 80.
Definitely wanna make some flash cards for yourself
and memorize those TCP port numbers.
And now I'm just gonna create my second line
permitting everything else, okay great.
And now I need to apply the access list.
So I will go on to my fast ethernet 0/1
and apply that with the access group command
in the inbound direction.
IP access-group 100 in.
Okay so to test this now, router one should still be able
to Telnet and ping to router three, 2323.
And he can.
He should still be able to ping router four, 2424.
And he can, but he should no longer be able to Telnet
to router four, and he cannot.
Destination unreachable.