Convertir un clic en una regla temporal del cortafuegos es cómodo, y además construye un sistema de autorización que decide quién puede llegar a un servicio. Lo que emite es una dirección en lugar de una persona, y esa diferencia importa en el momento en que dos personas comparten un NAT. Limite el alcance de la concesión, confírmela de forma deliberada y haga que la caducidad signifique algo antes de construir el enlace. La decisión que tiene delante es dónde poner la frontera, no si debería existir una.

Decida qué pregunta responde la concesión

Empiece por el requisito. Si una persona concreta debe llegar al servicio y la aplicación ya autentica a esa persona, una pasarela autenticada mantiene la identidad en el punto de aplicación y no necesita ninguna admisión por dirección. Si el objetivo es un agente de compilación, un puerto de salto administrativo o un dispositivo que no puede participar en el inicio de sesión de usuarios, una concesión de dirección de alcance limitado puede ser el único control práctico disponible.

Elegir la admisión por dirección para una aplicación orientada a usuarios traslada el problema real de autorización a otro sitio, y entonces el portal hereda la culpa de una brecha que nunca cerró.

Acote la solicitud en el servidor

El navegador no debe elegir el destino, el puerto ni el prefijo. El portal resuelve el servicio a partir de sus propios registros y comprueba el derecho con una prueba en el lado del servidor, que es el mismo principio que la guía de autorización de OWASP aplica a cada solicitud. La derivación de la dirección también corresponde a la frontera protegida: cuando un proxy inverso informa de la dirección del cliente, acepte solo la cadena de proxies configurada y su tratamiento documentado de las cabeceras. Una cabecera de reenvío aportada por un visitante es una afirmación sobre la procedencia, no una prueba de ella.

Después compruebe que el portal y el servicio observan la misma fuente. El túnel dividido, un salto de proxy y IPv4 frente a IPv6 pueden dar a dos destinos dos direcciones distintas, así que una concesión activada por un camino puede no cubrir la solicitud siguiente.

Muestre la concesión antes de instalarla

Abrir un enlace debería mostrar el servicio propuesto, la fuente observada y la duración, y todavía no cambiar nada. Ese único paso convierte el enlace del correo de una acción en una propuesta, y evita que un bot de vista previa o un escáner de correo concedan acceso solo por obtenerlo.

La confirmación debería ser una solicitud que cambia el estado con las defensas habituales contra sitios cruzados y de origen. El token debería ser de un solo uso y consumirse de forma atómica en el momento en que se instala la regla, y el registro debería recoger el propietario, el servicio, la dirección, el identificador de la concesión y la caducidad sin registrar nunca el token en claro.

La entrega del token merece el mismo cuidado que la propia regla. Un enlace caducado o ya consumido que todavía produce una regla es una segunda puerta equipada con la misma llave.

La dirección se comparte incluso mientras la concesión vive

Un NAT de oficina, un NAT de operador y una salida de VPN compartida colocan cada uno a varias personas detrás de una dirección. Admitir esa dirección admite a todos los que están detrás —por lo que respecta a la siguiente frontera del servicio—, sin demostrar nada sobre quién tiene la cuenta que el servicio espera.

Quitar la regla tampoco es una desconexión universal. Las conexiones establecidas, los tokens de aplicación en caché y las sesiones de larga duración pueden sobrevivir a la regla minutos o mucho más, así que la vida útil que elija debería reflejar qué hace el servicio después de la admisión y no solo cuánto tiempo existe la regla.

Pruebe cuatro casos y ambas familias de direcciones

Una concesión vale tanto como los cuatro casos que supera: una solicitud nueva permitida, un solicitante no aprobado, una repetición del mismo enlace y la misma solicitud después de la caducidad.

Después pruebe cada familia por separado, porque la dirección de origen que observa el servicio puede diferir entre ellas.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

El resultado útil es una decisión de admisión temporal y auditable bajo la autorización normal de usuario, en lugar de una apertura permanente que lleve el nombre de quien hizo clic primero.

Artículos relacionados