Port 2601 – zebra (Quagga / FRRouting VTY)

Port 2601 is the default port for the zebra daemon’s management CLI — its vty (virtual terminal) — in the Quagga / GNU Zebra / FRRouting (FRR) software routing suites. These suites turn an ordinary Linux host into a full router by running one daemon per routing protocol, and each daemon exposes a Cisco-IOS-style command line over a telnet-based vty on its own TCP port. zebra is the core daemon: it owns the kernel routing table and coordinates the protocol daemons, and its vty listens on 2601. Because the vty is plain telnet and historically ships with the default password zebra, an exposed port 2601 is a management-plane finding — a defender who sees it has found a software router’s control interface.

Why It’s Open

Port 2601 shows up wherever Quagga or FRRouting is turning a general-purpose OS into a router: Linux-based routers and firewalls, ISP and hosting infrastructure, virtual routers and route reflectors in the cloud, SDN/overlay nodes, and network appliances that bundle FRR (the OPNsense/pfSense routing plugins, VyOS historically, and various Linux network operating systems). The tell-tale sign is the cluster: zebra on 2601 rarely travels alone, and the sibling daemons sit on the next ports up — ripd 2602, ripngd 2603, ospfd 2604, bgpd 2605, ospf6d 2606, isisd 2608. Seeing several of these open together is a strong signal you’re looking at a software router’s routing stack.

By default, Quagga and FRR bind the daemon vtys to localhost (127.0.0.1), so 2601 answering a remote scan usually means someone changed the bind address — a vty_addr in the config or a -A 0.0.0.0 on the daemon — to put management on the network, or it lives inside a management VLAN. Modern deployments prefer vtysh (a single integrated shell over a local Unix socket) or SSH on port 22, which is exactly why a raw telnet vty answering on 2601 is worth flagging rather than assuming it’s benign.

Common Risks

• Cleartext telnet management. The vty is Telnet — the password and every configuration command and its output cross the wire unencrypted. Anyone on the path can sniff the full routing configuration and the vty credentials with tcpdump or Wireshark.
• Default password zebra. The historical default vty password is literally zebra. If it was never changed, anyone who can reach 2601 gets read access to the entire routing configuration; with the enable password they get write access.
• Route injection and blackholing. Write access to zebra and the protocol daemons lets an attacker add, redirect, or withdraw routes — quietly redirecting traffic for interception or dropping it to cause an outage, the local-router equivalent of a BGP hijack.
• Topology and configuration disclosure. Even read-only, show running-config, show ip route, and show ip bgp expose internal addressing, peer relationships, and the whole network topology — valuable reconnaissance for the next move.
• Brute-forceable. The telnet vty has no meaningful rate limiting, and it protects everything with a single shared password, so it’s a soft target for password guessing.
• Sibling management plane. The same host almost always exposes 2602–2608 alongside 2601, and each protocol daemon’s vty is its own independent entry point that needs the same locking down.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and version

nmap -sV -p 2601 <target>

Sweep the whole daemon range

# 2601-2608 maps the running daemons: zebra 2601, ripd 2602, ripngd 2603,
# ospfd 2604, bgpd 2605, ospf6d 2606, isisd 2608
nmap -sV -p 2601-2608 <target>

Connect to the vty

telnet <target> 2601

A software router answers with a telnet Password: prompt for the vty. Getting a prompt at all — from anywhere but localhost or the management range — is the finding.

Check for the default password

# At the vty Password: prompt, try the historical default
zebra
# then, to reach configuration mode, the enable password (often also default/blank)
enable
show running-config

Brute-force the vty password (telnet)

hydra -P /usr/share/wordlists/rockyou.txt telnet://<target>:2601 -t 4 -f

Confirm the exposure, then read the configuration read-only rather than changing routes on a live network. Log every open port in the 2601–2608 range and every default or guessed password so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The zebra vty’s biggest exposure isn’t a memory-corruption bug — it’s the design and configuration: a cleartext telnet CLI protected by the default password zebra. The one CVE that lives squarely in the vty is a denial of service, and the routing-protocol parse bugs that make headlines belong to the protocol daemons, not the management port:

• CVE-2017-5495 — Unbounded memory allocation in the Quagga telnet vty CLI (the exact service on 2601–2606). Because the input buffer grows without limit when no newline arrives, an attacker who can reach the vty sends an oversized string and exhausts memory, crashing the daemon. Affects Quagga 0.93 through 1.1.0; fixed in Quagga 1.1.1 and the corresponding FRR release. CVSS 3.0 7.5.
• CVE-2016-1245 — A stack-based buffer overflow in the zebra daemon, but in its IPv6 Neighbor Discovery (Router Advertisement) processing, not the vty — so it’s a routing-packet parsing bug in the same daemon rather than a management-CLI flaw. Quagga before 1.0.20161017; CVSS 3.x 9.8. Worth patching, but it isn’t reachable through port 2601’s telnet interface.
• Routing-protocol daemon parse bugs — the malformed-message crashes and overflows in bgpd, ospfd, and the other protocol daemons (for example the FRR bgpd out-of-bounds read in CVE-2022-40302) are triggered over the routing protocols themselves by a configured or on-path peer — they are covered on the BGP / port 179 page, not here on the zebra management port.

Mitigation

• Never expose the routing vty to untrusted networks. Keep the daemon vtys bound to localhost (the default) or a dedicated management VLAN/VRF; don’t set vty_addr or -A to a public interface. Port 2601 — and its 2602–2608 siblings — should not answer the general network.
• Change the default zebra password. Set a strong, unique vty password and a separate strong enable password so a leaked login doesn’t hand over configuration mode.
• Prefer vtysh or SSH over the telnet vty. Manage the router through vtysh (an integrated shell over a local Unix socket) or over an SSH session, so credentials and commands are never sent in cleartext.
• ACL and firewall the vty ports. Apply an access-class on the vty and firewall TCP 2601–2608 to the management range only.
• Patch Quagga / FRRouting. Run Quagga ≥ 1.1.1 (or current FRR) to close the vty memory-exhaustion DoS, and stay current for the protocol-daemon parse fixes.
• Log and monitor the management plane. Alert on vty logins, failed password attempts, and configuration changes — a route change you didn’t make is an early sign of compromise. Pair it with SNMP monitoring on port 161 of peer and interface state.

Real-World Example

A textbook case is the ZyXEL ZyWALL appliance advisory (Exploit-DB 5289). The ZyWall bundled Quagga/Zebra for its routing and exposed the vty on the usual ports (2601, plus 2602 for RIP and 2604 for OSPF). The problem: even after an administrator changed the appliance’s own login password, the embedded Quagga/Zebra service still accepted the default password zebra. An attacker who could reach the device simply telnetted to the routing vty, logged in with zebra, and could then view and manipulate the appliance’s routing configuration. No memory-corruption exploit and no zero-day — just a telnet management CLI left reachable with a vendor default password, which is exactly the exposure port 2601 represents when it answers a scan.

FAQ

What is port 2601 used for?

Port 2601 is the default TCP port for the zebra daemon’s management CLI (vty) in the Quagga and FRRouting software routing suites. zebra is the core daemon that manages the kernel routing table and coordinates the per-protocol daemons; connecting to 2601 with telnet gives you its Cisco-IOS-style command line for viewing and configuring routing.

What service runs on port 2601, and what are ports 2602–2608?

Port 2601 is the zebra vty. The neighboring ports are the vtys of the other routing daemons in the same suite: ripd 2602, ripngd 2603, ospfd 2604, bgpd 2605, ospf6d 2606, and isisd 2608. Seeing several open together indicates a Quagga/FRR software router.

Is port 2601 dangerous?

The service itself is a legitimate routing-management interface, but it’s risky when exposed. The vty is telnet (cleartext) and historically uses the default password zebra, so an exposed 2601 can leak the entire routing configuration and — with the enable password — allow an attacker to inject or blackhole routes. Bound to localhost or a management VLAN with a strong password, the risk is manageable; open to an untrusted network, it’s a serious exposure.

What is the default password for Quagga/Zebra on port 2601?

The historical default vty password is zebra. Any deployment that never changed it lets anyone who can reach port 2601 read the routing configuration, which is why changing the vty and enable passwords is the first hardening step.

How do I secure or close port 2601?

Bind the vty to localhost or a management VLAN (don’t set vty_addr/-A to a public interface), change the default zebra and enable passwords, prefer vtysh or SSH over the telnet vty, and firewall TCP 2601–2608 to a trusted management range with a vty access-class. Patch Quagga/FRR to close CVE-2017-5495. If the host doesn’t need dynamic routing, stop the daemons and confirm the ports are closed with a rescan.

TL;DR

• Service: zebra daemon vty (telnet management CLI) in Quagga / GNU Zebra / FRRouting
• Default port: 2601/TCP — siblings: ripd 2602, ripngd 2603, ospfd 2604, bgpd 2605, ospf6d 2606, isisd 2608
• Biggest risk: a cleartext telnet management plane with the default password zebra — config disclosure and route injection; plus a vty DoS (CVE-2017-5495)
• Mitigation: bind to localhost/mgmt VLAN, change the zebra + enable passwords, use vtysh/SSH, ACL and firewall 2601–2608, patch Quagga/FRR