Härdning av Windows VPN: rätta autentiseringen före tunneln

Din Windows VPN-server frågar efter användarnamn och lösenord, och den enda dialogen döljer tre oberoende uppgifter. En bevisar vem personen är, en hindrar någon som övervakar linjen från att återanvända beviset, och en avgör vilka adresser de får nå efteråt. De flesta små installationer härdar tunneln först och lämnar de två första uppgifterna på sina standardvärden, vilket är fel ordning.

Arbeta i den ordning angriparen arbetar. Först det som kan fångas från linjen. Sedan det som senare kan spelas upp igen med den inspelningen. Till sist det en autentiserad angripare kan nå när den väl är inne.

Tre uppgifter, en dialog

Identitet är den del folk tänker på, och den är bara en tredjedel av problemet. Identitetsbeviset måste stå emot en observatör som spelar in utbytet och försöker igen senare. Autorisering är ett separat beslut som servern fattar efter att identiteten är fastställd, och Windows håller det i en annan tjänst än den som validerar inloggningsuppgifterna.

När alla tre bor i en enda mental hink blir det vanliga resultatet en server som autentiserar starkt och sedan låter användaren nå allt. Att rätta det senare är svårare än att besluta policyn nu, eftersom brandväggsprofilen, adresspoolen och rutterna då alla kodar det gamla antagandet.

Separera de tre i dina anteckningar innan du rör en inställning, och rätta dem sedan från den svagaste länken och uppåt.

Varför MS-CHAPv2 inte klarar ett uppspelningstest

Om servern fortfarande accepterar PPTP med MS-CHAPv2 skyddar tunneln inte lösenordet i någon meningsfull mening. Utmaningen och svaret kan fångas och attackeras offline, och 2012 visade en offentlig knäcktjänst återställning från ett sådant handslag på ungefär en dag för ett typiskt lösenord. Ett längre och mer komplext lösenord höjer kostnaden; det tar inte bort materialet angriparen behöver från nätverket.

Egenskapen du vill ha är en inloggningsuppgift som inte kan spelas upp igen. EAP-TLS med klientcertifikat ger varje enhet sin egen identitet och låter dig återkalla exakt en enhet.

Att rulla ut certifikat är riktigt arbete: en privat CA, en återkallningsväg som klienterna kontrollerar och en förnyelseplan som överlever personalomsättning. Behandla det arbetet som projektet och inte som ett hinder mellan dig och en fungerande tunnel. Budgetera för det som du skulle budgetera för ett brandväggsbyte. Ett delat lösenord är bara billigare fram till den första återkallelsen.

En fördelad nyckel autentiserar paret, inte personen

L2TP/IPsec med en fördelad nyckel bevisar att två gateways känner till samma hemlighet. Den säger ingenting om vilken människa som ansluter, och den kan inte skilja en anställd från en annan på det lagret. Använd ett långt slumpvärde, långt över de tio tecken som vissa guider föreslår, eftersom den som fångar handslaget kan attackera nyckeln offline.

Varje klient på den profilen delar hemligheten, så att ta bort en person innebär att fördela den igen till alla som blir kvar. Håll ett separat steg för användarautentisering ovanpå hemligheten på maskinnivå, och gå över till certifikat i takt med att klientpopulationen växer. En fördelad nyckel kombinerat med MS-CHAPv2 är två svaga lager, och det andra upphäver det första.

Autorisering hör hemma i Network Policy Server

NPS i Windows avgör vem som får ansluta, och gör det efter att autentiseringen redan har lyckats. Den separationen är den mest användbara härdningskontrollen i produkten, och många installationer lämnar den orörd.

Använd principvillkor som speglar verkliga begränsningar: gruppmedlemskap, tidsfönstret när supporten är bemannad och enhetsstatus från en hälsokontroll. Lägg till en andra faktor där data rättfärdigar friktionen, och kom ihåg att principen utvärderas vid varje anslutningsförsök, vilket gör den till en levande kontroll och inte ett dokument.

RADIUS-redovisning ger dig också en post över vem som anslöt och när. Den loggen är skillnaden mellan en incidentgenomgång och en gissning, och den finns oavsett om någon någonsin läser den.

Begränsa vad en lyckad inloggning kan nå

VPN-adaptern bör landa i en brandväggsprofil som tillåter de tjänster rollen behöver i stället för hela subnätet. Dirigeringsfrågan är skild från filtrering. En full tunnel skyddar klientenheten och skickar varje byte genom din upplänk, medan en delad tunnel håller lokal trafik lokal och utsätter enheten för vilket nätverk den än befinner sig på.

Inget av valen är en säkerhetsstandard. Båda måste skrivas ned bredvid den brandväggsprofil de förutsätter.

Verifiera felvägarna

Testa vad som borde gå sönder: ett fel lösenord, ett utgånget certifikat, en återkallad enhet, en användare utanför gruppen. Varje bör misslyckas på olika punkter, och loggen bör säga vilken det var. Kör uppsättningen mot ett testkonto först och upprepa den sedan för en riktig användare. En avvisning som hamnar i händelseloggen utan anledning är värd att rätta långt innan du behöver den posten.

Bekräfta sedan vilka portar som publiceras och varför. PPTP behöver TCP 1723 och GRE som IP-protokoll i stället för port, IKEv2 behöver UDP 500 och 4500, och L2TP behöver UDP 1701 plus IPsec. Att exponera ett administrationsgränssnitt så att en klient ansluter är inte en reparation, det är en andra incident som väntar på att upptäckas.

Bestäm till sist vad servern registrerar och hur länge. En slutpunkt utan autentiseringshistorik kan inte svara på den första frågan efter en incident, nämligen om försöket någonsin var auktoriserat.