Security Center:FAQ sobre gerenciamento de vulnerabilidades

Por que o mesmo servidor relata várias ocorrências da mesma vulnerabilidade?

O Security Center detecta vulnerabilidades de aplicativos por instância de processo em execução. Se um servidor executar duas instâncias do mesmo processo com a mesma vulnerabilidade (por exemplo, dois serviços Tomcat em portas diferentes), cada uma será relatada separadamente. O sistema não verifica softwares instalados que não estejam em execução.

Por que os resultados de verificação para vulnerabilidades como Fastjson às vezes variam?

O Security Center detecta uma vulnerabilidade apenas quando a lógica de negócios chama o componente vulnerável (como um pacote JAR) durante a execução. Em modelos de carregamento dinâmico, os resultados variam conforme os componentes ativos em cada verificação.

Após o agente ficar offline, por que o console ainda mostra registros de vulnerabilidades?

O Security Center retém os registros de vulnerabilidades após o agente ficar offline, mas eles se tornam obsoletos e não podem ser corrigidos, verificados ou limpos. Períodos de obsolescência:

A verificação de vulnerabilidades ou a validação de prova de conceito (POC) para vulnerabilidades urgentes afetam os sistemas de negócios?

Geralmente não. A validação de POC envia apenas 1 ou 2 solicitações de sondagem inofensivas, sem qualquer ataque ou ação destrutiva. Existe risco mínimo apenas se o aplicativo alvo for excepcionalmente frágil ao processar entradas inesperadas.

Por que uma verificação de vulnerabilidades às vezes aciona um erro de falta de memória (OOM)?

O agente tem limite de memória de 200 MB. Se uma verificação exceder esse limite, o mecanismo OOM encerra o processo de detecção (ALiSecCheck).

Esse comportamento é normal e não indica falta de memória em todo o sistema. O cgroup aegisRtap0 gerencia o limite. As entradas OOM aparecem nos logs do dmesg. Nenhuma ação é necessária.

Qual é o escopo de uma verificação de vulnerabilidades?

A verificação abrange as camadas de sistema e de aplicativo:

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

1. Faça login no console do Security Center.

2. No painel de navegação à esquerda, escolha Risk Governance > Vulnerabilities.

3. Na seção de visão geral, localize o cartão de estatísticas Disclosed Vulnerabilities e clique em no número total para visualizar todas as vulnerabilidades detectáveis e seus detalhes.

O Security Center suporta detecção de vulnerabilidades em serviços como Elasticsearch?

Sim. Visualize os resultados da detecção na página Application Vulnerability no console.

O Security Center alerta sobre vulnerabilidades CVE que ainda não foram incluídas no banco de dados de vulnerabilidades?

O Security Center alerta apenas sobre vulnerabilidades conhecidas já incluídas no banco de dados de vulnerabilidades. Se um CVE não foi oficialmente divulgado ou incluído, o sistema não identifica o risco e não envia alertas. Caso uma vulnerabilidade tenha sido divulgada com patches disponíveis, mas ainda não seja detectada, verifique se medidas de correção manual ou mitigação já foram aplicadas. Recomendamos acompanhar os avisos de segurança da Alibaba Cloud. Assim que uma vulnerabilidade for oficialmente divulgada e o fornecedor lançar um patch, o Security Center atualizará suas regras de detecção.

Onde encontro a classificação mais recente das regras de vulnerabilidade após ajustes nas regras?

Algumas regras de vulnerabilidade podem ser removidas da categoria de vulnerabilidades de aplicativo devido a falsos positivos e reclassificadas como vulnerabilidades de sistema. Verifique a classificação mais recente na lista Supported vulnerabilities na página Vulnerabilities.

O Security Center suporta Ubuntu 24.04? Como verifico vulnerabilidades manualmente?

O Security Center suporta verificação manual de vulnerabilidades. As principais distribuições Linux são geralmente suportadas. Para verificar, faça login no console, acesse Risk Governance > Vulnerabilities, selecione a região no canto superior esquerdo, clique em Scan Now e selecione os tipos de vulnerabilidade. Alternativamente, na página Host, selecione o servidor alvo e use a opção de verificação de vulnerabilidades em Security Check. Para suporte específico a versões de SO, consulte os resultados reais da verificação no console.

Por que o Security Center e softwares de segurança de terceiros (como Huorong) mostram resultados de detecção diferentes?

O Security Center detecta principalmente patches oficiais do sistema Windows (como atualizações cumulativas KBxxxxx), enquanto softwares de segurança de terceiros, como o Huorong, podem não cobrir esses patches no nível do sistema ou usar estratégias de detecção diferentes. Diferenças nos resultados são normais.

Por que uma instância inativa ainda mostra alertas de vulnerabilidade de alto risco?

Os possíveis motivos incluem:

• Ativos legados (instâncias ou snapshots não totalmente liberados).

• Riscos de recursos associados (como fraquezas de configuração no OSS, RDS ou outros produtos de nuvem).

• Atraso na sincronização de dados.

Se o status do alerta mostrar Passed, não há risco ativo e ele pode ser ignorado.

Por que vulnerabilidades históricas aparecem e a pontuação de segurança muda após desativar a opção "Show only real-risk vulnerabilities"?

Vulnerabilidades de aplicativo podem ter sido verificadas anteriormente, mas não exibidas porque a opção estava ativada. Ao desativar a opção, as vulnerabilidades históricas são exibidas e a pontuação de segurança é atualizada. A pontuação será atualizada novamente após um período.

Uma nova verificação utiliza ou restaura dados históricos de vulnerabilidades?

Não. O Security Center retém apenas dados de vulnerabilidades atualmente válidos (detectadas nos últimos 30 dias). Cada verificação é uma detecção independente baseada no estado atual do ativo. Registros históricos de vulnerabilidades expirados e limpos não são recarregados.

Como distingo entre verificação ativa e detecção passiva nos resultados de verificação de vulnerabilidades do Security Center?

Nos resultados da verificação, as entradas marcadas como Web Scanner provêm de verificação ativa (envio de solicitações de sondagem via IP público para validação) e devem ter prioridade na correção. As entradas marcadas como Software Composition Analysis provêm de detecção passiva (comparação de informações de versão de software coletadas localmente via Agente).

Por que os resultados de detecção de vulnerabilidades de aplicativo não mostram caminhos de arquivo específicos?

A detecção de vulnerabilidades de aplicativo visa instâncias específicas de processos em execução. Se uma vulnerabilidade for detectada, mas nenhum caminho de arquivo específico for mostrado, consulte as sugestões nos detalhes da vulnerabilidade ou verifique caminhos comuns (como arquivos JAR no diretório de trabalho do Tomcat). Para vulnerabilidades complexas (como desserialização Jackson), talvez seja necessário fazer login no servidor e verificar os caminhos potenciais fornecidos (como /data/.../jackson-databind-*.jar).

Os resultados da verificação de vulnerabilidades do Security Center substituem dados históricos?

Sim. Após a conclusão de uma verificação, os resultados são automaticamente atualizados (substituídos) na página de detalhes do ativo no console. Visualize os resultados mais recentes acessando Risk Governance > Vulnerabilities, ou clique em Task Management no canto superior direito para visualizar o status de execução da tarefa de verificação.

Por que o botão Fix está esmaecido?

Na maioria dos casos, sua edição não suporta correção com um clique. A Basic Edition e a Anti-virus Edition não possuem esse recurso. Adquira o serviço complementar Vulnerability Fixing ou faça upgrade para a Enterprise Edition ou Ultimate Edition.

Se sua edição suportar correção com um clique, verifique se há problemas no servidor:

Linux

Windows

Por que vulnerabilidades de aplicativo não podem ser corrigidas com a correção com um clique?

Vulnerabilidades de sistema (software Linux e sistema Windows) residem em componentes do SO com caminhos de correção padronizados, permitindo a correção com um clique.

Vulnerabilidades de aplicativo existem em código implantado internamente ou em software de terceiros. A correção depende da sua lógica de negócios; portanto, devem ser corrigidas manualmente.

Por que há tantas vulnerabilidades no meu servidor?

Softwares mais antigos acumulam vulnerabilidades à medida que novos métodos de ataque surgem. Para focar nos riscos de maior prioridade, ative a opção Show Only Exploitable Vulnerabilities.

O que devo fazer se receber um erro "Permission acquisition failed" ao corrigir uma vulnerabilidade?

O arquivo necessário para a correção não pertence ao usuário root.

1. No Security Center, visualize os detalhes da vulnerabilidade para identificar o arquivo específico e seu caminho.

2. Faça login no servidor e altere o proprietário do arquivo para root.

3. Retorne ao console do Security Center e tente a correção novamente.

Em que ordem as vulnerabilidades são corrigidas em lote?

Vulnerabilidades de software Linux e vulnerabilidades Web-CMS são corrigidas na ordem em que aparecem na lista do console.

Vulnerabilidades do sistema Windows que exigem patches pré-requisitos são corrigidas primeiro. As vulnerabilidades restantes são então corrigidas na ordem em que aparecem na lista do console.

Por que reiniciar é ineficaz após corrigir uma vulnerabilidade de kernel do Ubuntu?

Isso ocorre quando a ordem de inicialização do GRUB foi modificada manualmente antes da correção. O script de correção do sistema não consegue definir automaticamente o kernel recém-instalado como item de inicialização padrão.

Solução 1: Configurar automaticamente o novo kernel

Esta solução abandona a configuração personalizada original do GRUB e permite que o sistema aplique as configurações padrão para o novo kernel.

1. Antes de executar a correção, faça login no seu servidor Ubuntu.

2. Execute o seguinte comando:

      export DEBIAN_FRONTEND=noninteractive

3. Retorne ao console do Security Center e execute a correção com um clique.

4. Reinicie o servidor conforme solicitado. O sistema habilitará automaticamente o kernel mais recente.

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

Use esta solução para manter a configuração original do GRUB.

1. No console do Security Center, execute a correção com um clique e reinicie o servidor conforme solicitado.

2. Faça login no seu servidor Ubuntu.

3. Modifique a ordem de inicialização do GRUB para definir o kernel recém-instalado como item de inicialização padrão. Isso geralmente envolve modificar /etc/default/grub e executar update-grub. Consulte Modificar a ordem de inicialização do kernel para ECS Linux CentOS.

4. Reinicie o servidor novamente.

Preciso reiniciar o sistema após corrigir uma vulnerabilidade?

• Windows: A reinicialização é sempre necessária.

• Linux Software Vulnerability: A reinicialização é necessária se uma vulnerabilidade de kernel foi corrigida, ou se a vulnerabilidade tiver uma tag Restart Required na aba Linux Software Vulnerability em Risk Governance > Vulnerabilities no console do Security Center.

A correção automática geralmente não causa desligamento do servidor, mas algumas correções de vulnerabilidades de kernel podem exigir reinicialização. Recomendamos operar fora do horário de pico e criar snapshots antes da correção.

Por que a reversão de uma vulnerabilidade falha?

Duas causas comuns:

• Agente offline: A operação de reversão depende do agente do Security Center estar online. Se o agente estiver offline, o comando não poderá ser entregue. Solucione o problema de conectividade do agente primeiro.

• Snapshot de backup inválido: A reversão depende do snapshot de backup criado antes da correção. Se o snapshot expirou ou foi excluído manualmente, a reversão não poderá prosseguir.

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

• Usuário RAM sem permissão: O usuário RAM não possui permissões para criação de snapshots. Use uma conta Alibaba Cloud para a operação. Consulte a Visão geral de usuários RAM.

• Servidor fora da Alibaba Cloud: A criação de snapshots para correção de vulnerabilidades é suportada apenas em servidores da Alibaba Cloud.

O Security Center suporta verificação e correção de vulnerabilidades para sistemas operacionais em fim de vida (EOL)?

Para versões de SO que atingiram o fim de vida (como CentOS 7.6), o Security Center não suporta verificação de vulnerabilidades ou correção com um clique. Se nenhuma vulnerabilidade for detectada, verifique se a versão do seu SO está dentro do intervalo suportado. Caso contrário, recomendamos fazer upgrade para uma versão de SO suportada, ou avaliar o risco e marcar a vulnerabilidade como Ignored no console.

Qual é o escopo de impacto das vulnerabilidades de SO quando vários serviços são implantados no mesmo servidor?

Quando vários serviços são implantados no mesmo servidor, as vulnerabilidades de SO afetam todos os serviços nesse servidor porque compartilham o mesmo ambiente de SO. Recomendamos aplicar patches de sistema em todo o servidor e criar um backup de snapshot antes da correção.

Preciso reiniciar o servidor após corrigir uma vulnerabilidade? Qual é o impacto nos negócios?

• Vulnerabilidades do sistema Windows: É necessário reiniciar o servidor para que os patches tenham efeito. A reinicialização causa breve interrupção do serviço. Recomendamos operar fora do horário de pico e selecionar Automatically Create Snapshot and Fix Risk para permitir reversão.

• Vulnerabilidades de kernel Linux: Reinicialização necessária. Se o status permanecer como Fixed and Pending Restarted após a correção, clique em Restart no console ou reinicie o servidor manualmente e, em seguida, clique em Verify.

• Vulnerabilidades de software Linux: Geralmente não requer reinicialização, a menos que o aviso de vulnerabilidade especifique Restart required.

• Exemplo específico de CVE: Para CVE-2024-57979, se o console não indicar necessidade de reinicialização, nenhuma reinicialização é necessária.

• Impacto nos negócios: A reinicialização causa interrupção do serviço; o processo de correção pode consumir recursos e causar lentidão. Recomendamos fazer backup (snapshot) e testar em um ambiente de teste primeiro.

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

• Risco: Vulnerabilidades de escalonamento de privilégios locais de alto risco (como CVSS 7.8) podem ser exploradas por invasores para roubar arquivos sensíveis (/etc/shadow, chaves privadas SSH) e obter acesso root, levando ao comprometimento total do servidor.

• Mitigação: Se a correção imediata não for possível, restrinja o acesso via grupos de segurança e fortaleça o monitoramento, mas a correção definitiva ainda é a aplicação do patch.

• Localização de vulnerabilidade SSL/TLS: Para vulnerabilidades de divulgação de informações SSL/TLS (como CVE-2016-2183), execute ping no domínio para resolver o IP e, em seguida, use recursos CLB/K8s para localizar os nós afetados para correção manual.

O efeito da correção automática de patches do Windows pelo Security Center é o mesmo que baixá-los e instalá-los manualmente?

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

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

• Relatórios de vulnerabilidades de aplicativo: Versões pay-as-you-go precisam fazer upgrade para Comprehensive Host Protection ou superior para suportar verificação de vulnerabilidades de aplicativo. No console, acesse Risk Governance > Vulnerabilities > Application Vulnerability para visualizar e exportar a lista. Relatórios independentes para URLs de sites não são suportados.

• Vulnerabilidades de instância ECS específica: Acesse Assets > Host, pesquise o servidor alvo, entre na página de detalhes e clique em Vulnerability Details > Application Vulnerability para visualizar e exportar.

• Verificação da origem do relatório: Verifique se o campo Scan tool mostra Alibaba Cloud Security Center e se o tipo de relatório inclui Host vulnerability scan.

• Relatórios de vulnerabilidades de alto risco (como Nacos): Visualize eventos de gerenciamento no módulo Security Management do console.

Como determino se minha versão do kernel Linux é afetada por um CVE específico?

1. Execute uname -r para verificar a versão atual do kernel e compare-a com o intervalo de versões afetadas no aviso 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 servidor não é afetado.

3. Visite a página oficial de anúncios de riscos e correções de vulnerabilidades da Alibaba Cloud para detalhes específicos sobre o impacto.

Qual é a ordem de execução e recomendação de simultaneidade para correção de vulnerabilidades em lote?

• Ordem de execução: Vulnerabilidades de software Linux são corrigidas na ordem da lista do console. Vulnerabilidades do sistema Windows priorizam patches pré-requisitos primeiro.

• Simultaneidade: Aguarde a conclusão do lote anterior antes de iniciar o próximo para evitar conflitos de recursos.

• UI sem resposta: Se a UI mostrar Sending command sem resposta, isso pode ser um atraso de exibição. Atualize manualmente a página para ver o status Fixing.

• Duração: A correção automática no Linux geralmente leva de minutos a dezenas de minutos, dependendo da quantidade de vulnerabilidades, desempenho do servidor e rede. Se demorar muito, verifique o espaço em disco (recomendado 3 GB ou mais), conflitos no gerenciador de pacotes ou problemas de permissão.

O Security Center suporta correção de vulnerabilidades para servidores sem endereços IP públicos?

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 internas da Alibaba Cloud, nenhum IP público é necessário. Pré-requisitos: O serviço Security Center deve estar ativado e o Agente deve estar online.

Quais são as consideraçõ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 antes de entrar em vigor.

• Limitação de escopo: Suporta apenas vulnerabilidades de sistema Linux que não sejam de kernel e depende do recurso de correção com um clique (requer suporte da versão).

• Recomendações: Teste em um ambiente de teste primeiro. Garanta que políticas de backup de snapshot estejam configuradas. Agende fora do horário de pico. Evite ativar para todos os ativos para prevenir consumo excessivo de cotas de correção.

Uma vulnerabilidade foi corrigida, mas o Security Center ainda a relata. O que devo fazer?

Algumas vulnerabilidades, particularmente as de kernel Linux, exigem reinicialização. Na página de detalhes da vulnerabilidade, clique em Restart. Após a reinicialização, clique em Verify. Se o status mostrar Fixed and Pending Restarted, a correção foi bem-sucedida.

O host não instalou um patch específico, mas a vulnerabilidade do Windows aparece como corrigida. Por quê?

Isso é esperado. As atualizações de segurança do Windows são cumulativas: cada patch mensal inclui todas as correções anteriores. Quando o Security Center detecta a atualização cumulativa mais recente, ele marca todas as vulnerabilidades mais antigas cobertas por essa atualização como corrigidas.

Para confirmar se uma vulnerabilidade antiga específica está coberta, visite o site oficial de patches da Microsoft e pesquise o patch instalado mais recente pelo seu número KB. Verifique os detalhes do pacote para confirmar a cobertura.

Após corrigir uma vulnerabilidade, por que ela ainda mostra "Not fixed"?

Três causas possíveis:

1. Atraso na verificação: Após uma correção manual, clique em Verify para acionar uma verificação instantânea. A atualização do status leva alguns minutos.

2. Cache do console: Force a atualização da página ou aguarde alguns minutos.

3. Correção incompleta: A correção pode não ter sido totalmente bem-sucedida, ou pode haver vários caminhos de vulnerabilidade com apenas um corrigido. Verifique novamente as etapas de correção.

O Security Center pode verificar automaticamente vulnerabilidades no estado "Fixed and Pending Restart"?

Não. Reinicie o servidor pelo console do Security Center ou manualmente e, em seguida, clique em Verify para confirmar se a correção foi bem-sucedida.

Por que não há resposta quando verifico manualmente após corrigir uma vulnerabilidade?

Duas causas possíveis:

• Nível de verificação não configurado: O Security Center atualiza apenas vulnerabilidades cujo nível de gravidade está selecionado em Vulnerability Settings. Verifique se os níveis de verificação cobrem a vulnerabilidade alvo.

• Agente offline: A função Verify requer uma conexão ativa entre o console e o agente. Se o agente estiver offline, resolva o problema de conectividade primeiro e tente novamente.

Como visualizo a notificação de falha após uma correção de vulnerabilidade falhar?

Como visualizar: Na página Vulnerabilities no console do Security Center, clique em no número sob Fixing. No painel Fixing, localize a vulnerabilidade com falha e clique em no ícone na coluna Status para visualizar a notificação de falha na caixa de diálogo Cause Details.

Conteúdo da notificação: A notificação de falha mostra o motivo específico da falha na correção, o código de erro correspondente (se disponível) e as ações sugeridas.

Como lido com códigos de erro nas notificações de falha de correção?

Siga as soluções fornecidas na documentação de Solucionar causas de falhas na correção de vulnerabilidades para o código de erro específico mostrado na notificação de falha.

Corrigir manualmente uma vulnerabilidade 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. Se o console ainda mostrar Unfixed após a correção manual, clique em no botão Verify ou aguarde a atualização automática do status dos dados.

O Security Center ainda relata uma vulnerabilidade de kernel após um upgrade. O que devo fazer?

1. Confirme que o kernel foi atualizado. Execute os seguintes comandos para verificar a versão do kernel em execução e confirmar se atende aos requisitos nos detalhes da vulnerabilidade: Confirme que o sistema inicia usando o novo kernel:

      uname -av
      cat /proc/version

      cat /etc/grub.conf

2. Remova pacotes antigos do kernel. Liste todos os pacotes de kernel instalados e identifique versões antigas: Desinstale o pacote antigo do kernel: Alternativamente, use o método recomendado pela distribuição. Para CentOS/Red Hat:

   Importante

   Antes de remover pacotes antigos do kernel, crie um snapshot ou imagem para a instância atual no console do Elastic Compute Service.

      rpm -qa | grep kernel

      rpm -e kernel-<old_version_number>

      yum remove kernel-<old_version_number>

3. Ignore o alerta (opcional). Se o kernel em execução já corrigiu a vulnerabilidade, ignore o alerta:

   1. Faça login no Faça login no console do Security Center.

   2. No painel de navegação à esquerda, escolha Risk Governance > Vulnerabilities. No canto superior esquerdo do console, selecione a região onde seu ativo está implantado: Chinese Mainland ou Outside Chinese Mainland.

   3. Na aba Linux Software Vulnerability, localize a vulnerabilidade e clique em seu nome.

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

Como atualizo manualmente um kernel do Ubuntu?

O exemplo a seguir atualiza o kernel 3,1* para o kernel 4,4 no Ubuntu 14.04.

1. Confirme que a versão atual do kernel é 3,1*:

      uname -av

2. Verifique se o pacote de atualização mais recente do kernel está disponível:

      apt list | grep linux-image-4.4.0-94-generic
      apt list | grep linux-image-extra-4.4.0-94-generic

3. Se nenhuma atualização relacionada estiver disponível, execute apt-get update para recuperar a lista de pacotes mais recente.

4. Instale a atualização do kernel:

      apt-get update && apt-get install linux-image-4.4.0-94-generic
      apt-get update && apt-get install linux-image-extra-4.4.0-94-generic

5. Reinicie o servidor para aplicar o novo kernel.

6. Após a reinicialização do servidor, verifique a atualização do kernel:

      uname -av

      dpkg -l | grep linux-image

O que devo fazer se receber uma notificação de incompatibilidade de kernel ao corrigir uma vulnerabilidade de kernel?

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

Causa: A versão do kernel do servidor é incompatível com a versão alvo da correção. Isso pode ocorrer se o kernel foi modificado manualmente, se uma versão não padrão está em uso, ou se a diferença de versão é muito grande para um upgrade normal.

Resolução:

Solução 1: Usar correção forçada

Se você tiver certeza de que suas cargas de trabalho não serão afetadas, use a correção forçada para ignorar a verificação de compatibilidade:

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

2. Na seção Unhandled Vulnerabilities, clique em Fix na coluna Actions para o servidor alvo.

3. Na caixa de diálogo exibida, marque a caixa de seleção Mandatory Fix.

4. Selecione um método de correção e clique em Fix Now.

   Importante

   A correção forçada ignora a verificação de compatibilidade do cliente, o que pode introduzir riscos. Recomendamos selecionar Automatically Create Snapshot and Fix Risk para manter a capacidade de reversão.

5. Clique em Fix Now.

Solução 2: Atualizar manualmente o kernel

Se a correção forçada não for adequada, consulte Como atualizo manualmente um kernel do Ubuntu? para etapas de upgrade manual.

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

Quando usar: A correção forçada aplica-se quando:

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

• Você tem certeza de que o ambiente do sistema atende aos requisitos de correção, mas a verificação de compatibilidade não foi aprovada.

Como usar: Marque a caixa de seleção Mandatory Fix na caixa de diálogo de correção.

Riscos: A correção forçada ignora a verificação de compatibilidade, o que pode causar:

• Problemas de compatibilidade após a correção que podem causar interrupções nos negócios.

• Falha no upgrade do kernel que pode impedir a inicialização normal do sistema.

Recomendação: Antes de usar a correção forçada, selecione Automatically Create Snapshot and Fix Risk para reversão rápida. Use a correção forçada apenas quando tiver certeza de que suas cargas de trabalho não serão afetadas.

O que devo fazer se uma vulnerabilidade não mostrar atualizações disponíveis?

Nenhum patch oficial disponível

Quando o comando de atualização retorna uma mensagem como already installed and latest version ou No Packages marked for Update, a fonte oficial de atualizações não lançou um patch. Isso pode afetar pacotes como Gnutls, Libnl e MariaDB. Aguarde a fonte oficial de software lançar uma atualização.

Versão do SO atingiu o fim de vida (EOL)

Se o pacote de software for a versão mais recente suportada pelo sistema atual, mas ainda não atender aos requisitos de correção, a versão do SO pode ter passado do seu EOL (por exemplo, CentOS 6.x). Duas opções:

• Atualize o SO para uma versão dentro do período de suporte oficial.

• Após avaliar o risco e confirmar que é gerenciável, ignore a vulnerabilidade no console do Security Center.

Como lido com um timeout ao conectar à fonte Yum da Alibaba Cloud?

Se a conexão atingir o tempo limite, um erro semelhante ao seguinte aparecerá:

[Errno 12] Timeout on http://mirrors.aliyun.com/centos/6/os/x86_64/repodata/repomd.xml: (28, 'connect() timed out!')

1. Verifique se a resolução DNS está funcionando. Execute ping mirrors.aliyun.com ou nslookup mirrors.aliyun.com.

2. Se o acesso à rede estiver normal, aguarde um momento e tente novamente. O timeout pode ser causado por flutuações temporárias de rede ou alto tráfego na fonte de espelhamento.

Como limpo pacotes de patches de vulnerabilidades do Windows do diretório do cliente?

Após uma correção com um clique, o agente baixa, instala e remove automaticamente o pacote de patches.

Se o patch permanecer após 3 dias, limpe-o manualmente:

1. Faça login no Faça login no console do Security Center.

2. No painel de navegação à esquerda, escolha System Settings > Feature Settings. No canto superior esquerdo do console, selecione a região onde seu ativo está implantado: Chinese Mainland ou Outside Chinese Mainland.

3. Se a autoproteção do cliente estiver ativada, acesse a página de detalhes do servidor em Asset Center e desative a opção Client Protection.

   Nota

   A autoproteção do cliente bloqueia solicitações para excluir ou baixar arquivos de processo do diretório do agente em servidores Windows. Se você não ativou a autoproteção do cliente, pule esta etapa.

4. Faça login no servidor Windows com permissões de administrador e exclua o pacote de patches do seguinte diretório:

   Importante

   O caminho padrão do pacote de patches é C:\Program Files (x86)\Alibaba\Aegis\globalcfg\hotfix.

5. (Opcional) Na página de detalhes do servidor, ative Client Protection.

O caminho da vulnerabilidade mostrando "none" nos resultados de verificação do Security Center requer ação?

Isso geralmente indica que uma vulnerabilidade foi detectada, mas o caminho específico do arquivo não pôde ser localizado. Este é um comportamento normal e nenhuma ação especial é necessária.

O pacote de recursos de correção de vulnerabilidades do Security Center é assinado automaticamente ou precisa de ativação manual?

Os usuários precisam resgatá-lo manualmente no console para que tenha efeito. Ele não é assinado ou ativado automaticamente por padrão.

Perguntas frequentes sobre registro de testes de penetração e verificação de vulnerabilidades

• Falha no envio da solicitação: Certifique-se de inserir apenas o endereço IP de origem público real (a máquina que inicia a verificação), não o IP do servidor alvo sendo verificado.

• Prompt "Not my asset" ao adicionar IP: Isso geralmente significa que o IP pertence a outra conta Alibaba Cloud. Mude para a conta proprietária do IP e envie a solicitação a partir dessa conta.

• Configuração de ferramenta de verificação de terceiros: Adicione o IP da ferramenta de verificação de terceiros à lista de permissões na plataforma de gerenciamento de segurança e envie uma solicitação de teste de penetração.

Por que ainda sou cobrado por verificações agendadas após cancelar serviços pagos?

Os recursos pay-as-you-go podem ainda estar ativados. Solução:

1. Faça login no console do Security Center.

2. No painel de navegação à esquerda, escolha Overview para acessar a página Overview.

3. Na seção Pay-as-you-go no canto superior direito da página, você pode:

   • Desativar serviços específicos: Desative a chave do serviço correspondente para parar o faturamento apenas desse serviço.

   • Desativar todos os serviços de uma vez: Clique em no botão Disable All Pay-as-you-go Services no canto superior direito da página para desativar todos os recursos pay-as-you-go de uma vez.

4. Recarregue e liquide qualquer saldo pendente para evitar impactos em outros serviços.

Como consulto logs de operação do Security Center no ActionTrail?

Use o console do ActionTrail em Console do ActionTrail - Eventos do Security Center. Se nenhum dado for retornado, verifique a configuração de região no console do ActionTrail — mude para a região onde os recursos estão localizados (por exemplo, Xangai), pois os logs de operação podem ser armazenados em regiões diferentes.

Por que o caminho de detecção da vulnerabilidade urgente CVE-2019-14439 não mostra o ambiente de contêiner?

Problema: O caminho de detecção da vulnerabilidade urgente CVE-2019-14439 não mostra o ambiente de contêiner. O caminho é /skywalking/oap-libs/jackson-databind-2.9.5.jar. O ambiente encontrado no servidor é um ambiente de contêiner, mas o ambiente local não contém a biblioteca Jackson. Em contraste, a vulnerabilidade de execução remota de código Spring Framework JDK >= 9 (também uma vulnerabilidade urgente) mostra que existe em contêineres.

Resposta: Os scripts de detecção variam por tipo de vulnerabilidade. Para cenários que exigem verificação de ambientes de contêiner, recomendamos usar a ferramenta de verificação de vulnerabilidades de aplicativo.

Como consulto os CVEs corrigidos pelos patches mensais do Windows?

1. Faça login no console do Security Center.

2. No painel de navegação à esquerda, escolha Risk Governance > Vulnerabilities, selecione a aba Windows System Vulnerability e obtenha o número do patch que você precisa consultar (por exemplo, patch 5043050).

3. Visite o link de patch da Microsoft e substitua o número do patch no final pelo que você precisa consultar. Por exemplo: https://support.microsoft.com/help/5043050

4. Na página aberta, clique em xx Month xx Security Update para visualizar a lista de CVEs corrigidos por aquele pacote KB.

5. Compare a lista de CVEs com a lista de CVEs exibida na coluna CVE ID no Security Center para garantir consistência.