So let's have a look at another example, in this example, we want to permit host 10.1.1.1 to server
10.1.2.1.
So this host should be permitted to this server, but we want to deny everyone else sending traffic to
that server.
But we also want to allow traffic to go to all other servers so anyone else should be able to connect
to all other servers.
So the first decision again is where are we going to bind this access control list and in which direction?
So we could bind it on f0/0 inbound or we could bind it on f01 outbound.
The issue with trying to bind the access list on f0/0 is that we cannot specify destination addresses
with the standard IP access list.
You can only specify source addresses, so you won't be able to implement this statement that says deny
everyone else to a specific server but allow traffic to all other servers because otherwise you're going
to say deny any
and the very next statement is going to be permit any, which won't work because the permit any will
never be used.
So what are we going to do is we're going to bind it on this interface outbound f0/1.
This also follows best practices which say that you should bind standard IP access lists as close to
the destination as possible.
I'll explain more about that in a moment.
So on our router, we could configure this access control list by going into global configuration mode
and typing acces list, let's choose number 3
permit
10.1.1.1
and then we could go into the interface f0/1 and type the command IP access group
3 out.
So once again, I could do the command show access lists.
Which just show me that simple access list that I've just created, the catch here was to remember where to bind
the access list
and to remember that you don't need a deny any at the end, because there's an implicit deny in an access list
statement.
I'm gonna explain what this number 10 means in a moment.
In this example, we want to permit subnet 10.1.1.0 and then deny everyone else, once again
we would bind the access control list inbound on fastEthernet 0/0 so as to make the access list as
efficient as possible.
We once again don't want the Rawda having to process packets internally just to have them dropped on
an external outbound interface.
So we'll bind the access control list inbound.
So on our router
going into global configuration mode
type the command access list t and in this case, let's choose number 4 and we will permit, in this case,
a specific subnet.
So 10.1.1.0 and then we need to put in the wild card mask.
A zero in binary means match.
So the first octet 10 mismatch, second octet 1 mismatch, third octet 1 mismatch at the last
octet can be equal to anything.
There's an implicit deny, so we don't have to specify anything else.
However, if you want to log information, you could do the following access list 4 deny
and notice the option, any that notice this option log that would allow us to log information to a sys
log server or log locally on the router so that we can see which packets were denied, when it comes
to logging its best practice not to log locally on the router, but to push it to a server like a sys
log server.
The reason for that is that the router has limited space for storing log messages, whereas if you store
that on a syslog server, you can store huge amounts of data because of the size of hard disks these days.
So it makes sense to back the logging information off to an external server.
The last step in this example is to go interface f0/0 and type the command IP access group
4 in.
Once again, I could do the command access list.
If I just wanted to see that specific access list, I could put a number on, so access list 4 you can see
the first line is saying permit 10.1.1.0 with wild card bit 0.0.0.255
and the second line is saying deny any and log that information.
Show IP interface f0/0
it shows me that the inbound access list is 4, so we have bound access list 4 inbound on fastethernet
0/0.
Now this example, the interface is shut down, not to concern because I'm just showing you the Syntex
of the access lists rather than showing you a working example.
Be careful with adding an explicit deny, as I did in this example.
You need to read between the lines in the questions and make sure that you are explicitly asked to deny
traffic.
If not asked
don't add the line to deny any because they may be testing you to make sure you know about the implicit
denial at the end of every access list.
Another example in this case, we want to permit 10.1.1.1 to telnet to the router and then we
want to deny everyone else telnet to the router and allow traffic anywhere else.
Now, once again, you need to read between the lines carefully.
In this example, we are setting up a standard access control list.
So the only way to do this is to bind the standard access control list on the VTY lines.
Remember, standard IP access lists cannot determine protocol or destination addresses.
So if the example is asking for a standard IP list to deny or permit telnet, then you know that you
have to bind that access list on the VTY lines.
So here's an example I'm going to tell me to a router.
This case, the address is 10.0.0.254
put in my username
put in my password typing the command show run
pipe section line will show me what's configured on the lines of this router, as you can see here,
there are no access lists on the VTY lines of this router then I could do the following
list, let's just pick a number like 10,
permit
and notice, the IP address is 10.1.1.1, no one else is allowed to telnet to the router.
So permit 10.1.1.1 and then I can go in to the line VTY , so line VTY 04
and I need to use the command access clause rather than access group.
Notice
you can specify either standard IP access list or extended access lists, in early IOS's you could only
choose standard IP access lists, but these days you can use both standard and extended ACLs.
So I'm going to choose 10.
Notice I can filter incoming telnet connections or outgoing Telnet connections, so I'm going to
specify in.
So now I'm going to try and telnet to the router again, so telnet 10.0.0.254 and notice
notice that Telnet connection does not open because we are denying Telnet to the router just to prove
that to you if I remove this access class
and then put it back on again, notice I'm able to telnet
and I can successfully log in, its disconnect
put that access list back again,
try and telnet.
I notice the telnet is denied, so please don't forget about access lists that can be bound on VTY lines
to permit or deny Telnet or SSH access to a router.
Once again, show, run, pipe, section line.
Shows me
that I have the access class 10 bound inbound on the VTY line.
So I'm unable to telnet from my PC, let's have a look at the IP address of my PC, as you'll see here,
the IP address is 10.0.0.1.
So on the router.
IF I type the command, no access list 10, be careful with that command. It doesn't just remove a line in
the access list, it deletes the entire axis list.
So typing the command do show access list 10 will show me that that access list does not exist.
So I've just deleted the access list entirely,
but I could type the command list 10 permit, 10.0.0.1 and then go on to my line VTY
just make sure that it's bound.
So access class
10 in.
Now, if I try and telnet.
Notice the telnet is successful.
So I'm able to telnet to the router.
That is why do the command do show access list 10, you can see that there are two matches on this access
list. If I telnet again,
do show command, notice the matches are increasing.
Can I still telnet to the router if I delete this access list?So I'm going to type the command access
list
10.
Do the show command and as you can see, the access list has been removed.
I'll disconnect my telnet session, let me see if I can telnet again
And as you can see.
I can gain access.
Do show run.
Pipe, section line.
Shows me that the axis list is still bound.
And this is a big gotcha.
This also applies to expound on interfaces, you can find a non-existent access list on an interface.
It's very dangerous because if someone later on created that access list and let's say inadvertently
configured it for something else, that axis list would immediately become active and traffic would
be denied or permitted unexpectedly as per the new access list.
So let's say we permitted 10.1.2.1, for argument's sake., now suddenly if I telnet back
to the router.
Notice the telnet session is denied.
Be very careful with your access lists, create them, then bind them.
If you delete them, remove them from the bindings.
In other words, remove them from the VTY lines or from the interfaces.
Do not allow nonexistent access lists to be bound to interfaces and do not allow access lists just to
exist in a configuration not being bound anywhere.
Just a reminder again, about remarks, remarks allow us to add descriptions to access control lists so
that they are easier to understand problem with access list as they can get fairly complicated if you
have a 10 line or 20 line ACL.
The last thing you want to do is decipher what the access list is intended to do.
So adding remarks can make it a lot easier to follow and understand, typing the command access list
on this router shows me the access lists configured at the moment, you can see there are access lists
with various lines, but they themselves don't mean much.
Rather than doing that, let's create an access list.
It's a access list 5 permit, let's say, for instance, 10.1.2.1
but now what you can do is you can say access list 5 remark
and now you can put in a remark up to 100 characters, so something like permit,
permit the boss, access
to exchange
server or whatever you decide, now I'm typing the command show access list.
Doesn't show the remark, but not as if I do the command show run to include access list.
Notice the remark is displayed in the access list, which makes it a lot easier to see what's going
on.
I could create another line in that access list, let's say access list 5 permit
and then I could create another remark.
Something like this
and now doing the same command again, show run pipe include access list.
Allows me to see each line in the access list and it's relevant remark, thus making it a lot easier to
understand what's going on.
Some guidelines regarding access lists, firstly, the type of the access list indicates what can be filtered.
In other words, a standard IP access list can only filter on source IP addresses or networks.
An extended IP access list can filter both on source and destination addresses, source and destination
port numbers and various other options relating to IP protocols.
So extended access lists tend to be a lot more powerful.
The order of processing is also of great importance.
You should place your more specific statements first.
If your first statement was permit any and your second statement was deny host 10 .1.1.1, that
second in statement would be irrelevant because of your first statement saying permit any, remember access
access control lists are process top down.
If there's a match on a line, all subsequent lines are ignored.
So I permit any would be matched
and all traffic, including traffic from host 10.1.1.1 would be permitted and the second line denying
host 10.1.1.1 would be ignored.
Don't forget that there's an implicit denial at the end of every access control list.
Unless you explicitly permit something, it's going to be denied.
Only one access list can be bound per interface, per direction, per protocol.
In other words, an IP version 4 ACL can be bound either in or out on a per interface basis.
You cannot have two IP version 4 access lists inbound on the same interface, but you can have one
in and one out.
As I've already demonstrated, if you try and bind two IP access lists inbound on the same interface,
the second one will just replace the first one.
So where should you place your access lists?
Now, the best practice from Cisco is to place Standard ACLs as close to the destination as possible.
And the reason for this is that you cannot match specific protocols,
now, in the real world, most ACL implementations will be using extended IP access lists because of
the fact that you can filter based on both source and destination IP address as well as source and destination
ports and so forth.
Whereas with IP standard access control lists you can only filter based on the source address.
So in this example, if you didn't want 10.1.1.1 to connect to the server, 10.1.2.1 you
could bind a standard IP access list either inbound on R1 or outbound and R1 or inbound on
R2 or outbound R2. If you decided to bind an access list denying this host inbound on R1
you would not only deny 10 one one one access to the server, but you would also deny the host access
to all other parts of the network because you cannot specify a destination, but only a source if you
bound an access list inbound on R1 denying hosting one one one, you would deny that host access to
all parts of the network.
So this wouldn't be a good place to bind that access list.
If you bound the access list outbound on R1 saying deny host 10.1.1.1 the host would
allowed access to this host.
But once again, 10.1.1.1 would be denied access to this network, this network, as well as this
network, because once again, you can only deny on the source address with a standard IP access list,
not on the destination or port numbers.
If you decided to bind the acccess list inbound on R2 the host 10.1.1.1 would have access to
this network as well as this network, but it wouldn't have access to this network or this network.
So that wouldn't work either.
And lastly, if you decided to bind the access list outbound on R2, that would be the optimum place
to place the access list because you would be denying host 10.1.1.1 access to the server that
you wouldn't be denying that host access to any other part of the network and thus you would accomplish
what you set out to do.
However, with the extended IP access lists, the recommendation is to place the access list as close
to the source as possible.
The reason for this is that you can match specific protocols and specific destination addresses.
So if you've bound an access list inbound on R1 you could say deny this
host 10.1.1.1 access to this host 10.1.2.1
but permit this host access to any other part of the network and thus you would accomplish what you
set out to do.
And this example would be a lot more efficient than the previous example, because you would be denying
traffic at this point rather than routing it all the way across the network to or to just to be dropped.
So extended IP access lists are a lot more flexible and a lot more efficient and thus tend to be used
more in the real world.