일반적인 문제 해결

다음에서 지원:

이 문서에서는 Google Security Operations 원격 에이전트의 배포 및 운영 중에 발생하는 일반적인 문제를 진단하고 해결하는 데 도움이 되는 도움말과 절차를 제공합니다.

키 불일치 문제

이 문제는 Google Security Operations의 비공개 키와 원격 에이전트가 일치하지 않을 때 발생합니다. 이 문제를 해결하려면 에이전트 리소스의 키가 Siemplify agent_db의 키와 일치하는지 확인합니다.

원격 커넥터 오류

원격 커넥터가 실패하면 다음 단계를 따르세요.

  1. 에이전트에 통합 인스턴스가 설치되었는지 확인합니다.
  2. 오류 수준에서 에이전트 로그를 확인하여 연결 프로세스에서 실패가 있는지 확인합니다.
  3. 로컬에서 동일한 커넥터 구성을 테스트하고 오류가 있는지 확인합니다.

설치 실패: 지원되지 않는 호스트 OS 또는 EOL 비호환성

glibc 추적 오류 및 시스템 호출 차단으로 인해 새로 설치하거나 자동 업그레이드에 실패하는 경우 다음 단계를 따르세요.

  1. 호스트 환경에서 최신 시스템 호출 후크가 없을 수 있는 기존 운영체제를 실행하고 있지 않은지 확인합니다.
  2. 최신 공식 버전의 엔터프라이즈 Linux 배포판에서 에이전트 환경을 다시 호스팅합니다.
  3. 호스트가 지원되는 플랫폼인지 확인합니다. Debian 12 (공식 기본), RHEL 8.7:

    /etc/os-release 확인: 다음 명령어를 실행하고 NAME= 및 VERSION_ID=를 찾습니다.

    cat /etc/os-release
    • Debian 12: NAME="Debian GNU/Linux" 및 VERSION_ID="12"를 찾습니다.
    • RHEL 8.7: NAME="Red Hat Enterprise Linux" 및 VERSION_ID="8.7"를 찾습니다.

컨테이너 설정에서 '최신' 빌드 대신 이전 운영 레이어를 가져옴

컨테이너 설정 명령어를 다시 실행할 때 새로 출시된 소프트웨어 빌드 대신 이전 운영 레이어를 실수로 가져오는 경우 다음 명령어를 실행하여 최신 이미지를 명시적으로 가져옵니다.

  • Docker:

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

  • Podman:

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

배포가 최신 소프트웨어 출시 버전에서 실행되도록 하려면 에이전트 실행 명령어를 실행하기 전에 항상 최신 이미지를 가져오세요.

Docker 에이전트 배포 실패

Docker 배포가 실패하면 다음 단계를 따르세요.

  1. Docker 컨테이너를 삭제합니다.

    1. 다음 명령어를 실행하여 실행 중인 컨테이너를 나열합니다.

      docker ps 

    2. 다음 명령어를 실행하여 실패한 컨테이너를 삭제합니다.

      docker rm -f container_id_or_name
  2. 이미지 삭제:

    1. 다음 명령어를 실행하여 이미지를 나열합니다.

      docker images 

    2. 다음 명령어를 실행하여 이미지를 삭제합니다.

      docker rmi image_id_or_name
  3. 볼륨을 삭제합니다.

    1. 다음 명령어를 실행하여 볼륨을 나열합니다.

      docker volume ls

    2. 다음 명령어를 실행하여 볼륨을 삭제합니다.

      docker volume rm volume_name
  4. 에이전트를 다시 배포합니다. 자세한 내용은 Docker를 사용하여 에이전트 만들기를 참조하세요.

상담사가 '상담사 대기 중' 상태에서 멈춤

에이전트가 배포되었지만 상태가 '에이전트 대기 중'으로 유지되는 경우 다음 단계에 따라 문제를 해결하세요.

  1. 호스트 연결 확인: 에이전트 호스트 머신의 인터넷 연결을 테스트합니다 (예: curl www.google.com 또는 ping 8.8.8.8). 실패하면 호스트의 인터넷 연결에 문제가 있는 것입니다.

  2. 컨테이너 연결 확인: 호스트 테스트를 통과하면 docker exec -it container_ID bash를 사용하여 컨테이너 셸을 입력하고 연결을 다시 확인합니다. 컨테이너에 연결이 없으면 호스트 머신에서 Docker 서비스를 다시 시작합니다(service docker restart).

    1. 다음 명령어를 실행합니다.

      docker exec -it bash

    2. 이전과 같이 연결을 다시 확인합니다.
    3. 연결이 없으면 다음 명령어를 실행하여 호스트 머신 (컨테이너 아님)에서 Docker 서비스를 다시 시작합니다.

      service docker restart

    4. 다음 명령어를 실행하여 컨테이너를 다시 시작합니다.

      docker start

  3. 컨테이너 로그에서 오류 검토

    이전 단계가 도움이 되지 않고 Google SecOps에서 원격 에이전트 페이지를 새로고침한 후에도 에이전트 상태가 여전히 '에이전트 대기 중'인 경우 컨테이너에 다시 로그인하고 로그를 가져옵니다.

    1. /var/log/SiemplifyAgent/ 디렉터리에서 로그를 찾습니다.
    2. 로그 파일에서 오류를 찾아 근본 원인을 파악합니다.

DNS 네트워킹 문제

컨테이너에 DNS 변환 실패 또는 네트워크 연결 문제가 발생하면 docker run 명령어에 --network host를 추가합니다. 호스트 네트워크 모드를 사용하면 컨테이너가 호스트 머신의 네트워크 스택과 DNS 구성을 직접 공유할 수 있습니다.

Docker 이미지를 로드할 수 없음 (IP4 전달이 사용 중지됨)

Google SecOps Docker 이미지 (시스템) 또는 에이전트를 로드하려고 할 때 CLI에 오류가 표시되면 IP4 전달이 사용 중지되었을 수 있습니다. 다음 단계에 따라 사용 설정하고 에이전트를 다시 시작합니다.

  1. /etc/sysctl.conf 파일에 다음 줄을 추가합니다.

    net.ipv4.ip_forward=1 파일 편집기를 사용해야 합니다 (예: nano 사용). yum install nano -y

  2. 다음 명령어를 실행하여 네트워크 서비스를 다시 시작합니다.

    systemctl restart network

  3. 다음 명령어를 실행하여 Docker 서비스를 다시 시작합니다.

    sudo systemctl restart docker

  4. 다음 명령어를 실행하여 컨테이너가 실행 중인지 확인합니다.

    docker ps

  5. 컨테이너가 실행 중이 아니면 다음 명령어를 실행하여 중지된 컨테이너를 포함한 모든 컨테이너를 나열합니다.

    docker ps -a

  6. 컨테이너가 나열되어 있지만 중지된 경우 다음 명령어를 실행하여 시작합니다.

    docker start container_id_or_name
  7. Docker 및 컨테이너를 다시 시작한 후에도 에이전트 또는 시스템이 여전히 실행되지 않는 경우:

    1. 다음 명령어를 실행하여 컨테이너를 중지합니다.

      docker stop container_id_or_name

    2. 다음 명령어를 실행하여 컨테이너를 삭제합니다.

      docker rm container_id_or_name

    3. 다음 명령어를 실행하여 이미지를 삭제합니다.

      docker rmi image_name
    4. 이미지를 다시 로드합니다.

에이전트 종료 또는 재부팅 후 오류

다음 명령어를 실행하여 설치 프로그램 에이전트를 강제로 시작합니다.
systemctl start supervisord

다음 명령어를 실행하여 Docker 에이전트를 강제로 시작합니다.
docker start

강화된 환경에서 원격 에이전트 작업이 실패함

RHEL 8과 같은 강화된 Linux 호스트에 원격 에이전트를 배포하면 에이전트 상태가 라이브로 유지되는 동안 에이전트 태스크(통합 저장 또는 업그레이드, 커넥터 및 작업 실행 포함)가 실패하거나 UI에서 타임아웃될 수 있습니다. 이 문제는 Enforcing 모드의 SELinux, AppArmor, 엔드포인트 보안 소프트웨어와 같은 호스트 OS 보안 시행이 컨테이너 내에서 에이전트가 실행하는 OS 명령어를 차단할 때 발생합니다.

이 문제를 해결하려면 원격 에이전트를 OS 명령어를 차단하는 호스트 보안 시행 정책에서 제외해야 합니다. 다음 단계에 따라 문제를 진단하고 해결하세요.

  1. SELinux가 호스트 머신에서 Enforcing 모드인지 확인합니다.

    getenforce
sestatus

    전체 로그 파일을 반환하지 않고 최근에 차단된 명령어 또는 거부된 작업에 대해 /var/log/audit/audit.log를 확인하려면 다음 명령어를 실행합니다.

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

    또한 호스트에서 엔드포인트 보안 로그를 검사하여 에이전트 컨테이너 프로세스와 관련된 차단된 작업을 확인할 수 있습니다.

  2. 호스트의 차단 보안 정책에서 원격 에이전트를 제외합니다.

    • 컨테이너화된 배포 (Docker 또는 Podman)의 경우 --security-opt label=disable (SELinux의 경우) 또는 --security-opt apparmor=unconfined (AppArmor의 경우)를 docker run 또는 podman run 명령어에 추가하여 처음 시작할 때 전체 원격 에이전트 컨테이너를 제외합니다.
    • OS 명령어가 차단되지 않도록 원격 에이전트 디렉터리(/opt/SiemplifyAgent, /home/siemplify_agent/agent_source, /var/log/SiemplifyAgent) 및 실행 파일 (/usr/local/bin/python3.11, /usr/local/bin/pip3, /usr/bin/supervisord)에 대해 커스텀 SELinux 정책 규칙, AppArmor 프로필 또는 호스트 엔드포인트 보안 예외를 구성합니다.

  3. 또는 타겟팅된 SELinux 예외를 구성할 수 없는 경우 호스트의 /etc/selinux/config에서 SELINUX=permissive를 설정하여 재부팅 시 SELinux를 Permissive 모드로 영구적으로 설정합니다.

    /etc/selinux/config를 수정할 수 없거나 재부팅하지 않고 변경사항을 즉시 적용해야 하는 경우 다음 명령어를 실행하여 SELinux를 일시적으로 Permissive 모드로 전환합니다.

    sudo setenforce 0

도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.