Mitigating Security Issues with ACLs

The most common attack is a denial of service (DoS) attack. Although ACLs can help with a DoS, you really need an intrusion detection system (IDS) and intrusion prevention system (IPS) to help prevent these common attacks. Cisco sells the Adaptive Security Appliance (ASA), which has IDS/IPS modules, but lots of other companies sell IDS/IPS products too.

Here’s a list of the many security threats you can mitigate with ACLs:

• IP address spoofing, inbound
• IP address spoofing, outbound
• Denial of service (DoS) TCP SYN attacks, blocking external attacks
• DoS TCP SYN attacks, using TCP Intercept
• DoS smurf attacks
• Denying/filtering ICMP messages, inbound
• Denying/filtering ICMP messages, outbound
• Denying/filtering Traceroute

It’s generally a bad idea to allow into a private network any external IP packets that contain the source address of any internal hosts or networks—just don’t do it!

Here’s a list of rules to live by when configuring ACLs from the Internet to your production network to mitigate security problems:

• Deny any source addresses from your internal networks.
• Deny any local host addresses (127.0.0.0/8).
• Deny any reserved private addresses (RFC 1918).
• Deny any addresses in the IP multicast address range (224.0.0.0/4).

None of these source addresses should be ever be allowed to enter your internetwork. Now finally, let’s get our hands dirty and configure some basic and advanced access lists!

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 12.2, 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 were an inbound list placed on F0/0, then any packet trying to enter interface F0/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 12.3 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 12.4, 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!

Controlling VTY (Telnet/SSH) Access

Trying to stop users from telnetting or trying to SSH to a router is really challenging because any active interface on a router is fair game for VTY/SSH access. Creating an extended IP ACL that limits access to every IP address on the router may sound like a solution, but if you did that, you’d have to apply it inbound on every interface, which really wouldn’t scale well if you happen to have dozens, even hundreds, of interfaces, now would it? And think of all the latency dragging down your network as a result of each and every router checking every packet just in case the packet was trying to access your VTY lines—horrible!

Don’t give up—there’s always a solution! And in this case, a much better one, which employs a standard IP access list to control access to the VTY lines themselves.

Why does this work so well? Because when you apply an access list to the VTY lines, you don’t need to specify the protocol since access to the VTY already implies terminal access via the Telnet or SSH protocols. You also don’t need to specify a destination address because it really doesn’t matter which interface address the user used as a target for the Telnet session. All you really need control of is where the user is coming from, which is betrayed by their source IP address.

You need to do these two things to make this happen:

1. Create a standard IP access list that permits only the host or hosts you want to be able to telnet into the routers.
2. Apply the access list to the VTY line with the access-class in command.

Here, I’m allowing only host 172.16.10.3 to telnet into a router:

Lab_A(config)#access-list 50 permit host 172.16.10.3
Lab_A(config)#line vty 0 4
Lab_A(config-line)#access-class 50 in

Because of the implied deny any at the end of the list, the ACL stops any host from telnetting into the router except the host 172.16.10.3, regardless of the individual IP address on the router being used as a target. It’s a good idea to include an admin subnet address as the source instead of a single host, but the reason I demonstrated this was to show you how to create security on your VTY lines without adding latency to your router.

Extended Access List Example 1

For our first scenario, we’ll use Figure 12.5. 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 12.4 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 12.6 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 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

Perfect! Now let’s get into how to create ACLs using names.

Named ACLs

As I said earlier, 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 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 12.2 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 12.6, 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. That isn’t just nice, it’s wonderful! Numbered ACLs just can’t compare with that, and I’ll demonstrate this in a minute.

Remarks

The remark keyword is really important because it arms you with the ability to include comments—remarks—regarding the entries you’ve made in both your IP standard and extended ACLs. Remarks are very cool because they efficiently increase your ability to examine and understand your ACLs to superhero level! Without them, you’d be caught in a quagmire of potentially meaningless numbers without anything to help you recall what all those numbers mean.

Even though you have the option of placing your remarks either before or after a permit or deny statement, I totally recommend that you choose to position them consistently so you don’t get confused about which remark is relevant to a specific permit or deny statement.

To get this going for both standard and extended ACLs, just use the access-list access-list number remark remark global configuration command like this:

R2#config t
R2(config)#access-list 110 remark Permit Bob from Sales Only To Finance
R2(config)#access-list 110 permit ip host 172.16.40.1 172.16.50.0 0.0.0.255
R2(config)#access-list 110 deny ip 172.16.40.0 0.0.0.255 172.16.50.0 0.0.0.255
R2(config)#ip access-list extended No_Telnet
R2(config-ext-nacl)#remark Deny all of Sales from Telnetting to Marketing
R2(config-ext-nacl)#deny tcp 172.16.40.0 0.0.0.255 172.16.60.0 0.0.0.255 eq 23
R2(config-ext-nacl)#permit ip any any
R2(config-ext-nacl)#do show run
[output cut]
!
ip access-list extended No_Telnet
 remark Stop all of Sales from Telnetting to Marketing
 deny   tcp 172.16.40.0 0.0.0.255 172.16.60.0 0.0.0.255 eq telnet
 permit ip any any
!
access-list 110 remark Permit Bob from Sales Only To Finance
access-list 110 permit ip host 172.16.40.1 172.16.50.0 0.0.0.255
access-list 110 deny   ip 172.16.40.0 0.0.0.255 172.16.50.0 0.0.0.255
access-list 110 permit ip any any
!

Sweet—I was able to add a remark to both an extended list and a named access list. Keep in mind that you cannot see these remarks in the output of the show access-list command, which we’ll cover next, because they only show up in the running-config.

Speaking of ACLs, I still need to show you how to monitor and verify them. This is an important topic, so pay attention!

Hands-on Lab 12.1: Standard IP Access Lists

In this lab, you will allow only packets from a single host on the SF LAN to enter the LA LAN.

1. Go to LA router and enter global configuration mode by typing config t.
2. From global configuration mode, type access-list ? to get a list of all the different access lists available.
3. Choose an access-list number that will allow you to create an IP standard access list. This is a number between 1 and 99 or 1300 and 1399.

4. Choose to permit host 192.168.10.2, which is the host address:

   LA(config)#access-list 10 permit 192.168.20.2 ?
     A.B.C.D  Wildcard bits
     <cr>

   To specify only host 192.168.20.2, use the wildcards 0.0.0.0:

   LA(config)#access-list 10 permit 192.168.20.2
     0.0.0.0

5. Now that the access list is created, you must apply it to an interface to make it work:

   LA(config)#int f0/0
   Lab_A(config-if)#ip access-group 10 out

6. Verify your access list with the following commands:

   LA#sh access-list
   Standard IP access list 10
       permit 192.168.20.2
   LA#sh run
   [output cut]
   interface FastEthernet0/0
    ip address 192.168.20.1 255.255.255.0
    ip access-group 10 out

7. Test your access list by pinging from 192.168.10.2 to 192.168.20.2.
8. If you have another host on the LA LAN, ping that address, which should fail if your ACL is working.

Hands-on Lab 12.2: Extended IP Access Lists

In this lab, you will use an extended IP access list to stop host 192.168.10.2 from creating a Telnet session to router LA (172.16.10.6). However, the host still should be able to ping the LA router. IP extended lists should be placed close to the source, so add the extended list on router SF. Pay attention to the log command used in step 6. It is a Cisco objective!

1. Remove any access lists on SF and add an extended list to SF.
2. Choose a number to create an extended IP list. The IP extended lists use 100–199 or 2000–2699.

3. Use a deny statement. (You’ll add a permit statement in step 7 to allow other traffic to still work.)

   SF(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
     igrp     Cisco's IGRP routing 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
     tcp      Transmission Control Protocol
     udp      User Datagram Protocol

4. Since you are going to deny Telnet, you must choose TCP as a Transport layer protocol:

   SF(config)#access-list 110 deny tcp ?
     A.B.C.D  Source address
     any      Any source host
     host     A single source host

5. Add the source IP address you want to filter on, then add the destination host IP address. Use the host command instead of wildcard bits.

   SF(config)#access-list 110 deny tcp host
     192.168.10.2 host 172.16.10.6 ?
     ack          Match on the ACK bit
     eq           Match only packets on a given port
                  number
     established  Match established connections
     fin          Match on the FIN bit
     fragments    Check 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
     tos          Match packets with given TOS value
     urg          Match on the URG bit
     <cr>

6. At this point, you can add the eq telnet command to filter host 192.168.10.2 from telnetting to 172.16.10.6. The log command can also be used at the end of the command so that whenever the access-list line is hit, a log will be generated on the console.

   SF(config)#access-list 110 deny tcp host
     192.168.10.2 host 172.16.10.6 eq telnet log

7. It is important to add this line next to create a permit statement. (Remember that 0.0.0.0 255.255.255.255 is the same as the any command.)

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

   You must create a permit statement; if you just add a deny statement, nothing will be permitted at all. Please see the sections earlier in this chapter for more detailed information on the deny any command implied at the end of every ACL.

8. Apply the access list to the FastEthernet0/0 on SF to stop the Telnet traffic as soon as it hits the first router interface.

   SF(config)#int f0/0
   SF(config-if)#ip access-group 110 in
   SF(config-if)#^Z

9. Try telnetting from host 192.168.10.2 to LA using the destination IP address of 172.16.10.6. This should fail, but the ping command should work.

10. On the console of SF, because of the log command, the output should appear as follows:

    01:11:48: %SEC-6-IPACCESSLOGP: list 110 denied tcp
      192.168.10.2(1030) -> 172.16.10.6(23), 1 packet
    01:13:04: %SEC-6-IPACCESSLOGP: list 110 denied tcp
      192.168.10.2(1030) -> 172.16.10.6(23), 3 packets