Security Center:FAQ sobre Detecção e Resposta

Como determinar se um ativo está comprometido por mineração de criptomoedas?

Se o uso da CPU do servidor estiver significativamente alto (atingindo 80% ou mais) e processos desconhecidos enviarem pacotes de rede continuamente para fora, confirme a existência de uma ameaça de mineração de criptomoedas no servidor.

Quando um programa de mineração compromete um ativo protegido pelo Security Center, o sistema envia um alerta por SMS ou e-mail. Acesse a página Alert e selecione a aba CWPP para tratar o alerta de mineração. Se o programa de mineração estiver associado a outros eventos de alerta, como comunicação com pool de mineração ou acesso a domínio malicioso, trate esses alertas associados em conjunto. Para mais detalhes sobre como visualizar e tratar alertas associados, consulte Responder a alertas de segurança.

A interceptação de vírus não está ativada e meu servidor está sob ataque de mineração. O que devo fazer?

Siga estas etapas para tratar o alerta de mineração e ativar o recurso de Malicious Host Behavior Prevention.

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

2. No painel de navegação à esquerda, escolha Detection and Response > Alert. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado:Chinese Mainland ou Outside Chinese Mainland.

3. Na página Alert, acesse a aba CWPP, localize o alerta correspondente e clique em Actions na coluna Process.

4. Na caixa de diálogo Crypto-mining program - Malicious software, selecione Virus Detection and Removal.

5. Clique em Handle Now para concluir o tratamento do evento de alerta de mineração.

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

7. Na página System Settings, acesse a aba Settings e, em seguida, a subaba Host Protection Settings. Na seção Proactive Defense, ative a chave Malicious Host Behavior Prevention para habilitar o recurso de interceptação de vírus.

Adicionei acidentalmente um alerta de mineração à lista de permissões. Como removê-lo?

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

2. No painel de navegação à esquerda, escolha Detection and Response > Alert. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado:Chinese Mainland ou Outside Chinese Mainland.

3. Na página Alert, acesse a aba CWPP e altere a condição de filtro para Handled para visualizar todos os alertas tratados.

4. Localize o alerta correspondente e clique em Remove from Whitelist na coluna Actions para restaurar o alerta.

Como verifico se a interceptação automática de vírus está ativa?

Faça login no console do Security Center. Após ativar o recurso Malicious Host Behavior Prevention na página System Settings, no painel de navegação à esquerda, escolha Detection and Response > Alert. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado:Chinese Mainland ou Outside Chinese Mainland.na página Alert, acesse a aba CWPP e clique em Precise Defense. Se o status de defesa dos alertas filtrados for Blocked, a interceptação automática de vírus está ativa.

Como o Security Center detecta comportamentos de intrusão de hackers?

O Security Center identifica todos os comportamentos de intrusão por meio de varreduras. Engenheiros de segurança da Alibaba Cloud verificam esses comportamentos após analisar os dados de tráfego dos clientes.

Quais são os comportamentos comuns de intrusão de hackers?

Os itens de detecção de alertas do Security Center cobrem comportamentos comuns de intrusão, incluindo backdoors, ataques de força bruta e mineração de criptomoedas. Para mais informações, consulte Alertas de segurança do CWPP.

Por que o phpinfo gera um alerta? É um falso positivo?

Não, não é um falso positivo.

O phpinfo contém muitas informações sensíveis, como o caminho absoluto do site. Isso representa um alto risco e hackers podem explorá-lo. A maioria dos invasores faz upload do phpinfo como primeiro passo para coletar mais informações visando uma penetração mais profunda. Se você confirmar que este arquivo é legítimo e necessário para o seu negócio, execute as seguintes operações:

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

2. No painel de navegação à esquerda, escolha Detection and Response > Alert. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado:Chinese Mainland ou Outside Chinese Mainland.

3. Na página Alert, acesse a aba CWPP e selecione Add to Whitelist ao tratar o alerta.

O Security Center isola automaticamente arquivos WebShell?

Não. Como os arquivos WebShell podem conter informações relacionadas ao seu negócio, isole-os manualmente após avaliação. Os arquivos isolados ficam na pasta Quarentena e podem ser restaurados dentro de 30 dias. Para mais informações sobre a pasta Quarentena, consulte Responder a alertas de segurança.

Como o Security Center detecta WebShells?

O Security Center utiliza os seguintes métodos de varredura para detectar arquivos de script de sites, como PHP, ASP e JSP.

• Varredura de disco: quando um arquivo é carregado ou baixado no servidor e o sistema detecta um comportamento de gravação em disco, o arquivo é verificado. Se o sistema encontrar um arquivo malicioso, emitirá um alerta.

• Monitoramento em tempo real de diretórios web.

• Varredura agendada de diretórios web.

Alertas de segurança envolvendo arquivos comuns no meu servidor são falsos positivos?

Isso não é um falso positivo. Se a data de criação de um arquivo comum no seu servidor tiver sido modificada ou se o conteúdo do arquivo contiver instruções óbvias de backdoor, o Security Center também gerará um alerta correspondente. Investigue e trate o alerta com base na sua situação real.

Quais objetos podem ser adicionados à lista de permissões para alertas de segurança?

O recurso de tratamento de alertas de segurança permite adicionar objetos à lista de permissões para alertas do tipo software malicioso. A operação de lista de permissões aplica-se apenas à origem do acesso no evento de alerta atual. Os seguintes tipos de alerta oferecem suporte à adição à lista de permissões:

Por que alguns alertas são marcados como Expirados?

Se mais de 30 dias se passaram desde a última ocorrência de um alerta, o Security Center marca o status do alerta como Expired. Se o alerta for detectado novamente, o Security Center atualiza o horário da ocorrência para o momento da detecção mais recente e define o status do alerta como Unhandled.

Por que o horário da primeira ocorrência de um alerta de acesso a domínio suspeito difere do horário de detecção?

Ao receber dados de resolução DNS, o Security Center precisa usar algoritmos para analisar e processar essas informações. Os próprios dados de resolução DNS também possuem certo atraso. Portanto, o horário da primeira ocorrência de um alerta de acesso a domínio suspeito é posterior ao horário de detecção. Uma diferença de tempo de até 5 horas é considerada normal.

Como funciona o recurso de detecção e alerta de login incomum do Security Center?

Após instalar o agente do Security Center no servidor, o recurso de login incomum detecta comportamentos de login e gera alertas para acessos vindos de locais incomuns. No console do Security Center, acesse a página Alert e vá para a aba CWPP para visualizar alertas relacionados a logins incomuns no servidor.

O agente do Security Center coleta periodicamente logs de login do servidor e os envia para a nuvem para análise e correlação. Se o sistema detectar um evento de login bem-sucedido a partir de um local, IP, horário ou conta incomuns, disparará um alerta. O conteúdo a seguir descreve como diferentes comportamentos de login por IP são determinados:

• Quando o Security Center é aplicado pela primeira vez ao servidor, nenhum alerta é disparado durante esse período, pois nenhum local de login habitual foi configurado para o servidor.

• Quando um IP público faz login com sucesso no servidor pela primeira vez, o Security Center registra a localização desse IP como um local de login habitual e marca todos os locais de login públicos nas próximas 24 horas a partir desse ponto como habituais. Após 24 horas, qualquer comportamento de login proveniente de um local que não esteja na lista de locais habituais é considerado um login remoto e um alerta é gerado.

• Quando se determina que um IP apresentou comportamento de login remoto, apenas o primeiro login dispara um alerta por SMS. Se o mesmo IP fizer login com sucesso 6 vezes ou mais, o Security Center registra automaticamente a localização desse IP como um local de login habitual.

  Nota

  Alertas de login remoto aplicam-se apenas a IPs públicos.

A seguir, descrevemos a política de alertas para IPs de login incomuns:

• O Security Center envia um alerta por SMS para o primeiro comportamento de login vindo de um IP remoto. Se esse IP continuar fazendo login, os alertas serão gerados apenas no console até que o IP faça login 6 vezes e seja automaticamente registrado como um local de login habitual.

• Se você utilizar as edições Advanced, Enterprise ou Ultimate do Security Center, poderá configurar locais de login habituais, IPs de login habituais, horários de login habituais e contas de login habituais para seus servidores. Alertas são gerados para comportamentos de login fora dessas regras personalizadas. Suas regras personalizadas de login têm precedência sobre a determinação de login remoto.

Quais alertas de login incomum o Security Center suporta?

Os seguintes itens de detecção de alerta de login incomum são suportados:

• Login por IP malicioso (servidor, aplicativo FTP, MySQL, SQL Server, entre outros)

• Login por conta backdoor

• Login por conta com senha fraca

• Atividade suspeita de varredura de login de saída

• Login de local incomum

• Login de conta incomum

• Sucesso em ataque de força bruta no ECS (múltiplos usuários inválidos, RDP, SSH)

• Sequência anormal de comandos após login no ECS (SSH)

• Login no ECS em horário, local, conta ou IP incomuns

Para mais informações sobre os princípios de detecção dos itens de alerta mencionados acima, consulte Itens de detecção de alertas de segurança.

Como evitar alertas de login incomum ao fazer login normalmente no servidor?

Utilize o recurso Common Logon Management no console do Security CenterProtection Configuration > Host Protection > Host-specific Rule Management para configurar locais de login habituais, IPs de login, horários de login e contas. Isso permite gerar alertas para comportamentos de login excepcionais. O recurso suporta a adição manual e a atualização automática de locais de login habituais para alertar sobre comportamentos de login remoto em ativos específicos.

O que devo fazer se acionei acidentalmente um alerta de ataque de força bruta no ECS?

Se a senha do servidor tiver alta complexidade, você pode inserir a senha de login incorreta várias vezes antes de conseguir acessar. O modelo de prevenção de força bruta do Security Center identifica esse comportamento como um ataque de força bruta à senha do ECS e gera um alerta correspondente. Após confirmar que o alerta foi causado por uma operação equivocada, ignore-o. Para mais informações sobre como ignorar um alerta, consulte Responder a alertas de segurança.

Configurei um IP, horário e conta habituais, mas ainda recebo alertas de login incomum durante logins normais. O que devo fazer?

Nesse caso, determine primeiro se o tipo de alerta é login por IP não autorizado, login de local incomum ou login de conta incomum. O IP de login, o local de login, a conta e o horário são fatores que afetam os alertas de login. Não há prioridade entre eles. Um alerta é disparado desde que qualquer um desses fatores seja anormal.

Quando um alerta de login incomum é gerado, o login foi bem-sucedido ou bloqueado?

Um alerta de login incomum indica que o login foi bem-sucedido, mas o comportamento foi considerado suspeito pelo Security Center, resultando na geração de um evento de alerta de comportamento suspeito.

O que devo fazer se confirmar que um alerta de login incomum é de um hacker?

1. Faça login no console do Security Center.No painel de navegação à esquerda, escolha Detection and Response > Alert. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado:Chinese Mainland ou Outside Chinese Mainland.

2. Na página Alert, acesse a aba CWPP, localize o alerta e clique em Handle na coluna Actions. Selecione Block for 12 hours e clique em Handle Now para bloquear imediatamente a intrusão do hacker. Recomendamos alterar sua senha imediatamente e verificar o servidor em busca de outras contas e chaves públicas desconhecidas para impedir logins SSH sem senha.

Quando um alerta de "Sequência anormal de comandos após login no ECS (SSH)" é gerado, o comando já foi executado?

Sim, o comando já foi executado. Atualize prontamente a senha de login do servidor e verifique se há outros comportamentos incomuns, como processos desconhecidos em execução.

Quais logs devo verificar no servidor quando ocorre um alerta de login incomum?

Verifique as informações no diretório /var/log/secure do servidor. Por exemplo, execute o comando grep 10.80.22.22 /var/log/secure.

Como visualizo o número de ataques de força bruta ou o status de interceptação no meu servidor?

Faça login no console do Security Center.No painel de navegação à esquerda, escolha Detection and Response > Alert Na seção Network Defense Alert, visualize informações sobre ataques de força bruta SSH interceptados com sucesso.

Como evito ataques de força bruta no meu servidor?

Configure um IP de login habitual ou use login baseado em certificado para evitar essa situação. Para mais informações sobre como configurar um IP de login habitual, consulte Configurar escopo de varredura de alertas e regras de tratamento.

A prevenção de força bruta oferece suporte à proteção de aplicações web ou sites?

Não.

A prevenção de força bruta protege servidores que utilizam os protocolos RDP e SSH para login. Ela não oferece suporte à proteção de aplicações web ou sites.

O que devo fazer após um ataque de força bruta bem-sucedido?

Se a senha do servidor tiver sido quebrada com sucesso por um ataque de força bruta, o invasor pode ter comprometido o servidor e deixado programas maliciosos. Faça login no console do Security Center.No painel de navegação à esquerda, escolha Detection and Response > Alert. No canto superior esquerdo do console, selecione a região onde o ativo a ser protegido está localizado:Chinese Mainland ou Outside Chinese Mainland.na página Alert, acesse a aba CWPP para verificar se existem alertas relacionados a sucesso em força bruta.

Se existirem alertas semelhantes a ECS brute-force attack success em seus ativos, isso indica que o servidor correspondente foi comprometido por força bruta. Recomendamos reforçar a segurança do servidor seguindo estas etapas o mais rápido possível:

• Trate alertas relacionados a sucesso em força bruta

  Na página Alert, acesse a aba CWPP, clique em Process na coluna Actions do alerta, selecione Block na página Alert e, em seguida, clique em Handle Now. O Security Center gera regras de defesa de grupo de segurança para bloquear o acesso de IPs maliciosos. Para mais informações, consulte Responder a alertas de segurança.

• Altere a senha do usuário do servidor

  Altere a senha do usuário comprometido o mais rápido possível. Recomendamos o uso de uma senha forte.

• Use o recurso de verificação de linha de base do Security Center para detecção de riscos

  Utilize o recurso de verificação de linha de base do Security Center para verificar abrangentemente a segurança do servidor e tratar itens de risco com base nas recomendações. Para mais informações sobre como ativar esse recurso, consulte Ativar o recurso de verificação de riscos de linha de base.

Por que ainda recebo alertas de força bruta de senha após alterar uma senha fraca?

A alteração da senha fraca entra em vigor em base T+1. Durante o período anterior à entrada em vigor da alteração, o Security Center continua relatando alertas de força bruta de senha. Por exemplo, se você alterar a senha de login às 10:00 de 15 de janeiro de 2023, o modelo de detecção de linha de base coletará as informações atualizadas da senha e atualizará o banco de dados de senhas fracas por volta das 24:00 daquele dia. O modelo de detecção de login incomum carrega a senha anterior do banco de dados de senhas fracas antes das 24:00 de 15 de janeiro de 2023; portanto, os alertas de força bruta de senha ainda existirão durante esse período.

Ignore o alerta após confirmar que alterou a senha fraca e que a verificação de linha de base não detectou riscos de senha fraca.

Se a senha de login do servidor tiver sido quebrada por força bruta, recomendamos reforçar prontamente a segurança do servidor. Para mais informações, consulte O que devo fazer após um ataque de força bruta bem-sucedido?.

Por que ainda existem registros de ataque de força bruta RDP mesmo com a porta RDP 3389 já bloqueada por regras de grupo de segurança ou firewall?

Devido ao mecanismo de auditoria de login do Windows, os processos de auditoria de login para os serviços $IPC, RDP e SAMBA são registrados no mesmo log sem distinguir o método específico de login. Portanto, se você já bloqueou a porta do serviço RDP, mas ainda vê registros de ataque de força bruta RDP, verifique se os outros dois serviços também estão ativados.

Para verificar, confirme se a instância ECS está escutando portas como 135, 139 e 445 e se o IP público pode acessá-las. Verifique também se há registros de login correspondentes nos logs de segurança do Windows durante esse período.

Senha fraca de login no ECS refere-se a varredura de RDP ou SSH no nível do sistema?

Senhas fracas incluem dois tipos: senhas fracas para RDP e SSH, e senhas fracas para logins de backend administrativo de sistemas como CMS.

Quais produtos fornecem dados para a página Análise de Ataques?

Os dados exibidos na página Análise de Ataques são as estatísticas de ataques coletadas após o Security Center identificar e interceptar automaticamente eventos básicos de ataque, além de dados de ataques do Alibaba Cloud Web Application Firewall. Esses dados de ataque cobrem ativos de nuvem protegidos pelo Security Center e pelo Web Application Firewall. Você pode visualizar quais ativos estão protegidos pelo Security Center na página Assets.

O que devo fazer se meu servidor Windows receber alertas de vírus continuamente?

• Se o servidor Windows receber alertas de vírus continuamente, recomendamos determinar primeiro se é um falso positivo.

• Se o caminho do arquivo de vírus estiver localizado em um diretório oculto do sistema Windows (como o diretório da Lixeira $Recycle.Bin), talvez você não consiga pesquisar diretamente esse caminho no sistema de arquivos. É necessário ativar a exibição de arquivos ocultos e arquivos de sistema como administrador para visualizá-los. O agente do Security Center obtém o caminho do arquivo por meio de varredura de baixo nível, que não é restrita pela visibilidade do sistema de arquivos.

• Se você confirmar que o alerta é um falso positivo ou que o arquivo foi limpo, consulte as operações de remoção da lista de permissões neste documento, semelhantes a Adicionei acidentalmente um alerta de mineração à lista de permissões. Como removê-lo?, ou simplesmente ignore o alerta.

O que devo fazer se não receber um alerta ao fazer login de um local ou IP incomum após configurar uma regra de login habitual?

Se você configurou um local de login habitual, IP de login habitual, horário de login habitual ou conta de login habitual, mas não recebeu o alerta esperado ao fazer login de um local ou IP incomum, recomendamos verificar o seguinte:

• Verifique se a regra está em vigor. Regras de login habitual recém-adicionadas podem levar algum tempo para entrar em vigor. Aguarde.

• Verifique se o método de notificação de alerta está configurado corretamente. Confirme se suas configurações de notificação por SMS e e-mail estão ativadas.

• Verifique se o servidor que disparou o login está dentro do escopo da regra.

• Na página Alert, acesse a aba CWPP e altere a condição de filtro para Handled para verificar se há registros de alertas tratados.

Encontrei um arquivo isca suspeito (como !~readme.txt no diretório .aegis) no meu servidor. Isso significa que o servidor está comprometido?

/root/.aegis/!~readme.txt é um arquivo isca implantado proativamente pelo Security Center para detectar comportamentos de ransomware. Quando o ransomware tenta criptografar esse arquivo, o Security Center captura o comportamento e dispara um alerta anti-ransomware.

Este arquivo é um arquivo de proteção de segurança normal e não é um sinal de comprometimento do servidor. Ele não afeta a operação normal do servidor. Não o exclua.

Ao tratar um alerta, apenas as opções Add to Whitelist e Ignore estão disponíveis. As opções End Process e Virus Removal estão ausentes. O que devo fazer?

Alguns alertas possuem apenas as opções Add to Whitelist e Ignore Once, sem as opções Terminate Process e Virus Detection and Removal. Isso geralmente ocorre pelos seguintes motivos:

• Você não ativou uma edição paga do Security Center.

• Este tipo de alerta não oferece suporte a Terminate Process e Virus Detection and Removal.

• O alerta é um dado histórico ou um evento de alerta expirado.

Como determino se um alerta foi disparado por um scanner oficial da Alibaba Cloud ou verifico a origem de um SMS de alerta?

• Método de determinação

  Verifique o endereço IP de origem nos detalhes do alerta. Se o IP de origem pertencer ao intervalo oficial de IPs de varredura do Security Center (por exemplo, 47.110.180.32/27), confirma-se como um comportamento normal de varredura disparado por serviços oficiais. Se o IP não estiver dentro desse intervalo, não se trata de uma chamada de serviço oficial. Recomendamos verificar se ele é utilizado pelo seu negócio ou por uma ferramenta de terceiros, ou verificar se há risco de vazamento de AccessKey.

• Verificação da origem do SMS

  Se você receber um SMS suspeito de alerta do Security Center, mas não houver alerta correspondente no console, ou se suspeitar da autenticidade do SMS, verifique o número do remetente do SMS e os registros reais de alertas no console. Se não houver eventos de segurança relacionados no console e nenhum vazamento de AccessKey for detectado na sua conta, geralmente pode-se determinar que o SMS não é do Security Center da sua conta (pode ser um falso positivo, outro produto ou um SMS de phishing). Recomendamos consultar os dados reais no console.

Por que o número de alertas de defesa de rede no Security Center difere dos registros de interceptação no Cloud Firewall?

Os principais motivos para a discrepância de dados entre os dois são os seguintes:

• Escopos estatísticos diferentes: O Cloud Firewall conta todos os eventos de interceptação na camada de rede (incluindo políticas ACL, prevenção de intrusão IPS, etc.), enquanto o Security Center foca apenas em ameaças de segurança específicas (como ataques de força bruta SSH e ataques a aplicações web).

• Mecanismos diferentes de agregação de dados: O Security Center agrega múltiplos ataques iniciados pelo mesmo IP de origem em um curto período para exibição (mesclados em um único alerta), enquanto o Cloud Firewall tipicamente registra cada log de interceptação independente.

• Janelas de tempo e atrasos: Os intervalos de tempo selecionados nos dois consoles podem diferir, e há também certo atraso de sincronização no processamento de dados do Security Center.

Os recursos do servidor são excluídos ou desligados após o Security Center gerar um alerta?

Não.

O que devo fazer se o tratamento de um processo suspeito for ineficaz ou se apenas as opções Add to Whitelist/Ignore estiverem disponíveis?

Causa

Você não ativou uma edição paga do Security Center, ou o processo correspondente ao alerta não está mais em execução ou o arquivo foi excluído.

Solução

• Ative a edição Advanced ou superior para usar recursos de tratamento automático.

• Se você não ativar uma edição paga, precisará tratar o problema manualmente fazendo login no servidor:

  1. Anote o ID do processo (PID) no alerta e execute o seguinte comando para encerrar forçadamente o processo:

     kill -9 <PID>

  2. Se o processo não puder ser encerrado devido à autoproteção de programas maliciosos, execute primeiro o seguinte comando para remover a proteção do arquivo e, em seguida, encerre forçadamente o processo:

     chattr -i /path/to/file

  3. Verifique /etc/crontab e ~/.ssh/authorized_keys para limpar quaisquer resíduos.

• Se você confirmar que a ameaça foi eliminada, selecione Ignore ou Manually Handled para fechar o alerta.

Como investigo e trato um alerta suspeito de escalonamento de privilégios?

1. Confirme se é uma operação normal de O&M: Verifique se algum administrador realizou operações de escalonamento de privilégios, como sudo, su ou instalação de software no host, próximo ao horário do alerta. Se for uma operação planejada, ignore-a ou adicione-a à lista de permissões.

2. Verifique processos e arquivos suspeitos: Faça login no console do Security Center e acesse a página de detalhes do alerta para visualizar a cadeia de processos e os caminhos dos arquivos. Concentre-se em verificar binários desconhecidos, scripts ou comandos de sistema adulterados. Se acompanhado por alertas de login incomum ou força bruta, analise-os em conjunto com os alertas de Unusual Logon.

3. Sugestões de tratamento:

   • Se confirmado como malicioso, isole imediatamente o ativo, bloqueie a conexão de rede suspeita e use o recurso Virus Detection and Removal ou Vulnerabilities do Security Center para limpar backdoors e corrigir vulnerabilidades relacionadas.

   • Se for um falso positivo, clique em Add to Whitelist na página de detalhes do alerta.

O que devo fazer se receber um alerta de login incomum em um servidor configurado com login baseado em chave SSH?

1. Acesse a página Detection and Response > Alert no Security Center para visualizar os detalhes do alerta de login remoto e obter as informações de IP e região de login.

   Nota

   Se você ativou o serviço Agentic SOC, a entrada no painel de navegação à esquerda muda para Agentic SOC > Alert.

2. Faça login no servidor e verifique o log /var/log/secure para confirmar se o IP possui registros de login bem-sucedido.

3. Se o log mostrar login bem-sucedido baseado em chave, verifique se há chaves SSH desconhecidas no servidor. Recomendamos criar um novo par de chaves, reconfigurá-lo para uso e redefinir a senha de login do servidor para garantir a segurança.

Como exporto a lista de alertas do Security Center através da API?

1. Chame a operação ExportSuspEvents - Exportar informações de eventos incomuns para gerar um ID de tarefa de exportação.

2. Chame a operação DescribeSuspEventExportInfo - Consultar informações de exportação de eventos de alerta e passe o ID da tarefa.

3. Obtenha o campo link (URL de download) do resultado retornado.

4. Acesse a URL pelo navegador para baixar a lista de alertas como um arquivo ZIP para sua máquina local.

O que devo fazer se receber um erro "Failed to list deduct package" ao tratar um alerta de mineração?

Crie um snapshot de disco em nuvem e conceda as permissões necessárias para solucionar o problema.

Como confirmo se o Security Center ainda detecta anomalias após reinstalar o sistema?

Verifique a página Alert do Security Center e o uso de recursos da CPU do servidor. Se nenhuma comunicação de mineração for detectada nas últimas horas e o uso da CPU voltar ao normal, a anomalia foi eliminada.

O que devo fazer se o uso da CPU estiver alto, mas nenhum alerta de mineração for detectado?

1. Na página Detection and Response > Alert, trate todos os alertas históricos primeiro e, em seguida, realize a varredura.

   Nota

   Se você ativou o serviço Agentic SOC, a entrada no painel de navegação à esquerda muda para Agentic SOCAlert.

2. Se nenhum vírus for encontrado durante a varredura, o vírus foi limpo.

3. Verifique se há alertas sobre aplicações Java executando comandos codificados suspeitos ou execução de código de script malicioso. Recomendamos entrar em contato com os desenvolvedores para corrigir as vulnerabilidades no código e continuar observando.

Como confirmo que um alerta do Security Center foi disparado pelas minhas próprias operações de O&M?

Como os alertas não conseguem confirmar o IP de acesso específico, recomendamos verificar usando os seguintes métodos:

1. Verifique o nome de usuário e o horário da operação nos detalhes do alerta para determinar se correspondem ao seu próprio comportamento de O&M.

2. Verifique o caminho do processo (como /usr/bin/bash) e o processo pai (como sshd-session) nos detalhes do alerta.

3. Valide contra os logs de login.

4. Após tratar o alerta, teste se sua própria conexão é afetada para determinar a correlação.

5. Clique para autorizar o Security AI Assistant na página de detalhes do alerta para analisar os detalhes do alerta.

Como trato alertas causados por tarefas de inspeção agendada do StarOPS?

Visualize os detalhes do alerta no Security Center para verificar as informações relevantes. Compare o horário do alerta e o diretório de varredura do alerta com a tarefa de inspeção agendada do StarOPS. Se confirmar que o alerta foi causado por um comando executado pelo StarOPS, determine-o como falso positivo, ignore o alerta e observe as condições subsequentes.

O que devo fazer se o Security Center ainda gerar alertas de segurança após uma instância ter a assinatura cancelada ou ser liberada?

1. Faça login no console do Security Center e desvincule o servidor correspondente conforme descrito em Gerenciar servidores.

2. Na página Alert, se a instância do servidor tiver alertas não tratados associados, trate-os uniformemente como Ignored ou Manually Handled.

Causas e métodos de solução de problemas para ataques de IP interno em alertas

Causa

O Security Center detecta comportamentos que correspondem a assinaturas de ataque (como ataques de força bruta, varredura de portas, exploração de vulnerabilidades, etc.) iniciados por um IP de origem contra um servidor com base na análise de comportamento no nível do host. Desde que o comportamento seja anormal, um alerta é disparado independentemente de o IP de origem ser público ou interno.

Cenários possíveis

• Outras instâncias ECS na mesma conta estão comprometidas ou mal configuradas, iniciando ataques internos.

• Instâncias em outras VPCs acessam através de redes internas via Cloud Enterprise Network (CEN), conexões de peering VPC ou VPCs compartilhadas.

• Data centers locais conectam-se à nuvem via circuitos Express Connect.

• Solicitações internas de negócios de alta frequência são julgadas erroneamente.

Solução de problemas e tratamento

• Confirme a propriedade do IP no console ECS e verifique se existem configurações de conectividade de rede, como CEN ou conexões de peering.

• Faça login no console do Security Center para verificar o tipo específico de ataque, horário e porta para determinar se é um falso positivo.

• Se confirmado como negócio interno confiável, desative a política para esse IP na política de interceptação de IP e adicione o IP à lista de permissões.

• Se a origem não puder ser determinada, recomendamos manter a interceptação ativada e verificar o grupo de segurança do servidor de destino para garantir que apenas as portas necessárias estejam abertas.

Como confirmo se um código malicioso foi plantado por uma pessoa específica?

O Security Center foca na detecção de ameaças e não consegue identificar diretamente quem plantou o código malicioso. Se você ativou o ActionTrail, recomendamos revisar os registros de operação associados dentro da janela de tempo do alerta para auxiliar no rastreamento da origem.

O que devo fazer se um usuário RAM anormal (subconta) for criado na minha conta Alibaba Cloud?

Causa

O AccessKey disparou as regras de controle de risco de segurança da Alibaba Cloud, detectando "criação anormal de subconta de alto privilégio", o que indica que o AccessKey pode ter vazado.

Etapas de tratamento

1. Exclua o usuário RAM anormal com status Frozen no console RAM.

2. Desative e exclua imediatamente todos os AccessKeys desnecessários. Crie um novo AccessKey para o seu negócio e atualize a configuração.

3. Faça login no console do Security Center e verifique a página Security Alert para confirmar se há outros vestígios de intrusão.

4. Ative a autenticação multifator MFA para a conta principal e todos os usuários RAM.

Um alerta de login incomum é um falso positivo em um cenário onde apenas IPs internos específicos são permitidos e acessados através de VPN?

Avaliação de risco

Combinando a política de grupo de segurança (permitindo apenas IPs internos específicos) e o controle de acesso VPN (permitindo apenas acesso remoto pessoal), a probabilidade de ser atacado externamente por agentes maliciosos é baixa.

Causa

O alerta pode ser causado por problemas na coleta de logs, login não interativo ou um falso positivo (flutuações normais de negócios disparando a detecção de anomalias).

Sugestão

Após confirmar com a equipe de O&M que o IP é normal, execute Add to Whitelist para esse IP no Security Center, faça um backup via snapshot e observe se alertas semelhantes ocorrem posteriormente.

Como recupero a acessibilidade do site após o Security Center detectar um backdoor?

1. Faça login no console do Security Center e acesse a aba CWPP em Detection and Response > Alert para visualizar os detalhes específicos do alerta.

   Nota

   Se você ativou o serviço Agentic SOC, a entrada no painel de navegação à esquerda muda para Agentic SOC > Alert.

2. Se confirmado como arquivo backdoor, crie primeiro um backup via snapshot da instância ECS, depois exclua ou isole manualmente o arquivo anormal e verifique se o diretório do site e os arquivos de configuração estão completos.

3. Após concluir o tratamento, reinicie o serviço web para tentar restaurar o acesso.

O que devo fazer se o ambiente Python da minha instância ECS for danificado repetidamente, causando indisponibilidade do site?

1. Faça login no console do Security Center para verificar os detalhes do alerta e confirmar se há alertas críticos para Backdoor (WebShell) file discovered.

2. Se confirmado como arquivo malicioso, escolha o método de tratamento descrito em Virus Detection and Removal para encerrar imediatamente o processo do vírus e mover o arquivo do vírus para a área de quarentena.

3. Após o tratamento, investigue a causa da intrusão e reforce o sistema para evitar que backdoors sejam plantados novamente.

4. Se o ambiente Python não puder ser restaurado após a limpeza do backdoor, pode ser necessária intervenção adicional do suporte técnico.

O que devo fazer se alertas ECS não forem exibidos devido a instâncias estarem em regiões diferentes?

Acesse o console do Security Center, vá para a página Detection and Response > Alert e alterne a região para Outside Chinese Mainland para visualizar alertas de instâncias ECS fora da China continental.

O que devo fazer se a operação HandleSimilarSecurityEvents retornar um erro InvalidOperationForEvent?

A causa é que o servidor ECS está atualmente vinculado a uma autorização da edição Free do Security Center. Os recursos de tratamento proativo do Security Center, como colocar arquivos em quarentena ou encerrar processos, requerem autorização da edição Anti-Virus ou superior. Atualize sua autorização para usar os recursos relacionados ao tratamento de alertas.

Como visualizo alertas de segurança históricos para uma data específica?

Faça login no console do Security Center. No painel de navegação à esquerda, escolha Detection and Response > Alert para acessar a página de lista de alertas. Defina a condição de filtro de tempo (por exemplo, selecione uma data específica) para consultar os registros históricos de alertas de segurança desse período.

O que devo fazer se o console não exibir registros de alerta de proteção contra adulteração de arquivos?

1. No console do Security Center, acesse a aba CWPP em Detection and Response > Alert.

   Nota

   Se você ativou o serviço Agentic SOC, a entrada no painel de navegação à esquerda muda para Agentic SOC > Alert.

2. Confirme se a região correta está selecionada (por exemplo, Chinese Mainland ou Outside Chinese Mainland).

3. Na lista de alertas, localize o alerta filtrando pelo IP do servidor e tipo de evento.