Dismettere PPTP/MS-CHAPv2: runbook per una VPN legacy

Password di venti caratteri, ruotate ogni mese e conservate in una cassaforte, non trasformano un server PPTP con MS-CHAPv2 in una VPN moderna. La password è un input di uno scambio la cui debolezza vive nello scambio stesso. Questo runbook è per chi ha ereditato quel server e deve spostare gli utenti senza tagliare il sito che ne dipende. Segui i passaggi in ordine, perché ciascuno lascia un registro che ti servirà quando qualcuno chiederà perché l’accesso è cambiato all’improvviso.

Scrivi lo stack prima di toccare qualsiasi cosa

Tre livelli si fondono nella parola PPTP, e ciascuno fallisce a modo suo. Il tunnel è PPTP stesso, GRE più TCP 1723. L’autenticazione è il metodo PPP offerto dal server, qui MS-CHAPv2. La protezione del collegamento è MPPE, le cui chiavi derivano da quello scambio di autenticazione. Nominare tutti e tre evita che una correzione successiva atterri sul livello sbagliato.

Leggi la configurazione viva invece di fidarti di una pagina wiki, e annota il file, il listener e le ultime sessioni che si sono autenticate.

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

In un ruolo di accesso remoto Windows lo stesso inventario arriva da due comandi, e il secondo conta perché un ruolo può annunciare più metodi insieme mentre i client sul campo negoziano sempre e solo il più debole.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Decidi cosa trasporta davvero oggi il tunnel

Elenca i consumatori prima di scegliere un sostituto: portatili in mobilità, un router di filiale, un terminale di pagamento, un insieme di tablet sul campo. Un consumatore che deve raggiungere solo un host interno è facile da spostare. Un consumatore incorporato in hardware che non puoi riflashare può aver bisogno di un gateway intermedio invece di un aggiornamento del client, e quella decisione appartiene al piano, non alla metà della migrazione.

Poi chiediti cosa otterrebbe un attaccante che può osservare o influenzare lo scambio di accesso. Con MS-CHAPv2 la risposta include materiale che consente un recupero offline della password dell’utente, ed è proprio per questo che lunghezza e rotazione non riparano il progetto: il segreto recuperato è valido su ogni sistema dove l’utente lo ha riutilizzato.

MPPE eredita la stessa debolezza, poiché le sue chiavi provengono da quello scambio, e non ti dà l’integrità per pacchetto né il comportamento di replay di un cifrario AEAD moderno. Una sessione che si autentica in modo pulito ha dimostrato compatibilità con i controlli configurati e nulla di più.

Né una breve pausa pranzo né un numero ridotto di utenti trasformano una proprietà crittografica in una proprietà di policy.

Esegui la migrazione dentro una sola finestra di manutenzione

Alza il sostituto, dimostralo con un gruppo pilota, poi ferma il vecchio listener invece di lasciarlo come ripiego silenzioso. Un ripiego a cui tutti possono ancora arrivare non è una migrazione, e tiene lo scambio debole disponibile proprio per gli utenti che non si prendono mai la briga di cambiare.

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

Chiudi il percorso del firewall nella stessa finestra. GRE non ha una porta da ricordare, quindi una regola che consente il protocollo 47 per numero sfugge facilmente e lascia il servizio raggiungibile anche dopo che il demone è sparito. Registra la regola rimossa, la sua posizione precedente e il motivo, così che una revisione successiva non la ripristini per caso.

Gestisci le credenziali separatamente dalla configurazione. Rimuovere un profilo client non è una revoca, e un account che si autentica ancora altrove non è stato dismesso.

Verifica che il sostituto faccia il lavoro che faceva PPTP

La lista di controllo non è “si connette?”. È se autenticazione, assegnazione degli indirizzi, risoluzione DNS, selezione del percorso, comportamento di riconnessione e verifica del peer tengono ancora sotto il sostituto. Prova ciascun punto su un dispositivo pilota, in quell’ordine, e scrivi il risultato osservato accanto all’attesa.

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

Un indirizzo sull’interfaccia dimostra che la negoziazione è conclusa. Non dimostra che il lato remoto abbia autorizzato il percorso che ti aspetti, e la ricerca qui sopra risponde solo per questo host, non per una LAN inoltrata. Una risposta del resolver dimostra la raggiungibilità di un resolver, non che la policy di DNS diviso gli invii i nomi giusti.

Ricontrolla la riconnessione per ultima, perché è lì che la maggior parte dei sostituti regredisce: sospendi un portatile, cambia rete e conferma che il tunnel si ristabilisce senza lasciare rotte obsolete.

Rollback, revoca e il registro che lasci

Il rollback ripristina il servizio; non ripristina la sicurezza, e la differenza va detta ad alta voce prima che la finestra si apra. Se il nuovo percorso fallisce, riporta gli utenti attraverso un secondo endpoint moderno o un gateway temporaneo, non riattivando PPTP per tutti. Tenere un percorso di emergenza sul vecchio protocollo allarga l’esposizione che hai appena documentato.

Dopo la migrazione revoca gli account che si sono autenticati via PPTP, lascia scadere i profili memorizzati e conferma che la regola GRE sia sparita da ogni dispositivo di bordo, compresa la copia di disaster recovery di cui nessuno si ricorda.

Lascia un registro breve: i protocolli trovati, la data di arresto di ogni listener, le versioni client supportate dal sostituto e il proprietario che può riaprire la decisione. L’igiene delle password conta ancora dopo, ma come igiene su un protocollo che la merita, non come argomento per tenere in vita il vecchio.