Secure a VTY Port

All Cisco routers and switches cannot be accessed remotely via a terminal program like PuTTy and Tera Term by default. There are two methods of remote connectivity, either vty connection or SSH connection. The SSH provides encrypted connectivity, and Cisco recommends it for remote administration.

But, if your router’s Cisco IOS does not support SSH, we can use the vty connection. We can improve the security of administrative lines by restricting VTY port access.

VTY port access restriction allows you to define which IP addresses are allowed Telnet access to the router EXEC process. We can also control administrative workstations using an ACL and an access-class statement configured on VTY lines.

The access-class command configured in line configuration mode restricts connections between a particular VTY/SSH and the addresses in an access list. Both standard and extended access lists apply to packets that travel through a router. An outbound Telnet extended ACL does not prevent router-initiated Telnet sessions by default.

Filtering Telnet traffic is usually considered an extended IP ACL function because it filters a higher-level protocol. However, a standard ACL can be used because the access-class command filters incoming or outgoing Telnet/SSH sessions by source address. The access-class command syntax is the following:

Router(config-line)# access-class <access-list-number> { in |out }

The parameter “in” restricts incoming connections, and “out” restricts outgoing connections between the addresses in the access list and the Cisco device. We can allow a range of addresses or specific hosts.

The example below allows a range of addresses to access VTY lines 0-4 to router 3. Network 192.168.1.0 is permitted in the ACL to access VTY lines 0-4, and all other networks are denied access to the VTY port.

Verifying a Standard ACL used to secure a VTY Port

After configuring and applying ACL to VTY lines, verifying it is working as expected is important. The figure below shows a computer attempting to access R3 using telnet. Access list 2 has been configured on the VTY lines on R3. PC0 cannot access R3, but the attempt of PC1 successfully accessed the R3.

This is the expected result as we configured it. We can also use the show access-lists command after PC0 and PC1’s telnet attempts. The ACL statistics will show the match between the permit and deny lines.