Filtrado de puertos y protección perimetral

Todos los servidores deben exponer únicamente los servicios necesarios para su función. En Occentus establecemos como criterio de protección perimetral denegar por defecto las conexiones entrantes y autorizar expresamente las que sean necesarias. El tráfico dirigido a puertos no autorizados se descartará mediante DROP, sin emitir una respuesta de rechazo.

Esta política se aplica a SSH y al resto de puertos TCP y UDP, tanto en IPv4 como en IPv6. Los servicios públicos que deban responder, por ejemplo una web, y el tráfico de control necesario para el funcionamiento de la red tendrán siempre sus excepciones documentadas.

Cómo deben estar accesibles

Cada autorización debe identificar destino, puerto, protocolo, origen permitido, finalidad, responsable y fecha de revisión o caducidad. No debe autorizarse una red extensa cuando basta con una dirección concreta. Si un proveedor necesita acceso temporal, se establecerá una ventana de mantenimiento y se retirará el permiso al finalizar.

El control debe cubrir el cortafuegos perimetral, las reglas del proveedor cloud y el propio servidor. También deben revisarse NAT, balanceadores, contenedores y cualquier vía alternativa de publicación. El tráfico saliente y las comunicaciones entre servidores necesitan una política propia basada en los flujos necesarios; esta guía incluye una plantilla básica de filtrado de entrada, no una configuración completa de toda la red.

Puerto abierto, cerrado y filtrado

Un servicio accesible puede aparecer como abierto. Cuando no hay un proceso escuchando, el sistema puede responder y el puerto aparecer como cerrado. Desactivar SSH no equivale, por sí solo, a implantar el filtrado requerido.

REJECT bloquea el tráfico enviando una respuesta de rechazo; DROP lo descarta sin esa respuesta. Ambos pueden impedir el acceso, pero para los puertos no autorizados de nuestra política perimetral se requiere DROP. La ventaja principal de seguridad procede de impedir que el tráfico llegue al servicio; el descarte silencioso evita además respuestas explícitas a esos intentos. No convierte al servidor en invisible ni sustituye una protección frente a DDoS.

La etiqueta de un escáner no demuestra por sí sola que exista una regla DROP: puede haber filtrado intermedio o pérdidas. En UDP, la ausencia de respuesta puede producir el resultado open|filtered. Deben contrastarse el escaneo, las reglas efectivas y sus contadores.

Por qué protegemos especialmente SSH

SSH proporciona administración remota y, según la configuración, transferencia de archivos y túneles. Restringir sus orígenes limita la exposición a intentos de autenticación y a fallos que puedan explotarse antes de iniciar sesión. Una clave robusta no evita por sí sola una vulnerabilidad previa a la autenticación.

Estos ejemplos no constituyen un inventario exhaustivo ni demuestran que una máquina concreta sea vulnerable. Las distribuciones pueden incorporar correcciones sin cambiar la versión principal mostrada en el banner. Se debe comprobar el paquete instalado, los avisos del mantenedor y su soporte, y aplicar las actualizaciones correspondientes a servidor, clientes y agentes. Por ejemplo, en agosto de 2026, el equipo de OpenSSH explicó que estaba recibiendo numerosos informes asistidos por IA y acelerando las publicaciones de correcciones. Advirtió asimismo que muchos informes no tenían impacto de seguridad en escenarios realistas. Notas de OpenSSH 10.5.

Nuestra conclusión operativa frente a este, como a otros servicios administrativos, es reducir los servicios alcanzables para poder actualizar con diligencia, y verificar la exposición periódicamente. La automatización masiva ya existía antes de la IA, solo que ésta puede facilitar y acelerar partes del trabajo ofensivo.

Marco normativo

El filtrado forma parte de un conjunto de medidas técnicas y organizativas. Su aplicación debe ajustarse al riesgo, a los servicios prestados y al ámbito normativo de cada entidad.

Plantilla básica de filtrado IPv4

La siguiente configuración utiliza el formato de iptables-restore, evita una secuencia de vaciado seguida de políticas ACCEPT y establece DROP por defecto en INPUT y FORWARD.

Alcance: servidor independiente con direccionamiento IPv4 estático, sin función de router y sin reglas gestionadas por Docker, Kubernetes, UFW, firewalld u otro orquestador. Sustituye la tabla filter IPv4; no debe cargarse sobre configuraciones existentes sin integrarlas previamente. Si hay NAT, contenedores o reenvío, se requiere una adaptación específica.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Trafico local del propio equipo.
-A INPUT -i lo -j ACCEPT

# Descartar paquetes invalidos.
-A INPUT -m conntrack --ctstate INVALID -j DROP

# SSH: solo origenes autorizados, incluidas sesiones existentes.
-A INPUT -p tcp -s <IP_O_RED_ADMIN_IPV4_CIDR> --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -m comment --comment "SSH autorizado" -j ACCEPT
-A INPUT -p tcp --dport 22 -j DROP

# Trafico de retorno de comunicaciones permitidas.
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Mantener UNICAMENTE si el servidor publica estos servicios web.
-A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m comment --comment "HTTP publico" -j ACCEPT
-A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m comment --comment "HTTPS publico" -j ACCEPT

# Ping de diagnostico: solo desde origenes autorizados.
-A INPUT -p icmp --icmp-type echo-request -s <IP_O_RED_MONITORIZACION_IPV4_CIDR> -j ACCEPT

# Resto de entradas y reenvios: DROP por la politica de cadena.
COMMIT

El bloqueo de SSH se coloca antes de la aceptación general de conexiones establecidas. Así, una sesión SSH de un origen no autorizado no queda permitida por esa regla general. Es imprescindible incluir el origen de administración real antes del cambio; de lo contrario, se perderá también la sesión actual.

La excepción ESTABLISHED,RELATED permite tráfico de retorno y mensajes ICMP relacionados, necesarios entre otras cosas para diagnóstico y descubrimiento de MTU. No habilitar ayudantes de seguimiento de protocolos innecesarios. Las conexiones preexistentes de otros servicios pueden continuar al aplicar el cambio: si se exige revocación inmediata, deben revisarse sus estados de conexión de forma selectiva durante la intervención.

OUTPUT ACCEPT mantiene las salidas para esta plantilla básica. No representa una política de salida de mínimo privilegio. Entornos que la requieran deben definir destinos y servicios de salida autorizados, incluidos DNS, NTP, actualizaciones, copias y monitorización. Añadir también las excepciones necesarias si se utiliza DHCP, VPN u otros servicios no contemplados.

IPv6 debe protegerse por separado

Una regla IPv4 no protege IPv6. Antes de considerar resuelto un hallazgo hay que revisar todas las direcciones publicadas, incluidos los registros AAAA, y configurar el cortafuegos IPv6 con los mismos permisos de aplicación.

Esta segunda plantilla, reglas.v6, se limita a un servidor con IPv6 estática y ruta predeterminada configurada estáticamente. Permite los mensajes de error ICMPv6 y el descubrimiento de vecinos necesarios para ese escenario. Debe adaptarse con el proveedor si utiliza SLAAC, anuncios de router, DHCPv6 o multicast; no debe aplicarse sin esa revisión.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -i lo -j ACCEPT

# ICMPv6 esencial: errores y descubrimiento de vecinos.
-A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT
-A INPUT -i <INTERFAZ_RED> -p ipv6-icmp --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -i <INTERFAZ_RED> -p ipv6-icmp --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -m conntrack --ctstate INVALID -j DROP

-A INPUT -p tcp -s <IP_O_RED_ADMIN_IPV6_CIDR> --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -m comment --comment "SSH autorizado" -j ACCEPT
-A INPUT -p tcp --dport 22 -j DROP

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Mantener solo si estos servicios deben publicarse tambien en IPv6.
-A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 128 -s <IP_O_RED_MONITORIZACION_IPV6_CIDR> -j ACCEPT
COMMIT

No debe bloquearse indiscriminadamente ICMPv6: puede romper la conectividad, la resolución de vecinos y el descubrimiento de MTU. Permitir ese tráfico de control no equivale a abrir puertos de aplicación. Véanse las recomendaciones IETF para filtrado de ICMPv6, RFC 4890.

Si no se va a prestar servicio por IPv6, su desactivación debe ser explícita y verificada en el sistema y en la infraestructura. Eliminar un registro AAAA no desactiva la conectividad IPv6 existente.

Medidas complementarias y seguimiento

Mantener SSH y el sistema actualizados, usar claves o certificados bien gestionados, incorporar MFA donde proceda, restringir privilegios y revisar registros de autenticación. Deshabilitar el acceso directo de root, la autenticación por contraseña y los reenvíos innecesarios cuando la operativa lo permita y tras verificar una alternativa funcional. Cambiar el número de puerto no sustituye el filtrado.

Durante nuestras revisiones rutinarias, si detectamos un servicio de administración expuesto, comunicaremos el hallazgo y ayudaremos a revisar su configuración. Si continúa abierto en las siguientes comprobaciones, enviaremos un recordatorio a los pocos días. Un puerto cerrado que todavía responda también requiere revisión para ajustarse a esta política.

Para solicitar un acceso, indica el servidor, puerto, protocolo, IP o rango de origen, finalidad y duración necesaria. No es necesario publicar esos datos: se gestionarán a través del canal de soporte.

Recomendamos complementar las comprobaciones con nuestra plataforma Edgewatch para revisar la exposición externa de activos propios o autorizados. El servicio es gratuito hasta 10 activos expuestos y ayuda a detectar y modelar nuestra exposición.

En caso de duda o necesitar ayuda, contacta con nuestro soporte. Os ayudaremos a definir los accesos necesarios y a verificar que el filtrado funciona sin interrumpir los servicios legítimos.

#!/bin/bash
 
# 1. Limpiar reglas anteriores y restablecer contadores
iptables -F
iptables -X
iptables -Z
 
# 2. Establecer políticas por defecto
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
 
# 3. Permitir tráfico de la interfaz local (Loopback)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
 
# 4. Permitir conexiones ya establecidas y relacionadas
# Evita que se corten tus conexiones actuales y permite el tráfico de vuelta
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 
# =========================================================================
# 5. PUERTO 22 (SSH) - SOLO PARA IPs AUTORIZADAS
# =========================================================================
 
iptables -I INPUT 1 -p tcp -s 192.168.0.1/32 --dport 22 -m comment --comment "Motivo por el que se autoriza" -j ACCEPT

 
# =========================================================================
# 6. PUERTOS WEB (80 y 443) - EXPUESTOS
# =========================================================================
iptables -A INPUT -p tcp --dport 80 -m comment --comment "Web HTTP" -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m comment --comment "Web HTTPS" -j ACCEPT
 
# (Opcional) Permitir ping (ICMP) para diagnóstico, filtrado.
iptables -A INPUT -p icmp --icmp-type echo-request -s 192.168.0.1/32  -m comment --comment "Ping solo desde xxx" -j ACCEPT
 
# =========================================================================
# 7. BLOQUEAMOS RESTO
# =========================================================================
 
iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable