Linux용 Google Security Operations 전달자

이 문서에서는 Linux에서 전달자를 설치하고 구성하는 방법을 설명합니다. Windows에서 전달자를 설치하려면 Windows 전달자를 참조하세요.

전달자는 고객 환경의 로그를 Google Security Operations 인스턴스로 보내는 데 사용됩니다. 고객이 로그를 직접 Google Security Operations에 전송하려고 하고 데이터를 수집하는 데 클라우드 버킷을 사용하려고 하지 않거나 logtype에 서드 파티 API를 통한 기본 수집이 없는 경우에 사용됩니다. Ingestion API를 수동으로 사용하는 대신 솔루션 배포 준비로 전달자를 사용할 수 있습니다.

Debian, Ubuntu, Red Hat, Suse를 포함하여 다양한 Linux 배포판에 전달자를 설치할 수 있습니다. Google Cloud는 Docker 컨테이너를 사용하여 소프트웨어를 제공합니다. Linux를 실행하는 물리 또는 가상 머신에서 Docker 컨테이너를 실행하고 관리할 수 있습니다.

시스템 요구사항

다음은 일반적인 권장사항입니다. 시스템별 권장사항은 Google Security Operations 지원팀에 문의하세요.

• RAM—Google Security Operations에서 수집을 허용하는 수집된 데이터 유형(수집기)마다 1GB가 필요합니다. 예를 들어 서로 다른 수집기 4개를 지정한 경우 모든 수집기 4개의 데이터를 수집하려면 RAM 4GB가 필요합니다.

• CPU—10,000보다 낮은 초당 이벤트(EPS) 수를 처리하려면 2개 CPU로 충분합니다(모든 데이터 유형 합계). 10,000 초과 EPS를 전달해야 하면 4~6개 CPU를 프로비저닝하세요.

• 디스크—Google Security Operations 전달자에서 처리하는 데이터 양에 관계없이 디스크 공간 100MB이면 충분합니다. 메모리와 반대로 디스크에 백로그 메시지를 버퍼링해야 하는 경우 디스크 버퍼링을 참조하세요. 기본적으로 Google Security Operations 전달자는 메모리로 버퍼링됩니다.

Google IP 주소 범위

방화벽 구성을 설정할 때와 같이 전달자 구성을 설정할 때 IP 주소 범위를 열어야 할 수 있습니다. Google은 특정 IP 주소 목록을 제공할 수 없습니다. 하지만 Google IP 주소 범위를 가져올 수 있습니다.

방화벽 구성 확인

Google Security Operations 전달자 컨테이너와 인터넷 사이에 있는 방화벽이나 인증된 프록시를 사용하려면 다음 호스트에 대한 액세스 열기 규칙이 필요합니다.

연결 유형	대상	포트
TCP	malachiteingestion-pa.googleapis.com	443
TCP	asia-northeast1-malachiteingestion-pa.googleapis.com	443
TCP	asia-south1-malachiteingestion-pa.googleapis.com	443
TCP	asia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	australia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	europe-malachiteingestion-pa.googleapis.com	443
TCP	europe-west2-malachiteingestion-pa.googleapis.com	443
TCP	europe-west3-malachiteingestion-pa.googleapis.com	443
TCP	europe-west6-malachiteingestion-pa.googleapis.com	443
TCP	me-central2-malachiteingestion-pa.googleapis.com	443
TCP	me-west1-malachiteingestion-pa.googleapis.com	443
TCP	northamerica-northeast2-malachiteingestion-pa.googleapis.com	443
TCP	accounts.google.com	443
TCP	gcr.io	443
TCP	oauth2.googleapis.com	443
TCP	storage.googleapis.com	443

구성 파일 맞춤설정

Google Cloud는 출력 섹션에 표시된 대로 특정 메타데이터를 사용하여 전달자 인스턴스에 맞게 구성 파일을 조정합니다. 요구사항에 따라 구성 파일을 다운로드하고 수집기 섹션에서 수집할 로그 유형에 대한 정보를 포함할 수 있습니다. 구성 설정에 대한 자세한 내용은 구성 설정 참조를 확인하세요.

Linux 전달자 구성

UI를 통해 Linux 전달자를 구성하려면 Google SecOps UI를 통해 전달자 구성 관리를 참조하세요.

Linux 전달자를 수동으로 구성하려면 다음을 수행합니다.

1. 소프트웨어와 함께 제공된 구성 파일 템플릿을 복사합니다.

2. UI를 통해 구성 파일을 다운로드합니다.

3. 다음 이름 지정 규칙에 따라 두 파일을 같은 디렉터리에 저장합니다.

   FORWARDER_NAME.conf - 이 파일을 사용하여 로그 수집과 관련된 구성 설정을 정의합니다.

   FORWARDER_NAME_auth.conf - 이 파일을 사용하여 승인 사용자 인증 정보를 정의합니다.

4. 전달자 인스턴스의 구성이 포함되도록 파일을 수정합니다. 이 문서에 제공된 샘플을 참조로 사용합니다.

5. 입력에 해당하는 인증 세부정보가 없더라도 FORWARDER_NAME_auth.conf 파일의 각 입력에 항목이 존재해야 합니다. 이는 데이터를 올바르게 매핑하는 데 필요합니다.

구성 파일에 대한 변경 사항은 5분 이내에 전달자에 의해 자동으로 적용됩니다.

샘플 구성

다음 코드 샘플은 전달자의 구성 파일 형식을 보여줍니다. Splunk 또는 Syslog와 같은 각 수집 메커니즘 유형의 설정에 대한 자세한 내용은 데이터 수집을 참조하세요.

FORWARDER_NAME.conf 파일

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: COLLECTOR_ID \
    customer_id: CUSTOMER_ID \

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DNS"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      tcp_buffer_size: 524288

FORWARDER_NAME_auth.conf 파일

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
  - syslog:
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"

이 두 파일 시스템을 사용하면 보안이 강화되도록 인증 사용자 인증 정보를 별도의 파일에 저장할 수 있습니다. FORWARDER_NAME.conf 파일을 버전 제어 저장소 또는 열려 있는 구성 관리 시스템에 저장할 수 있습니다. 전달자가 실행되는 물리적 또는 가상 머신에 FORWARDER_NAME_auth.conf 파일을 직접 저장할 수 있습니다.

참고: 단일 구성 파일을 사용하여 이미 Google Security Operations 전달자 인스턴스를 실행하고 있으면 단일 파일을 계속 사용하여 데이터 수집에 사용되는 전달자를 구성할 수 있습니다.

샘플 구성(단일 파일)

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: "COLLECTOR_ID" \
    customer_id: "CUSTOMER_ID" \
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\ "PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/malachite-test-1%40malachite-test.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DNS"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"
      tcp_buffer_size: 524288

단일 구성 파일을 사용 중이고 두 파일 시스템으로 이전하려는 경우 다음을 수행합니다.

1. 기존 구성의 사본을 만듭니다.
2. 한 파일을 FORWARDER_NAME.conf 파일로 저장하고 파일에서 승인 사용자 인증 정보를 삭제합니다.
3. 다른 파일을 FORWARDER_NAME_auth.conf 파일로 저장하고 파일에서 승인되지 않은 모든 데이터를 삭제합니다. 이 가이드에 제공된 샘플 구성 파일을 참조로 사용합니다.
4. 구성 파일 맞춤설정 섹션에 설명된 이름 지정 규칙과 기타 가이드라인을 따라야 합니다.

주의: 조직 외부에서 구성 파일을 공유하지 마세요.

Docker 설치

Docker 설치는 호스트 환경에 따라 달라집니다. 서로 다른 호스트 운영체제에 Docker를 설치할 수 있습니다. Google Cloud는 몇 가지 일반적인 Linux 배포판에서 Docker를 쉽게 설치할 수 있도록 일부 제한적인 문서를 제공합니다. 하지만 Docker는 오픈소스이고 필요한 모든 문서가 이미 제공되고 있습니다. Docker 설치에 대한 안내는 Docker 문서를 참조하세요.

Docker가 시스템에 설치되면 Google Security Operations 전달자 설치 프로세스는 모든 유형의 Linux 배포와 비슷합니다.

Docker가 시스템에 올바르게 설치되었는지 확인하려면 다음 명령어 (승격된 권한)를 실행합니다.

   docker ps
  

다음 응답은 Docker가 올바르게 설치되었음을 나타냅니다.

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

유용한 Docker 명령어

• 다음 명령어를 사용하여 Docker 설치에 대한 추가 정보를 수집할 수 있습니다.

  docker info
  

• Docker 서비스는 기본적으로 사용 중지될 수 있습니다. 사용 중지되었는지 확인하려면 다음 명령어를 실행하세요.

  systemctl is-enabled docker
  

• Docker 서비스를 사용 설정하고 즉시 시작하려면 다음 명령어 중 하나를 실행합니다.

  sudo systemctl enable --now docker
  

  sudo systemctl enable /usr/lib/systemd/system/docker.service
  

  출력:

  Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service
  

• 전달자를 시작할 때 다음 명령어를 실행하여 전달자를 자동 다시 시작으로 설정합니다.

  sudo docker run --restart=always `IMAGE_NAME`
  

  IMAGE_NAME은 전달자 이미지 이름입니다.

• Docker 서비스의 상태와 세부정보를 확인하려면 다음 명령어를 실행합니다.

  sudo systemctl status docker
  

  Output:

  ● docker.service - Docker Application Container Engine
      Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
      Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago
  TriggeredBy: ● docker.socket
        Docs: https://docs.docker.com
    Main PID: 263 (dockerd)
        Tasks: 20
      Memory: 100.4M
      CGroup: /system.slice/docker.service
              └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock"
  Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine
  

  Docker에 문제가 있는 경우 Google Security Operations 지원팀에서 문제를 해결하고 디버깅하기 위해 이 명령어의 출력을 요청할 수 있습니다.

Linux에 전달자 설치

이 섹션에서는 Linux 시스템에서 Docker 컨테이너를 사용하여 Google Security Operations 전달자를 설치하는 방법을 설명합니다.

1단계: 전달자 구성 파일 다운로드, 전송 및 설치

Google Security Operations는 운영체제(Linux 또는 Windows)에 맞는 전달자 구성 파일을 제공합니다. 요구사항에 따라 구성 파일을 다운로드할 수 있습니다. 다음 단계를 완료한 후 노트북에서 사용자의 홈 디렉터리 내에 있는 전달자 /opt/chronicle/config 디렉터리로 구성 파일을 전송합니다.

참고: 디렉터리에 원하는 이름을 지정할 수 있습니다. /config 이름은 디렉터리 이름의 예시입니다. 그러나 동일한 디렉터리 이름을 계속 사용해야 합니다.

1. 터미널을 통해 Linux 전달자의 호스트에 연결합니다.

2. Linux 전달자의 호스트에서 새 사용자를 만듭니다.

     adduser USERNAME
     passwd USERNAME
     usermod -aG wheel USERNAME
   

3. Docker 컨테이너를 실행하는 새 사용자의 홈 디렉터리로 디렉터리를 변경합니다.

4. Google Security Operations 전달자 구성 파일을 저장할 디렉터리를 만듭니다.

     mkdir /opt/chronicle/config
   

   참고: 디렉터리 이름 config는 예시입니다. 이 디렉터리에 원하는 이름을 지정할 수 있습니다. 하지만 Docker 실행 명령어를 실행하는 동안 동일한 디렉터리 이름을 사용해야 합니다.

5. 디렉터리를 변경합니다.

     cd /opt/chronicle/config
   

6. 파일이 전송되면 구성 파일이 /opt/chronicle/config 디렉터리에 있는지 확인합니다.

     ls -l
   

2단계: Docker 컨테이너 내에서 전달자 실행

다음 절차를 수행하여 Google Security Operations 전달자를 처음 시작하고 Google Security Operations 컨테이너의 최신 버전으로 업그레이드할 수 있습니다.

--log-opt 옵션은 Docker 1.13부터 제공되었습니다. 이러한 옵션은 컨테이너 로그 파일의 크기를 제한하며, 해당 Docker 버전에서 지원되는 경우에만 사용해야 합니다.

1. 업그레이드할 때는 이전 Docker 실행을 삭제하는 것으로 시작하세요. 다음 예시에서 Docker 컨테이너 이름은 cfps입니다. 아래와 같이 docker pull 명령어를 사용하여 Google Cloud에서 최신 Docker 이미지를 가져옵니다.

   docker stop cfps
   

   docker rm cfps
   

2. Google Cloud에서 최신 Docker 이미지를 가져옵니다.

   docker pull gcr.io/chronicle-container/cf_production_stable
   

3. Docker 컨테이너에서 Google Security Operations 전달자를 시작합니다.

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

전달자 로그 보기

Google Security Operations 전달자 로그를 보려면 다음 명령어를 실행합니다.

  sudo docker logs cfps

로그가 저장되는 파일의 경로를 보려면 다음 명령어를 실행합니다.

docker inspect --format='{{.LogPath}}' CONTAINER_NAME
 

실시간 실행 로그를 보려면 다음 명령어를 실행합니다.

  sudo docker logs cfps -f

로그를 파일에 저장하려면 다음 명령어를 실행합니다.

  sudo docker logs cfps &> logs.txt

전달자 제거

다음 Docker 명령어를 사용하면 Google Security Operations 전달자를 중지하고 제거하거나 삭제할 수 있습니다.

전달자 컨테이너를 중지하거나 제거하려면 다음 명령어를 실행합니다.

    docker stop cfps
  

전달자 컨테이너를 삭제하려면 다음 안내를 따르세요.

    docker rm cfps
  

전달자 업데이트

Google Security Operations 전달자는 두 부분으로 구성되며 다음과 같이 업그레이드됩니다.

• 전달자 번들: 자동으로 업데이트되므로 다시 시작할 필요가 없습니다.

• 전달자 Docker 이미지 - 기존 전달자를 중지하고 2단계에 설명된 대로 새 인스턴스를 시작한 후 수동으로 업데이트됩니다.

중요: 2023년 4월 1일 이후 전달자 Docker 이미지를 업데이트하지 않았으면 2023년 10월 31일 전에 업데이트해야 합니다. 그러면 전달자 번들이 계속 업데이트를 수신할 수 있습니다.

프록시 뒤에 전달자 설치

이 섹션에서는 프록시 뒤에 Google Security Operations 전달자를 설치하는 방법을 설명합니다.

1. 프록시를 사용하도록 머신을 구성합니다.

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

      nameserver = 10.0.0.1
      nameserver = 10.0.0.2
      

   2. 다음 환경 변수를 설정합니다.

      $HTTP_PROXY = http://proxy.example.com:80
      $HTTPS_PROXY = https://proxy.example.com:80
      

2. 프록시를 사용하도록 Docker를 구성합니다.

   1. Docker 서비스의 systemd 삽입형 디렉터리를 만듭니다.

      mkdir /etc/systemd/system/docker.service.d
      

   2. HTTP_PROXY 및 HTTPS_PROXY 환경 변수를 추가하는 /etc/systemd/system/docker.service.d/http-proxy.conf 파일을 만듭니다.

      [Service]
      Environment="HTTP_PROXY=http://proxy.example.com:80/"
      Environment="HTTPS_PROXY=https://proxy.example.com:80/"
      

   3. 변경사항을 플러시합니다.

      $ sudo systemctl daemon-reload
      

   4. 구성이 로드되었는지 확인합니다.

      $ sudo systemctl show --property Environment docker
      Environment=HTTP_PROXY=http://proxy.example.com:80/
      Environment=HTTPS_PROXY=https://proxy.example.com:80/
      

   5. Docker를 다시 시작합니다.

      $ sudo systemctl restart docker
      

3. Google Cloud에서 최신 Google Security Operations 전달자 Docker 이미지를 가져옵니다.

   docker pull gcr.io/chronicle-container/cf_production_stable
   

4. 프록시 환경 변수를 추가하여 Google Security Operations 전달자 컨테이너를 실행합니다.

   docker run \
   --env HTTP_PROXY="http://proxy.example.com:80/" \
   --env HTTPS_PROXY="https://proxy.example.com:80/" \
   --detach \
   --name cfps \
   --restart=always \
   --log-opt max-size=100m \
   --log-opt max-file=10 \
   --net=host \
   -v /opt/chronicle/config:/opt/chronicle/external \
   gcr.io/chronicle-container/cf_production_stable
   

데이터 수집

다음 섹션을 통해 Google Security Operations 인스턴스로 전달되는 여러 유형의 데이터를 수집하도록 Google Security Operations 전달자를 구성할 수 있습니다.

참고: batch_n_bytes에 4MB보다 큰 값을 구성하지 마세요.

Splunk 데이터 수집

Google Security Operations 전달자를 구성하여 Splunk 데이터를 Google Security Operations로 전달할 수 있습니다. Google Cloud는 Splunk의 데이터가 전달되도록 다음 정보를 사용하여 Google Security Operations 전달자를 구성합니다.

• Splunk REST API의 URL(예: https://10.0.113.15:8089).

• 필요한 각 데이터 유형에 대해 데이터를 생성하기 위한 Splunk 쿼리(예: index=dns).

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime

• Google Security Operations 전달자에 Splunk 계정 사용자 인증 정보를 사용할 수 있도록 설정합니다. 이를 위해서는 creds.txt 파일을 만들면 됩니다.

creds.txt 파일을 사용하려면 다음 안내를 따르세요.

1. Splunk 사용자 인증 정보에 대한 로컬 파일을 만들고 이름을 creds.txt로 지정합니다.

   참고: 사용자 인증 정보가 안전하게 저장되었는지 확인하세요. Splunk 사용자 인증 정보를 Google Cloud로 전달하지 마세요.

2. 첫 번째 줄에 사용자 이름을 입력하고 두 번째 줄에 비밀번호를 입력합니다.

   cat creds.txt
   
   myusername
   mypassword
   

3. Google Security Operations 전달자를 사용하여 Splunk 인스턴스에 액세스하려면 creds.txt 파일을 구성 디렉터리(구성 파일이 있는 같은 디렉터리)에 복사합니다. 예를 들면 다음과 같습니다.

   cp creds.txt /opt/chronicle/config/creds.txt
   

4. creds.txt 파일이 적절한 위치에 있는지 확인합니다.

   ls /opt/chronicle/config
   

syslog 데이터 수집

Google Security Operations 전달자는 Syslog 서버로 작동할 수 있습니다. 데이터가 Google Security Operations 전달자에 전달되도록 TCP 또는 UDP 연결을 통한 syslog 데이터 전송을 지원하는 어플라이언스나 서버를 구성할 수 있습니다. 어플라이언스나 서버에서 Google Security Operations 전달자로 전송하는 데이터를 정확하게 제어할 수 있습니다. 그런 다음 Google Security Operations 전달자가 데이터를 Google Security Operations로 전달할 수 있습니다.

FORWARDER_NAME.conf 구성 파일(Google Cloud에서 제공)은 전달되는 각 데이터 유형에 대해 모니터링할 포트(예: 포트 10514)를 지정합니다. 기본적으로 Google Security Operations 전달자는 TCP 및 UDP 연결 모두 허용합니다.

rsyslog 구성

rsyslog를 구성하려면 각 포트의 대상(예: 각 데이터 유형)을 지정해야 합니다. 시스템 문서에서 올바른 문법을 확인합니다. 다음 예시에서는 rsyslog 대상 구성을 보여줍니다.

• TCP 로그 트래픽: dns.* @@192.168.0.12:10514

• UDP 로그 트래픽: dns.* @192.168.0.12:10514

syslog 구성에 TLS 사용 설정

Google Security Operations 전달자에 대한 Syslog 연결에 TLS를 사용 설정할 수 있습니다. Google Security Operations 전달자 구성 파일(FORWARDER_NAME.conf)에서 다음 예시와 같이 직접 생성한 인증서와 인증서 키의 위치를 지정합니다.

인증서	'/opt/chronicle/external/certs/client_generated_cert.pem'
certificate_key	'/opt/chronicle/external/certs/client_generated_cert.key'

표시된 예시에 따라 Google Security Operations 전달자 구성 파일(FORWARDER_NAME.conf)을 다음과 같이 수정합니다.

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

중요 주의 사항:

• TCP 버퍼 사이즈를 구성할 수 있습니다. 기본 TCP 버퍼 사이즈는 64KB입니다.

• connection_timeout의 기본값 및 권장값은 60초입니다. 지정된 시간 동안 연결이 비활성 상태이면 TCP 연결이 종료됩니다.

• 최소 TLS 버전은 입력 요청의 TLS 버전으로 확인됩니다. 입력 요청의 TLS 버전이 최소 TLS 버전보다 커야 합니다. 최소 TLS 버전은 TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3 값 중 하나여야 합니다.

구성 디렉터리 아래에 certs 디렉터리를 만들고 여기에 인증서 파일을 저장할 수 있습니다.

참고: Google Security Operations FORWARDER_NAME.conf 구성 파일에서 udp_address 필드를 삭제하세요. TLS는 전송을 위해 TCP를 사용해야 합니다. 따라서 UDP를 구성할 수 없습니다.

파일 데이터 수집

파일 수집기는 파일에서 로그를 가져오도록 설계되었습니다. 파일이 Docker 컨테이너에 결합되어야 합니다.

단일 로그 파일에서 수동으로 로그를 업로드하려면 이를 사용합니다. 특정 로그 파일의 로그를 백필하는 데 사용될 수 있습니다.

Docker 컨테이너에서 Google Security Operations 전달자를 시작합니다.

  docker run \
    --detach \
    --name cfps \
    --log-opt max-size=100m \
    --log-opt max-file=10 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhostclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

이 Docker 실행 명령어는 로드 볼륨을 컨테이너에 매핑하는 데 중요합니다.

이 예시를 기반으로 Google Security Operations 전달자 구성(FORWARDER_NAME.conf 파일)을 다음과 같이 수정해야 합니다. sample.txt 파일이 /var/log/crowdstrike/falconhostclient 폴더에 있어야 합니다.

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: /opt/chronicle/edr/sample.txt
       filter:

참고: 위와 같이 파일 입력을 설정하는 구성을 만듭니다.

플래그 구성

skip_seek_to_end(부울): 이 플래그는 기본적으로 false로 설정되며 파일 입력에서 입력으로 새 로그 줄만 보냅니다. true로 설정하면 전달자 재시작 중에 모든 이전 로그 줄이 다시 전송됩니다. 이로 인해 로그 중복이 발생합니다. 이 플래그를 true로 설정하면 서비스 중단과 같은 특정 상황에서 유용합니다. 전달자를 다시 시작하면 누락된 로그 줄이 다시 전송되기 때문입니다.

poll(부울): 파일 수집기는 Tail 라이브러리를 사용하여 파일 시스템의 변경사항을 확인합니다. 이 플래그를 true로 설정하면 Tail 라이브러리에서 기본 알림 메서드 대신 폴링 메서드를 사용합니다.

패킷 데이터 수집

Google Security Operations 전달자는 Linux의 libcap을 사용하여 네트워크 인터페이스에서 직접 패킷을 캡처할 수 있습니다. libcap에 대한 자세한 내용은 libcap - Linux 매뉴얼 페이지를 참조하세요.

패킷이 캡처되고 로그 항목 대신 Google Security Operations로 전송됩니다. 패킷 캡처는 로컬 인터페이스에서만 처리됩니다. 시스템에 패킷 캡처를 사용 설정하려면 Google Security Operations 지원팀에 문의하세요.

Google Cloud는 패킷을 캡처할 때 사용되는 Berkeley Packet Filter(BPF) 표현식을 사용하여 Google Security Operations 전달자를 구성합니다(예: 포트 53, localhost 제외). 자세한 내용은 버클리 패킷 필터를 참조하세요.

Kafka 주제에서 데이터 수집

syslog에서와 같이 Kafka 주제에서도 데이터를 수집할 수 있습니다. 소비자 그룹을 활용하여 최대 3개의 전달자를 배포하고 동일한 Kafka 주제에서 데이터를 가져올 수 있습니다. 자세한 내용은 Kafka를 참조하세요.

Kafka 소비자 그룹에 대한 자세한 내용은 https://docs.confluent.io/platform/current/clients/consumer.html을 참조하세요.

예시 구성: Kafka 입력

다음 전달자 구성은 Kafka 주제에서 데이터를 수집하기 위해 전달자를 설정하는 방법을 보여줍니다.

FORWARDER_NAME.conf 파일

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

FORWARDER_NAME_auth.conf 파일

collectors:
- kafka:
      username: user
      password: password
- syslog:

WebProxy 데이터 수집

Google Security Operations 전달자는 Linux의 libcap을 사용하여 네트워크 인터페이스에서 직접 WebProxy 데이터를 캡처할 수 있습니다. libcap에 대한 자세한 내용은 libcap - Linux 매뉴얼 페이지를 참조하세요. 시스템에서 WebProxy 데이터 캡처를 사용 설정하려면 Google Security Operations 지원팀에 문의하세요.

Google Security Operations 전달자 구성(FORWARDER_NAME.conf 파일)을 다음과 같이 수정합니다.

- webproxy:
      common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: any
      bpf: tcp and dst port 80

구성 맞춤설정

다음 표에는 전달자 구성 파일에서 사용되는 중요한 매개변수가 나와 있습니다.

매개변수	설명
data_type	수집기가 수집하고 처리할 수 있는 로그 데이터의 유형입니다.
metadata	메타데이터: 전역 메타데이터를 재정의합니다.
max_file_buffer_bytes	디스크 또는 파일 버퍼에 누적될 수 있는 최대 바이트 수입니다. 기본값은 1073741824로, 1GB입니다.
max_memory_buffer_bytes	메모리 버퍼에 누적될 수 있는 최대 바이트 수입니다. 기본값은 1073741824로, 1GB입니다.
write_to_disk_dir_path	파일 또는 디스크 버퍼에 사용할 경로입니다.
write_to_disk_buffer_enabled	true인 경우 메모리 버퍼 대신 디스크 버퍼가 사용됩니다. 기본값은 false입니다.
batch_n_bytes	데이터가 일괄 처리된 후 수집기로 누적할 수 있는 최대 바이트 수입니다. 기본값은 1048576로, 1MB입니다.
batch_n_seconds	수집기로 수집된 데이터가 일괄 처리된 후 경과된 시간(초)입니다. 기본값은 11초입니다.
data_hint	수집기가 수신할 수 있는 데이터 형식입니다(일반적으로 형식을 설명하는 로그 파일 헤더).

구성 파일에 사용되는 자세한 매개변수 목록은 전달자 구성 필드 및 수집기 구성 필드를 참조하세요.

데이터 압축 전환

로그 압축은 로그를 Google Security Operations로 전송할 때 네트워크 대역폭 소비를 줄여줍니다. 하지만 압축은 CPU 사용을 늘립니다. CPU 사용과 대역폭 사이의 적정 지점은 로그 데이터 유형, 데이터의 압축 가능성, 전달자를 실행하는 호스트에서 CPU 주기 가용성, 네트워크 대역폭 소비 감소 요구와 같은 여러 요인들에 따라 달라집니다.

예를 들어 텍스트 기반 로그는 압축이 잘 되고, 적은 CPU 사용으로도 대역폭을 크게 절약할 수 있습니다. 하지만 원시 패킷의 암호화된 페이로드는 압축이 잘 되지 않고 CPU 사용이 늘어납니다.

기본적으로 로그 압축은 사용 중지되어 있습니다. 로그 압축을 사용 설정하면 대역폭 소비가 줄어들 수 있습니다. 하지만 로그 압축을 사용 설정하면 CPU 사용량이 증가할 수도 있습니다. 이러한 장단점에 주의해야 합니다.

로그 압축을 사용 설정하려면 다음 예시와 같이 Google Security Operations 전달자 구성 파일에서 압축 필드를 true로 설정합니다.

FORWARDER_NAME.conf 파일

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

FORWARDER_NAME_auth.conf 파일

output:
  identity:
    secret_key: |
    {
     "type": "service_account",
...
    }

디스크 버퍼링 구성

디스크 버퍼링을 사용하면 메모리와 달리 디스크를 사용하여 백로그된 메시지를 버퍼링할 수 있습니다. 전달자 또는 기본 호스트가 비정상 종료되는 경우를 대비하여 백로그된 메시지를 저장할 수 있습니다. 디스크 버퍼링을 사용 설정하면 성능에 영향을 줄 수 있습니다.

참고: '일괄 처리 작업자 한도(xxx)에 도달하여 백로그에서 배치가 해제됩니다'라는 오류 메시지가 표시되면 max_file_buffer_bytes를 1GB 이상으로 늘립니다.

디스크 버퍼링이 사용 중지되면 전달자는 각 로그 유형(예: 커넥터별)에 1GB 메모리(RAM)를 사용합니다. max_memory_buffer_bytes 구성 매개변수를 지정합니다. 허용되는 최대 메모리는 4GB입니다.

수집기에서 동적으로 공유된 버퍼를 사용하도록 자동 메모리 버퍼링을 구성하면 트래픽 급증을 더 효과적으로 처리할 수 있습니다. 동적으로 공유된 버퍼를 사용 설정하려면 전달자 구성에 다음을 추가합니다.

auto_buffer:
  enabled: true
  target_memory_utilization: 80

자동 디스크 버퍼링이 사용 설정되었지만 target_memory_utilization이 정의되지 않은 경우 기본값 70이 사용됩니다.

Docker를 사용하여 전달자를 실행하는 경우에는 격리 목적으로 구성 볼륨과 다른 볼륨을 마운트하는 것이 좋습니다. 또한 충돌 방지를 위해 고유 디렉터리 또는 볼륨을 사용하여 각 입력을 격리해야 합니다.

예시 구성: 디스크 버퍼링

다음 구성에는 디스크 버퍼링을 사용 설정하기 위한 문법이 포함되어 있습니다.

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

정규 표현식 필터 설정

정규 표현식 필터를 사용하면 원시 로그에 대한 정규 표현식 일치를 기준으로 로그를 필터링할 수 있습니다.

필터는 여기에 설명된 RE2 문법이 사용됩니다(https://github.com/google/re2/wiki/Syntax).

필터는 정규 표현식을 포함해야 하며, 선택적으로 일치 항목이 있을 때의 동작을 정의할 수 있습니다. 일치 항목이 있을 때의 기본 동작은 차단이며, 동작을 명시적으로 차단으로 구성할 수도 있습니다.

도는 allow 동작으로 필터를 지정할 수 있습니다. allow 필터를 지정하는 경우 하나 이상의 allow 필터와 일치하지 않는 모든 로그가 전달자에서 차단됩니다.

필터는 원하는 만큼 정의할 수 있습니다. 차단 필터는 allow 필터보다 우선 적용됩니다.

필터를 정의할 때는 여기에 이름을 지정해야 합니다. 활성 필터 이름은 전달자 상태 측정항목을 통해 Google Security Operations에 보고됩니다. 구성 루트에 정의된 필터는 수집기 수준에서 정의된 필터와 병합됩니다. 이름이 충돌하는 경우 수집기 수준 필터가 우선 적용됩니다. 루트 또는 수집기 수준에 정의된 필터가 없으면 행동이 항상 모두 허용입니다.

예시 구성: 정규 표현식 필터

다음 전달자 구성에서 루트 필터(allow_filter)와 일치하지 않는 WINEVTLOG 로그는 차단됩니다. 이 정규 표현식을 사용할 때 필터는 우선순위가 0~99 사이인 로그만 허용합니다. 하지만 'foo' 또는 'bar'가 포함된 모든 NIX_SYSTEM 로그는 allow_filter에도 불구하고 차단됩니다. 이것은 필터에 논리적 OR이 사용되기 때문입니다. 필터가 트리거될 때까지 모든 로그가 처리됩니다.

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

임의 라벨 구성

라벨은 키 및 값 쌍을 사용하여 임의 메타데이터를 로그에 연결하기 위해 사용됩니다. 라벨은 전체 전달자에 대해 또는 전달자의 특정 수집기 내에서 구성될 수 있습니다. 둘 다 제공된 경우 라벨이 수집기의 키와 병합되고 키가 겹치는 경우 전달자의 키보다 우선 적용됩니다.

예시 구성: 임의 라벨

다음 전달자 구성에서 'foo=bar' 및 'meow=mix' 키와 값 쌍은 모두 WINEVTLOG 로그에 연결되고 'foo=baz' 및 'meow=mix' 키와 값 쌍은 NIX_SYSTEM 로그에 연결됩니다.

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

네임스페이스 구성

네임스페이스 라벨을 사용하면 고유 네트워크 세그먼트에서 로그를 식별하고 겹치는 IP 주소의 충돌을 해결할 수 있습니다. 전체 전달자에 대해 또는 전달자의 특정 수집기 내에서 네임스페이스 라벨을 구성할 수 있습니다. 둘 모두 포함된 경우 특정 수집기의 네임스페이스가 우선 적용됩니다.

전달자용으로 구성된 모든 네임스페이스는 Google Security Operations 사용자 인터페이스에 연결된 애셋과 함께 표시됩니다. 또한 Google Security Operations 검색 기능을 사용하여 네임스페이스를 검색할 수 있습니다.

Google Security Operations 사용자 인터페이스에서 네임스페이스를 보는 방법은 여기를 참조하세요.

예시 구성: 네임스페이스

다음 전달자 구성에서 WINEVTLOG 로그는 FORWARDER 네임스페이스에 연결되고 NIX_SYSTEM 로그는 CORPORATE 네임스페이스에 연결됩니다.

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

부하 분산 및 고가용성 옵션 구성

Linux용 Google Security Operations 전달자를 데이터 소스와 전달자 인스턴스 사이에 Layer 4 부하 분산기가 설치된 환경에 배포할 수 있습니다. 이렇게 하면 고객은 여러 전달자에 로그 수집을 배포하거나 장애가 발생한 경우 로그를 다른 전달자로 전송할 수 있습니다. 이 기능은 syslog 수집 유형에서만 지원됩니다.

Linux 전달자에는 부하 분산기의 HTTP 상태 점검에 응답하는 HTTP 서버가 내장되어 있습니다. 또한 HTTP 서버는 전달자를 시작하거나 종료하는 동안 로그가 손실되지 않도록 합니다.

전달자 구성 파일의 서버 섹션에서 HTTP 서버, 부하 분산, 고가용성 옵션을 구성합니다. 이러한 옵션에서 컨테이너 스케줄러, 조정 기반 배포 및 기존 부하 분산기에서 수신된 상태 확인에 대한 응답으로 반환되는 제한 시간 기간과 상태 코드를 설정할 수 있습니다.

상태, 준비, 활성 확인에 다음 URL 경로를 사용합니다. <host:port> 값은 전달자 구성에서 정의됩니다.

• http://<host:port>/meta/available: 컨테이너 스케줄러 또는 조정자의 활성 확인
• http://<host:port>/meta/ready: 준비 확인 및 기존 부하 분산기 상태 확인

다음 전달자 구성은 부하 분산과 고가용성의 예시입니다.

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503

구성 경로	설명
server : graceful_timeout	전달자가 잘못된 준비/상태 확인을 반환하고 새 연결을 수락하는 시간입니다. 또한 중지 신호를 수신하고 실제로 서버 자체의 종료를 시작하기까지 기다리는 시간입니다. 이렇게 하면 부하 분산기 시간이 풀에서 전달자를 삭제할 수 있습니다.
server : drain_timeout	전달자가 서버에서 연결을 닫기 전에 활성 연결이 성공적으로 종료될 때까지 대기하는 시간입니다.
server : http : port	HTTP 서버가 부하 분산기에서 상태 점검을 리슨하는 포트 번호입니다. 1,024에서 65,535 사이여야 합니다.
server : http : host	서버가 리슨할 IP 주소 또는 IP 주소로 변환할 수 있는 호스트 이름입니다. 비워 두면 기본값은 로컬 시스템(0.0.0.0)입니다.
server : http : read_timeout	HTTP 서버를 조정하는 데 사용됩니다. 일반적으로 기본 설정에서 변경할 필요가 없습니다. 헤더와 본문 등 전체 요청을 읽을 수 있는 최대 시간입니다. read_timeout과 read_header_timeout 모두 설정할 수 있습니다.
server : http : read_header_timeout	HTTP 서버를 조정하는 데 사용됩니다. 일반적으로 기본 설정에서 변경할 필요가 없습니다. 요청 헤더를 읽을 수 있는 최대 시간입니다. 헤더를 읽으면 연결의 읽기 기한이 재설정됩니다.
server : http : write_timeout	HTTP 서버를 조정하는 데 사용됩니다. 일반적으로 기본 설정에서 변경할 필요가 없습니다. 응답을 보낼 수 있는 최대 시간입니다. 새 요청 헤더를 읽으면 재설정됩니다.
server : http : idle_timeout	HTTP 서버를 조정하는 데 사용됩니다. 일반적으로 기본 설정에서 변경할 필요가 없습니다. 유휴 연결이 사용 설정된 경우 다음 요청을 기다리는 최대 시간입니다. idle_timeout이 0인 경우 read_timeout의 값이 사용됩니다. 둘 다 0이면 read_header_timeout이 사용됩니다.
routes : meta : ready_status	다음 상황 중 하나에서 트래픽을 허용할 수 있는 경우에 전달자가 반환하는 상태 코드입니다. 준비 확인은 컨테이너 스케줄러 또는 조정자에서 수신됩니다. 상태 점검은 기존 부하 분산기에서 수신합니다.
routes : meta : unready_status	트래픽을 허용할 수 없는 경우에 전달자가 반환하는 상태 코드입니다.
routes : meta : available_status	활성 확인이 수신되고 전달자를 사용할 수 있는 경우에 전달자가 반환하는 상태 코드입니다. 컨테이너 스케줄러 또는 조정자가 활성 확인을 보내는 경우가 많습니다.

자주 묻는 질문(FAQ)

전달자를 업데이트하려면 어떻게 해야 하나요?

Linux 전달자는 Docker 이미지에서 셸 스크립트를 통해 지속적으로 업데이트됩니다. Docker 이미지를 업데이트하려면 전달자를 실행합니다.

Docker 컨테이너란 무엇인가요?

• Docker 컨테이너는 추가적인 보안, 격리, 리소스 관리를 제공하는 가상 머신과 유사합니다.

• 가상 머신 — 권한이 있는 공간(Linux 커널)과 사용자 공간(libc, python, ls, tcpdump 등을 사용하는 모든 것)이 있습니다.

• 컨테이너 - 사용자 공간(libc, python, ls, tcpdump 등을 사용하는 모든 것)만 있고 호스트의 권한 공간이 필요합니다.

컨테이너를 사용하여 Google Security Operations 전달자를 배포하는 이유는 무엇인가요?

• 격리를 통한 보안 향상:
  • 고객 환경과 요구사항은 Google Security Operations 전달자에 영향을 주지 않습니다.
  • Google Security Operations 전달자 환경과 요구사항은 고객에게 영향을 주지 않습니다.
  • 컨테이너 배포 메커니즘은 이미 존재하며 비공개일 수 있고 Google Cloud 및 고객에 대해 별개일 수 있습니다. https://cloud.google.com/container-registry/

고급 Docker 명령어를 배워야 하나요?

• Google Security Operations 전달자는 단일 컨테이너를 사용하므로 Swarm, 조정 또는 기타 고급 Docker 개념이나 명령어를 배울 필요가 없습니다.