Per què una sortida VPN compartida provoca avisos d’inici de sessió que no has causat
Un bloqueig d’inici de sessió sol ser una puntuació de risc, no un veredicte sobre el teu túnel. Les sortides compartides canvien qui més entra en aquesta puntuació i què els costa.
Obriu un lloc conegut a través d’una VPN i rebeu un repte addicional, i l’explicació temptadora és que s’ha detectat el túnel. S’ha detectat alguna cosa, però no éreu vosaltres. El lloc ha puntuat un conjunt de senyals, un dels quals és l’adreça d’origen, i aquesta adreça es comparteix amb desconeguts que podrien haver generat inicis de sessió fallits un minut abans. Llegir la decisió com un veredicte sobre la vostra connexió és malinterpretar per a què serveix la puntuació.
Què pot i què no pot resoldre una adreça d’origen
Una adreça IP descriu un camí per la xarxa en un moment concret. No identifica una persona, un dispositiu ni tan sols un sol compte, i amb NAT d’operador o una piscina VPN ocupada pot encapçalar milers de sessions no relacionades alhora. Un lloc que tracta l’adreça com una identitat en realitat la tracta com una reputació, que és una afirmació estadística i no un fet.
Dues persones poden compartir una sortida i produir proves oposades: una inicia sessió amb èxit amb un segon factor, l’altra prova quaranta contrasenyes. L’adreça és idèntica, així que qualsevol regla basada només en l’adreça no les pot distingir, i qualsevol resposta que activi s’aplica a totes dues.
Això no és un argument per ignorar les adreces. És un argument per recordar què mesura el senyal, perquè la major part del comportament sorprenent al voltant dels inicis de sessió per VPN prové d’aplicar un control a la granularitat equivocada, no d’una observació equivocada.
Per què bloquejar la sortida castiga desconeguts
Un bloqueig a nivell d’adreça és barat d’implementar i car d’apuntar. El seu radi d’acció és cada sessió darrere d’aquesta adreça, i per això el comportament d’adreces compartides i NAT té la seva pròpia història en la documentació operativa: el mateix raonament apareix en el treball de l’IETF sobre adreces d’origen compartides i els efectes col·laterals del filtratge basat en adreça.
| 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 |
Penseu en els dos fracassos que crea un bloqueig. Un client legítim darrere de la mateixa sortida rep un rebuig de servei i obre un tiquet de suport que costa més que l’abús. Un atacant real es mou a la següent sortida d’una piscina de milers i continua, sense haver gastat res més que una reconnexió.
La proporcionalitat és el pas que falta. Els inicis de sessió fallits repetits, una allau de sol·licituds automatitzades i una violació de permisos autenticada són tres esdeveniments diferents, i només el segon és plausiblement un problema amb forma d’adreça. Aplicar la mateixa prohibició de xarxa a tot el lloc als tres és com un control de seguretat es converteix en una cua de suport.
Poseu la decisió on viu l’evidència
Els controls a nivell de compte segueixen el compte a través de les adreces, cosa que coincideix amb l’entitat que realment us importa. La limitació de velocitat, els períodes d’espera després de fracassos repetits i l’autenticació esglaonada per a accions sensibles operen sobre el compte o l’acció, no sobre el camí de xarxa. Això encaixa millor amb l’entitat que realment protegiu. També elimina l’incentiu de l’atacant de buscar una adreça de sortida nova.
La guia d’autenticació del NIST tracta aquests elements com a entrades d’una avaluació de risc i enumera l’adreça, la geolocalització i el moment de la sol·licitud entre els senyals, que és exactament l’enquadrament que cal manllevar: un senyal informa una decisió, no substitueix un autenticador. Llegiu aquesta llista com a entrades, no com un menú de coses a prohibir. L’autenticador continua fent la prova, i els altres senyals només decideixen quanta fricció cal posar al seu voltant.
Dues restriccions de disseny eviten que l’enfocament a nivell de compte es converteixi en la seva pròpia caiguda. Els límits de velocitat necessiten un camí de revisió segur perquè un usuari pugui informar d’una classificació errònia sense publicar credencials, i els reptes esglaonats no s’han de poder respondre amb una contrasenya ni amb un codi d’un sol ús lliurat a un contacte de suport no verificat.
Com es veu des de fora una política justa
Anoteu quina decisió recolza cada control i després comproveu que la granularitat del control hi coincideixi. Els controls d’adreça responen preguntes sobre el trànsit d’una xarxa; els controls de compte responen preguntes sobre un compte; els esdeveniments d’aplicació responen preguntes sobre el comportament després de l’autenticació. Una política que anomena els tres és auditable, i una que només anomena trànsit VPN no ho és.
Després mesureu el resultat i no el nombre de regles. Els intents no autoritzats haurien de baixar, els usuaris legítims haurien de conservar un camí suportat, i el nombre de contactes de suport per cada mil inicis de sessió no hauria d’augmentar. Un bloqueig que millora el primer número mentre trenca els altres dos ha mogut el problema, no l’ha resolt.
Acceptar connexions VPN i aplicar controls d’abús són objectius compatibles. La versió que funciona tracta l’adreça d’origen com una entrada entre diverses, aplica el control més estret que encaixa amb l’evidència i deixa una via honesta per a la persona mal classificada. La versió que falla tracta una adreça com un sospitós i en diu política.