Protección de routers en sitios de torres sin personal

Por qué los routers sin supervisión son un caso especial

Los routers en un centro de datos con personal se benefician de una supervisión constante: registros de credenciales de acceso, cámaras y colegas que notan comportamientos extraños. Un router de torre no cuenta con nada de eso. La ventana de detección de una intrusión se extiende de minutos a semanas, y el atacante lo sabe. Los patrones de exposición más comunes en los sitios de torre incluyen:

• Credenciales predeterminadas del fabricante o compartidas que permanecen activas después de la instalación
• Interfaces de gestión accesibles desde el lado de los suscriptores de la red —o desde el Internet público
• Puertos de Telnet, HTTP o API del fabricante habilitados "temporalmente" durante una puesta en marcha y nunca deshabilitados
• Ausencia de registro centralizado, por lo que los intentos de fuerza bruta y los cambios de configuración no dejan constancia fuera del sitio
• Firmware que no se ha actualizado desde que se instaló el router

Cada uno de estos problemas es barato de corregir durante la instalación y costoso de corregir después de un incidente. Las secciones siguientes los abordan en orden de impacto.

Elimine las credenciales predeterminadas y compartidas

Los nombres de usuario y contraseñas predeterminados están publicados en cada manual del fabricante y son indexados por escáneres automatizados a los pocos minutos de que un dispositivo aparezca en una dirección enrutable. La primera tarea en cualquier torre nueva es reemplazarlos —no con una única "contraseña de empresa" reutilizada en todas partes, sino con credenciales únicas por dispositivo y almacenadas en una bóveda de contraseñas.

Centralice la autenticación

Cuando ya existen más de unos pocos routers, las cuentas locales por dispositivo dejan de escalar. Los ingenieros comparten la contraseña, el personal que se va conserva el acceso y nadie puede responder "¿quién inició sesión en este router el martes pasado?". La solución estándar es la autenticación centralizada mediante RADIUS o TACACS+, de modo que:

• Cada ingeniero se autentica con una cuenta individual
• El acceso puede revocarse de forma centralizada cuando alguien deja la empresa
• TACACS+ puede registrar y autorizar comandos individuales, no solo sesiones
• La autenticación multifactor puede exigirse en la capa de identidad

Mantenga una cuenta local de emergencia por router —resguardada en bóveda, única y auditada— para el día en que los servidores de autenticación no estén disponibles. Una torre que no puede administrarse porque la ruta hacia RADIUS está caída es un tipo distinto de interrupción.

Aísle el tráfico de gestión en una VLAN dedicada

El tráfico de suscriptores y el tráfico de gestión nunca deben compartir un dominio de difusión. Una VLAN de gestión dedicada —extendida a través de la red de backhaul hasta cada sitio— le proporciona una superficie única y bien definida que proteger:

• Las interfaces de gestión de routers y radios existen únicamente en la VLAN de gestión
• Las listas de acceso en el borde de la red permiten el tráfico de gestión solo desde las subredes del NOC y los hosts de salto
• Los CPE de los suscriptores no pueden alcanzar los puertos de gestión del router aunque un cliente lo intente
• Las adyacencias de protocolos de enrutamiento, NTP y syslog viajan por el mismo plano aislado

Trate la VLAN de gestión como su propia zona de seguridad con su propia política de firewall. Si además asigna direccionamiento público en las torres, mantenga las interfaces de gestión en espacio privado dentro de esa zona —consulte cuántas IP públicas necesita realmente una torre para conocer el aspecto de direccionamiento de esa decisión.

Endurezca el acceso remoto: SSH, API y todo lo demás

Cada protocolo de gestión que habla un router es una puerta. El objetivo es una sola puerta bien vigilada, no cinco sin vigilancia. Una base defendible para los routers de torre:

Lista de verificación de hardening de SSH

• Deshabilite por completo la gestión por Telnet y HTTP sin cifrar; permita únicamente SSH y HTTPS
• Mueva SSH fuera del puerto predeterminado solo como reducción de ruido —nunca como sustituto del control de acceso
• Vincule el servicio SSH a la interfaz de la VLAN de gestión, no a todas las interfaces
• Prefiera la autenticación basada en claves para las cuentas de automatización
• Aplique un filtro de entrada para que SSH sea accesible únicamente desde las direcciones del NOC y de los hosts de salto
• Habilite banners de inicio de sesión y tiempos de expiración de sesión acordes con sus políticas

Las API de los fabricantes y los puertos de gestión propietarios merecen el mismo tratamiento: deshabilitados salvo que algo los use activamente, y protegidos con listas de acceso cuando lo estén. Funciones como los paneles web del router, las páginas de "configuración rápida" y los agentes de gestión en la nube deben ser una decisión deliberada por sitio, no un valor predeterminado que acompaña al router desde la caja.

Construya un acceso fuera de banda que sobreviva a una interrupción

La gestión dentro de banda falla exactamente cuando más la necesita: una ruta incorrecta, un plano de control bloqueado o un corte de backhaul corta su único camino hacia el router. El acceso fuera de banda (OOB) le ofrece una vía de entrada independiente. Patrones comunes en sitios de torre:

• Módem LTE/5G en un servidor de consola — una pequeña ruta celular hacia un puerto serial o de gestión, independiente del backhaul principal
• Backhaul secundario con una política exclusiva de gestión — si el sitio cuenta con rutas diversas, reserve una ruta de gestión de bajo ancho de banda por el enlace secundario
• Acceso asistido por un sitio vecino — alcance el router de un sitio adyacente dentro de banda y luego salte al sitio aislado por un enlace local

La ruta OOB debe autenticarse y filtrarse con el mismo rigor que la principal —un módem celular con contraseña predeterminada es peor que no tener módem. El diseño de redundancia para la ruta de acceso sigue la misma lógica que la redundancia del tráfico de suscriptores; consulte conmutación por error de rutas entre dos proveedores de backhaul y la solución de backhaul redundante para el lado del transporte.

Mantenga el firmware actualizado —de forma deliberada

Las vulnerabilidades de los routers se corrigen mediante firmware, y un router sin supervisión que ejecuta una versión de hace años es una invitación abierta. Pero las actualizaciones automáticas a ciegas en un sitio remoto conllevan su propio riesgo: una actualización fallida sin nadie en el sitio puede significar enviar un camión o escalar la torre. Una política viable:

• Dé seguimiento a los avisos de seguridad del fabricante para cada modelo de router y radio que opere
• Programe las actualizaciones de firmware en ventanas de mantenimiento, un anillo de sitios a la vez, verificando primero la ruta OOB
• Conserve una imagen de firmware de confianza y una copia de seguridad de la configuración en el dispositivo o en el sitio para poder revertir
• Estandarice en la menor cantidad de modelos de router posible para que el seguimiento de avisos y las pruebas sean manejables

Registre todo fuera del sitio y respalde cada configuración

El búfer de registro local de un router desaparece con el reinicio —y un atacante que controla el router controla sus registros. Envíe syslog (eventos de autenticación, cambios de configuración, inestabilidad de enrutamiento) a un recolector central y genere alertas sobre los patrones que importan: inicios de sesión desde orígenes inesperados, fallos de autenticación repetidos, cambios de configuración fuera de las ventanas de mantenimiento.

Complemente el registro con copias de seguridad automatizadas de la configuración ante cada cambio o, al menos, a diario. Cuando un router se ve comprometido —o simplemente muere en una tormenta eléctrica— restaurar el servicio se convierte en enviar una configuración a hardware de reemplazo en lugar de una reconstrucción de memoria. Las copias de seguridad con control de versiones también le dan una comparación limpia para responder "¿qué cambió?" después de cualquier incidente.

No olvide la capa física

El hardening lógico sirve de poco si cualquiera que abra el gabinete puede restablecer de fábrica el router o conectarse a un puerto de consola. Controles físicos razonables en sitios sin personal:

• Gabinetes o envolventes con llave, con llaves o códigos registrados y rotados
• Puertos de consola deshabilitados, protegidos con contraseña u obstruidos físicamente cuando la plataforma lo permite
• Puertos Ethernet sin uso apagados y asignados a una VLAN sin salida
• Sellos antimanipulación o sensores de contacto en las envolventes, integrados a su monitoreo
• Un procedimiento documentado sobre quién puede visitar un sitio y qué puede tocar

Para concluir

Ninguno de estos controles es exótico, y ninguno requiere hardware nuevo más allá, como máximo, de un servidor de consola y un módem celular. Lo difícil es la consistencia: una plantilla de configuración estándar para routers, aplicada en cada puesta en marcha y auditada periódicamente, es lo que separa una red endurecida de una presentación endurecida. La misma disciplina se extiende hacia arriba, a la exposición a DDoS —consulte protección de la infraestructura de torres contra ataques DDoS— y al programa de seguridad WISP más amplio en la lista de verificación de ciberseguridad para WISP.

Para saber dónde se encuentran sus sitios actuales, evalúe su postura con la calculadora de puntuación de seguridad, o explore la solución de seguridad para torres y la división SmashByte Wireless en general.