Cómo limitar el acceso SSH a un router TP-Link a IPs de confianza

¿Cómo limitar el acceso SSH a un router TP-Link a IPs de confianza? Controlar quién puede entrar por SSH a tu red no es un capricho, es una capa imprescindible de seguridad. Permitir el acceso solo desde direcciones IP de confianza reduce la superficie de ataque, frena los escaneos automáticos y evita intentos de intrusión constantes desde Internet.

En esta guía práctica y extensa verás cómo hacerlo en distintos escenarios con equipos TP-Link (SMB y Omada), qué tener en cuenta con reglas ACL y listas blancas, y cómo verificar que todo está bien cerrado. Integramos métodos adicionales como TCP Wrappers, iptables y buenas prácticas para que puedas blindar tu entorno sin dejar cabos sueltos.

Por qué limitar el acceso SSH en routers TP-Link

Exponer SSH a Internet abre la puerta a barridos masivos de bots y a curiosos con malas intenciones. No es raro detectar el puerto 22 accesible en la WAN tras un escaneo, tal y como se ha observado en fallos críticos en routers TP-Link. Un simple nmap sirve para comprobar si tu IP pública tiene el 22 abierto: ejecuta en una máquina externa algo como nmap -vvv -p 22 TU_IP_PUBLICA y revisa si aparece «open ssh».

Incluso si usas claves públicas, dejar el 22 en abierto invita a más exploraciones, a probar otros puertos y a atacar servicios de gestión. La solución es clara: deniega por defecto y habilita solo desde IPs o rangos permitidos, preferiblemente fijos y controlados por ti. Si no necesitas gestión remota, desactívala por completo en la WAN.

Además de exponer puertos, hay situaciones en las que sospechar de cambios de reglas o comportamientos anómalos (por ejemplo, un cable módem que empieza a «tumbar» tráfico de salida tras un tiempo). Si notas que el ping, traceroute o la navegación no pasan del módem, revisa configuración, firmware y considera restaurar a valores de fábrica y cerrar todo lo que no uses.

Modelo mental: bloquear por defecto y crear lista blanca

La filosofía ganadora es sencilla: política por defecto de denegar y excepciones explícitas. En muchos routers TP-Link con interfaz avanzada puedes establecer en el firewall una política de entrada remota de tipo Drop, y luego permitir direcciones concretas en una lista blanca para los servicios de gestión.

En equipos que incluyen opciones de «Remote Input Policy» y «Whitelist rules» (en páginas de Network – Firewall), marca Drop en la política remota de entrada y añade en la lista blanca las IP públicas con formato CIDR X.X.X.X/XX que deben poder llegar a la configuración o a servicios como SSH/Telnet/HTTP(S). Estas entradas pueden llevar una descripción breve para que no te líes más adelante.

Es crucial entender la diferencia entre mecanismos. El port forwarding (NAT/DNAT) redirige puertos hacia máquinas LAN, mientras que las «Filtering rules» controlan el tráfico WAN→LAN o entre redes, y las «Whitelist rules» del firewall gobiernan el acceso a la propia gestión del router. Las reglas de filtrado no bloquean el acceso al propio dispositivo; para eso usa lista blanca o reglas específicas sobre la entrada hacia el router.

Para acceder a servicios internos, se crea el mapeo de puertos en NAT y luego se limita quién puede alcanzar ese mapeo desde fuera. La receta es: abrir el puerto necesario y acto seguido acotarlo con un control de acceso que deje pasar solo los orígenes autorizados y bloquee el resto.

SSH desde IPs de confianza en TP-Link SMB (ER6120/ER8411 y similares)

En routers SMB como TL-ER6120 o ER8411, el patrón habitual para publicar un servicio de la LAN (p. ej. SSH en un servidor interno) y limitarlo por IP de origen es de dos fases. Primero se abre el puerto con Servidor Virtual (NAT) y después se filtra con Control de Acceso basado en grupos de IP y tipos de servicio.

Fase 1 – Servidor Virtual: ve a Advanced → NAT → Virtual Server y crea una entrada para la interfaz WAN correspondiente. Configura el puerto externo 22 y apunta a la IP interna del servidor (por ejemplo 192.168.0.2:22). Guarda para que la regla quede en la lista. Si tu caso usa otro puerto (p. ej., has cambiado SSH a 2222), ajusta el valor en consecuencia.

Fase 2 – Tipo de servicio: entra en Preferencias → Tipo de servicio, crea un nuevo servicio llamado, por ejemplo, SSH, selecciona TCP o TCP/UDP y define el puerto de destino 22 (el rango de puertos de origen puede quedar 0–65535). Esta capa te permitirá referenciar el puerto de forma limpia en la ACL.

Fase 3 – Grupo IP: ve a Preferencias → Grupo IP → Dirección IP y añade entradas tanto para el origen permitido (p. ej. tu IP pública o un rango, nombrado «Access_Client») como para el recurso destino (p. ej. «SSH_Server» con la IP interna del servidor). Luego asocia cada dirección a su correspondiente Grupo IP dentro del mismo menú.

Fase 4 – Control de acceso: en Firewall → Control de acceso crea dos reglas. 1) Regla de Permitir: política Allow, servicio «SSH» recién definido, origen = Grupo IP «Access_Client» y destino = «SSH_Server». Ponle ID 1. 2) Regla de Bloqueo: política Block con origen = IPGROUP_ANY y destino = «SSH_Server» (o como aplique) con ID 2. Así, solo la IP o rango de confianza atravesará el NAT hacia tu SSH; el resto quedará bloqueado.

El orden de evaluación es vital. Los ID más bajos tienen prioridad, por tanto la regla Allow debe ir antes (ID menor) que la regla Block. Tras aplicar los cambios, desde la IP permitida podrás conectar a la IP WAN del router en el puerto definido, y desde otros orígenes no se llegará.

Notas de modelo/firmware: la interfaz puede variar entre hardware y versiones. TL-R600VPN requiere v4 de hardware para cubrir ciertas funciones, y en equipos distintos los menús pueden estar reubicados. Aun así, el flujo es el mismo: tipo de servicio → grupos IP → ACL con Allow y Block. No olvides guardar y aplicar para que las reglas entren en vigor.

Verificación recomendada: desde la IP autorizada, intenta ssh usuario@IP_WAN y verifica el acceso. Desde otra IP, el puerto debe quedar inaccesible (conexión que no llega o rechazada, idealmente sin banner para no dar pistas).

ACL con Omada Controller: listas, estados y escenarios de ejemplo

Si gestionas gateways TP-Link con Omada Controller, la lógica es parecida pero con más opciones visuales. Crea grupos (IP o puertos), define ACL de puerta de enlace y ordena las reglas para permitir lo mínimo necesario y denegar lo demás.

Listas y grupos: en Configuración → Perfiles → Grupos puedes crear grupos de IP (subredes o hosts, como 192.168.0.32/27 o 192.168.30.100/32) y también grupos de puertos (por ejemplo, HTTP 80 y DNS 53). Estos grupos simplifican reglas complejas al reutilizar objetos.

ACL de puerta de enlace: en Configuración → Seguridad de red → ACL añade reglas con dirección LAN→WAN, LAN→LAN o WAN→LAN según lo que quieras proteger. La política de cada regla puede ser Allow o Deny y el orden determina el resultado efectivo. Marca «Habilitar» para activarlas. Algunas versiones permiten dejar reglas preparadas y deshabilitadas.

Casos útiles (adaptables a SSH): permitir solo servicios concretos y bloquear el resto (por ejemplo, Allow DNS y HTTP y luego Deny All). Para listas blancas de gestión, crea Allow desde IPs de confianza a la «Página de administración de puerta de enlace» y después una Deny general desde las demás redes. Si tu firmware tiene opción Bidireccional, puedes generar la regla inversa de manera automática.

Estado de conexión: las ACL pueden ser con estado. Los tipos comunes son Nuevo, Establecido, Relacionado e Inválido. «Nuevo» casa el primer paquete (p. ej. SYN en TCP), «Establecido» implica tráfico bidireccional ya visto, «Relacionado» cubre conexiones dependientes (como canal de datos FTP) e «Inválido» atrapa tráfico anómalo. Lo normal es mantener la configuración por defecto salvo que necesites granularidad extra.

VLAN y segmentación: Omada y routers SMB soportan escenarios unidireccionales y bidireccionales entre VLAN. Puedes bloquear Marketing→I+D pero permitir I+D→Marketing, o bloquear ambos sentidos y, aun así, autorizar a un administrador concreto. La dirección LAN→LAN en la ACL se usa para controlar tráfico entre subredes internas.

Métodos y refuerzos adicionales: TCP Wrappers, iptables, MikroTik y firewall clásico

Además de las ACL del router, hay otras capas que conviene aplicar, especialmente si el destino SSH es un servidor Linux detrás del router. TCP Wrappers permite filtrar por IP con hosts.allow y hosts.deny en servicios compatibles (incluido OpenSSH en muchas configuraciones tradicionales).

Archivos de control: si no existen, créalos con sudo touch /etc/hosts.{allow,deny}. Buena práctica: deniega todo en hosts.deny y explícitamente permite en hosts.allow. Por ejemplo: en /etc/hosts.deny pon sshd: ALL y en /etc/hosts.allow añade sshd: 203.0.113.10, 198.51.100.0/24. Así, solo esas IPs podrán llegar al demonio SSH del servidor.

iptables a medida: si tu router o servidor te lo permite, añade reglas que solo acepten SSH desde orígenes concretos. Una regla típica sería: -I INPUT -s 203.0.113.10 -p tcp --dport 22 -j ACCEPT seguida de una política por defecto de DROP o una regla que bloquee el resto. En routers con pestaña de Custom rules podrás inyectar estas líneas y aplicar con «Save & Apply».

Buenas prácticas en MikroTik (aplicables como guía general): cambia puertos por defecto si te es viable, desactiva Telnet (usa solo SSH), usa contraseñas robustas o, mejor, autenticación por clave, limita por IP desde el firewall, activa 2FA si el equipo lo soporta, mantén firmware/RouterOS al día, deshabilita acceso desde WAN si no lo necesitas, monitoriza intentos fallidos y, si procede, aplica limitaciones de tasa de conexión para frenar fuerza bruta.

Interfaz clásica de TP-Link (firmware antiguos): entra en el panel con la IP LAN (por defecto 192.168.1.1) y credenciales admin/admin, ve a Seguridad → Firewall, habilita el filtro de IP y elige que los paquetes no especificados sigan la política deseada. Luego, en Filtrado de Direcciones IP, pulsa «Agregar nuevo» y define qué IPs pueden o no pueden usar el puerto de servicio en la WAN (para SSH, 22/tcp). Guarda cada paso. Con esto puedes aplicar una denegación general y excepciones para permitir solo IPs de confianza.

Bloquear IPs muy concretas con rutas estáticas

En algunos casos es útil bloquear salidas a IPs específicas para mejorar estabilidad con ciertos servicios (como streaming). Una forma de hacerlo en varios TP-Link es mediante Enrutamiento estático, creando rutas /32 que eviten alcanzar esos destinos o las dirijan de forma que no se consuman por la ruta por defecto (el soporte varía por firmware).

Modelos recientes: ve a la pestaña Avanzada → Red → Enrutamiento avanzado → Enrutamiento estático y pulsa «+ Agregar». Introduce «Destino de red» con la IP a bloquear, «Máscara de subred» 255.255.255.255, «Puerta de enlace predeterminada» la puerta de enlace LAN (típicamente 192.168.0.1) y «Interfaz» LAN. Marca «Permitir esta entrada» y guarda. Repite para cada IP objetivo según el servicio que quieras controlar.

Firmwares antiguos: entra en Enrutamiento avanzado → Lista de enrutamiento estático, pulsa «Agregar nuevo» y rellena los mismos campos. Activa el estado de la ruta y guarda. Consulta con el soporte de tu servicio para saber qué IPs conviene tratar, ya que pueden cambiar.

Comprobación: abre un terminal o símbolo del sistema y prueba con ping 8.8.8.8 (o la IP de destino que has bloqueado). Si ves «Tiempo de espera agotado» o «Host de destino inaccesible», el bloqueo está funcionando. Si no, revisa los pasos y reinicia el router para que apliquen todas las tablas.

Verificación, testeo y resolución de incidencias

Para validar que tu lista blanca SSH funciona, desde una IP autorizada intenta ssh usuario@IP_WAN -p 22 (o el puerto que uses) y confirma el acceso. Desde una IP no autorizada, el puerto no debe ofrecer servicio. Usa nmap -p 22 IP_WAN para comprobar el estado en caliente.

Si algo no responde como debería, revisa la prioridad de las ACL. Las reglas se procesan secuencialmente y las de menor ID ganan; una Deny por encima de tu Allow invalida la lista blanca. Comprueba también que el «Tipo de servicio» apunta al puerto correcto y que tus «Grupos IP» contienen los rangos adecuados.

Ante comportamientos sospechosos (pérdida de conectividad tras un rato, reglas que cambian solas, tráfico LAN que se cae), considera actualizar el firmware, deshabilitar servicios que no uses (administración remota web/Telnet/SSH), cambiar credenciales, revisar clonación MAC si aplica, y, en último término, restaurar a fábrica y reconfigurar con mínimos y lista blanca estricta.

Compatibilidad, modelos y notas de disponibilidad

La disponibilidad de funciones (ACL con estado, perfiles, listas blancas, edición de PVID en puertos, etc.) puede depender del modelo y versión de hardware. En algunos equipos, como TL-R600VPN, ciertas capacidades solo están presentes a partir de la v4. Las interfaces de usuario también cambian, pero el proceso base es el mismo: bloquear por defecto, definir servicios y grupos, permitir desde IPs concretas y bloquear el resto.

En el ecosistema TP-Link hay muchos equipos implicados en redes de empresa. Modelos citados por la documentación incluyen T1600G-18TS, T1500G-10PS, TL-SG2216, T2600G-52TS, T2600G-28TS, TL-SG2210P, T2500-28TC, T2700G-28TQ, T2500G-10TS, TL-SG5412F, T2600G-28MPS, T1500G-10MPS, SG2210P, S4500-8G, T1500-28TC, T1700X-16TS, T1600G-28TS, TL-SL3452, TL-SG3216, T3700G-52TQ, TL-SG2008, T1700G-28TQ, T1500-28PCT, T2600G-18TS, T1600G-28PS, T2500G-10MPS, Festa FS310GP, T1600G-52MPS, T1600G-52PS, TL-SL2428, T1600G-52TS, T3700G-28TQ, T1500G-8T, T1700X-28TQ, entre otros. Ten en cuenta que la oferta varía por región y puede que algunos no estén disponibles en tu zona.

Para estar al día, visita la página de soporte de tu producto, elige la versión de hardware correcta y consulta las notas de firmware y la ficha técnica con las mejoras más recientes. A veces las actualizaciones amplían o pulen funciones de firewall, ACL o gestión remota.

Cerrar el SSH a cal y canto salvo para IPs concretas, ordenar bien las ACL y entender qué mecanismo controla cada cosa te ahorra sustos. Con una política de denegar por defecto, listas blancas precisas y verificación regular, tu router TP-Link y los servicios tras él quedarán mucho más protegidos sin renunciar a la administración cuando la necesitas.

Artículo relacionado:

TP-Link afronta fallos críticos en routers empresariales y crece la presión regulatoria

Cristian Garcia

Apasionado de la tecnología desde pequeñito. Me encanta estar a la última en el sector y sobre todo, comunicarlo. Por eso me dedico a la comunicación en webs de tecnología y videojuegos desde hace ya muchos años. Podrás encontrarme escribiendo sobre Android, Windows, MacOS, iOS, Nintendo o cualquier otro tema relacionado que se te pase por la cabeza.