Una flotta di siti WordPress fuori dal server a fine vita.
Decine di siti di clienti diversi su server Ubuntu 20, ormai senza aggiornamenti di sicurezza. Li spostiamo su server nuovi a ondate, con un utente isolato per sito e PHP aggiornato.
Abbiamo pianificato la migrazione di circa 45 siti, rimasti dopo aver eliminato quelli non più usati, da server Ubuntu 20 a server nuovi gestiti con Laravel Forge. Si procede a ondate, dal rischio più basso al più alto, con i siti isolati per utente e il vecchio server acceso finché tutto non è verificato. Insieme abbiamo separato le credenziali di invio email: un utente IAM per sito, limitato al proprio dominio.
Contesto
Nel tempo i siti dei clienti si erano accumulati su pochi server con Ubuntu 20.04, ormai fuori dal supporto standard: WordPress moderni, WordPress datati, applicazioni Laravel e PHP su misura, alcuni ancora su PHP 7.4. Un cliente aveva da solo 14 siti su un server con pannello ISPConfig.
Il problema
Tenere tutto dov'era significava server senza aggiornamenti di sicurezza e, sui server più vecchi, siti che condividevano lo stesso utente di sistema. In parallelo, un audit sull'account AWS ha trovato 39 chiavi di accesso su 41 da ruotare, dopo una compromissione delle credenziali SMTP.
Cosa abbiamo fatto
- 01
Prima si toglie
Inventario e cancellazione dei siti non più usati, così non si migra spazzatura. Abbassamento del TTL DNS a 300 secondi qualche giorno prima, per cambi e rollback quasi istantanei.
- 02
Ondate per rischio
Prima i WordPress aggiornati, poi quelli da verificare su PHP recente, poi le applicazioni con repository, infine il codice su misura più datato, già provato sul vecchio server alzando la versione di PHP.
- 03
Lo stesso rito per ogni sito
Sito creato sul server nuovo con il suo utente, copia dei file con rsync, dump del database, certificato, test con il file hosts, cambio DNS. Il vecchio server resta acceso 48-72 ore.
- 04
Codice verificato su PHP 8.4
Revisione dei temi e dei plugin su misura: dipendenze passate come null, confronti stretti fragili, redirect senza exit, accessi a $_POST senza controlli. Corretti prima del passaggio.
- 05
Email con il minimo dei permessi
Un utente IAM per sito su Amazon SES, con una policy che consente l'invio solo dal dominio del sito e solo dagli IP dei server. Una chiave rubata non manda posta per gli altri.
Com'è andata
Ogni sito spostato gira con il proprio utente di sistema e una versione di PHP supportata, e le credenziali di invio sono separate sito per sito. Se un sito viene compromesso, resta confinato nel suo utente e la sua chiave email non serve a nient'altro.
Strumenti
Domande frequenti
Si può migrare senza fermare i siti?
Sì. Con TTL bassi, test tramite file hosts prima del cambio e vecchio server acceso in parallelo, il visitatore non se ne accorge e il ritorno indietro è immediato.
Perché un utente di sistema per sito?
Perché se un sito viene compromesso l'attaccante resta confinato nella sua cartella e non legge file e database degli altri.