Resolver problemas comuns

Compatível com:

Este documento fornece uma coleção de dicas e procedimentos para ajudar você a diagnosticar e resolver problemas comuns encontrados durante a implantação e a operação do agente remoto do Google Security Operations.

Problema de incompatibilidade de chaves

Esse problema ocorre quando as chaves privadas no Google Security Operations e no agente remoto não correspondem. Para resolver isso, verifique se a chave nos recursos do agente corresponde à chave no agent_db do Siemplify.

Falha no conector remoto

Se um conector remoto falhar, siga estas etapas:

  1. Verifique se uma instância de integrações foi instalada no agente.
  2. Verifique os registros agênticos no nível de erro para encontrar falhas no processo de conexão.
  3. Teste a mesma configuração do conector localmente e verifique se há erros.

Falha na instalação: SO host não compatível ou incompatibilidades de EOL

Se as instalações novas ou os upgrades automáticos falharem devido a erros de rastreamento da glibc e bloqueios de chamadas do sistema, siga estas etapas:

  1. Verifique se o ambiente de host não está executando um sistema operacional legado, que pode não ter ganchos de chamada de sistema modernos.
  2. Hospede novamente o ambiente do agente em uma distribuição empresarial do Linux com a versão oficial mais recente.
  3. Para implantações de instalador manual, verifique se o host executa um sistema operacional compatível, como o Debian 12 ou o Red Hat Enterprise Linux (RHEL) 8.7:

    Verifique /etc/os-release: execute o comando a seguir e procure NAME= e VERSION_ID=:

    cat /etc/os-release
    • Para o Debian 12: procure NAME="Debian GNU/Linux" e VERSION_ID="12".
    • Para o RHEL 8.7: procure NAME="Red Hat Enterprise Linux" e VERSION_ID="8.7".

    Se o host executar o RHEL 9 ou 10 (ou posterior), implante o agente remoto usando um mecanismo de contêiner compatível (Podman ou Docker) em vez do instalador manual. As imagens de contêiner pré-criadas para versões do agente remoto posteriores à 2.5.0.4 são baseadas no Debian 12, que também resolve incompatibilidades binárias de roda do Python (.whl) (como ModuleNotFoundError para TIPCommon ou SiemplifyAddressProvider) em agentes do CentOS 7. Para mais informações, consulte Sistemas operacionais compatíveis.

A configuração do contêiner extrai a camada operacional anterior em vez do build "mais recente"

Se a nova execução dos comandos de configuração do contêiner extrair inadvertidamente uma camada operacional anterior em vez do build de software recém-lançado, execute os seguintes comandos para extrair explicitamente a imagem mais recente:

  • Para o Docker:

    docker pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

  • Para o Podman:

    podman pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

Para garantir que a implantação seja executada na versão de software mais atualizada, sempre extraia a imagem mais recente antes de executar o contêiner do agente. Se a extração de docker.io solicitar credenciais devido a limitação de taxa, extraia a imagem do endpoint público do Artifact Registry (us-docker.pkg.dev/siem-ar-public/images/agent:latest). Para domínios de lista de permissões de firewall necessários, consulte Requisitos de rede e firewall.

Falha na implantação do agente do Docker

Se a implantação do Docker falhar, siga estas etapas:

  1. Remova o contêiner do Docker:

    1. Execute o comando a seguir para listar os contêineres em execução:

      docker ps 

    2. Execute o seguinte comando para remover os contêineres com falha:

      docker rm -f container_id_or_name
  2. Remover imagens:

    1. Execute o comando a seguir para listar as imagens:

      docker images 

    2. Execute o comando a seguir para remover a imagem:

      docker rmi image_id_or_name
  3. Remova os volumes:

    1. Execute o comando a seguir para listar os volumes:

      docker volume ls

    2. Execute o comando a seguir para remover os volumes:

      docker volume rm volume_name
  4. Implante o agente novamente. Para mais informações, consulte Criar um agente usando o Docker.

Agente travado no status "Aguardando agente"

Se o agente foi implantado, mas o status permanece "aguardando agente", siga estas etapas para resolver o problema:

  1. Verifique a conectividade do host: teste a conectividade com a Internet da máquina host do agente (por exemplo, curl www.google.com ou ping 8.8.8.8). Se isso falhar, o problema é com a conexão de Internet do host.

  2. Verifique a conectividade do contêiner: se o teste do host for aprovado, entre no shell do contêiner usando docker exec -it container_ID bash e verifique a conectividade novamente. Se o contêiner não tiver conectividade, reinicie o serviço do Docker na máquina host (service docker restart).

    1. Execute este comando:

      docker exec -it bash

    2. Verifique a conectividade novamente como você fez antes.
    3. Se não houver conectividade, execute o seguinte comando para reiniciar o serviço do Docker na máquina host (não no contêiner):

      service docker restart

    4. Execute o comando a seguir para iniciar o contêiner novamente:

      docker start

  3. Analisar os registros do contêiner em busca de erros

    Se a etapa anterior não ajudar e o status do agente ainda for "aguardando agente" depois de atualizar a página Agente remoto no Google SecOps, faça login novamente no contêiner e extraia os registros.

    1. Encontre os registros no diretório /var/log/SiemplifyAgent/.
    2. Procure erros nos arquivos de registro para identificar a causa raiz.

  4. Confirme se o firewall permite o tráfego HTTPS de saída na porta TCP 443 para o Publisher, a API Chronicle de localização e os endpoints de autenticação do Google Cloud . Verifique também se os proxies da camada do aplicativo ou os firewalls de inspeção profunda de pacotes (DPI, na sigla em inglês) ignoram a inspeção SSL/TLS para o host do agente remoto. Para ver a lista de domínios necessários, consulte Requisitos de rede e firewall.

Problemas de rede de DNS

Se o contêiner tiver falhas de resolução de DNS ou problemas de conectividade de rede, adicione --network host ao comando docker run. O uso do modo de rede do host permite que o contêiner compartilhe diretamente a pilha de rede e a configuração de DNS da máquina host.

Falha ao carregar a imagem Docker (o encaminhamento de IP4 está desativado)

Se você receber um erro na CLI ao tentar carregar uma imagem Docker (sistema) ou um agente do Google SecOps, o encaminhamento de IP4 pode estar desativado. Siga estas etapas para ativá-lo e reiniciar o agente:

  1. Adicione a seguinte linha ao arquivo /etc/sysctl.conf:

    net.ipv4.ip_forward=1 Será necessário usar um editor de arquivos (como o nano, por exemplo: yum install nano -y

  2. Execute o seguinte comando para reiniciar o serviço de rede:

    systemctl restart network

  3. Execute o comando a seguir para reiniciar o serviço do Docker:

    sudo systemctl restart docker

  4. Execute o seguinte comando para verificar se o contêiner está em execução:

    docker ps

  5. Se o contêiner não estiver em execução, execute o seguinte comando para listar todos os contêineres (incluindo os que foram interrompidos):

    docker ps -a

  6. Se o contêiner estiver listado, mas interrompido, execute o seguinte comando para iniciá-lo:

    docker start container_id_or_name
  7. Se o agente ou o sistema ainda não estiver em execução depois de reiniciar o Docker e o contêiner:

    1. Execute o seguinte comando para interromper o contêiner:

      docker stop container_id_or_name

    2. Execute o comando a seguir para excluir o contêiner:

      docker rm container_id_or_name

    3. Execute o comando a seguir para excluir a imagem:

      docker rmi image_name
    4. Carregue a imagem novamente.

Erro após o desligamento ou a reinicialização do agente

Execute o seguinte comando para forçar o início do agente do instalador:
systemctl start supervisord

Execute o comando a seguir para forçar o início do agente do Docker:
docker start

As tarefas do agente remoto falham em ambientes protegidos

Ao implantar um agente remoto em um host Linux protegido, como o RHEL 8, as tarefas do agente (incluindo salvar ou fazer upgrade de uma integração ou executar conectores e ações) podem falhar ou expirar na UI, enquanto o status do agente permanece Ativo. Esse problema ocorre quando a aplicação da segurança do SO host, como o SELinux no modo Enforcing, o AppArmor ou o software de segurança de endpoint, bloqueia os comandos do SO executados pelo agente dentro do contêiner.

Para resolver esse problema, o Agente Remoto precisa ser isento das políticas de restrição de segurança do host que bloqueiam os comandos do SO. Siga estas etapas para diagnosticar e resolver o problema:

  1. Verifique se o SELinux está no modo Enforcing na máquina host:

    getenforce
sestatus

    Para verificar se há comandos bloqueados ou operações negadas recentemente em /var/log/audit/audit.log sem retornar todo o arquivo de registro, execute o seguinte comando:

    sudo grep -i "denied" /var/log/audit/audit.log | tail -n 50

    Também é possível inspecionar os registros de segurança do endpoint no host para operações bloqueadas relacionadas aos processos do contêiner do agente.

  2. Isente o agente remoto da política de segurança de bloqueio no host:

    • Para implantações em contêineres (Docker ou Podman), isente todo o contêiner do agente remoto ao iniciá-lo pela primeira vez adicionando --security-opt label=disable (para SELinux) ou --security-opt apparmor=unconfined (para AppArmor) ao comando docker run ou podman run.
    • Configure regras de política personalizadas do SELinux, perfis do AppArmor ou isenções de segurança de endpoint do host para os diretórios do agente remoto (/opt/SiemplifyAgent, /home/siemplify_agent/agent_source e /var/log/SiemplifyAgent) e executáveis (/usr/local/bin/python3.11, /usr/local/bin/pip3 e /usr/bin/supervisord) para que os comandos do SO não sejam bloqueados.

  3. Como alternativa, se não for possível configurar uma isenção de SELinux direcionada, defina o SELinux para o modo Permissive de maneira persistente em todas as reinicializações, definindo SELINUX=permissive em /etc/selinux/config no host.

    Se não for possível modificar /etc/selinux/config ou se você precisar aplicar a mudança imediatamente sem reiniciar, execute o comando a seguir para alternar temporariamente o SELinux para o modo Permissive:

    sudo setenforce 0

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.