Windows-VPN harder maken: repareer eerst de authenticatie, dan de tunnel

Uw Windows VPN-server vraagt om een gebruikersnaam en een wachtwoord, en dat ene dialoogvenster verbergt drie losstaande taken. Eén bewijst wie de persoon is, één voorkomt dat iemand die de lijn observeert dat bewijs hergebruikt, en één bepaalt welke adressen hij daarna mag bereiken. De meeste kleine installaties verharden eerst de tunnel en laten de eerste twee taken op hun standaardwaarden, en dat is de verkeerde volgorde.

Werk in de volgorde waarin de aanvaller werkt. Eerst wat van de lijn kan worden afgevangen. Dan wat later met die opname opnieuw kan worden afgespeeld. Ten slotte wat een geauthenticeerde aanvaller kan bereiken als hij eenmaal binnen is.

Drie taken, één dialoogvenster

Identiteit is het deel waar mensen aan denken, en het is maar een derde van het probleem. Het identiteitsbewijs moet een waarnemer doorstaan die de uitwisseling opneemt en het later opnieuw probeert. Autorisatie is een aparte beslissing die de server neemt nadat de identiteit vaststaat, en Windows bewaart die in een andere service dan de service die de inloggegevens valideert.

Wanneer alle drie in één mentale emmer leven, is het gebruikelijke resultaat een server die sterk authenticeert en de gebruiker daarna alles laat bereiken. Dat later repareren is moeilijker dan nu het beleid bepalen, want tegen die tijd coderen het firewallprofiel, de adrespool en de routes allemaal de oude aanname.

Scheid de drie in uw notities voordat u een instelling aanraakt, en repareer ze daarna van de zwakste schakel omhoog.

Waarom MS-CHAPv2 een herhalingstest niet doorstaat

Als de server nog steeds PPTP met MS-CHAPv2 accepteert, beschermt de tunnel het wachtwoord in geen enkele zinvolle betekenis. De uitdaging en het antwoord kunnen worden afgevangen en offline worden aangevallen, en in 2012 demonstreerde een publieke kraakdienst herstel uit zo'n handdruk in ongeveer een dag voor een typerend wachtwoord. Een langer en complexer wachtwoord verhoogt de kosten; het verwijdert niet het materiaal dat een aanvaller uit het netwerk nodig heeft.

De eigenschap die u wilt is een inloggegeven dat niet opnieuw kan worden afgespeeld. EAP-TLS met clientcertificaten geeft elk apparaat zijn eigen identiteit en laat u precies één apparaat intrekken.

Certificaten uitrollen is echt werk: een particuliere CA, een intrekkingspad dat clients controleren, en een vernieuwingsplan dat personeelsverloop overleeft. Behandel dat werk als het project en niet als een obstakel tussen u en een werkende tunnel. Begroot het zoals u een firewallvervanging zou begroten. Een gedeeld wachtwoord is alleen goedkoper tot de eerste intrekking.

Een vooraf gedeelde sleutel authenticeert het paar, niet de persoon

L2TP/IPsec met een vooraf gedeelde sleutel bewijst dat twee gateways hetzelfde geheim kennen. Het zegt niets over welk mens verbinding maakt, en het kan op die laag de ene medewerker niet van de andere onderscheiden. Gebruik een lange willekeurige waarde, ver boven de tien tekens die sommige handleidingen voorstellen, want wie de handdruk afvangt kan de sleutel offline aanvallen.

Elke client op dat profiel deelt het geheim, dus iemand verwijderen betekent het opnieuw verdelen onder iedereen die overblijft. Houd een aparte stap voor gebruikersauthenticatie boven het geheim op machineniveau, en stap over op certificaten naarmate de clientpopulatie groeit. Een vooraf gedeelde sleutel gecombineerd met MS-CHAPv2 zijn twee zwakke lagen, en de tweede doet de eerste teniet.

Autorisatie hoort in Network Policy Server

NPS op Windows bepaalt wie mag verbinden, en doet dat nadat de authenticatie al is geslaagd. Die scheiding is de nuttigste verhardingscontrole in het product, en veel installaties laten die ongemoeid.

Gebruik beleidsvoorwaarden die echte beperkingen weerspiegelen: groepslidmaatschap, het tijdvenster waarin de ondersteuning bezet is, en apparaatstatus uit een gezondheidscontrole. Voeg een tweede factor toe waar de gegevens de wrijving rechtvaardigen, en bedenk dat het beleid per verbindingspoging wordt geëvalueerd, wat er een levende controle van maakt in plaats van een document.

RADIUS-accounting geeft u ook één registratie van wie verbond en wanneer. Dat log is het verschil tussen een incidentbeoordeling en een gok, en het bestaat of iemand het ooit leest of niet.

Beperk wat een geslaagde login kan bereiken

De VPN-adapter zou in een firewallprofiel moeten landen dat de diensten toestaat die zijn rol nodig heeft in plaats van het hele subnet. De routeringsvraag staat los van filteren. Een volledige tunnel beschermt het clientapparaat en stuurt elke byte via uw uplink, terwijl een gesplitste tunnel lokaal verkeer lokaal houdt en het apparaat blootstelt aan welk netwerk het zich ook bevindt.

Geen van beide keuzes is een beveiligingsstandaard. Beide moeten worden vastgelegd naast het firewallprofiel dat ze veronderstellen.

Controleer de faalpaden

Test wat zou moeten breken: een verkeerd wachtwoord, een verlopen certificaat, een ingetrokken apparaat, een gebruiker buiten de groep. Elk zou op een ander punt moeten falen, en het log zou moeten zeggen welke het was. Voer de set eerst uit tegen een testaccount en herhaal die daarna voor een echte gebruiker. Een afwijzing die zonder reden in het gebeurtenislog belandt, is het waard om veel eerder te repareren dan wanneer u die registratie nodig hebt.

Bevestig daarna welke poorten zijn gepubliceerd en waarom. PPTP heeft TCP 1723 en GRE als IP-protocol in plaats van als poort nodig, IKEv2 heeft UDP 500 en 4500 nodig, en L2TP heeft UDP 1701 plus IPsec nodig. Een beheerinterface blootstellen zodat een client verbinding maakt is geen reparatie, het is een tweede incident dat wacht om ontdekt te worden.

Bepaal ten slotte wat de server vastlegt en hoe lang. Een eindpunt zonder authenticatiegeschiedenis kan de eerste vraag na een incident niet beantwoorden, namelijk of de poging ooit was geautoriseerd.