La aplicación de parches y la actualización de los sistemas es un paso clave para reducir los posibles vectores de ataque contra su infraestructura. Cuando hay sistemas en su entorno que no están actualizados con los parches, podría haber vectores de ataque que usted no sabe que podrían afectar a toda su organización. Sin embargo, ¿qué pasos tiene implementados cuando un evento de aplicación de parches no sale como se esperaba?
[ A los lectores también les gustó: Proteger un sistema Linux heredado]
Por ejemplo, es posible que no se cumplan las dependencias, que haya versiones que no coincidan entre los RPM i686 y x86_64, que las nuevas versiones del paquete no funcionen como se esperaba o que algo más pueda salir mal. Cuando algo sale mal, es importante tener un plan sobre cómo proceder. Esto reducirá el nivel de estrés y garantizará que todos los que trabajen en la tarea sepan lo que están haciendo los demás.
Parches de prueba
Al aplicar parches, es importante probar primero los parches en un entorno de prueba. que coincida con su entorno de producción . Si prueba los parches en hardware diferente, con versiones de software diferentes o con cargas de trabajo o procesos diferentes a los de su entorno de producción, no hay garantía de que los resultados de la prueba de parches reflejen lo que sucederá en producción. Una vez que tenga un entorno de prueba donde pueda verificar que se debe instalar un paquete de parches determinado, reducirá en gran medida las posibilidades de problemas al instalar las actualizaciones.
Parches fallidos
Si las actualizaciones no se instalan, lo primero que debe hacer es capturar cualquier resultado en la consola o en los registros. Esto podría ser simplemente copiar un archivo de registro en una ubicación separada, o podría estar copiando el texto que se muestra en la pantalla de la consola. Dependiendo de cómo se haya intentado la aplicación de parches, es posible que desee volver a ejecutar las actualizaciones, esta vez con la salida detallada habilitada. Una vez que tenga la salida de error, querrá ver las diferencias entre su entorno de prueba y lo que tiene en producción. También debe verificar que todos los parches se aplicaron en las pruebas y que no se omitieron parches ni errores accidentalmente. Un elemento esencial que debe verificar es la lista de RPM instalados en su servidor de prueba para comparar con las versiones en su servidor de producción.
Por ejemplo, en el servidor de producción:
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'| sort &> /tmp/rpm-qa.prod.output.txt
Luego podría comparar eso con la salida recopilada en su servidor de prueba en su /tmp/rpm-qa.dev.output.txt .
También debe verificar para asegurarse de que el yum disponible Los repositorios son los mismos en ambos sistemas. Puede hacerlo en tres sencillos pasos.
Primero, borre el caché:
# yum clean all
# rm /var/cache/yum/* -rf A continuación, actualice el administrador de suscripciones:
# subscription-manager refresh
Tercero, enumere los repositorios en yum con el -v argumento para que pueda ver información adicional, como el reemplazo y el número de paquetes en los repositorios:
# yum repolist -v En el siguiente ejemplo, veremos el rhel-8-for-x86_64-appstream-rpms repositorio utilizado por un cliente en mi servidor Red Hat Satellite:
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision: 1605844838
Repo-updated : Thu 19 Nov 2020 11:02:03 PM EST
Repo-pkgs : 13,502
Repo-size : 31 G
Repo-baseurl : https://opendemo.usersys.redhat.com/pulp/repos/opendemoorg/Library/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 1 second(s) (last: Wed 31 Dec 1969 07:00:00 PM EST)
Repo-filename: /etc/yum.repos.d/redhat.repo Las líneas clave aquí son repo-id , repo-actualizado , paquetes de repositorio y repo-baseurl . Si mis sistemas de prueba y producción muestran información diferente para sus repositorios ascendentes, existe la posibilidad de que no se cumplan las dependencias o que algo más falle. Si ese es el caso, deberá investigar por qué los sistemas ven información diferente.
Otras configuraciones
Suponga que los sistemas de prueba y producción tienen los RPM esperados y los mismos repositorios, pero la aplicación de parches sigue fallando. En ese caso, otras causas posibles podrían ser una configuración de seguridad mal aplicada, poco espacio en disco o quizás permisos de usuario incorrectos. Para investigarlos, verifique registros como /var/log/messages , /var/log/secure y /var/log/audit/audit.log podría ser útil, además de usar el comando df -h para comprobar el espacio en disco. Además, los clientes de Red Hat pueden abrir un ticket de soporte para obtener ayuda para resolver el problema.
[ Curso gratuito en línea:Descripción general técnica de Red Hat Enterprise Linux. ]
Resumir
Existen muchas causas posibles para que los parches no se instalen correctamente, pero poder comparar su entorno de prueba con su entorno de producción facilitará mucho la resolución de problemas. Las configuraciones, las dependencias, las cargas de trabajo y los repositorios deben ser todos iguales en los dos entornos.