Varför en delad VPN-utgång utlöser inloggningsvarningar du inte orsakade
En inloggningsblockering är oftast en riskpoäng, inte en dom över din tunnel. Delade utgångar ändrar vilka andra som ingår i den poängen och vad det kostar dem.
Öppna en välkänd webbplats via en VPN och få en extra utmaning, och den lockande förklaringen är att tunneln upptäcktes. Något upptäcktes, men det var inte du. Webbplatsen poängsatte en uppsättning signaler, varav en är källadressen, och den adressen delas med främlingar som kanske genererade misslyckade inloggningar en minut tidigare. Att läsa beslutet som en dom över din anslutning missförstår vad poängen är till för.
Vad en källadress kan och inte kan avgöra
En IP-adress beskriver en väg genom nätverket vid en viss tidpunkt. Den identifierar inte en person, en enhet eller ens ett enda konto, och med carrier-grade NAT eller en upptagen VPN-pool kan den stå framför tusentals orelaterade sessioner samtidigt. En webbplats som behandlar adressen som en identitet behandlar den egentligen som ett rykte, vilket är ett statistiskt påstående och inte ett faktum.
Två personer kan dela en utgång och producera motsatta bevis: den ena loggar in med en andra faktor, den andra provar fyrtio lösenord. Adressen är identisk, så ingen regel som bara bygger på adressen kan skilja dem, och vilken reaktion den än utlöser gäller för båda.
Det är inte ett argument för att ignorera adresser. Det är ett argument för att komma ihåg vad signalen mäter, eftersom det mesta överraskande beteendet kring VPN-inloggningar kommer från en kontroll som tillämpas på fel detaljnivå, snarare än från en felaktig observation.
Varför blockering av utgången straffar främlingar
En blockering på adressnivå är billig att införa och dyr att rikta. Dess radie är varje session bakom den adressen, och därför har delade adresser och NAT-beteende sin egen historia i den operativa dokumentationen: samma resonemang förekommer i IETF-arbetet om delade källadresser och biverkningarna av adressbaserad filtrering.
| 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 |
Tänk på de två misslyckanden en blockering skapar. En legitim kund bakom samma utgång nekas tjänst och skickar in en supportbiljett som kostar mer än missbruket. En faktisk angripare flyttar till nästa utgång i en pool på tusentals och fortsätter, utan att ha spenderat något annat än en återanslutning.
Proportionalitet är det saknade steget. Upprepade misslyckade inloggningar, en våg av automatiserade förfrågningar och en autentiserad behörighetsöverträdelse är tre olika händelser, och bara den andra är sannolikt ett adressformat problem. Att tillämpa samma webbplatsövergripande nätverksspärr på alla tre är hur en säkerhetskontroll blir en supportkö.
Lägg beslutet där bevisen finns
Kontroller på kontonivå följer kontot över adresser, vilket motsvarar den enhet du faktiskt bryr dig om. Hastighetsbegränsning, väntetider efter upprepade misslyckanden och stegvis autentisering för känsliga åtgärder verkar alla på kontot eller åtgärden snarare än på nätverksvägen. Det passar bättre med den enhet du faktiskt skyddar. Det tar också bort angriparens incitament att leta efter en ny utgångsadress.
NIST:s riktlinjer för autentisering behandlar dessa som indata till en riskbedömning och listar adress, geolokalisering och begäranstid bland signalerna, vilket är precis det ramverk som är värt att låna: en signal informerar ett beslut, den ersätter inte en autentiserare. Läs den listan som indata, inte som en meny av saker att förbjuda. Autentiseraren gör fortfarande beviset, och de andra signalerna avgör bara hur mycket friktion som läggs runt den.
Två designbegränsningar hindrar att kontonivåansatsen blir sitt eget avbrott. Hastighetsgränser behöver en säker granskningsväg så att en användare kan rapportera en felaktig klassificering utan att publicera autentiseringsuppgifter, och stegvisa utmaningar får inte kunna besvaras med ett lösenord eller en engångskod som getts till en overifierad supportkontakt.
Hur en rättvis policy ser ut utifrån
Skriv ner vilket beslut varje kontroll stöder och kontrollera sedan att kontrollens detaljnivå stämmer. Adresskontroller svarar på frågor om trafik från ett nätverk; kontokontroller svarar på frågor om ett konto; applikationshändelser svarar på frågor om beteende efter autentisering. En policy som nämner alla tre är granskningsbar, och en som bara nämner VPN-trafik är det inte.
Mät sedan resultatet i stället för antalet regler. Obehöriga försök bör minska, legitima användare bör behålla en stödd väg, och antalet supportkontakter per tusen inloggningar bör inte öka. En blockering som förbättrar den första siffran medan den förstör de andra två har flyttat problemet, inte löst det.
Att acceptera VPN-anslutningar och upprätthålla missbrukskontroller är förenliga mål. Den version som fungerar behandlar källadressen som en indata bland flera, tillämpar den snävaste kontrollen som passar bevisen och lämnar en ärlig väg för personen som felklassificerades. Den version som misslyckas behandlar en adress som en misstänkt och kallar det en policy.