Abra un sitio conocido a través de una VPN y reciba un desafío adicional, y la explicación tentadora es que el túnel fue detectado. Algo se detectó, pero no era usted. El sitio puntuó un conjunto de señales, una de las cuales es la dirección de origen, y esa dirección se comparte con desconocidos que quizá generaban inicios de sesión fallidos un minuto antes. Leer la decisión como un veredicto sobre su conexión malinterpreta para qué sirve la puntuación.

Qué puede y qué no puede resolver una dirección de origen

Una dirección IP describe una ruta por la red en un momento dado. No identifica a una persona, un dispositivo ni siquiera una sola cuenta, y con NAT de operador o un grupo de VPN ocupado puede estar frente a miles de sesiones no relacionadas al mismo tiempo. Un sitio que trata la dirección como una identidad en realidad la trata como una reputación, que es una afirmación estadística y no un hecho.

Dos personas pueden compartir una salida y producir pruebas opuestas: una inicia sesión con éxito con un segundo factor, la otra prueba cuarenta contraseñas. La dirección es idéntica, así que ninguna regla basada solo en la dirección puede distinguirlas, y cualquier respuesta que active se aplica a ambas.

Eso no es un argumento para ignorar las direcciones. Es un argumento para recordar qué mide la señal, porque la mayor parte del comportamiento sorprendente en torno a los inicios de sesión por VPN proviene de aplicar un control con la granularidad equivocada, no de una observación equivocada.

Por qué bloquear la salida castiga a desconocidos

Un bloqueo a nivel de dirección es barato de implementar y caro de apuntar. Su radio de acción es cada sesión detrás de esa dirección, y por eso el comportamiento de direcciones compartidas y NAT tiene su propia historia en la documentación operativa: el mismo razonamiento aparece en el trabajo de la IETF sobre direcciones de origen compartidas y los efectos colaterales del filtrado basado en dirección.

SignalWhat it provides evidence aboutWhat it cannot settle
Source address and its reputationThe network path, and how that path behaved recently for othersWhich account or person is behind the request
Authenticator resultWhether the account claim was proved at the required strengthWhether the account's owner initiated it
Request timing and volumeWhether the pattern looks automated or burst-likeWhether the intent was malicious or a shared client
Application event historyWhat this account has done while signed inAnything about requests that never authenticated

Considere los dos fallos que crea un bloqueo. A un cliente legítimo detrás de la misma salida se le niega el servicio y abre un ticket de soporte que cuesta más que el abuso. Un atacante real se traslada a la siguiente salida de un grupo de miles y continúa, sin haber gastado nada más que una reconexión.

La proporcionalidad es el paso que falta. Los inicios de sesión fallidos repetidos, una ráfaga de solicitudes automatizadas y una violación de permisos autenticada son tres sucesos diferentes, y solo el segundo es plausiblemente un problema con forma de dirección. Aplicar la misma prohibición de red a todo el sitio a los tres es como un control de seguridad se convierte en una cola de soporte.

Ponga la decisión donde vive la evidencia

Los controles a nivel de cuenta siguen la cuenta a través de las direcciones, lo que coincide con la entidad que realmente le importa. La limitación de velocidad, los periodos de espera tras fallos repetidos y la autenticación escalonada para acciones sensibles operan todos sobre la cuenta o la acción, no sobre la ruta de red. Eso encaja mejor con la entidad que realmente protege. También elimina el incentivo del atacante a buscar una dirección de salida nueva.

La guía de autenticación del NIST trata estos elementos como entradas de una evaluación de riesgo y enumera la dirección, la geolocalización y el momento de la solicitud entre las señales, que es exactamente el marco que conviene tomar prestado: una señal informa una decisión, no sustituye a un autenticador. Lea esa lista como entradas, no como un menú de cosas que prohibir. El autenticador sigue haciendo la prueba, y las otras señales solo deciden cuánta fricción poner a su alrededor.

Dos restricciones de diseño evitan que el enfoque a nivel de cuenta se convierta en su propia caída. Los límites de velocidad necesitan una vía de revisión segura para que un usuario pueda informar de una clasificación errónea sin publicar credenciales, y los desafíos escalonados no deben poder responderse con una contraseña ni con un código de un solo uso entregado a un contacto de soporte no verificado.

Cómo se ve desde fuera una política justa

Anote qué decisión respalda cada control y luego compruebe que la granularidad del control coincide. Los controles de dirección responden preguntas sobre el tráfico de una red; los controles de cuenta responden preguntas sobre una cuenta; los eventos de aplicación responden preguntas sobre el comportamiento tras la autenticación. Una política que nombra los tres es auditable, y una que solo nombra tráfico VPN no lo es.

Luego mida el resultado en lugar del número de reglas. Los intentos no autorizados deberían bajar, los usuarios legítimos deberían conservar una vía soportada, y el número de contactos de soporte por cada mil inicios de sesión no debería subir. Un bloqueo que mejora el primer número mientras arruina los otros dos ha movido el problema, no lo ha resuelto.

Aceptar conexiones VPN y aplicar controles de abuso son objetivos compatibles. La versión que funciona trata la dirección de origen como una entrada entre varias, aplica el control más estrecho que encaja con la evidencia y deja una vía honesta para la persona que fue mal clasificada. La versión que falla trata una dirección como sospechosa y lo llama política.

Artículos relacionados