Paranoid Sysadmin -vs- Versión PHP desactualizada

¿Cómo puede un administrador de sistemas paranoico mantenerse actualizado con las últimas versiones estables de PHP? (Las correcciones de seguridad han estado llegando con bastante regularidad).

Este es un servidor de producción, por lo que "romper cosas" está asustando a mi chico. El tiempo de inactividad por mantenimiento no es el problema.

Específicamente, estamos ejecutando un Suse Enterprise Linux reciente, pero una respuesta genérica o más general es perfectamente aceptable.

¿Cómo maneja las actualizaciones de seguridad para las máquinas de producción? ¿Qué ignoramos que este tipo tenga tanto miedo de usar el administrador de paquetes para "actualizar"?

¿Algún consejo?

Manejo PHP de la misma manera que manejo todo lo demás: primero actualice el entorno de desarrollo (un clon de producción de VMWare), haga una prueba de regresión y luego lo promocione a producción usando las mismas plantillas de implementación que utilizamos para los hosts VMWare. (Si usa administradores de paquetes para realizar sus actualizaciones, usaría los mismos paquetes).

Como una capa adicional de aislamiento, nuestro entorno de producción se compone de hosts redundantes emparejados, y un host se retira de la rotación de producción para su actualización, luego se prueba exhaustivamente antes de pasar a ese host para actualizar a su socio.

Como regla general, las actualizaciones de seguridad se aplican tan pronto como sea práctico, y las actualizaciones de corrección de errores no críticas / no críticas se aplican trimestralmente para minimizar el tiempo de inactividad.

PHP está en mi lista principal de cosas para mantener actualizado a la versión actual. Confío menos que la mayoría de las cosas.

En última instancia, su mejor opción es revisar cada registro de cambios desde su versión actual hasta la última y sopesar el riesgo de manera tangible.

Si está hablando de actualizar versiones menores, como 5.3.1 a 5.3.2, no me preocuparía demasiado.

Si está actualizando de 5.2.x a 5.3.x, es probable que presente algunos problemas de compatibilidad.

Si está utilizando paquetes del sistema, normalmente las distribuciones no introducirán actualizaciones que rompan el rendimiento existente. RHEL y CentOS parchean versiones antiguas para corregirlas hasta que salga una versión de distribución principal. Por lo general, hacen las pruebas por usted, lo que reduce el riesgo. Esperaría que la empresa SuSE sea ​​similar.

Para las rutas de actualización, la mejor opción sería construir un servidor de prueba y probar la aplicación con la última versión antes de actualizar la producción.

Otra respuesta menos apreciada es crear una lista blanca de URL y características permitidas. En Apache puede hacer esto combinando las funciones de proxy y reescritura.

Básicamente, realiza dos instalaciones, una que tiene una configuración simplificada: Proxy, reescribir y sin ejecución de código; etc. Cualquier URL "permitida" (con parámetros, etc.) se aproxima a la segunda instalación.

Luego, agréguese a la lista de desarrolladores de PHP y monitoree las notas de la versión cuidadosamente. Cada vez que ve algo que parece ser una vulnerabilidad de seguridad, crea una cuña en la primera instalación para detectar este tipo de falla y envía un error al usuario.

En una configuración como esta, querrás redirigir POST a un filtro (si es que necesitas POST; ¡algunos sitios funcionan bien al permitir POST solo desde algunas direcciones IP!) Que puede buscar fuentes permitidas y validar todo.

Tal lista blanca lleva mucho tiempo configurarla, pero para aplicaciones de misión crítica que necesitan ejecutarse por más tiempo que la vida útil estable de PHP (que parece ser solo unos pocos años), esta puede ser una excelente manera de aprovechar la gran cantidad de PHP aplicaciones sin obtener sus vulnerabilidades también.

Además de lo anterior, puede habilitar la reversión de paquetes por si acaso.

Luego, si algo se interrumpe en la producción y estaba seguro de que funcionaba bien en el desarrollo , al menos puede deshacer el cambio rápidamente antes de solucionar el problema.

Consulte el paquete Rollback YUM para ver un ejemplo en Yum. Estoy seguro de que otros sistemas de gestión de paquetes tienen similares.

Sé que es cinturón y frenillos y estoy de acuerdo con Warner con los puntos de lanzamiento. Los cambios menores no deberían romper nada. Personalmente, no he tenido ningún problema en las actualizaciones de PHP, pero siempre es mejor prevenir que curar.