컨테이너 탈출 공격 탐지 및 예방

홈 » Python » 컨테이너 탈출 공격 탐지 및 예방

컨테이너 탈출은 클라우드 및 플랫폼 팀을 밤에 잠 못 이루게 하는 주제 중 하나가 되었습니다. 잘못 구성된 단일 포드나 오래된 커널만으로도 격리된 워크로드가 기반 호스트에 대한 직접 브리지로 전환될 수 있기 때문입니다. 이렇게 되면 공격자는 더 이상 하나의 컨테이너에 갇히지 않고 노드를 이동하거나 다른 테넌트의 데이터에 액세스하거나 심지어 전체 클러스터를 장악할 수도 있습니다.

컨테이너 이스케이프가 실제로 어떻게 작동하는지 이해하는 것(Linux 내부에서 런타임 신호 및 EDR 감지까지)은 무서운 유행어와 실제로 관리할 수 있는 위험의 차이입니다.이 가이드에서는 OS 수준에서 컨테이너가 무엇인지, 실제로 이스케이프가 발생하는 방식, 실제 공격에서 발견된 주요 악용 기술, 그리고 기능 모니터링, Falco 규칙, CNAPP 플랫폼, 그리고 전통적인 강화 및 세분화를 사용하여 이러한 기술을 탐지하고 방지하는 방법을 살펴보겠습니다.

컨테이너 탈출이란 무엇이고 왜 중요한가요?

컨테이너 탈출은 공격자가 컨테이너를 호스트와 다른 컨테이너로부터 분리해야 하는 논리적 격리를 깨뜨릴 때 발생합니다.공격자는 자신의 네임스페이스와 cgroup에 갇히는 대신 호스트 수준 컨텍스트에서 코드를 실행할 수 있는 능력을 얻습니다. 이는 종종 높거나 모든 권한을 가지고 실행됩니다.

컨테이너는 가상 머신과 중요한 면에서 다릅니다. 즉, 모두 동일한 호스트 커널을 공유합니다.Linux 네임스페이스(PID, 마운트, 네트워크 등), cgroup 및 기능과 같은 기술은 커널을 여러 개의 격리된 뷰로 분할하지만, 취약점이나 잘못된 구성으로 인해 공격자가 해당 경계를 넘을 수 있게 되면 손상은 원래 해킹된 컨테이너를 훨씬 넘어 확산될 수 있습니다.

사업적 관점에서 성공적인 탈출의 폭발 반경이 그것을 매우 위험하게 만드는 것입니다.. 인터넷에 연결된 단일 취약한 컨테이너로 인해 민감한 데이터가 도난당하고, 대규모 암호화폐 채굴기가 배포되고, 중요 서비스가 중단되고, 다중 테넌트 또는 규제 환경에서 심각한 규정 준수 문제가 발생할 수 있습니다.

적대자들은 일반적으로 컨테이너 탈출을 더 광범위한 공격 체인의 한 단계로 사용합니다.: 앱 버그, 취약한 자격 증명 또는 공급망 문제를 통해 권한이 낮은 컨테이너에 침입하여 컨테이너 내부에서 권한을 확대한 다음 호스트로 탈출하여 측면 피벗을 수행하거나 자격 증명을 수집하거나 커널 수준 루트킷과 같은 지속성을 구축합니다.

컨테이너가 후드 아래에서 작동하는 방식

탈출 기술을 실제로 이해하려면 먼저 Linux 컨테이너가 프로세스를 격리하는 방법에 대한 정신 모델이 필요합니다.컨테이너는 본질적으로 컨테이너 런타임(예: containerd, Docker 또는 CRI‑O)에 의해 조정된 속성(네임스페이스, 기능, cgroup, seccomp 프로필 등)을 가진 프로세스 트리입니다. 컨테이너화 기술.

컨테이너가 시작되면 런타임은 프로세스를 생성하고 이를 자체 작은 우주의 "init" 프로세스로 전환합니다.: 자체 PID 네임스페이스, 마운트 네임스페이스, 네트워크 네임스페이스 등을 가지며, 이 모든 것은 커널에 의해 적용됩니다. 해당 프로세스는 이미지 구성(예: Dockerfile의 ENTRYPOINT/CMD)에 정의된 명령을 실행합니다.

기능은 Linux가 기존의 모든 강력한 루트를 더 작은 권한 비트로 나누는 방식입니다.. "루트가 모든 것을 할 수 있다"는 말과 달리 커널은 다음과 같은 플래그를 정의합니다. CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG 그리고 수십 개가 더 있습니다. 각 스레드는 수행할 수 있는 특권 작업을 정의하는 기능 집합(허용된 기능, 유효한 기능, 상속 가능한 기능)을 가지고 있습니다.

네임스페이스는 "프로세스가 어디에서 권한을 행사할 수 있는가?"라는 질문에 답합니다.예를 들어, PID 네임스페이스는 컨테이너 내부의 PID 1을 호스트의 PID 1과 무관하게 만들고, 마운트 네임스페이스는 컨테이너에 자체 파일 시스템 뷰를 제공합니다. 프로세스에 다음과 같은 기능이 있더라도 CAP_KILL제한된 PID 네임스페이스에서는 해당 네임스페이스에 있는 프로세스만 종료할 수 있습니다.

Cgroup은 컨테이너가 소모할 수 있는 리소스 수를 제어하여 이러한 격리를 보완합니다. – CPU 공유, 메모리 제한, I/O 등. seccomp 필터(시스템 호출 허용/거부 목록) 및 AppArmor나 SELinux와 같은 LSM과 결합하면 최신 컨테이너 보안의 기반이 되는 계층적 격리를 구현할 수 있습니다.

공격자가 컨테이너 탈출을 시도하는 이유

적이 컨테이너를 손상시키면 내부의 생명이 상당히 제한되어 있다는 사실을 빨리 알게 됩니다.: 제한된 파일 시스템, 제한된 네트워크 보기, 루트가 아닐 수 있음, 일반적으로 다른 작업에 직접 액세스할 수 없음.

호스트로 탈출하면 해당 가드레일이 제거됩니다.호스트의 초기 네임스페이스에서 명령을 실행할 수 있다면 모든 프로세스를 보고 모든 파일 시스템을 마운트하고 다음과 같은 위치에서 자격 증명을 수집할 수 있습니다. /root/.ssh 또는 클라우드 메타데이터 에이전트로 전환하고 다른 컨테이너나 VM으로 전환합니다.

탈출은 또한 근절하기 어려운 지속성을 가능하게 합니다.공격자는 일시적인 컨테이너에만 백도어를 설치하는 대신, 커널 모듈을 설치하고 runc나 containerd와 같은 컨테이너 런타임을 조작하거나, 백도어가 설치된 포드가 Kubernetes 클러스터의 모든 노드에서 실행되도록 하는 데몬셋을 배포할 수 있습니다.

탐지 관점에서 컨테이너 탈출의 많은 징후는 고전적인 권한 확대 및 측면 이동 동작과 겹칩니다. – 커널 모듈 로딩, 의심스러움 mount/unshare/setns 사용, 런타임 소켓에 대한 직접 액세스, SUID 악용, 컨테이너 내부에 노출된 호스트 경로에 대한 비정상적인 파일 액세스.

컨테이너 탈출의 주요 경로: 취약점, 권한 및 잘못된 구성

대부분의 실제 컨테이너 탈출 시나리오는 세 가지 광범위한 범주로 나뉩니다.: 취약점(커널 또는 런타임)을 악용하거나, 권한이 지나치게 높은 컨테이너를 남용하거나, 위험한 마운트 및 노출된 소켓과 같은 잘못된 구성을 이용하는 것입니다.

커널 및 컨테이너 런타임 취약점

모든 컨테이너가 호스트 커널을 공유하기 때문에 단일 커널 버그가 탈출을 위한 직접적인 경로를 제공할 수 있습니다.Dirty COW(CVE‑2016‑5195) 및 Dirty Pipe(CVE‑2022‑0847)와 같은 유명한 문제는 공격자가 읽기 전용 매핑과 임의 파일에 쓸 수 있도록 허용하는 로컬 권한 상승 버그로, 이를 통해 컨테이너 내부에서 호스트 바이너리나 구성을 변조할 수 있는 경우가 많습니다.

특히 중요한 컨테이너 관련 버그 중 하나는 runc의 CVE‑2019‑5736입니다.컨테이너가 시작되거나 실행될 때 컨테이너 내 프로세스가 호스트의 runc 바이너리를 덮어쓰도록 허용하여 공격자에게 호스트 수준 코드 실행 권한을 부여했습니다. runc는 Docker, Kubernetes 및 기타 플랫폼을 기반으로 하기 때문에 그 영향은 광범위했습니다.

최근 "누수 선박"(예: CVE‑2024‑21626)과 같은 공개는 빌드 시스템과 시작 경로도 비옥한 토양임을 보여주었습니다.BuildKit 또는 runc 초기화 논리의 취약점을 악용하여 공격자는 다른 방어책이 완전히 적용되기 전에 이미지 빌드 또는 컨테이너 초기 시작 중에 침입할 수 있습니다.

containerd, Docker Engine 또는 CRI‑O와 같은 컨테이너 런타임 데몬에는 자체 버그가 있습니다.예를 들어, containerd의 CRI 플러그인의 CVE‑2022‑23648은 컨테이너를 생성할 수 있는 공격자가 민감한 호스트 경로(예: /root/.ssh)을 컨테이너에 넣고 절대 볼 수 없는 데이터를 읽어 탈출을 위한 발판을 마련합니다.

주목할 만한 컨테이너 이스케이프 CVE 및 이를 완화하는 방법

• CVE‑2019‑5736(runc): 컨테이너에서 호스트의 runc 바이너리를 다시 쓰는 것이 허용됨Docker, Kubernetes 및 기타 runc 기반 스택에 영향을 미칩니다. 보안 강화 조치에는 적극적인 패치 적용, 악용 도구에 대한 이미지 스캐닝, runc 바이너리 수정에 대한 런타임 모니터링이 포함됩니다.

• CVE‑2016‑5195(더티 카우): 권한이 없는 프로세스가 읽기 전용 매핑에 대한 쓰기 액세스 권한을 얻을 수 있도록 하는 copy‑on‑write의 경쟁 조건컨테이너 내부에서 마운트를 통해 노출된 호스트 파일을 변경하는 데 악용될 수 있습니다.

• CVE‑2022‑0847(더티 파이프): 컨테이너에 읽기 전용으로 마운트된 파일을 포함하여 파일에 대한 무단 쓰기를 가능하게 하는 또 다른 커널 버그자동으로 이스케이프를 허용하지는 않지만 권한이 있는 마운트나 런타임 오류 구성과 잘 연결됩니다.

• CVE‑2024‑21626 및 관련 "누수 용기" 문제: 이미지 빌드 또는 컨테이너 시작 중 호스트 리소스를 노출시키는 BuildKit 및 runc의 결함빌드 파이프라인 자체가 공격 표면의 일부가 될 수 있음을 증명합니다.

이 모든 종류의 문제에 대한 완화책은 패치 위생 및 아키텍처 선택을 중심으로 구성됩니다.: 호스트 커널을 패치하고, 최소 또는 배포판이 없는 기본 이미지를 사용하여 공격 표면을 줄이고, 민감도가 높은 작업 부하에는 샌드박스 또는 VM 지원 런타임을 선호하고, 커널 악용 시도처럼 보이는 의심스러운 시스템 호출 및 파일 쓰기를 지속적으로 모니터링합니다.

과도한 기능 및 특권 컨테이너

뿌리의 힘을 약화시키기 위한 기능이 발명되었지만 실제로는 "작은 조각"이 다시 덩어리로 묶이는 경우가 많습니다."그냥 작동하게 하라"는 압박을 받는 개발자들은 종종 CAP_SYS_ADMIN 또는 간단히 컨테이너를 실행합니다. --privileged용기 내부의 뿌리와 같은 힘을 효과적으로 회복합니다.

CAP_SYS_ADMIN 악명 높게 압도적이다: 파일 시스템 마운트, 네임스페이스 생성 또는 조인이 가능합니다.unshare, setns), cgroup 조정 등. 마운트와 네임스페이스를 적절히 조합하면 이러한 기능을 가진 공격자는 호스트의 초기 네임스페이스로 피벗하여 전역 가시성을 확보할 수 있습니다.

CAP_NET_ADMIN 네트워킹 관점에서도 마찬가지로 광범위합니다.인터페이스 재구성, iptables 규칙 조작, 그리고 무차별 모드 활성화에 사용될 수 있습니다. 이스케이프 체인에서는 트래픽 스니핑, 네트워크 정책 우회, 또는 세그먼테이션 우회 터널링에 악용될 수 있습니다.

완전 권한 모드에서 컨테이너를 실행한다는 것은 기본적으로 "이것을 호스트의 일부로 취급한다"는 것을 의미합니다.모든 기능을 확보하고 호스트 장치에 접근할 수 있으며, 종종 seccomp 프로필을 우회합니다. 많은 공격 체인에서 가장 어려운 단계는 잘못 구성된 컨테이너 하나를 찾아 발사대로 사용하는 것입니다.

Falco와 같은 최신 툴링은 감지를 위해 스레드 수준에서 기능을 노출하기 시작했습니다.. 이제 다음과 같은 필드를 검사할 수 있습니다. thread.cap_effective, thread.cap_permitted thread.cap_inheritable 런타임에 위험한 기능이 있는 프로세스가 의심스러운 작업을 수행할 때마다 경고를 트리거합니다.

잘못된 구성: 마운트, 소켓 및 로그 트릭

컨테이너 탈출의 놀라울 정도로 큰 부분은 특이한 0일이 아닌 단순한 잘못된 구성에 의존합니다.운영자가 민감한 호스트 경로를 컨테이너에 마운트하거나 내부 Unix 소켓을 노출하는 경우 공격자는 종종 이를 뚫고 침투할 수 있습니다.

위험한 hostPath 또는 볼륨 마운트는 전형적인 예입니다.컨테이너가 다음과 같은 디렉토리에 대한 읽기-쓰기 액세스 권한을 얻는 경우 /etc, /proc, /sys or /var/run 호스트에서 격리 모델이 크게 붕괴됩니다. /proc/sys 또는 sysfs는 커널 매개변수를 변경할 수 있습니다. 다음과 같은 호스트 구성 파일에 액세스할 수 있습니다. /etc/shadow 자격 증명을 유출할 수 있습니다.

Docker 소켓(/var/run/docker.sock) 및 기타 런타임 소켓은 또 다른 고통스러운 잘못된 구성입니다.이것을 컨테이너 내부에 마운트하면 컨테이너를 제어하는 ​​사람이 Docker 데몬을 거의 완벽하게 제어할 수 있습니다. 간단한 방법으로 curl --unix-socket 호출을 통해 공격자는 컨테이너를 나열하고 호스트 루트를 마운트하는 새로운 권한이 있는 컨테이너를 만들고 해당 도우미 컨테이너에서 탈출할 수 있습니다.

Kubernetes에서는 kubelet의 로그 처리 및 호스트 로그 마운트도 남용되었습니다.. 포드에 호스트가 있는 경우 /var/log 바인드 마운트되고 공격자가 로그 심볼릭 링크를 조작하고 API를 통해 로그를 읽을 수 있는 경우 로그 심볼릭 링크를 임의의 호스트 파일로 가리키고 kubelet을 속여 다음을 반환하도록 할 수 있습니다. /etc/shadow 내용.

겉보기에 단순한 SUID 동작조차도 역할을 할 수 있습니다.컨테이너가 호스트와 사용자 네임스페이스를 공유하는 환경에서 컨테이너 내부의 공유 디렉토리에 있는 바이너리에 SUID 비트를 설정하면 나중에 권한이 낮은 호스트 사용자가 호스트에서 루트 권한으로 해당 프로그램을 실행할 수 있습니다.

야외에서 발견된 콘크리트 용기 탈출 기술

범주에서 특정 기술로 확대하면 원격 측정 및 위협 보고서의 패턴을 인식하는 데 도움이 됩니다.여러 가지 방법론이 연구자들에 의해 반복적으로 시연되었고 침투 테스트나 실제 공격에 사용되었습니다.

사용자 모드 도우미 및 release_agent 비결

Linux 커널은 함수를 노출합니다. call_usermodehelper커널 공간 이벤트에 대한 응답으로 상승된 권한으로 사용자 영역 프로그램을 시작합니다.적절한 조건 하에서 사용자가 제어하는 ​​파일은 어떤 프로그램이 실행되는지에 영향을 미쳐 합법적인 메커니즘을 탈출 벡터로 바꿀 수 있습니다.

Cgroups v1 release_agent 이 패턴의 가장 잘 알려진 예는 다음과 같습니다.. cgroup이 비어 있을 때 notify_on_release 활성화되면 커널은 다음에서 가리키는 바이너리를 실행합니다. release_agent 파일. 컨테이너 내부의 공격자가 충분한 권한으로 cgroup 파일 시스템을 마운트하고 조작할 수 있는 경우 다음을 가리킬 수 있습니다. release_agent 호스트의 임의의 실행 파일에서.

일반적인 악용 시퀀스는 대략 다음과 같습니다.: cgroup 디렉토리를 생성하고 마운트하고 활성화합니다. notify_on_release, 설정하다 release_agent 호스트 네임스페이스에 있는 악성 스크립트의 경로로 이동한 다음, cgroup의 프로세스 목록을 비웁니다. 커널은 호스트에서 루트 권한과 같은 권한으로 공격자의 스크립트를 실행합니다.

감지에는 사용자 모드 도우미 경로에 대한 의미적 이해와 변경 사항이 발생한 위치에 대한 컨텍스트가 모두 필요합니다.. 강력한 접근 방식은 모든 것을 매핑합니다. call_usermodehelper 호출 사이트를 식별하고, 사용자 모드 파일의 영향을 받을 수 있는 사이트를 식별한 다음, 컨테이너에서 해당 파일에 대한 쓰기를 모니터링하여 의심스러운 수정 사항을 표시합니다.

SUID 비트를 통한 호스트에 대한 권한 확대

SUID 기술은 공격자가 이미 호스트 액세스 권한을 가지고 있다고 가정하기 때문에 "순수한" 컨테이너 이스케이프가 아닙니다.하지만 제한된 호스트 사용자에서 루트로 점프하기 위해 컨테이너 액세스와 자주 연결됩니다.

이 트릭은 호스트와 컨테이너 간의 공유 디렉토리와 공유 사용자 네임스페이스에 달려 있습니다.루트로 실행되는 컨테이너 내부에서 공격자는 양쪽에서 볼 수 있는 디렉토리(예: 공유 볼륨)에 실행 파일을 넣고 SUID 비트를 설정합니다. chmod u+s.

나중에 호스트의 루트가 아닌 사용자가 해당 바이너리를 실행하고 호스트에서 루트 권한을 얻습니다.SUID 비트는 호스트 컨텍스트에서 해석되기 때문입니다. 컨테이너는 해당 호스트 사용자에게 적용될 수 있는 제한 없이 SUID 페이로드를 준비할 수 있는 편리한 장소로 사용됩니다.

SUID 남용에 대한 가시성은 세 가지 순간에 초점을 맞춥니다.: 공유 경로에 실행 파일 생성, 컨테이너에서 SUID/SGID 비트 설정, 그리고 루트가 아닌 계정으로 호스트에서 해당 파일 실행. EDR 및 런타임 보안 도구는 이러한 단계들을 상호 연관시켜 고충실도 경보를 발생시킬 수 있습니다.

런타임 소켓 남용: Docker 및 containerd

컨테이너 환경은 종종 CLI 도구나 오케스트레이터가 Unix 소켓을 통해 데몬과 통신하는 클라이언트/서버 아키텍처에 의존합니다.. 예는 다음과 같습니다. /var/run/docker.sock Docker 또는 /run/containerd/containerd.sock 컨테이너용.

이러한 소켓 파일이 컨테이너 내부에 마운트되면 해당 컨테이너는 효과적으로 관리자 클라이언트 역할을 할 수 있습니다.컨테이너를 손상시킨 공격자는 API 요청을 런타임에 직접 보내 컨테이너를 나열하고, 워크로드를 시작 및 중지하거나, 호스트 마운트가 있는 새로운 권한이 있는 컨테이너를 생성할 수 있습니다.

다음과 같은 일반 도구를 사용하여 curlUnix 소켓을 통해 Docker 원격 API를 사용하는 것은 간단합니다.: 쿼리 /containers/json 컨테이너를 열거하고 게시하다 /containers/create JSON 정의를 사용하여 권한이 있는 도우미를 만든 다음 호출합니다. /containers/{id}/start 이를 실행하려면 해당 도우미 컨테이너가 호스트 루트 파일 시스템을 마운트하고 공격자에게 대화형 액세스를 제공할 수 있습니다.

수비수는 여러 가지 방법으로 이를 사냥할 수 있습니다.: 컨테이너화된 프로세스에서 런타임 Unix 소켓에 대한 액세스를 모니터링하고 의심스러운 것을 감지합니다. curl --unix-socket 또는 해당 소켓을 타겟으로 하는 런타임 CLI 호출 및 비정상적인 컨테이너 생성 패턴(예: hostPath가 마운트됨)에 대한 경고 /, --privileged (Kubernetes 사양에 따라)

Kubernetes 특정 트릭: 로그 마운트 및 Pod 이스케이프

Kubernetes에서 일부 공격은 원시 Docker 개념보다는 kubelet 동작과 Kubernetes 추상화를 표적으로 삼습니다.. 호스트 디렉토리를 마운트하는 Pod /var/log or /var/lib/docker 특히 적대자들에게는 흥미로운 일이다.

한 가지 입증된 방법은 로그를 반환할 때 kubelet이 심볼릭 링크를 해결하는 방식을 남용합니다.각 포드는 로그 파일을 받습니다. /var/log 컨테이너의 디렉토리에 심볼릭 링크가 연결됩니다. /var/lib/docker/containers. 공격자가 심볼릭 링크를 생성하거나 수정할 수 있는 경우 /var/log hostPath 마운트를 통해 "로그"를 임의의 파일을 가리키도록 리디렉션할 수 있습니다(예: /etc/shadow).

로그 읽기 권한이 있는 사용자 또는 서비스 계정이 호출할 때 kubectl logs 또는 해당 API, kubelet은 심볼릭 링크를 따라가서 해당 대상의 콘텐츠를 반환합니다.공격자는 창의력을 발휘하여 일련의 심볼릭 링크된 "로그"를 통해 호스트 파일 시스템의 상당 부분을 노출시킬 수 있습니다.

여기서의 탐지는 네트워크와 파일 시스템 렌즈를 결합합니다.: 비정상적인 경로 패턴에 대한 Kubernetes 로그 읽기 HTTP 요청을 모니터링하고 동시에 호스트에서 심볼릭 링크 생성 또는 수정을 감시합니다. /var/log 컨테이너화된 프로세스에서 유래됨.

민감한 호스트 마운트 및 직접적인 데이터 도난

때때로 이스케이프는 호스트 수준 코드를 실행하지 않고 컨테이너 내부에서 호스트 데이터를 읽거나 수정하는 것으로만 구성됩니다.민감한 디렉토리를 노출시키는 잘못 구성된 마운트는 심각한 영향을 미치기에 충분합니다.

예를 들어, 컨테이너에는 다음과 같은 마운트가 있을 수 있습니다. /host_etc 호스트를 가리키며 /etc 예배 규칙서. 이 경로에 우연히 들어간 공격자는 간단히 열 수 있습니다. /host_etc/passwd or /host_etc/shadow 그리고 그들은 컨테이너 내부에서 호스트 인증 파일을 효과적으로 읽고 있습니다.

이러한 마운트의 오용을 감지하는 것은 많은 액세스 패턴이 일반 파일 작업과 유사해 보이기 때문에 까다롭습니다.. 그냥 지켜보는 것만으로는 안 돼 /etc/shadow 컨테이너 내부에서, 이는 일반적으로 호스트 파일이 아닌 컨테이너 자체 파일을 의미하기 때문입니다. 각 마운트에 대해 "컨테이너 경로"를 "기본 호스트 경로"로 변환하는 매핑 계층이 필요합니다.

고급 EDR 및 CNAPP 도구는 호스트 측 경로를 기반으로 마운트 지점을 확인하고 액세스를 추적하여 이를 해결합니다.. 이렇게 하면 컨테이너 내부의 무해해 보이는 경로를 통해서라도 호스트에 민감한 파일에 영향을 미치는 모든 읽기 또는 쓰기 작업을 실시간으로 플래그로 지정할 수 있습니다.

런타임 시 컨테이너 이스케이프 시도 감지

예방적 강화가 필수적이지만 컨테이너가 실행되는 동안 무슨 일이 일어나는지 잘 살펴봐야 합니다.. 최신 공격은 여러 단계로 이어지는 경우가 많으며, 강력한 런타임 모니터링을 통해 호스트에 도달하기 전에 해당 단계를 포착할 수 있습니다.

최첨단 탐지 기능은 일반적으로 저수준 원격 측정(예: eBPF 기반 시스템 호출 추적)과 동작 분석 및 클라우드 컨텍스트를 결합합니다.원시 신호는 시스템 호출, 파일 작업, 프로세스 트리 및 소켓 활동에서 발생하며, 분석 계층은 이를 ID, 네트워크 노출 및 클라우드 자산과 연관시켜 무해한 관리자 작업과 실제 탈출 시도를 구분합니다.

주요 시스템 호출 수준 표시기

특정 시스템 호출은 경계를 깨는 활동과 밀접하게 연관되어 있습니다. 컨테이너에서 호출할 경우 추가적인 조사를 받아야 합니다.

• mount, umount, pivot_root – 파일 시스템 마운트를 조작하거나 루트 디렉토리를 피벗팅하는데, 종종 호스트 경로를 컨테이너에 꿰매거나 chroot를 이스케이프하는 데 사용됩니다.

• setns, unshare – 호스트의 초기 네임스페이스로 이동하는 기술의 핵심 단계인 새로운 네임스페이스에 가입하거나 생성합니다.

• ptrace – 디버깅이나 다른 프로세스에 주입하는 경우, 컨테이너 경계를 넘거나 시스템 데몬을 타겟팅하는 경우 의심스럽습니다.

• capset – 실행 중에 새로운 강력한 플래그를 얻는 데 사용될 수 있는 기능의 런타임 수정.

• init_module, finit_module – 컨테이너에서 커널 모듈을 로드하는 것은 합법적인 작업 부하에서는 거의 필요하지 않은 고위험 동작입니다.

Falco와 같은 규칙 엔진을 사용하면 컨테이너 인식 방식으로 이러한 시스템 호출에 대한 감지 논리를 표현할 수 있습니다.예를 들어, 컨테이너화된 프로세스가 있을 때마다 경고할 수 있습니다. CAP_SYS_ADMIN 라는 이름의 파일을 엽니다 release_agent 쓰기의 경우, 이는 사용자 모드 도우미 기반 탈출 시도의 매우 강력한 지표입니다.

의심스러운 파일 액세스 패턴

파일 무결성 및 액세스 모니터링은 공격자가 어떤 경로를 터치하는지 정확하게 보여줌으로써 시스템 호출을 보완합니다.컨테이너/호스트 매핑의 관점에서 보면 이는 강력한 탈출 감지기가 됩니다.

• 에게 편지를 쓴다 /proc/sys or /sys 컨테이너 신호에서 커널 매개변수나 장치 설정을 변경하려고 시도합니다.

• 컨테이너 런타임 소켓에 대한 액세스 /var/run/docker.sock or /run/containerd/containerd.sock 일반적인 애플리케이션 컨테이너에서 나오는 경우 위험 신호입니다.

• 변경 사항 /etc/passwd, /etc/shadow or /etc/sudoers 컨테이너에서 볼 수 있는 경로를 통해 호스트에서 권한 확대 및 지속성 단계처럼 보입니다.

• 다음에서 읽습니다. /proc/*/environ or /proc/*/cmdline 네임스페이스 전반에 걸쳐 컨테이너 자체의 프로세스 트리를 넘어서 프로세스 열거와 자격 증명 수집을 나타낼 수 있습니다.

가장 안정적인 알림은 경로, 시스템 호출, 기능 및 컨테이너 메타데이터 등 여러 요소를 결합합니다.. 예를 들어, a mount 관리자가 아닌 인터넷에 노출된 앱 컨테이너에서 발생하는 syscall CAP_SYS_ADMIN 및 타겟팅 /proc/sys 알려진 특권 유지 관리 작업에서 수행하는 동일한 작업보다 훨씬 더 놀랍습니다.

프로세스 수준 및 행동 신호

원시 시스템 호출 및 파일 이벤트를 넘어 상위 수준 프로세스 동작은 무슨 일이 일어나고 있는지에 대한 스토리를 그려냅니다.. 특정 활동은 일반 마이크로서비스에서는 극히 드물지만, 익스플로잇 이후 단계에서는 흔히 발생합니다.

• 비대화형 컨테이너에서 생성된 대화형 셸 (예 : /bin/bash 웹 서버 프로세스 아래에 나타나는) 키보드 활동을 제안합니다.

• 다음과 같은 권한 확대 도구 사용 sudo, su or newgrp 내부 용기특히 대화형 사용을 목적으로 하지 않은 앱은 매우 의심스럽습니다.

• 네트워크 스캐닝, 측면 이동 툴링 및 특이한 아웃바운드 연결 소수의 서비스와만 통신해야 하는 컨테이너에서 정찰이나 전파 시도가 있음을 나타냅니다.

• Cryptominer 서명, 예상치 못한 장기 실행 CPU 바인딩 프로세스 또는 GPU 사용량 급증 공격자가 호스트 수준 액세스를 사용하여 리소스를 수익화했다는 사실을 알 수 있습니다.

"인과 관계 체인"(조상과 환경을 포함하는 프로세스 트리)을 유지하는 EDR 및 CNAPP 플랫폼이 여기에서 빛을 발합니다.분석가는 이를 통해 의심스러운 작업을 원래 컨테이너 이미지, Kubernetes 워크로드, 클라우드 계정 또는 CI/CD 파이프라인으로 추적하여 근본 원인 분석과 장기적인 수정을 보다 효과적으로 수행할 수 있습니다.

컨테이너 탈출 방지: 심층 방어

단일 제어로는 컨테이너 탈출 시도가 발생하지 않을 것이라는 보장이 없으므로 코드에서 클라우드까지 계층화된 방어가 필요합니다.여기에는 이미지 위생, 최소 권한, 강화된 구성, 네트워크 제어 및 강력한 런타임 보호가 포함됩니다.

최소 권한으로 컨테이너 실행

컨테이너에서 불필요한 권한을 무자비하게 제거하는 것부터 시작하세요.매우 드물고 엄격하게 통제되는 경우를 제외하고는 권한 모드를 피하고, "내부 루트"가 호스트의 권한이 없는 사용자에 매핑되도록 루트가 없는 컨테이너나 사용자 네임스페이스를 사용하는 것이 좋습니다.

Kubernetes에서 securityContext 설정을 현명하게 활용하세요. 처럼 runAsNonRoot, runAsUser, allowPrivilegeEscalation: false readOnlyRootFilesystem: true이러한 제약 조건은 공격자가 애플리케이션 런타임을 완전히 손상시키더라도 수행할 수 있는 작업을 제한합니다.

기능의 범위는 엄격하게 지정되어야 합니다.: 기본적으로 모든 항목을 삭제하고 워크로드에 필요한 최소 세트만 추가합니다. 컨테이너에 실제로 필요한 경우 CAP_SYS_ADMIN or CAP_NET_ADMIN고위험 자산으로 취급하고, 이를 추가 모니터링과 네트워크 격리로 보호하세요.

Falco의 기능 필드를 활용하는 탐지 규칙은 통과하는 잘못된 구성에 대한 안전망 역할을 할 수 있습니다.예를 들어, 컨테이너화된 스레드가 있을 때마다 규칙이 트리거될 수 있습니다. CAP_SYS_ADMIN CAP_DAC_OVERRIDE 라는 이름의 파일에 씁니다 release_agent매우 낮은 소음으로 많은 종류의 탈출 공격을 포착합니다.

컨테이너 공급망을 확보하세요

대부분의 손상은 취약하거나 변조된 이미지 형태로 런타임 이전에 시작됩니다.강력한 이미지 보안으로 인해 공격자가 처음부터 안정적인 입지를 확보하기 어렵습니다.

신뢰할 수 있는 레지스트리에서 강화된 최소 기반 이미지를 사용하고 이를 최신 상태로 유지하세요.패키지 수가 적은 작은 이미지는 악용 가능한 CVE를 포함할 수 있는 라이브러리 수를 줄이고, Wiz나 배포판 관리자와 같은 공급업체는 이제 엄격하게 요구되는 것만 포함하는 "배포판이 없는" 기반을 제공합니다.

CI/CD에 취약성 스캐닝 및 소프트웨어 자재 목록(SBOM) 통합모든 빌드는 레지스트리에 푸시하기 전에 검사해야 하며, 노출 및 권한과 관련된 패치되지 않은 높음 또는 심각도 높은 버그가 있는 이미지는 배포에서 차단해야 합니다.

이미지 신뢰 정책으로 루프를 닫습니다.이미지에 암호화된 서명을 하고, 서명되지 않았거나 신뢰할 수 없는 이미지를 거부하도록 입장 컨트롤러를 구성하고, 시간 경과에 따라 클러스터에서 실제로 실행 중인 이미지에 대한 가시성을 유지하여 위험한 아티팩트를 신속하게 폐기할 수 있습니다.

마지막으로, 원시 CVE 수가 아닌 실제 위험을 기준으로 수정의 우선 순위를 정하십시오.추가 기능 없이 실행되는 휴면 상태의 네트워크 연결되지 않은 일괄 작업의 심각한 취약점은 민감한 데이터를 처리하는 인터넷 연결 권한이 있는 포드의 "중간" 버그보다 덜 시급합니다.

네트워크 분할 및 런타임 보호

공격자가 하나의 컨테이너에 침입하더라도 스마트한 네트워크 설계를 통해 이를 전체 클러스터 침해로 전환하는 것을 막을 수 있습니다.세분화된 네트워크 정책, 방화벽 및 서비스 메시는 측면 이동을 제한하는 데 도움이 됩니다.

허용 목록 스타일 네트워크 정책 구현 쿠버네티스에서는 포드가 실제로 필요한 서비스와만 통신할 수 있도록 합니다. 이는 공격자가 클러스터를 스캔하거나 Docker 소켓이나 쿠버네티스 API 서버와 같은 내부 관리 API를 호출하는 능력을 제한합니다.

런타임 보호 시스템은 실시간 브레이크를 추가합니다.. 컨테이너 탈출과 일치하는 동작(예: 의심스러운)을 감지하는 경우 nsenter 사용법, hostPath는 다음으로 마운트됩니다. / 또는 컨테이너 소켓 변조)를 통해 프로세스를 차단하거나 종료하고, 컨테이너를 격리하거나, 완전한 포렌식 흔적을 통해 자동으로 사고를 열 수 있습니다.

Wiz CNAPP와 같은 플랫폼은 이러한 런타임 감지를 클라우드 컨텍스트 및 보안 그래프와 결합합니다.컨테이너, 호스트, ID 및 데이터 저장소 간의 관계를 매핑함으로써 탈출이 발생했다는 사실뿐만 아니라 폭발 반경 내에 어떤 민감한 자산이 있는지도 파악하여 팀이 대응의 우선순위를 정할 수 있습니다.

지속적인 모니터링 및 사고 대비

컨테이너는 수명이 짧기 때문에 기존 포렌식 및 로그 분석이 더 어렵습니다.. 미리 이를 계획하지 않으면 포드 일정이 변경될 때 탈출을 이해하는 데 필요한 증거가 사라질 수 있습니다.

컨테이너 런타임, 오케스트레이터 및 호스트에 대한 중앙 로깅 및 메트릭 수집을 설정합니다.ELK, Prometheus 및 클라우드 기반 로그 서비스와 같은 도구를 사용하면 일시적인 워크로드에 대해서도 프로세스 활동, 보안 이벤트 및 구성 변경 사항을 캡처할 수 있습니다.

컨테이너 탈출 시나리오에 맞춰 특별히 플레이북을 만듭니다.. 이는 탈출이나 호스트 수준 손상이 의심될 때 노드를 신속하게 차단하고, 디스크 스냅샷을 찍고, 컨테이너 메타데이터를 수집하고, 클라우드 공급자나 사고 대응 팀과 협력하는 방법을 정의해야 합니다.

Palo Alto Networks(Cortex XDR, Prisma Cloud) 및 기타 공급업체는 여기에 설명된 기술을 중심으로 광범위한 탐지 콘텐츠를 구축했습니다.사용자 모드 도우미 남용부터 런타임 소켓 악용 및 민감한 마운트 액세스까지 방어자에게 일반적인 "의심스러운 활동" 소음이 아닌 실행 가능하고 맥락이 명확한 알림을 제공합니다.

견고한 Linux 격리 기본 사항, 엄격한 권한, 강화된 이미지, 네트워크 제어 및 심층적인 런타임 가시성 등 이러한 모든 요소를 ​​하나로 합치면 컨테이너가 실존적 위협으로부터 탈출하는 것을 팀이 조기에 감지하고 효과적으로 격리하며 이를 통해 학습하여 시간이 지남에 따라 클라우드 기반 보안 태세를 더욱 강화할 수 있는 관리 가능한 위험으로 전환할 수 있습니다..