Por que unha saída VPN compartida provoca avisos de inicio de sesión que vostede non causou
Un bloqueo de inicio de sesión adoita ser unha puntuación de risco, non un veredicto sobre o seu túnel. As saídas compartidas cambian quen máis entra nesa puntuación e o que lles custa.
Abra un sitio coñecido a través dunha VPN e reciba un desafío adicional, e a explicación tentadora é que o túnel foi detectado. Detectouse algo, pero non era vostede. O sitio puntuou un conxunto de sinais, unha das cales é o enderezo de orixe, e ese enderezo compártese con descoñecidos que quizais xeraban inicios de sesión fallidos un minuto antes. Ler a decisión como un veredicto sobre a súa conexión malinterpreta para que serve a puntuación.
Que pode e que non pode resolver un enderezo de orixe
Un enderezo IP describe unha ruta pola rede nun momento dado. Non identifica a unha persoa, un dispositivo nin sequera unha soa conta, e con NAT de operador ou un grupo de VPN ocupado pode estar diante de miles de sesións non relacionadas ao mesmo tempo. Un sitio que trata o enderezo como unha identidade en realidade trátao como unha reputación, que é unha afirmación estatística e non un feito.
Dúas persoas poden compartir unha saída e producir probas opostas: unha inicia sesión con éxito cun segundo factor, a outra proba corenta contrasinais. O enderezo é idéntico, así que ningunha regra baseada só no enderezo pode distinguilas, e calquera resposta que active aplícase a ambas.
Iso non é un argumento para ignorar os enderezos. É un argumento para lembrar que mide o sinal, porque a maior parte do comportamento sorprendente arredor dos inicios de sesión por VPN vén de aplicar un control coa granularidade incorrecta, non dunha observación incorrecta.
Por que bloquear a saída castiga a descoñecidos
Un bloqueo a nivel de enderezo é barato de implementar e caro de apuntar. O seu radio de acción é cada sesión detrás dese enderezo, e por iso o comportamento de enderezos compartidos e NAT ten a súa propia historia na documentación operativa: o mesmo razoamento aparece no traballo da IETF sobre enderezos de orixe compartidos e os efectos colaterais do filtrado baseado en enderezo.
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
Considere os dous fallos que crea un bloqueo. A un cliente lexítimo detrás da mesma saída négaselle o servizo e abre unha incidencia de soporte que custa máis que o abuso. Un atacante real móvese á seguinte saída nun grupo de miles e continúa, sen ter gastado nada máis que unha reconexión.
A proporcionalidade é o paso que falta. Os inicios de sesión fallidos repetidos, unha ráfaga de solicitudes automatizadas e unha violación de permisos autenticada son tres sucesos diferentes, e só o segundo é plausiblemente un problema con forma de enderezo. Aplicar a mesma prohibición de rede a todo o sitio aos tres é como un control de seguridade se converte nunha cola de soporte.
Pon a decisión onde está a evidencia
Os controis a nivel de conta seguen a conta a través dos enderezos, o que coincide coa entidade que realmente lle importa. A limitación de velocidade, os períodos de espera tras fallos repetidos e a autenticación escalonada para accións sensibles operan todos sobre a conta ou a acción, non sobre a ruta de rede. Iso encaixa mellor coa entidade que realmente protexe. Tamén elimina o incentivo do atacante a buscar un enderezo de saída novo.
A guía de autenticación do NIST trata estes elementos como entradas dunha avaliación de risco e enumera o enderezo, a xeolocalización e o momento da solicitude entre os sinais, que é exactamente o marco que convén tomar prestado: un sinal informa unha decisión, non substitúe un autenticador. Lea esa lista como entradas, non como un menú de cousas que prohibir. O autenticador segue facendo a proba, e os outros sinais só deciden canta fricción poñer ao seu redor.
Dúas restricións de deseño evitan que o enfoque a nivel de conta se converta na súa propia caída. Os límites de velocidade necesitan unha vía de revisión segura para que un usuario poida informar dunha clasificación errónea sen publicar credenciais, e os desafíos escalonados non deben poder responderse cun contrasinal nin cun código dun só uso entregado a un contacto de soporte non verificado.
Como se ve desde fóra unha política xusta
Anote que decisión respalda cada control e logo comprobe que a granularidade do control coincide. Os controis de enderezo responden preguntas sobre o tráfico dunha rede; os controis de conta responden preguntas sobre unha conta; os eventos de aplicación responden preguntas sobre o comportamento tras a autenticación. Unha política que nomea os tres é auditable, e unha que só nomea tráfico VPN non o é.
Logo mida o resultado en lugar do número de regras. Os intentos non autorizados deberían baixar, os usuarios lexítimos deberían conservar unha vía soportada, e o número de contactos de soporte por cada mil inicios de sesión non debería subir. Un bloqueo que mellora o primeiro número mentres arruína os outros dous moveu o problema, non o resolveu.
Aceptar conexións VPN e aplicar controis de abuso son obxectivos compatibles. A versión que funciona trata o enderezo de orixe como unha entrada entre varias, aplica o control máis estreito que encaixa coa evidencia e deixa unha vía honesta para a persoa que foi mal clasificada. A versión que falla trata un enderezo como sospeitoso e chámao política.