[2026-07-10] CODA Runtime Detection of Application-Layer CPU-Exhaustion DoS Attacks in Containers

Motivation

연구 배경

• 지능적인 표적 공격: 최근의 DoS는 단순히 무차별적인 트래픽을 퍼붓는 전통적인 방식을 넘어, 표적 애플리케이션의 알고리즘이나 시맨틱(의미론적 구조)의 약점을 정밀하게 겨냥
• 자원 소모의 극대화: 공격자들은 애플리케이션 내부에서 연산 비용이 가장 많이 드는 비효율적인 실행 경로(Execution path)를 찾아내어 악성 요청을 주입. 단 몇 개의 요청만으로도 애플리케이션 계층의 CPU 자원을 압도하여 서비스를 마비
• 탐지의 어려움 : 정규표현식 취약점을 노린 ReDoS 공격의 경우, 네트워크 계층에서는 어떠한 비정상 패턴이나 대용량 트래픽 징후가 나타나지 않음.

기존 애플리케이션 계층 탐지 기법의 한계

• RAMPART : 오직 PHP 언어로 작성된 웹 프로그램만을 지원. 다양한 언어로 구축되는 현대 멀티 컨테이너 환경에 적용할 수 없음
• FINELAME : 개발자가 직접 소스 코드를 분석하고 요청의 시작과 끝을 알리는 주석(Annotation)을 코드에 추가. 소스 코드를 입수할 수 없는 Closed-source 기반의 서드파티 프로그램이나 외부 패키지가 많아 적용이 불가능
• COGO : 컨테이너 내부에 별도의 감시 프로세스를 강제로 심어야 함 → 컨테이너의 격리성을 깨뜨리고 본래의 동작에 영향을 줄 수 있음
  • 탐지 주기가 초 단위로 굼떠서 즉각 차단이 어려움

Goal

• 언어 독립적
• 소스 코드에 대한 지식 요구 X : closed source 기반의 서드 파티도 보호
• 투명한 컨테이너 모니터링 : 컨테이너 환경의 격리성을 보존. 컨테이너 내부를 침범하지 않고 밖에서 투명하게 감시하여 원래 동작에 간섭이나 영향을 주지 않음

Contribution

• 연결에 의해 소비된 CPU 시간을 모델링하고 모니터링하여 컨테이너 환경에서 CPU 고갈 DoS 공격을 탐지
• 소스 코드를 알지 못해도
• 테이너 내부의 PID를 추적하고 이를 전역 PID와 매핑하여 컨테이너 모니터링을 지원하며, 이는 컨테이너에 어떠한 간섭도 없이 투명
• 실제 환경의 애플리케이션과 공격을 대상으로 CODA를 평가. 낮은 추가 오버헤드로 정확한 탐지

Threat Model & Assumptions

Threat Model : 컨테이너에 배포된 애플리케이션의 취약점을 알고 있는 공격자

Scope : 단일 또는 다수의 클라이언트이며 배경 트래픽과 같이 전송. 기존 장비로 쉽게 방어 가능한Volumetric 공격은 제외

Assumption : 공격자도 사전 탐색 시간이 필요하기 때문에 배포 직후는 정상 트래픽만 보장되며 해당 데이터를 통해 모델 학습

CODA Design

Overview

• Architecture

  

  1. Containers tracing module : 컨테이너 내부에서 발생하는 시스템 호출(인수 및 반환값 포함)를 추적. 해당 호출의 UTS 네임스페이스 이름, PID 및 TID도 함께 추적
     • UTS 네임스페이스 : 호스트 이름과 NIS 도메인 이름을 다른 프로세스들과 완전히 격리
       • 해당 이름을 가져와서 컨테이너를 고유하게 식별
       • 원래 커널 자체에는 컨테이너나 컨테이너 ID라는 객체 개념이 없음
     • PID, TID 및 시스템 호출은 매개변수로 모니터링 모듈로 전달
  2. CPU time monitoring module : 처리 중인 연결이 소비하는 CPU 시간을 모니터링
  3. Attack detection module : 사용자 공간에서 정상 CPU 시간 모델을 학습해 임계치를 설정하고, 런타임에 CPU 소모량이 이를 벗어날 경우 공격으로 판별

• 동작 흐름

  

  1. 학습 단계 : 정상 연결이 소비하는 CPU 시간 모델링
  2. 탐지 단계 : 각 연결이 소비하는 CPU 시간을 모니터링 후 공격 탐지
     1. 컨테이너를 tracing 하기 시작
     2. accept()이 포착되면 CPU 시간 모니터링 모듈을 트리거하여 해당 연결이 소비하는 CPU 시간을 모니터링
     3. 공격 탐지
     4. close()이 포착되면 CPU 시간에 대한 모니터링을 중단

• 구동 환경 : 서버 호스트 환경에 배포. 커널 수정 없이 eBPF를 통해 커널에 주입

Containers Tracing Module

기존 방식의 한계

• 전통적인 시스템 호출 추적 도구(예: strace)는 호출마다 프로세스를 중단시키므로 오버헤드가 큼
  • 기존 방식은 프로세스를 중단 한 후 모니터링 도구가 데이터를 읽어감.
• 호스트 OS 입장에서는 컨테이너화된 프로세스와 일반 프로세스를 구분하기 힘듦

eBPF 기반 컨테이너 추적

CODA는 eBPF를 활용하여 커널을 수정하지 않고도 네이티브 속도로 시스템 호출을 추적하며, 다음과 같은 논리로 컨테이너 프로세스만 선별

• PID 네임스페이스 특성 활용 : 컨테이너가 생성될 때는 자신만의 고유한 PID 네임스페이스를 가지며, 이 네임스페이스 내부의 첫 번째 프로세스는 항상 PID 1을 할당
• PID 추적
  • eBPF 함수 bpf_get_current_task()를 호출하여 현재 실행 중인 프로세스의 디스크립터(task_struct)에 접근
    • BCC 툴킷의 attach_kprobe()와 attach_kretprobe() 함수를 사용하여 가
  • task_struct 내부의 nsproxy 포인터를 통해 네임스페이스 정보를 확인. PID가 1인 프로세스가 포착되면 새로운 컨테이너의 시작으로 간주하고 해당 PID 네임스페이스를 공유하는 모든 하위 프로세스 추적
    • 호스트 OS도 전역 네임 스페이스가 존재하기 때문에 1을 발견하고 해당하는 프로세스를 추적
    • task_struct : 프로세스 정보를 적어두는 디스크럽터
    • nsproxy : namespace proxy
• 다른 모듈들에서 활용할 수 있게 nsproxy 구조체를 통해 TID도 추적
• 후에 로깅을 하기 위해 컨테이너 구별 : 시스템 호출이 어느 컨테이너에서 왔는 지 구분
  • UTS 네임스페이스 이름을 nsproxy 구조체를 통해 얻어내고 컨테이너 ID로 설정.
• Background: 컨테이너 ID vs 네임스페이스
  • 네임스페이스 : 메모리 주소나 고유 번호. 컨테이너가 멈췄다가 다시 실행하면 초기화
  • 컨테이너 ID : User space에서 사용하는 컨테이너 식별값. 멈췄다가 다시 실행해도 유지. 하나의 컨테이너에 여러 개의 네임스페이스가 있을 수 있음
  • 커널 단에서 컨테이너를 구분하기 위해서는 간단한 번호 형태의 네임스페이스를 통해 구분
    • 네임스페이스라는 방에 컨테이너 ID라는 명패가 걸려 있음
  • 모니터링 시에도 컨테이너 ID를 통해 자원을 얼마나 썻는 지 기록
  • 탐지 모듈에서 공격을 탐지했을 때 컨테이너 ID를 통해서 네임스페이스를 확인하고 정지시키든 가 조치를 취함

CPU Time Monitoring Module

System Calls for HTTP(S) Requests

HTTP 요청을 대상으로 하지만 다른 애플리케이션 계층 공격으로 확장이 가능함.

• accept() 호출 시 측정 시작. close() 시 측정 종료
  • HTTP 통신은 TCP 위에서 동작하므로 TCP를 추적하여 측정
  • HTTP 자체는 애플리케이션 프로토콜이라 시스템 콜이 없어 언제 시작되고 끝나는 지 모르기 때문에 TCP 단에서 함
• 위와 같은 방식으로 작성됐기 때문에 언어와 상관 없고 개발자가 모니터링을 위해 소스 코드를 수정하지 않아도 됨

PID/TID Mapping

• 측정하는 PID/TID는 컨테이너 내부의 로컬 번호이므로 이를 global PID/TID로 매핑
  • 호스트에서 컨테이너 내부의 CPU 사용량을 확인
• 용어 차이
  • User space : 프로세스 번호는 PID, 스레드 번호는 TID
  • Kernel Space : 프로세스 번호는 TGID(Thread Group ID), 스레드 번호는 PID. 논문에서는 k-PID라고 명명
• 동작 흐름
  1. accept() 호출이 트리거될 때, bpf_get_current_pid_tgid()라는 eBPF 함수를 호출
  2. accept()가 TGID와 k-PID를 리턴
  3. Containers Tracing Module이 주는 PID와 TID를 TGID와 k-PID를 매핑

CPU Time Monitoring

• PID-TID 쌍은 thread의 고유식별값이며 이 하나의 thread는 한 개의 연결을 처리
• 동작 흐름
  1. 커널이 accept() 호출하면 accept()가 해당 소켓의 파일 디스크립터에 해당하는 양의 정수 번호를 리턴
  2. close()할 때, 소켓 번호를 인자로 넣고 연결을 끊음.

  → close()의 인자값과 accept()의 리턴값이 같으면 모니터링을 중단

• 현대 애플리케이션 : 연결을 설정하고 처리하는 작업이 서로 다른 스레드에 의해 수행될 수 있음.
  1. 단일 프로세스/ 단일 스레드 환경 : 위의 방식대로 처리
  2. 멀티 프로세스/ 멀티 스레드 환경 : 각 프로세스/스레드가 독립적으로 연결을 수락하고 처리. 동시에 요청을 처리하고 있어도 결국은 연결과 스레드는 1대1로 매핑
  3. 멀티 프로세스 / 멀티 스레드 환경 중 부모-자식 모델
     • 동작 흐름
       1. 하나의 프로세스나 스레드가 연결 수락
       2. 부모 process/thread가 sub-process/thread를 clone하여 생성 후 대기로 돌아감
          • sub-process/thread는 각기 다른 PID/TID를 가짐
       3. sub-process/thread가 연결을 처리하고 종료
     • CODA는 clone() 시스템 콜을 추적하여 하위 PID/TID를 기록하고 close() 전까지 sub-process/thread의 자원 사용량 추적
  4. Process Pool/Thread Pool : 여러 개의 thread를 미리 유지하고 연결 수락 후 관리 프로그램이 작업을 할당
     • thread clone을 하지도 않고 소멸하지 않아서 TID가 변하지 않음
     • CODA
       1. Thread Pool에 있는 제한된 수의 TID를 기록
       2. accept() 시 기록된 TID들을 바탕으로 Thread Pool 내의 Thread들이 소비하는 CPU 시간을 모니터링
       3. close() 트리거 시 종료
          • 대부분 이 4가지에 속하며 관리자가 서버에 맞는 모니터링 방법을 채택
• 실제 CPU 사용 시간과 accept-close 시간의 차이 : 컨텍스트 스위치 등으로 항상 CPU를 점유하지는 않음.
  • 컨텍스트 스위치 시 호출되는 finish_task_switch()을 통해 CPU 사용 시간을 확인
  • 위 함수가 호출될 때, bpf_get_current_pid_tgid()를 통해 현재의 k-PID와 TGID를 얻고, bpf_ktime_get_ns() 함수를 통해 타임스탬프를 얻어 어떤 프로세스가 얼마만큼 컨텍스트 스위치 했는 지 알 수 있음

Attack Detection Module

정상 CPU 시간 모델을 통해 임계값을 설정하여 연결마다 CPU 시간을 비교함. 임계값 이하면 정상(0), 초과하면 공격(1)로 판별

• 컨테이너 내부에서 제공하는 서비스는 대체로 하나의 서비스
  • 하나의 컨테이너 내부에서 소모하는 CPU 시간은 비슷할 것
  • 각 컨테이너마다 서비스가 다르기 때문에 임계값이 달라야 함. 다른 모델 사용
• 임계값과 성능의 트레이드오프 : 높게 설정하면 미탐이 높아지고 낮게 설정하면 오탐이 높아짐
  • 악성 공격이 효과를 보기 위해서는 아주 많은 CPU 시간을 소모시켜야 하므로 임계값을 높게 설정

  • 설정 공식

    \[P(|t - m| > ks) \le \frac{1}{k^2}\] \[t = \max(t_{max}, m + ks)\]
    • $t_{max}$ : 학습 데이터셋(정상) 중 가장 큰 시간
    • $m, s$ : 학습 데이터셋의 데이터의 평균과 표준 편차
    • 체비쇼프 부등식 : 분포가 어떻든 무조건 성립하는 법칙
      • 트래픽의 분포를 가정하지 않음
      • 무작위 t가 표준 편차의 k배 떨어져 있을 확률은 $\frac{1}{k^2}$
    • $m + ks$ : 통계적 한계선.
    • 두 번째 수식 : 더 큰 값을 기준선으로 쓴 다는 것 → 오탐 감소
• eBPF 제약
  • 부동 소수점 연산 지원 X : 임계값 $t$에 $10^a$를 곱하고 반올림하여 정수값 $t’$를 얻어냄.

Evaluation

Setup

서버(Intel i7-8700k CPU와 16GB RAM 환경)와 클라이언트(Intel i5-6200u CPU와 8GB RAM 환경)은 LAN으로 연결

1. 컨테이너 1 : Node.js 사용. 단일 thread
   • tough-cookie라는 쿠키 파서를 사용. ReDoS에 취약
2. 컨테이너 2 : Apache. 멀티 프로세스로 구성
   • WordPress를 사용하여 구축. 비밀번호 해시값을 계산할 대 길이를 제한하지 않기 때문에 발생하는 해시 연산 취약점.
     • 긴 비밀번호를 사용하여 CPU 자원 소진
3. 컨테이너 3 : Flask. 하나의 스레드가 연결을 수락하고 처리를 위해 하위 스레드를 생성하는 multi-thread
   • 비밀번호 강도 측정기인 zxcvbn을 사용. 알고리즘 복잡도 취약
     • 비밀번호 강도를 계산할 때 모호한 특수 문자로 이루어진 긴 비밀번호를 집어넣어 막대한 CPU 시간 소모
4. 컨테이너 4: Tornado. thread pool을 구축
   • XML 파서 사용. XML Bomb (Billion laughs)에 취약

Overhead

• Baseline
  • 트래픽 생성 : Siege 도구를 사용
    • 연속된 연결의 간격은 0.1초로 극한의 상황보다는 느리지만 실제 환경보다는 일반적으로 빠름
  • 컨테이너와 내부 애플리케이션은 기본으로 설정
    • 컨테이너마다 5회 실험 반복. 180초 동안 진행
  • 지연 시간의 중앙값을 선택하고 5번의 중앙값 평균을 baseline으로 잡음

  • 결과

    

    • 32명을 넘지 않을 때는 괜찮았지만 64명 이상으로 가는 경우 성능 저하 발생
      • CODA로 인한 성능 저하인지 세션이 많아서 발생하는 성능 저하인지 구분이 안감
    • 이후 실험에서 32명의 사용자 세션을 사용

• CODA

  

  • 0.7 ~5ms 정도의 지연시간이 추가됨
    • 1ms 정도는 인지할 수 없음
  • baseline의 지연 시간이 짧은 경우만 오버헤드 증가 비율이 높게 나옴
  • 다른 연구와 비교 : 1 ~ 7ms 지연 시간추가
    • 실험 설정과 네트워크 환경이 다르기 때문에 엄밀한 비교는 불가

  • 공격 탐지의 오버헤드

    

    • 공격 탐지로 인한 지연 시간은 크게 증가하지 않았고 대체로 컨테이너 모니터링 과정에서 지연 시간 발생

Performance

• Setup
  • 실험 진행
    • 0 ~ 200초 : 정상 요청만 전송하여 공격 탐지 기준 학습
    • 200 ~260초 : 정상 + 악성 요청
    • 260 ~300초 : 정상 요청
  • QoS를 저하시키는 수준으로 조절
  • 임계값 k = 4, 소수점 a = 4로 설정
  • 탐지 속도 측정 : 악성 연결의 수명 대비, 공격이 탐지된 시점부터 해당 연결이 종료될 때까지 남은 시간의 비율

• 컨테이너 1 : 32개의 사용자 세션. 초당 2개의 연결을 생성. 각 연결은 10개의 정상 요청을 포함하여 초당 640개의 요청을 생성. 그 중 16개가 악성
  • 공격의 강도가 증가함에 따라 서버 다운을 방지하기 위해 공격 비율을 줄임
• 컨테이너 2, 3, 4 : 어떤 환경이든 어떤 공격이든 높은 탐지율과 빠른 탐지 속도를 가짐

Discussion

• 다른 애플리케이션 계층에서의 확장 : 현재는 TCP 기반의 HTTP(S) 기준
  • UDP 기반은 recvfrom과 close 시스템 호출이 진입점과 종료점을 나타내는 데 사용
  • CPU가 아닌 다른 자원으로 확장
    • tcp_sent 커널 함수를 통해 TCP 연결을 통해 전송된 바이트 양을 알아냄
• eBPF에서 kprobes의 한계
  • 동시에 추적할 수 있는 호출 횟수에 제한이 있음
  • 일부 추적을 놓칠 수 있지만, 커널과 도구의 발전으로 동시 연결 1000까지 테스트해봤지만 누락이 없었음
• 운영체제의 확장
• 탐지 이후의 시나리오

생각

단일 컨테이너가 단일 서비스를 제공하지 않을 때 문제?

공격 요청은 단일 또는 다수의 클라이언트

정상 때 너무 긴 시간이 들어온다면??? → 전처리 해야 하나