Lesson 50 - Extended ACL Examples

Try to think of this post as your opportunity to put the extended ACLs into practice. Do not look at the solutions which are presented at the end of this post. Try to accomplish the tasks using IOS help '?' If you have found this difficult, you can look at the solutions and watch my videos I posted on Youtube. ACL related video links can be found at the bottom of this post.

The last video shows the syntax and benefits of using Named ACLs. Once you get to know named ACLs, you will not want to use numbered ones.

Look at this simple topology below first. Then

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Extended ACL Lab

Assumptions
You are in charge of R1 and R2 routers. R3 belongs to your Service Provider network (SP) and simulates Internet in our examples. If you want to enable HTTP access on the router, type in the 'config' mode:
ip http server

Static routing has been configured between routers.

Task 1
Configure an access-list disabling anyone TELNET to R1 and all devices behind it (R2) if the traffic is originated from Internet (here: SP). All other traffic should be permitted.

Task 2
On R1 remove the previous ACL and configure a new one allowing only HTTP access to 172.16.102.0/24 if the traffic is originated from Internet (here: SP). All other traffic should be discarded.

Task 3
On R1 remove previously configured access-list. Instead, allow the returning traffic from HTTP (172.16.102.0/24) towards any destination. All other traffic from 172.16.102.0/24 should be discarded.

Task 4
Remove previously configured ACL. Configure an access-list that blocks the TELNET/SSH traffic to R1 if the traffic is originated by 10.1.13.3 address. Use a standard ACL.

Extended ACL Lab

Task 1

Configure an access-list disabling anyone TELNET to R1 and all devices behind it (R2) if the traffic is originated from Internet (here: SP). All other traffic should be permitted.

R1 Configuration:

!

R1(config)#access-list 100 deny tcp  any any eq telnet
R1(config)#access-list 100 permit ip any any
R1(config)#int s0/1
R1(config-if)#ip access-group 100 in
R1(config-if)#end
R1#

!

Verification:

Pic. 2 - Ping from R3.

Pic. 3 - Telnet Test from R3.

Pic. 4 - ACL Statistics.

Task 2

On R1 remove the previous ACL and configure a new one allowing only HTTP access to 172.16.102.0/24 if the traffic is originated from Internet (here: SP). All other traffic should be discarded.

R1 Configuration:

!

R1(config)#no access-list 100
R1(config)#int s0/1
R1(config-if)#no ip access-group 100 in
R1(config-if)#exit
R1(config)#
R1(config)#access-list 101 permit tcp any host 172.16.102.2 eq www
R1(config)#int s0/1
R1(config-if)#ip access-group 101 in
R1(config-if)#

!

Notice!
There is an 'implicit' deny all at the end of the ACL that is why I do not have to use: 'deny ip any any' statement.

Verification:

Pic. 5 - ACL Test.

Notice!
I got the connection to port 80 and terminated session using GET command. In order for the router to accept incoming connection to TCP 80 (WWW), you must type in the following command in the 'config' mode:
ip http server


Task 3

On R1 remove previously configured access-list. Instead, allow the returning traffic from HTTP (172.16.102.0/24) towards any destination. All other traffic from 172.16.102.0/24 should be discarded.

R1 Configuration (one way of accomplishing the goal):

!

R1(config)#int s0/1
R1(config-if)#no ip access-group 101 in
R1(config-if)#exit
R1(config)#no access-list 101
R1(config)#
R1(config)#access-list 102 permit tcp 172.16.102.0 0.0.0.255 eq 80 any
R1(config)#int f1/0
R1(config-if)#ip access-group 102 in
R1(config-if)#

!

Task 4
Remove previously configured ACL. Configure an access-list that blocks the TELNET/SSH traffic to R1 if the traffic is originated by 10.1.13.3 address. Use a standard ACL.
R2 Configuration:

!

R1(config)#int f1/0
R1(config-if)#no ip access-group 102 in
R1(config-if)#exit
R1(config)#no access-list 102
R1(config)#
R1(config)#access-list 1 deny host 10.1.13.3
R1(config)#access-list 1 permit any        

R1(config)#
R1(config)#line vty 0 4
R1(config-line)#access-class 1 in
R1(config-line)#exit
R1(config)#

!

Notice!
Because I forgot to mention this little contraption in my Standard ACL post, here it is. A standard ACL can be used to block traffic to ports VTY (remote access). The ACL is applied using the: access-class statement.

Pic. 6 - Verification.

Notice!
Changing the source of my TELNET (lo0=172.16.103.3) allows me to login.

If you want a guided tour through the solutions please click the below links. The two last videos will add extra tools to your toolbelt. I hope you'll find them useful as well.



In my next post, I'll attempt to explain Network Address Translation (NAT) which you must be familiar at CCNA level (as of the time of posting it).

Lesson 49 - Packet Filtering with Extended ACLs

This post I start with presenting solution to the Task 2 I left unanswered in the lesson 49.

Task 2
Configure an IP standard ACL that denies packets coming from the host 172.31.123.3 going towards 192.168.5.0/24. Traffic from other sources should be allowed.

Again, we use the standard IP ACL here, which is going to be applied on R5. Here goes:

R5 Configuration:

!

! In the global config 

!

access-list 1 deny host 172.31.123.3

access-list 1 permit any

!

! Enter the the incoming interface and apply the access-list

!

interface serial0/2

 ip access-group 1 in

!

Notice!

• access-list 1 - ACL numbers 1-99 are IP standard ACLs (check source of the packets only.
• host 172.31.123.3 - this keyword is an alias for: 172.16.123.3 0.0.0.0. It is a source address of the packets being inspected.
• any - this keyword is an alias for: 0.0.0.0 255.255.255.255 - any source here.

I hope your answers were correct. Now is the time to learn Extended ACLs.

First, look at the syntax you see in Cisco documentation:

Pic. 1 - Extended ACL Syntax.

If you go like: 'OMG!' do not worry because you do not have to use all these keywords.

The options we are going to use can be presented as follows:

Pic. 2 - Extended ACL Common Syntax.

It looks a bit more convoluted but do not worry because in time you will feel quite confident with it. Your best friend is help '?' which is going to show you what options and arguments are required.

The best way to explain the syntax you need to get familiar with is to use an example and try to de-construct it. So, let's look at our topology one more time and create the following filter:

Task 1
Deny telnet sessions coming from 192.168.4.0/24 destined to 172.31.3.0/28 and 172.31.3.16/28. All other traffic should be allowed.

Pic. 3 - Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Which ACL type should we use?
Since, we are very specific in terms of which protocols we want to deny, we must use Extended ACL. The standard ACL can only match on the source IP address, permitting or denying all protocols the packet is carrying.

Which router/interface should we apply the ACL on?
Our topology clearly shows that R3 has three different interfaces with three different addresses. So, we have two options here:

• We can configure an Extended ACL on R4 FastEthernet 1/0 interface in the inbound direction (close to the source as per ACL guideline)
• We can configure an Extended ACL on R4 Serial0/2 in the outbound direction.
• Alternatively, we can apply an Extended ACL on R3 FastEthernet1/0 (inbound).

I'm going to chose the option suggested by the ACL guide lines: as close to the source as possible.

Let's read the task again:


Task 1

Deny telnet sessions coming from 192.168.4.0/24 destined to 172.31.3.0/28 and 172.31.3.16/28. All other traffic should be allowed.

Here's one way to configure this:

R4 Configuration:

!

! In the global 'config' mode the statements are:

!

access-list 100 deny tcp 192.168.4.0 0.0.0.255 172.31.3.0 0.0.0.15 eq 23

access-list 100 deny tcp 192.168.4.0 0.0.0.255 172.31.3.16 0.0.0.15 eq 23

access-list 100 permit ip any any

!

! Apply the ACL on the interface

!

interface Serial0/2

  ip access-group 100 out

!

Three lines that 'deny' traffic are similar. Let's dissect its syntax:

access-list 100 deny tcp 192.168.4.0 0.0.0.255 172.31.3.0 0.0.0.15 eq 23

• access-list 100 - The extended ACL (numbers 100-199)
• deny - condition (either 'deny' or 'permit' are allowed)
• tcp - layer 3 or 4 protocol (such as: ip, icmp, tcp, udp, rip, eigrp etc.)
• 192.168.4.0 - source IP address
• 0.0.0.255 - source wildcard mask (inversed mask)
• 172.31.3.0 - destination IP address
• 0.0.0.15 - destination wildcard mask (inversed mask)
• eq - operator: eq (equal), lt (less than), gt (greater than), range
• 23 - destination port (telnet)

Notice!
After source wildcard there is no source port. This means that the source port is not inspected at all (disregarded).

In the next post I'm going to show you few examples of extended ACL which should reinforce your study (today I have a friend over from UK so no time to do it ;))

Lesson 48 - Standard ACL Examples

Pic. 1 - Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1

Configure an IP standard ACL that denies packets coming from 172.31.3.16/28 going towards 192.168.4.0/24. All other traffic should be allowed.

Task 2

Configure an IP standard ACL that denies packets coming from the host 172.31.123.3 going towards 192.168.5.0/24. Traffic from other sources should be allowed.

Let's get 'em tiger!

When it comes to configuring ACLs my work flow goes like this:

1. Which ACL is going to accomplish my goal: Standard or Extended?
2. Which router and interface should I apply the ACL on?
3. Which direction should I use: in or out?

Dig this! 

Since as of this moment we talk about standard ACL, the answer to the first question is obvious: standard ACL must be used. In real life examples, the goals you try to accomplish will impose the criteria. If you must filter out some specific TCP traffic (e.g. going towards port 80), an extended ACL must be used as the standard one cannot filter on TCP (source IP only).

The guidelines specify that standard ACL must be placed as close to the destination as possible. Think about it. If I applied the ACL in Task 1 on R3 F1/0 out, the packet with the source 172.31.3.32/28 could not go anywhere out that interface. We're supposed to filter this source going towards Branch 1 (R4) and not anywhere else. R4 is going to be the router I'm going to apply the ACL on.

As for the last question about the direction, I could use R4's S0/2 inbound or F1/0 outbound. Since there are only two interfaces, I can apply this on s0/2 inbound and it won't make much difference except that the packet will be rejected on the inbound interface. This way, R4 won't have to do layer 3 lookup and waste it resources. If there were more interfaces I would use it on F1/0 interface outbound since the traffic should not be sent to the specific network (192.168.4.0).

Task 1

Configure an IP standard ACL that denies packets coming from 172.31.3.16/28 going towards 192.168.4.0/24. All other traffic should be allowed.

Pic. 2 - Communication Before Applying ACL.

Notice!

I pinged from the subnet in question (172.31.3.16/28).

R4 Configuration:

!

! Step 1 - Create an ACL statement in the global config

R4(config)#access-list 1 deny 172.31.3.16 0.0.0.15
R4(config)#access-list 1 permit any              
R4(config)#

!

! Step 2 - Apply the ACL on the interface

R4(config)#int s0/2
R4(config-if)#ip access-group 1 in
R4(config-if)#

!

Verification:

Pic. 3 - Communication After Applying ACL.

Notice!

Only packets sourced from the 172.31.3.16/24 are being blocked on R4. The packets from 172.31.3.0/28 are getting through.

Pic. 4 - R4's ACL counters.

I owe you an explanation here.

!

R4(config)#access-list 1 deny 172.31.3.16 0.0.0.15

!

access-list 1 - the number 1 implies the standard ACL (1-99)

deny - the packets meeting the criterion that follows will be denied (dropped)

172.31.3.16 - the source IP criterion

0.0.0.15 - the wildcard mask which is the subnet's inversed network mask

The subnet's network mask is: 255.255.255.240. In the binary it looks like:

11111111.11111111.11111111.11110000

If we inverse this network mask we get:

00000000.00000000.00000000.00001111

That, converted to decimal is: 0.0.0.15

Easy right?

!

R4(config)#access-list 1 permit any

!

permit any - this permits all other source IP. The word 'any' is the alias for:

0.0.0.0 255.255.255.255

Try to write an ACL according to the Task 2 description on your own. I will show you the solution in the next post.

In my next post: solution to the Task 2 and extended ACLs. 

Stop by and see what magic they can do! Meanwhile, happy studying!

Lesson 47 - Packet Filtering with Standard ACL

NOTICE!
Access Control Lists can inspect the traffic based on different protocols and criteria. In this post I’m going to focus in on IP-based ACLs. Other types such as MAC-based ACLs, dynamic or reflective ACLs are beyond the scope of this tutorial.

Have you noticed how your hand luggage is being scanned at the airport? ACL is similar to such scanner only used on the router. It can look at the content of the packet traversing it and check the content of the packet up to the layer 4 (extended ACL). You, as an administrator, get to decide what the action is going to be if the packet matches your criteria. A few applications of ACLs are as follows:

• ACLs can filter the packets that traverse the router in order to drop the unwanted traffic.
• ACLs can deny SSH or Telnet traffic to vty lines (router/switch remote management).
• ACLs are used as to match an interesting traffic to trigger VPN tunnel establishment and encrypt data.
• ACLs are commonly used in Quality of Service to prioritize certain applications or traffic flows over others or provide different treatment to a certain stream of packets.
• ACLs are used to filter inbound or outbound dynamic protocol advertisements.
• Etc.

To summarize it: you cannot call yourself a network specialist without being able to use ACLs. In this tutorial, we focus in on IP based ACLs.

IP  Based ACLs
You can use two major IP-based ACLs (look at the guidelines above):

1. Standard ACLs (numbers: 1 through 99)
2. Extended ACLs (numbers: 100 through 199)
3. Named ACL (standard or extended). Named ACLs offer more flexibility in terms of modifying ACLs 'on the fly'

The major differences between them are the amount and type of criteria we can use to inspect the packets as well as the syntax used to create the statement.

In this post I present IP standard ACL only used as a filtering mechanism (permit or deny the traffic through the router), but get familiar with the general guidelines first as they apply to all types and applications of ACLs.

ACL Guidelines
Here are some important guidelines regarding ACLs:

• ACLs use the top-down processing. This means that statements are being processed from the one listed on the top of the list first. If the statement is a successful match (permit or deny), the remaining entries listed below this matching statement are NOT inspected anymore.
• Cisco IOS allows to apply only one ACL per interface, protocol and direction. This means that you can apply ACL1 on two different interfaces, or ACL1 and ACL2 on the same interface but in two different directions (in and out).
• The ACL number will determine whether it is IP standard ACL (numbers 1-99) or IP extended ACL (numbers 100-199).
• Standard ACL can only inspect the source IP of the packet.
• Extended ACL will inspect both source and destination IP. In addition to these it can match on layer 4 protocols (TCP, UDP, OSPF, EIGRP etc.) and even the layer 4 port numbers (either source or destination or both).
• The standard ACLs should be placed close to the destination, extended ACLs should be placed close to the source of the transmission.
• There is an IMPLICIT DENY ALL at the end of all the statements that you create. This means, that if your statements have been created to deny traffic, there must be at least a single permit statements. Otherwise all traffic crossing the interface where ACL has been configured will be denied (filtered out).

The process of configuring ACLs consist of two steps:

1. Configuring the ACL statements in the global configuration mode.
2. Applying the ACLs on the interfaces to inbound or outbound traffic.

Standard Access Lists
Standard ACL offers you only a single criterion to single packets out from the flows a router handles. It is a source IP address. Based on this criterion, a router determines if the packet should be forwarded or dropped. This type of ACL does not check if IP carries TCP, UDP, OSPF, EIGRP etc. Based on the source IP address the “whole” IP packet (irrespective of the layer 4-5 content) will be forwarded or dropped.

This time, I'm going to show you the syntax taken directly from the Cisco web site. The point is, that sooner or later you have to learn how to use the official Cisco Documentation. You must learn how to be self-reliant at your work because in many cases you will not have anyone around to take you by the hand and solve an issue.

The ultimate source of all Cisco related configurations can be found at (here IOS 12.4 version):

http://www.cisco.com/en/US/products/ps6350/tsd_products_support_series_home.html

Pic. 1 - IP Standard ACL Syntax.

Pic. 1 shows you the standard ACL syntax you type in the 'config' mode (global configuration mode.

• access-list - the ACL keyword that is followed by a number of argument
• access-list-number - IP standard ACLs use the numbers in the range 1-99
• permit|deny - what is in braces '{}' are possible options; here permit or deny
• host|source - again in braces '{}' are possible options; here either a host address or other source such as network or subnet.
• source-wildcard|any - this is the inversed network mask ('1' becomes '0' and vice versa).

Bold font is the keyword that you must use.
Italic font is the arguement that follows the keyword.
| - a pipe is the logical 'or' statement giving you multiple choices.
{} - in braces the possible options are listed.

The next step in configuring an ACL (standard or Extended) is to apply it on the interface in either inbound or outbound direction.

Pic. 2 - Applying ACL on the Interface.

interface - the keyword to enter the interface context (must be in the 'config mode')
<interface> - type/number of the interface (e.g. interface Fa0/0)
ip access-group - the keyword that applies an ACL on the interface
number - the number of access-list configured in the 'config' mode (standard ACL use range 1-99)

in|out - the direction inbound or outbound (how packets are going to be processed)

INBOUND ACLs
This type of ACL analyzes the packets coming towards the router (the interface where packet was received on). Based on the criteria defined in the ACL, the packet will further be processed (layer 3 lookup performed trying to find the outbound interface), or dropped.

OUTBOUND ACLs
If you apply the ACL as 'out' the incoming interface does NOT compare the packet content with the ACL statements. It performs a layer 3 lookup immediately. Once the outbound interface is found, and the ACL is applied there as 'out' it analyzes the ACL statement one by one (top-down). Once the match is found (permit or deny) the packet is or is not sent out that interface.

Remember, that IP standard ACLs check the source IP only!


In the next post, I show you a few examples of IP standard ACL with a detailed analysis how they work. This and the next post should get you going with IP standard ACLs.