Lab 3-8 – Configuring the VTY Lines Access Control List

In this lab you will learn how to configure an ACL to control specific networks and/or host access to establish an exec session via VTY lines used for remote administration.

Real World Application

In production networks it’s a common security policy to control remote administration to network devices using an access control list specifying only a particular administrative subnets and/or hosts on the network access to establish a remote exec session to the device for management.

Lab Prerequisites

• If you are using GNS3 than load the Stub Area Networking GNS3 topology than start devices start R1, R2, R3 and SW1.
• Establish a console session with devices R1, R2, R3 and SW1 than configure their respected host names.
• Configure the IP address 10.1.1.1/24 on the FastEthernet0/0 interface of R1.
• Configure the IP address 10.1.1.2/24 on the FastEthernet0/0 interface of R2.
• Configure the IP address 10.1.1.3/24 on the FastEthernet0/0 interface of R3.
• Configure a local username and password on R1 with level 15 privileges which will be used to authenticate VTY exec sessions locally.
• Configure R1 to accept both Telnet and SSH sessions.

Lab Objectives

• Create a named extended access-list called VTY_ACCESS
• Deny host 10.1.1.3 from accessing the vty lines via telnet.
• Permit the network range 10.1.1.0/24 to use telnet or ssh
• Deny all other traffic and log the denied attempted connections.
• Configure the access-list on the vty lines using the access-class command.
• Verify your configuration and connectivity using R2 and R3.

Lab Instruction

One of the biggest new management features of 12.3T and 12.4 mainline is the ability to use extended access-lists to permit particular traffic to establish an exec session to the vty lines of a Cisco device using a particular protocol; ie, telnet and/or ssh.

Step 1. – Configure a named access-list on R1 called VTY_ACCESS

R1 con0 is now available

Press RETURN to get started.

R1>enable
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip access-list extended VTY_ACCESS
R1(config-ext-nacl)#

Step 2. – Deny host 10.1.1.3 from accessing the vty lines via telnet. In order to complete this objective you’ll need to specify the source as host 10.1.1.3 and destination as any eq telnet as shown below;

R1(config-ext-nacl)#10 deny tcp host 10.1.1.3 any eq telnet

Step 3. – Permit the network range 10.1.1.0/24 to use telnet or ssh. This objective will require two access list entries, one for telnet (tcp port 23) and one for ssh (tcp port 22) as shown below;

R1(config-ext-nacl)#20 permit tcp 10.1.1.0 0.0.0.255 any eq 22
R1(config-ext-nacl)#30 permit tcp 10.1.1.0 0.0.0.255 any eq 23

Step 4. – Deny all other traffic and log the denied connection attempts.

R1(config-ext-nacl)#500 deny ip any any log

Step 5. – Configure the access-list on the vty lines using the access-class command.

R1(config-ext-nacl)#line vty 0 4
R1(config-line)#access-class VTY_ACCESS in
R1(config-line)#end
R1#

Step 6. – Verify your configuration and connectivity using R2 and R3.

Before verifying the connectivity using R2 and R3 first be sure to verify your access-list on R1 using the show ip access-list

R1#show access-list
Extended IP access list VTY_ACCESS
    10 deny tcp host 10.1.1.3 any eq telnet
    20 permit tcp 10.1.1.0 0.0.0.255 any eq 22
    30 permit tcp 10.1.1.0 0.0.0.255 any eq telnet
    500 deny ip any any log
R1#

After verifying the access-list is correct, you can then test connectivity to R1 from R2 using Telnet and/or SSH. Keep in mind when you Telnet or SSH from a Cisco device it will use the IP address of the interface that traffic exits to get to that destination, in this case 10.1.1.2/24 as shown below by the show users command;

R2#telnet 10.1.1.1
Trying 10.1.1.1 ... Open

User Access Verification

Username: tom
Password:
R1#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:14:12
*  2 vty 0     tom        idle                 00:00:00 10.1.1.2

  Interface    User               Mode         Idle     Peer Address

R1#exit

[Connection to 10.1.1.1 closed by foreign host]
R2#ssh -l tom 10.1.1.1

Password: 

R1#sh ssh
Connection Version Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       tom
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       tom
%No SSHv1 server connections running.
R1#

Now using R3 verify that 10.1.1.3/24 is being denied access via telnet and permitted access via SSH to R1 as shown below;

R3#telnet 10.1.1.1
Trying 10.1.1.1 ...
% Connection refused by remote host

R3#ssh -l tom 10.1.1.1

Password: 

R1#show ssh
Connection Version Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       tom
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       tom
%No SSHv1 server connections running.
R1#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:13:53
*  2 vty 0     tom        idle                 00:00:00 10.1.1.3

  Interface    User               Mode         Idle     Peer Address

R1#

You can verify that telnet was indeed denied using the vty line ACL on R1 by executing the show access-list command in privileged mode. This will show you a hit count number beside each access control list entry;

R1#show access-list
Extended IP access list VTY_ACCESS
    10 deny tcp host 10.1.1.3 any eq telnet (1 match)
    20 permit tcp 10.1.1.0 0.0.0.255 any eq 22 (4 matches)
    30 permit tcp 10.1.1.0 0.0.0.255 any eq telnet (6 matches)
    500 deny ip any any log
R1#