일반적인 Linux 전달자 문제 해결

다음에서 지원:

Google SecOps SIEM

이 문서는 Google Security Operations Linux 전달자를 사용하는 동안에 발생할 수 있는 일반적인 문제를 인식하고 해결하는 데 도움이 됩니다.

전달자가 시작되지 않음

전달자가 시작되지 않고 로그에 다음 오류와 함께 지속적인 재시작 루프에 빠졌습니다.

F0510 06:17:39.013603 202 main_linux.go:153] open /opt/chronicle/external/*.conf: no such file or directory

원인 1: 구성 파일의 매핑이 잘못됨

이 문제를 해결하려면 구성 파일에 올바른 경로를 전달하고 외부 폴더에 매핑하고 있는지 확인해야 합니다.

가능한 원인 2: SELinux가 사용 설정됨

전달자를 시작하지 않고 컨테이너로 이동하여 구성 파일을 확인하고 다음 명령어를 실행합니다.
```
docker run --name cfps --log-opt max-size=100m --log-opt   max-file=10 --net=host -v ~/configuration:/opt/chronicle/external --entrypoint=/bin/bash \
-it gcr.io/chronicle-container/cf_production_
```
이 명령어를 사용하면 컨테이너 내부에서 셸로 이동할 수 있습니다.
다음 명령어를 실행합니다.
```
ls -lrt /opt.chronicle/external/
```
권한 거부 오류가 발생하면 전달자가 구성 파일을 열 수 없으므로 시작할 수 없음을 나타냅니다.

이 문제를 해결하려면 다음 단계를 따르세요.

다음 명령어를 실행하여 SELinux 상태를 확인합니다.
```
  sestatus
```
SELinux 상태가 출력에 사용 설정되어 있으면 다음 명령어를 실행하여 중지합니다.
```
  setenforce 0
```

로그가 Google Security Operations 테넌트에 도달하지 않음

가능한 원인 1: DNS 변환

다음 명령어를 실행하여 호스트에서 주소를 확인할 수 없거나 Google Security Operations에 연결할 수 없는지 확인합니다.

  nslookup malachiteingestion-pa.googleapis.com

명령어가 실패하면 네트워킹팀에 문의하여 문제를 해결하세요.

가능한 원인 2: 방화벽

다음 명령어를 실행하여 로컬 방화벽에서 Google Security Operations와 전달자 간의 통신을 차단하는지 확인합니다.

  firewall-cmd --state

방화벽이 사용 설정되어 있으면 다음 명령어를 실행하여 중지합니다.

  systemctl stop firewalld

가능한 원인 3: 버퍼 사이즈

로그에서 다음 오류를 찾아 버퍼 사이즈 문제인지 확인합니다.

Memory ceiling (1073741824) reached, freeing a batch from the backlog

이 문제를 해결하려면 다음 단계를 따르세요.

전달자 구성 파일에서 압축을 사용 설정합니다.
구성 파일에서 max_memory_buffer_bytes 및 max_file_buffer_bytes 매개변수를 업데이트하여 버퍼 크기를 늘립니다. 이 매개변수는 메모리 또는 디스크에 저장된 백로그 일괄 처리의 버퍼를 나타냅니다.

전달자와 호스트가 로그를 수신하지 않음

호스트와 전달자가 로그를 수신하지 않는 경우 각 포트에 대해 다음 명령어를 실행하여 포트 상태를 확인합니다.

  netstat -a | grep PORT

PORT를 확인하려는 포트 ID로 바꿉니다.

명령어에 출력이 없으면 호스트가 해당 포트에서 수신 대기 중이 아님을 나타내므로 네트워크 관리자에게 문의해야 합니다.

명령어의 출력에 호스트가 포트에서 수신 대기 중이고 전달자가 여전히 로그를 수신하지 않는다고 표시되면 다음을 수행하세요.

다음 명령어를 실행하여 Docker를 중지합니다.
```
docker stop cfps
```
네트워크 설정에 따라 다음 명령어 중 하나를 실행합니다.

TCP의 경우:
```
nc -l PORT
```
UDP의 경우:
```
nc -l -u PORT
```
PORT를 문제 해결하려는 포트 ID로 바꿉니다.
외부 서비스를 다시 시작하고 문제가 해결됐는지 확인합니다. 문제가 지속되면 [Google Security Operations 지원팀에 문의하세요.

전달자가 로그를 수신하지 않지만 호스트는 로그를 수신함

호스트는 로그를 수신하지만 전달자는 수신하지 않는 경우 전달자가 구성 파일에 지정된 포트에서 수신 대기하고 있지 않다는 의미입니다.

이 문제를 해결하려면 다음 단계를 따르세요.

시스템에서 터미널 창 두 개를 엽니다. 하나는 전달자를 구성하고 다른 하나는 호스트로 테스트 메시지를 전송하는 데 사용됩니다.
1. 첫 번째 터미널(전달자)에서 다음 명령어를 실행하여 전달자를 시작하지 않고 Docker를 시작합니다.
```
docker run \
--name cfps \
--log-opt max-size=100m \
--log-opt max-file=10 \
--net=host \
-v ~/config:/opt/chronicle/external \
--entrypoint=/bin/bash \
-it gcr.io/chronicle-container/cf_production_stable
```
2. 전달자가 리슨해야 하는 포트를 지정합니다.
```
nc -l PORT
```
  PORT를 문제 해결하려는 포트 ID로 바꿉니다.
두 번째 터미널(호스트)에서 다음 명령어를 실행하여 포트로 테스트 메시지를 전송합니다.
```
echo "test message" | nc localhost PORT
```
PORT를 문제 해결하려는 포트 ID로 바꿉니다.

docker 명령어를 다시 실행합니다. 다음 명령어를 실행하여 전달자가 수신 대기해야 하는 포트와 함께 -p 플래그를 지정합니다.

docker run \
--detach \
–name cfps \
--restart=always \
--log-opt max-size=100m \
--log-opt max-file=10 --net=host \
—v /root/config:/opt/chronicle/external \
-p 11500:11800 \
gcr.io/chronicle-container/cf_production_stable