Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

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.

Should You Secure Your VTY Lines on a Router?

You’re monitoring your network and notice that someone has

telnetted into your core router by using the

show users

command. You

use the

disconnect

command and they’re disconnected from the

router, but you notice that they’re right back in there a few minutes

later. You consider putting an ACL on the router interfaces, but you

don’t want to add latency on each interface since your router is

already pushing a lot of packets. At this point, you think about putting

an access list on the VTY lines themselves, but not having done this

before, you’re not sure if this is a safe alternative to putting an ACL on

each interface. Would placing an ACL on the VTY lines be a good idea

for this network?

Yes—absolutely! And the

access-class

command covered in this

chapter is the way to do it. Why? Because it doesn’t use an access list

that just sits on an interface looking at every packet, resulting in

unnecessary overhead and latency.

When you put the

access-class in

command on the VTY lines, only

packets trying to telnet into the router will be checked and compared,

providing easy-to-configure yet solid security for your router!

Just a reminder—Cisco recommends using Secure Shell (SSH)

instead of Telnet on the VTY lines of a router, as we covered in

Chapter 6, “Cisco’s Internetworking Operating System (IOS),” so

review that chapter if you need a refresher on SSH and how to

configure it on your routers and switches.

Extended Access Lists

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 affectively allow

users access to a physical LAN while denying them access to specific hosts

—even specific services on those hosts!

Yes, I am well aware there are no ICND1 objectives for

extended access lists, but you need to understand Extended ACL’s for

when you get to ICND2 troubleshooting, so I added foundation here.

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

If you want to filter by Application layer protocol, you have to

choose the appropriate layer 4 transport protocol after the

permit

or

deny

statement. For example, to filter Telnet or FTP, choose TCP since

both Telnet and FTP use TCP at the Transport layer. Selecting IP

wouldn’t allow you to specify a particular application protocol later

and only filter based on source and destination addresses.

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

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, the

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 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.

FIGURE 12.5

Extended ACL example 1

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.

Remember that instead of the

host 172.16.50.5

command

when we created the extended access list, we could have entered

172.16.50.5 0.0.0.0

. There would be no difference in the result other

than the router would change the command to

host 172.16.50.5

in

the running-config.

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).

The protocol parameter must be TCP since Telnet uses TCP. If it

were TFTP instead, then the protocol parameter would have to be

UDP because TFTP uses UDP at the Transport layer.

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.

FIGURE 12.6

Extended ACL example 3

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#