Security Center:Perguntas frequentes sobre gerenciamento de vulnerabilidades

Comportamento da varredura e resultados

• Por que várias instâncias da mesma vulnerabilidade são relatadas para um único servidor?

  A detecção de vulnerabilidades de aplicação tem como alvo instâncias específicas de processos em execução. Se um servidor executa múltiplas instâncias de um processo com a mesma vulnerabilidade, como dois serviços Tomcat idênticos em portas diferentes, o sistema relata uma vulnerabilidade separada para cada instância. Caso o software vulnerável esteja instalado, mas seu processo correspondente não esteja em execução, a vulnerabilidade não é detectada.

• Por que os resultados de varredura para vulnerabilidades como Fastjson às vezes variam?

  A detecção dessas vulnerabilidades depende se seus componentes, como pacotes JAR, estão carregados em um estado de "runtime" durante a varredura. Em um modelo de carregamento dinâmico, o sistema identifica a vulnerabilidade apenas quando a lógica de negócios chama o componente vulnerável. Portanto, os resultados da varredura podem diferir em momentos distintos.

  Nota

  Para melhorar a precisão da detecção desses tipos de vulnerabilidades, recomendamos executar varreduras periódicas ou múltiplas.

• Por que os registros de vulnerabilidades de um host permanecem no console após o agente ficar offline?

  Quando um agente fica offline, seus registros de vulnerabilidades detectados anteriormente são mantidos no console. No entanto, esses registros tornam-se automaticamente obsoletos e você não pode agir sobre eles (por exemplo, corrigi-los, verificá-los ou excluí-los). As vulnerabilidades tornam-se obsoletas automaticamente após os seguintes períodos:

  Importante

  Todos os dados são excluídos permanentemente apenas se o service Security Center expirar e não for renovado dentro de 7 dias.

  • Linux Software Vulnerability e Windows System Vulnerability: 3 dias.

  • Web-CMS Vulnerability: 7 dias.

  • Application Vulnerability: 30 dias.

  • Urgent Vulnerability: 90 dias.

• Uma varredura manual afeta o cronograma de varredura automática?

  Executar uma varredura manual com um clique não afeta o cronograma existente de varredura automática. Ambos operam independentemente. Varreduras automáticas, como as de vulnerabilidades de sistema que ocorrem diariamente ou a cada dois dias, continuam em seus ciclos agendados, independentemente das varreduras manuais.

Comportamento da varredura e resultados

• Por que o número de vulnerabilidades emergenciais difere do número de vulnerabilidades de aplicação?

  Engenheiros de segurança da Alibaba Cloud confirmam as vulnerabilidades emergenciais, que são detectadas por comparação de versão e verificação de POC. Elas aparecem apenas na aba Emergency Vulnerabilities. Já as vulnerabilidades de aplicação são detectadas automaticamente por meio de Análise de Composição de Software (SCA), focando em instâncias de processos e envolvendo componentes como Apache, Redis e Docker. Os dois tipos diferem no mecanismo de detecção, local de exibição e método de correção, portanto, suas contagens não correspondem exatamente. Mesmo que as regras de detecção se baseiem no mesmo número de versão (como fastjson < 1.2.83), os resultados podem divergir devido ao estado de carregamento em runtime dos componentes.

Impacto no desempenho e segurança

• As varreduras de vulnerabilidades ou POCs para vulnerabilidades urgentes afetam os sistemas de negócios?

  Geralmente, não. Os POCs do Security Center enviam apenas uma ou duas solicitações de sondagem inofensivas e não realizam ataques ou ações destrutivas. Contudo, em casos raros onde uma aplicação lida mal com entradas inesperadas, pode existir um risco mínimo e desconhecido.

• Por que uma varredura de vulnerabilidades pode acionar um erro de falta de memória (OOM)?

  O agente do Security Center possui um limite padrão de memória de 200 MB. Se o uso de memória durante uma varredura exceder esse limite, o mecanismo OOM do sistema encerra o processo de detecção (ALiSecCheck) para conservar recursos.

  Nota

  • Um grupo de controle (cgroup) chamado aegisRtap0 geralmente gerencia esse limite. Você pode encontrar informações relacionadas ao OOM nos logs dmesg.

  • Esse comportamento é normal e não indica escassez de memória em todo o sistema. Nenhuma intervenção do usuário é necessária.

  • Esse tipo de erro Out of Memory (OOM) resulta de um limite de memória do cgroup, não de uma escassez de memória em todo o sistema.

Escopo e capacidades da varredura

1. O que a varredura de vulnerabilidades cobre?

   A varredura abrange tanto a camada de sistema quanto a de aplicação:

   • Camada de sistema: Linux Software Vulnerability e Windows System Vulnerability.

     Importante

     A varredura de Windows System Vulnerability suporta apenas patches de atualização de segurança mensais.

   • Camada de aplicação: Web-CMS Vulnerability, Application Vulnerability e Urgent Vulnerability.

2. Posso usar o Security Center para varredura de vulnerabilidades durante um exercício de ataque e defesa?

   Sim. Antes de um exercício de ataque e defesa, utilize a varredura de vulnerabilidades do Security Center para verificar seus ativos. A varredura cobre os seguintes tipos:

   • Linux Software Vulnerability

   • Windows System Vulnerability

   • Application Vulnerability (requer a edição Enterprise ou Ultimate)

   • Urgent Vulnerability

   Configurações arriscadas de cloud services não são cobertas pela varredura de vulnerabilidades. Esses riscos são detectados pela Cloud Platform Configuration Assessment (Cloud Security Posture Management, CSPM).

   A varredura de vulnerabilidades do Security Center não cobre vulnerabilidades de lógica de código, como bypass de lógica de negócios ou problemas de escalonamento de privilégios que exigem compreensão da semântica do negócio. Se precisar detectar vulnerabilidades de lógica de código durante um exercício de ataque e defesa, utilize o service Penetration Test, que é independente da varredura de vulnerabilidades.

3. Como visualizo a lista de vulnerabilidades que o Security Center pode detectar?

   1. Faça logon no Security Center console.

   2. No painel de navegação à esquerda, escolha Vulnerabilities > Vulnerabilities. Na seção de visão geral, localize o cartão Disclosed Vulnerabilities.

   3. Clique no total number of vulnerabilities no cartão para visualizar uma lista de todas as vulnerabilidades detectáveis e seus detalhes.

4. A detecção para vulnerabilidades específicas como Elasticsearch é suportada?

   Sim. Visualize os resultados de detecção para services como Elasticsearch na página Application Vulnerability no console.

   Nota

   Este recurso está disponível apenas para Subscription (edições Enterprise e Ultimate) e Enable Pay-as-You-Go Service (Comprehensive Host Protection e Hosts and Container Protection). Se sua edição atual não suportar este recurso, {{XREF_0}} seu service.

Escopo e capacidades da varredura

• O Security Center alerta sobre vulnerabilidades CVE não listadas?

  O Security Center alerta apenas sobre vulnerabilidades conhecidas listadas em seu banco de dados. Se um número CVE não foi oficialmente divulgado ou listado (como números não divulgados tipo CVE-2026-31431), o sistema não consegue identificar o risco e não envia alertas. Caso uma vulnerabilidade tenha sido divulgada com patch disponível, mas ainda não seja detectada, verifique se você a corrigiu manualmente ou tomou medidas de mitigação. Acompanhe os anúncios de segurança da Alibaba Cloud. Após a divulgação oficial da vulnerabilidade e o lançamento do patch pelo fornecedor, o Security Center atualiza as regras de detecção e passa a suportar a varredura.

• Onde vejo a classificação mais recente após ajustes nas categorias de regras de vulnerabilidades?

  Algumas regras de vulnerabilidade podem ser removidas da categoria de vulnerabilidades de aplicação devido a falsos positivos e ajustadas para serem suportadas como vulnerabilidades de sistema. Encontre a classificação mais recente na lista Disclosed Vulnerabilities.

• O Security Center suporta Ubuntu 24.04? Como faço uma varredura manual de vulnerabilidades?

  O Security Center suporta varredura manual de vulnerabilidades. As principais distribuições Linux geralmente estão dentro do escopo suportado. Para o status de suporte de versões específicas de SO como Ubuntu 24.04, consulte os resultados reais da varredura no console. Os seguintes métodos são suportados:

  • Faça logon no console e acesse Risk Management > Vulnerabilities, selecione as vulnerabilidades a serem corrigidas e clique em Quick Scan para correção com um clique.

  • Edição Gratuita do Security Center: Faça logon manualmente na instância ECS e realize uma atualização do sistema através da ferramenta de gerenciamento de pacotes do SO (como yum ou apt).

  Antes de corrigir vulnerabilidades, recomendamos fazer backup dos dados do disco do sistema através de snapshots do ECS para evitar problemas de compatibilidade durante o processo de correção.

• Por que há uma diferença significativa nas contagens de alertas de vulnerabilidades entre dois servidores?

  • Versões de SO e status de manutenção diferentes: Servidores executando sistemas EOL (como CentOS 5 e Ubuntu 12) continuam relatando vulnerabilidades de alto risco porque os fornecedores não lançam mais atualizações de segurança. Essas vulnerabilidades não podem ser eliminadas através de correção com um clique. Servidores executando sistemas ainda dentro do ciclo de suporte oficial não possuem tais alertas. Para mais informações, veja a seção EOL neste tópico.

  • Status de execução de processos de aplicação diferentes: A detecção de vulnerabilidades de aplicação visa instâncias de processos em execução. Se um servidor executa middlewares ou bancos de dados específicos e o outro não, o primeiro detectará vulnerabilidades de aplicação para esses componentes, enquanto o segundo não.

  Além disso, diferenças em pacotes de software instalados, autorização da edição do Security Center e configurações de nível de varredura de vulnerabilidades entre os dois servidores também causam diferenças na contagem de alertas.

• O que faço se um alerta relatar vulnerabilidades de middleware como Redis, mas eu não conseguir encontrar a instância correspondente do cloud product?

  Tais alertas de vulnerabilidade geralmente apontam para middleware instalado em servidores ECS (como Redis autogerenciado), não para instâncias de banco de dados gerenciadas pela Alibaba Cloud. O Security Center detecta vulnerabilidades em ativos de host e contêiner, não dentro de instâncias de banco de dados gerenciadas. Recomendamos usar o endereço IP ou nome do host nos detalhes do alerta para localizar o servidor ECS correspondente e, em seguida, verificar o status de instalação e execução do middleware nesse servidor. Após localizar o middleware, consulte a documentação de correção de vulnerabilidades do middleware correspondente para atualizá-lo manualmente. Depois da atualização, retorne ao console e clique em Verify.

• Por que recebo um aviso de que vulnerabilidades de sistema de alto risco não foram corrigidas?

  Este aviso indica que o SO ou software instalado na instância ECS possui vulnerabilidades de alto risco que foram oficialmente divulgadas, mas ainda não corrigidas. Causas comuns incluem: imagem do sistema não atualizada a tempo, versões de software instaladas manualmente muito antigas ou status não atualizado porque o servidor não foi reiniciado ou verificado após a correção. Solução: Acesse Risk Governance > Asset Center, visualize os detalhes das vulnerabilidades por gravidade, corrija as vulnerabilidades que suportam correção com um clique e trate manualmente outras vulnerabilidades com base nos anúncios. Certifique-se também de que o nível de varredura em Vulnerability Management Settings Host cubra o nível de alto risco.

• O que faço se Vulnerability Management e alertas de segurança não tiverem dados após adicionar uma nova instância?

  Instâncias recém-adicionadas têm um intervalo de tempo entre a sincronização de dados e a primeira varredura. A página de gerenciamento de vulnerabilidades pode não mostrar dados imediatamente. Recomendamos clicar em Scan na página de gerenciamento de vulnerabilidades, selecionar os tipos de vulnerabilidade conforme necessário para acionar a detecção e visualizar os resultados após a conclusão da varredura. Acompanhe o progresso da varredura em Task Management. Se nenhum dado estiver disponível após a conclusão da varredura e o agente estiver online com status normal da instância, significa que a instância atualmente não possui riscos detectados, o que é normal. Certifique-se também de que a região selecionada no canto superior esquerdo do console corresponda à região real do ativo.

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

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

  • 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 "Vulnerability Fixing" value-added service ou faça upgrade para Enterprise Edition ou Ultimate Edition.

  • Problema: Problemas no lado do 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 um upgrade 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 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 service Windows Update não está funcionando conforme esperado: O service está desabilitado ou uma instalação de patch já está em andamento.

      • Se o service estiver desabilitado, acesse o gerenciador de Services no server, habilite o service 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 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, você deve corrigir essas vulnerabilidades manualmente.

• Por que meu servidor tem tantas vulnerabilidades?

  Conforme novos métodos de ataque surgem, vulnerabilidades são continuamente descobertas em softwares mais antigos. Varreduras e aplicações de patches regulares são tarefas de segurança essenciais e contínuas. Para ajudar você a focar nos riscos mais críticos, ative a opção Security Check.

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, resultando 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 requerem correção.

    2. Modifique as permissões:

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

    3. Tente a correção novamente:

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

• Ao corrigir vulnerabilidades em lote, em que ordem elas são corrigidas?

  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 utiliza 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 então não consegue definir o novo kernel como a opção de boot padrão.

  • Resolução:

    Solução 1: Configurar automaticamente o novo kernel

    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 logon no seu server Ubuntu.

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

       docker ps | grep php
       docker exec <container_name> php -v

    3. Retorne ao Security Center console 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 habilitará automaticamente o kernel mais recente.

    Solução 2: Modificar manualmente a ordem de boot

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

    Procedimento:

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

    2. Após a reinicialização do server, faça logon 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 {{XREF_1}}.

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

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

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

  • High-priority Vulnerabilities (CVE): É necessária uma reinicialização se qualquer uma das seguintes condições for atendida:

    • Uma kernel vulnerability foi corrigida.

    • Na aba Urgent Vulnerability da página Urgent Vulnerability > High-priority Vulnerabilities (CVE) no Security Center console, o boletim da vulnerability possui uma tag High-priority Vulnerabilities (CVE).

• 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 Security Center agent esteja online. Se o agent estiver offline, o comando não pode ser entregue. Primeiro solucione e resolva 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 {{XREF_2}}.

  • 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: Este 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 Vulnerabilities. Após a conclusão da reinicialização, clique em Urgent Vulnerability Scan Cycle. Se o status mudar para Repaired, a vulnerability foi corrigida com sucesso.

• 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 Stop e Application Vulnerability Scan Cycle 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 desativar AutoType, o número da versão permanece dentro da faixa afetada. Varreduras subsequentes continuarão a relatar a vulnerabilidade, e clicar em Every 3 Days não alterará o status para corrigido.

  • Resolução: Após confirmar que a mitigação eliminou o risco, acesse a página Every 1 Week e aplique Every 2 Weeks ou Every 2 Weeks na vulnerabilidade para interromper alertas repetidos. Risk Governance 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. Vulnerability Management suprime alertas para este tipo de vulnerabilidade dentro do escopo configurado até que você exclua manualmente a regra de whitelist. 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 vulnerabilidades do Windows muda para "Invalid"?

  O mecanismo de detecção de vulnerabilidades do Windows foi atualizado. Após atualizações mensais nas regras de vulnerabilidades 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 no botão Task Management para acionar uma varredura imediata. A atualização do status pode levar alguns minutos.

  2. Cache do navegador: A página do console pode estar armazenada 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 múltiplos caminhos vulneráveis, mas apenas um foi corrigido. Revise as etapas de correção e tente novamente.

• Risk Governance: O Security Center pode verificar automaticamente uma vulnerabilidade neste estado?

  Não. Reinicie o server a partir do Security Center console ou reinicie-o manualmente. Após a reinicialização do server, clique em Vulnerabilities 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 varredura 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 varredura. 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 eu 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 varredura de vulnerabilidades não está totalmente configurado

    • Causa: O Security Center varre e atualiza o status apenas para os níveis de risco selecionados em Fix. Se o nível de risco da vulnerability alvo, como Alto ou Médio, não estiver selecionado, o sistema não atualiza seu status.

    • Resolução: Verifique as configurações de varredura em Vulnerabilities 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.

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

• Após o SO atingir o fim da vida útil (EOL), o Security Center suporta varredura e correção de vulnerabilidades?

  Para versões de sistema que não são mais oficialmente suportadas, como CentOS 7.6, o Security Center não suporta varredura de vulnerabilidades ou correção com um clique. Se nenhuma vulnerabilidade for detectada pela varredura, confirme se a versão do sistema está dentro do escopo suportado. Caso contrário, recomendamos verificar a data de lançamento do kernel ou consultar anúncios oficiais. Atualize o SO para uma versão ainda dentro do ciclo de suporte oficial ou, após avaliar e confirmar que o risco é gerenciável, marque a vulnerabilidade como Ignore no console.

• Quando múltiplos services são implantados no mesmo servidor, qual é o escopo de impacto das vulnerabilidades de sistema?

  Quando múltiplos services são implantados no mesmo servidor, vulnerabilidades de sistema afetam todos os services no servidor porque compartilham o mesmo ambiente de SO. Recomendamos aplicar patches de sistema em todo o servidor e garantir a criação de backups de snapshot antes da correção.

• Preciso reiniciar o servidor ao corrigir vulnerabilidades? Qual o impacto nos negócios?

  • Vulnerabilidades de sistema Windows: É necessária uma reinicialização do servidor para que o patch tenha efeito. A reinicialização causa uma breve interrupção do service. Recomendamos corrigir vulnerabilidades fora do horário de pico e selecionar Create Snapshot and Fix para reversão.

  • Vulnerabilidades de kernel Linux: É necessária uma reinicialização. Se o status ainda for Fixed - Restart Required após a correção, clique em Restart no console ou reinicie manualmente o servidor e, em seguida, clique em Verify.

  • Vulnerabilidades de software Linux: Geralmente não é necessária uma reinicialização, a menos que o anúncio da vulnerabilidade contenha a tag Vulnerability Scan Level.

  • Impacto nos negócios: A reinicialização causa interrupção do service, e o processo de correção pode consumir recursos e causar lentidão. Recomendamos fazer backup antecipadamente (snapshots) e verificar em um ambiente de teste.

  • Mecanismo de parada de service: Vulnerabilidades de sistema Windows e vulnerabilidades de kernel Linux exigem uma reinicialização após a correção para terem efeito, e a reinicialização causa uma breve interrupção do service. Vulnerabilidades de aplicação e vulnerabilidades emergenciais suportam apenas detecção e não suportam correção com um clique, portanto, não causam paradas de service devido a operações de correção do Security Center. Para vulnerabilidades que exigem reinicialização, o console exibe a tag Show Only Exploitable Vulnerabilities. Após a conclusão da correção, o status é exibido como Fixed - Restart Required.

  • Risco de não corrigir: Não corrigir vulnerabilidades de sistema Windows não afeta a operação normal do sistema e dos negócios, mas reduz a segurança do sistema e aumenta o risco de ataques. Recomendamos avaliar as prioridades de correção com base na gravidade da vulnerabilidade e na importância do negócio, e tomar medidas de mitigação, como controle de acesso, para vulnerabilidades que não forem corrigidas imediatamente.

• Quais são os riscos de não corrigir vulnerabilidades de alto risco (como Linux Kernel ptrace)?

  • Descrição do risco: Se uma vulnerabilidade de escalonamento de privilégios local de alto risco (como CVSS 7.8) não for corrigida, atacantes podem explorá-la para roubar arquivos sensíveis (/etc/shadow, chaves privadas SSH) e obter os privilégios mais altos, resultando em controle total do servidor.

  • Mitigação: Se a correção não for possível imediatamente, use grupos de segurança para restringir o acesso e fortalecer o monitoramento. No entanto, a solução fundamental ainda exige a correção.

  • Identificação de vulnerabilidade SSL/TLS: Para vulnerabilidades de divulgação de informações do protocolo SSL/TLS (como CVE-2016-2183), faça ping no nome de domínio para resolver o endereço IP, use recursos CLB/K8s para localizar os nós específicos afetados e corrija-os manualmente.

• Serei cobrado novamente se clicar em Fix novamente após uma falha na correção de vulnerabilidade?

  A correção de vulnerabilidades do Security Center é cobrada por correção. Clicar em Fix Now consome um crédito de correção, e a entrada de correção no console exibe os créditos de correção restantes disponíveis atuais. Se uma correção falhar, clicar em Fix novamente para a mesma vulnerabilidade não incorre em cobranças adicionais até que a correção seja bem-sucedida. Todo o processo é cobrado como uma única correção. Para preços específicos e regras de faturamento, consulte a documentação de faturamento do Security Center.

• Preciso esperar o snapshot ser concluído antes de corrigir? Como reverter se os negócios ficarem anormais após a correção?

  • Momento do snapshot antes da correção: Se você criou manualmente um snapshot como backup, recomendamos aguardar até que o status do snapshot se torne Available antes de realizar a correção de vulnerabilidades para garantir que o backup seja válido. Ao corrigir no Security Center, selecione Create Snapshot and Fix ou selecione Fix Without Snapshot para economizar tempo. Esta última opção não suporta reversão por snapshot.

  • Reversão após correção: Se a correção causar indisponibilidade da aplicação ou anomalias no sistema, encontre a vulnerabilidade com status de correção bem-sucedida em Windows e clique em Roll Back para selecionar o snapshot criado antes da correção para recuperação. A reversão está disponível apenas para vulnerabilidades de software Linux e vulnerabilidades de sistema Windows que suportam correção com um clique. Servidores não Alibaba Cloud não suportam reversão.

  • Solução de problemas de falha na reversão: A falha na reversão geralmente é causada pelo agente estar offline ou pelo snapshot ter sido excluído ou expirado. Para detalhes, consulte as seções sobre por que a reversão de vulnerabilidade falha e por que a criação de snapshot falha durante a correção de vulnerabilidade neste tópico.

• Alertas de vulnerabilidades de alto risco podem ser excluídos diretamente? Como lido com vulnerabilidades que não precisam de correção ou são falsos positivos?

  • Exclusão direta não é suportada: Os registros de vulnerabilidades do Security Center são gerados com base em resultados reais de detecção de ativos e não suportam exclusão manual. Registros de vulnerabilidades tornam-se inválidos apenas quando o agente fica offline por mais tempo que o período de retenção ou quando o service expira.

  • Ação recomendada: Para vulnerabilidades confirmadas como sem risco, falsos positivos ou que não exigem correção imediata, use Ignore ou adicione-as à Whitelist para interromper alertas.

  • Diferença entre Ignore e Whitelist: Ignore tem efeito em um único registro de vulnerabilidade no ativo atual. Se o processo vulnerável for reiniciado ou a vulnerabilidade for detectada novamente em varreduras subsequentes, ela pode reaparecer. Whitelist configura o escopo por dimensão de vulnerabilidade (todos os ativos, grupos de ativos especificados ou ativos especificados) e permanece efetiva até que a regra de whitelist seja excluída manualmente.

  • Tratamento de vulnerabilidades de baixa gravidade: No modo pagamento conforme o uso, decida se deve corrigir vulnerabilidades de gravidade baixa a média com base na avaliação de risco do negócio. Para vulnerabilidades não corrigidas imediatamente, use Ignore ou Whitelist para gerenciar o ruído de alertas.

• Vulnerabilidades emergenciais mostrando To Be Protected ou Protected precisam ser tratadas?

  • Descrição do status: Vulnerabilidades emergenciais suportam apenas detecção e não suportam correção com um clique. Linux Software Vulnerability / Protected na lista indica o status de proteção dos patches virtuais do Cloud Firewall: Linux Software Vulnerability indica que a vulnerabilidade ainda não está protegida por patches virtuais do Cloud Firewall. Clique no link para ir à página de proteção de vulnerabilidades do Cloud Firewall e ativar a proteção. Protected indica que Virtual Patching of Cloud Firewall Is Enabled entrou em vigor. O status de tratamento das próprias vulnerabilidades emergenciais também inclui Unfixed, Fix Failed, Fixing, Verifying, Fixed, Ignored e Expired.

  • Solução de problemas: Se o relatório diário indicar riscos de vulnerabilidades emergenciais, mas o console não os mostrar, acesse Risk Governance > Vulnerabilities > aba Restart Required para verificar se há vulnerabilidades emergenciais não corrigidas e confirme se a região selecionada no canto superior esquerdo corresponde à localização do ativo.

  • Recomendação de tratamento: Um status de proteção normal não significa segurança absoluta. Recomendamos atualizar os componentes afetados para versões seguras conforme sugerido nos detalhes da vulnerabilidade ou usar patches virtuais do Cloud Firewall para proteção.

• Vulnerabilidades de aplicação não possuem um ID de processo. Como as protejo?

  Vulnerabilidades de aplicação visam instâncias de processos em execução para detecção. Algumas vulnerabilidades de aplicação não estão associadas a um ID de processo e não suportam correção com um clique. Utilize os seguintes métodos para proteção:

  • Atualize para a versão do fornecedor: Acesse o site oficial do fornecedor do software para baixar a versão mais recente e atualizar para corrigir a vulnerabilidade.

  • Use proteção de aplicação RASP: Ative Application Protection (RASP) no console do Security Center para fornecer proteção em runtime através da integração com o Security Center. Este é um recurso pago. Para mais informações sobre suas capacidades de proteção em runtime, consulte {{XREF_3}}.

Operações de correção

• Preciso reiniciar o sistema após a correção de vulnerabilidades?

  A correção automática geralmente não causa o desligamento do servidor, mas algumas correções de vulnerabilidades de kernel podem exigir uma reinicialização. Para correção manual, o requisito depende do tipo de vulnerabilidade: vulnerabilidades de software Linux geralmente não exigem reinicialização, enquanto vulnerabilidades de sistema Windows e vulnerabilidades de kernel Linux exigem uma reinicialização para terem efeito. Recomendamos corrigir vulnerabilidades fora do horário de pico e criar snapshots.

• O efeito da correção automática de patches do Windows pelo Security Center é o mesmo do download e instalação manual de patches?

  Sim. O recurso de correção do Security Center essencialmente chama interfaces no nível do sistema para instalar patches oficiais da Microsoft, o que equivale ao download e instalação manuais.

• Após a Microsoft lançar um patch, preciso esperar a sincronização do Security Center antes de corrigir?

  Não é necessário esperar. Instale diretamente o patch de atualização cumulativa mais recente através da atualização do sistema Windows no servidor para concluir a correção. Após a instalação, acesse o console do Security Center e clique em Verify para a vulnerabilidade atualizar o status. Se o status não for atualizado a tempo, aguarde a próxima varredura periódica. O efeito da correção automática no Security Center é o mesmo da instalação manual de patches oficiais. Para detalhes, consulte a seção sobre instalação automática versus manual de patches neste tópico.

• O Security Center suporta geração e exportação de relatórios de varredura de vulnerabilidades?

  • Relatório de vulnerabilidades de aplicação: Edições pagamento conforme o uso precisam ser atualizadas para Full Host Protection ou superior para suportar varredura de vulnerabilidades de aplicação. Faça logon no console e acesse a aba Risk Governance > Vulnerabilities > Application Vulnerability. Clique no ícone acima da lista para exportar a lista de vulnerabilidades de aplicação no servidor. Nota: Relatórios independentes para URLs de sites não são suportados.

  • Informações de vulnerabilidades de instância ECS especificada: Acesse Urgent Vulnerability > Verify, pesquise o servidor alvo para ir à página de detalhes e clique na seção Vulnerabilities sob a lista IgnoreAdd to Whitelist. Clique no ícone para visualizar e exportar.

  • Ignore: Acesse Add to Whitelist > Verify para criar um relatório de segurança personalizado. O Security Center atualmente não suporta o fornecimento de relatórios dedicados de varredura de vulnerabilidades. Para obter um relatório de varredura de vulnerabilidades, adquira {{XREF_4}} para realizar a varredura.

• Como determino se uma versão do kernel Linux é afetada por uma vulnerabilidade CVE específica?

  1. Execute o comando uname -r para visualizar a versão atual do kernel e compare-a com a faixa de versão afetada no anúncio do CVE.

  2. Exemplo: Se o CVE afeta versões de kernel 4.14 a 6.18.21 e 6.19.11, e a versão atual é 3.10.0, o sistema não é afetado e nenhuma correção é necessária.

  3. Visite {{XREF_5}}{{XREF_6}} para verificar impactos específicos.

  Página oficial de anúncios de riscos de vulnerabilidades e correções da Alibaba Cloud

• Como lido com a ordem de execução, recomendações de concorrência e problemas de exibição de UI durante a correção de vulnerabilidades em lote?

  • Ordem de execução: Vulnerabilidades de software Linux são executadas na ordem da lista do console. Para vulnerabilidades de sistema Windows, vulnerabilidades que exigem patches pré-requisitos são corrigidas primeiro, e o restante é executado na ordem da lista.

  • Recomendação de concorrência: Recomendamos aguardar a conclusão do lote anterior de correções de vulnerabilidades antes de executar o próximo para evitar conflitos de recursos ou confusão de gerenciamento.

  • UI não responde: Se a UI não mostrar resposta após "Sending commands" durante a correção em lote, pode ser um atraso de exibição do frontend. Atualize manualmente a página para visualizar o status "Fixing".

  • Duração: A correção automática Linux geralmente leva de vários minutos a dezenas de minutos, dependendo do número de vulnerabilidades, desempenho do servidor e rede. Se demorar muito, verifique o espaço em disco (recomendado >= 3 GB), conflitos de processos do gerenciador de pacotes ou problemas de permissão.

• Servidores sem endereço IP público suportam correção de vulnerabilidades do Security Center?

  Sim. Desde que o servidor tenha o agente do Security Center instalado e a conectividade de rede esteja normal, a correção de vulnerabilidades é suportada. Ao usar fontes de rede interna da Alibaba Cloud para correção, não é necessário vincular um endereço IP público. Pré-requisitos: Certifique-se de que o Security Center esteja ativado e o agente esteja online.

• Quais são as precauções e recomendações para ativar a correção automática de vulnerabilidades?

  • Não ativado por padrão: A correção automática requer configuração manual de política para ter efeito e não é ativada por padrão.

  • Limitação de escopo suportado: Apenas vulnerabilidades de sistema Linux não-kernel são suportadas, e depende do recurso de correção com um clique (suporte de versão necessário).

  • Recomendações de operação: Recomendamos verificar primeiro em um ambiente de teste. Certifique-se de que uma política de backup de snapshot esteja configurada antes de ativar. Configure a execução fora do horário de pico. Evite ativar para todos os ativos para prevenir consumo excessivo de créditos de correção ou contenção de recursos.

• Corrigir versões de banco de dados ou middleware (como MySQL ou Oracle) afeta os negócios? Quais são as precauções?

  • Impacto nos negócios: O processo de correção em si não modifica dados de negócios no banco de dados, mas atualizações de versão geralmente exigem reinicialização do banco de dados ou service de middleware, o que pode causar uma breve interrupção do service. Recomendamos corrigir fora do horário de pico.

  • Recomendação de backup: Certifique-se de criar um snapshot do ECS ou backup do banco de dados antes da correção. Ao corrigir no Security Center, selecione Create Snapshot and Fix. Se selecionar Fix Without Snapshot, a reversão por snapshot não estará disponível após anomalias.

  • Prioridade de correção: Nem todas as vulnerabilidades precisam ser corrigidas imediatamente. Recomendamos priorizar vulnerabilidades urgentes e de alta gravidade. Vulnerabilidades de gravidade média a baixa podem ser corrigidas em um horário agendado após avaliar o impacto nos negócios, ou você pode optar por Ignorá-las ou adicioná-las à Whitelist após implementar medidas de mitigação (como restringir acesso através de grupos de segurança).

  Vulnerabilidades de banco de dados e middleware são majoritariamente vulnerabilidades de aplicação e não suportam correção com um clique. Faça logon no servidor para atualizar manualmente e depois retorne ao console para clicar em Verify.

• O que faço se a correção de vulnerabilidades em lote mostrar "No matching records" ou uma lista vazia?

  Solucione o problema na seguinte ordem:

  1. Verificação de autorização da edição: Correção com um clique e correção em lote dependem de edições pagas do Security Center ou capacidades pagas de correção de vulnerabilidades. A edição gratuita não suporta correção com um clique. Confirme a edição autorizada para o servidor alvo na página Assets. Atualize a edição ou ative capacidades de correção de vulnerabilidades se necessário. Para escopo específico de suporte, consulte {{XREF_7}}.

  2. Verificação de filtro: Verifique se filtros excessivamente restritivos estão selecionados na página Vulnerability Management, como a opção Fixed and Pending Restarted, gravidade da vulnerabilidade ou status de tratamento. Tente limpar os filtros e atualizar a página.

  3. Verificação de região: Confirme se a região selecionada no canto superior esquerdo do console corresponde à região real dos ativos. A correspondência de região é especialmente importante para vulnerabilidades de aplicação.

  4. Limitação de tipo de vulnerabilidade: Confirme se as vulnerabilidades selecionadas suportam correção com um clique. A correção em lote aplica-se apenas a vulnerabilidades de software Linux e vulnerabilidades de sistema Windows que suportam correção com um clique. Vulnerabilidades de aplicação e vulnerabilidades emergenciais suportam apenas varredura e correção manual, e não suportam correção em lote com um clique.

• O que faço se a correção de vulnerabilidades em um cluster ACK for lenta ou ineficiente?

  • Verifique a configuração da tarefa de correção: A eficiência da correção de vulnerabilidades em clusters de contêineres é afetada pela capacidade de concorrência das tarefas de correção. Recomendamos verificar a configuração relevante das tarefas de correção de vulnerabilidades no console do Security Center para confirmar se a concorrência pode ser aumentada.

  • Recomendação de otimização: Observe o progresso da correção após o ajuste. Se gargalos de desempenho ainda existirem, avalie abrangentemente a carga de recursos dos nós do cluster para evitar contenção de recursos entre tarefas de correção e negócios.

  Durante a correção, visualize o progresso específico da tarefa e nós com falha através de Task Management.

• Recebi um aviso de vulnerabilidade de alto risco da autoridade, mas o controle de acesso já está implementado. Como preencho o relatório de retificação?

  • Princípio de tratamento: Se confirmar que o ativo com a vulnerabilidade teve o acesso estritamente restrito através de grupos de segurança, ACLs de rede e outras medidas (como permitir apenas endereços IP confiáveis), e a correção imediata não for viável por motivos de negócios, descreva a configuração de controle de acesso como uma medida compensatória.

  • Preenchimento do relatório: No relatório de retificação, descreva o status atual da vulnerabilidade e o escopo de impacto, as políticas de controle de acesso implementadas (com capturas de tela da configuração), a conclusão da avaliação de risco e o plano e cronograma de correção subsequentes para provar que o risco está sob controle.

  • Ações de acompanhamento: Medidas compensatórias não substituem a correção. Recomendamos concluir a correção da vulnerabilidade durante uma janela de negócios e atualizar o status da vulnerabilidade através de verificação após a correção.

• Como desativo a correção automática de vulnerabilidades para evitar cobranças adicionais?

  Na página Vulnerability Management, clique em Vulnerability Management Settings no canto superior direito, acesse a aba Automatic Vulnerability Fix Settings e desative a Automatic Vulnerability Fix Switch. Após desativar, as tarefas de correção não são mais executadas automaticamente e nenhum crédito de correção é consumido pela correção automática. Antes de desativar, recomendamos confirmar o escopo da política de correção automática configurada para evitar afetar arranjos existentes de O&M. O cartão de correção automática na página Overview do Security Center serve apenas para ativar este recurso e redirecionar para a aba de configurações. Para desativá-lo, acesse Vulnerability Management Settings.

Correção de tipos específicos de vulnerabilidades

• Como lido com a situação em que o Security Center ainda relata vulnerabilidades após uma correção de upgrade de kernel?

  1. Confirme se o kernel atual foi atualizado com sucesso

     1. Verifique a versão do kernel atualmente em execução e certifique-se de que atenda aos requisitos especificados na descrição da vulnerabilidade.

        docker ps | grep php
        docker exec <container_name> php -v

     2. Confirme se o sistema inicializa com o novo kernel

        docker ps | grep php
        docker exec <container_name> php -v

  2. Verifique e limpe pacotes rpm antigos do kernel

     1. Visualize todos os pacotes de kernel instalados e identifique pacotes antigos do kernel (versões inferiores ao kernel atual).

        docker ps | grep php
        docker exec <container_name> php -v

     2. Crie um snapshot de proteção para o sistema (altamente recomendado)

        Crie um snapshot/imagem para a instância atual no console do ECS para prevenir anomalias no sistema ou falhas de inicialização causadas por exclusão acidental.

     3. Desinstale pacotes rpm antigos do kernel

        2. docker ps | grep php
           docker exec <container_name> php -v

        3. Ou use o método recomendado pela distribuição: CentOS/RedHat:

           docker ps | grep php
           docker exec <container_name> php -v

  3. Ignore o alerta

     Após confirmar que o novo kernel em uso corrigiu a vulnerabilidade, ignore apenas o alerta.

     1. Faça logon no Security Center console.

     2. No painel de navegação à esquerda, escolha Verify > Vulnerability Settings. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado: Vulnerability Settings ou Restart Required.

     3. Clique na aba Restart Required para localizar a vulnerabilidade e clique no nome da vulnerabilidade para ir à página Total Handled Vulnerabilities.

     4. Na coluna Actions, clique no ícone e selecione Unprotected.

• Como atualizo manualmente o kernel do Ubuntu?

  Importante

  Upgrades de kernel envolvem certos riscos. Recomendamos fortemente consultar {{XREF_8}} para o método de upgrade.

  O exemplo a seguir descreve como atualizar manualmente o kernel do Ubuntu de 3.1* para 4.4 no Ubuntu 14.04.

  1. Execute o comando uname -av para verificar se a versão atual do kernel é 3.1*.

     docker ps | grep php
     docker exec <container_name> php -v

  2. Execute os seguintes comandos para verificar se os pacotes de atualização mais recentes do kernel estão disponíveis.

     docker ps | grep php
     docker exec <container_name> php -v

  3. Se nenhuma atualização estiver disponível, execute o comando apt-get update para obter os pacotes de atualização mais recentes.

  4. Execute os seguintes comandos para atualizar o kernel.

     docker ps | grep php
     docker exec <container_name> php -v

  5. Após a instalação dos pacotes de atualização, reinicie o servidor para carregar o novo kernel.

  6. Após a reinicialização do servidor, execute os seguintes comandos para verificar se o upgrade do kernel foi bem-sucedido.

     • Execute o comando uname -av para visualizar o kernel atual.

       docker ps | grep php
       docker exec <container_name> php -v

     • Execute o comando dpkg -l | grep linux-image para visualizar os pacotes de kernel atuais.

       Execute também uname -av para confirmar que a versão atual do kernel é 4.4.0-94-generic. Na saída, linux-image-4.4.0-94-generic e linux-image-extra-4.4.0-94-generic são os pacotes de kernel em uso.

       docker ps | grep php
       docker exec <container_name> php -v

• O que faço se receber um erro de incompatibilidade de kernel alvo ao corrigir uma vulnerabilidade de kernel?

  • Sintoma: Após a correção de vulnerabilidade de kernel com um clique no console do Security Center, a correção falha e a mensagem de erro mostra incompatibilidade de kernel alvo.

  • Causa: O sistema detecta que a versão do kernel no servidor é incompatível com a versão alvo da correção. Isso pode ser causado por alterações manuais na configuração do kernel, versões de kernel não padronizadas ou uma grande diferença de versão do kernel que impede o upgrade normal.

  • Solução:

    • Método 1: Usar correção forçada

      Se confirmar que os negócios não são afetados, use a correção forçada para pular a verificação de compatibilidade:

      1. Feche a caixa de diálogo de falha na correção.

      2. Na área Unprotected, clique no botão Fix da coluna Actions do servidor alvo.

      3. Na caixa de diálogo de correção, a opção Urgent Vulnerability aparece. Após selecionar esta opção e o método de correção, clique em Risk Governance para tentar novamente.

         Importante

         Corrigir vulnerabilidades pode envolver o upgrade do kernel do sistema ou versão de software, o que apresenta riscos de compatibilidade de negócios. Recomendamos selecionar a opção Vulnerabilities para reversão rápida caso ocorram problemas.

    • Método 2: Atualizar manualmente o kernel

      Se a correção forçada não for adequada, consulte {{XREF_9}} para upgrade manual.

• Quando posso usar a correção forçada? Quais são os riscos?

  • Casos de uso: A correção forçada é usada principalmente nos seguintes cenários:

    • Quando a correção com um clique falha devido a incompatibilidade de kernel alvo.

    • Quando o ambiente atual do sistema atende aos requisitos de correção da vulnerabilidade, mas a verificação de compatibilidade falha.

  • Método de operação: Na caixa de diálogo de correção, selecione a opção Application Vulnerability.

  • Aviso de risco: A correção forçada pula a verificação de compatibilidade do cliente e pode apresentar os seguintes riscos:

    • Após a correção, o sistema pode ter problemas de compatibilidade que causem anomalias nos negócios.

    • Falha no upgrade do kernel pode impedir que o sistema inicialize corretamente.

  • Recomendação: Antes de usar a correção forçada, selecione a opção Asset Center para criar um backup para reversão rápida. A correção forçada é recomendada apenas quando você confirma que os negócios não são afetados.

• O que faço se algumas vulnerabilidades no console do Security Center não mostrarem atualizações?

  Nenhuma atualização para uma vulnerabilidade significa que o software com a vulnerabilidade não possui fonte oficial de atualização e não pode ser corrigido no console do Security Center. Consulte as instruções a seguir e escolha uma solução apropriada:

  • A fonte oficial de atualização não forneceu um patch

    • Sintoma: Ao executar o comando de atualização, o sistema retorna already installed and latest version ou No Packages marked for Update ou mensagens similares.

    • Pacotes conhecidos: Gnutls, Libnl, MariaDB

    • Recomendação: Aguarde a fonte oficial lançar uma atualização.

  • A versão do SO não é mais suportada (EOL)

    • Sintoma: Mesmo que o pacote seja a versão mais recente suportada pelo sistema atual, ele ainda não atende à versão necessária para a correção da vulnerabilidade. Por exemplo, CentOS 6.x e outras versões de sistema EOL.

    • Recomendação:

      • Método 1: Atualize o SO para uma versão ainda dentro do ciclo de suporte oficial.

      • Método 2: Após avaliar e confirmar que o risco é gerenciável, marque a vulnerabilidade como "Ignore".

  • Nova varredura: Na página de gerenciamento de vulnerabilidades, execute Scan novamente para obter os resultados de detecção mais recentes e soluções de correção.

  • Aguarde a sincronização: Se nenhuma opção de correção estiver disponível após a varredura, o patch oficial pode não ter sido lançado ainda ou a solução de correção ainda está sendo verificada. Aguarde atualizações subsequentes.

  • Alternativa: Se uma vulnerabilidade não tiver opção de correção por um longo período, consulte o anúncio oficial de segurança do fornecedor do SO para tratamento manual ou tome medidas temporárias de mitigação, como controle de acesso. Após avaliar o risco, execute Ignore.

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

• Após executar yum update kernel, Nothing to do ou nenhuma mensagem de sucesso no upgrade, preciso reiniciar o servidor?

  Mesmo que yum update kernel retorne Nothing to do ou nenhuma mensagem de sucesso no upgrade seja exibida, ainda recomendamos uma reinicialização para garantir que a alteração do kernel tenha efeito total e que o estado de execução do sistema seja consistente com o kernel instalado. Após a reinicialização, clique em Verify na página de detalhes da vulnerabilidade no console do Security Center para verificar se o status da vulnerabilidade foi atualizado para Fixed. Se o status ainda não for atualizado após a verificação, consulte as instruções de solução de problemas nesta seção.

• Como visualizo o alerta de falha após uma correção de vulnerabilidade falhar?

  • Método de visualização: No console do Security Center, na página Host, clique no número sob o painel Vulnerability Details. Encontre a vulnerabilidade com correção falha, clique no ícone da coluna Vulnerabilities da coluna Application Vulnerability e visualize o alerta de falha na correção na caixa de diálogo Security Report.

  • Conteúdo do alerta: O alerta de falha na correção mostra a causa específica da falha, o código de erro correspondente (se houver) e recomendações de tratamento.

• Como lido com códigos de erro em alertas de falha na correção?

  Com base no código de erro no alerta de falha na correção, consulte {{XREF_10}} para a solução correspondente.

• A correção manual de vulnerabilidades faz o Security Center gerar alertas de ataque falso positivo?

  Não. Atualizar manualmente patches de vulnerabilidades não faz o Security Center gerar alertas de ataque falso positivo. Os dois não estão relacionados. Se o console ainda mostrar a vulnerabilidade como não corrigida após a correção manual, clique no botão System Configuration ou aguarde a atualização automática subsequente do status.

• Por que uma vulnerabilidade ainda aparece como não corrigida ou exigindo reinicialização após a correção, ou por que a verificação não responde?

  • Status de reinicialização necessária: Para vulnerabilidades de kernel Linux ou vulnerabilidades marcadas com Security Report, é necessária uma reinicialização do servidor após a correção. Clique em Restart diretamente na página de detalhes da vulnerabilidade do Security Center (disponível apenas para vulnerabilidades de software Linux e vulnerabilidades de sistema Windows com status Fixed - Restart Required. Servidores não Alibaba Cloud não são suportados). Alternativamente, faça logon no console do ECS ou no servidor e execute o comando reboot. Após a reinicialização, clique em Verify para atualizar o status.

  • Reinicialização unificada para múltiplas vulnerabilidades: Múltiplas vulnerabilidades que exigem reinicialização podem ser corrigidas uma a uma para instalar patches, e então o sistema pode ser reiniciado uma única vez no final. Não é necessário reiniciar para cada vulnerabilidade.

  • Verificação não responde: Se o status não mudar por um longo período após clicar em Verify, pode ser causado por configuração incompleta do nível de varredura de vulnerabilidades ou status offline do agente. Para detalhes, consulte a seção sobre por que a verificação manual não responde após a correção.

  • Atraso na sincronização de dados: Após ignorar uma vulnerabilidade ou concluir uma correção, a exibição no console pode ter um atraso, o que é normal. Aguarde a sincronização automática ou acione manualmente a verificação.

• Por que vulnerabilidades são detectadas mesmo que eu não tenha instalado ativamente software de terceiros?

  Vulnerabilidades de software de terceiros detectadas pelo Security Center podem vir de componentes pré-instalados em imagens de sistema ou suas bibliotecas de dependências, e são detectadas mesmo que você não tenha instalado ativamente o software. Para mais informações, consulte a seção sobre por que instâncias ECS recém-adquiridas possuem vulnerabilidades. Recomendamos visualizar a descrição de impacto e o caminho do arquivo nos detalhes da vulnerabilidade para confirmar o arquivo específico que acionou o alerta. Se for confirmado como falso positivo ou não precisar de correção após avaliação, execute Ignore na vulnerabilidade ou adicione-a a uma whitelist com base no tipo de vulnerabilidade.

• O que significa quando uma vulnerabilidade é marcada como corrigida com o motivo Rule Offline?

  Rule Offline é um dos motivos de tratamento para vulnerabilidades de aplicação, indicando que a regra de detecção foi desativada e a vulnerabilidade não será mais identificada como uma vulnerabilidade de aplicação. Outros motivos paralelos incluem Process Not Exist, Middleware Not Exist e Middleware Updated. Nenhuma ação adicional é necessária quando esta marca aparece.

• Por que vulnerabilidades são encontradas no diretório /usr/share/doc? As mesmas vulnerabilidades reaparecerão após a correção?

  • Causa da vulnerabilidade em /usr/share/doc: Arquivos neste diretório são majoritariamente documentações de componentes básicos ou arquivos de exemplo que vêm com a imagem do sistema. As versões de componentes registradas nesses arquivos são baixas e correspondem a vulnerabilidades conhecidas no banco de dados de vulnerabilidades, o que aciona alertas. Este é um comportamento normal de detecção. Para eliminar alertas, atualize a versão do componente ou adicione-o a uma whitelist após confirmar que não há risco real em runtime.

  • Causa da recorrência de vulnerabilidades: A correção de vulnerabilidades aplica patch apenas na versão detectada na varredura atual. Se atualizações subsequentes do sistema ou aplicação introduzirem novas vulnerabilidades, configurações mudarem ou melhores práticas de segurança não forem seguidas, novos registros de vulnerabilidades ainda podem ser detectados.

  • Recomendações de proteção contínua: Recomendamos realizar varreduras de vulnerabilidades regularmente, acompanhar anúncios oficiais de segurança e combinar verificações de linha de base para fortalecer o sistema, em vez de depender de correções únicas.