Avveckling av PPTP/MS-CHAPv2: runbook för ett gammalt VPN

Lösenord på tjugo tecken, som roteras varje månad och förvaras i ett valv, gör inte en PPTP-server med MS-CHAPv2 till ett modernt VPN. Lösenordet är en indata till ett utbyte vars svaghet ligger i själva utbytet. Den här runbooken är för den som har ärvt servern och måste flytta användarna därifrån utan att skära av den plats som är beroende av den. Gå igenom stegen i ordning, för varje steg lämnar en anteckning som du kommer att vilja ha när någon frågar varför åtkomsten plötsligt ändrades.

Skriv ned stacken innan du rör något

Tre lager smälts samman i ordet PPTP, och varje lager fallerar på sitt eget sätt. Tunneln är PPTP själv, GRE plus TCP 1723. Autentiseringen är den PPP-metod som servern erbjuder, här MS-CHAPv2. Länkskyddet är MPPE, vars nycklar härleds från det autentiseringsutbytet. Att namnge alla tre hindrar att en senare rättelse landar på fel lager.

Läs den levande konfigurationen i stället för att lita på en wikisida, och notera filen, lyssnaren och de senaste sessionerna som autentiserades.

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

I en Windows-roll för fjärråtkomst kommer samma inventering från två kommandon, och det andra spelar roll eftersom en roll kan annonsera flera metoder samtidigt medan klienterna i fält alltid bara förhandlar om den svagaste.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Avgör vad tunneln faktiskt bär i dag

Lista konsumenterna innan du väljer en ersättning: resande bärbara datorer, en filialrouter, en betalterminal, en uppsättning fältsurfplattor. En konsument som bara behöver nå en intern värd är lätt att flytta. En konsument inbäddad i hårdvara som du inte kan flasha om kan behöva en mellanliggande gateway i stället för en klientuppgradering, och det beslutet hör hemma i planen, inte mitt i övergången.

Fråga sedan vad en angripare som kan observera eller påverka inloggningsutbytet skulle få. Med MS-CHAPv2 innehåller svaret material som gör det möjligt att återställa användarens lösenord offline, och det är just därför längd och rotation inte reparerar designen: den återställda hemligheten är giltig på varje system där användaren återanvände den.

MPPE ärver samma svaghet, eftersom dess nycklar kommer från det utbytet, och det ger dig varken integritet per paket eller upprepningsbeteende som ett modernt AEAD-chiffer. En session som autentiseras rent har bevisat kompatibilitet med de konfigurerade kontrollerna och ingenting mer.

Varken en kort lunchrast eller ett litet antal användare förvandlar en kryptografisk egenskap till en policyegenskap.

Kör migreringen inom ett enda underhållsfönster

Sätt upp ersättningen, bevisa den med en pilotgrupp och stoppa sedan den gamla lyssnaren i stället för att lämna den som en tyst reserv. En reserv som alla fortfarande kan nå är ingen migrering, och den håller det svaga utbytet tillgängligt just för de användare som aldrig bryr sig om att byta.

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

Stäng brandväggsvägen i samma fönster. GRE har ingen port att komma ihåg, så en regel som tillåter protokoll 47 efter nummer är lätt att förbise och lämnar tjänsten nåbar även efter att daemonen är borta. Registrera regeln du tog bort, dess tidigare placering och orsaken, så att en senare ändringsgranskning inte återställer den av misstag.

Hantera inloggningsuppgifter separat från konfigurationen. Att ta bort en klientprofil är inte en återkallelse, och ett konto som fortfarande autentiseras någon annanstans är inte avvecklat.

Verifiera att ersättningen gör de jobb som PPTP gjorde

Checklistan är inte ”ansluter den”. Den är om autentisering, adresstilldelning, DNS-uppslagning, ruttval, återanslutningsbeteende och peer-verifiering alla fortfarande håller under ersättningen. Testa varje på en pilotenhet, i den ordningen, och skriv det observerade resultatet bredvid förväntan.

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

En adress på gränssnittet bevisar att förhandlingen slutfördes. Den bevisar inte att fjärrsidan auktoriserade den rutt du förväntar dig, och uppslaget ovan svarar bara för den här värden, inte för ett vidarebefordrat LAN. Ett resolver-svar bevisar att en resolver är nåbar, inte att delad DNS-policy skickar rätt namn dit.

Testa återanslutning sist, för det är där de flesta ersättningar regredierar: försätt en bärbar dator i viloläge, byt nätverk och bekräfta att tunneln återupprättas utan att lämna kvar inaktuella rutter.

Återställning, återkallelse och den anteckning du lämnar

Återställning återställer tjänsten; den återställer inte säkerheten, och skillnaden måste sägas högt innan fönstret öppnas. Om den nya vägen misslyckas, ta tillbaka användarna via en andra modern slutpunkt eller en tillfällig gateway, inte genom att slå på PPTP igen för alla. Att behålla en nödväg på det gamla protokollet utökar den exponering du just dokumenterade.

Efter övergången, återkalla de konton som autentiserades över PPTP, låt deras sparade profiler löpa ut och bekräfta att GRE-regeln är borta från varje kantenhet, inklusive katastrofåterställningskopian som ingen minns.

Lämna en kort anteckning: protokollen du hittade, datumet varje lyssnare stoppade, klientversionerna som ersättningen stöder och ägaren som kan öppna beslutet igen. Lösenordshygien spelar fortfarande roll efteråt, men som hygien på ett protokoll som förtjänar den, inte som ett argument för att hålla det gamla vid liv.