Paranoid Sysadmin -vs- Versione PHP non aggiornata

Come può un amministratore di sistema paranoico rimanere aggiornato con le ultime versioni stabili di PHP? (le correzioni di sicurezza sono arrivate abbastanza regolarmente).

Questo è un server di produzione, e quindi "rompere le cose" sta spaventando il mio ragazzo a morte. I tempi di fermo per manutenzione non sono il problema.

In particolare, stiamo eseguendo un recente Suse Enterprise Linux, ma una risposta generica o più generale è perfettamente accettabile.

Come gestite gli aggiornamenti di sicurezza delle macchine di produzione? Cosa siamo così ignoranti di questo ragazzo che ha così paura di usare il gestore dei pacchetti per "aggiornare"?

Qualche consiglio?

Gestisco PHP nello stesso modo in cui gestisco tutto il resto: aggiorna prima l'ambiente di sviluppo (un clone di produzione VMWare), test di regressione, quindi promuovilo alla produzione utilizzando gli stessi modelli di distribuzione che abbiamo usato per gli host VMWare. (Se si utilizzano i gestori pacchetti per eseguire gli aggiornamenti, si utilizzerebbero gli stessi pacchetti).

Come ulteriore livello di isolamento, il nostro ambiente di produzione è composto da host ridondanti accoppiati e un host viene rimosso dalla rotazione di produzione per il suo aggiornamento, quindi testato a fondo prima di passare a tale host per aggiornare il suo partner.

Come regola generale, gli aggiornamenti di sicurezza vengono applicati non appena pratici e gli aggiornamenti di bugfix non di sicurezza / non critici vengono applicati trimestralmente per ridurre al minimo i tempi di inattività.

PHP è nella mia lista di cose da tenere aggiornata alla versione attuale. Mi fido di meno della maggior parte delle cose.

In definitiva, la cosa migliore da fare è rivedere tutti i log delle modifiche dalla versione attuale all'ultima e ponderare in modo tangibile il rischio.

Se stai parlando di aggiornare versioni secondarie, come 5.3.1 a 5.3.2, non mi preoccuperei troppo.

Se si esegue l'aggiornamento da 5.2.xa 5.3.x, è probabile che si verifichino alcuni problemi di compatibilità.

Se si utilizzano pacchetti di sistema, in genere le distribuzioni non introdurranno aggiornamenti che interromperanno le prestazioni esistenti. RHEL e CentOS patch vecchie versioni per correzioni fino a quando non viene rilasciata una versione di distribuzione principale. Il test per te, in genere, riduce il rischio. Mi aspetto che l' impresa SuSE sia simile.

Per i percorsi di aggiornamento, la soluzione migliore sarebbe quella di costruire un server di prova e testare l'applicazione con l'ultima versione prima di aggiornare la produzione.

Un'altra risposta meno apprezzata è quella di creare una lista bianca di URL e funzionalità consentiti. In Apache puoi farlo combinando il proxy e le funzionalità di riscrittura.

Fondamentalmente, si eseguono due installazioni, una con una configurazione ridotta: Proxy, riscrittura e nessuna esecuzione di codice; ecc. Qualsiasi URL "consentito" (con parametri, ecc.) viene assegnato alla seconda installazione.

Quindi, aggiungiti all'elenco degli sviluppatori di PHP e monitora attentamente le note di rilascio. Ogni volta che vedi qualcosa che sembra essere una vulnerabilità della sicurezza, crei uno shim nella prima installazione per rilevare questo tipo di errore e inviare all'utente un errore.

In una configurazione come questa, ti consigliamo di reindirizzare il POST a un filtro (se hai bisogno del POST; alcuni siti riescono bene permettendo il POST solo da alcuni indirizzi IP!) Che può cercare fonti consentite e pre convalida tutto.

Una whitelist di questo tipo richiede molto tempo per essere configurata, ma per le app mission-critical che devono funzionare per un periodo di tempo più lungo della durata di vita stabile di PHP (che sembra essere solo pochi anni), questo può essere un modo eccellente per sfruttare il gran numero di PHP applicazioni senza ottenere anche le loro vulnerabilità.

Oltre a quanto sopra è possibile abilitare i rollback dei pacchetti per ogni evenienza.

Quindi se qualcosa si interrompe sulla produzione che si è sicuri che funzionasse bene nello sviluppo , è possibile almeno annullare rapidamente la modifica prima di risolvere il problema.

Vedere il pacchetto Rollback YUM per un esempio in Yum. Sono sicuro che altri sistemi di gestione dei pacchetti hanno simili.

So che è cintura e bretelle e sono d'accordo con Warner con i rilasci puntuali. Piccoli cambiamenti non dovrebbero interrompere nulla. Personalmente non ho avuto problemi con gli aggiornamenti di PHP, ma è sempre meglio prevenire che curare.