Security Center:Gerenciar vulnerabilidades

Procedimento

1. Na página Vulnerabilities, clique em Vulnerability Settings no canto superior direito.

2. Na tabela Vulnerability Auto-remediation Settings, ative a chave Automatic Vulnerability Remediation.

3. Configure a política de correção automática

   • Vulnerability Auto-Fix Schedule

     Importante

     A correção de vulnerabilidades pode ser arriscada. Recomendamos aplicar correções fora do horário de pico para minimizar o impacto nos seus negócios.

     • Task Type: Selecione One-time (executa apenas uma vez) ou Cycle (executa periodicamente).

     • Execution Date : Este parâmetro é necessário apenas quando o Task Type está definido como One-time. Configure a data e hora específicas para a execução da tarefa.

     • Execution Cycle: Este parâmetro é necessário apenas quando o Task Type está definido como Cycle. Defina o ciclo como Every Day ou Every Week.

     • Execution Time: Este parâmetro é necessário apenas quando o Task Type está definido como Cycle. Especifique o horário para a execução da tarefa.

   • Vulnerability Fix Configuration

     • Vulnerability Level: Selecione um Vulnerability Level para filtrar as vulnerabilidades que exigem correção.

     • Select Manually: Filtre as vulnerabilidades que exigem correção com base na Vulnerability selecionada.

   • Snapshot Configuration

     Aviso

     Se você ativar a chave de snapshot, taxas adicionais de snapshot serão incorridas quando a tarefa de correção de vulnerabilidade for executada. A criação e retenção de snapshots incorrem em taxas. O serviço de snapshot cobra essas taxas. Por padrão, o método de faturamento é pagamento conforme o uso.

     • Chave Snapshot Configuration: Se você ativar esta chave, o sistema cria um backup de snapshot quando uma tarefa de correção é executada. Se ocorrer um problema, use o snapshot para reverter o sistema e restaurar rapidamente seus serviços.

     • Snapshot Name: Defina um nome descritivo, como vulnerability-fix-snapshot.

     • Storage Time: Defina a duração de armazenamento do snapshot.

4. Configure o Auto-Repair Asset

   • All Assets: Corrige todos os ativos nos quais vulnerabilidades corrigíveis foram detectadas.

     Importante

     A correção consome cotas de Correção de Vulnerabilidades. Para evitar consumo desnecessário, use esta opção com cautela.

   • By Asset: Especifique os ativos nos quais as tarefas de correção automática podem ser executadas.

5. Após concluir a configuração, clique em Save.

Visualizar tarefas de correção automática

O sistema verifica periodicamente vulnerabilidades em seus servidores e as corrige com base no cronograma de correção automática configurado. Para visualizar os resultados da execução:

1. Na página Vulnerabilities, clique em Task Management no canto superior direito.

2. Na aba Auto-remediation Tasks, visualize as estatísticas de execução das tarefas de correção.

   Nota

   Um novo registro é gerado sempre que uma tarefa periódica é executada.

   • Status: Status de execução da tarefa.

   • Progress: Progresso de execução da tarefa.

   • Vulnerability Statistics: Número de correções bem-sucedidas e com falha.

   • Host Statistics: Número de hosts afetados.

3. Clique em Details na coluna Actions de uma tarefa para visualizar seus detalhes de execução.

4. Clique em no ícone ao lado de um servidor alvo para expandir os detalhes de todas as vulnerabilidades corrigidas, incluindo CVE ID, Handled At e Status.

Correção manual

Etapas de correção

1. Encontre o plano de correção

   Na lista de vulnerabilidades da aba correspondente, clique em no nome da vulnerabilidade desejada.

   • Application Vulnerability: Na aba Vulnerability Details, visualize o escopo afetado e as Fixing Suggestions.

     • Exemplo: Vulnerabilidades no Spring Framework ou Nacos: Siga as sugestões de correção nos detalhes da vulnerabilidade para modificar a configuração relevante, como uma versão de dependência em pom.xml ou uma configuração de autenticação em application.properties, e então reimplemente ou reinicie o serviço afetado. Antes de fazer alterações, crie um snapshot do ECS para fazer backup do servidor e valide a compatibilidade em um ambiente de teste antes de aplicar a alteração em produção.

     • Atualizar manualmente o OpenSSH em servidores Windows: Se uma atualização manual do OpenSSH ou componente similar falhar devido a espaço insuficiente em disco, libere espaço ou expanda o disco e tente a atualização novamente.

   • Linux Software Vulnerability ou Windows System Vulnerability:

     1. Na seção Vulnerability Details, clique em Fixing Suggestions na coluna Actions da vulnerabilidade.

     2. Na seção Solution Suggestions do Banco de Dados de Vulnerabilidades da Alibaba Cloud, visualize o plano de correção da vulnerabilidade. Siga o plano para fazer login no servidor e corrigir a vulnerabilidade.

2. Aplique o plano de correção

   1. Antes de fazer alterações, recomendamos criar manualmente um snapshot para fazer backup do servidor.

      Aviso

      A correção de vulnerabilidades pode ser arriscada. Recomendamos fazer backup dos dados do servidor antes de corrigir uma vulnerabilidade. Se o servidor com a vulnerabilidade for uma instância ECS da Alibaba Cloud, crie um snapshot para fazer backup dos dados. Para mais informações, consulte Create a snapshot.

   2. Faça login no servidor usando um método como SSH ou Área de Trabalho Remota.

   3. Execute os comandos necessários com base no plano de correção, como atualizar pacotes de software ou modificar configurações.

3. Visualize o resultado da correção

   Após uma correção manual, o status da vulnerabilidade não é atualizado imediatamente. Para vulnerabilidades de aplicação, como vulnerabilidades do OpenSSH, não é necessário alterar manualmente o nível da vulnerabilidade. Em vez disso, clique em Verify na coluna Operation, e o Security Center verificará automaticamente o servidor novamente. Assim que a verificação confirmar que a versão do componente está em conformidade, o status mudará automaticamente para Fixed.

   1. Após corrigir a vulnerabilidade, retorne ao console do Security Center.

   2. Clique em no nome da vulnerabilidade para abrir o painel de detalhes. Na lista Unhandled Vulnerabilities, localize o servidor onde você acabou de corrigir a vulnerabilidade.

   3. Clique em Verify na coluna Actions para confirmar a correção. Uma vez verificada, seu status muda para Fixed. Esta verificação de vulnerabilidade de aplicação aciona uma sincronização automática de status: recomendamos clicar em Verify imediatamente após concluir a correção manual. Se o status não mudar imediatamente, aguarde a próxima verificação agendada ou reinicie o servidor e clique em Verify novamente.

      Nota

      Se o status não for atualizado por muito tempo, a causa pode ser latência de rede ou problema de cache. Atualize a página mais tarde para verificar o status.

Caso de uso

1. Instalar manualmente um patch do Windows: Se uma correção com um clique falhar ou os detalhes da vulnerabilidade recomendarem um patch KB específico, acesse o Catálogo do Microsoft Update, pesquise o número KB fornecido nos detalhes da vulnerabilidade (por exemplo, KB5088064) e baixe o pacote de patch correspondente à sua versão do Windows. Faça upload do pacote para o servidor e instale-o. Após a conclusão da instalação, retorne ao console do Security Center e clique em Verify para confirmar a correção.

2. Corrigir vulnerabilidades de aplicações de terceiros: Para vulnerabilidades de aplicação que não suportam correção com um clique, como aquelas em XStream, Jackson, ThinkPHP ou 1Panel, siga as sugestões de correção nos detalhes da vulnerabilidade. Baixe uma versão segura do site oficial ou execute o comando de atualização (por exemplo, atualize o ThinkPHP para 5.0.25 ou posterior, ou atualize o 1Panel para v2.0.6 ou posterior). Antes de fazer alterações, crie um snapshot para fazer backup do servidor.

3. Confirmar atualizações de componentes, como MySQL: Após atualizar manualmente um componente como o MySQL, clique em Verify no console. Recomendamos também fazer login no servidor e executar um comando de consulta de versão (por exemplo, mysql --version) para confirmar que a atualização teve efeito.

Etapa 3: Verificar resultados e solucionar problemas

Se o status da vulnerabilidade for Fixing Failed ou a verificação falhar após uma correção manual, siga estas etapas para solucionar o problema:

• Falha na correção com um clique:

  • Esse problema geralmente ocorre devido a uma exceção no ambiente do script de correção, como um arquivo alvo modificado, espaço insuficiente em disco ou problemas de permissão. Visualize o motivo da falha nos detalhes da tarefa e tente uma correção manual.

    Aviso

    Pode ser necessário reiniciar o servidor após uma correção com um clique. Se uma correção falhar, sua cota de Correção de Vulnerabilidades não será consumida.

  • Falha na verificação de compatibilidade do kernel. Ao corrigir vulnerabilidades de kernel, o sistema verifica se a versão atualizada do kernel é compatível com o agente do Security Center. Se houver incompatibilidade, o sistema interrompe a correção. Inicie a correção com um clique novamente e selecione Mandatory Fix para ignorar a verificação de compatibilidade.

• Falha na verificação após correção manual:

  1. Confirme se a correção está correta: Verifique se os comandos ou operações executados no servidor correspondem às sugestões de correção.

  2. Confirme a versão do componente: O Security Center detecta vulnerabilidades com base no número da versão do software ou componente. Verifique se o software ou componente relacionado foi atualizado para a versão exigida pelo plano de correção.

     • Algumas vulnerabilidades oferecem várias opções de correção. Se você aplicar uma mitigação (que altera apenas configurações sem atualizar a versão do software), o número da versão permanece inalterado. Como resultado, a verificação de vulnerabilidades ainda relata a vulnerabilidade e a verificação falha. Recomendamos priorizar a opção de correção que atualiza o software para uma versão segura.

     • Se não for possível atualizar o software, clique em Ignore na página da lista de vulnerabilidades para interromper alertas repetidos. Para opções de correção disponíveis e versões afetadas, consulte a seção "Sugestões de correção" na página de detalhes da vulnerabilidade correspondente.

  3. Atraso na atualização de status: A atualização do status da vulnerabilidade depende dos resultados da verificação, que podem sofrer atrasos.

Etapa 4 (Opcional): Reverter a correção

Aviso

Uma reversão restaura os dados do disco para o estado no momento em que o snapshot foi criado. Os dados gravados após esse momento são perdidos. Prossiga com cautela.

Se uma correção causar problemas no serviço e você tiver criado um snapshot anteriormente, reverta as alterações no console.

1. Na página Vulnerabilities, clique em no número em Total Handled Vulnerabilities.

2. No painel Total Handled Vulnerabilities, defina Status como Fixed, localize a vulnerabilidade desejada e clique em Roll Back na coluna Actions.

3. Selecione o snapshot que deseja usar para a reversão e clique em OK.

Adiar correção (Ignore ou Add to Whitelist)

Se determinar que uma vulnerabilidade não exige correção, ignore-a ou adicione-a a uma lista de permissões para evitar alertas repetidos.

• Add to Whitelist: Esta ação suprime alertas para um tipo específico de vulnerabilidade dentro do escopo configurado. O escopo padrão são todos os ativos. Isso pode fazer com que você negligencie riscos de segurança relacionados. Use este recurso com cautela.

• Melhor prática para componentes de sistema Kubernetes: Vulnerabilidades de alto risco em componentes básicos de serviço do Kubernetes, como csi-plugin ou plugins CNI, frequentemente existem porque esses componentes requerem altos privilégios para funcionar. Como melhor prática do setor de segurança, geralmente é aceitável confiar nesses componentes fornecidos pelo fornecedor. Recomendamos adicionar esses riscos conhecidos e necessários à lista de permissões para reduzir o ruído de alertas.

• Ignore: A operação de ignorar afeta apenas o processo atual. Se a aplicação reiniciar ou um novo processo iniciar, o Security Center poderá detectar a vulnerabilidade novamente.

Recurso	Ignore	Add to Whitelist
Escopo	Aplica-se a uma única instância de vulnerabilidade em um único ativo.	Aplica-se a uma classe de vulnerabilidades, como um CVE ID. O escopo padrão é All Assets. Altere o escopo para ativos específicos selecionando Hosts ou By Asset Group.
Persistência	Temporária. Um alerta pode ser acionado novamente após a reinicialização do processo.	Persiste até que você exclua manualmente a regra da lista de permissões.
Casos de uso	Você confirmou que uma vulnerabilidade específica não representa risco. Você está aceitando temporariamente o risco e lidará com ele posteriormente.	Você confirmou que um tipo específico de vulnerabilidade é um falso positivo. Você está aceitando o risco de um tipo específico de vulnerabilidade por motivos comerciais e não planeja corrigi-lo.

Ignore

Procedimento

1. Na página Vulnerabilities, acesse a aba correspondente, como Linux Software Vulnerability, e localize a vulnerabilidade desejada.

2. Clique em no nome da vulnerabilidade para abrir sua página de detalhes. Na seção Unhandled Vulnerabilities, selecione um ou mais servidores para os quais deseja ignorar a vulnerabilidade.

3. Clique em Ignore abaixo da lista, insira um motivo e clique em OK.

   Nota

   Também clique em no ícone e depois clique em Ignore na coluna Actions para uma única vulnerabilidade.

Visualizar e cancelar itens ignorados

1. Retorne à página Vulnerabilities e clique em no número em Total Handled Vulnerabilities.

2. No painel Total Handled Vulnerabilities, defina Status como Ignored para visualizar uma lista de todas as vulnerabilidades ignoradas.

3. Localize a vulnerabilidade desejada e clique em Cancel Ignore na coluna Actions.

Add to Whitelist

Procedimento

• Método 1:

  1. Na página Vulnerabilities, acesse a aba de vulnerabilidade correspondente, como Linux Software Vulnerability, e selecione as vulnerabilidades que deseja processar.

  2. Clique em Add to Whitelist no canto inferior esquerdo da lista.

     Importante

     Por padrão, este método aplica-se a All Assets.

• Método 2:

  1. Na página Vulnerabilities, clique em Vulnerability Settings no canto superior direito.

  2. Na aba Vulnerability Whitelist Settings, clique em Create Rule.

  3. Configure os parâmetros conforme descrito na tabela a seguir e clique em OK.

     1. Select Vulnerability: Selecione uma ou mais vulnerabilidades que deseja adicionar à lista de permissões.

     2. Applied Assets: Defina o escopo para a regra da lista de permissões. Se selecionar Asset Group ou Hosts, selecione os ativos desejados.

Visualizar e gerenciar lista de permissões

1. Na página Vulnerabilities, clique em Vulnerability Settings no canto superior direito.

2. Na aba Vulnerability Whitelist Settings, visualize todas as regras de lista de permissões configuradas.

3. Para modificar ou excluir uma regra, clique em Edit ou Delete na coluna Actions da regra.

   1. Delete: Após excluir uma regra, o Security Center detecta a vulnerabilidade novamente nas verificações subsequentes.

   2. Edit: Modifique apenas os Applied Assets (o escopo da regra da lista de permissões) e as observações.

Faturamento

O recurso de correção de vulnerabilidades incorre nas seguintes taxas:

• Serviço de correção de vulnerabilidades (pagamento conforme o uso): Ative este serviço de pagamento conforme o uso para utilizar o recurso de correção com um clique. A cobrança é de USD 0,30 por correção, com faturamento diário. O número de correções de vulnerabilidades é calculado da seguinte forma:

  • Unidade mínima: Corrigir com êxito um Security Notice em um servidor conta como uma correção.

    Importante

    Um único Security Notice pode conter vários CVEs relacionados. Corrigir o aviso conta como apenas 1 correção, independentemente de quantos CVEs ele inclua.

  • Número de correções de vulnerabilidades = Σ (Número de Security Notices com status "Fixed" em cada servidor)

    Importante

    Uma correção só é contabilizada após o servidor reiniciar e seu status mudar para "Fixed". Correções com falha não são contabilizadas.

  • Exemplo:

    Se você usar o Security Center para corrigir com êxito 10 Security Notices diferentes em cada um dos 5 servidores:

    Total de correções de vulnerabilidades = 5 servidores × 10 Security Notices = 50 correções

• Taxas de backup de snapshot: Ao realizar uma correção com um clique, recomendamos selecionar Automatically Create Snapshot and Fix Risk. Esta ação cria um backup de snapshot do disco do servidor para que você possa reverter rapidamente as alterações se a correção causar problemas inesperados. A criação e retenção de snapshots incorrem em taxas cobradas pelo serviço de Snapshot do ECS. Para mais informações sobre as taxas, entre em contato com o suporte de pré-vendas.

Implementação em produção

Procedimento de correção

1. Antes da correção

   • Confirmação de ativos: Verifique se as versões de software afetadas estão presentes nos ativos do seu servidor.

   • Avaliação de risco: Avalie o impacto nos negócios para determinar a urgência e a necessidade da correção. Nem todas as vulnerabilidades exigem correção imediata.

   • Testes rigorosos: Implante o patch em um ambiente de staging. Valide totalmente sua compatibilidade e segurança e gere um relatório de teste detalhado.

   • Backup de dados: Realize um backup completo do servidor, por exemplo, criando um snapshot do ECS, para permitir uma reversão rápida caso ocorra um erro.

   • Agende a correção: Realize a correção fora do horário de pico para minimizar o impacto nos negócios.

2. Durante a correção

   • Operação com duas pessoas: Garanta a presença de pelo menos dois profissionais. Para evitar erros, um profissional executa a operação enquanto outro revisa e registra.

   • Siga o plano: Adira estritamente ao plano de correção e aplique as correções sequencialmente.

3. Após a correção

   • Verifique os resultados: Confirme se a vulnerabilidade foi corrigida e se todas as funções do sistema e aplicações de negócios estão funcionando corretamente.

   • Arquive a documentação: Documente todo o processo em um relatório final de correção de vulnerabilidades e arquive-o.

Mitigação de riscos

• Desenvolva um plano detalhado: Crie um plano de correção viável que tenha sido minuciosamente testado e validado. Adira estritamente às etapas definidas durante a execução.

• Teste em um ambiente simulado: Configure um ambiente de teste simulado idêntico ao ambiente de produção — incluindo sistema, aplicações e dados — para validar totalmente o plano de correção.

• Backup completo do sistema: Selecione a opção Automatically Create Snapshot and Fix Risk para realizar um backup completo do sistema, incluindo sistema operacional, aplicação e dados. Verifique a recuperabilidade do backup para garantir que você possa restaurar rapidamente os serviços caso surja um problema.

FAQ

Vulnerabilidades ausentes e problemas de verificação

• Nenhuma vulnerabilidade é exibida na página de gerenciamento de vulnerabilidades. O que devo fazer?

  Uma lista de vulnerabilidades vazia pode significar que nenhum risco foi detectado atualmente ou que o escopo da consulta ou o status do serviço está limitando os resultados. Verifique o seguinte, nesta ordem:

  1. Verifique a região: A lista de vulnerabilidades é exibida por região. O seletor de região no topo da página (por exemplo, Chinese Mainland) determina o escopo da consulta. Mude para a região dos seus ativos alvo e atualize a página.

  2. Verifique a edição e o status de ativação: Algumas capacidades de vulnerabilidade dependem de um serviço adicional. Se a página exibir Pay-as-you-go vulnerability fixing: Not activated, o recurso relacionado não está ativado e o escopo disponível é limitado. Acesse a página Overview para confirmar a edição e o status de ativação do Security Center.

  3. Acione uma verificação manualmente: Se nenhuma verificação foi executada ainda ou se a última verificação foi há muito tempo, clique em One-click scan no topo da página para acionar uma verificação e atualize a página após a conclusão.

  4. Entenda o estado vazio: Se abas como Linux software vulnerability ou Windows system vulnerability exibirem No records found, nenhum resultado foi detectado sob as condições de filtro atuais. Isso é esperado e não indica mau funcionamento. Mude para outra aba, como Urgent Vulnerabilities, para confirmar que a página retorna dados normalmente.

  5. Distinga vulnerabilidades de alertas: Se você recebeu um alerta de segurança, como um ataque de saída do servidor, mas a página de gerenciamento de vulnerabilidades não mostra registros, saiba que a verificação de vulnerabilidades e os alertas são duas dimensões de detecção diferentes, e um alerta não necessariamente corresponde a uma vulnerabilidade. Consulte View and handle alert events para investigar o evento de segurança.

Limitações e princípios de correção

• Por que o botão Fix está esmaecido?

  • Problema: Limitações da edição do product

    • Causa: O recurso one-click fix não é suportado na Basic Edition ou Anti-virus Edition.

    • Resolução: Adquira o value-added service "Correção de Vulnerabilidades" ou faça upgrade para a Enterprise Edition ou Ultimate Edition.

  • Problema: Problemas no servidor

    Problemas em servidores Linux

    • O sistema operacional atingiu o fim da vida útil (EOL): O fornecedor não fornece mais patch. Atualize manualmente o operating system. A correção de vulnerabilidades nos seguintes sistemas operacionais exige uma atualização do SO:

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

      • CentOS 5

      • Ubuntu 12

      • Debian 8, 9, 10

    • Espaço em disco insuficiente: O espaço disponível em disco é inferior a 3 GB. Libere espaço ou expanda o disco.

    • Processo em uso: O processo apt ou yum está em execução. Aguarde a conclusão do processo e tente novamente ou encerre o processo manualmente.

    • Permissões insuficientes: O usuário que executa o comando de correção não tem permissões suficientes. Certifique-se de que o proprietário do arquivo seja o usuário root e defina permissões apropriadas, como 755.

    Problemas em servidores Windows

    • Espaço em disco insuficiente: O espaço disponível em disco é inferior a 500 MB. Libere espaço ou expanda o disco.

    • O serviço Windows Update não está funcionando conforme o esperado: O serviço está desabilitado ou uma instalação de patch já está em andamento.

      • Se o serviço estiver desabilitado, acesse o gerenciador de Serviços no server, habilite o serviço Windows Update e tente corrigir a vulnerability novamente.

      • Se uma atualização estiver em andamento, aguarde a conclusão do processo Wusa.exe ou encerre o processo manualmente e tente corrigir a vulnerability novamente.

• Qual é a diferença entre uma vulnerabilidade de aplicação e uma vulnerabilidade de sistema? Por que a correção com um clique não suporta vulnerabilidades de aplicação?

  • Uma system vulnerability, como uma Linux software vulnerability ou uma Windows system vulnerability, afeta o operating system ou seus componentes. Essas vulnerabilidades possuem caminhos de correção padronizados, o que permite que sejam corrigidas com o recurso one-click fix.

  • Uma application vulnerability existe em uma aplicação autogerenciada, como código de site ou software de terceiros. O método de correção para este tipo de vulnerability está intimamente ligado à sua lógica de negócios e código específicos. Como ferramentas automatizadas não conseguem entender o contexto do seu negócio, corrija essas vulnerabilidades manualmente.

• Por que meu servidor tem tantas vulnerabilidades?

  À medida que novos métodos de ataque surgem, vulnerabilidades são continuamente descobertas em softwares mais antigos. Verificações regulares e aplicação de patches são tarefas de segurança essenciais e contínuas. Para ajudar você a focar nos riscos mais críticos, ative a chave Show Only Exploitable Vulnerabilities.

Operações de correção

• O que devo fazer se o erro "Permission acquisition failed, please check permissions and retry" aparecer ao executar um comando de correção?

  • Causa: O proprietário do arquivo necessário para realizar a operação de reparo não é root, o que resulta em permissões insuficientes.

  • Resolução:

    1. Localize o arquivo:

       No Security Center, visualize os detalhes da vulnerability para identificar o arquivo e o caminho específicos que exigem correção.

    2. Modifique as permissões:

       Faça login no servidor e execute o seguinte comando para alterar o proprietário do arquivo para root.

    3. Tente a correção novamente:

       Retorne ao console do Security Center e execute a operação de correção na vulnerability novamente.

• Quando corrijo vulnerabilidades em lote, em que ordem elas são corrigidas?

  A Linux software vulnerability é corrigida na ordem em que aparece na lista do console. Algumas Windows system vulnerabilities exigem que um patch pré-requisito seja instalado primeiro. Ao executar uma correção em lote para Windows system vulnerabilities, esses tipos de vulnerabilidades têm prioridade. As vulnerabilidades restantes são corrigidas na ordem em que aparecem na lista do console.

• Por que a reinicialização não funciona após corrigir uma vulnerabilidade de kernel no Ubuntu?

  • Sintoma: Após usar o recurso de correção com um clique no Security Center para aplicar patch em uma vulnerabilidade de kernel em um servidor Ubuntu, uma mensagem "Fixed, pending restart" é exibida. No entanto, após reiniciar o servidor, o alerta de vulnerabilidade persiste porque o sistema não usa o kernel recém-instalado.

  • Causa: Esse problema geralmente ocorre se a ordem de inicialização padrão do menu de boot GRUB foi modificada manualmente. O script de correção não consegue definir o novo kernel como a opção de boot padrão.

  • Resolução:

    Solução 1: Configurar novo kernel automaticamente

    Esta solução descarta sua configuração personalizada existente do GRUB e permite que o sistema aplique automaticamente as configurações padrão para o novo kernel.

    Procedimento:

    1. Antes de corrigir a vulnerabilidade, faça login no seu server Ubuntu.

    2. Execute o seguinte comando para definir a variável de ambiente:

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Retorne ao console do Security Center e realize uma correção com um clique na vulnerability.

    4. Após a conclusão da correção, reinicie o server conforme solicitado. O sistema habilita automaticamente o kernel mais recente.

    Solução 2: Modificar ordem de boot manualmente

    Se precisar manter sua configuração existente do GRUB, use esta solução.

    Procedimento:

    1. No console do Security Center, realize uma one-click fix e reinicie o server conforme solicitado.

    2. Após a reinicialização do server, faça login no seu server Ubuntu.

    3. Modifique manualmente a ordem de boot do GRUB para definir a versão do kernel recém-instalado como a opção de boot padrão.

       Nota

       O procedimento geralmente envolve modificar o arquivo /etc/default/grub e executar o comando update-grub. Para mais informações, consulte Change the kernel boot order of an ECS Linux CentOS instance.

    4. Reinicie o server novamente para que a nova ordem de boot tenha efeito.

• Preciso reiniciar o sistema após corrigir uma vulnerabilidade?

  • Windows: É necessária uma reinicialização.

  • Linux Software Vulnerability: É necessária uma reinicialização se qualquer uma das seguintes condições for atendida:

    • Uma vulnerability de kernel foi corrigida.

    • Na aba Linux Software Vulnerability da página Risk Governance > Vulnerabilities no console do Security Center, o boletim da vulnerability possui uma tag Restart Required.

• Por que uma operação de reversão de vulnerabilidade falha?

  Se uma operação de vulnerability rollback falhar, investigue as seguintes causas possíveis:

  1. Verifique o status do agente

     A operação de reversão exige que o agent do Security Center esteja online. Se o agent estiver offline, o comando não pode ser entregue. Solucione e resolva primeiro o status offline do agente.

  2. Confirme se o snapshot de backup é válido

     O recurso de reversão depende do backup snapshot criado antes da correção. Se o snapshot expirou ou foi excluído manualmente, a operação de reversão não pode ser realizada.

• Por que a criação de snapshot falha ao corrigir uma vulnerabilidade?

  A criação de um snapshot pode falhar pelos seguintes motivos:

  • Operação realizada por um usuário RAM: Se um RAM user sem a permission necessária realizar a operação, a criação do snapshot falhará. Recomendamos usar sua Alibaba Cloud account para realizar a operação. Para mais informações sobre RAM user, consulte Overview.

  • Servidor não Alibaba Cloud: A criação de snapshot para correção de vulnerabilidades não é suportada em non-Alibaba Cloud server.

Status pós-correção e verificação

• Corrigi uma vulnerabilidade, mas o Security Center ainda a relata. O que devo fazer?

  • Causa: Esse problema ocorre porque algumas vulnerabilidades, como vulnerabilidades de kernel Linux, exigem uma reinicialização do server após a correção.

  • Resolução: Na página de detalhes da vulnerability, clique em Restart. Após a conclusão da reinicialização, clique em Verify. Se o status mudar para Repaired, a vulnerability foi corrigida com êxito.

• Corrigi uma vulnerabilidade sem atualizar a versão do software, mas o Security Center ainda a relata. O que devo fazer?

  • Causa: O Security Center detecta Application Vulnerability e Urgent Vulnerability comparando o número da versão do software ou componente. Se você mitigar uma vulnerabilidade em vez de atualizar para uma versão segura, por exemplo, habilitando SafeMode no fastjson para desabilitar AutoType, o número da versão permanece dentro do intervalo afetado. Verificações subsequentes continuam relatando a vulnerabilidade, e clicar em Verify não altera o status para corrigido.

  • Resolução: Após confirmar que a mitigação eliminou o risco, acesse a página Vulnerabilities e aplique Ignore ou Add to Whitelist na vulnerabilidade para interromper alertas repetidos. Ignore tem efeito apenas para o processo atual. Se a aplicação reiniciar ou um novo processo iniciar, o Security Center poderá detectar a vulnerabilidade novamente. Add to Whitelist suprime alertas para este tipo de vulnerabilidade dentro do escopo configurado até que você exclua manualmente a regra da lista de permissões. Para as diferenças entre as duas ações e os procedimentos correspondentes, consulte a seção "Adiar correção" deste tópico.

• Por que o status das correções de vulnerabilidade do Windows muda para "Invalid"?

  O mecanismo de detecção de vulnerabilidades do Windows foi atualizado. Após atualizações mensais das regras de vulnerabilidade do Windows, o status das vulnerabilidades existentes afetadas por essas mudanças de regra será marcado como "Invalid".

• Após corrigir uma vulnerabilidade, por que o console ainda mostra um status "Not fixed"?

  Isso pode ocorrer pelos seguintes motivos:

  1. Atraso na verificação: Após uma correção manual, clique em no botão Verify para acionar uma verificação imediata. A atualização do status pode levar alguns minutos.

  2. Cache do navegador: A página do console pode estar em cache no seu navegador. Tente forçar a atualização da página ou aguarde alguns minutos.

  3. Correção incompleta: A operação de correção pode não ter sido totalmente bem-sucedida. Por exemplo, uma vulnerability pode ter vários caminhos vulneráveis, mas apenas um foi corrigido. Revise as etapas de correção e tente novamente.

• Fixed and Pending Restarted: O Security Center pode verificar automaticamente uma vulnerabilidade neste estado?

  Não. Reinicie o server pelo console do Security Center ou reinicie-o manualmente. Após a reinicialização do server, clique em Verify para confirmar que a vulnerability foi corrigida.

  Importante

  Se você não verificar manualmente a correção, o Security Center verifica automaticamente o status durante a próxima verificação agendada. Para evitar falsos negativos devido a problemas de rede, o sistema retém o registro da vulnerability por três dias se ela não for detectada na primeira verificação. Se a vulnerability permanecer não detectada por três dias consecutivos, o sistema remove o registro.

• Por que o status de verificação não é atualizado após corrigir manualmente uma vulnerabilidade?

  Após corrigir manualmente uma vulnerabilidade em um servidor, se o recurso 'Verify' no console do Security Center falhar em atualizar o status da vulnerabilidade para 'Fixed', esse problema geralmente ocorre por dois motivos:

  • O nível de verificação de vulnerabilidades não está totalmente configurado

    • Causa: O Security Center verifica e atualiza o status apenas para os níveis de risco selecionados em Vulnerability Settings. Se o nível de risco da vulnerability alvo, como High ou Medium, não estiver selecionado, o sistema não atualiza seu status.

    • Resolução: Verifique as configurações de verificação em Vulnerability Settings e certifique-se de que o nível de risco da vulnerability alvo esteja selecionado.

  • O agente do Security Center está offline

    • Motivo: A função 'Verification' depende da comunicação em tempo real entre o console e o cliente no servidor. Se o cliente estiver offline, o console não pode enviar comandos de verificação ou receber os resultados.

    • Resolução: Solucione o problema do agent offline. Após o agent voltar a ficar online, tente verificar novamente.

  Apêndice: Parâmetros de detalhes da vulnerabilidade

  Parâmetro	Descrição
  CVE ID	Este é o CVE ID da vulnerabilidade. Common Vulnerabilities and Exposures (CVE) é uma lista de nomes públicos para vulnerabilidades de segurança da informação ou fraquezas expostas amplamente reconhecidas. Usando o CVE ID, como CVE-2018-1123, você pode encontrar rapidamente informações sobre a correção da vulnerabilidade correspondente em qualquer outro banco de dados compatível com CVE para ajudar a resolver problemas de segurança.
  Impact Score	A pontuação CVSS é baseada no Common Vulnerability Scoring System (CVSS), um padrão industrial amplamente adotado. A pontuação é calculada usando uma fórmula baseada em vários atributos de uma vulnerabilidade. É usada principalmente para quantificar a gravidade de uma vulnerabilidade e ajuda a determinar a urgência e a importância da correção. O sistema de pontuação CVSS define os níveis de gravidade da seguinte forma: 0: None 0,1–3,9: Low Vulnerabilidades que podem causar um ataque de negação de serviço (DoS) local. Outras vulnerabilidades de baixo impacto. 4,0–6,9: Medium Vulnerabilidades que exigem interação do usuário para serem exploradas. Vulnerabilidades que permitem a um atacante obter privilégios de usuário padrão. Vulnerabilidades que podem ser exploradas ainda mais após alterações de configuração local ou coleta de informações. 7,0–8,9: High Vulnerabilidades que permitem a um atacante obter indiretamente privilégios padrão em um servidor ou sistema de aplicação. Vulnerabilidades que permitem leitura, download, gravação ou exclusão arbitrária de arquivos. Vulnerabilidades que podem levar à exposição de dados sensíveis. Vulnerabilidades que podem causar diretamente interrupções de serviço ou ataques DoS remotos. 9,0–10,0: Critical Vulnerabilidades que permitem a um atacante obter diretamente privilégios de nível de sistema em um servidor. Vulnerabilidades que permitem acesso direto a informações sensíveis importantes, potencialmente causando uma violação de dados. Vulnerabilidades que concedem acesso não autorizado a informações sensíveis. Outras vulnerabilidades com impacto abrangente.
  Affected Assets	Informações sobre os ativos de servidor afetados pela vulnerabilidade, incluindo seus endereços IP públicos ou privados.
  Severity	A gravidade da vulnerabilidade é calculada com base em sua pontuação CVSS, importância do ativo e outros fatores. Os níveis incluem: High: Uma vulnerabilidade de alto risco. Recomenda-se correção imediata. Medium: Uma vulnerabilidade de risco médio. Corrija com base nas necessidades do seu negócio. Low: Uma vulnerabilidade de baixo risco. A correção é opcional, com base nas necessidades do seu negócio.
  Details	Acesse a página Vulnerabilities, clique em no nome de uma vulnerabilidade alvo na coluna Vulnerability e, em seguida, na aba Unhandled Vulnerabilities, clique em Details na coluna Actions da vulnerabilidade para visualizar informações como ativos afetados, comandos de correção e descrições de impacto. Fixing Command: Execute este comando para corrigir a vulnerabilidade. Nota Este recurso não está disponível na Basic Edition. Impact Description: Software: O software vulnerável e a versão que o Security Center detectou no seu servidor. Por exemplo: mariadb-libs 5.5.52-1.el7. Hit: A condição que acionou a detecção. Uma vulnerabilidade é geralmente sinalizada porque a versão do software instalado é mais antiga que a versão necessária. Por exemplo, a vulnerabilidade é detectada porque a versão do mariadb-libs é anterior a 5.5.56-2.el7. Path: O caminho para o programa vulnerável no seu servidor. Por exemplo, o caminho do mariadb-libs é /etc/ld.so.conf.d/mariadb-x86_64.conf. Caution (Read Before Further Operations): Fornece alertas de risco, sugestões adicionais de correção e materiais de referência para a vulnerabilidade. A caixa de diálogo de detalhes da vulnerabilidade (usando CESA-2023:0291: sudo security update como exemplo) exibe as seguintes informações principais: Affected assets: Ativos de servidor e informações de rede afetados pela vulnerabilidade. Fix command: Por exemplo, yum update sudo. Impact description: Inclui a versão atual do software (ex.: sudo 1.8.23-10.el7_9.2), condições de correspondência (ex.: versão do sudo inferior a 1.8.23-10.el7_9.3) e caminho de detecção (ex.: /etc/pam.d/sudo).