por favor, perdona esta pregunta bastante sencilla.
En primer lugar, no soy un administrador de sistemas, y mi experiencia con Linux es algo limitada.
Hace unos 3-4 meses, configuré un servidor CentOS en el trabajo, por una variedad de razones. Lo estamos utilizando como servidor de desarrollo para sitios web (a los que nuestros clientes tienen acceso), servidor de subversión, y también estamos alojando un wiki para comunicación interna, por lo que se ha convertido en una herramienta bastante importante para nosotros. (¡Probablemente más importante de lo que pensamos que sería cuando lo configurara!)
Me ha llamado la atención que Yum quiere actualizar unos 250 paquetes a las últimas versiones en el repositorio.
Dado que el servidor funciona bien para nosotros, ¿debería correr el riesgo de actualizar estos paquetes? ¿Los riesgos de seguridad superan el riesgo de que el servidor se rompa cuando actualizo todo?
Debo señalar que si bien tengo copias de seguridad de todo, tomaría tiempo configurar todo de la forma en que está ahora, ¡y no tengo mucho tiempo libre en el trabajo en este momento!
Si el consejo es actualizar, ¿hay alguna mejor práctica que se pueda transmitir para que el proceso sea lo más seguro posible?
Gracias de antemano por cualquier consejo.
ACTUALIZACIÓN - Gracias por sus respuestas a todos. Si tuviera suficiente representante para votar a todos, lo haría. ;) He decidido crear un fantasma en el disco duro y actualizarlo. Desafortunadamente, conseguir un administrador de sistemas de tiempo completo o parcial no es una opción en este momento, ¡así que tendré que lidiar con el problema lo mejor que pueda!
Si, actualizar.
RHEL (y, por lo tanto, CentOS) tienen cuidado de no actualizar las versiones a nada incompatible, sino que soportan correcciones de errores y correcciones de seguridad, por lo que los cambios reales en los paquetes son mínimos y es poco probable que causen problemas de compatibilidad.
Si algún archivo de configuración ha cambiado, los paquetes le informarán sobre un archivo .rpmorig o .rpmnew que se crea. Depende de la configuración del propio RPM. Puede buscar advertencias sobre cualquiera de los que se están creando y volver a poner su configuración anterior ("
cp foo foo.bak; cp foo.rpmorig foo") o mirar los archivos .rpmnew e incorporar cualquier cambio en su configuración.El problema es menos notable si actualiza regularmente.
Tenemos muchos sistemas que se actualizan trimestralmente (cada 3 meses); y muy raramente ve algún problema por las actualizaciones de paquetes. (excepto en sistemas que hacen cosas extrañas del núcleo para acceder a LUN desde una SAN)
fuente
Si bien sí, tomaría tiempo actualizarse, y de la misma manera, tomaría tiempo restaurar si algo salía mal, ¿Cuánto dolor / sufrimiento sería si los datos en ese sistema fueran eliminados a través de un exploit / hack?
En su mayor parte, las actualizaciones de los repositorios base de CentOS son seguras de instalar. La única vez que he tenido problemas de actualización con CentOS es cuando inicio o necesito usar un repositorio externo (DAG, RPMForge, Ect, etc.).
La mejor configuración para este tipo de cosas es tener un servidor intercambiable en caliente listo, para que pueda probar las actualizaciones en él antes de implementarlas en el servidor en vivo.
fuente
Parece que necesita un administrador del sistema real para tomar un par de horas para revisar su sistema, actualizarlo y asegurarse de que todo vuelva a funcionar. Lo ideal sería que esta persona viniera y hiciera esto por usted varias veces al mes. Un servidor no es una cosa de instalar una vez y olvidarlo; Necesita servicio regular.
fuente
Si este sistema es tan importante, las actualizaciones de seguridad se vuelven aún más importantes. Considere las implicaciones si ese sistema tiene que desmontarse para una reconstrucción si (¿cuándo?) Un paquete desactualizado permite un compromiso del sistema. Idealmente, debería tener un servidor de prueba configurado de manera similar que podría actualizar primero y verificar si algo se rompe.
Cuando aplique actualizaciones, debe asegurarse de algunas cosas:
Un buen administrador de sistemas tendría experiencia en este tipo de trabajo y debería hacer todas esas cosas de todos modos. Si su organización tiene alguna, entonces este podría ser el momento de volcar la administración del sistema en ellas. O si está nervioso de hacer esto usted mismo, busque contratar a alguien por contrato para hacer este tipo de mantenimiento de rutina. De cualquier manera, las actualizaciones deben realizarse, ya que te estás abriendo a una situación mucho peor en el futuro.
fuente
Es por eso que hoy casi nunca ejecuto ningún sistema de producción en hardware real. Los ejecuto en máquinas virtuales. Luego, durante un breve período de inactividad (5 minutos), ejecuto una instantánea desde ESX, o si estoy usando una configuración personalizada de Xen / Solaris / OpenVZ, hago una instantánea LVM de la imagen del servidor. Luego reinicio el original, y ahora tengo una copia con la que puedo hacer lo que quiera.
Dicho esto, comience con la actualización del kernel y apache, y luego trabaje hacia atrás desde allí. No tiene que tomar la lista completa de paquetes que reporta yum, pero los principales vectores de ataque deberían ser los que parche antes.
Cada vez que tengo un sistema Linux hackeado, es porque dejé apache, openssh o el kernel sin parchar.
fuente
Simplemente actualizaría los paquetes relacionados con la seguridad.
fuente
Hace exactamente un año surgió exactamente eso ... Hice la actualización yum en la caja de CentOS, ejecutándose en el hardware de Dell e instaló un kernel que no arrancaba. La caja todavía no tenía nada cargado (de lo contrario habría sido más cauteloso). Pasé mucho tiempo jugando y parece que hay alguna incompatibilidad entre los núcleos más nuevos de CentOS / Linux y esa caja de Dell. Sé muy cauteloso con tus actualizaciones. Todavía recomiendo actualizar, ya que es lo correcto, ¡pero prepárate para recuperarte de un sistema basura!
fuente