Welcome back.
My name is David Bombal CCIE 1123.
In this section, we're going to look at access lists,
I'd like to show you how to implement security using access control lists, which are one of the most
basic building blocks for implementing security in the Cisco network.
These days, there are multiple ways to implement security, but access lists are one of the most fundamental
and a lot of the newer technologies are based on them.
So it's important that you have a good understanding of how access lists work and how to implement them.
So we're going to look at the purpose of access control list.
I'd like to show you how they are bound to interfaces, they are either bound inbound or outbound.
I'd like to show you various types of access lists, including numbered lists, named access lists, as
well as standard and extended access control lists or ACLS.
I'd like to explain what a wildcard mask does and how you can match individual hosts, subnets or all
hosts by changing the wildcard mask.
I'd also like to explain time based, Reflexive and Dynamic ACLs.
Now, before getting into a discussion of access control list or ACL, let's review some of the information
covered in IC
ND1 course you will not be able to implement ACLs without a good understanding of protocols, port
numbers and other options available in the TCP IP protocol stack and other protocols if you have them
running on your network.
So here's an example,
if we have a PC connecting to a server and the PC connects using HTTP and that traffic is sent across
the network, router 1 will see a packet with a source address of 10.1.1.1 with a source port
number greater than 1023.
So in this example, let's say 1024 in this case, because you are using HTTP, it's going to well known
port number 80.
So the destination IP address is 10.1.2.1 and the destination port number is 80.
Now, with access lists, direction is of great importance on this interface.
The route is receiving the packet inbound, but on this interface, the packet is being transmitted
outbound.
It's important that you look at this from the routers point of view.
The packet arrives inbound and is sent outbound.
So in other words, if you configure an access-list outbound on this interface, it would have no effect
on traffic from the PC to the server because an outbound access list only checks traffic outbound from
the routers point of view.
So if you configured an inbound access control list on the left hand side, packets would have to pass
that access control list before being permitted.
And once again, if you configured an outbound access control list on this interface, traffic sent
would have to pass the access list or be permitted by the access list.
Otherwise the traffic will be dropped.
When the service ends, traffic in reply, the source address will now be 10.1.2.1 with a source
port of 80 and the destination IP address will be 10.1.1.1, and the destination port number will
be 1024.
In this case, an outbound access list on this interface would come into effect for traffic from the
server to the PC because the traffic is going out from the routers point of view.
So an access list configured outbound in this interface would affect this traffic and this traffic would
have to pass the criteria set in the access list before being permitted
by the same token, an inbound access list on this interface would affect the traffic and the traffic
would have to pass the criteria set in that access control list.
Here's another example, this MacBook is telneting to switch 1 via the router, so for argument's
sake, let's assume the MacBook chooses Port 50000.
The source address or frames from the MacBook to the switch would be 10.1.1.1 with a source
port of 50000.
The destination would be 10.1.2.1 with the destination port number of 23.
So once again, from the routers point of view, it's receiving frames on this interface with a source
of 10.1.1.1 source port 50000.
And it's transmitting those packets out of this interface with the same details packets sent in reply
from the switch at the source address of 10.1.2.1 source port of 23 and a destination IP address
of 10.1.1.1, the destination port of 50000.
Once again, it's important that you understand your protocols and port numbers because without that
understanding you'll not be able to configure ACLs.
Always look at the direction of the traffic to determine whether an access list should be bound inbound
or outbound on specific interfaces.
Here are some examples of some well-known TCP protocols with the relevant port numbers, FTP uses
Port 21 for control and 20 for data, telnet uses Port 23, Secure Shell uses Port 22, SMTP uses
Port 25, HTTP uses Port 80,
POP3 uses Port 110, SSL uses port 443.
So those are examples of some well-known TCP port numbers that you should remember. For the real world
just Google IANA port numbers to see a list of the Internet assigned numbers authority port numbers.
The IANA is in charge of port numbers and determines the allocation.
So as an example, just type IANA port numbers
and your very first hit will be a list of port numbers, and they explained quite nicely
about the well-known port numbers,
registered port numbers,
and dynamic and private port numbers. So as an example, if you just do a search or
Telnet, you'll see which port no telnet uses.
So here's a nice list if you're not sure which port numbers are used by specific protocols.
Here's an example of protocols that use UDP and their relevant port numbers, so as an example, DHCP
uses port numbers 67 and 68, TFTP uses port 69 and SNMP uses Port 161.
Once again on that same list, on the IANA, you could do a search for specific protocols
and there's an example of TFTP, DNS is a special case
it uses port number 53 that uses both TCP and UDP, so both for study purposes and the real world.
Remember their protocols like Telnet uses Port 23 and Telnet uses TCP, whereas, for example, TFTP uses
port 69 using UDP.
Now, why would you use ACLs up to this point, and of course, we've been enabling access between
different parts of the network, no shutting interfaces creating inter VLAN routing, setting up routing
protocols like EIGRP and OSPF all enable access throughout the network.
However, you might not want everyone to be able to access every part of the network.
This is especially true when you connect to the Internet.
You don't necessarily want everyone on the Internet to be able to access your corporate servers or corporate
network.
So access lists are one of the first lines of defense to stop or deny traffic from one part of the network
to another so they can be used to permit or deny traffic moving through a router.
So as an example, we might allow this MacBook to gain access to the Internet.
But we might deny traffic from the Internet into our corporate environment, so we would permit or deny
traffic on a per interface basis and thus deny traffic moving through the router.
You could put a password on a VTY line on a router to force a level of security.
However, you might say that only administrative subnet, for instance, this machine on an administrative
subnet is allowed to access the VTY lines with this machine is not allowed to access the VTY lines.
In this case, the access list will not even permit Telnet or SSH traffic to the VTY lines on this
router.
So rather than just having one line of defense a password, you implement two lines of defense, only
permitting certain subnets to the VTY lines, as well as putting a password on the VTY lines.
it comes to security
you've got to think of the risk dependent on the risk
you will implement more security.
In this case, you might deem the risk of users accessing network equipment to be high.
So you only allow certain subnets to connect to the VTY lines of a router or a switch.
So once again, without ACLs all packets could be transmitted to all parts of the network, and that might
not be desirable.
So you might want to deny certain parts of the network from gaining access to other parts of the network.
The whole idea here is that you are starting to implement security, locking down parts of the network
so that they cannot be accessed by all individuals inside and outside of the organization.
ACLs, however, not just used for permitting or denying traffic, they can also be used for classification
when setting up an IPSec VPN or virtual private network between two sites, you need to tell the router
which traffic needs to be encrypted.
You might not want all traffic encrypted from your local LAN because you might want traffic from your
local LAN to an Internet server to be sent unencrypted.
But traffic from your local LAN to the LAN on the other side of the VPN tunnel needs to be encrypted.
So you create an access list determining what traffic is interesting.
In other words, needs to be encrypted on what traffic is not interesting, in other words, does not
need to be encrypted.
ACLs can also be used in redistribution, where you are taking routes from one routing protocol and
redistributing them or pumping them in to another routing protocol.
So you might not want OSPF to learn about all EIGRP routes and therefore you can use access control list
to limit or only permit certain routes to be redistributed.
Access lists are also used with NAT or network address translation the access list will determine which
packets need to be translated in which packets do not need to be translated.
So you would create an access list permitting only certain subnets which would allow for those packets
to be translated.
Packets denied by the access list are not denied access or dropped, but they are not translated using
network address translation or NAT.
When using ACLs to permit or deny packets moving through a router, there are two main steps.
So firstly, in global configuration mode, you create the access list using the command access list and
then filling in various options.
So the access list command is used to create the access list
and then secondly, you apply the access list either inbound or outbound on an interface by using the
access group command.
So access list command creates the access list, access group command binds the access list and when you bind
it, either specify inbound or outbound.
In other words, determining the direction that the access list is bound, it's important to note that
an ACL does not take effect until it's applied somewhere.
So if you have access lists in the running configuration of a router and they haven't been applied that
have no effect, they are two steps.
You create the axis list and then you apply it somewhere.
For instance, inbound on fast Ethernet 0/0.
So once again, Inbound ACLs applied inbound on an interface, the ACL will be processed before the traffic
traffic will be reported.
In other words, if the ACL denies the traffic and the traffic is discarded, the router will not have
to process the packets by looking at its routing table and determining the outbound interface.
The packets will be discarded or dropped before the routing engine needs to process them.
If they are permitted, they will be processed for routing and the router will determine the outgoing
interface, if discarded
there is no additional overhead on the router because the router does not need to do a routing table
lookup to determine the egress or outgoing interface.
If the traffic is permitted, the routing process will then do the routing table lookup to determine
the outgoing interface.
With outbound ACLs, routing is performed first and then the package is directed to an outbound interface
and then based on the ACL, the packets will be permitted, in other words, transmitted or denied.
It is therefore more efficient to bind an access list inbound on an interface because packets that are
dropped or denied will not need to be processed by the routing process on the router.
If an ACL is applied outbound, the router still has to process all the packets which may then be denied
or dropped on the outbound interface.
So where possible, bind ACLs inbound on interfaces rather than outbound for more efficient processing.
An access list is a sequential list of statements where packets are evaluated from the first statement
to the last.
In other words, there is top down processing.
If a packet is matched by an individual statement in the access list, that packet will either be permitted
or denied, depending on whether the permit or deny Keywood is used in that specific statement or remaining
lines of the access list or ignored for that specific packet.
So in other words, as soon as there's a match on a line all remaining lines are ignored, if the traffic
does not match that specific line or statement, then the next line in the ACL is checked.
So next list is a sequential list of statements and the Rada will check from the first line to the last
until it gets a match.
As soon as there's a match, all subsequent lines are ignored.
If there is no match for any statement in the ACL, the packet is dropped because of what's called the
implicit deny at the end.
At the end of every access list, there's an implicit denial, which means if you're not explicitly
permitted by an access list, you are implicitly denied.
All traffic not permitted somewhere in that access list with the use of a permit statement will be dropped.
That means, therefore, that you must have at least one permit statement somewhere in your access list,
Otherwise you might as well unplug the cable.
Now there are two main types of access lists that we concentrate on in this course.
The first is a standard ACL and the second is an extended ACL, standard
ACLs only check on source IP addresses
they do not check on individual port numbers or individual protocols.
They either permit or denied the entire protocol suite based on the source IP address or source network.
Nothing else in the source IP address or source network can be specified.
Extended ACLs check on both the source and destination address and allows you to permit or deny specific
protocols and applications.
In other words, you could permit or deny based on IP, TCP, UDP, ICMP and many other protocols
and you can also permit or deny based on source port numbers and destination port numbers.
Extended access lists are therefore a lot more granular and tend to be used in the real world.
But for completeness, we need to cover both standard and extended access lists in this course.