5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

Every network device has three logical planes: the data plane that forwards user traffic, the control plane that runs the routing and switching protocols, and the management plane that administrators use to configure the box. CPSA syllabus item D1 asks about weaknesses in the protocols used for remote management of devices and names Cisco Reverse Telnet explicitly alongside Telnet, SSH, SNMP, TFTP and NTP.

The management plane is attractive precisely because it is often treated as a back office concern. It is built early, documented poorly, and exempted from the hardening that the production path receives.

---

1. In-Band vs Out-of-Band Management

The last row is the assessor's opportunity. An organisation builds an OOB network so that it can recover from an outage, then reasons that because the OOB network is "separate" it does not need authentication hardening. If any path exists from the corporate network into that management segment — a dual-homed jump host, a misconfigured firewall rule, a forgotten trunk — the entire estate's consoles are exposed.

---

2. Console and AUX Ports

Cisco IOS devices expose several line types, listed by show line:

• con 0 — the console port. An RJ-45 or USB serial port requiring physical presence. Critically, console access normally permits password recovery by interrupting the boot sequence and altering the configuration register (confreg 0x2142) to bypass the startup configuration. Physical access to a console port is therefore equivalent to administrative control of the device, which is why comms-room locks are a network finding, not just a facilities one.
• aux 0 — the auxiliary port. A second serial port intended for an inbound modem. If left enabled with a modem attached, it provides a dial-in route straight to the device's EXEC prompt, entirely bypassing the firewall, the VPN and every network control. This is the classic "war dialling" target and remains a genuine finding in utilities, retail and manufacturing estates.
• tty / line N — asynchronous lines. On a router equipped with an async module (for example an NM-16A or NM-32A), each line drives a serial cable to another device's console port. This is the terminal server role.
• vty 0 4 (or 0 15) — virtual terminal lines. The inbound Telnet/SSH sessions.

---

3. Reverse Telnet and the Terminal Server

Reverse Telnet inverts the usual direction. Normally you telnet from a router to somewhere else. In reverse telnet you telnet to the router, on a special TCP port, and the router connects you through to one of its async lines — and therefore to the console port of whatever is cabled to that line.

A terminal server (console server) with sixteen async lines cabled to sixteen device consoles lets an administrator reach every console in a rack from their desk. It also means that compromising that one terminal server yields console-level access to sixteen devices.

The Port Arithmetic

This is examinable and worth memorising. The router derives the listening TCP port from a base plus the line number:

+--------------+---------------------------+----------------------------------------+
| TCP Base     | Target                    | Behaviour                              |
+--------------+---------------------------+----------------------------------------+
| 2000 + line  | Individual async line     | Telnet protocol; CR translated to CRLF |
| 3000 + rotary| Rotary group (hunt group) | Connects to the next free line in group|
| 4000 + line  | Individual async line     | Raw TCP; no Telnet option negotiation  |
| 6000 + line  | Individual async line     | As 2000, but no carriage-return xlation|
+--------------+---------------------------+----------------------------------------+

So to reach the console of the device cabled to line 7 on terminal server 10.10.50.9:

telnet 10.10.50.9 2007        # telnet-style session to async line 7
telnet 10.10.50.9 4007        # raw TCP to the same line (e.g. for a printer)
telnet 10.10.50.9 6007        # telnet, no CR->CRLF translation
telnet 10.10.50.9 3001        # next free line in rotary group 1

Typical supporting configuration on the terminal server:

ip host SW-CORE-01 2007 10.10.50.9
!
line 1 16
 no exec
 transport input telnet
 exec-timeout 0 0
 rotary 1

Why This Is a Finding

Reverse Telnet sessions are authenticated by the line's own configuration, not by the device's main login. Three defaults conspire against the client:

1. transport input telnet (or all) — the console pass-through runs in cleartext, so credentials typed at the downstream device's console prompt cross the network unencrypted.
2. No line password and no login directive — a line configured with no exec for pass-through use frequently has no authentication at all, because administrators reason that the downstream device will prompt for its own credentials. That reasoning fails whenever the downstream device is sitting at a Router> prompt from a previous session.
3. exec-timeout 0 0 — sessions never time out, so an abandoned administrative session on a downstream console stays live and is inherited by whoever connects next. Clearing the line (clear line 7) resets it; not clearing it leaves a privileged session open indefinitely.

Scanning for this is straightforward: an Nmap scan of a suspected terminal server showing a contiguous run of open ports in the 2000–2032 or 4000–4032 range is a strong indicator.

nmap -Pn -sS -p 2001-2032,3001-3016,4001-4032,6001-6032 10.10.50.9

---

4. Hardening the Cisco Management Plane

The findings above map directly to a short set of recommendations you can put in a report:

line vty 0 4
 transport input ssh          ! never telnet
 access-class MGMT-ACL in     ! restrict source addresses
 login local                  ! or AAA
 exec-timeout 5 0             ! idle sessions die
!
line aux 0
 no exec                      ! disable the EXEC on the AUX port
 transport input none
!
line con 0
 login local
 exec-timeout 5 0
!
service password-encryption   ! obscures type 7 only - see 5.1
no ip http server             ! disable cleartext web management
ip ssh version 2
aaa new-model                 ! centralise auth (TACACS+ / RADIUS)

Note the ordering of value: access-class on the VTY lines is the single highest-value control, because it prevents the management plane from even being reachable from user subnets. service password-encryption is the lowest, because Cisco type 7 encoding is reversible.

---

5. Modern Lights-Out Management

Serial console servers have largely been replaced by baseboard management controllers (BMCs) — HPE iLO, Dell iDRAC, Lenovo/IBM IMM, Supermicro IPMI, and the vendor-neutral Redfish API. A BMC is an independent computer inside the server with its own CPU, firmware, NIC and power domain. It stays running when the host is powered off, and it can mount virtual media, power-cycle the host and capture the console.

The security properties are alarming and frequently examined in practice:

• IPMI listens on UDP port 623 (asf-rmcp). An Nmap UDP scan or the ipmi-version NSE script identifies it immediately.
• Cipher Zero — IPMI 2.0 defines cipher suite 0, which means "no authentication and no integrity". Where it is enabled, any client can execute administrative IPMI commands, including creating an administrator account, without credentials.
• RAKP hash retrieval — the IPMI 2.0 RAKP authentication exchange returns a salted HMAC of the requested user's password to an unauthenticated client, which can then be cracked offline. This is a design flaw in the specification, not a vendor bug, so the mitigation is network isolation rather than patching.
• Default credentials — ADMIN/ADMIN, root/calvin (iDRAC) and factory-printed iLO passwords survive in the field for years.
• Shared-NIC mode — many BMCs can share the host's production NIC. A BMC intended to be OOB then appears on the production VLAN, undoing the entire isolation design.

Because a BMC compromise yields power control, virtual media and console access, treat it as equivalent to physical access to the server. The correct recommendation is an isolated management VLAN with no route from user subnets, unique credentials, disabled cipher zero, and current BMC firmware.

---

6. Assessment Checklist for the Management Plane