Herdning av Windows VPN: rett opp autentiseringen før tunnelen
MS-CHAPv2 er ikke en passordkontroll det er verdt å stole på, og en lang forhåndsdelt nøkkel er ikke brukerautentisering. Sorter rettelsene etter hva en angriper kan spille av på nytt.
Windows VPN-serveren din ber om et brukernavn og et passord, og den ene dialogen skjuler tre uavhengige plikter. Én beviser hvem personen er, én hindrer at noen som overvåker linjen bruker beviset om igjen, og én avgjør hvilke adresser de kan nå etterpå. De fleste små installasjoner herder tunnelen først og lar de to første pliktene stå på standardverdiene, og det er feil rekkefølge.
Arbeid i den rekkefølgen angriperen arbeider i. Først det som kan fanges fra linjen. Deretter det som senere kan spilles av på nytt med det opptaket. Til slutt det en autentisert angriper kan nå når den først er inne.
Tre plikter, én dialog
Identitet er den delen folk tenker på, og den er bare en tredjedel av problemet. Beviset for identitet må tåle en observatør som tar opp utvekslingen og prøver igjen senere. Autorisasjon er en egen beslutning som serveren tar etter at identiteten er avklart, og Windows oppbevarer den i en annen tjeneste enn den som validerer legitimasjon.
Når alle tre bor i én mental bøtte, er det vanlige resultatet en server som autentiserer sterkt og deretter lar brukeren nå alt. Å rette det senere er vanskeligere enn å bestemme policyen nå, fordi brannmurprofilen, adressepoolen og rutene da alle koder den gamle antakelsen.
Skill de tre i notatene dine før du rører en innstilling, og rett dem deretter fra det svakeste leddet og oppover.
Hvorfor MS-CHAPv2 ikke tåler en gjenoppspillingstest
Hvis serveren fortsatt godtar PPTP med MS-CHAPv2, beskytter ikke tunnelen passordet i noen meningsfull forstand. Utfordringen og svaret kan fanges og angripes offline, og i 2012 viste en offentlig knekketjeneste gjenoppretting fra et slikt håndtrykk på omtrent en dag for et typisk passord. Et lengre og mer komplekst passord øker kostnaden; det fjerner ikke materialet angriperen trenger fra nettverket.
Egenskapen du vil ha, er en legitimasjon som ikke kan spilles av på nytt. EAP-TLS med klientsertifikater gir hver enhet sin egen identitet og lar deg tilbakekalle nøyaktig én enhet.
Utrulling av sertifikater er ekte arbeid: en privat CA, en tilbakekallingsvei som klientene kontrollerer, og en fornyelsesplan som tåler utskifting av personale. Behandle det arbeidet som prosjektet og ikke som en hindring mellom deg og en fungerende tunnel. Budsjetter for det slik du ville budsjettert for en brannmur-utskifting. Et delt passord er bare billigere fram til den første tilbakekallingen.
En forhåndsdelt nøkkel autentiserer paret, ikke personen
L2TP/IPsec med en forhåndsdelt nøkkel beviser at to gatewayer kjenner den samme hemmeligheten. Den sier ingenting om hvilket menneske som kobler til, og den kan ikke skille én ansatt fra en annen på det laget. Bruk en lang tilfeldig verdi, godt over de ti tegnene noen veiledninger foreslår, fordi den som fanger håndtrykket kan angripe nøkkelen offline.
Hver klient på den profilen deler hemmeligheten, så å fjerne én person betyr å fordele den på nytt til alle som blir igjen. Hold et eget brukerautentiseringstrinn over hemmeligheten på maskinnivå, og gå over til sertifikater etter hvert som klientmassen vokser. En forhåndsdelt nøkkel kombinert med MS-CHAPv2 er to svake lag, og det andre opphever det første.
Autorisasjon hører hjemme i Network Policy Server
NPS på Windows avgjør hvem som får koble til, og det gjør den etter at autentiseringen allerede har lyktes. Den delingen er den nyttigste herdingskontrollen i produktet, og mange installasjoner lar den være urørt.
Bruk policybetingelser som gjenspeiler reelle begrensninger: gruppemedlemskap, tidsvinduet når støtten er bemannet, og enhetstilstand fra en helsesjekk. Legg til en annen faktor der dataene rettferdiggjør friksjonen, og husk at policyen vurderes for hvert tilkoblingsforsøk, noe som gjør den til en levende kontroll og ikke et dokument.
RADIUS-regnskap gir deg også én registrering av hvem som koblet til og når. Den loggen er forskjellen mellom en hendelsesgjennomgang og et gjetning, og den finnes uansett om noen noen gang leser den.
Begrens hva en vellykket innlogging kan nå
VPN-adapteren bør lande i en brannmurprofil som tillater tjenestene rollen trenger i stedet for hele subnettet. Rutingsspørsmålet er atskilt fra filtrering. En full tunnel beskytter klientenheten og sender hver byte gjennom opplastingslinjen din, mens en delt tunnel holder lokal trafikk lokal og utsetter enheten for hvilket nettverk den enn befinner seg på.
Ingen av valgene er en sikkerhetsstandard. Begge må skrives ned ved siden av brannmurprofilen de forutsetter.
Verifiser feilveiene
Test hva som bør bryte: et feil passord, et utløpt sertifikat, en tilbakekalt enhet, en bruker utenfor gruppen. Hver bør feile på et forskjellig punkt, og loggen bør si hvilken det var. Kjør settet mot en testkonto først, og gjenta det deretter for en ekte bruker. En avvisning som havner i hendelsesloggen uten grunn er verdt å rette lenge før du trenger den registreringen.
Bekreft deretter hvilke porter som er publisert og hvorfor. PPTP trenger TCP 1723 og GRE som en IP-protokoll i stedet for en port, IKEv2 trenger UDP 500 og 4500, og L2TP trenger UDP 1701 pluss IPsec. Å eksponere et administrasjonsgrensesnitt slik at en klient kan koble til er ikke en reparasjon, det er en andre hendelse som venter på å bli oppdaget.
Til slutt, bestem hva serveren registrerer og hvor lenge. Et endepunkt uten autentiseringshistorikk kan ikke svare på det første spørsmålet etter en hendelse, nemlig om forsøket noen gang var autorisert.