PPTP/MS-CHAPv2 uitfaseren: runbook voor een erfenis-VPN

Wachtwoorden van twintig tekens, maandelijks geroteerd en in een kluis bewaard, maken van een PPTP-server met MS-CHAPv2 geen moderne VPN. Het wachtwoord is een invoer voor een uitwisseling waarvan de zwakte in de uitwisseling zelf zit. Deze runbook is voor wie die server heeft geërfd en de gebruikers ervan moet verhuizen zonder de locatie af te snijden die ervan afhankelijk is. Werk de stappen op volgorde af, want elke stap laat een aantekening achter die je wilt hebben wanneer iemand vraagt waarom de toegang plotseling veranderde.

Schrijf de stapel op voordat je iets aanraakt

Drie lagen worden samengevat in het woord PPTP, en elk faalt op zijn eigen manier. De tunnel is PPTP zelf, GRE plus TCP 1723. De authenticatie is de PPP-methode die de server biedt, hier MS-CHAPv2. De verbindingsbeveiliging is MPPE, waarvan de sleutels uit die authenticatie-uitwisseling worden afgeleid. Alle drie benoemen voorkomt dat een latere correctie op de verkeerde laag landt.

Lees de levende configuratie in plaats van een wikipagina te vertrouwen, en noteer het bestand, de listener en de laatste sessies die zich hebben geauthenticeerd.

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

Op een Windows-rol voor externe toegang komt dezelfde inventarisatie uit twee opdrachten, en de tweede is belangrijk omdat een rol meerdere methoden tegelijk kan adverteren terwijl de clients in het veld altijd alleen de zwakste onderhandelen.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Bepaal wat de tunnel vandaag werkelijk vervoert

Inventariseer de gebruikers voordat je een vervanging kiest: rondreizende laptops, een filiaalrouter, een betaalterminal, een set veldtablets. Een gebruiker die maar één interne host hoeft te bereiken, is eenvoudig te verhuizen. Een gebruiker die is ingebed in hardware die je niet opnieuw kunt flashen, heeft misschien een tussenliggende gateway nodig in plaats van een clientupgrade, en die beslissing hoort in het plan, niet midden in de overgang.

Vraag dan wat een aanvaller zou krijgen die de inloguitwisseling kan observeren of beïnvloeden. Bij MS-CHAPv2 bevat het antwoord materiaal waarmee het wachtwoord van de gebruiker offline kan worden hersteld, en juist daarom repareren lengte en rotatie het ontwerp niet: het herstelde geheim is geldig op elk systeem waar de gebruiker het opnieuw gebruikte.

MPPE erft dezelfde zwakte, omdat de sleutels uit die uitwisseling komen, en het geeft je niet de integriteit per pakket en het herhalingsgedrag van een moderne AEAD-cijfer. Een sessie die schoon authenticeert, heeft alleen compatibiliteit met de geconfigureerde controles bewezen en niets meer.

Noch een korte lunchpauze noch een klein aantal gebruikers verandert een cryptografische eigenschap in een beleidseigenschap.

Voer de migratie binnen één onderhoudsvenster uit

Zet de vervanging op, bewijs die met één pilotgroep, en stop daarna de oude listener in plaats van hem als stille terugval te laten staan. Een terugval die iedereen nog kan bereiken is geen migratie, en houdt de zwakke uitwisseling beschikbaar precies voor de gebruikers die nooit de moeite nemen om over te stappen.

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

Sluit het firewallpad in hetzelfde venster. GRE heeft geen poort om te onthouden, dus een regel die protocol 47 op nummer toestaat is gemakkelijk over het hoofd te zien en laat de dienst bereikbaar, zelfs nadat de daemon weg is. Leg de verwijderde regel, de vorige positie en de reden vast, zodat een latere wijzigingsreview hem niet per ongeluk herstelt.

Behandel inloggegevens apart van de configuratie. Het verwijderen van een cliëntprofiel is geen intrekking, en een account dat elders nog authenticeert is niet buiten gebruik gesteld.

Verifieer dat de vervanging het werk doet dat PPTP deed

De checklist is niet “maakt het verbinding”. Het is of authenticatie, adrestoewijzing, DNS-resolutie, routeselectie, herverbindingsgedrag en peer-verificatie allemaal nog standhouden onder de vervanging. Test elk op een pilotapparaat, in die volgorde, en schrijf het waargenomen resultaat naast de verwachting.

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

Een adres op de interface bewijst dat de onderhandeling is afgerond. Het bewijst niet dat de verre zijde de route heeft geautoriseerd die je verwacht, en de opzoeking hierboven antwoordt alleen voor deze host, niet voor een doorgestuurd LAN. Een resolver-antwoord bewijst bereikbaarheid van een resolver, niet dat gesplitst DNS-beleid de juiste namen daarheen stuurt.

Test herverbinden als laatste, want daar gaan de meeste vervangingen achteruit: zet een laptop in slaapstand, wissel van netwerk en bevestig dat de tunnel zich herstelt zonder verouderde routes achter te laten.

Terugdraaien, intrekken en het verslag dat je achterlaat

Terugdraaien herstelt de dienst; het herstelt de beveiliging niet, en dat verschil moet hardop gezegd worden voordat het venster opengaat. Als het nieuwe pad faalt, haal gebruikers dan terug via een tweede modern eindpunt of een tijdelijke gateway, niet door PPTP voor iedereen weer aan te zetten. Eén noodpad op het oude protocol houden vergroot de blootstelling die je zojuist hebt gedocumenteerd.

Trek na de overgang de accounts in die via PPTP authenticeerden, laat hun opgeslagen profielen verlopen en bevestig dat de GRE-regel van elk randapparaat verdwenen is, inclusief de disaster recovery-kopie die niemand zich herinnert.

Laat een kort verslag achter: de protocollen die je vond, de datum waarop elke listener stopte, de clientversies die de vervanging ondersteunt en de eigenaar die de beslissing opnieuw kan openen. Wachtwoordhygiëne blijft daarna belangrijk, maar als hygiëne op een protocol dat het verdient, niet als argument om het oude in leven te houden.