Tras la reciente heartbleed vulnerabilidad de OpenSSL, me gustaría mantener mis máquinas EC2 actualizados sobre una base regular. El enfoque ingenuo sería establecer un trabajo cron por hora para las actualizaciones de seguridad ( sudo apt-get update && sudo unattended-upgrade).
¿Hay algún riesgo de hacer eso? ¿Existe un mecanismo de actualización recomendado para máquinas EC2?
Respuestas:
El paquete de actualizaciones desatendidas es la forma estándar de aplicar automáticamente correcciones de errores importantes y parches de seguridad en Ubuntu.
Recomiendo instalar esto en cada sistema Ubuntu:
sudo apt-get update &&
sudo apt-get install unattended-upgrades
No necesita crear su propio trabajo cron. El paquete instala uno para ti.
Puede editar la configuración predeterminada si desea modificar su comportamiento: https://help.ubuntu.com/lts/serverguide/automatic-updates.html
Hemos estado utilizando unattended-upgradesdesde 2015 hasta 2020 sin problemas. Tenemos una pequeña configuración (en DigitalOcean) con:
nginxmysql-serverphp5-fpm php5-curl php5-mysqlBasado en un buen desempeño pasado, hacer actualizaciones de esta manera se siente más seguro que no hacerlo. ¡Pero eso no es necesariamente una garantía para el futuro!
Es posible que no sea una buena idea apache, según los informes de otros usuarios y mi experiencia previa de apacheactualizaciones. [Ver arriba y aquí ]
Con unattended-upgrades, la intervención manual seguirá siendo necesaria cuando la versión se acerque a EOL .
(Aparte de la pregunta: en mi experiencia con TWiki, WordPress y Jenkins, mantener estas aplicaciones actualizadas es en realidad una preocupación mayor que el sistema operativo en sí, aunque, por supuesto, deberíamos hacer ambas cosas. Para su tranquilidad, podría poner aplicaciones sandbox a Internet como procesos no root que se ejecutan dentro de un contenedor Docker).
Pero como usted preguntó sobre las mejores prácticas , el enfoque principal recomendado en la documentación de AWS es:
Cree e inicie nuevas instancias para reemplazar sus instancias en línea actuales. Luego elimine las instancias actuales.
Las nuevas instancias tendrán el último conjunto de parches de seguridad instalados durante la instalación.
(Febrero 2020)
Esto se puede hacer como parte de una estrategia de implementación azul-verde . La ventaja aquí es que puede ejecutar pruebas en su nuevo servidor antes de cambiar el tráfico. Si sus pruebas son exhaustivas, entonces, en teoría, sus actualizaciones se pueden automatizar completamente, verificar antes de ponerlas en funcionamiento y sin tiempo de inactividad.
Otras ventajas:
Las pruebas pueden proporcionarle una advertencia avanzada si se requiere atención humana (a diferencia de unattended-upgradescuando las advertencias solo provienen de sus usuarios una vez que el problema está vivo).
Si su sistema se ve comprometido, o si decide cambiar de proveedor, este enfoque debería facilitar el despliegue de una nueva implementación. Su estrategia de despliegue está programada, en lugar de memoria antigua.
Pero, por supuesto, se requiere más configuración para este enfoque que simplemente la instalación unattended-upgrades, y más complejidad, por lo que aún hay margen de error.
AWS también menciona la ejecución del "comando de pila Actualizar dependencias", que parece ser su forma oficial de hacer algo similar unattended-upgrades. Parece que se puede activar desde su interfaz de instancias, pero no estoy seguro de si se puede automatizar.