Mejores prácticas para mantener actualizadas las máquinas EC2 Ubuntu

12

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?

unattended-upgrades Adam Matan
fuente

Respuestas:

13

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

Eric Hammond
fuente
¿Alguna idea sobre la conveniencia de hacer esto en un servidor de producción? Me pone nervioso tener cambios silenciosamente aplicados y arriesgar la posibilidad de que la actualización falle o presente problemas.
ianjs
3
Por "cada" me refería a los sistemas de producción, también. He estado aplicando automáticamente parches de seguridad de Ubuntu durante muchos años y no puedo recordar ningún problema grave. Me pone nervioso tener un servidor de producción sentado sin parches para problemas de seguridad conocidos y arriesgar la posibilidad de explotarlos. Dicho esto, cada situación tiene diferentes necesidades, por lo que es mejor pasar por una fase de prueba rigurosa para cada parche. Sin embargo, tenga en cuenta que se lanzan todo el tiempo, por lo que estará ocupado.
Eric Hammond
1
Yo no aconsejaría a este a menos que tenga una configuración redundante / cluster. Los procedimientos de actualización de Ubuntu no están a la altura, he interrumpido los servicios varias veces y, más recientemente, incluso un sector de arranque roto ... Y no hacemos nada especial, solo Apache como proxy inverso y aplicaciones Tomcat.
dualeado
1

Hemos estado utilizando unattended-upgradesdesde 2015 hasta 2020 sin problemas. Tenemos una pequeña configuración (en DigitalOcean) con:

  • nginx
  • mysql-server
  • php5-fpm php5-curl php5-mysql

Basado 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.

joeytwiddle
fuente