Configure, verify, and troubleshoot port security

It's usually not a good thing to have your switches available for anyone to just plug into and play around with. I mean, we worry about wireless security, so why wouldn't we demand switch security just as much, if not more?

But just how do we actually prevent someone from simply plugging a host into one of our switch ports—or worse, adding a hub, switch, or access point into the Ethernet jack in their office? By default, MAC addresses will just dynamically appear in your MAC forward/filter database and you can stop them in their tracks by using port security!

Static

You can set a static MAC address in the MAC address table, but it's a ton of work. Just in case you want to do it, here's how it's done:

S3(config)#mac address-table ?

  aging-time    Set MAC address table entry maximum age

  learning      Enable MAC table learning feature

  move          Move keyword

  notification  Enable/Disable MAC Notification on the switch

  static        static keyword

 

S3(config)#mac address-table static aaaa.bbbb.cccc vlan 1 int fa0/7

S3(config)#do show mac address-table

          Mac Address Table

-------------------------------------------

 

Vlan    Mac Address       Type        Ports

----    -----------       --------    -----

 All    0100.0ccc.cccc    STATIC      CPU

[output cut]

   1    000e.83b2.e34b    DYNAMIC     Fa0/1

   1    0011.1191.556f    DYNAMIC     Fa0/1

   1    0011.3206.25cb    DYNAMIC     Fa0/1

   1    001a.4d55.2f7e    DYNAMIC     Fa0/1

   1    001b.d40a.0538    DYNAMIC     Fa0/1

   1    001c.575e.c891    DYNAMIC     Fa0/1

   1    aaaa.bbbb.0ccc    STATIC      Fa0/7

[output cut]

Total Mac Addresses for this criterion: 59

As shown in the Type column of the output, you can see that a static MAC address has now been assigned permanently to interface Fa0/7 and that it's also been assigned to VLAN 1 only.

Dynamic

When utilizing dynamic port security, you specify the total number of allowed MAC addresses and the switch will allow only that number simultaneously, without regard to what those MAC addresses are.

To enable dynamic port security, you simply enable port security on the port without specifying the allowed MAC address. The MAC will be learned and will be the only allowed address. The configuration is shown here:

SW1(config)#interface fa0/3

SW1(config-if)#switchport mode access

SW1(config-if)#switchport port-security

Sticky

Probably one of my favorite commands is the sticky command, and not just because it's got a cool name. It also makes very cool things happen! You can find this command under the mac-address command:

Switch(config-if)#switchport port-security mac-address sticky

Switch(config-if)#switchport port-security maximum 2

Switch(config-if)#switchport port-security violation shutdown

Basically, with the sticky command you can provide static MAC address security without having to type in absolutely everyone's MAC address on the network. I like things that save me time like that!

In the preceding example, the first two MAC addresses coming into the port “stick” to it as static addresses and will be placed in the running-config, but when a third address tried to connect, the port would shut down immediately.

The difference between dynamically learned MAC addresses configured by using the switchport port-security interface subcommand and sticky learned MAC addresses configured by using the switchport port-security mac-address sticky interface subcommand is that dynamically learned MAC addresses are not added to the running-config, whereas sticky learned MAC addresses are. Port security with sticky MAC addresses retains dynamically learned MAC addresses during a link-down condition.

Max MAC Addresses

If you want to set up a switch port to allow only one host per port and make sure the port will shut down if this rule is violated, use the following commands like this:

Switch(config-if)#switchport port-security maximum 1

Switch(config-if)#switchport port-security violation shutdown

These commands really are probably the most popular because they prevent random users from connecting to a specific switch or access point that's in their office. The port security default that's immediately set on a port when it's enabled is maximum 1 and violation shutdown. This sounds okay, but the drawback to this is that it only allows a single MAC address to be used on the port, so if anyone, including you, tries to add another host on that segment, the switch port will immediately enter an error-disabled state and the port will turn amber. And when that happens, you have to manually go into the switch and re-enable the port by cycling it with a shutdown and then a no shutdown command.

Violation Actions

You can configure the device to take one of the following actions when a security violation occurs by using the switchport port-security command with the following parameters:

• Protect: The protect violation mode drops packets with unknown source addresses until you remove enough secure MAC addresses to drop below the maximum value.
• Restrict: The restrict violation mode also drops packets with unknown source addresses until you remove enough secure MAC addresses to drop below the maximum value. However, it also generates a log message, causes the security violation counter to increment, and sends an SNMP trap.
• Shutdown: Shutdown is the default violation mode. The shutdown violation mode puts the interface into an error-disabled state immediately. The entire port is shut down. Also, in this mode, the system generates a log message, sends an SNMP trap, and increments the violation counter. To make the interface usable, you must perform a shut/no shut on the interface.

Err-disable Recovery

When a port is error disabled, it is effectively shut down and no traffic is sent or received on that port. The port LED is set to the color orange, and when you issue the show interfaces command, the port status shows err-disabled. Here is an example of what an error-­disabled port looks like from the command-line interface (CLI) of the switch:

switch#show interfaces gigabitethernet 3/1 status

 

Port    Name       Status       Vlan       Duplex  Speed Type

Gi3/1              err-disabled 200          full   1000 1000BaseSX

To recover the disabled ports, use the following command. The first is for a max MAC address violation and the second is for a disallowed MAC address violation.

switch(Config)#errdisable recovery cause mac-limit

switch(Config)#errdisable recovery cause psecure-violation

Exam Essentials

Understand the reason for port security. Port security restricts access to a switch based on MAC addresses.

Know the command to enable port security. To enable port security on a port, you must first make sure the port is an access port with switchport mode access command and then use the switchport port-security command at the interface level. You can set the port security parameters before or after enabling port security.

Describe common access layer threat mitigation techniques

Since the access layer is both the point at which user devices connect to the network and the connection point between the network and client device, protecting it plays an important role in protecting other users, applications, and the network itself from attacks.

Some of the ways to protect the access layer (also shown in Figure 6.1) are covered in the following sections.

802.1x

Identity-based networking is a concept that ties together several authentication, access control, and user policy components in order to provide users with the network services you want them to have.

In the past, for a user to connect to the Finance services, for example, a user had to be plugged into the Finance LAN or VLAN. However, with user mobility as one of the core requirements of modern networks, this is no longer practical, nor does it provide sufficient security.

Identity-based networking allows you to verify users when they connect to a switch port by authenticating them and placing them in the right VLAN based on their identity. Should any users fail to pass the authentication process, their access can be rejected, or they might be simply put in a guest VLAN. Figure 6.2 shows this process.

The IEEE 802.1x standard allows you to implement identity-based networking on wired and wireless hosts by using client/server access control. There are three roles:

Client Also referred to as a supplicant, this software runs on a client that is 802.1x compliant.

Authenticator Typically a switch, this controls physical access to the network and is a proxy between the client and the authentication server.

Authentication server (RADIUS) This is a server that authenticates each client before making available any services.

DHCP Snooping

DHCP snooping is a layer 2 security feature that validates DHCP messages by acting like a firewall between untrusted hosts and trusted DHCP servers.

In order to stop rogue DHCP servers in the network, switch interfaces are configured as trusted or untrusted, where trusted interfaces allow all types of DHCP messages and untrusted interfaces allow only requests. Trusted interfaces are interfaces that connect to a DHCP server or are an uplink toward the DHCP server, as shown in Figure 6.3.

With DHCP snooping enabled, a switch also builds a DHCP snooping binding database, where each entry includes the MAC and IP address of the host as well as the DHCP lease time, binding type, VLAN, and interface. Dynamic ARP inspection also uses this DHCP snooping binding database.

Dynamic ARP Inspection (DAI)

DAI, used with DHCP snooping, tracks IP-to-MAC bindings from DHCP transactions to protect against ARP poisoning (which is an attacker trying to have your traffic be sent to him instead of to your valid destination). DHCP snooping is required in order to build the MAC-to-IP bindings for DAI validation.

Nondefault Native VLAN

You can change the trunk port native VLAN from VLAN 1, which many people do for security reasons. To change the native VLAN, use the following command:

S1(config)#int f0/15

S1(config-if)#switchport trunk native vlan ?

  <1-4094>  VLAN ID of the native VLAN when this port is in trunking mode

 

S1(config-if)#switchport trunk native vlan 4

1w6d: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered

on FastEthernet0/15 (4), with S3 FastEthernet0/1 (1)

So we've changed our native VLAN on our trunk link to 4, and by using the show running-config command, I can see the configuration under the trunk link:

S1#sh run int f0/15

Building configuration...

 

Current configuration : 202 bytes

!

interface FastEthernet0/15

 description 1st connection to S3

 switchport trunk encapsulation dot1q

 switchport trunk native vlan 4

 switchport trunk allowed vlan 4,6,12,15

 switchport mode trunk

end

Oops—wait a minute! You didn't think it would be this easy and would just start ­working, did you? Of course not! Here's the rub: If all switches don't have the same native VLAN configured on the given trunk links, then we'll start to receive this error, which ­happened immediately after I entered the command:

1w6d: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered

on FastEthernet0/15 (4), with S3 FastEthernet0/1 (1).

Actually, this is a good, noncryptic error, so either we can go to the other end of our trunk link(s) and change the native VLAN or we set the native VLAN back to the default to fix it. Here's how we'd do that:

S1(config-if)#no switchport trunk native vlan

1w6d: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/15

on VLAN0004. Port consistency restored.

Now our trunk link is using the default VLAN 1 as the native VLAN. Just remember that all switches on a given trunk must use the same native VLAN or you'll have some ­serious management problems. These issues won't affect user data, just management traffic between switches. Now, let's mix it up by connecting a router into our switched network and configure inter-VLAN communication.

Exam Essentials

Understand how to mitigate threats at the access layer. You can mitigate threats at the access layer by using port security, changing the native VLAN id, DHCP snooping, dynamic ARP inspection, and identity-based networking.

Configure, verify, and troubleshoot IPv4 and IPv6 access list for traffic filtering

An access list is essentially a list of conditions that categorize packets, and they really come in handy when you need to exercise control over network traffic. An ACL would be your tool of choice for decision making in these situations.

One of the most common and easiest-to-understand uses of access lists is to filter unwanted packets when implementing security policies. For example, you can set them up to make very specific decisions about regulating traffic patterns so that they'll allow only certain hosts to access web resources on the Internet while restricting others. With the right combination of access lists, network managers arm themselves with the power to enforce nearly any security policy they can invent.

Creating access lists is really a lot like programming a series of if-then statements—if a given condition is met, then a given action is taken. If the specific condition isn't met, nothing happens and the next statement is evaluated. Access-list statements are basically packet filters that packets are compared against, categorized by, and acted upon accordingly. Once the lists are built, they can be applied to either inbound or outbound traffic on any interface. Applying an access list causes the router to analyze every packet crossing that interface in the specified direction and take the appropriate action.

There are three important rules that a packet follows when it's being compared with an access list:

• The packet is always compared with each line of the access list in sequential order—it will always start with the first line of the access list, move on to line 2, then line 3, and so on.
• The packet is compared with lines of the access list only until a match is made. Once it matches the condition on a line of the access list, the packet is acted upon and no further comparisons take place.
• There is an implicit “deny” at the end of each access list—this means that if a packet doesn't match the condition on any of the lines in the access list, the packet will be ­discarded.

Each of these rules has some powerful implications when you're filtering IP packets with access lists, so keep in mind that creating effective access lists definitely takes some practice.

There are several types of access lists: standard, extended, and named.

Standard

Standard IP access lists filter network traffic by examining the source IP address in a packet. You create a standard IP access list by using the access-list numbers 1–99 or numbers in the expanded range of 1300–1999 because the type of ACL is generally differentiated using a number. Based on the number used when the access list is created, the router knows which type of syntax to expect as the list is entered. By using numbers 1–99 or 1300–1999, you're telling the router that you want to create a standard IP access list, so the router will expect syntax specifying only the source IP address in the test lines.

The following output displays a good example of the many access-list number ranges that you can use to filter traffic on your network. The IOS version delimits the protocols you can specify access for:

Corp(config)#access-list ?

 <1-99>            IP standard access list

 <100-199>         IP extended access list

 <1000-1099>       IPX SAP access list

 <1100-1199>       Extended 48-bit MAC address access list

 <1200-1299>       IPX summary address access list

 <1300-1999>       IP standard access list (expanded range)

 <200-299>         Protocol type-code access list

 <2000-2699>       IP extended access list (expanded range)

 <2700-2799>       MPLS access list

 <300-399>         DECnet access list

 <700-799>         48-bit MAC address access list

 <800-899>         IPX standard access list

 <900-999>         IPX extended access list

 dynamic-extended  Extend the dynamic ACL absolute timer

 rate-limit        Simple rate-limit specific access list

Wow—there certainly are lot of old protocols listed in that output! IPX and DECnet would no longer be used in any of today's networks. Let's take a look at the syntax used when creating a standard IP access list:

Corp(config)#access-list 10 ?

  deny    Specify packets to reject

  permit  Specify packets to forward

  remark  Access list entry comment

As I said, by using the access-list numbers 1–99 or 1300–1999, you're telling the router that you want to create a standard IP access list, which means you can only filter on source IP address.

Once you've chosen the access-list number, you need to decide whether you're creating a permit or deny statement. I'm going to create a deny statement now:

Corp(config)#access-list 10 deny ?

  Hostname or A.B.C.D  Address to match

  any                  Any source host

  host                 A single host address

The next step is more detailed because there are three options available in it:

1. The first option is the any parameter, which is used to permit or deny any source host or network.
2. The second choice is to use an IP address to specify either a single host or a range of them.
3. The last option is to use the host command to specify a specific host only.

The any command is pretty obvious—any source address matches the statement, so every packet compared against this line will match. The host command is relatively simple too, as you can see here:

Corp(config)#access-list 10 deny host ?

  Hostname or A.B.C.D  Host address

Corp(config)#access-list 10 deny host 172.16.30.2

This tells the list to deny any packets from host 172.16.30.2. The default parameter is host. In other words, if you type access-list 10 deny 172.16.30.2, the router assumes you mean host 172.16.30.2 and that's exactly how it will show in your running-config.

But there's another way to specify either a particular host or a range of hosts, and it's known as wildcard masking. In fact, to specify any range of hosts, you must use wildcard masking in the access list.

So exactly what is wildcard masking? Coming up, I'm going to show you using a standard access list example.

Wildcard Masking

Wildcards are used with access lists to specify an individual host, a network, or a specific range of a network or networks. The block sizes you learned about earlier used to specify a range of addresses are key to understanding wildcards.

Let me pause here for a quick review of block sizes before we go any further. I'm sure you remember that the different block sizes available are 64, 32, 16, 8, and 4. When you need to specify a range of addresses, you choose the next-largest block size for your needs. So if you need to specify 34 networks, you need a block size of 64. If you want to specify 18 hosts, you need a block size of 32. If you specify only 2 networks, then go with a block size of 4.

Wildcards are used with the host or network address to tell the router a range of available addresses to filter. To specify a host, the address would look like this:

172.16.30.5 0.0.0.0

The four zeros represent each octet of the address. Whenever a zero is present, it indicates that the octet in the address must match the corresponding reference octet exactly. To specify that an octet can be any value, use the value 255. Here's an example of how a /24 subnet is specified with a wildcard mask:

172.16.30.0 0.0.0.255

This tells the router to match up the first three octets exactly, but the fourth octet can be any value.

Okay—that was the easy part. But what if you want to specify only a small range of subnets? This is where block sizes come in. You have to specify the range of values in a block size, so you can't choose to specify 20 networks. You can only specify the exact amount that the block size value allows. This means that the range would have to be either 16 or 32, but not 20.

Let's say that you want to block access to the part of the network that ranges from 172.16.8.0 through 172.16.15.0. To do that, you would go with a block size of 8, your network number would be 172.16.8.0, and the wildcard would be 0.0.7.255. The 7.255 equals the value the router will use to determine the block size. So together, the network number and the wildcard tell the router to begin at 172.16.8.0 and go up a block size of eight addresses to network 172.16.15.0.

This really is easier than it looks! I could certainly go through the binary math for you, but no one needs that kind of pain because all you have to do is remember that the wildcard is always one number less than the block size. So, in our example, the wildcard would be 7 since our block size is 8. If you used a block size of 16, the wildcard would be 15. Easy, right?

Just to make you've got this, we'll go through some examples that will definitely help you nail it down. The following example tells the router to match the first three octets exactly but that the fourth octet can be anything:

Corp(config)#access-list 10 deny 172.16.10.0 0.0.0.255

The next example tells the router to match the first two octets and that the last two octets can be any value:

Corp(config)#access-list 10 deny 172.16.0.0 0.0.255.255

Now, try to figure out this next line:

Corp(config)#access-list 10 deny 172.16.16.0 0.0.3.255

This configuration tells the router to start at network 172.16.16.0 and use a block size of 4. The range would then be 172.16.16.0 through 172.16.19.255, and by the way, the Cisco objectives seem to really like this one!

Let's keep practicing. What about this next one?

Corp(config)#access-list 10 deny 172.16.16.0 0.0.7.255

This example reveals an access list starting at 172.16.16.0 going up a block size of 8 to 172.16.23.255.

Let's keep at it... What do you think the range of this one is?

Corp(config)#access-list 10 deny 172.16.32.0 0.0.15.255

This one begins at network 172.16.32.0 and goes up a block size of 16 to 172.16.47.255.

You're almost done practicing! After a couple more, we'll configure some real ACLs.

Corp(config)#access-list 10 deny 172.16.64.0 0.0.63.255

This example starts at network 172.16.64.0 and goes up a block size of 64 to 172.16.127.255.

What about this last example?

Corp(config)#access-list 10 deny 192.168.160.0 0.0.31.255

This one shows us that it begins at network 192.168.160.0 and goes up a block size of 32 to 192.168.191.255.

Here are two more things to keep in mind when working with block sizes and wildcards:

Each block size must start at 0 or a multiple of the block size. For example, you can't say that you want a block size of 8 and then start at 12. You must use 0–7, 8–15, 16–23, etc. For a block size of 32, the ranges are 0–31, 32–63, 64–95, etc.

The command any is the same thing as writing out the wildcard 0.0.0.0 255.255.255.255.

Standard Access List Example

In this section, you'll learn how to use a standard access list to stop specific users from gaining access to the finance department LAN.

In Figure 6.4, a router has three LAN connections and one WAN connection to the Internet. Users on the Sales LAN should not have access to the Finance LAN, but they should be able to access the Internet and the marketing department files. The Marketing LAN needs to access the Finance LAN for application services.

We can see that the following standard IP access list is configured on the router:

Lab_A#config t

Lab_A(config)#access-list 10 deny 172.16.40.0 0.0.0.255

Lab_A(config)#access-list 10 permit any

It's very important to remember that the any command is the same thing as saying the following using wildcard masking:

Lab_A(config)#access-list 10 permit 0.0.0.0 255.255.255.255

Since the wildcard mask says that none of the octets are to be evaluated, every address matches the test condition, so this is functionally doing the same as using the any keyword.

At this point, the access list is configured to deny source addresses from the Sales LAN to the Finance LAN and to allow everyone else. But remember, no action will be taken until the access list is applied on an interface in a specific direction!

But where should this access list be placed? If you place it as an incoming access list on Fa0/0, you might as well shut down the FastEthernet interface because all of the Sales LAN devices will be denied access to all networks attached to the router. The best place to apply this access list is on the Fa0/1 interface as an outbound list:

Lab_A(config)#int fa0/1

Lab_A(config-if)#ip access-group 10 out

Doing this completely stops traffic from 172.16.40.0 from getting out FastEthernet0/1. It has no effect on the hosts from the Sales LAN accessing the Marketing LAN and the Internet because traffic to those destinations doesn't go through interface Fa0/1. Any packet trying to exit out Fa0/1 will have to go through the access list first. If there was an inbound list placed on Fa0/0, then any packet trying to enter interface Fa0/0 would have to go through the access list before being routed to an exit interface.

Now, let's take a look at another standard access list example. Figure 6.5 shows an internetwork of two routers with four LANs.

Now we're going to stop the Accounting users from accessing the Human Resources server attached to the Lab_B router but allow all other users access to that LAN using a standard ACL. What kind of standard access list would we need to create and where would we place it to achieve our goals?

The real answer is that we should use an extended access list and place it closest to the source! But this question specifies using a standard access list, and as a rule, standard ACLs are placed closest to the destination. In this example, Ethernet 0 is the outbound interface on the Lab_B router and here's the access list that should be placed on it:

Lab_B#config t

Lab_B(config)#access-list 10 deny 192.168.10.128 0.0.0.31

Lab_B(config)#access-list 10 permit any

Lab_B(config)#interface Ethernet 0

Lab_B(config-if)#ip access-group 10 out

Keep in mind that to be able to answer this question correctly, you really need to understand subnetting, wildcard masks, and how to configure and implement ACLs. The Accounting subnet is the 192.168.10.128/27, which is a 255.255.255.224, with a block size of 32 in the fourth octet.

With all this in mind and before we move on to restricting Telnet access on a router, let's take a look at one more standard access list example. This one is going to require some thought. In Figure 6.6, you have a router with four LAN connections and one WAN connection to the Internet.

Okay—you need to write an access list that will stop access from each of the four LANs shown in the diagram to the Internet. Each of the LANs reveals a single host's IP address, which you need to use to determine the subnet and wildcards of each LAN to configure the access list.

Here is an example of what your answer should look like, beginning with the network on E0 and working through to E3:

Router(config)#access-list 1 deny 172.16.128.0 0.0.31.255

Router(config)#access-list 1 deny 172.16.48.0 0.0.15.255

Router(config)#access-list 1 deny 172.16.192.0 0.0.63.255

Router(config)#access-list 1 deny 172.16.88.0 0.0.7.255

Router(config)#access-list 1 permit any

Router(config)#interface serial 0

Router(config-if)#ip access-group 1 out

Sure, you could have done this with one line:

Router(config)#access-list 1 deny 172.16.0.0 0.0.255.255

But what fun is that?

And remember the reasons for creating this list. If you actually applied this ACL on the router, you'd effectively shut down access to the Internet, so why even have an Internet connection? I included this exercise so you can practice how to use block sizes with access lists, which is vital for succeeding when you take the Cisco exam!

Extended

Let's go back to the standard IP access list example where you had to block all access from the Sales LAN to the finance department and add a new requirement. You now must allow Sales to gain access to a certain server on the Finance LAN but not to other network services for security reasons. What's the solution? Applying a standard IP access list won't allow users to get to one network service but not another because a standard ACL won't allow you to make decisions based on both source and destination addresses. It makes decisions based only on source address, so we need another way to achieve our new goal—but what is it?

Using an extended access list will save the day because extended ACLs allow us to specify source and destination addresses as well as the protocol and port number that identify the upper-layer protocol or application. An extended ACL is just what we need to effectively allow users access to a physical LAN while denying them access to specific hosts—even specific services on those hosts!

We're going to take a look at the commands we have in our arsenal, but first, you need to know that you must use the extended access-list range from 100 to 199. The 2000–2699 range is also available for extended IP access lists.

After choosing a number in the extended range, you need to decide what type of list entry to make. For this example, I'm going with a deny list entry:

Corp(config)#access-list 110 ?

  deny     Specify packets to reject

  dynamic  Specify a DYNAMIC list of PERMITs or DENYs

  permit   Specify packets to forward

  remark   Access list entry comment

And once you've settled on the type of ACL, you then need to select a protocol field entry:

Corp(config)#access-list 110 deny ?

  <0-255>  An IP protocol number

  ahp      Authentication Header Protocol

  eigrp    Cisco's EIGRP routing protocol

  esp      Encapsulation Security Payload

  gre      Cisco's GRE tunneling

  icmp     Internet Control Message Protocol

  igmp     Internet Gateway Message Protocol

  ip       Any Internet Protocol

  ipinip   IP in IP tunneling

  nos      KA9Q NOS compatible IP over IP tunneling

  ospf     OSPF routing protocol

  pcp      Payload Compression Protocol

  pim      Protocol Independent Multicast

  tcp      Transmission Control Protocol

  udp      User Datagram Protocol

So now, let's filter an Application layer protocol that uses TCP by selecting TCP as the protocol and indicating the specific destination TCP port at the end of the line. Next, we'll be prompted for the source IP address of the host or network and we'll choose the any command to allow any source address:

Corp(config)#access-list 110 deny tcp ?

  A.B.C.D  Source address

  any      Any source host

  host     A single source host

After we've selected the source address, we can then choose the specific destination address:

Corp(config)#access-list 110 deny tcp any ?

  A.B.C.D  Destination address

  any      Any destination host

  eq       Match only packets on a given port number

  gt       Match only packets with a greater port number

  host     A single destination host

  lt       Match only packets with a lower port number

  neq      Match only packets not on a given port number

  range    Match only packets in the range of port numbers

In this output, you can see that any source IP address that has a destination IP address of 172.16.30.2 has been denied:

Corp(config)#access-list 110 deny tcp any host 172.16.30.2 ?

  ack          Match on the ACK bit

  dscp         Match packets with given dscp value

  eq           Match only packets on a given port number

  established  Match established connections

  fin          Match on the FIN bit

  fragments    Check non-initial fragments

  gt           Match only packets with a greater port number

  log          Log matches against this entry

  log-input    Log matches against this entry, including input interface

  lt           Match only packets with a lower port number

  neq          Match only packets not on a given port number

  precedence   Match packets with given precedence value

  psh          Match on the PSH bit

  range        Match only packets in the range of port numbers

  rst          Match on the RST bit

  syn          Match on the SYN bit

  time-range   Specify a time-range

  tos          Match packets with given TOS value

  urg          Match on the URG bit

  <cr>

And once we have the destination host addresses in place, we just need to specify the type of service to deny using the equal to command, entered as eq. The following help screen reveals the options available now. You can choose a port number or use the application name:

Corp(config)#access-list 110 deny tcp any host 172.16.30.2 eq ?

  <0-65535>    Port number

  bgp          Border Gateway Protocol (179)

  chargen      Character generator (19)

  cmd          Remote commands (rcmd, 514)

  daytime      Daytime (13)

  discard      Discard (9)

  domain       Domain Name Service (53)

  drip         Dynamic Routing Information Protocol (3949)

  echo         Echo (7)

  exec         Exec (rsh, 512)

  finger       Finger (79)

  ftp          File Transfer Protocol (21)

  ftp-data     FTP data connections (20)

  gopher       Gopher (70)

  hostname     NIC hostname server (101)

  ident        Ident Protocol (113)

  irc          Internet Relay Chat (194)

  klogin       Kerberos login (543)

  kshell       Kerberos shell (544)

  login        Login (rlogin, 513)

  lpd          Printer service (515)

  nntp         Network News Transport Protocol (119)

  pim-auto-rp  PIM Auto-RP (496)

  pop2         Post Office Protocol v2 (109)

  pop3         Post Office Protocol v3 (110)

  smtp         Simple Mail Transport Protocol (25)

  sunrpc       Sun Remote Procedure Call (111)

  syslog       Syslog (514)

  tacacs       TAC Access Control System (49)

  talk         Talk (517)

  telnet       Telnet (23)

  time         Time (37)

  uucp         Unix-to-Unix Copy Program (540)

  whois        Nicname (43)

  www          World Wide Web (HTTP, 80)

Now let's block Telnet (port 23) to host 172.16.30.2 only. If the users want to use FTP, fine—that's allowed. The log command is used to log messages every time the access list entry is hit. This can be an extremely cool way to monitor inappropriate access attempts, but be careful because in a large network, this command can overload your console's screen with messages!

Here's our result:

Corp(config)#access-list 110 deny tcp any host 172.16.30.2 eq 23 log

This line says to deny any source host trying to telnet to destination host 172.16.30.2. Keep in mind that the next line is an implicit deny by default. If you apply this access list to an interface, you might as well just shut the interface down because by default, there's an implicit deny all at the end of every access list. So we've got to follow up the access list with the following command:

Corp(config)#access-list 110 permit ip any any

The IP in this line is important because it will permit the IP stack. If TCP was used instead of IP in this line, then UDP, etc. would all be denied. Remember, that 0.0.0.0 255.255.255.255 is the same command as any, so the command could also look like this:

Corp(config)#access-list 110 permit ip 0.0.0.0 255.255.255.255

0.0.0.0 255.255.255.255

But if you did this, when you looked at the running-config, the commands would be replaced with the any any. I like efficiency so I'll just use the any command because it requires less typing.

As always, once our access list is created, we must apply it to an interface with the same command used for the IP standard list:

Corp(config-if)#ip access-group 110 in

Or this:

Corp(config-if)#ip access-group 110 out

Next, we'll check out some examples of how to use an extended access list.

Extended Access List Example 1

For our first scenario, we'll use Figure 6.7. What do we need to do to deny access to a host at 172.16.50.5 on the finance department LAN for both Telnet and FTP services? All other services on this and all other hosts are acceptable for the sales and marketing departments to access.

Here's the ACL we must create:

Lab_A#config t

Lab_A(config)#access-list 110 deny tcp any host 172.16.50.5 eq 21

Lab_A(config)#access-list 110 deny tcp any host 172.16.50.5 eq 23

Lab_A(config)#access-list 110 permit ip any any

The access-list 110 tells the router we're creating an extended IP ACL. The tcp is the protocol field in the Network layer header. If the list doesn't say tcp here, you cannot filter by TCP port numbers 21 and 23 as shown in the example. Remember that these values indicate FTP and Telnet, which both use TCP for connection-oriented services. The any command is the source, which means any source IP address, and the host is the destination IP address. This ACL says that all IP traffic will be permitted from any host except FTP and Telnet to host 172.16.50.5 from any source.

After the list is created, it must be applied to the FastEthernet 0/1 interface outbound because we want to block all traffic from getting to host 172.16.50.5 and performing FTP and Telnet. If this list was created to block access only from the Sales LAN to host 172.16.50.5, then we'd have put this list closer to the source, or on FastEthernet 0/0. In that situation, we'd apply the list to inbound traffic. This highlights the fact that you really need to analyze each situation carefully before creating and applying ACLs!

Now let's go ahead and apply the list to interface Fa0/1 to block all outside FTP and Telnet access to the host 172.16.50.5:

Lab_A(config)#int fa0/1

Lab_A(config-if)#ip access-group 110 out

Extended Access List Example 2

We're going to use Figure 6.6 again, which has four LANs and a serial connection. We need to prevent Telnet access to the networks attached to the E1 and E2 interfaces.

The configuration on the router would look something like this, although the answer can vary:

Router(config)#access-list 110 deny tcp any 172.16.48.0 0.0.15.255

eq 23

Router(config)#access-list 110 deny tcp any 172.16.192.0 0.0.63.255

eq 23

Router(config)#access-list 110 permit ip any any

Router(config)#interface Ethernet 1

Router(config-if)#ip access-group 110 out

Router(config-if)#interface Ethernet 2

Router(config-if)#ip access-group 110 out

Here are the key factors to understand from this list:

• First, you need to verify that the number range is correct for the type of access list you are creating. In this example, it's extended, so the range must be 100–199.
• Second, you must verify that the protocol field matches the upper-layer process or application, which in this case is TCP port 23 (Telnet).

• Third, verify that the destination port number matches the application you're filtering for. In this case, port 23 matches Telnet, which is correct, but know that you can also type telnet at the end of the line instead of 23.
• Finally, the test statement permit ip any any is important to have there at the end of the list because it means to enable all packets other than Telnet packets destined for the LANs connected to Ethernet 1 and Ethernet 2.

Extended Access List Example 3

I want to guide you through one more extended ACL example before we move on to named ACLs. Figure 6.8 displays the network we're going to use for this last scenario.

In this example, we're going to allow HTTP access to the Finance server from source Host B only. All other traffic will also be permitted. We need to be able to configure this in only three test statements, and then we'll need to add the interface configuration.

Let's take what we've learned and knock this one out:

Lab_A#config t

Lab_A(config)#access-list 110 permit tcp host 192.168.177.2

host 172.22.89.26 eq 80

Lab_A(config)#access-list 110 deny tcp any host 172.22.89.26 eq 80

Lab_A(config)#access-list 110 permit ip any any

This is really pretty simple! First we need to permit Host B HTTP access to the Finance server. But since all other traffic must be allowed, we must detail who cannot HTTP to the Finance server, so the second test statement is there to deny anyone else from using HTTP on the Finance server. Finally, now that Host B can HTTP to the Finance server and everyone else can't, we'll permit all other traffic with our third test statement.

Not so bad—this just takes a little thought! But wait—we're not done yet because we still need to apply this to an interface. Since extended access lists are typically applied closest to the source, we should simply place this inbound on F0/0, right? Well, this is one time we're not going to follow the rules. Our challenge required us to allow only HTTP traffic to the Finance server from Host B. If we apply the ACL inbound on Fa0/0, then the branch office would be able to access the Finance server and perform HTTP. So in this example, we need to place the ACL closest to the destination:

Lab_A(config)#interface fastethernet 0/1

Lab_A(config-if)#ip access-group 110 out

Named

Named access lists are just another way to create standard and extended access lists. In medium to large enterprises, managing ACLs can become a real hassle over time! A handy way to make things easier is to copy the access list to a text editor, edit the list, then paste the new list back into the router, which works pretty well if it weren't for the “pack rat” mentality. It's really common to think things like, “What if I find a problem with the new list and need to back out of the change?” This and other factors cause people to hoard unapplied ACLs, and over time, they can seriously build up on a router, leading to more questions, like, “What were these ACLs for? Are they important? Do I need them?” All good questions, and named access lists are the answer to this problem!

And of course, this kind of thing can also apply to access lists that are up and running. Let's say you come into an existing network and are looking at access lists on a router. Suppose you find an access list 177, which happens to be an extended access list that's a whopping 93 lines long. This leads to more of the same bunch of questions and can even lead to needless existential despair! Instead, wouldn't it be a whole lot easier to identify an access list with a name like “FinanceLAN” rather than one mysteriously dubbed “177”?

To our collective relief, named access lists allow us to use names for creating and applying either standard or extended access lists. There's really nothing new or different about these ACLs aside from being readily identifiable in a way that makes sense to humans, but there are some subtle changes to the syntax. So let's re-create the standard access list we created earlier for our test network in Figure 6.8 using a named access list:

Lab_A#config t

Lab_A(config)# ip access-list ?

  extended    Extended Access List

  log-update  Control access list log updates

  logging     Control access list logging

  resequence  Resequence Access List

  standard    Standard Access List

Notice that I started by typing ip access-list, not access-list. Doing this allows me to enter a named access list. Next, I'll need to specify it as a standard access list:

Lab_A(config)#ip access-list standard ?

  <1-99>       Standard IP access-list number

  <1300-1999>  Standard IP access-list number (expanded range)

  WORD         Access-list name

 

Lab_A(config)#ip access-list standard BlockSales

Lab_A(config-std-nacl)#

I've specified a standard access list, then added the name, BlockSales. I definitely could've used a number for a standard access list, but instead, I chose to use a nice, clear, descriptive name. And notice that after entering the name, I hit Enter and the router prompt changed. This confirms that I'm now in named access list configuration mode and that I'm entering the named access list:

Lab_A(config-std-nacl)#?

Standard Access List configuration commands:

  default  Set a command to its defaults

  deny     Specify packets to reject

  exit     Exit from access-list configuration mode

  no       Negate a command or set its defaults

  permit   Specify packets to forward

 

Lab_A(config-std-nacl)#deny 172.16.40.0 0.0.0.255

Lab_A(config-std-nacl)#permit any

Lab_A(config-std-nacl)#exit

Lab_A(config)#^Z

Lab_A#

So I've entered the access list and then exited configuration mode. Next, I'll take a look at the running configuration to verify that the access list is indeed in the router:

Lab_A#sh running-config | begin ip access

ip access-list standard BlockSales

 deny   172.16.40.0 0.0.0.255

 permit any

!

And there it is: The BlockSales access list has truly been created and is in the running-config of the router. Next, I'll need to apply the access list to the correct interface:

Lab_A#config t

Lab_A(config)#int fa0/1

Lab_A(config-if)#ip access-group BlockSales out

Clear skies! At this point, we've re-created the work done earlier using a named access list. But let's take our IP extended example, shown in Figure 6.8, and redo that list using a named ACL instead as well.

Same business requirements: Allow HTTP access to the Finance server from source Host B only. All other traffic is permitted.

Lab_A#config t

Lab_A(config)#ip access-list extended 110

Lab_A(config-ext-nacl)#permit tcp host 192.168.177.2 host 172.22.89.26 eq 80

Lab_A(config-ext-nacl)#deny tcp any host 172.22.89.26 eq 80

Lab_A(config-ext-nacl)#permit ip any any

Lab_A(config-ext-nacl)#int fa0/1

Lab_A(config-if)#ip access-group 110 out

Okay—true—I named the extended list with a number, but sometimes it's okay to do that! I'm guessing that named ACLs don't seem all that exciting or different to you, do they? Maybe not in this configuration, except that I don't need to start every line with access-list 110, which is nice. But where named ACLs really shine is that they allow us to insert, delete, or edit a single line.

Monitoring Access Lists

It's always good to be able to verify a router's configuration. Table 6.1 lists the commands that we can use to achieve that.

Table 6.1 Commands used to verify access-list configuration

We've already used the show running-config command to verify that a named access list was in the router, so now let's take a look at the output from some of the other commands.

The show access-list command will list all ACLs on the router, whether they're applied to an interface or not:

Lab_A#show access-list

Standard IP access list 10

    10 deny   172.16.40.0, wildcard bits 0.0.0.255

    20 permit any

Standard IP access list BlockSales

    10 deny   172.16.40.0, wildcard bits 0.0.0.255

    20 permit any

Extended IP access list 110

    10 deny tcp any host 172.16.30.5 eq ftp

    20 deny tcp any host 172.16.30.5 eq telnet

    30 permit ip any any

    40 permit tcp host 192.168.177.2 host 172.22.89.26 eq www

    50 deny tcp any host 172.22.89.26 eq www

Lab_A#

First, notice that access list 10 as well as both of our named access lists appear on this list—remember, my extended named ACL was named 110! Second, notice that even though I entered actual numbers for TCP ports in access list 110, the show command gives us the protocol names rather than TCP ports for serious clarity.

But wait! The best part is those numbers on the left side: 10, 20, 30, etc. Those are called sequence numbers, and they allow us to edit our named ACL. Here's an example where I added a line into the named extended ACL 110:

Lab_A (config)#ip access-list extended 110

Lab_A (config-ext-nacl)#21 deny udp any host 172.16.30.5 eq 69

Lab_A#show access-list

[output cut]

Extended IP access list 110

    10 deny tcp any host 172.16.30.5 eq ftp

    20 deny tcp any host 172.16.30.5 eq telnet

    21 deny udp any host 172.16.30.5 eq tftp

    30 permit ip any any

    40 permit tcp host 192.168.177.2 host 172.22.89.26 eq www

    50 deny tcp any host 172.22.89.26 eq www

You can see that I added line 21. I could have deleted a line or edited an existing line as well—very nice!

Here's the output of the show ip interface command:

Lab_A#show ip interface fa0/1

FastEthernet0/1 is up, line protocol is up

  Internet address is 172.16.30.1/24

  Broadcast address is 255.255.255.255

  Address determined by non-volatile memory

  MTU is 1500 bytes

  Helper address is not set

  Directed broadcast forwarding is disabled

  Outgoing access list is 110

  Inbound access list is not set

  Proxy ARP is enabled

  Security level is default

  Split horizon is enabled

[output cut]

Be sure to notice the bold line indicating that the outgoing list on this interface is 110, yet the inbound access list isn't set. What happened to BlockSales? I had configured that outbound on Fa0/1! That's true, I did, but I configured my extended named ACL 110 and applied it to Fa0/1 as well. You can't have two lists on the same interface, in the same direction, so what happened here is that my last configuration overwrote the BlockSales configuration.

And as I've already mentioned, you can use the show running-config command to see any and all access lists.

IPv6 Extended Access Lists

First, understand that you can only create named extended IPv6 ACLs, so you don't need to specify standard or extended in your named list, and although you won't see any sequence numbers, you can still somewhat edit a named IPv6 ACL, meaning you can delete a single line but there is no way to insert a line other than at the end of the ACL.

In addition, there's an implicit deny ip any any at the bottom of every IPv4 access list. However, IPv6 access lists actually have three implied statements at the bottom:

• permit icmp any any nd-na
• permit icmp any any nd-ns
• deny ipv6 any any

The two permit statements are required for neighbor discovery, which is an important protocol in IPv6 because it's the replacement for ARP.

Using Figure 6.9 network layout and IPv6 addresses, let's create an IPv6 extended named ACL that blocks Telnet to Server1 with an IPv6 address of 2001:db8:3c4d:1:a14c: 8c33:2d1:be3d from PC1 with a destination IPv6 address of 2001:db8:3c4d:3:2ef:1823:8938. Since it's an IPv6 extended named ACL (always), we'll place it closest to the source address if possible.

Step 1: Test that you can telnet to the remote host:

R1#telnet 2001:db8:3c4d:1:a14c:8c33:2d1:be3d

Trying 2001:db8:3c4d:1:a14c:8c33:2d1:be3d... Open

 

Server1>

Okay, great, but that was way too much effort! Let's create an entry into the hosts table of R1 so I don't have to type an IPv6 address when trying to access that host:

R1(config)#ipv6 host Server1 2001:db8:3c4d:1:a14c:8c33:2d1:be3d

R1(config)#do sh host

[output cut]

 

Host Port Flags Age Type Address(es)

Server1 None (perm, OK) 0 IPV6 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D

Now I can just type this from now on (the name is case sensitive):

R1#telnet Server1

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D... Open

 

Server1>

Or better yet, just the name (telnet is the default):

R1#Server1

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D... Open

 

Server1>exit

Also, ping using the name:

R1#ping Server1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D,

timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/1 ms

Step 2: Create an ACL on R2 that stops telnet to the remote host Server1 (2001:db8:3c4d:1:a14c:8c33:2d1:be3d). The name is absolutely case sensitive when applying to an interface:

R2(config)#ipv6 access-list Block_Telnet

R2(config-ipv6-acl)#

Step 3: Once you have created the named list, add your test parameters:

R2(config-ipv6-acl)#deny tcp host 2001:DB8:3C4D:2:21A:6DFF:FE37:A44F

host 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D eq telnet

R2(config-ipv6-acl)#permit ipv6 any any

Step 4: Configure your ACP on your router interface.

Since we're adding this to the R2 router in Figure 6.9, add it to interface FastEthernet 0/1, stopping traffic closest to the source, and use the command ipv6 traffic-filter:

R2(config)#int fa0/1

R2(config-if)#ipv6 traffic-filter Block_Telnet out

Step 5: Test your access list by telnetting from Server1 on the R1 router:

R1#Server1

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D ...Open

 

 

Server1>

Hmm… and I tried really hard not to make a typo! Let's take a look:

R2#sh access-lists

IPv6 access list Block_Telnet

      deny tcp host 2001:DB8:3C4D:2:21A:6DFF:FE37:A44F host

2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D eq telnet (96 match(es))

     permit ipv6 any any (181 match(es))

By verifying the IPv6 addresses with the interfaces of the routers, this list looks correct. It's important to verify your addresses with a show ipv6 interface brief command. Let's take a look:

R1#sh ipv6 int brief

FastEthernet0/0 [up/up]

      FE80::2E0:B0FF:FED2:B701

      2001:DB8:3C4D:3:21A:6DFF:FE37:A44E

FastEthernet0/1 [up/up]

      FE80::2E0:B0FF:FED2:B702

      2001:DB8:3C4D:2:21A:6DFF:FE37:A44F

Since R1 Fa0/1 is my source address, we can see that this address is correct in my ACL. Let's take a look at the destination device:

Server1#sh ipv6 int br

      FastEthernet0/0 [up/up]

      FE80::260:70FF:FED8:DD01

      2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D

Yup, this one is correct too! My IPv6 ACL is correct, so now we need to check our interface.

Step 6: Fix and/or edit your access list and/or interfaces:

R2#show running-config

[output cut]

!

interface FastEthernet0/0

      no ip address

      duplex auto

      speed auto

      ipv6 address 2001:DB8:3C4D:1:21A:6DFF:FE37:A443/64

      ipv6 rip 1 enable

!

interface FastEthernet0/1

      no ip address

      ipv6 traffic-filter Block_Telnet out

      duplex auto

      speed auto

      ipv6 address 2001:DB8:3C4D:2:21A:6DFF:FE64:9B3/64

      ipv6 rip 1 enable

!

Unlike with IPv4, where we can use the show ip interface command to see if an ACL is set, we can only use the show running-config command to verify if an IPv6 ACL is set on an interface. In the preceding output, we can see that I certainly did set the ACL to the interface Fa0/1. However, I configured it to out instead of in on the interface. Let's fix that:

R2#config t

R2(config)#int fa0/1

R2(config-if)#no ipv6 traffic-filter Block_Telnet out

R2(config-if)#ipv6 traffic-filter Block_Telnet in

Step 7: Retest your ACL:

R1#Server1

 

Trying 2001:DB8:3C4D:1:A14C:8C33:2D1:BE3D ...%

Connection timed out; remote host not responding

R1#

Looks good! Although I don't recommend using this method to block telnet to a router, it was a great way to test our IPv6 ACLs.

Exam Essentials

Remember the standard and extended IP access-list number ranges. The number ranges you can use to configure a standard IP access list are 1–99 and 1300–1999. The number ranges for an extended IP access list are 100–199 and 2000–2699.

Understand the term implicit deny. At the end of every access list is an implicit deny. What this means is that if a packet does not match any of the lines in the access list, it will be discarded. Also, if you have nothing but deny statements in your list, the list will not permit any packets.

Understand the standard IP access-list configuration command. To configure a standard IP access list, use the access-list numbers 1–99 or 1300–1999 in global configuration mode. Choose permit or deny, then choose the source IP address you want to filter on using one of the three techniques covered in this discussion of access lists.

Understand the extended IP access-list configuration command. To configure an extended IP access list, use the access-list numbers 100–199 or 2000–2699 in global configuration mode. Choose permit or deny, the Network layer protocol field, the source IP address you want to filter on, the destination address you want to filter on, and finally, the Transport layer port number if TCP or UDP has been specified as the protocol.

Remember the command to verify an access list on a router interface. To see whether an access list is set on an interface and in which direction it is filtering, use the show ip interface command. This command will not show you the contents of the access list, merely which access lists are applied on the interface.

Remember the command to verify the access-list configuration. To see the configured access lists on your router, use the show access-list command. This command will not show you which interfaces have an access list set.

Verify ACLs using the APIC-EM Path Trace ACL Analysis tool

Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) is a Cisco SDN controller, which uses open APIs for policy-based management and security through a single controller, abstracting the network and making network services simpler. APIC-EM provides centralized automation of policy-based application profiles, and the APIC-EM northbound interface is the only API that you'll need to control your network programmatically. Through this programmability, automated network control helps IT to respond quickly to new business opportunities. The APIC-EM also includes support for greenfield (new installations) and brownfield (current or old installations) deployments, which allows you to implement programmability and automation with the infrastructure that you already have.

APIC-EM is pretty cool, easy to use (although that's up for debate), and automates the tasks that network engineers have been doing for well over 20 years. At first glance this seems like it will replace our current jobs, and in some circumstances, people resistant to change will certainly be replaced. But you don't have to be one of them if you start planning now. Figure 6.10 demonstrates exactly where the APCI-EM controller sits in the SDN stack.

Cisco APIC-EM's northbound interface is only an API, but southbound interfaces are implemented with something called a service abstraction layer (SAL), which talks to the network elements via SNMP and CLI. Using the SNMP and the CLI allows APIC-EM to work with legacy Cisco products, and soon APIC-EM will be able to use NETCONF too. The network devices can be either physical or virtual, including Nexus data center switches, ASA firewalls, ASR routers, or even third-party load balancers. The managed devices must be specific to ACI; in other words, a special NX-OS or ASR IOS version is required to add the southbound APIs required to communicate with the APIC controller.

The APIC-EM API is REST based, which as you know allows you to discover and control your network using HTTP by using the GET, POST, PUT, and DELETE options along with JSON (JavaScript Object Notation) and XML (eXtensible Markup Language) syntax.

In Figure 6.11 are some important features of Cisco APIC-EM that are covered in the CCNA objectives.

On the left of the screen you can see the Discovery button. This provides the network information database, which scans the network and ­provides the inventory, including all network devices; the network devices are also shown on the Device Inventory page.

There's also a network topology visualization, which reveals the physical topology discovered, as shown in the layout on Figure 6.11. This auto-discovers and maps network devices to a physical topology with detailed device-level data, including the discovered hosts. And take note of that IWAN button. It provides the provisioning of IWAN network profiles with simple business policies. Plus there is a Path Trace button, which I will talk about next.

But wait... Before I move on to the path trace functionality of APIC-EM, let me go over a few more promising features with you. In the APIC-EM is the Zero-Touch Deployment feature, which finds a new device via the controller scanner and automatically configures it. You can track user identities and endpoints by exchanging the information with the Cisco Identity Service Engine (Cisco ISE) via the Identity Manager. You can also quickly set and enforce QoS priority policies with the QoS deployment and change management feature and accelerate ACL management by querying and analyzing ACLs on each network device. This means you can quickly identify ACL misconfiguration using the ACL analysis! And last but not least, using the Policy Manager, the controller translates a business policy into a network-device-level policy. The Policy Manager can enforce the policy for a specific user at various times of the day, across wired and wireless networks.

Now let's take a look at the very vital path tracing feature of APIC-EM.

Using APIC-EM for Path Tracing

An important objective in this intelligent networks section is the path tracing ability in the APIC-EM. Matter of fact, I've mostly been using the APIC-EM for just this feature in order to help me troubleshoot my virtual networks, and it does it very well. And it looks cool too!

Pushing toward staying tight to the CCNA objectives here, you really want to know that you can use the path trace service of APIC-EM for ACL analysis. Doing this allows you to examine the path that a specific type of packet travels as it makes its way across the network from a source to a destination node, and it can use IP and TCP/UDP ports when diagnosing an application issue. If there is an ACL on an interface that blocks a certain application, you'll see this in a GUI output. I cannot tell you how extremely helpful this is in the day-to-day administration of your networks!

The result of a path trace will be a GUI representation of the path that a packet takes across all the devices and links between the source and destination, and you can choose to provide the output of a reverse path as well. Although I could easily do this same work manually, it would certainly be a whole lot more time consuming if I did! APIC-EM's Path Trace app actually does the work for you with just a few clicks at the user interface.

Once you fill in the fields for the source, destination, and optionally, the application, the path trace is initiated. You'll then see the path between hosts, plus the list of each device along the path, illustrated in Figure 6.12.

Okay, here you can see the complete path taken from host A to host B. I chose to view the reverse path as well. In this particular case, we weren't being blocked by an ACL, but if a packet actually was being blocked for a certain application, we'd see the exact interface where the application was blocked and why. Here is more detail on how my trace occurred.

First, the APIC-EM Discovery finds the network topology. At this point I can now choose the source and destination address of a packet and, alternately, port numbers and the application that can be used. The MAC address table, IP routing tables, and so on are used by the APIC-EM to find the path of the packet through the network. Finally, the GUI will show you the path, complete with device and interface information.

Last point: The APIC-EM is free, and most of the applications off the NBI are built in and included, but there are some solution applications that need a license. So if you have a VM with at least 64 gigs of RAM, you're set!

Exam Essentials

Understand APIC-EM and the path trace. Read through Verify ACLs using the APIC-EM Path Trace ACL Analysis tool section, which cover the CCNA objectives fully.

Configure, verify, and troubleshoot basic device hardening

Hardening a device is the process of ensuring the device is secured from attack. There are a number of steps that should be taken as standard operating procedure to lock down infrastructure devices. In the following sections, we'll discuss the most important of these.

Local Authentication

There are five passwords you'll need to secure your Cisco routers: console, auxiliary, telnet (VTY), enable password, and enable secret. The enable secret and enable password are the ones used to set the password for securing privileged mode. Once the enable commands are set, users will be prompted for a password. The other three are used to configure a password when user mode is accessed through the console port, through the auxiliary port, or via Telnet.

Let's take a look at each of these now.

Enable Passwords

You set the enable passwords from global configuration mode like this:

Todd(config)#enable ?

 last-resort Define enable action if no TACACS servers

             respond

 password    Assign the privileged level password

 secret      Assign the privileged level secret

 use-tacacs  Use TACACS to check enable passwords

The following list describes the enable password parameters:

last-resort This allows you to still enter the device if you set up authentication through a TACACS server and it's not available. It won't be used if the TACACS server is working.

password This sets the enable password on older, pre-10.3 systems and isn't ever used if an enable secret is set.

secret The newer, encrypted password that overrides the enable password if it has been set

use-tacacs This tells the router or switch to authenticate through a TACACS server. It comes in really handy when you have lots of routers because changing the password on a multitude of them can be insanely tedious. It's much easier to simply go through the TACACS server and change the password only once!

Here's an example that shows how to set the enable passwords:

Todd(config)#enable secret todd

Todd(config)#enable password todd

The enable password you have chosen is the same as your

  enable secret. This is not recommended. Re-enter the

  enable password.

If you try to set the enable secret and enable passwords the same, the device will give you a polite warning to change the second password. Make a note to yourself that if there aren't any old legacy routers involved, you don't even bother to use the enable password!

User-mode passwords are assigned via the line command like this:

Todd(config)#line ?

  <0-16>   First Line number

  console  Primary terminal line

  vty      Virtual terminal

And these two lines are especially important for the exam objectives:

console Sets a console user-mode password

vty Sets a Telnet password on the device. If this password isn't set, then by default, Telnet can't be used.

To configure user-mode passwords, choose the line you want and configure it using the login command to make the switch prompt for authentication. Let's focus in on the configuration of individual lines now.

Console Password

We set the console password with the line console 0 command, but look at what happened when I tried to type line console ? from the (config-line)# prompt—I received an error! Here's the example:

Todd(config-line)#line console ?

% Unrecognized command

Todd(config-line)#exit

Todd(config)#line console ?

  <0-0>  First Line number

Todd(config)#line console 0

Todd(config-line)#password console

Todd(config-line)#login

You can still type line console 0 and that will be accepted, but the help screens just don't work from that prompt. Type exit to go back one level, and you'll find that your help screens now work. This is a “feature.” Really.

Because there's only one console port, I can only choose line console 0. You can set all your line passwords to the same password, but doing this isn't exactly a brilliant security move!

And it's also important to remember to apply the login command or the console port won't prompt for authentication. The way Cisco has this process set up means you can't set the login command before a password is set on a line because if you set it but don't then set a password, that line won't be usable. You'll actually get prompted for a password that doesn't exist, so Cisco's method isn't just a hassle; it makes sense and is a feature after all!

Okay, there are a few other important commands you need to know regarding the console port.

For one, the exec-timeout 0 0 command sets the time-out for the console EXEC session to zero, ensuring that it never times out. The default time-out is 10 minutes.

Logging synchronous is such a cool command that it should be a default, but it's not. It's great because it's the antidote for those annoying console messages that disrupt the input you're trying to type. The messages will still pop up, but at least you get returned to your device prompt without your input being interrupted! This makes your input messages oh-so-much easier to read!

Here's an example of how to configure both commands:

Todd(config-line)#line con 0

Todd(config-line)#exec-timeout ?

  <0-35791>  Timeout in minutes

Todd(config-line)#exec-timeout 0 ?

  <0-2147483>  Timeout in seconds

  <cr>

Todd(config-line)#exec-timeout 0 0

Todd(config-line)#logging synchronous

Telnet Password

To set the user-mode password for Telnet access into the router or switch, use the line vty command. IOS switches typically have 16 lines, but routers running the Enterprise edition have considerably more. The best way to find out how many lines you have is to use that handy question mark like this:

Todd(config-line)#line vty 0 ?

% Unrecognized command

Todd(config-line)#exit

Todd(config)#line vty 0 ?

  <1-15>  Last Line number

  <cr>

Todd(config)#line vty 0 15

Todd(config-line)#password telnet

Todd(config-line)#login

This output clearly shows that you cannot get help from your (config-line)# prompt. You must go back to global config mode in order to use the question mark (?).

So what will happen if you try to telnet into a device that doesn't have a VTY password set? You'll receive an error saying the connection has been refused because the password isn't set. So, if you telnet into a switch and receive a message like this one that I got from Switch B:

Todd#telnet SwitchB

Trying SwitchB (10.0.0.1)...Open

 

Password required, but none set

[Connection to SwitchB closed by foreign host]

Todd#

it means the switch doesn't have the VTY password set. But you can still get around this and tell the switch to allow Telnet connections without a password by using the no login command:

SwitchB(config-line)#line vty 0 15

SwitchB(config-line)#no login

After your IOS devices are configured with an IP address, you can use the Telnet program to configure and check your routers instead of having to use a console cable. You can use the Telnet program by typing telnet from any command prompt (DOS or Cisco).

Auxiliary Password

To configure the auxiliary password on a router, go into global configuration mode and type line aux ?. And by the way, you won't find these ports on a switch. This output shows that you only get a choice of 0–0, which is because there's only one port:

Todd#config t

Todd(config)#line aux ?

  <0-0>  First Line number

Todd(config)#line aux 0

Todd(config-line)#login

% Login disabled on line 1, until 'password' is set

Todd(config-line)#password aux

Todd(config-line)#login

Secure Password

Because only the enable secret password is encrypted by default, you'll need to manually configure the user-mode and enable passwords for encryption.

Notice that you can see all the passwords except the enable secret when performing a show running-config on a switch:

Todd#sh running-config

Building configuration...

 

Current configuration : 1020 bytes

!

! Last configuration change at 00:03:11 UTC Mon Mar 1 1993

!

version 15.0

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Todd

!

enable secret 4 ykw.3/tgsOuy9.6qmgG/EeYOYgBvfX4v.S8UNA9Rddg

enable password todd

!

[output cut]

!

line con 0

 password console

 login

line vty 0 4

 password telnet

 login

line vty 5 15

 password telnet

 login

!

end

To manually encrypt your passwords, use the service password-encryption command. Here's how:

Todd#config t

Todd(config)#service password-encryption

Todd(config)#exit

Todd#show run

Building configuration...

!

!

enable secret 4 ykw.3/tgsOuy9.6qmgG/EeYOYgBvfX4v.S8UNA9Rddg

enable password 7 1506040800

!

[output cut]

!

!

line con 0

 password 7 050809013243420C

 login

line vty 0 4

 password 7 06120A2D424B1D

 login

line vty 5 15

 password 7 06120A2D424B1D

 login

!

end

Todd#config t

Todd(config)#no service password-encryption

Todd(config)#^Z

Todd#

Nicely done—the passwords will now be encrypted. All you need to do is encrypt the passwords, perform a show run, then turn off the command if you want. This output clearly shows us that the enable password and the line passwords are all encrypted.

I want to stress some points about password encryption. I said, if you set your passwords and then turn on the service password-encryption command, you have to perform a show running-config before you turn off the encryption service or your passwords won't be encrypted. You don't have to turn off the encryption service at all—you'd only do that if your switch is running low on processes. And if you turn on the service before you set your passwords, then you don't even have to view them to have them encrypted.

Access to Device

Access to a device can be controlled at any line (console, terminal, or aux) with the use of access lists applied to the line as shown in the section “Local Authentication.” In the following sections, we'll take a look at another method of securing access using SSH.

Source Address

Controlling access by IP address is done though the implementation of access lists as described in the section “Local Authentication.”

Telnet/SSH

I strongly recommend using Secure Shell (SSH) instead of Telnet because it creates a more secure session. The Telnet application uses an unencrypted data stream, but SSH uses encryption keys to send data so your username and password aren't sent in the clear, ­vulnerable to anyone lurking around!

Here are the steps for setting up SSH:

1. Set your hostname:

   Router(config)#hostname Todd

2. Set the domain name—both the hostname and domain name are required for the encryption keys to be generated:

   Todd(config)#ip domain-name Lammle.com

3. Set the username to allow SSH client access:

   Todd(config)#username Todd password Lammle

4. Generate the encryption keys for securing the session:

   Todd(config)#crypto key generate rsa

   The name for the keys will be: Todd.Lammle.com

   Choose the size of the key modulus in the range of 360 to

   4096 for your General Purpose Keys. Choosing a key modulus

   Greater than 512 may take a few minutes.

    

   How many bits in the modulus [512]: 1024

   % Generating 1024 bit RSA keys, keys will be non-exportable...

   [OK] (elapsed time was 6 seconds)

    

   Todd(config)#

   1d14h: %SSH-5-ENABLED: SSH 1.99 has been enabled*June 24

   19:25:30.035: %SSH-5-ENABLED: SSH 1.99 has been enabled

5. Enable SSH version 2 on the device—not mandatory, but strongly suggested:

   Todd(config)#ip ssh version 2

6. Connect to the VTY lines of the switch or router:

   Todd(config)#line vty 0 15

7. Configure your access protocols:

   Todd(config-line)#transport input ?

     all     All protocols

     none    No protocols

     ssh     TCP/IP SSH protocol

     telnet  TCP/IP Telnet protocol

   Beware of this next line, and make sure you never use it in production because it's a horrendous security risk:

   Todd(config-line)#transport input all

   I recommend using the next line to secure your VTY lines with SSH:

   Todd(config-line)#transport input ssh ?

     telnet  TCP/IP Telnet protocol

     <cr>

I actually do use Telnet once in a while when a situation arises that specifically calls for it. It just doesn't happen very often. But if you want to go with Telnet, here's how you do that:

Todd(config-line)#transport input ssh telnet

Know that if you don't use the keyword telnet at the end of the command string, then only SSH will work on the device. You can go with either, just so long as you understand that SSH is way more secure than Telnet.

Login Banner

A very good reason for having a banner is to give any and all who dare attempt to telnet or sneak into your internetwork a little security notice. And they're very cool because you can create and customize them so that they'll greet anyone who shows up on the router with exactly the information you want them to have!

Here are the three types of banners you need to be sure you're familiar with:

• Exec process creation banner
• Login banner
• Message of the day banner

And you can see them all illustrated in the following code:

Todd(config)#banner ?

  LINE            c banner-text c, where 'c' is a delimiting character

  exec            Set EXEC process creation banner

  incoming        Set incoming terminal line banner

  login           Set login banner

  motd            Set Message of the Day banner

  prompt-timeout  Set Message for login authentication timeout

  slip-ppp        Set Message for SLIP/PPP

Message of the day (MOTD) banners are the most widely used banners because they give a message to anyone connecting to the router via Telnet or an auxiliary port or even through a console port as seen here:

Todd(config)#banner motd ?

LINE c banner-text c, where 'c' is a delimiting character

Todd(config)#banner motd #

Enter TEXT message. End with the character '#'.

$ Acme.com network, then you must disconnect immediately.

#

Todd(config)#^Z (Press the control key + z keys to return to privileged mode)

Todd#exit

con0 is now available

Press RETURN to get started.

If you are not authorized to be in Acme.com network, then you

must disconnect immediately.

Todd#

This MOTD banner essentially tells anyone connecting to the device to get lost if they're not on the guest list. The part to focus upon here is the delimiting character, which is what informs the router the message is done. Clearly, you can use any character you want for it except for the delimiting character in the message itself. Once the message is complete, press Enter, then the delimiting character, and then press Enter again. Everything will still work if you don't follow this routine unless you have more than one banner. If that's the case, make sure you do follow it or your banners will all be combined into one message and put on a single line!

You can set a banner on one line like this:

Todd(config)#banner motd x Unauthorized access prohibited! x

Let's take a minute to go into more detail about the other two types of banners I mentioned:

Exec banner You can configure a line-activation (exec) banner to be displayed when EXEC processes such as a line activation or an incoming connection to a VTY line have been created. Simply initiating a user exec session through a console port will activate the exec banner.

Login banner You can configure a login banner for display on all connected terminals. It will show up after the MOTD banner but before the login prompts. This login banner can't be disabled on a per-line basis, so to globally disable it you've got to delete it with the no banner login command.

Here's what a login banner output looks like:

!

banner login ^C

-----------------------------------------------------------------

Cisco Router and Security Device Manager (SDM) is installed on this device.

This feature requires the one-time use of the username "cisco"

with the password "cisco". The default username and password

have a privilege level of 15.

Please change these publicly known initial credentials using

SDM or the IOS CLI.

Here are the Cisco IOS commands.

username <myuser>  privilege 15 secret 0 <mypassword>

no username cisco

Replace <myuser> and <mypassword> with the username and

password you want to use.

For more information about SDM please follow the instructions

in the QUICK START GUIDE for your router or go to http://www.cisco.com/go/sdm

-----------------------------------------------------------------

^C

!

The previous login banner should look pretty familiar to anyone who's ever logged into an ISR router because it's the banner Cisco has in the default configuration for its ISR routers.

Exam Essentials

Differentiate the enable password and enable secret password. Both of these passwords are used to gain access into privileged mode. However, the enable secret password is newer and is always encrypted by default. Also, if you set the enable password and then set the enable secret, only the enable secret will be used.

Describe the configuration and use of banners. Banners provide information to users accessing the device and can be displayed at various login prompts. They are configured with the banner command and a keyword describing the specific type of banner.

Set the enable secret on a router. To set the enable secret, you use the global config command enable secret. Do not use enable secret password password or you will set your password to password password. Here is an example:

enable

config t

enable secret todd

Set the console password on a router. To set the console password, use the following sequence:

enable

config t

line console 0

password todd

login

Set the Telnet password on a router. To set the Telnet password, the sequence is as follows:

enable

config t

line vty 0 4

password todd

login

Describe the advantages of using Secure Shell and list its requirements. Secure Shell (SSH) uses encrypted keys to send data so that usernames and passwords are not sent in the clear. It requires that a hostname and domain name be configured and that encryption keys be generated.

Describe device security using AAA with TACACS+ and RADIUS

Of course we only want authorized IT folks to have administrative access to our network devices such as routers and switches, and in a small to medium-sized network, just using local authentication is sufficient.

However, if you have hundreds of devices, managing administrative connectivity would be nearly impossible since you'd have to configure local authentication on each device by hand, and if you changed just one password, it can take hours to update your network.

Since maintaining the local database for each network device for the size of the network is usually not feasible, you can use an external authentication, authorization, and accounting (AAA) server that will manage all user and administrative access needs for an entire network. The two most popular options for external AAA are RADIUS and TACACS+, both covered next.

RADIUS

Remote Authentication Dial-In User Service, or RADIUS, was developed by the Internet Engineering Task Force—the IETF—and is basically a security system that works to guard the network against unauthorized access. RADIUS, which uses only UDP, is an open standard implemented by most major vendors, and it's one of the most popular types of security servers around because it combines authentication and authorization services into a single process. So after users are authenticated, they are then authorized for network services.

RADIUS implements a client/server architecture, where the typical client is a router, switch, or AP and the typical server is a Windows or Unix device that's running RADIUS software.

The authentication process has three distinct stages:

1. The user is prompted for a username and password.
2. The username and encrypted password are sent over the network to the RADIUS server.
3. The RADIUS server replies with one of the following:

It's important to remember that RADIUS encrypts only the password in the access-request packet from the client to the server. The remainder of the packet is unencrypted.

Configuring RADIUS

To configure a RADIUS server for console and VTY access, first you need to enable AAA services in order to configure all the AAA commands. Configure the aaa new-model command in the global configuration mode.

Router(config)# aaa new-model

The aaa new-model command immediately applies local authentication to all lines and interfaces (except line con 0). So, to avoid being locked out of the router or switch, you should define a local username and password before starting the AAA configuration.

Now, configure a local user.

Router(config)#username Todd password Lammle

Creating this user is super important because you can then use this same locally created user if the external authentication server fails! If you don't create this and you can't get to the server, you're going to end up doing a password recovery.

Next, configure a RADIUS server using any name and the RADIUS key that is configured on the server.

Router(config)#radius server SecureLogin

Router(config-radius-server)#address ipv4 10.10.10.254

Router(config-radius-server)#key MyRadiusPassword

Now, add your newly created RADIUS server to an AAA group of any name.

Router(config)#aaa group server radius MyRadiusGroup

Router(config-sg-radius)#server name SecureLogin

Last, configure this newly created group to be used for AAA login authentication. If the RADIUS server fails, the fallback to local authentication should be set.

Router(config)# aaa authentication login default group MyRadiusGroup local

TACACS+

Terminal Access Controller Access Control System (TACACS+) is also a security server that's Cisco proprietary and uses TCP. It's really similar in many ways to RADIUS; however, it does all that RADIUS does and more, including multiprotocol support.

TACACS+ was developed by Cisco Systems, so it's specifically designed to interact with Cisco's AAA services. If you're using TACACS+, you have the entire menu of AAA features available to you—and it handles each security aspect separately, unlike RADIUS:

• Authentication includes messaging support in addition to login and password functions.
• Authorization enables explicit control over user capabilities.
• Accounting supplies detailed information about user activities.

Configuring TACACS+

This is pretty much identical to the RADIUS configuration.

To configure a TACACS+ server for console and VTY access, first you need to enable AAA services in order to configure all the AAA commands. Configure the aaa new-model command in the global configuration mode (if it isn't already enabled).

Router(config)# aaa new-model

Now, configure a local user if you haven't already.

Router(config)#username Todd password Lammle

Next, configure a TACACS+ server using any name and the key that is configured on the server.

Router(config)#radius server SecureLoginTACACS+

Router(config-radius-server)#address ipv4 10.10.10.254

Router(config-radius-server)#key MyTACACS+Password

Now, add your newly created TACACS+ server to a AAA group of any name.

Router(config)#aaa group server radius MyTACACS+Group

Router(config-sg-radius)#server name SecureLoginTACACS+

Last configure this newly created group to be used for AAA login authentication. If the TACACS+ server fails, the fallback to local authentication should be set.

Router(config)# aaa authentication login default group MyTACACS+Group local

Exam Essentials

Understand TACACS+ and RADIUS. TACACS+ is Cisco proprietary, uses TCP, and can separate services. RADIUS is an open standard, uses UDP, and cannot separate services.

Review Questions

You can find the answers in the Appendix.

1. Which of the following commands will enable AAA on a router?
   1. aaa enable
   2. enable aaa
   3. new-model aaa
   4. aaa new-model
2. Which of the following will mitigate access layer threats? (Choose two.)
   1. Port security
   2. Access lists
   3. Dynamic ARP inspection
   4. AAA
3. Which of the following is not true about DHCP snooping?
   1. DHCP snooping validates DHCP messages received from untrusted sources and filters out invalid messages.
   2. DHCP snooping builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.
   3. DHCP snooping rate-limits DHCP traffic from trusted and untrusted sources.
   4. DHCP snooping is a layer 2 security feature that acts like a firewall between hosts.
4. Which of the following are true about TACACS+? (Choose two.)
   1. TACACS+ is a Cisco proprietary security mechanism.
   2. TACACS+ uses UDP.
   3. TACACS+ combines authentication and authorization services as a single process—after users are authenticated, they are also authorized.
   4. TACACS+ offers multiprotocol support.
5. Which of the following is not true about RADIUS?
   1. RADIUS is an open standard protocol.
   2. RADIUS separates AAA services.
   3. RADIUS uses UDP.
   4. RADIUS encrypts only the password in the access-request packet from the client to the server. The remainder of the packet is unencrypted.
6. Which of the following statements is false when a packet is being compared to an access list?
   1. It's always compared with each line of the access list in sequential order.
   2. Once the packet matches the condition on a line of the access list, the packet is acted upon and no further comparisons take place.
   3. There is an implicit “deny” at the end of each access list.
   4. Until all lines have been analyzed, the comparison is not over.
7. You need to create an access list that will prevent hosts in the network range of 192.168.160.0 to 192.168.191.0. Which of the following lists will you use?
   1. access-list 10 deny 192.168.160.0 255.255.224.0
   2. access-list 10 deny 192.168.160.0 0.0.191.255
   3. access-list 10 deny 192.168.160.0 0.0.31.255
   4. access-list 10 deny 192.168.0.0 0.0.31.255
8. You have created a named access list called BlockSales. Which of the following is a valid command for applying this to packets trying to enter interface Fa0/0 of your router?
   1. (config)#ip access-group 110 in
   2. (config-if)#ip access-group 110 in
   3. (config-if)#ip access-group Blocksales in
   4. (config-if)#BlockSales ip access-list in
9. Which access list statement will permit all HTTP sessions to network 192.168.144.0/24 containing web servers?
   1. access-list 110 permit tcp 192.168.144.0 0.0.0.255 any eq 80
   2. access-list 110 permit tcp any 192.168.144.0 0.0.0.255 eq 80
   3. access-list 110 permit tcp 192.168.144.0 0.0.0.255 192.168.144.0 0.0.0.255 any eq 80
   4. access-list 110 permit udp any 192.168.144.0 eq 80
10. Which of the following access lists will allow only HTTP traffic into network 196.15.7.0?
    1. access-list 100 permit tcp any 196.15.7.0 0.0.0.255 eq www
    2. access-list 10 deny tcp any 196.15.7.0 eq www
    3. access-list 100 permit 196.15.7.0 0.0.0.255 eq www
    4. access-list 110 permit ip any 196.15.7.0 0.0.0.255
    5. access-list 110 permit www 196.15.7.0 0.0.0.255