Security Center:Gestionar vulnerabilidades

Corregir vulnerabilidades

Aplace la solución (Ignore o Add to Whitelist)

Si determina que una vulnerabilidad no requiere corrección, ignórela o agréguela a una lista blanca para evitar alertas repetidas.

• Add to Whitelist: Esta acción suprime las alertas de un tipo específico de vulnerabilidad dentro del alcance configurado. El alcance predeterminado abarca todos los activos. Esto podría hacer que pase por alto riesgos de seguridad relacionados. Use esta función con precaución.

• Práctica recomendada para componentes del sistema Kubernetes: Las vulnerabilidades de alto riesgo en componentes básicos de Kubernetes, como csi-plugin o los plugins de CNI, suelen existir porque estos componentes requieren privilegios elevados para funcionar. Según las mejores prácticas de la industria de seguridad, generalmente es aceptable confiar en estos componentes proporcionados por el proveedor. Se recomienda agregar estos riesgos conocidos y necesarios a la lista blanca para reducir el ruido de las alertas.

• Ignore: La operación de ignorar afecta únicamente al proceso actual. Si la aplicación se reinicia o se inicia un nuevo proceso, Security Center podría detectar la vulnerabilidad nuevamente.

Procedimiento de remediación

1. Antes de la remediación

   • Confirmación de activos: Compruebe que las versiones de software afectadas estén presentes en los activos de sus servidores.

   • Evaluación de riesgos: Evalúe el impacto en el negocio para determinar la urgencia y necesidad de la remediación. No todas las vulnerabilidades requieren atención inmediata.

   • Pruebas exhaustivas: Despliegue el parche en un entorno de pruebas. Valide por completo su compatibilidad y seguridad, y luego genere un informe de pruebas detallado.

   • Copia de seguridad de datos: Cree una copia de seguridad completa del servidor, por ejemplo, mediante una instantánea de ECS, para poder revertir los cambios rápidamente si ocurre un error.

   • Programación de la remediación: Ejecute la remediación fuera del horario de mayor actividad para minimizar el impacto en el negocio.

2. Durante la remediación

   • Operación con dos personas: Asegúrese de que haya como mínimo dos profesionales presentes. Para evitar errores, un profesional ejecuta la operación mientras otro la revisa y la registra.

   • Seguimiento del plan: Siga estrictamente el plan de remediación y aplique las correcciones de forma secuencial.

3. Después de la remediación

   • Verificación de resultados: Confirme que la vulnerabilidad se corrigió y que todas las funciones del sistema y las aplicaciones de negocio se ejecutan correctamente.

   • Archivo de documentación: Documente todo el proceso en un informe final de remediación de vulnerabilidades y archívelo.

Mitigación de riesgos

• Elabore un plan detallado: Diseñe un plan de remediación viable que haya sido probado y validado a fondo. Siga estrictamente los pasos definidos durante la ejecución.

• Pruebe en un entorno simulado: Configure un entorno de pruebas idéntico al de producción —incluidos el sistema, las aplicaciones y los datos— para validar completamente el plan de remediación.

• Copia de seguridad completa del sistema: Seleccione la opción Automatically Create Snapshot and Fix Risk para crear una copia de seguridad completa del sistema, que incluye el sistema operativo, la aplicación y los datos. Compruebe que la copia de seguridad se pueda recuperar para asegurar que podrá restaurar los servicios rápidamente si surge algún problema.

Vulnerabilidades faltantes y problemas de escaneo

• No se muestran vulnerabilidades en la página de gestión de vulnerabilidades. ¿Qué debo hacer?

  Una lista de vulnerabilidades vacía puede indicar que no se detectaron riesgos actualmente o que el alcance de la consulta o el estado del servicio limita los resultados. Revise lo siguiente en orden:

  1. Revise la región: La lista de vulnerabilidades se muestra por región. El selector de región en la parte superior de la página (por ejemplo, the Chinese mainland) determina el alcance de la consulta. Cambie a la región de sus activos objetivo y actualice la página.

  2. Revise la edición y el estado de activación: Algunas capacidades de detección de vulnerabilidades dependen de un servicio de valor agregado. Si la página muestra Pay-as-you-go vulnerability fixing: Not activated, la función correspondiente no está activada y el alcance disponible es limitado. Vaya a la página Overview para confirmar la edición y el estado de activación de Security Center.

  3. Inicie un escaneo manualmente: Si aún no se ha ejecutado ningún escaneo o el último fue hace mucho tiempo, haga clic en One-click scan en la parte superior de la página para iniciar uno y luego actualice la página cuando termine.

  4. Comprenda el estado vacío: Si pestañas como Linux software vulnerability o Windows system vulnerability muestran No records found, significa que no se detectaron resultados con las condiciones de filtro actuales. Este comportamiento es normal y no indica un mal funcionamiento. Cambie a otra pestaña, como Urgent Vulnerabilities, para confirmar que la página devuelve datos con normalidad.

  5. Distinga entre vulnerabilidades y alertas: Si recibió una alerta de seguridad, como un ataque saliente desde el servidor, pero la página de gestión de vulnerabilidades no muestra registros, tenga en cuenta que el escaneo de vulnerabilidades y las alertas son dos dimensiones de detección distintas. Una alerta no necesariamente corresponde a una vulnerabilidad. Consulte View and handle alert events para investigar el evento de seguridad.

Límites y principios de remediación

• ¿Por qué el botón Fix aparece atenuado?

  • Problema: Limitaciones de la edición del producto

    • Causa: La función one-click fix no es compatible con Basic Edition ni con Anti-virus Edition.

    • Solución: Adquiera el value-added service "Vulnerability Fixing" o actualice a Enterprise Edition o Ultimate Edition.

  • Problema: Problemas del lado del servidor

    Problemas en servidores Linux

    • El sistema operativo alcanzó el fin de su vida útil (EOL): El proveedor ya no proporciona patch. Debe actualizar manualmente el operating system. Corregir vulnerabilidades en los siguientes sistemas operativos requiere una actualización del SO:

      • Red Hat 5, Red Hat 6, Red Hat 7, Red Hat 8

      • CentOS 5

      • Ubuntu 12

      • Debian 8, 9, 10

    • Espacio en disco insuficiente: El espacio disponible en disco es menor a 3 GB. Libere espacio o amplíe el disco.

    • Proceso en uso: El proceso apt o yum se está ejecutando. Espere a que termine y vuelva a intentarlo, o finalice el proceso manualmente.

    • Permisos insuficientes: El usuario que ejecuta el comando de remediación no tiene permisos suficientes. Asegúrese de que el propietario del archivo sea el usuario root y establezca los permisos adecuados, como 755.

    Problemas en servidores Windows

    • Espacio en disco insuficiente: El espacio disponible en disco es menor a 500 MB. Libere espacio o amplíe el disco.

    • El servicio Windows Update no funciona como se espera: El servicio está deshabilitado o ya hay una instalación de patch en curso.

      • Si el servicio está deshabilitado, vaya al administrador de servicios en el server, habilite el servicio Windows Update y vuelva a intentar corregir la vulnerability.

      • Si hay una actualización en curso, espere a que finalice el proceso Wusa.exe o finalícelo manualmente, y luego intente corregir la vulnerability nuevamente.

• ¿Cuál es la diferencia entre una vulnerabilidad de aplicación y una de sistema? ¿Por qué la corrección con un clic no admite vulnerabilidades de aplicación?

  • Una system vulnerability, como una Linux software vulnerability o una Windows system vulnerability, afecta al operating system o a sus componentes. Estas vulnerabilidades tienen rutas de remediación estandarizadas, lo que permite corregirlas con la función one-click fix.

  • Una application vulnerability existe en una aplicación autogestionada, como el código de un sitio web o software de terceros. El método de remediación para este tipo de vulnerability está estrechamente ligado a su lógica de negocio y código específicos. Dado que las herramientas automatizadas no comprenden el contexto de su negocio, debe remediar estas vulnerabilidades manualmente.

• ¿Por qué mi servidor tiene tantas vulnerabilidades?

  A medida que surgen nuevos métodos de ataque, se descubren vulnerabilidades continuamente en software antiguo. El escaneo y la aplicación de parches de forma regular son tareas de seguridad esenciales y continuas. Para ayudarle a concentrarse en los riesgos más críticos, active el interruptor Show Only Exploitable Vulnerabilities.

Operaciones de remediación

• ¿Qué debo hacer si aparece el error "Permission acquisition failed, please check permissions and retry" al ejecutar un comando de corrección?

  • Causa: El propietario del archivo necesario para la operación de reparación no es root, lo que provoca permisos insuficientes.

  • Solución:

    1. Localice el archivo:

       En Security Center, consulte los detalles de la vulnerability para identificar el archivo y la ruta específicos que requieren remediación.

    2. Modifique los permisos:

       Inicie sesión en el servidor y ejecute el siguiente comando para cambiar el propietario del archivo a root.

    3. Reintente la corrección:

       Regrese a la Security Center console y vuelva a ejecutar la operación de remediación en la vulnerability.

• Cuando corrijo vulnerabilidades por lotes, ¿en qué orden se corrigen?

  Las Linux software vulnerability se corrigen en el orden en que aparecen en la lista de la console. Algunas Windows system vulnerabilities requieren que primero se instale un patch previo. Cuando ejecuta una corrección por lotes para Windows system vulnerabilities, estos tipos de vulnerabilidades tienen prioridad. Las vulnerabilidades restantes se corrigen en el orden en que aparecen en la lista de la console.

• ¿Por qué no funciona el reinicio después de corregir una vulnerabilidad del kernel en Ubuntu?

  • Síntoma: Después de usar la función de corrección con un clic en Security Center para aplicar un parche a una vulnerabilidad del kernel en un servidor Ubuntu, se muestra el mensaje "Fixed, pending restart". Sin embargo, tras reiniciar el servidor, la alerta de vulnerabilidad persiste porque el sistema no utiliza el nuevo kernel instalado.

  • Causa: Este problema suele ocurrir si se modificó manualmente el orden de arranque predeterminado del menú de arranque de GRUB. En ese caso, el script de remediación no logra establecer el nuevo kernel como opción de arranque predeterminada.

  • Solución:

    Solución 1: Configurar automáticamente el nuevo kernel

    Esta solución descarta su configuración personalizada actual de GRUB y permite que el sistema aplique automáticamente la configuración predeterminada para el nuevo kernel.

    Procedimiento:

    1. Antes de corregir la vulnerabilidad, inicie sesión en su server Ubuntu.

    2. Ejecute el siguiente comando para establecer la variable de entorno:

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Regrese a la Security Center console y ejecute una corrección con un clic en la vulnerability.

    4. Una vez completada la corrección, reinicie el server según las indicaciones. El sistema habilita automáticamente el kernel más reciente.

    Solución 2: Modificar manualmente el orden de arranque

    Utilice esta solución si necesita conservar su configuración actual de GRUB.

    Procedimiento:

    1. En la Security Center console, ejecute una one-click fix y reinicie el server según las indicaciones.

    2. Después de que el server se reinicie, inicie sesión en su server Ubuntu.

    3. Modifique manualmente el orden de arranque de GRUB para establecer la versión del kernel recién instalado como opción de arranque predeterminada.

       Nota

       Este procedimiento generalmente implica modificar el archivo /etc/default/grub y ejecutar el comando update-grub. Para obtener más información, consulte Change the kernel boot order of an ECS Linux CentOS instance.

    4. Reinicie el server nuevamente para que el nuevo orden de arranque surta efecto.

• ¿Necesito reiniciar el sistema después de corregir una vulnerabilidad?

  • Windows: Se requiere un reinicio.

  • Linux Software Vulnerability: Se requiere un reinicio si se cumple alguna de las siguientes condiciones:

    • Se corrigió una kernel vulnerability.

    • En la pestaña Linux Software Vulnerability de la página Risk Governance > Vulnerabilities en la consola de Security Center, el boletín de la vulnerability tiene la etiqueta Restart Required.

• ¿Por qué falla una operación de reversión de vulnerabilidad?

  Si una operación de vulnerability rollback falla, investigue las siguientes causas posibles:

  1. Compruebe el estado del agente

     La operación de reversión requiere que el Security Center agent esté en línea. Si el agent está desconectado, el comando no se puede entregar. Primero debe solucionar el problema de desconexión del agente.

  2. Confirme que la instantánea de copia de seguridad sea válida

     La función de reversión depende de la backup snapshot creada antes de la remediación. Si la snapshot caducó o se eliminó manualmente, la operación de reversión no se puede ejecutar.

• ¿Por qué falla la creación de la instantánea al corregir una vulnerabilidad?

  La creación de una snapshot puede fallar por las siguientes razones:

  • Operación ejecutada por un usuario de RAM: Si un RAM user sin el permission requerido ejecuta la operación, la creación de la snapshot falla. Se recomienda utilizar su Alibaba Cloud account para ejecutar la operación. Para obtener más información sobre el RAM user, consulte Overview.

  • Servidor externo a Alibaba Cloud: La creación de instantáneas para la remediación de vulnerabilidades no es compatible con un non-Alibaba Cloud server.

Estado posterior a la remediación y verificación

• Corregí una vulnerabilidad, pero Security Center la sigue reportando. ¿Qué debo hacer?

  • Causa: Este problema ocurre porque algunas vulnerabilidades, como las de kernel de Linux, requieren reiniciar el server después de la remediación.

  • Solución: En la página de detalles de la vulnerability, haga clic en Restart. Una vez completado el reinicio, haga clic en Verify. Si el estado cambia a Repaired, la vulnerability se corrigió correctamente.

• Corregí una vulnerabilidad sin actualizar la versión del software, pero Security Center la sigue reportando. ¿Qué debo hacer?

  • Causa: Security Center detecta las Application Vulnerability y las Urgent Vulnerability comparando el número de versión del software o componente. Si mitiga una vulnerabilidad en lugar de actualizar a una versión segura, por ejemplo, habilitando SafeMode en fastjson para deshabilitar AutoType, el número de versión permanece dentro del rango afectado. Los escaneos posteriores seguirán reportando la vulnerabilidad y hacer clic en Verify no cambiará el estado a corregido.

  • Solución: Después de confirmar que la mitigación eliminó el riesgo, vaya a la página Vulnerabilities y aplique Ignore o Add to Whitelist a la vulnerabilidad para detener las alertas repetidas. La opción Ignore solo surte efecto para el proceso actual. Si la aplicación se reinicia o inicia un nuevo proceso, Security Center podría detectar la vulnerabilidad nuevamente. La opción Add to Whitelist suprime las alertas para este tipo de vulnerabilidad dentro del alcance configurado hasta que elimine manualmente la regla de lista blanca. Para conocer las diferencias entre ambas acciones y sus procedimientos correspondientes, consulte la sección "Posponer la remediación" de este tema.

• ¿Por qué el estado de las correcciones de vulnerabilidades de Windows cambia a "Invalid"?

  El mecanismo de detección de vulnerabilidades de Windows se actualizó. Tras las actualizaciones mensuales de las reglas de vulnerabilidades de Windows, el estado de las vulnerabilidades existentes afectadas por estos cambios de reglas se marcará como "Invalid".

• Después de corregir una vulnerabilidad, ¿por qué la consola sigue mostrando el estado "Not fixed"?

  Esto puede deberse a las siguientes razones:

  1. Retraso en la verificación: Después de una corrección manual, debe hacer clic en el botón Verify para iniciar un escaneo inmediato. La actualización del estado puede tardar unos minutos.

  2. Caché del navegador: Es posible que la página de la console esté almacenada en la caché de su navegador. Intente forzar la actualización de la página o espere unos minutos.

  3. Corrección incompleta: Es posible que la operación de remediación no se haya completado por completo. Por ejemplo, una vulnerability puede tener varias rutas vulnerables, pero solo se corrigió una. Revise los pasos de remediación e inténtelo de nuevo.

• Fixed and Pending Restarted: ¿Security Center puede verificar automáticamente una vulnerabilidad en este estado?

  No. Debe reiniciar el server desde la Security Center console o reiniciarlo manualmente. Después de que el server se reinicie, haga clic en Verify para confirmar que la vulnerability está corregida.

  Importante

  Si no verifica la corrección manualmente, Security Center comprueba el estado automáticamente durante el siguiente escaneo programado. Para evitar falsos negativos por problemas de red, el sistema conserva el registro de la vulnerability durante tres días si no se detecta en el primer escaneo. Si la vulnerability no se detecta durante tres días consecutivos, el sistema elimina el registro.

• ¿Por qué el estado de verificación no se actualiza después de corregir manualmente una vulnerabilidad?

  Si después de corregir manualmente una vulnerabilidad en un servidor la función 'Verify' en la consola de Security Center no actualiza el estado de la vulnerabilidad a 'Fixed', este problema suele deberse a dos razones:

  • El nivel de escaneo de vulnerabilidades no está completamente configurado

    • Causa: Security Center escanea y actualiza el estado únicamente para los niveles de riesgo seleccionados en Vulnerability Settings. Si el nivel de riesgo de la vulnerability objetivo, como High o Medium, no está seleccionado, el sistema no actualiza su estado.

    • Solución: Revise la configuración de escaneo en Vulnerability Settings y asegúrese de que el nivel de riesgo de la vulnerability objetivo esté seleccionado.

  • El agente de Security Center está desconectado

    • Motivo: La función 'Verification' depende de la comunicación en tiempo real entre la consola y el cliente en el servidor. Si el cliente está desconectado, la consola no puede enviar comandos de verificación ni recibir los resultados.

    • Solución: Solucione el problema de desconexión del agent. Una vez que el agent vuelva a estar en línea, intente verificar de nuevo.