Tu servidor tiene que recibir a tus clientes, pero tampoco hace falta que organice una jornada de puertas abiertas. Y menos en la entrada de administración, donde algunos visitantes vienen sin cita y con demasiado interés por ver qué hay dentro.
La web puede dar la bienvenida al público. Para la base de datos, el panel de gestión y el acceso SSH, mejor una lista de invitados. Parece una obviedad, pero aquí estamos encarando la recta final del 2026 y seguimos hablando de lo mismo.
En Occentus revisamos la exposición de los servicios de nuestros clientes periódicamente. Para nosotros es tan básico e importante que incluso hemos desarrollado Edgewatch, toda una plataforma de ciberseguridad sobre esa premisa; para automatizar la vigilancia del perímetro. El criterio es sencillo y parece un lema de los teleñecos: permitir lo necesario y filtrar el resto. Hoy vamos a centrarnos en reiterar porqué un puerto SSH no debe estar abierto indiscriminadamente a internet. Lo explicamos en nuestra Política de filtrado de puertos y protección perimetral básica, con ejemplos de configuración y pasos para comprobar el resultado.
SSH es una herramienta esencial para administrar servidores. Precisamente por eso, conviene que solo puedan alcanzarlo los orígenes autorizados, preferiblemente a través de una VPN o un bastión.
«Pero usamos claves, no contraseñas» es una buena respuesta. Aunque no resuelve todos los riesgos.
Algunas vulnerabilidades pueden explotarse antes de que el servidor llegue a preguntar quién eres. En 2024, regreSSHion —CVE-2024-6387— mostró el riesgo de ejecución remota en determinadas versiones y entornos de OpenSSH. En febrero de 2025, CVE-2025-26466 permitió atacar la disponibilidad de sshd antes de la autenticación. Ambos problemas recibieron correcciones.
Las correcciones han continuado en 2026, con fallos de distinto alcance en servidores, clientes y agentes. No todos afectan a cualquier instalación ni tienen la misma gravedad: importan la versión, la configuración y los parches del distribuidor.
Por eso combinamos tres medidas: restringir el acceso, mantener el software actualizado y utilizar una autenticación robusta. Cada una cubre riesgos que las otras no resuelven por completo.
Los ataques automatizados llevan años recorriendo Internet. No estaban esperando a que apareciera un chatbot. Pero es cierto que la IA puede facilitar la combinación e industrialización de tareas como reconocimiento, análisis de vulnerabilidades y preparación de ataques. ENISA, la Agencia de la Unión Europea para la Ciberseguridad, advierte de que la IA está acortando el tiempo entre descubrir una vulnerabilidad y aprovecharla para atacar, aumentando la presión sobre los sistemas antiguos o sin soporte. Vamos, que el «ya lo actualizaré el lunes» tiene cada vez menos margen. Evaluación de ENISA sobre ciberseguridad e IA, julio de 2026.
La conclusión práctica es sencilla: cuanto menos expongamos innecesariamente, menos oportunidades ofrecemos.
«Cerrado» y «filtrado» no son exactamente lo mismo
Cuando detectamos un SSH abierto a internet sin restricciones, pedimos limitarlo a las direcciones IP que realmente necesitan acceder. Para el resto del tráfico dirigido a ese servicio, nuestra política requiere DROP: descartar sin enviar una respuesta de rechazo.
Un puerto cerrado puede seguir contestando a los escaneos. Sería algo parecido a responder al telefonillo para decir que no hay nadie. Con DROP, el cortafuegos descarta ese intento sin contestar.
La comparación tiene sus límites: el servidor no se vuelve invisible y DROP no sustituye una protección frente a DDoS. La protección principal consiste en impedir que el tráfico no autorizado llegue al servicio.
Aplicamos el mismo criterio al resto de puertos, con las excepciones necesarias para cada función. Una web pública debe responder; una base de datos interna normalmente no debe presentarse a todo Internet.
IPv4 e IPv6. Cerrar una puerta y olvidarse de cerrar la otra. Un plan sin fisuras.
IPv6 puede convertirse en una vía de entrada cuando protegemos IPv4 y nos olvidamos de aplicar controles equivalentes a IPv6. Un servicio como SSH puede quedar restringido por una vía y seguir accesible por la otra: los atacantes pueden aprovechar esa diferencia para alcanzar servicios que creíamos protegidos. No es que IPv6 sea menos seguro; es que también necesita reglas de filtrado. La revisión debe cubrir ambos protocolos, preservando el tráfico de control necesario para que la red funcione.
Si te avisamos, también estamos para ayudarte
Durante nuestras revisiones rutinarias, si encontramos un servicio de administración expuesto sin las restricciones necesarias, comunicamos el hallazgo y ayudamos al cliente a revisar su configuración. Si es una máquina gestionada por nosotros, lo filtramos de oficio, manteniendo los accesos autorizados necesarios.
Si en las siguientes comprobaciones el puerto continúa abierto sin restricciones, enviaremos un recordatorio a los pocos días. No es que le hayamos cogido cariño al ticket: el objetivo es que la exposición quede resuelta, aunque sea por cansinos.
La intervención debe hacerse con cuidado, conservando una vía de recuperación y comprobando que los accesos autorizados funcionan. La seguridad también consiste en que el administrador pueda seguir administrando. Si tienes dudas, consulta con nuestro equipo de soporte qué direcciones o rangos debes autorizar si necesitamos acceder a tu servidor.
NIS2: controles concretos y obligatorios
La Directiva (UE) 2022/2555 (NIS2), en su artículo 21 contempla gestión de vulnerabilidades, control de acceso, gestión de activos y evaluación de la eficacia de las medidas. Para las entidades incluidas en su ámbito, estas actuaciones forman parte de una gestión del riesgo más amplia.
En concreto el Reglamento 2024/2690, anexo 6.7 concreta, para determinados proveedores digitales, medidas como impedir comunicaciones innecesarias, controlar el acceso remoto y desactivar servicios que no se utilizan. Su alcance incluye determinados servicios cloud, centros de datos y servicios gestionados. Por su parte, en España, el Esquema Nacional de Seguridad (ENS) nos exige protección perimetral y autorización previa de los flujos para los sistemas sujetos a él. También deben considerarse las obligaciones de seguridad de redes y de protección de datos que correspondan a cada organización.
Configurar un cortafuegos no equivale a cumplir toda NIS2, ni estas normas imponen universalmente una regla literal DROP. Nuestra documentación distingue el marco aplicable de nuestra política técnica y recoge las fuentes consultadas sobre la transposición española.
En Occentus ayudamos a avanzar con actuaciones verificables: detectar exposición, revisar permisos, corregir configuraciones y comprobar resultados.
La configuración interna cuenta cómo esperamos que funcione la protección. Una comprobación externa ayuda a ver qué está realmente accesible.
En el caso de que no contéis con nuestro servicio de gestión, recomendamos Edgewatch como complemento para revisar la exposición de activos propios o autorizados y detectar proactivamente hallazgos que merecen atención y priorización. Os recordamos que el Free Tier incluye hasta 10 activos, escaneos automáticos mensuales y tres meses de retención sin coste alguno.
Consulta nuestra política de filtrado y sus ejemplos de configuración. Si necesitas ayuda, habla con nosotros: revisaremos qué conexiones necesita tu servidor y cuáles pueden quedarse fuera de la lista de invitados.