Security Center:Analyze and handle security alerts

Virus Detection and Removal

• Casos de uso

  • Confirmação de atividade maliciosa: Quando o Security Center detecta processos maliciosos em execução, como vírus, trojans ou ransomware, que precisam ser bloqueados imediatamente.

  • Requisitos de resposta a emergências: Necessidade de conter rapidamente a propagação de vírus ou riscos de vazamento de dados para evitar que as ameaças se espalhem para outros servidores.

• Antes de começar

  A verificação de vírus pode causar riscos de interrupção do serviço. Para evitar afetar os negócios normais, verifique os arquivos de origem antes do tratamento. Os pontos de verificação comuns incluem:

  • Verificar propriedades do arquivo: Confirme se o arquivo é um vírus checando o caminho, a assinatura e o valor de hash (evite excluir acidentalmente arquivos de sistema ou de negócios).

  • Avaliação de dependência de negócios: Verifique se o arquivo é chamado por serviços críticos (como componentes relacionados ao nginx ou mysql).

• Como funciona

  • Encerra imediatamente o processo do vírus e move o arquivo para quarentena. Após a quarentena, o arquivo não pode ser executado, acessado ou propagado.

    Aviso

    • Encerrar o processo pode causar anomalias em serviços que dependem dele (por exemplo, se o vírus se disfarçar como um processo legítimo).

    • Se o arquivo em quarentena for um arquivo de negócios infectado com código malicioso (como um componente central de aplicação), a quarentena pode causar interrupção do serviço.

  • Arquivos em quarentena podem ser restaurados dentro de 30 dias. Arquivos restaurados reaparecem na lista de alertas e o Security Center continua a monitorá-los. Para restauração, consulte Visualizar e recuperar arquivos em quarentena.

    Nota

    Arquivos não restaurados dentro de 30 dias são excluídos automaticamente e não podem ser recuperados.

• Próximas etapas

  Revise regularmente a quarentena: Confirme as propriedades dos arquivos dentro de 30 dias para evitar exclusão irreversível. Para visualizar arquivos em quarentena, consulte Visualizar e recuperar arquivos em quarentena.

Deep Cleanup

O Deep Cleanup é uma capacidade especializada de remoção desenvolvida pela equipe de especialistas em segurança do Security Center após análise e testes aprofundados de vírus persistentes e resistentes.

• Casos de uso

  A varredura profunda é uma solução especializada para vírus persistentes que infectam arquivos. Características deste tipo de vírus:

  • Infectam arquivos do host: O vírus se injeta em arquivos de sistema, arquivos de aplicação ou documentos pessoais, tornando-se parte deles.

  • Difíceis de erradicar: A varredura padrão de vírus exclui apenas o corpo principal do vírus, mas não consegue reparar arquivos infectados, causando problemas recorrentes.

  Nota

  Se o vírus não for deste tipo, use primeiro o recurso padrão de Varredura de Vírus.

• Antes de começar

  O Deep Cleanup pode causar risco de exclusão acidental de arquivos, interrupção de serviço e risco à integridade dos dados. Para evitar afetar os negócios normais, verifique os arquivos de origem antes do tratamento. Os pontos de verificação comuns incluem:

  • Verificar propriedades do arquivo: Confirme se o arquivo é um vírus checando o caminho, a assinatura e o hash (evite excluir arquivos de sistema ou de negócios).

  • Avaliação de dependência de negócios: Verifique se o arquivo é chamado por serviços críticos (como componentes relacionados ao nginx ou mysql).

• Como funciona

  • Limpa vírus resistentes encerrando processos virais maliciosos, colocando arquivos maliciosos em quarentena e removendo itens de residência persistente de vírus/trojans.

  • Além disso, você pode criar snapshots para fazer backup dos dados, permitindo restaurar os dados limpos por meio de snapshots durante a varredura profunda de vírus.

    Importante

    A criação e retenção de snapshots geram custos. As taxas são cobradas pelo produto de snapshot. O método de faturamento padrão é pagamento conforme o uso (pós-pago).Você pode entrar em contato com a consultoria de pré-vendas para obter informações sobre custos.

• Próximas etapas

  Revise regularmente a quarentena: Confirme as propriedades dos arquivos dentro de 30 dias para evitar exclusão irreversível. Para visualizar arquivos em quarentena, consulte Visualizar e recuperar arquivos em quarentena.

Quarantine

• Casos de uso

  Quando um arquivo é confirmado como backdoor, vírus ou outro arquivo malicioso, bloqueie imediatamente sua execução.

• Como funciona

  • O sistema move arquivos suspeitos para quarentena. Após a quarentena, o arquivo não pode ser executado, acessado ou propagado.

    Aviso

    Se o arquivo em quarentena for um arquivo de negócios infectado com código malicioso (como um componente central de aplicação), a quarentena pode causar interrupção do serviço.

  • Arquivos em quarentena podem ser restaurados dentro de 30 dias. Arquivos restaurados reaparecem na lista de alertas e o Security Center continua a monitorá-los. Para restauração, consulte Visualizar e recuperar arquivos em quarentena.

    Nota

    Arquivos não restaurados dentro de 30 dias são excluídos automaticamente e não podem ser recuperados.

• Próximas etapas

  Revise regularmente a quarentena: Confirme as propriedades dos arquivos dentro de 30 dias para evitar exclusão irreversível. Para visualizar arquivos em quarentena, consulte Visualizar e recuperar arquivos em quarentena.

Terminate Process

• Casos de uso

  Utilizado principalmente para tratar alertas de tipos de comportamento anormal de processo, como MySQL executando comandos anormais ou ataques de exploração web causando execução anormal de comandos.

• Como funciona

  O Security Center tentará encerrar o processo. Se falhar, tente encerrar manualmente o processo usando kill process ID e selecione o método de tratamento "Manually Handled".

  Nota

  O ID do processo pode ser visualizado na página de detalhes do alerta, em Mais Informações.

Block

• Casos de uso

  Indicado principalmente para cenários de ataque de IP, como logon incomum e ataques de força bruta.

• Como funciona

  • Ao executar a operação Block, o Security Center cria automaticamente regras de defesa de grupo de segurança correspondentes para bloquear o acesso de IPs maliciosos aos ativos afetados.

    • Clique em Show Details para visualizar as informações básicas da regra de defesa gerada. Por exemplo: Assets, Rule Direction, Port Range, Rule Direction.

    • O Security Center seleciona automaticamente o mecanismo de bloqueio com base na instalação do cliente. Mecanismos de bloqueio suportados:

      • Security Center: Prioriza o uso do plugin do Security Center para bloquear comportamentos de logon. Quando a instância do Security Center for das edições Advanced, Enterprise ou Ultimate e a chave Malicious Network Behavior Prevention estiver ativada, o Security Center selecionará automaticamente este plugin. Ative a chave Malicious Network Behavior Prevention. Para a operação específica da chave, consulte Defesa proativa.

      • ECS Security Group: Quando a regra de bloqueio é ativada, a regra de grupo de segurança correspondente é criada automaticamente. A regra é excluída automaticamente quando a regra de bloqueio expira ou é desativada.

        Nota

        Quando uma instância ECS é usada como servidor backend de um CLB (Classic Load Balancer), o tráfego encaminhado pelo CLB ignora as regras ACL do grupo de segurança da instância ECS backend. O grupo de segurança não consegue interceptar o IP original do cliente. Neste cenário, a ação de bloqueio do grupo de segurança não entra em vigor. Recomendamos configurar uma lista de bloqueios de controle de acesso no listener do CLB para bloquear IPs maliciosos. Acesse o console do CLB, selecione a instância alvo em Instance Management, vá para Listener Management, selecione o listener alvo, acesse a página Access Control, defina o controle de acesso como Blacklist e adicione os IPs maliciosos a serem bloqueados.

  • Rule Validity Period, que é a duração efetiva da regra de bloqueio. Padrão: 6 horas. Opções: 30 minutos, 1 hora, 2 horas, 6 horas, 12 horas, 1 dia, 7 dias, 14 dias, 30 dias.

  • As regras de bloqueio geradas podem ser visualizadas em Protection Configuration > Host Protection > Host-specific Rule Management, na aba Defense Against Brute-force Attacks, em System rules.

    Nota

    Para encerrar a política de bloqueio antecipadamente, desative a chave em System Rules.

  Supressão de alertas

  O Security Center utiliza principalmente os métodos Add to Whitelist e Ignore para implementar a supressão de alertas. Também suporta opções específicas para determinados alertas, como Do Not Intercept Rule, Protect Without Notification e Manually Handled.

  Após a atualização do mecanismo de detecção por modelo grande, ele pode reavaliar arquivos existentes no sistema, gerando novos alertas para arquivos que não haviam disparado alertas anteriormente. Este é um comportamento normal devido à melhoria na capacidade de detecção e não um falso positivo. Após confirmar que o arquivo é um arquivo de negócios normal, utilize a opção Add to Whitelist para evitar que alertas subsequentes sejam disparados para o mesmo arquivo. Em ambientes de cluster, como SLB, a detecção por IA é executada por instância. O mesmo arquivo pode disparar alertas em servidores diferentes. Confirme e adicione à lista de permissões em cada servidor individualmente.

  Diferenças entre Add to Whitelist e Ignore

  Diferenças	Add to Whitelist	Ignore
  Cenários	Problemas de exceção permanente	Aplicável a falsos positivos temporários ou ocasionais, ou problemas conhecidos.
  Escopo de impacto	Quando o mesmo ativo de host possui um arquivo com o mesmo MD5 e no mesmo caminho de arquivo deste alerta. Se outras regras de lista de permissões estiverem configuradas, alertas subsequentes que corresponderem às regras também não gerarão notificações.	Trata apenas o alerta atual, sem impacto em alertas subsequentes.

  Add to Whitelist

  Aviso

  Após adicionar à lista de permissões, os mesmos alertas e alertas correspondentes à regra da lista de permissões deixarão de ser notificados. Escolha com cuidado.

  • Casos de uso

    O alerta atual é um falso positivo ou requer uma regra de exceção permanente. Por exemplo, se um processo suspeito enviando pacotes TCP de saída for, na verdade, uma interação normal de negócios, ou se um comportamento suspeito de varredura for uma detecção de rede normal, defina uma regra de lista de permissões para evitar tais falsos positivos.

  • Descrição do resultado do tratamento

    • Para o alerta atual

      • Este alerta muda para Tratado. O status do alerta torna-se Manually Allowlisted.

      • Quando o mesmo alerta ocorrer novamente, nenhum novo dado de alerta será gerado, mas o horário da ocorrência mais recente deste alerta será atualizado.

        O que são alertas idênticos?

        Alertas idênticos referem-se a ameaças de segurança com características de alerta altamente consistentes. Por exemplo:

        • Alertas de vírus: mesmo ativo + mesmo caminho de arquivo de vírus + mesmo MD5 do arquivo de vírus.

        • Logon incomum: mesmo ativo + mesmo IP de logon.

    • Para alertas subsequentes

      Se uma regra específica de lista de permissões estiver configurada, quando um alerta correspondente ocorrer novamente, o alerta será adicionado automaticamente à lista de Tratados com o status Automatically Add to Whitelist e nenhuma notificação de alerta adicional será enviada.

  • Definir regras específicas de lista de permissões (opcional)

    Na caixa de diálogo de tratamento de alertas, clique na aba Add to Whitelist. Clique em Create Rule para adicionar uma regra. Clique em para excluir uma regra.

    Importante

    • Quando várias regras são configuradas, elas têm uma relação OU. Se qualquer regra for correspondida, a lista de permissões será aplicada.

    • Garanta precisão ao configurar regras para evitar um escopo excessivamente amplo. Por exemplo, "Path contains: /data/" pode acidentalmente adicionar subdiretórios sensíveis à lista de permissões.

    Cada regra possui 4 caixas de configuração da esquerda para a direita. Descrição:

    1. Campos de informação do alerta: Na página de detalhes, consulte More Information para visualizar quais campos de informação de alerta são suportados para o alerta atual.

    2. Tipo de condição: Suporta correspondência regex, maior que, igual a, menor que, contém e outras operações. Algumas descrições de regras:

       • Expressão regular: Expressões regulares podem corresponder precisamente a padrões específicos. Por exemplo, para adicionar todo o conteúdo sob a pasta "/data/app/logs/" à lista de permissões, defina a regra "Path matches regex: ^/data/app/logs/.*$".

       • Contém palavra-chave: Defina a regra "Path contains: D:\programs\test\". Todos os eventos com este caminho serão adicionados à lista de permissões.

    3. Valor da condição: Suporta constantes e expressões regulares.

    4. Ativos aplicáveis:

       • Todos os ativos: Entra em vigor para novos ativos e todos os ativos conectados.

       • Current Asset: Efetivo apenas para os ativos envolvidos no alerta atual.

  • Cancelar lista de permissões

    Nota

    Regras de lista de permissões para alertas de defesa de precisão precisam ser configuradas na página Protection Configuration > Host Protection > Rule Management, na aba Malicious Behavior Defense Custom Defense Rule.

    • Cancelar regra automática de lista de permissões

      1. Faça logon no console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alerts.

         Nota

         Se você ativou o Agentic SOC, no painel de navegação à esquerda, escolha Agentic SOC > Detection and Response.

      2. Clique em CWPP no canto superior direito do Cloud Workload Coverage Alert Management. Selecione Alert Settings.

      3. Na página Alert Settings, na área Alert Handling Rule, selecione o método de tratamento Automatically Add to Whitelist.

      4. Localize a regra alvo e clique em Excluir na coluna Ações para cancelar a regra automática de lista de permissões.

    • Cancelar lista de permissões de alerta

      1. Faça logon no console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alerts.

         Nota

         Se você ativou o Agentic SOC, no painel de navegação à esquerda, escolha Agentic SOC > Alerts.

      2. Na aba CWPP, defina a condição de filtro Handled or Not como Handled.

      3. Localize o alerta para remover da lista de permissões e clique no botão Remove from Whitelist na coluna Ações para cancelar a lista de permissões do alerta atual. Você também pode selecionar vários alertas e clicar no botão Remove from Whitelist na parte inferior da lista para cancelar a lista de permissões em lote.

  Ignore

  Importante

  • "Ignore" é apenas uma operação de gerenciamento de status de alerta. Ela não resolve o problema de segurança subjacente.

  • Use esta opção somente após confirmar totalmente que se trata de um falso positivo ou de um risco conhecido/aceito, para evitar mascarar ataques reais.

  • Recomendamos revisar regularmente (semanal ou mensalmente) a lista de alertas Ignorados.

  • Casos de uso

    • Confirmado como falso positivo ou baixa prioridade.

    • Problemas temporários/conhecidos: O problema existe, mas é um risco conhecido e aceito, ou um estado temporário não malicioso (por exemplo, teste de penetração autorizado ou comportamento anormal durante uma janela de manutenção). A causa raiz não pode ser corrigida imediatamente, mas a lista de alertas precisa ser limpa.

    • Ambiente de teste ou depuração: Em ambientes de não produção (como ambientes de desenvolvimento e teste), alertas esperados que não afetam a segurança podem interferir no monitoramento normal. Suprima-os temporariamente.

  • Descrição do resultado do tratamento

    • Para o alerta atual: Este alerta muda para Tratado. O status do alerta torna-se Ignored.

    • Para alertas subsequentes: Sem impacto. Quando alertas do mesmo tipo aparecerem novamente, o Security Center o alertará novamente.

  • Cancelar ignorar

    1. Faça logon no console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alerts.

       Nota

       Se você ativou o Agentic SOC, no painel de navegação à esquerda, escolha Agentic SOC > Alerts.

    2. Na aba CWPP, defina a condição de filtro Handled or Not como Handled.

    3. Localize o alerta para cancelar a ação de ignorar e clique no botão Cancel Ignore na coluna Ações para cancelar o status de ignorado do alerta atual.

       Nota

       Você também pode selecionar vários alertas e clicar no botão Cancel Ignore na parte inferior da lista para cancelar a ação de ignorar em lote.

  Do Not Intercept Rule

  • Cenários

    Atualmente suporta tratamento apenas para alertas de Bloqueio adaptativo de comunicação WebShell gerados por regras em Protection Configuration > Host Protection > Host-specific Rule Management, dentro de Malicious Behavior Defense System Defense Rule.

  • Como funciona

    O sistema não bloqueia solicitações para o URI correspondente e nenhum alerta é gerado.

  Protect Without Notification

  Aviso

  Alertas idênticos subsequentes não serão notificados separadamente. Escolha com cuidado.

  • Cenários

    Para alertas gerados por regras (tipo de alerta: defesa de precisão) em Protection Configuration > Host Protection > Host-specific Rule Management, dentro de Malicious Behavior Defense.

  • Como funciona

    • Alerta atual: Este alerta muda para Tratado.

    • Alertas subsequentes: Quando a mesma regra de defesa for atingida novamente, o alerta gerado será adicionado automaticamente à lista de Tratados e nenhuma notificação de alerta será enviada.

  • Cancelar regra de proteção sem notificação

    1. Faça logon no console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alerts.

       Nota

       Se você ativou o Agentic SOC, no painel de navegação à esquerda, escolha Agentic SOC > Alerts.

    2. Clique em CWPP no canto superior direito do Cloud Workload Coverage Alert Management. Selecione Alert Settings.

    3. Na página Alert Settings, na área Alert Handling Rule, selecione o método de tratamento Protect Without Notification.

    4. Localize a regra alvo e clique em Excluir na coluna Ações para cancelar a regra automática de lista de permissões.

  Manually Handled

  Se você já tratou este alerta manualmente, selecione Manually Handled. O status do alerta atual será atualizado para Manually Handled.

  Troubleshooting

  Cenários

  Suporta apenas o tratamento de alertas de anomalia de agente do Security Center offline.

  Como funciona

  O programa de diagnóstico do cliente do Security Center coleta dados de rede, processos e logs relacionados ao cliente na máquina local e os reporta ao Security Center para análise.

  Importante

  A verificação consome alguns recursos de CPU e memória. Avalie antes de usar.

  • Selecione o modo de problema:

    • Standard Mode: Coleta dados de logs relacionados ao cliente e reporta ao Security Center para análise.

    • Enhancement Mode: Coleta dados de rede, processos e logs relacionados ao cliente e reporta ao Security Center para análise.

  • Clique em Handle Now para gerar uma tarefa de diagnóstico. Você pode acessar Asset Center > Host e, no canto superior direito da página, clicar em Agent Task Management para visualizar os resultados e o progresso da tarefa de diagnóstico. Para mais informações, consulte Solução de problemas do cliente.

    Nota

    • Se a coluna Result fornecer soluções, trate o alerta de acordo com as soluções fornecidas.

    • Se a coluna Result não fornecer uma solução, clique em Actions na coluna Download Diagnostic Logs. Forneça os logs de diagnóstico exportados e o AliUid ao pessoal relevante para verificação e análise adicionais.

  Tratamento via console

  1. Faça logon no console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alerts.

     Nota

     Se você ativou o Agentic SOC, no painel de navegação à esquerda, escolha Agentic SOC > Alerts.

  2. Na página Alert, aba CWPP, localize o alerta alvo e clique em Handle na coluna Ações. Selecione o método de tratamento para o alerta e clique em Handle Now.

     Nota

     • Diferentes tipos de alerta suportam diferentes métodos de tratamento. Consulte a página do console para detalhes.

     • Preencha observações conforme necessário, incluindo o motivo do tratamento do alerta e o operador, para facilitar o gerenciamento dos alertas tratados.

  Verificação pós-tratamento

  • Confirme que o alerta foi tratado: Na página Alertas, defina o filtro Status como Handled para confirmar que o alerta alvo aparece na lista de Tratados. Na coluna Handling status, visualize o nome do método de tratamento (como Virus Scan, Ignored, Manually Handled, etc.) e confirme se o alerta foi tratado conforme esperado.

  • Execute uma varredura completa do disco: Após tratar os alertas, recomendamos executar uma varredura completa do disco no servidor para confirmar que não há novos alertas. A varredura completa do disco requer detecção sem agente (pagamento conforme o uso). Consulte a documentação de varredura de vírus.

  • Confirme a ausência de novos alertas: Após o tratamento, monitore a lista de alertas. Se os alertas persistirem, podem existir backdoors persistentes. Consulte a solução de problemas de alertas recorrentes abaixo.

  Procedimento

  1. AtiveAI-Powered Alert Triage

     Acesse a página Alert, na aba CWPP, e ative a chave AI-Powered Alert Triage no canto superior direito da lista de alertas.

  2. Visualize os resultados da análise de IA

     Após ativar esse recurso, o sistema realiza automaticamente uma análise aprofundada dos novos alertas diariamente. Na coluna AI Analysis da lista de alertas, visualize o resultado da análise de cada alerta:

     • Chinese Mainland: Alta confiança de que se trata de uma ameaça real. Recomendamos priorizar o tratamento.

     • Outside Chinese Mainland: Provável falso positivo. É possível reduzir a prioridade de tratamento.

     • Indeterminate (Desconhecido): A IA não conseguiu determinar o resultado temporariamente devido à falta de informações.

     Na parte inferior da lista de alertas, selecione os registros desejados e clique em AI automatic handling para realizar o tratamento em lote.

  3. Execute o tratamento automático por IA

     1. Acesse a páginaAI-Powered Remediation

        Na página Alerts, defina o filtro AI Analysis Result como All ou filtre conforme necessário. Selecione os alertas para tratamento automático por IA e clique no botão AI Auto-remediate na parte inferior da lista.

        Nota

        Você também pode passar o ponteiro do mouse sobre a área da chave AI-Powered Alert Triage e clicar em Handle Now na janela pop-up.

     2. Avalie e confirme o plano de tratamento

        1. Na página AI-Powered Remediation, visualize os alertas pendentes de tratamento, a Entity associada (como arquivos maliciosos, processos anômalos e IPs de risco) e o Handling plan recomendado.

        2. Avalie cuidadosamente a viabilidade do plano de tratamento. Após confirmar, clique em Confirm.

  4. Visualize os resultados do tratamento

     1. Após o tratamento, retorne à página Alerts e defina o filtro Handled or Not como Handled.

     2. Para alertas tratados automaticamente pela IA, o status será exibido como AI Response.

  Cotas e limitações

  • Escopo de aplicação: Aplica-se apenas aos novos alertas gerados após a ativação para análise e tratamento. Alertas históricos não são processados.

  • Limite diário de análises:

    • Cada host pode ter até 20 alertas submetidos à análise de IA.

    • Quando múltiplos alertas são acionados simultaneamente para análise, o sistema os ordena pelo horário de geração.

  • Limitações do escopo de tratamento automático por IA:

    O recurso de tratamento automático por IA aplica-se somente a alertas que atendem simultaneamente às seguintes condições:

    • Classificados pela IA como Confirmed Attack;

    • O alerta contém entidades acionáveis claras (como arquivos, processos e IPs).

  Resposta a emergências

  Operações comuns

  • Altere a senha: Ao receber um alerta de logon incomum, caso a operação não tenha sido realizada por você, altere imediatamente a senha da instância ECS. Utilize o recurso Reset Instance Password no console ECS. Em casos de intrusão por senha fraca de SSH, altere imediatamente a senha do root para uma combinação complexa de letras maiúsculas, minúsculas, dígitos e caracteres especiais. Ative o logon baseado em chave SSH e desative o logon por senha para evitar ataques de força bruta.

  • Bloqueie o IP de origem do atacante: Confirme que os processos maliciosos foram encerrados e bloqueie o IP de origem do atacante no grupo de segurança. Configure o grupo de segurança da Alibaba Cloud para negar todo o acesso a portas provenientes dos IPs relacionados, bloqueando imediatamente o logon remoto.

  • Investigue backdoors persistentes: Verifique o crontab, itens de inicialização, chaves públicas SSH (~/.ssh/authorized_keys) e outros arquivos em busca de entradas suspeitas para garantir que nenhum backdoor persistente tenha sido deixado pelos atacantes.

  Investigação de logs locais

  Além do recurso de rastreamento de ataques do Security Center, você pode verificar manualmente os logs do sistema do servidor para investigar os caminhos de intrusão:

  • Servidor Linux: Verifique os arquivos /var/log/secure ou /var/log/auth.log para confirmar registros de logon incomuns e origens de ataque.

  • Servidor Windows: Utilize o Visualizador de Eventos para verificar os logs de segurança, focando nos eventos de sucesso ou falha de logon.

  • Servidor Linux: Consulte os arquivos /var/log/messages ou entradas relacionadas a DNS nos logs do systemd para investigar requisições DNS anômalas.

  • Servidor Windows: Acesse Event Viewer > DNS Server para verificar os registros de consulta DNS e investigar requisições DNS anômalas.

  Tratamento de execução de comandos após vazamento de AccessKey

  Receber o alerta RAM sub-account AccessKey attempted denied operation indica que a AccessKey está tentando chamar uma API não autorizada. Por exemplo, uma falha ao chamar Ecs:DescribeInstances. Esse alerta é um sinal claro de que a AccessKey pode ter vazado ou estar sendo usada indevidamente. Trate-o imediatamente. Se houver suspeita de que o atacante executou comandos na instância ECS afetada por meio do Cloud Assistant, siga estas etapas para investigar e limpar o ambiente:

  Nota

  Caso ainda não tenha confirmado se a AccessKey vazou, utilize o recurso Detect AccessKey leaks para visualizar os resultados da detecção de vazamentos.

  1. Ajuste a autorização e a AccessKey

     1. Desative imediatamente a AccessKey do usuário RAM relevante para bloquear chamadas não autorizadas subsequentes.

     2. Verifique se a política de permissões do usuário RAM possui autorizações excessivas.

     3. No ActionTrail, pesquise pelo ID da AccessKey para consultar o histórico de chamadas de API e avaliar os serviços cloud afetados, as operações realizadas e o escopo do impacto.

  2. Investigue e limpe o servidor:

     1. Confirme a execução de comandos:

        1. Faça logon no console ActionTrail. Na página de consulta de eventos, filtre por Cloud service name selecionando ECS, ou utilize a Advanced query buscando por Event name com InvokeCommand.

        2. Clique no evento alvo e selecione View details. No registro de evento JSON retornado, obtenha em requestParameters o campo CommandContent (codificado em BASE64; decodifique para visualizar o conteúdo real do comando) e o InstanceId (que identifica a instância ECS afetada).

     2. Faça logon no servidor para investigação: Com base nas informações obtidas na etapa anterior, utilize o InstanceId para acessar a instância ECS correspondente e realize as seguintes verificações:

        • Execute ps aux para verificar a existência de processos anômalos.

        • Execute crontab -l para verificar tarefas agendadas suspeitas.

        • Execute cat /root/.ssh/authorized_keys para verificar se chaves públicas de backdoor SSH foram inseridas.

     3. Limpe resíduos e reforce a segurança: Remova os processos e arquivos maliciosos encontrados na etapa anterior, exclua tarefas agendadas anômalas e chaves públicas de backdoor. Substitua a AccessKey comprometida e reinicie o servidor para concluir o reforço de segurança.

  Tutoriais comuns de tratamento de alertas de vírus

  • Melhores práticas para tratar programas de criptomineração

  • Detectar e remover trojans no Linux

  • Defender-se contra ataques de trojans

  Reforço de segurança e prevenção de ataques

  • Atualize a edição do Security Center: As edições Enterprise e Ultimate oferecem quarentena automática de vírus, proporcionando capacidades de defesa precisa e suporte a mais itens de detecção de segurança.

  • Restrinja o controle de acesso: Abra apenas as portas de negócio necessárias (como 80 e 443). Configure políticas rigorosas de lista de permissões de IP para portas de gerenciamento (como 22 e 3389) e portas de banco de dados (como 3306).

    Nota

    Para servidores ECS da Alibaba Cloud, consulte Manage security groups para realizar a operação.

  • Realize verificações de baseline: No painel de navegação à esquerda, escolha Risk governance > Cloud security posture management. Na aba System baseline risks, visualize e trate os itens de risco de baseline.

  • Ative a análise de logs: No painel de navegação à esquerda, escolha Risk governance > Log analysis. Após a ativação, os logs de segurança serão retidos e poderão ser pesquisados.

  • Ative o backup anti-ransomware: No painel de navegação à esquerda, escolha Protection configuration > Anti-ransomware. Crie e ative políticas de backup anti-ransomware para servidores críticos.

  • Ative o Security AI Assistant: Na parte superior da página Overview, abra o Security AI Assistant para obter conclusões de análise de IA e sugestões de tratamento para o alerta.

  • Defina senhas complexas para servidores: Configure senhas complexas contendo letras maiúsculas, minúsculas, dígitos e caracteres especiais para servidores e aplicações.

  • Atualize softwares: Mantenha as aplicações atualizadas para a versão oficial mais recente. Evite utilizar versões sem suporte ou versões antigas com vulnerabilidades de segurança conhecidas.

  • Faça backups regulares: Crie políticas de snapshot periódicas para dados importantes e discos de sistema dos servidores.

    Nota

    Para servidores ECS da Alibaba Cloud, consulte Create policy para realizar a operação.

  • Corrija vulnerabilidades prontamente: Utilize regularmente o recurso Vulnerability repair do Security Center para corrigir rapidamente vulnerabilidades de alto risco do sistema e de aplicações.

  • Redefina o SO do servidor (escolha com cautela).

    Se o vírus infiltrou-se profundamente no sistema e está associado a componentes subjacentes do SO, recomendamos fortemente redefinir o sistema operacional do servidor após fazer backup dos dados importantes. Procedimento:

    1. Crie snapshots para fazer backup dos dados importantes no servidor. Para mais informações, consulte Manually create a single snapshot.

    2. Inicialize o SO do servidor. Para mais informações, consulte Re-initialize system disk (reset OS).

    3. Utilize o snapshot para criar um disco cloud. Para mais informações, consulte Create a data disk from a snapshot.

    4. Anexe o disco cloud ao servidor após a reinstalação do SO. Para mais informações, consulte Attach a data disk.

  Perguntas frequentes

  Perguntas frequentes sobre tratamento de alertas

  • O que fazer se o tratamento falhar ou os alertas retornarem?

    1. Caso o tratamento falhe ou o mesmo alerta retorne após a limpeza, siga esta ordem de solução de problemas:

       Sintoma	Causas comuns	Método de tratamento
       Falha na quarentena/encerramento do processo	O agente do servidor está offline ou a versão é muito antiga. Os comandos de tratamento não podem ser entregues.	Em Assets, confirme se o cliente está online. Consulte Solução de problemas de agente offline. Tente novamente após a restauração.
       Falha na quarentena	O processo malicioso ainda está em execução e ocupando o arquivo, ou o arquivo foi excluído.	Primeiro encerre os processos maliciosos (por exemplo, usando o comando kill) e depois coloque o arquivo em quarentena. Marque diretamente o alerta como Tratado quando o arquivo não existir.
       Alertas recorrentes (comum em worms e mineração)	Apenas subprocessos ou arquivos de vírus foram limpos. Mecanismos de persistência, como processo pai, tarefas agendadas e itens de inicialização, não foram removidos.	Utilize a árvore de processos nos detalhes do alerta para localizar o processo pai. Verifique e limpe tarefas agendadas do crontab, itens de inicialização, chaves públicas SSH e contas desconhecidas. Consulte Melhores práticas para tratar programas de mineração.
       Alertas recorrentes conforme agendamento (como em um horário fixo toda semana)	Existem tarefas agendadas de download remoto ou outros hosts comprometidos no mesmo segmento de rede estão causando infecções laterais repetidamente.	Verifique as tarefas agendadas em todos os servidores. Execute verificações de vírus em outros hosts na mesma VPC.
       Botão de tratamento indisponível	A edição gratuita ou a autorização expirada não suporta operações de tratamento.	Faça a Compra do Security Center com uma edição de proteção superior ou realize a Autorização de vinculação de ativos.
       Outros	Senha fraca: Senhas de SSH/RDP/banco de dados são muito simples. Vulnerabilidade não corrigida: Aplicações como Redis, XXL-JOB e WebLogic possuem vulnerabilidades de alto risco. Backdoor oculto: A limpeza inicial foi incompleta, deixando backdoors escondidos. Contaminação de dados: Restauração de backup/snapshot infectado por vírus.	Altere a senha e prontamente faça a Correção de vulnerabilidades. Utilize a Detecção e remoção de vírus para executar uma verificação completa de vírus no servidor.

    2. Se os alertas persistirem após as etapas acima, podem existir backdoors não detectados. Recomendamos fazer o Backup dos dados antes de Redefinir o SO do servidor.

       Aviso

       Esta operação apresenta risco de perda de dados. Faça backup dos dados primeiro. Avalie cuidadosamente o escopo de impacto antes de prosseguir.

       1. Crie snapshots para fazer backup de dados importantes no servidor. Para mais informações, consulte Criar manualmente um único snapshot.

       2. Inicialize o SO do servidor. Para mais informações, consulte Reinicializar disco do sistema (redefinir SO).

       3. Use o snapshot para criar um disco cloud. Para mais informações, consulte Criar um disco de dados a partir de um snapshot.

       4. Anexe o disco cloud ao servidor após a reinstalação do SO. Para mais informações, consulte Anexar um disco de dados.

  • O que fazer se uma aplicação web gerar um alerta de subprocesso anormal?

    Esses alertas geralmente são acionados quando o SQL Server habilita o xp_cmdshell, ocorrem chamadas suspeitas de procedimentos armazenados para invocar comandos do sistema ou há disparos de exploits web. Verifique a linha de comando e o processo pai nos detalhes do alerta em busca de arquivos anormais, como C:\Users\Public\tmp_out.txt. Em seguida, desative recursos de banco de dados de alto risco e verifique tarefas agendadas e itens de inicialização automática para remover elementos que possam continuar a acionar subprocessos anormais.

  • Alerta de execução de comando sensível (como cat /etc/ssh/sshd_config)?

    O comando cat /etc/ssh/sshd_config serve para visualizar informações de configuração SSH e pode acionar alertas no modo estrito. Confirme se esta é uma operação de O&M esperada. Caso contrário, trate-a como um risco de segurança e investigue os processos relacionados e as origens da operação.

  • O que fazer se for gerado um alerta de suspeita de varredura/ataque externo via logon?

    Este alerta indica que o servidor pode estar comprometido e sendo usado para ataques externos. Encerre processos maliciosos, coloque arquivos relacionados em quarentena, execute uma verificação completa de vírus no disco, verifique logs do sistema para investigar o caminho da intrusão e reforce as regras de grupo de segurança e políticas de senha.

  • O que fazer se for gerado um alerta de desativação do service de proteção de segurança do host cloud?

    Este alerta indica que invasores podem estar tentando desativar processos de proteção, como o AliSecCheck. Execute uma verificação de vírus, coloque arquivos infectados em quarentena e encerre processos anormais. Depois, investigue vestígios de intrusão e mecanismos de persistência no servidor.

  • Não é possível excluir arquivos de vírus (trojans, programas de mineração)?

    O arquivo e seu diretório pai possuem atributos ocultos. Use o comando chattr -i para remover o atributo imutável do arquivo e do diretório pai antes de excluir.

  • O servidor tem um alerta de trojan DDoS e o arquivo foi excluído manualmente, mas o alerta persiste?

    Os arquivos não foram completamente excluídos. Solução:

    1. Quando o Security Center estiver na edição gratuita, você pode ativar o Teste gratuito de dias da Enterprise ou Ultimate Edition. Ou consulte a Compra do Security Center. Atualize o Security Center para a Anti-Virus Edition ou Enterprise Edition.

    2. Após a ativação, acesse a página de tratamento de alertas, localize o trojan DDoS, clique em Handle e selecione Virus Scan. O sistema encerra o processo do trojan e coloca o arquivo em quarentena. Para mais informações, consulte Detecção e Remoção de Vírus.

  • Como adicionar alertas de defesa precisa à lista de permissões?

    Os alertas gerados pela defesa precisa dependem de plugins de defesa. O bloqueio é aplicado automaticamente após a geração desses alertas. Adicione manualmente à lista de permissões no Gerenciamento de Regras do Host. Procedimento:

    1. Acesse o Console do Security Center - Protection Settings - Host Protection - Host Rule Management. No canto superior esquerdo da página, selecione a região dos seus ativos: Chinese Mainland ou Outside Chinese Mainland.

    2. Na aba Malicious Behavior Defense, subaba Custom Defense Rule, clique em Create Rule. Tipos de lista de permissões suportados:

       • Hash do processo

       • Linha de comando

       • Rede do processo

       • Interceptação de rede (IP/domínio de origem)

         É possível configurar regras de lista de bloqueios ou lista de permissões para endereços IP de origem ou domínios. Quando um alerta de segurança indicar um reverse shell ou conexão de saída maliciosa persistente, você pode bloquear IPs de ataque específicos criando regras personalizadas de interceptação de rede. IPs ou domínios maliciosos fornecidos pelo suporte ou equipes de segurança também podem ser adicionados à lista de bloqueios para interceptação.

         Por exemplo, após tratar um alerta de reverse shell ou de conexão de saída maliciosa persistente, se o IP de origem do atacante tiver sido confirmado e o processo malicioso encerrado, você pode bloquear o IP executando as seguintes etapas:

         1. Na página Malicious Behavior Defense, clique na aba Custom Defense Rule e, em seguida, clique em Create Rule.

         2. Selecione Network Interception como tipo de regra, adicione o IP de origem do atacante confirmado ou domínio malicioso à lista de bloqueios, defina a ação como Block e selecione os servidores onde a regra terá efeito.

         Recomendamos também configurar regras de grupo de segurança para proteção: crie uma regra de negação de grupo de segurança para a instância de destino no console ECS e adicione o IP malicioso confirmado tanto às listas de negação de entrada quanto de saída para bloquear imediatamente o tráfego malicioso. Para mais informações, consulte a documentação de configuração de regras de grupo de segurança na documentação do ECS.

       • Leitura/Escrita de arquivo

       • Operação de registro

       • Carregar biblioteca de vínculo dinâmico

       • Renomear arquivo

  • O que fazer se apenas as opções Whitelist e Ignore estiverem disponíveis para tratamento de alertas?

    Alguns alertas podem ter apenas as opções Whitelist e Ignore, sem as opções Terminate Process ou Virus Scan. Isso geralmente significa que o processo não está mais em execução ou que o arquivo foi excluído. Sugestões:

    • Se você confirmar que a ameaça foi removida (processo encerrado, arquivos excluídos), selecione Ignore ou Manually Handled para fechar o alerta.

    • Caso ainda precise encerrar o processo, selecione Terminate Process primeiro e atualize a página para visualizar as opções de tratamento.

    • Para vírus persistentes ou alertas recorrentes, siga a seção de Reforço de segurança e prevenção de ataques acima para um tratamento completo.

  • Um alerta de webshell pertence a operações automáticas do sistema?

    Ataques de webshell geralmente são comportamentos de intrusão externa. Invasores exploram vulnerabilidades para carregar webshells ou escrever backdoors através de falhas de execução de código. Isso não é uma operação automática do sistema. Trate como uma intrusão: combine os Detalhes do alerta e logs locais do servidor para investigar a entrada da intrusão. Remova arquivos maliciosos e processos anormais, e conclua a correção de vulnerabilidades, controle de acesso e reforço de segurança de contas.

  • O que fazer se eu receber uma notificação de comportamento malicioso suspeito em um servidor (varredura de porta SSH em larga escala ou ataques externos)?

    • O servidor foi desligado: Se o servidor não estiver mais em uso, você pode ignorar esta notificação inicialmente.

    • Continuar usando: Reinstale o SO para remover completamente o vírus. No console ECS, localize a instância e escolha All Operations > Initialize Disk (deve estar parado). Após a reinstalação, reforce a segurança: configure uma senha forte, restrinja regras de grupo de segurança para permitir apenas IPs especificados para logon remoto e abra apenas as portas de negócios necessárias.

    • Sobre bloqueios: Se nenhum ataque externo for detectado após a reinstalação, banimentos da plataforma geralmente não são acionados. Se problemas de acesso persistirem após uma verificação limpa de vírus, verifique outras causas, como configurações de grupo de segurança e firewall do servidor.

  • Por que a porta SSH é exibida como 22 nos detalhes do alerta?

    Se o sshd_config não tiver o campo Port explicitamente configurado, o Security Center identifica o SSH como porta 22 por padrão. Mesmo que a porta real tenha sido alterada, os detalhes do alerta ainda podem mostrar a porta 22. Verifique a configuração real de SSH do servidor.

  • O que fazer se continuar recebendo alertas de ataque de força bruta SSH bem-sucedido após a correção?

    Verifique se a porta não padrão (como 5522) está configurada corretamente e em uso real. Se o alerta persistir após a verificação da configuração, faça backup dos dados necessários e redefina a instância.

  • Por que os alertas continuam após a exclusão de arquivos de vírus/maliciosos?

    O Security Center retém registros históricos de ameaças por cerca de um ano. Mesmo que arquivos de vírus sejam excluídos, se nenhuma operação de tratamento for realizada (como ignore ou whitelist), o sistema continua enviando notificações baseadas em registros históricos. Sugestões:

    • Após confirmar que a ameaça foi removida, execute Ignore ou Manually Handled nos alertas relacionados na lista de alertas.

    • Se o horário do alerta for anterior à operação de segurança, você pode ignorar o alerta após confirmar a segurança.

  • O que fazer se eu ainda receber alertas de logon incomuns para o IP antigo após alterar o IP público?

    Alertas de IP antigo após uma mudança de IP geralmente são acionados pelo Security Center com base no comportamento histórico de logon. Sugestões:

    • Se o horário do alerta for anterior à mudança de IP, você pode ignorar o alerta.

    • Sincronize as informações mais recentes de ativos no centro de ativos para garantir que o Security Center registre os endereços IP válidos atuais.

  • Não é possível encontrar usuários e senhas fracas específicas nos detalhes do alerta?

    Na coluna Actions da página Alerts, clique em Details para visualizar usuários e credenciais de senhas fracas. Se os detalhes não forem mostrados, o alerta pode ser histórico ou expirado. Altere as senhas das contas relevantes para senhas complexas contendo letras maiúsculas, minúsculas, dígitos e caracteres especiais.

  • Como autorizar engenheiros da Alibaba Cloud a investigar e tratar vírus?

    • Preencha as informações de autorização no ticket, forneça a senha do servidor e autorize os engenheiros da Alibaba Cloud para investigação remota in loco.

    • Pré-requisitos: Para operações de alto risco, crie um backup de snapshot antes de autorizar engenheiros para operações in loco. Operações sem snapshots não são permitidas. Engenheiros não podem criar snapshots para você. Conclua o backup de snapshot primeiro.

    • Se você não souber a senha do servidor, poderá redefinir a senha da instância no console ECS.

  • Por que o botão Handle está acinzentado ou não responde?

    Causas comuns:

    1. Atualmente usando a edição gratuita ou nenhuma autorização de proteção comprada: A edição gratuita suporta apenas a visualização de alguns alertas e não suporta operações de tratamento (quarentena, bloqueio, lista de permissões, etc.). Primeiro faça a Compra do Security Center Anti-Virus Edition ou superior, e garanta que o servidor afetado esteja vinculado à autorização.

    2. Instância expirada: Após a expiração de uma instância subscription, a capacidade de tratamento torna-se inválida. Renove e tente novamente.

    3. Permissões insuficientes de usuário RAM: A permissão AliyunYundunSASFullAccess é necessária. A permissão somente leitura (ReadOnlyAccess) não pode executar operações de tratamento.

    4. O agente do servidor para o alerta está offline: Comandos de tratamento não podem ser entregues. Primeiro consulte a Solução de problemas de agente offline para restaurar o status online do cliente.

  Problemas de recursos do console

  • O que fazer se o alerta mostrar que o arquivo não existe?

    Isso pode ocorrer porque o vírus foi removido por outros meios ou se limpou sozinho. Clique em Ignore ou Manually Handled na lista de alertas para limpar este alerta.

  • Recebi um alerta de segurança, mas não há dados relacionados no console?

    • Os dados de alerta do Security Center são exibidos por região. Você pode alternar regiões no canto superior esquerdo da página Alerts, entre as regiões Chinese Mainland e Outside Chinese Mainland. Se você receber uma notificação de alerta, mas ele não for exibido na página, mude para outra região usando o seletor de região na parte superior.

    • Verifique sua edição do Security Center: A edição gratuita possui recursos limitados. Recomendamos a Compra do Security Center. Atualize o Security Center para a Anti-Virus Edition ou Enterprise Edition.

    • Alguns alertas podem vir do monitoramento de tráfego da Alibaba Cloud, análise de inteligência de segurança ou outros products de segurança da Alibaba Cloud. Esses alertas podem não aparecer no console CWPP do Security Center.

  • Como tratar múltiplos alertas em lote?

    O Security Center atualmente suporta lista de permissões em lote, ignorar, cancelar lista de permissões e cancelar ignorar para tratar alertas de segurança.

    1. Faça login no Console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alert. Acesse a página Alerts e selecione os alertas para tratar em lote.

    2. Clique no botão Ignore This Time, Add to Whitelist, Remove from Whitelist ou Cancel Ignore na parte inferior esquerda.

  • Por que o botão de tratamento de alerta de segurança está acinzentado?

    • Verifique sua edição do Security Center. A edição gratuita não suporta o tratamento de alertas de segurança. Você pode Ativar um teste gratuito de 7 dias da Enterprise Edition ou ativar a Anti-Virus Edition ou Enterprise Edition. Para detalhes, consulte a Compra do Security Center.

    • Edições diferentes suportam tipos diferentes de alertas de segurança. Para mais informações, consulte Alertas de segurança CWPP.