Router Port Security and INsecurity

Frequently a Cisco Router administrator desires to have “backdoor” access to their device in case the authentication/authorization server is down or unreachable. Occasionally the senior administrator or IT staff manager will also desire a method of access which will always be available and only be available to them. This post will focus on the vty lines of a Cisco IOS router as a means to accomplish the above objective, as well as offer a “practice to avoid” in terms of a vulnerability that this author has discovered.

Consider a simple situation where a router will be accessed via the IP address via five vty (virtual terminal) lines numbered vty 0 through vty 4; virtually all Cisco IOS devices have this minimum number of available virtual terminal ports. The typical operation of an IOS device with the five vty lines is in a “round-robin” fashion whereby an administrator cannot predict which vty line they will access at any point in time. When a telnet to the router is performed, the IOS allocates the lowest numbered available port for the connection. A solution to this dilemma is provided in the IOS config commands offered below:

Router(config)# aaa new-model
Router(config)# aaa authentication login admin-only local
Router(config)# username superadmin password ********
Router(config)# access-list 150 permit tcp any any eq 3055
Router(config)# line vty 4
Router(config-line)# rotary 55
Router(config-line)# access-class 150 in
Router(config-line)# login authentication admin-only

A little-known “trick” shown above is to put a rotary group on the vty line which makes this particular port accessible via port 30xy using telnet, where xy is the rotary number. This would be an effective solution by itself if it weren’t for the fact that vty 4 can also be accessed via the default telnet port of 23. The access-list 150 above applied to this vty takes care of this by only allowing port 3055 into this line. Finally, the addition of a specific login authentication method isolates this port from the others in using strictly the local config database. Note that the last vty line in the series was chosen so that vty 0 through vty 3 are still available for round-robin access.

Now that we’ve looked at a means of providing specialized access to a particular vty line, let’s examine a security vulnerability. Examine the following partial configuration shown below:

Router(config)# ip finger
Router(config)# line vty 0 4
Router(config-line)# autocommand-option nohangup

First of all, let us be quick to point out that a strong recommendation from Cisco is to disable access to the finger port. The autocommand-option nohangup above is implemented usually in conjunction with a particular autocommand which would automatically execute a command upon logging into the vty line and not exit afterward. The author has successfully configured a router with autocommand terminal monitor and the autocommand-option nohangup so that log/debug messages will be enabled by default when a telnet is done and the session will remain active.

The result of having the finger service (TCP port 79) enabled can be seen dramatically in the screenshots below:

As seen here, a telnet to port 79 at the router results in getting logged into the router without authentication! To verify that an actual session has been established, some commands have been entered: show session and show ip int brief; note the strange “double characters”. This drives home the point of keeping the finger port disabled.

Author: Doug McKillip


  • Dial Technologies Commands: pri through rotary
  • Cisco Configuration Professional User Guide Version 1.4 (pdf file)
In this article

Join the Conversation