Solución 1:
No hay nada especial en parchear Ubuntu frente a Windows, RHEL, CentOS, SuSE, Debian, etc.
El estado mental básico en el que debe estar al diseñar su procedimiento de parche es asumir que algo lo hará descanso.
Algunas de las pautas básicas que tiendo a usar al diseñar una configuración de parche son:
- Utilice siempre un sistema local para centralizar internamente en su red desde donde se instalan los parches
Esto puede incluir el uso de WSUS o espejos de <your_os_here> a una máquina interna de administración de parches. Preferiblemente uno que pueda consultar de forma centralizada y hacerle saber el estado de los parches instalados en sus máquinas individuales.
- Preparar las instalaciones, cuando sea posible, en las máquinas.
Cuando sea posible, a medida que salgan los parches, haga que el servidor central los copie en las máquinas individuales. Esto realmente es solo un ahorro de tiempo para que no tenga que esperar a que se descarguen E instalen, solo tiene que iniciar la instalación durante la ventana del parche.
- Obtenga una ventana de interrupción para instalar los parches, es posible que deba reiniciar y es probable que algo se rompa. Asegúrese de que las partes interesadas de esos sistemas sepan que se están implementando parches. Esté preparado para las llamadas "esto" no funciona.
De acuerdo con mi teoría básica de que los parches rompen cosas, asegúrese de tener una ventana de interrupción para aplicar parches el tiempo suficiente para solucionar problemas críticos y posiblemente revertir el parche. No necesariamente necesita tener personas sentadas allí probando después de los parches. Personalmente, confío en gran medida en mis sistemas de monitoreo para saber que todo funciona al nivel mínimo que podemos lograr. Pero también prepárese para los pequeños problemas molestos que se presentarán cuando la gente se ponga a trabajar. Siempre debe tener a alguien programado para estar allí listo para contestar el teléfono, preferiblemente no el tipo que estuvo levantado hasta las 3 a.m. parcheando las cajas.
- automatizar tanto como sea posible
Como todo lo demás en TI, script, script y luego script un poco más. Escriba la descarga del paquete, el inicio de la instalación, el espejo. Básicamente, desea convertir las ventanas de parches en una tarea de niñera que solo necesita un humano allí en caso de que las cosas se rompan.
- Tenga varias ventanas cada mes
Esto le da la posibilidad de no parchear algunos servidores si por alguna razón no pueden ser parcheados en "la noche designada". Si no puede hacerlo en la noche 1, exija que estén libres en la noche 2. También le permite mantener la cantidad de servidores parcheados al mismo tiempo.
Lo más importante es ¡mantente al día con los parches! Si no lo hace, se encontrará con que tiene que hacer ventanas de parche muy grandes de más de 10 horas solo para volver al punto en el que está atrapado. Introduciendo aún más puntos en los que las cosas podrían salir mal, y haciendo que encontrar qué parche causó y problema fue mucho más difícil.
La otra parte de este problema es que mantenerse al día con los parches es 'algo bueno', pero los parches se lanzan casi a diario. ¿Cuántas interrupciones programadas se deben realizar si hay un nuevo parche de seguridad disponible todos los días?
Parchear un servidor una vez al mes o una vez cada dos meses es, en mi humilde opinión, un objetivo muy alcanzable y aceptable. Más que eso, y bueno, estará constantemente parcheando servidores, mucho menos y comienza a meterse en situaciones en las que tiene cientos de parches que deben aplicarse por servidor.
¿En cuanto a cuántas ventanas necesita al mes? Eso depende de tu entorno. ¿Cuántos servidores tienes? ¿Cuál es el tiempo de actividad requerido para sus servidores?
Los entornos más pequeños que son 9x5 probablemente puedan salirse con la suya con una ventana de parche al mes. Las tiendas grandes 24x7 pueden necesitar dos. Es posible que un servidor muy grande las 24 horas del día, los 7 días de la semana, los 365 días del año necesite una ventana continua cada semana para tener un conjunto diferente de servidores parcheados cada semana.
Encuentre una frecuencia que funcione para usted y su entorno.
Una cosa a tener en cuenta es que 100% actualizado es un imposible meta a alcanzar - no deje que su departamento de seguridad le diga lo contrario. Haz tu mejor esfuerzo, no te quedes demasiado atrás.
Solución 2:
Cosas que hacer:
- Realizar una copia de seguridad
- Asegúrese de que sea una copia de seguridad restaurable (aunque estos dos son puntos generales)
- Intente desviar el tráfico de la caja de producción mientras realiza la actualización.
- Trate de tener un método de acceso fuera de banda en caso de que todo salga mal, KVM, consola serie, acceso local o manos remotas.
- Pruebe en un servidor, luego asegúrese de que todo funcione, antes de implementar actualizaciones en más servidores
- Utilice una marioneta si puede para asegurarse de que los números de versión sean los mismos en varios servidores. (También puede usarlo para forzar actualizaciones)
- En un servidor de prueba, compare las versiones de los archivos de configuración con los nuevos (actualización instalada) y asegúrese de que nada vaya a romper seriamente las cosas. Me parece recordar que dpkg preguntó antes de instalar nuevas versiones que difieran de las instaladas actualmente.
Cosas a evitar:
- Hacer actualizaciones a la mitad del día, o a las 09:00 un lunes por la mañana, o a las 5:00 p. m. un viernes por la tarde. (¡gracias @3influence!)
- Actualización de MySQL en servidores de bases de datos realmente grandes (el reinicio puede llevar mucho tiempo)
- Hacer todos sus servidores a la vez (especialmente kernels)
- Hacer cualquier cosa que pueda cambiar /etc/networks (porque podría perder la conectividad)
- Actualizaciones automáticas que podrían hacer lo anterior sin que usted esté allí para verificar que todo esté bien.
Solución 3:
Otro punto que vale la pena mencionar:si está acostumbrado a Windows, se sorprenderá de que la mayoría de las actualizaciones de Linux no. requieren tiempo de inactividad o reinicio. Algunos lo hacen, como las actualizaciones del kernel. Pero las actualizaciones que requieren reinicio o tiempo de inactividad generalmente se marcan como tales y se pueden manejar en un horario separado.
Solución 4:
Todas nuestras máquinas Ubuntu ejecutan versiones LTS.
Simplemente instalamos automáticamente todas las actualizaciones; seguro que no es la "mejor práctica", pero somos una tienda relativamente pequeña y no tenemos un entorno de prueba/desarrollo/producción para cada servicio. Las actualizaciones de LTS generalmente están bastante bien probadas y son mínimamente invasivas de todos modos.
La actualización a una nueva versión obviamente es un poco más complicada.
Solución 5:
Tratamos las actualizaciones de la siguiente manera para los sistemas ubuntu LTS:
- Mantener un conjunto de pruebas de aceptación que verifican todas las rutas críticas en nuestro software
- Instale actualizaciones de seguridad sin supervisión a las 4 a. m. todas las mañanas y ejecute de inmediato las pruebas de aceptación. Si algo falla, se llama a un ingeniero y este tiene mucho tiempo para arreglar las cosas o retroceder antes de las 9 a.m. Hasta ahora, esto ha sucedido solo dos veces en cinco años:LTS está bien probado y es estable.
- Volvemos a implementar automáticamente toda nuestra infraestructura cada semana (en digitalocean) con implementaciones azul/verde, lo que mantiene todos los paquetes en sus últimas versiones. Si una nueva implementación falla las pruebas de aceptación, la implementación se suspende hasta que un ingeniero pueda solucionar el problema.
El siguiente paso lógico para nosotros es eliminar la información de la sesión en memoria para que podamos simplemente volver a implementar la infraestructura todos los días o incluso varias veces al día sin afectar a los clientes y eliminar el paso (2).
Este enfoque es de bajo mantenimiento y evita las ventanas de mantenimiento por completo.