Linux & 클라우드 탐지 엔지니어링 - 컨테이너용 Defend(D4C) 시작하기

서문

Linux 시스템은 특히 컨테이너와 오케스트레이션 플랫폼이 표준인 클라우드 네이티브 환경에서 최신 인프라의 중요한 기반으로 남아 있습니다. 워크로드가 수명이 긴 호스트에서 임시 컨테이너로 이동함에 따라 공격자의 수법도 변화하고 있습니다. 디스크에 영구적인 아티팩트를 남기던 활동은 점점 더 기존 로그 소스로 캡처하기 어려운 단기간의 런타임 동작에 국한되고 있습니다.

따라서 이러한 환경에서의 탐지 엔지니어링은 런타임 가시성에 크게 의존합니다. 정적 지표나 사고 후 아티팩트에 의존하는 것보다 컨테이너 내에서 프로세스가 실행되는 방식, 파일 액세스 방식, 워크로드가 호스트와 상호 작용하는 방식을 이해하는 것이 더 중요해집니다.

Elastic은 이러한 유형의 탐지 작업을 지원하기 위해 몇 가지 Linux 중심 원격 분석 소스를 제공합니다. 이 시리즈의 이전 포스팅에서는 낮은 수준의 시스템 이벤트가 어떻게 높은 정확도의 탐지로 변환될 수 있는지 보여드리기 위해 Auditd 및 Auditd Manager를 사용한 호스트 수준의 가시성에 중점을 두었습니다. 이 포스팅에서는 컨테이너화된 Linux 워크로드를 위해 특별히 구축된 런타임 보안 통합인 Elastic의 Defend for Containers에 초점을 맞추고 있습니다.

이 문서의 목표는 컨테이너용 방어의 모든 기능을 문서화하는 것이 아니라 탐지 엔지니어에게 통합이 생성하는 데이터와 해당 데이터를 추론하는 방법 등 실질적인 시작점을 제공하는 것입니다. 다음 파트에서는 이를 실제 컨테이너 공격 시나리오에 어떻게 적용할 수 있는지 살펴보겠습니다.

컨테이너용 Defend로 가시성 간소화

9.3.0 버전에 컨테이너용 Defend를 출시하게 되어 기쁘게 생각합니다. 릴리스합니다. 이 통합으로 컨테이너 보안에 대한 접근 방식이 간소화되어 클라우드 네이티브 인프라의 가시성을 위한 강력한 기반을 제공합니다. 사용자는 최신 Kubernetes 위협과 컨테이너별 취약성을 방어하기 위해 맞춤화된 탐지 규칙 모음을 활용할 수 있습니다. 컨테이너용 Defend의 출시와 함께 실제 컨테이너 및 Kubernetes 위협 모델을 중심으로 설계된 컨테이너 전용 탐지 규칙 집합이 함께 제공됩니다.

이 글을 쓰는 현재, 컨테이너를 위한 방어 규칙 세트는 정찰 활동, 자격 증명 액세스 시도, kubelet 공격, 서비스 계정 토큰 악용, 대화형 프로세스 실행, 파일 생성 및 수정, 인터프리터 악용, 인코딩된 페이로드 실행, 툴링 설치, 터널링 동작, 여러 권한 상승 벡터 등 일반적인 컨테이너 공격 기술에 대한 기본 범위를 제공하고 있습니다. 중요한 것은 기존의 모든 컨테이너 및 Kubernetes 관련 탐지 규칙이 컨테이너용 Defend와 호환되도록 만들어져, 이전에 호스트 중심이었던 로직이 컨테이너 런타임 원격 분석에서 직접 작동할 수 있게 되었다는 점입니다.

따라서 행동 기반 런타임 탐지에 중점을 둔 Linux 탐지 엔지니어에게 Defend for Containers는 실용적이고 즉시 사용할 수 있는 데이터 소스입니다. 이 글의 나머지 부분에서는 원격 분석이 실제로 어떻게 보이는지, 그리고 실제 컨테이너 공격 시나리오에 어떻게 적용할 수 있는지에 초점을 맞추고 있습니다.

컨테이너용 디펜스 소개

컨테이너용 Defend는 실행 중인 Linux 컨테이너에 대한 가시성을 제공하는 런타임 보안 통합 기능입니다. 정적 이미지 스캔이나 실행 후 로그에 의존하는 대신 컨테이너 동작을 실시간으로 관찰하는 데 중점을 둡니다.

높은 수준에서 Defend for Containers는 실행 중인 컨테이너에서 프로세스 실행 및 파일 액세스와 같은 보안 관련 런타임 이벤트를 캡처합니다. 이러한 이벤트는 컨테이너와 오케스트레이션 컨텍스트로 보강되어 Elasticsearch로 전송되어 분석하고 탐지 규칙의 입력으로 사용할 수 있습니다.

탐지 엔지니어링 관점에서 볼 때, 컨테이너용 Defend는 기존 Linux 동작과 컨테이너 컨텍스트가 교차하는 지점에 위치합니다. 프로세스, 시스템 호출, 파일 활동은 여전히 핵심 신호이지만 이제 컨테이너, 네임스페이스, 잠깐만 존재할 수 있는 워크로드로 범위가 제한됩니다.

컨테이너용 Defend는 Elastic 에이전트의 일부로 배포되며 Elastic Security와 직접 통합됩니다. 이 기능을 활성화하면 KQL 또는 ES|QL을 사용하여 쿼리하거나 탐지 분석에서 직접 사용할 수 있는 컨테이너 런타임 이벤트 전용 스트림을 제공합니다. 이를 통해 탐지 엔지니어는 익숙한 분석 기법을 적용하면서 클라우드 네이티브 워크로드의 운영 현실을 고려할 수 있습니다.

다음 섹션에서는 컨테이너에 대한 방어 이벤트를 자세히 살펴보고 몇 가지 컨테이너 공격 시나리오를 통해 이 데이터를 실제로 어떻게 사용할 수 있는지 설명합니다.

컨테이너용 방어 설정

컨테이너용 Defend의 런타임 가시성 및 분석을 활용하려면 먼저 통합을 배포하고 관찰할 이벤트와 일치하는 활동이 발견될 때 취할 조치를 정의하는 정책을 구성해야 합니다. 통합 및 설정에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 이 설정은 크게 다음과 같이 구성됩니다:

Kubernetes 환경에서 Elastic 에이전트를 통해 컨테이너용 Defend 통합 배포하기.
일치시킬 작업을 정의하는 선택기와 수행할 작업을 정의하는 응답으로 구성된 컨테이너에 대한 방어 정책을 구성하거나 사용자 지정합니다.
관찰된 워크로드 동작을 기반으로 정책을 검증하고 개선합니다.

배포 방법

컨테이너를 위한 방어는 Elastic 에이전트 통합으로 제공되며, 컨테이너 런타임 원격 분석을 수집하고 Elastic Stack으로 전달하기 위해 Elastic 에이전트에 의존합니다. Kubernetes 워크로드의 경우, Elastic Security UI를 통해 통합을 설치한 다음 클러스터 노드에 에이전트를 등록합니다.

기본 배포 흐름은 다음과 같습니다:

Elastic Security UI에서 Fleet으로 이동하여 새 에이전트 정책을 생성하거나 기존 정책에 통합을 추가합니다. 에이전트 정책이 생성되면 정책에 '컨테이너에 대한 방어' 통합 기능을 추가할 수 있습니다.

통합에 이름을 지정하고 선택적으로 기본 선택기와 응답을 조정할 수 있습니다(이 게시물의 뒷부분에서 사용 가능한 옵션에 대해 자세히 살펴보겠습니다). "연동 서비스 추가"를 선택하면 올바른 연동 서비스가 포함된 새 상담원 정책을 사용할 수 있습니다.

이 데모에서는 Kubernetes 배포 방법을 활용합니다. 이 정책을 워크로드에 배포하려면 작업 → 에이전트 추가 → Kubernetes로 이동하면 됩니다. 여기에는 Kubernetes 매니페스트 복사 또는 다운로드에 대한 지침이 나와 있습니다.

주의해야 할 중요한 사항은 "다음 매니페스트에는 프로덕션 환경에 적합하지 않을 수 있는 리소스 제한이 포함되어 있다는 점에유의하세요.이 매니페스트를 배포하기 전에 Kubernetes에서 Elastic 에이전트 확장에 대한 가이드를 검토하세요."

서비스가 작동하려면 다음 capabilities 을 securityContext 아래에 포함시켜야 합니다:

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

제공된 elastic-agent-managed-kubernetes.yml 매니페스트를 복사하거나 다운로드한 후 필요에 따라 매니페스트를 편집하고 다음을 사용하여 매니페스트를 적용할 수 있습니다:

kubectl apply -f elastic-agent-managed-kubernetes.yml

매니페스트에서도 언급했듯이, 자세한 배포 정보는 "Fleet에서 관리하는 Kubernetes에서 Elastic 에이전트 실행" 가이드를 참조하세요.

Elastic 에이전트 포드가 스케줄링되고 데이터가 Elasticsearch로 유입되기 시작할 때까지 기다리세요.

배포가 완료되면 Elastic Agent는 Fleet에 연결을 설정하고 선택한 정책에 따라 등록한 다음 Elastic Security가 사용할 수 있는 Defend for Containers 원격 분석을 전송하기 시작합니다.

다음 섹션에서는 연동 구성 옵션을 살펴보고 어떤 기능을 사용할 수 있는지 살펴보겠습니다.

컨테이너에 대한 방어 정책

컨테이너를 위한 방어 구성의 핵심은 정책입니다. 정책에 따라 관찰할 활동과 일치하는 이벤트가 발생할 때 대응하는 방법이 결정됩니다. 정책은 두 가지 기본 구성 요소로 이루어져 있습니다:

선택기: 작업 및 조건을 지정하여 관심 있는 이벤트를 정의합니다;
응답: 선택기의 조건이 충족될 때 수행할 작업을 정의합니다.

컨테이너용 Defend 정책은 배포 전에 편집하거나 배포 후 Elastic Security UI의 정책 편집기를 통해 수정할 수 있습니다.

정책 구조

각 정책에는 적어도 하나의 선택기와 적어도 하나의 응답이 포함되어야 합니다. 일반적인 선택기는 하나 이상의 작업(예: 프로세스 이벤트 또는 파일 활동)을 지정하고 조건(예: 컨테이너 이미지 이름, 네임스페이스 또는 파드 레이블)을 사용하여 범위를 좁힙니다. 응답은 선택기를 참조하고 이벤트가 일치할 때 취할 조치를 나타냅니다.

기본 컨테이너에 대한 방어 정책에는 두 개의 선택기-응답 쌍이 포함되어 있습니다: "위협 탐지" 및 "드리프트 탐지 & 예방".

위협 탐지: allProcesses 이라는 이름의 selector 는 컨테이너의 모든 fork 및 exec 이벤트와 일치합니다.

그리고 연결된 response 에는 Log 으로 액션이 설정되어 이벤트가 수집되고 분석될 수 있도록 합니다.

드리프트 감지 & 예방: executableChanges 라는 선택기가 createExecutable 및 modifyExecutable 작업과 일치합니다.

그리고 응답은 경고를 생성하도록 구성되며, 이러한 작업을 차단하도록 수정할 수 있습니다.

이러한 정책은 UI를 통해 수정할 수 있지만, 내부적으로는 모든 CI|CD 흐름에서 쉽게 수정하고 사용할 수 있는 간단한 YAML 구성 파일입니다:

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

다음으로 몇 가지 예제 선택기와 응답을 살펴보고 원하는 대로 통합을 설정할 수 있는 옵션에 대해 논의하겠습니다.

선택기 스니펫 예시

선택기를 사용하면 다음과 같은 필드에 조건을 사용하여 세분화된 매칭을 수행할 수 있습니다:

containerImageFullName와 같은 전체 이미지 이름 docker.io/nginx;
containerImageName: 부분 이미지 이름;
containerImageTag최신과 같은 특정 태그;
kubernetesClusterId: 쿠버네티스 클러스터 ID;
kubernetesClusterName: 쿠버네티스 클러스터 이름;
kubernetesNamespace워크로드가 실행되는 네임스페이스입니다;
kubernetesPodName: 포드 이름, 후행 와일드카드 지원;
kubernetesPodLabel와일드카드 지원으로 키/값 쌍에 레이블을 지정합니다.

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

이 예제에서 nodeExports 라는 선택기는 이미지 이름에 "nginx"가 포함되고 Kubernetes 네임스페이스가 “prod-” 로 시작하는 컨테이너 내에서 실행 파일을 생성하거나 수정하는 파일 이벤트와 일치한다.

응답 스니펫 예시

응답은 선택기 조건이 충족될 때 어떤 일이 발생하는지 결정합니다. 일반적인 작업에는 다음이 포함됩니다:

log: 분석을 위해 이벤트를 원격 분석으로 보냅니다;
alert를 클릭해 Elastic Security에서 경보를 생성하세요;
block: 작동을 방지합니다(지원되는 유형의 경우).

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

여기서 alertAndBlockNodeExports 이라는 응답은 이전에 정의된 nodeExports 선택기를 참조하며 경고를 생성하고 작업을 차단합니다.

와일드카드 및 매칭

컨테이너에 대한 방어의 선택기는 문자열 기반 조건(예: 포드 이름 또는 이미지 태그)에서 후행 와일드카드를 지원합니다. 이렇게 하면 가능한 모든 값을 열거하지 않고도 광범위하게 일치시킬 수 있습니다. 예를 들어, backend-* 의 파드 셀렉터는 이름이 backend- 으로 시작하는 모든 파드와 일치하고, role:api* 과 같은 레이블 조건은 api 으로 시작하는 레이블 값과 일치한다.

이 와일드카드는 워크로드가 빠르게 확장되고 이동하는 동적 환경에서 필수적입니다.

컨테이너에 대한 방어 선택기는 단순한 문자열 일치 외에도 파일 경로를 일치시킬 때 경로 기반 와일드카드 시맨틱도 지원합니다. 다음 선택기 예시를 살펴보세요:

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

이 예시에서는 다음과 같이 사용됩니다.

/usr/bin/echo 는 해당 경로의 echo 바이너리만 일치합니다.
/usr/sbin/* 의 직계 자식인 /usr/sbin 의 모든 항목과 일치합니다.
/usr/local/** 는 /usr/local/bin/something 과 같은 경로를 포함하여 /usr/local 에서 재귀적으로 모든 것을 일치시킵니다.

이러한 구분을 통해 파일 기반 선택기의 범위를 정확하게 지정하여 적용 범위와 노이즈의 균형을 맞출 수 있습니다. 실제로 탐지 엔지니어는 지나치게 허용적인 규칙을 사용하지 않고도 사용 사례에 따라 특정 바이너리, 전체 디렉토리 또는 심층 디렉토리 트리를 대상으로 지정할 수 있습니다.

모든 것을 하나로 묶기

지금까지 컨테이너에 대한 방어 선택기, 와일드카드 의미론, 이벤트 유형 및 런타임에 공격자의 행동을 드러내는 방법에 대해 살펴보았습니다. 마지막 단계는 이러한 요소들이 정책 내에서 어떻게 결합되어 실제 탐지 로직을 표현하는지 이해하는 것입니다.

다음 정책 조각을 고려하세요:

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

이 정책에는 세 가지 선택기가 정의되어 있습니다. 두 개의 선택기(binDirExeMods 및 etcFileChanges)는 관심 있는 파일 시스템 활동을 설명하고, 세 번째 선택기(nginx)는 제외할 컨테이너 컨텍스트를 설명합니다.

응답 섹션은 이러한 선택기를 하나로 묶습니다. match 아래에 나열된 선택기는 논리적으로 OR'd'로, 두 조건 중 하나만 충족해도 응답을 트리거할 수 있습니다. exclude 아래에 나열된 선택기는 논리적 NOT 으로 작동하여 컨테이너 이미지가 nginx 일 때 일치하는 이벤트를 제거합니다.

이 정책을 일반 언어로 읽으면 다음과 같은 논리를 표현합니다:

/usr/bin 에서 실행 파일이 생성 또는 수정되거나 /etc 에서 파일이 생성, 수정 또는 삭제되고 해당 활동이 nginx 컨테이너에서 시작되지 않은 경우 경고를 생성하고 해당 작업을 차단합니다.

이를 부울 형식으로 표현하면 다음과 같습니다:

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

바로 이 지점에서 컨테이너를 위한 방어 정책이 강력해집니다. 쿼리 언어로 복잡한 탐지 로직을 작성하는 대신 셀렉터를 사용하면 동작을 재사용 가능한 작은 빌딩 블록으로 분해한 다음 선언적으로 결합할 수 있습니다. 경로 기반 선택기, 작업 유형, 컨테이너 컨텍스트 및 제외를 혼합하여 미묘한 감지 로직을 가독성 및 유지 관리가 가능한 상태로 표현할 수 있습니다.

실제로 이 모델을 사용하면 탐지 엔지니어가 위협 가설( 어떤 행동이 중요한지, 어디서 발생하는지, 어떤 워크로드에서 발생하는지, 발생하면 어떻게 해야 하는지 등)을 정책 로직으로 직접 변환할 수 있습니다.

정책 검증 및 개선

정책을 배포한 후에는 차단과 같은 공격적인 대응을 활성화하기 전에 실제 워크로드 동작에 대해 정책을 검증하는 것이 중요합니다. 너무 제한적인 정책은 정상적인 컨테이너 운영을 방해할 수 있고, 너무 허용적인 정책은 원치 않는 활동을 눈치채지 못하게 할 수 있습니다.

권장되는 워크플로는 다음과 같습니다:

모니터링 모드에서 기본 정책을 배포합니다(예: 이벤트를 로깅하는 선택기 사용).
Elasticsearch에 나타나는 이벤트를 관찰하여 정상적인 워크로드 패턴을 파악하세요.
로그 전용 → 경고 → 차단으로 단계적으로 선택기와 응답을 강화하여 각 단계에서 테스트합니다.
스테이징 또는 테스트 클러스터를 사용하여 차단 동작을 프로덕션에 적용하기 전에 검증하세요.

컨테이너용 디펜스 베타 제한 사항

이 글을 쓰는 현재 컨테이너용 Defend는 베타 통합 버전으로 제공되며, 현재 기능 및 플랫폼 지원은 이러한 상태를 반영합니다.

디펜드 포 컨테이너는 공식적으로 Amazon EKS와 Google GKE를 지원합니다. 이 통합은 Azure AKS에 배포할 수 있지만 이 구성은 공식적으로 지원되지 않습니다. 특히, 현재 AKS 배포에는 파일 이벤트 원격 분석 기능이 없기 때문에 이러한 환경에서는 파일 기반 공격 기법에 대한 탐지 범위가 제한됩니다.

현재 베타 버전은 네트워크 이벤트도 캡처하지 않습니다. 따라서 아웃바운드 연결, 측면 네트워크 이동 또는 데이터 유출과 관련된 탐지는 Defend for Containers 원격 분석에만 의존하지 말고 Network Packet Capture 통합 또는 Packetbeat 통합과 같은 보완적인 데이터 소스를 사용해야 합니다.

파일 활동의 경우, 컨테이너를 위한 방어는 쓰기 의도로 파일을 열었을 때만 파일 열기 이벤트를 의도적으로 기록합니다. 이 설계 선택은 노이즈를 줄이고 시스템 상태를 수정하는 동작에 집중합니다. 그러나 비밀 검색, 구성 스크래핑 또는 액세스 시도 실패와 같은 민감한 파일에 대한 읽기 전용 액세스는 현재 관찰할 수 없다는 의미이기도 합니다.

이 제한은 다음과 같은 탐지 사용 사례에 영향을 미칩니다:

쿠버네티스 서비스 계정 토큰 검색 및 읽기,
.env 파일 또는 자격 증명 자료를 검색합니다.

이러한 영역은 향후 디펜드 포 컨테이너 반복을 통해 고급 탐지 엔지니어링 사용 사례를 지원하기 위해 보다 세분화된 원격 분석을 제공할 수 있는 영역입니다.

컨테이너에 대한 방어 사전 구축 탐지 규칙 활성화하기

컨테이너용 방어는 일반적인 컨테이너 공격 기법에 대한 기본 범위를 제공하는 사전 구축된 탐지 규칙 세트를 제공합니다. 통합이 활성화되면 이러한 규칙은 추가 구성 없이 Elastic Security에서 바로 활성화할 수 있습니다.

사전 빌드된 규칙은 컨테이너용 Defend의 런타임 원격 분석과 일치하고 컨테이너 내부의 실행, 파일 수정, 지속성 및 손상 후 동작을 포함하도록 설계되었으므로 시작점으로 활성화하는 것을 권장합니다. 여기에서 환경별 워크로드 및 위협 모델에 맞게 규칙을 확장하거나 세분화할 수 있습니다.

"데이터 소스: 컨테이너용 Elastic Defend"로 필터링하면 이 통합과 관련된 모든 규칙을 찾을 수 있습니다.

참고: 규칙이 표시되지 않으면 스택이 9.3.0 버전으로 실행되고 있는지 확인하세요, 이 규칙은 9.3.0 이상에만 배포되므로 9.3.0 이상에 배포해야 합니다.

모든 중요한 베타 제한 사항이 매핑되고, 통합이 배포되고, 사전 구축된 탐지 규칙이 설치 및 활성화되고, 작동 정책이 마련되면 다음 단계는 탐지 로직에서 일반적으로 사용되는 필드, 성능 고려 사항, 이러한 이벤트가 Elastic Defend 이벤트와 어떻게 다른지 등 컨테이너용 Defend가 생성하는 이벤트 의미론을 살펴보는 것입니다.

컨테이너에 대한 방어 이벤트 분석하기

이제 컨테이너용 Defend가 배포되고 정책이 적용되었으므로 다음 단계는 생성되는 이벤트를 이해하는 것입니다. Elastic Defend 또는 Auditd Manager로 작업할 때와 마찬가지로, 이벤트가 어떻게 구조화되고 탐지 엔지니어링에 가장 적합한 필드가 무엇인지에 대한 정신 모델을 개발하면 Defend for Containers 원격 분석의 가치가 훨씬 더 높아집니다.

컨테이너용 Defend는 여러 이벤트 유형, 특히 프로세스 이벤트와 파일 이벤트를 생성하며, 각각 컨테이너, 호스트 및 오케스트레이션 컨텍스트가 강화되어 있습니다. 기본 신호는 Linux 동작에 뿌리를 두고 있지만, 추가 Kubernetes 및 컨테이너 메타데이터를 사용하면 호스트 전용 원격 분석으로는 불가능한 방식으로 활동을 추론할 수 있습니다.

다음 섹션에서는 실제 컨테이너용 방어 이벤트를 기준으로 가장 중요한 필드 그룹과 이벤트 유형을 살펴봅니다.

공통 필드

특정 이벤트 카테고리에 대해 자세히 알아보기 전에 Defend for Containers 원격 분석에서 일관되게 나타나는 필드를 이해하는 것이 유용합니다. 이러한 필드는 개별 런타임 작업을 정책, 선택기 및 커널 내부의 기본 실행 지점에 다시 연결하는 컨텍스트 접착제를 제공합니다.

프로세스 이벤트와 파일 이벤트의 세부 사항은 다르지만, 아래에 설명된 필드는 Defend for Containers 데이터 스트림 전체에 존재하며 탐지의 유효성을 검사하거나 정책 동작 문제를 해결할 때 가장 먼저 살펴봐야 할 곳입니다.

컨테이너별 컨텍스트에 대한 방어

컨테이너를 위한 방어는 이벤트 수집 및 정책 적용 방식과 관련된 몇 가지 필드를 추가합니다.

cloud_defend.hook_point 필드는 커널에서 이벤트가 캡처된 위치를 나타냅니다. 표시된 예에서 tracepoint__sched_process_fork 및 tracepoint__sched_process_exec 같은 값은 이벤트가 프로세스 생성 및 실행과 관련된 커널 트레이스포인트에서 생성되었음을 나타냅니다.

cloud_defend.matched_selectors 필드에는 활성 정책에서 이벤트와 일치하는 선택자가 표시됩니다. 이 예에서 allProcesses 값은 이 이벤트가 모든 프로세스 활동을 캡처하는 광범위한 선택기와 일치했음을 나타냅니다. 정책을 조정하거나 알림을 조사할 때 이 필드는 이벤트가 캡처된 이유를 이해하는 데 필수적입니다.

cloud_defend.package_policy_id 및 cloud_defend.package_policy_revision 필드는 이벤트를 특정 Elastic 에이전트 정책 및 해당 개정에 다시 연결합니다. 이를 통해 시간 경과에 따른 구성 변경 사항과 이벤트의 상관관계를 파악하고 이벤트가 발생했을 때 어떤 버전의 정책이 활성화되어 있었는지 확인할 수 있습니다.

이벤트 메타데이터

컨테이너를 위한 방어 이벤트는 Elastic 공통 스키마 규칙을 따르며 활동의 유형과 수명 주기를 설명하는 표준 이벤트 메타데이터를 포함합니다.

event.category 필드는 process 또는 file 와 같은 상위 수준의 활동 유형을 식별하며, 일반적으로 Defend for Containers 데이터를 필터링할 때 가장 먼저 사용되는 필드입니다. event.action 필드에는 프로세스 활동의 경우 fork 또는 exec, 파일 이벤트의 경우 open, creation, modification 및 deletion 과 같이 발생한 내용을 설명합니다.

event.type 필드는 프로세스 실행을 위한 start 등의 수명 주기 컨텍스트를 추가하며, 종종 event.action 와 함께 사용되어 활동의 여러 단계를 구분합니다. event.dataset 필드는 데이터 세트 범위의 쿼리 또는 탐지를 작성할 때 유용한 cloud_defend.process 과 같은 원본 Defend for Containers 데이터 스트림을 나타냅니다.

event.id, event.ingested, event.kind 와 같은 추가 메타데이터 필드는 주로 감지 로직보다는 상관관계, 순서 지정 및 문제 해결에 사용됩니다.

호스트 정보

컨테이너용 Defend 이벤트에는 Elastic Defend 및 Auditd Manager와 유사하게 전체 호스트 컨텍스트가 포함됩니다. 이를 통해 컨테이너 런타임 활동을 기본 Kubernetes 노드와 다시 연관시킬 수 있습니다.

host.name 필드는 컨테이너가 실행 중인 노드를 식별하고 host.os.* 필드는 배포 및 커널 버전과 같은 운영 체제 세부 정보를 제공합니다. host.architecture 필드는 바이너리 실행 또는 커널별 동작을 분석할 때 관련될 수 있는 CPU 아키텍처를 나타냅니다.

특히 유용한 필드 중 하나는 PID 네임스페이스를 식별하는 host.pid_ns_ino 입니다. 이 필드를 사용하면 컨테이너 활동을 호스트 수준 프로세스 및 커널 원격 분석과 연관시킬 수 있으며, 컨테이너 탈출 시도 또는 노드 수준 영향을 조사할 때 특히 유용합니다.

여러 컨테이너가 동일한 호스트와 커널을 공유하는 경우가 많고 컨테이너의 런타임 동작이 경계를 넘어 영향을 미칠 수 있으므로 클라우드 네이티브 공격을 분석할 때 이러한 호스트 컨텍스트는 매우 중요합니다.

컨테이너 및 오케스트레이터 컨텍스트

디펜드 포 컨테이너의 주요 강점은 컨테이너 인식 기능에 있습니다. 모든 런타임 이벤트는 컨테이너 및 오케스트레이션 메타데이터로 강화되어 실행 중인 항목, 실행 중인 위치, 실행 중인 권한에 대한 컨텍스트에서 활동을 분석할 수 있습니다.

컨테이너 수준에서 container.id 및 container.name 과 같은 필드는 실행 중인 컨테이너를 고유하게 식별하고 container.image.name, container.image.tag 및 이미지 해시는 워크로드의 원본 및 버전에 대한 가시성을 제공합니다. 이는 예상되는 유틸리티 이미지와 예상치 못한 또는 임시 워크로드를 구분하는 데 특히 유용합니다.

위험 평가의 핵심 필드는 container.security_context.privileged 입니다. 이 필드는 컨테이너가 권한 모드로 실행 중인지 여부를 명시적으로 나타냅니다. 권한 실행이 대화형 셸 또는 광범위한 Linux 기능과 같은 다른 신호와 결합되면 탐지된 모든 활동의 위험 프로필이 크게 증가합니다.

컨테이너용 방어는 또한 오케스트레이션 컨텍스트를 통해 이벤트를 더욱 풍부하게 합니다. orchestrator.cluster.name, orchestrator.namespace, orchestrator.resource.name (일반적으로 파드 이름)과 같은 필드는 런타임 동작을 쿠버네티스 워크로드에 다시 연결합니다. orchestrator.resource.label 을 통해 노출된 레이블을 통해 워크로드 의도와 소유권을 통합하여 탐지할 수 있습니다.

탐지 엔지니어링의 경우, 이 컨텍스트를 통해 탐지 범위를 정확하게 지정할 수 있습니다:

특정 네임스페이스(예: kube-system),
권한이 있거나 고위험 컨테이너,
민감한 레이블이 있는 워크로드,
또는 netshoot, kubectl, curl 와 같은 알려진 유틸리티 이미지.

이러한 강화 계층을 통해 컨테이너 인식 탐지 로직을 파일 시스템 경로, cgroup 또는 네임스페이스 식별자에서 간접적으로 의도를 추론할 필요 없이 직접 표현할 수 있습니다.

이벤트 처리

프로세스 실행은 컨테이너를 위한 방어가 제공하는 가장 중요한 신호 유형 중 하나입니다. 프로세스 이벤트는 컨테이너 내의 fork, exec, end 활동을 캡처하고 런타임에 실행이 어떻게 전개되는지 이해하는 데 중요한 상세한 계보 정보를 노출합니다.

탐지 엔지니어링에는 몇 가지 분야가 특히 중요합니다. process.name 와 process.executable 의 조합은 실행된 내용과 실행된 위치를 식별하고 process.args 는 실행 방법에 대한 인사이트를 제공합니다. process.pid, process.start, process.end, process.exit_code 과 같은 필드는 프로세스 수명 주기를 설명하며 타이밍 분석 및 실행 흐름 재구성에 유용합니다. process.entity_id 은 여러 관련 이벤트에서 프로세스를 추적할 수 있는 안정적인 식별자를 제공합니다.

컨테이너용 디펜스는 풍부한 조상 정보도 캡처합니다. process.parent.* 아래의 필드는 즉각적인 부모 프로세스를 설명하므로 예기치 않은 바이너리에 의해 생성된 셸과 같은 의심스러운 부모-자식 관계를 감지할 수 있습니다. 또한 process.entry_leader.* 및 process.session_leader.* 은 프로세스 트리 내에서 상위 수준의 앵커를 제공합니다.

Elastic Defend와 마찬가지로, 컨테이너용 Defend는 분리된 이벤트가 아닌 그래프로 프로세스를 모델링합니다. 엔트리 리더는 컨테이너 런타임에 의해 시작되는 초기 프로세스(예: containerd, runc, 또는 컨테이너 진입점으로 지정된 셸)를 나타내는 경우가 많으므로 컨테이너 환경에서 특히 유용합니다. 항목 리더에 감지를 고정하면 컨테이너가 수명이 짧은 많은 하위 프로세스를 생성하는 경우에도 프로세스 트리를 일관되게 해석할 수 있습니다.

세션 리더 필드는 대화형 실행 및 세션 경계에 대한 추가 컨텍스트를 제공하여 백그라운드 서비스와 대화형 또는 공격자 주도 활동을 구분하는 데 도움이 됩니다.

이러한 필드를 함께 사용하면 단일 실행을 넘어 실행 체인, 계보, 의도를 추론하는 탐지 로직을 표현할 수 있으며, 이는 실제 컨테이너 공격 기법을 탐지하는 데 필수적입니다.

기능 및 권한 컨텍스트

컨테이너를 위한 방어 프로세스 이벤트의 더 강력한 측면 중 하나는 Linux 기능 정보를 포함한다는 점입니다. 각 프로세스에 대해 컨테이너용 방어는 다음을 통해 유효 기능 세트와 허용된 기능 세트를 모두 노출합니다:

process.thread.capabilities.effective
process.thread.capabilities.permitted

이러한 필드는 사용자 ID 또는 컨테이너 경계와 관계없이 프로세스가 런타임에 실제로 수행할 수 있는 작업을 설명합니다.

권한이 있는 컨테이너에서 프로세스는 종종 CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIO, CAP_BPF 과 같은 매우 민감한 기능을 포함하여 광범위한 효과적인 기능을 노출합니다. 이러한 기능이 있으면 호스트 커널이나 기타 워크로드에 직접적인 영향을 미칠 수 있는 작업을 수행할 수 있으므로 실행되는 명령의 위험 프로필이 크게 변경됩니다.

탐지 엔지니어링 관점에서 볼 때 이러한 컨텍스트는 매우 중요합니다. 이를 통해 탐지가 단순한 프로세스 이름 일치를 넘어 영향력을 추론할 수 있습니다. 동일한 바이너리 실행이라도 최소한의 기능 세트로 실행되는지 아니면 호스트 수준에 가까운 권한으로 실행되는지에 따라 그 영향이 크게 달라질 수 있습니다.

실제로 기능 데이터를 통해 탐지 엔지니어는 다음을 수행할 수 있습니다:

지나치게 허용적인 컨테이너 내에서 실행되는 의심스러운 툴을 식별합니다.
런타임 동작과 위험한 기능 조합의 상관관계를 파악합니다.
표면적인 활동보다는 실제 악용 가능성을 기준으로 알림의 우선순위를 정하세요.

이는 특정 기능의 유무에 따라 익스플로잇의 실행 여부가 결정되는 경우가 많은 컨테이너 브레이크아웃 연구와 특히 관련이 있습니다.

대화형 실행

process.interactive 필드는 프로세스가 대화형 세션과 연결되어 있는지 여부를 나타냅니다. 컨테이너 환경에서는 프로덕션 워크로드에서 대화형 실행이 상대적으로 드물며, 종종 사후 손상 또는 키보드 작업과 밀접한 관련이 있습니다.

컨테이너를 위한 방어는 프로세스 수준뿐만 아니라 process.parent.interactive, process.entry_leader.interactive, process.session_leader.interactive 등 관련 실행 컨텍스트 전반에서 상호 작용을 노출합니다. 이를 통해 단일 프로세스 플래그에 의존하지 않고 전체 실행 체인이 대화형인지 여부를 판단할 수 있습니다.

컨테이너 내에서 대화형 실행의 일반적인 예로는 bash 또는 sh 셸 생성, curl, kubectl 또는 busybox 와 같은 대화형 유틸리티 실행 또는 손상된 파드 내에서 운영자 주도 정찰이 있습니다. 이러한 작업은 디버깅 중에는 합법적일 수 있지만, 정상 상태의 프로덕션 워크로드에서는 일반적이지 않습니다.

컨테이너 이미지, 네임스페이스, 권한 컨텍스트와 결합하면 대화형 실행은 강력한 이상 징후가 됩니다. 이를 통해 탐지 로직은 예상되는 자동화된 컨테이너 동작과 수동 개입 또는 공격자 주도 탐색과 더 일치하는 활동을 구분할 수 있습니다.

파일 이벤트

컨테이너용 Defend 파일 이벤트는 컨테이너 내부의 파일 시스템 활동을 캡처하며, 다양한 작업에 대해 방출됩니다. 기존의 파일 무결성 모니터링과 달리, 이러한 이벤트는 런타임을 인식하고 컨테이너 워크로드로 범위를 지정하여 파일 변경이 발생하는 방식과 이유에 대한 컨텍스트를 제공합니다.

컨테이너용 Defend는 쓰기 의도가 있는 파일 열기, 콘텐츠 수정, 파일 생성, 이름 변경, 권한 변경 및 삭제와 같은 파일 활동을 감지할 수 있습니다. 쓰기 지향 작업에 중점을 두는 Defend for Containers는 수동적인 파일 액세스보다는 시스템 상태를 변경하는 동작을 강조합니다.

이를 통해 탐지 엔지니어는 변경의 결과뿐만 아니라 런타임에 파일 사용 패턴을 추론할 수 있습니다.

파일 기반 탐지 기능을 구축할 때 특히 중요한 몇 가지 필드가 있습니다. file.path 및 file.name 필드는 영향을 받는 파일과 해당 위치를 식별하고 file.extension 는 바이너리, 스크립트 및 구성 파일을 구분하는 데 도움이 됩니다. event.action 및 event.type 필드에는 어떤 작업이 발생했으며 이벤트 수명 주기에서 어떻게 해석되어야 하는지 설명합니다.

이러한 필드를 함께 사용하면 Defend for Containers가 정상적인 파일 액세스와 바이너리 쓰기 또는 민감한 디렉터리 내 권한 변경과 같은 의심스러운 수정 패턴을 구분할 수 있습니다.

하나로 모으기

다른 데이터 소스와 마찬가지로, 프로세스, 파일, 컨테이너, 오케스트레이션 도메인 전반에서 필드를 결합하는 방법을 이해하면 Defend for Containers 원격 분석의 진정한 가치가 발휘됩니다. 컨테이너를 위한 방어는 정적 지표에 의존하는 대신 런타임 동작, 권한 컨텍스트, 워크로드 ID를 기반으로 탐지 엔지니어링을 지원합니다.

결론

Elastic Stack 9.3.0의 컨테이너를 위한 방어 에는 Linux 탐지 엔지니어링의 핵심 구성 요소로 컨테이너 런타임 탐지가 포함되어 있습니다. 명확한 범위, 정책 중심 구성 모델, 컨테이너화된 워크로드를 위해 특별히 설계된 런타임 원격 분석이 특징입니다.

이 게시물에서는 컨테이너용 Defend를 배포하는 방법, 정책 모델의 구조, 런타임 이벤트가 생성되고 컨테이너 및 오케스트레이션 컨텍스트가 강화되는 방법을 살펴보았습니다. 프로세스 및 파일 이벤트, 기능 메타데이터, 대화형 실행 신호, 워크로드 인식 방식으로 탐지를 표현할 수 있는 컨테이너별 필드의 구조를 살펴봤습니다.

중요한 점은 효과적인 컨테이너 탐지를 위해서는 프로세스, 파일 수정, 권한, 워크로드 ID를 함께 평가해야 하는 등 컨텍스트에서 런타임 동작에 대한 추론이 필요하다는 것입니다. 디펜드 포 컨테이너는 이를 가능하게 하는 데 필요한 원격 분석 기능을 제공합니다.

다음 글에서는 이러한 기반을 바탕으로 실제 컨테이너 공격 시나리오를 살펴보고 Defend for Containers 원격 분석이 실제로 각 침해 단계를 어떻게 드러내는지 시연해 보겠습니다.