The VTY sessions are set for SSH, is telnet still open?

[samuel.d.knox]

I'm in the process of enabling SSH on all of my routers, switches and firewalls.  After upgrading the IOS to one that supports SSH, generating the crypto key and then setting all of the VTY sessions to SSH only, my security team informs me that telnet is still vulnerable to IP spoofing.  They can demonstrate that when they launch a telnet session to one of my routers, the telnet session will pause for maybe 2 seconds before receivign the message that the session was terminated by the router.  They claim this indicates that the router is responding to the telnet session and before the actual disconnect is forced they could IP spoof the box and cause a DOS.

I say boulderdash but without any proof I am forced to create a bunch of ACL's to specifically deny telnet.  Here is an example of my VTY's:

line vty 0 4
access-class 23 in
exec-timeout 30 0
password 7 xxxxxxxxxxxxx
logging synchronous
transport preferred ssh
transport input ssh
transport output ssh

*The access list here is limiting access from a certain internal set of IP's.

Any thoughts?

[Marcos Hernandez]

I think what you are seeing is normal behavior. An additional security mechanism which would prevent the TCP session from being established to the VTY, is to add an access list to your WAN interface that blocks Telnet. This ought to help and is what we recommend.

Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

[samuel.d.knox]

Thank you for the reply.

I understand that creating an ACL to specifically block telnet would help.  What I want to know is whether or not telnet is actually still open or not in the configuration I have identified.  My line of thinking is the answer is no.  I would think that unless the router specifically says telnet is available, then it doesn't matter if you try to open a telnet session or not, after all the return message specifically states that the session was terminated by the host.  So if the technical answer is, "No, telnet is not open nor is it possible to IP spoof the box and DOS the box." then creating an ACL for 500 plus devices is just make work.  On the other hand, if it is possible then my priority just went up to implement those access-lists.

FYI:  My WAN is already locked down in every location.  What I'm doing is tightening up the internal access because I've been told that the majority of hacking occurs from within a network.

Sam

[Marcos Hernandez]

By doing "transport input ssh" under the VTY, you are NOT disabling listening on port 23 (Telnet) on the router, but rather instructing the VTY to only do SSH. You can verify this by downloading a port scanner (like FreePortScanner) and running a port scan against the LAN IP. The only way to really close a port is by applying an ACL to the appropriate interfaces. This is the recommended configuration by many of our security advisories.

There is no command in IOS to display all "listening" ports (TCP or UDP). "show tcp brief all" gives you some information (for TCP), but it won't display all the TCP sessions in LISTEN state (including Telnet, finger, SSH, etc.). This is just the way IOS is.

Thanks,

Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

[samuel.d.knox]

Marcos,

Thank you for your time on this.  I believe I have found and corrected my issue.  In my first post I showed what the vty 0 4 sessions were set as.  What I failed to show was that the "vty 5 15" sessions were only set to "no exec".  So what was happening is that when I would telnet to the router, the session attempt would either walk down the list of VTY sessions looking for an open port or the router just bypassed the ones that were set for SSH and tried the first VTY port that was set for no exec.  This would allow for the telnet session to attempt to open but because the router was not allowing access to the command line interpreter, the router would reject the session attempt.

To correct this I simply set up all of my VTY sessions the same way, transport SSH in & transport SSH out.  The next attempt closed the telnet session immediately.  I still maintain there is no need for additional access-lists as I'm trying to keep my processor's free from any additional load to allow them to process the payload traffic as efficiently as possible.

If anyone has any best practices they would care to leave here, I would be interested.

Sam

[Marcos Hernandez]

Hi Sam,

You should be fine, but we still recommend interface ACL's for added security.

Thanks,

Marcos

[paul-d]

Just to say thanks I have been banging my head against a wall with this problem.

I assume there are a lot of people who haven't checked after trying top disable telnet - many thanks