Cisco gear has a well-known behaviour pattern that when you telnet to some weird and positively 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 (I don’t talk about other equipment from the Golden Gate folks) and it only confirmed this observation. Also I tested telnetting 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
control-plane host
service-policy type port-filter input FILTER_CLOSED_PORTS

Before the configuration:

# telnet 444
telnet: connect to address Connection refused

After the configuration:

[root@darkstar ~]# telnet 444
telnet: connect to address 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