Standard Access Lists

Standard Access Lists

Objective:

  • Configure and apply ACLs based on network filtering requirements.

Cisco provides two primary categories of IP-based access lists: standard and extended. Standard access lists can permit or deny traffic based only on the source IP address. For example, I can set up an access list that says the host 192.168.1.1 is denied. However, if I use a standard access list to accomplish this, I can never say what destination the host is denied from reaching or what protocol it is denied from using; I can say only that they are denied. Period.

Therefore, the interface on the router where you apply the standard access list can make all the difference. The benefits of using standard access lists are the simplicity and resource usage. Because the standard access lists filter based only on the source IP address, the router processor and memory resources are not as taxed as they are when you use an extended access list.

Configuration of Standard Access Lists

Whenever you decide to begin configuring any type of access list, remember this wisdom from the Cisco elders: Context-sensitive help is your friend. If you have not yet become accustomed to entering a question mark after each step of your configuration, now is the perfect chance to gain that familiarity. In these initial examples, the question mark is entered after each command to find out what arguments the router expects next.

The standard access list is created from Global Configuration mode with the access-list command, so that’s where this example begins: Neo(config)#access-list ?

dynamic-extended Extend the dynamic ACL absolute timer Just by looking at the categories of access-list, you can tell what protocols this router supports. In this case, the router supports the IP-only feature set. Otherwise, you would see access list categories for each protocol (such as IPX/SPX, Appletalk, or Decnet). Notice the number ranges for each access list; the type of access list you are going to create depends on what number you type after the access-list command. If you were to type access-list 25, the syntax that followed would be that of a standard access list because you chose a number between 1 and 99. Likewise, if you were to enter the command access-list 135, the syntax that followed would be that of an extended access list because you chose a number between 100 and 199.

EXAM ALERT
Knowing that access list numbers 1–99 represent standard access lists and 100–199 represent extend ed access lists increases your chances of passing the CCNA exam by at least 1.2%.

In addition to dictating the type of access list that will be created, the access list number represents your access list as a whole. As the name “access list” implies, each access list number can contain many individual statements. For example, you could create access list 4, which contains 3000 specific lines dictating what source IP addresses are permitted and denied.

Even though each access list can contain many statements, if you have a router with an extremely complex configuration, you could run out of access lists. For this reason, Cisco created the expanded access list ranges for both standard (1300–1999) and extended (2000–2699) access lists, as shown in the prior syntax. This ensures that routers will never run out of IP access list numbers again. The configuration example continues by using access list number 25:

You are now given the option to either enter an IP address, use the any keyword to match any source host address, or to use the host keyword to match a single host address. You might ask

the question at this point, “So do I enter the IP address 10.1.1.5 here, or the keyword host?” You can enter either one. Try entering the IP address first, and then the example returns to the host command:

Neo(config)#access-list 25 permit 10.1.1.5 ?
A.B.C.D Wildcard bits
log Log matches against this entry
Because the host keyword was not used, the router is now prompting for the correct wildcard bits. This may bring back bad memories of the OSPF routing protocol, which is another major router configuration that relies on wildcard masks (also called inverse masks) to specify OSPF interface(s). Just to review, a wildcard mask is exactly the opposite of a subnet mask. The zero bits (0) of a wildcard mask say, “Look at these,” whereas the one bits (1) of a wildcard mask say, “I don’t care.

” For example, if you entered the IP address 172.16.0.0 with a wildcard mask 0.0.255.255, the router would look at the 172.16 digits (because they matched the binary zeros in the wildcard mask) and would not care about the 0.0 digits (because they matched the binary ones in the wildcard mask). This means that the address 172.16.90.100 would match because all the router cares about is that the address starts with 172.16. This now brings us back to the configuration. You need to create a wildcard mask that matches exactly the IP address 10.1.1.5. It would be safe to say that you want the router to look at every single octet of that IP address,

so the appropriate wildcard mask would be 0.0.0.0. Here’s a look at the complete line of syntax:
Neo(config)#access-list 25 permit 10.1.1.5 0.0.0.0 ?
log Log matches against this entry
<cr>
Notice that the only options context-sensitive help gives you is to enter the log command (which writes a record to the router log file anytime this entry is matched) or to press Enter. If you choose the latter, you enter your first line into an access list. Let’s work through the syntax one more time to add a second statement to the access list. This time, you want to permit
the entire 192.168.77.0/24 subnet: Neo(config)#access-list ?

rate-limit Simple rate-limit specific access list

Notice the IOS on the Neo router has been upgraded to a version that supports a few more protocols than the prior IOS version. You will now continue on through this configuration of permitting the entire 192.168.77.0/24 subnet, using context-sensitive help to guide you through each additional piece of syntax.

The second line has just been added to access list 25. Notice that the wildcard mask 0.0.0.255 tells the router to look at the 192.168.77 (the first three octets of zero bits in the wildcard mask), and to ignore the last octet (because of the one bit in the last octet of the wildcard mask). You can now use a couple of show commands to verify your work: show ip accesslists or show running-config.

Initially, it looks as if the router lost the wildcard mask that was added for the 10.1.1.5 host. The Cisco router removes the 0.0.0.0 because an IP address without the wildcard mask is assumed to be an individual host anyway.

EXAM ALERT
Some IOS versions completely remove the wildcard mask as shown in the text, whereas other, newer IOS versions insert the host keyword, such as in the following: access-list 25 permit host 10.1.1.5 To be safe on the CCNA exam, always use either the wildcard mask or the host keyword when config uring your access list in a simulation. Never just type in an IP address and press Enter. Although this may work on real Cisco equipment, the test simulations may deduct points.

Placement of Standard Access Lists

As mentioned before, you can create access lists all day on your router and no functional change will ever occur. Access lists take effect only when you apply them in some way. This chapter focuses on applying access lists for security purposes. Access lists can be placed inbound or outbound on any router interface. When applying access-list for security,
remember this mantra:
One access list…
…per protocol,
…per interface,
…per direction
You must take these rules into account when deciding how to engineer the access list. Here is what the mantra means: You must design a single access list to include all the possible permit and deny statements you need for each protocol (such as TCP/IP or IPX/SPX, not subprotocols such as TCP or UDP) on a single interface for the inbound or outbound direction.
You are allowed to apply only one access list number inbound and one access list outbound.

Finally, keep this in mind before you apply an access list: The access list goes into effect immediately when applied. Before you apply the access list, check the access list thoroughly to make sure you have allowed enough traffic to pass through. The most common mistake made by network administrators is to create an access list and quickly list the items they want to deny. They then apply this to an interface, forgetting about the implicit deny at the end of the access list. The access list then acts as a “deny all” statement for the interface, effectively shutting down the communication on that interface. If this is done in a production network, it can have devastating effects.

The other common mistake is to make changes to an access list while it is applied to an interface. Although this can be done successfully, it is not recommended. The changes go into effect immediately after you press the Enter key, not giving you the time you need to take the entire access list into consideration.

NOTE
Many Cisco administrators create their access lists in a text editor such as Notepad, which enables you to reorder the statements as you see fit before the access list is created and applied.

With all these cautions in place, the syntax to apply the access list to the interface is simple. Use the following syntax from interface configuration mode:

Router(config-if)#ip access-group <access_list_number> <in/out>

The <in/out> keyword tends to be the most confusing portion of this syntax. The in keyword
filters inbound traffic to the interface, whereas the out keyword filters outbound traffic from the interface. The easiest way to remember this is to picture yourself as a router. Seriously, stand up and say out loud, “I am a router.” Now hold your arms out and picture them as router interfaces. Your left arm is a FastEthernet connection to a switch. Your right arm is a serial link to a remote office. If you apply an access list on your FastEthernet interface in the IN-bound direction, it filters traffic coming from the switch, up your arm, and into your body. If you apply it OUT-bound on your FastEthernet interface, you are filtering traffic leaving your body, and going out to the switch. By putting yourself in the place of the router, you will get the direction right every time.

EXAM ALERT
Cisco testing procedures do not currently restrict you from standing and waving your arms wildly in the testing center as long as you do not hit any other test takers.

For example, let’s apply access list 25 that was created previously to a router’s FastEthernet 0 interface in the inbound direction. Just as a refresher, I list the syntax used to create the access list first, and then apply it to the interface:

The access list is now applied and in effect. The router permits the host 10.1.1.5 and anyone from the network 192.168.77.0/24 to enter the router’s FastEthernet 0 interface (inbound) from an attached switch. The implicit deny keeps any other devices from entering FastEthernet 0.

Standard Access List Examples

Now let’s start putting this newfound knowledge into practice. Use the topology shown in Figure 19.1 to see a visual diagram for this example.

Isolating Networks
To keep devices on Network 3 from accessing devices on Network 1 the first thing you must determine is where in the network you want to create the access list. When configuring standard access lists, the best practice is to create and apply the access list on the router closest to the destination. Standard access lists cannot dictate what the source IP addresses are permitted or denied; they can say just that they are permitted or denied. By applying the access list close to the destination, you effectively limit the scope of effect that the access list has. If you apply it too close to the source, you may deny or permit too much. You will see more examples of this as you work through applying more access lists.

EXAM ALERT
Know that the best practice of standard access lists is to apply them on the interface closest to the destination.

When you look at the figure, you can see that the Homer router is closest to the destination (Network 1), so that is the place to begin configuration:

A line has been added to the access list to block Network 1. If the access list is left like this, it will also deny all other traffic because of the implicit deny at the end, so you need to add a statement that permits all other networks to reach Network 1:
Homer(config)#access-list 30 permit any

TIP

The any keyword is a shortcut, just as the host keyword is. You could accomplish the same thing by using the statement:
access-list 30 permit 0.0.0.0 255.255.255.255 When you have a wildcard mask of all 255s, the router does not care what you enter for the IP address (which is all zeros in this case, but could have been anything). This is equivalent to a permit any state ment. Use whichever one you feel more comfortable with.

You have created the access list; now it’s time to apply it. Looking back at the figure, there are two possible places to apply this access list on the Homer router: inbound on the S0/0 interface, or outbound on the Fa0/0 interface. Using the best practice of applying closest to the destination, this is how to do the latter:

Isolating a Network from Specific Hosts
You now need to prevent just two devices (the Network 1 and 2 hosts) from accessing Network 3. If you remember the rule of applying the standard access list closest to the destination, you know that the configuration should be performed on the Marge router:

Now that the access list has been created, you have to decide where to apply it. Initially, you might eye the S0/0 interface inbound. If you applied it there, the host 172.16.70.100 and 172.16.60.100 would be denied as soon as they tried to make their way into the S0/0 interface of Marge. Although this would prevent the hosts from reaching Network 3, it would also block
them from accessing Network 1 and the Internet (because they cannot even enter the Marge router). Aha! Do you now see why it is so important to apply the standard access list close to the destination? In this case, you need to apply it to the FastEthernet 0/0 interface, outbound:

Perfect. This part of the example is complete.

Isolating the Internal Network from the Internet
The servers on Network 3 contain confidential information and should not be accessible from the Internet. Assuming your entire internal network uses 172.16.0.0/16 addresses, this configuration should maintain the isolation of Network 3 from Network 1 and 2 hosts.

Wow! This requires a little thought. You have no idea what addresses may be trying to come in from the Internet, so you have to reverse your strategies. So far, you have been denying a host or network and permitting everything else. You must now permit what you know and deny everything else, still keeping in mind that you cannot allow the two hosts from the previous
objective to access the server. Start on the Marge router in Global Configuration mode and remove the access list applied previously:
Marge(config)#no access-list 45

CAUTION
Removing the access list by using the no access-list <number > command does not remove the access-group command from the interface. The access list is still applied! Thankfully, an empty access list allows all traffic (this overrules the implicit deny statement). However, as soon as you add one line to the access list, the implicit deny statement is reapplied with all its fury. It is a very good idea to un-apply the access list from the interface while you make changes.

Whew! That caution popped up at just the right place. Let’s follow that advice:

Now you can start on a new access list. First, deny the specific hosts that should not be able to reach Network 3:

Notice that the wildcard mask cares about only the first two octets of the IP address, thus permitting any IP address that begins with 172.16. This is why the deny statements for the hosts were listed first. Otherwise, this line would have permitted them. With the one permit statement added, you have finished creating the access list. The implicit deny should catch any other networks not specified (including those coming from the Internet). Finally, using best practices, you need to apply this list close to the destination:

Awesome! This just keeps getting better. Mission accomplished.

Restricting VTY Access

Objective:

  • Configure and apply ACLs to limit telnet and SSH access to the router

Now here’s a new application for an access list. So far, access lists have been applied inbound and outbound on interfaces, but access lists can also be applied to VTY lines (which are used for Telnet and SSH). This example will allow only the host on Network 2 to Telnet to the Marge router. The command syntax to do this differs slightly from applying an access list to an interface. Instead of using the ip access-group command, use the access-class command. After referring back to the figure, you can see that the host on Network 2 has the IP address 172.16.70.100. Here’s the configuration:

That’s it! The implicit deny blocks all other hosts from accessing your VTY lines. This brings up a huge tip.

CAUTION
If you are configuring access lists on your router remotely, be sure to allow your remote Telnet session access into the router in the access list. It is a very common mistake to create an access list that kills the remote Telnet session and requires the administrator to drive to the site (or contact someone on-site) to reconfigure the router through the console port. It is, therefore, a good practice to issue the following command before applying an access list remotely:
Router# reload in 5
This instructs the router to reboot itself in 5 minutes if there is no administrative intervention. This way, if you lock yourself out of the router, it reboots and sets its configuration back to what it was before you applied the access list. If the access list applies successfully without limiting remote access, be sure to issue the reload cancel command to stop the automatic reboot countdown.

About the author

Prasanna

Leave a Comment