Securing Routers at Unattended Tower Sites

Why unattended routers are a special case

Routers in a staffed data center benefit from ambient oversight: badge logs, cameras, colleagues noticing odd behavior. A tower router has none of that. The detection window for compromise stretches from minutes to weeks, and the attacker knows it. Common exposure patterns at tower sites include:

• Vendor default or shared credentials left in place after installation
• Management interfaces reachable from the subscriber side of the network — or from the public Internet
• Telnet, HTTP or vendor API ports enabled "temporarily" during a turn-up and never disabled
• No centralized logging, so brute-force attempts and config changes leave no off-site record
• Firmware that has not been updated since the router was racked

Each of these is cheap to fix during installation and expensive to fix after an incident. The sections below treat them in order of impact.

Eliminate default and shared credentials

Default usernames and passwords are published in every vendor manual and indexed by automated scanners within minutes of a device appearing on a routable address. The first task at any new tower is to replace them — not with a single "company password" reused everywhere, but with credentials that are unique per device and stored in a password vault.

Centralize authentication

Once more than a handful of routers exist, per-device local accounts stop scaling. Engineers share the password, departing staff retain access, and nobody can answer "who logged into this router last Tuesday?" The standard fix is centralized authentication against RADIUS or TACACS+ so that:

• Every engineer authenticates with an individual account
• Access can be revoked centrally when someone leaves
• TACACS+ can log and authorize individual commands, not just sessions
• Multi-factor authentication can be enforced at the identity layer

Keep one local emergency account per router — vaulted, unique, and audited — for the day the authentication servers are unreachable. A tower that cannot be managed because the RADIUS path is down is a different kind of outage.

Isolate management traffic on a dedicated VLAN

Subscriber traffic and management traffic should never share a broadcast domain. A dedicated management VLAN — extended across the backhaul network to every site — gives you a single, well-defined surface to protect:

• Router and radio management interfaces live only on the management VLAN
• Access lists at the network edge permit management traffic only from your NOC subnets and jump hosts
• Subscriber CPE cannot reach router management ports even if a customer goes looking
• Routing protocol adjacencies, NTP and syslog all ride the same isolated plane

Treat the management VLAN as its own security zone with its own firewall policy. If you also assign public addressing at towers, keep management interfaces on private space inside that zone — see how many public IPs a tower actually needs for the addressing side of that decision.

Harden remote access: SSH, API and everything else

Every management protocol a router speaks is a door. The goal is one well-guarded door, not five unguarded ones. A defensible baseline for tower routers:

SSH hardening checklist

• Disable Telnet and plain-HTTP management entirely; permit SSH and HTTPS only
• Move SSH off the default port only as noise reduction — never as a substitute for access control
• Bind the SSH service to the management VLAN interface, not to all interfaces
• Prefer key-based authentication for automation accounts
• Apply an ingress filter so SSH is reachable only from NOC and jump-host addresses
• Enable login banners and session timeouts appropriate to your policies

Vendor APIs and proprietary management ports deserve the same treatment: disabled unless something actively uses them, and access-listed if they are. Features like router web panels, "quick set" pages and cloud-management agents should be a deliberate choice per site, not a default that follows the router out of the box.

Build out-of-band access that survives an outage

In-band management fails exactly when you need it most: a bad route, a locked-up control plane or a backhaul cut severs your only path to the router. Out-of-band (OOB) access gives you an independent way in. Common patterns at tower sites:

• LTE/5G modem on a console server — a small cellular path to a serial or management port, independent of the primary backhaul
• Secondary backhaul with a management-only policy — if the site has diverse paths, reserve a low-bandwidth management route over the secondary link
• Neighbor-assisted access — reach an adjacent site's router in-band, then hop to the isolated site over a local link

The OOB path must be authenticated and filtered as strictly as the primary one — a cellular modem with a default password is worse than no modem. Redundancy design for the access path follows the same logic as redundancy for subscriber traffic; see route failover between two backhaul providers and the redundant backhaul solution for the transport side.

Keep firmware current — deliberately

Router vulnerabilities are patched by firmware, and an unattended router running a years-old release is an open invitation. But blind auto-updates at a remote site carry their own risk: a failed upgrade with no one on-site can mean a truck roll or a climb. A workable policy:

• Track vendor security advisories for every router and radio model you operate
• Stage firmware updates in maintenance windows, one ring of sites at a time, with the OOB path verified first
• Keep a known-good firmware image and config backup on the device or at the site for rollback
• Standardize on as few router models as practical so advisory tracking and testing stay manageable

Log everything off-site, and back up every config

A router's local log buffer vanishes on reboot — and an attacker who controls the router controls its logs. Send syslog (authentication events, config changes, routing flaps) to a central collector, and alert on the patterns that matter: logins from unexpected sources, repeated authentication failures, configuration changes outside maintenance windows.

Pair logging with automated config backups on every change or at least daily. When a router is compromised — or simply dies in a lightning storm — restoring service becomes a config push to replacement hardware instead of a reconstruction from memory. Version-controlled backups also give you a clean diff to answer "what changed?" after any incident.

Do not forget the physical layer

Logical hardening means little if anyone who opens the cabinet can factory-reset the router or plug into a console port. Reasonable physical controls at unattended sites:

• Locked cabinets or enclosures, with keys or codes tracked and rotated
• Console ports disabled, password-protected or physically obstructed where the platform allows
• Unused Ethernet ports shut down and assigned to a dead-end VLAN
• Tamper-evident seals or contact sensors on enclosures feeding into your monitoring
• A documented procedure for who may visit a site and what they may touch

Putting it together

None of these controls is exotic, and none requires new hardware beyond, at most, a console server and a cellular modem. The hard part is consistency: a standard router configuration template, applied at every turn-up and audited on a schedule, is what separates a hardened network from a hardened slide deck. The same discipline extends upstream to DDoS exposure — see protecting tower infrastructure from DDoS attacks — and to the wider WISP security program in the cybersecurity checklist for WISPs.

To see where your current sites stand, score your posture with the security score calculator, or explore the tower security solution and the broader SmashByte Wireless division.