Cisco gear has a well-known behaviour pattern that when you telnet to some weird and closed port on Cisco you get the uniform response of “Connection refused” . To add more precision it happens when a terminal line management access is enabled on the Cisco but your IP is not in the access-list allowing access to the device. The funny thing about that is that only Cisco seem to do it , and given so, it makes exposing a Cisco device a no-brainer. I tested it on few dozens of Cisco routers and it only confirmed this observation. Also I tested telneting to the other vendors’ equipment and always got back time out. So far I’ve tried Juniper, Brocade, IBM, Huawei. To somehow fix this situation Cisco actually have a feature in their Control Plane Protection toolbox just for that. Below I bring the configuration from IOS router that causes the router to time out connection attempts to the closed ports.

class-map type port-filter match-any CLOSED_PORTS  
 match  closed-ports  
policy-map type port-filter FILTER_CLOSED_PORTS  
 class CLOSED_PORTS  
   drop  
control-plane host  
 service-policy type port-filter input FILTER_CLOSED_PORTS

Testing.
Before the configuration:

telnet 19.6.24.51 444

Trying 19.6.24.51...  
telnet: connect to address 19.6.24.51: Connection refused

After the configuration:

[root@darkstar ~]# telnet 19.6.24.51 444

Trying 19.6.24.51...  
telnet: connect to address 19.6.24.51: Connection timed out  
telnet: Unable to connect to remote host: Connection timed out

NB Unfortunately it is a half-solution cause if telnet access is enabled on the Cisco then connection attempts to the port 23 will elicit the same “Connection refused” . To close even this disclosure hole , disable telnet as the management protocol and switch to SSH.
NB2 The good news for the pentesters out there is that rare ISP implement such protections

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.