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
Before the configuration:
telnet 126.96.36.199 444
Trying 188.8.131.52... telnet: connect to address 184.108.40.206: Connection refused
After the configuration:
[root@darkstar ~]# telnet 220.127.116.11 444
Trying 18.104.22.168... telnet: connect to address 22.214.171.124: 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