[2026-07-06] Detecting Asymmetric Application-layer Denial of Service Attacks In Flight with FINELAME

Motivation & Background

Asymmetric DoS

애플리케이션의 알고리즘적, 의미론적 또는 구현상의 특성을 표적으로 삼아 적은 양의 트래픽과 공격자의 자원만으로 자원의 가용성을 침해하는 공격.

• Type
  • Regular-expression DoS (ReDoS) : 정규표현식을 사용하는 프로그램을 표적으로 삼음. 알고리즘의 worst case를 유도
    • ex) (a+)+ 같은 정규식 : a가 들어가 있는 상자가 1개 이상 있는 지 확인. aaaaX인 경우.
      • 상자 1개 : aaaa 확인 후 X가 있음으로 다시 돌아감
      • 상자 2개 : aaa a 확인 후 X가 있음을 확인. aa aa 이후 X가 있음을 화ㄱㄱ인
      • 이 과정을 상자 4개까지 해서 여러 번 함
  • XML Bomb : XML 문서에 Entity라는 단축어 기능이 있음. 해당 기능을 악용하여 지연 시간이 증가
    • ex) &A; → 하하하하하하하하하, &B; → &A;&A;&A;&A;&A;&A; &C; → &B;&B;&B;…
    • 공격자의 텍스트는 조금이지만 서버에서 파싱을 할 때 용량이 커짐
  • Improper (de-)serialization : 디코딩하는 과정에서 for (;;) {} 같은 무한 루프 코드를 주입하여 프로세스를 중단
  • Event-handler Poisoning (EHP) : 싱글 스레드 기반 Node.js 같은 경우에는 하나의 요청이 이벤트 핸들러를 붙잡고 있는 순간에 다른 웹 요청이 멈춰 버림
• 방어 방법의 부재
  • 네트워크 기반 방어 : 네트워크 수준에서 식별 가능한 문제 패턴이 부족
  • DPI 뿐만 아니라 어떤 요청이 자원을 독점하는 지 사전에 예측해야 하지만 실행 전까지는 모름
  • 애플리케이션 수준 방어
    • 현대 웹 서비스의 코드는 오픈 소스와 라이브러리 위주이며 외부 패키지들은 소스코드를 볼 수 없는 컴파일된 바이너리 형태이기 때문에 블랙 박스 환경에 방어 로직을 넣기 힘듦
    • 현대 애플리케이션은 여러 언어로 만들어짐. 모든 언어와 런타임의 특성을 다 이해하고 맞는 방어 코드를 작성하는 것은 어려움
    • 수동으로 요청을 추적하는 감시 코드를 넣는 것은 비용이 많이 들며 위험한 작업

Design goal

• 실행 중 탐지 : 요청을 실행해야 악성임을 알아차릴 수 있으며 하나의 요청만으로 시스템이 무너지기 때문에 사후 대응 방식 역시 불가능
• 자원 독립성 : ADoS는 여러 자원을 타겟으로 해서 Solution은 자원 종류에 종속되면 안됨.
• 컴포넌트 간 추적 : 애플리케이션은 여러 내부 컴포넌트나 처리 단계를 건넘. 공격자는 이 컴포넌트 사이의 경계를 넘나들며 자원을 갉아먹기 때문에, 어떤 컴포넌트에서 자원이 소모되든 상관없이 최초의 웹 요청 ID 하나로 끝까지 추적해서 자원 사용량을 일원화
• 언어 독립성 : 애플리케이션들이 여러 언어로 작성되며 다양한 라이브러리를 사용하므로 종속되면 안됨.
• 개발자 노력의 최소화 : 탐지 시스템은 DevOps 환경에 최소한의 부담을 줘야 하며 내부 구조를 잘 몰라도 됨.

Threat Model

Threat Model

1. 공격자는 취약한 애플리케이션을 호스팅하는 서비스에 임의의 요청을 보낼 수 있음
2. 공격자는 애플리케이션에 있는 모든 일반 클라이언트를 제어
3. 공격자는 애플리케이션의 내부 구조와 취약점을 알고 있음
   • CPU 자원뿐만 아니라 모든 자원을 대상으로 공격
   • 일반 클라이언트와 악성 클라이언트를 구분하지 않음

Assumptions

1. 백도어 같은 악성 코드가 아님
2. 최소한 어느 정도의 정상적인 트래픽(benign traffic)이 들어와야 함
   • 100% 악성 트래픽만 들어오는 경우 ML이 잘못 학습
3. 단일 요청이 사용하는 소비된 자원을 알 수 있음

FINELAME

Request Mapping

각 컴포넌트와 처리 단계에 대해 처리의 시작과 끝, 그리고 자원 사용량이 귀속되어야 할 대상 요청을 구분

• startProcessing() : 처리 단계의 시작을 나타냄. 이 지점 이후에 발생하는 자원 사용이나 할당도 새롭게 들어온 고유한 요청의 몫으로 할당
• attributeRequest(reqId) : PID를 결정할 수 있게 되면 처리 단계를 요청 ID에 매핑
• endProcessing() : 처리가 완료.
• EX) 네트워크 패킷 과정
  1. NIC에 패킷이 들어오면 Queue에서 패킷을 꺼낼 때 startProcessing을 실행하며 자원을 기록
  2. 처음에는 패킷이 어떤 웹 요청인지 모르지만 TCP 계층이 되어서야 5-tuple을 확인하여 ID를 기록. 이 순간 attributeRequest(reqID)를 호출하여 startProcessing에서부터 측정한 자원을 해당 ID에 할당하며 이후 과정도 해당 ID로 할당
• 배경 작업 (ex. 가비지 컬렉션) 같은 공유 오버헤드는 분할하거나 확률적으로 할당
  • 순수하게 애플리케이션에서 발생한 오버헤드는 할당하지 않을 수 있음
• OS의 thread/process와 식별자(ID)의 동기화 : 어떤 thread가 어떤 ID를 처리하는 지 매핑
  • 식별자는 네트워크 단에서는 5-tuple, 애플리케이션에서는 메모리 주소일 수 있음.
  • 후에 식별자가 통합됨.
  • 최적화 : ID 발급과 OS 스레드 간 매핑이 한 번에 해결
    • 이벤트 기반의 프레임워크나 스레드 풀 기반은 요청의 entry point가 하나거나 적음
      • 해당 진입점에 request-mapper를 손쉽게 부착

Resource Monitoring

context switches, mallocs, page faults 같은 작은 단위에서 실행중인 요청의 자원 사용량을 추적

eBPF

• BPF : 리눅스 커널 네트워킹 하위 시스템의 구성 요소. 커널 이벤트에서 생성된 데이터를 필터링하는 데 사용되는 단순한 언어를 해석하는 가상 머신(Virtual Machine)
  • JIT(Just-In-Time) 컴파일러 개발로 실행 중에 최적화
• eBPF : BPF + 더 많은 레지스터와 네이티브 RISC ISA(명령어 집합 아키텍처)를 모방한 명령어 집합을 사용 + 제한된 커널 함수의 일부를 호출 + 해시 형태의 데이터 구조를 통해 kernel-space에서 user-space으로 데이터를 공유
  • 사용자가 C언어를 통해 작성한 프로그램을 컴파일러를 통해 low-level의 eBPF 코드 생성
  • 검증기에서 부동 소수점 금지, 명령어 수 제한, 무한 루프 금지 등의 제약이 있음

Architecture

다양한 사용자 및 커널 공간의 데이터 소스 (스케쥴러, TCP 스택) 등에 attach

• Feature

  

• 동작 흐름
  1. 현재 PID에 요청 mapping 활성화 확인. 아닌 경우 exit
  2. 활성화된 PID인 경우 metrics를 수집하고 timestamp와 함께 공유 데이터 구조에 저장
  3. 자원 사용량을 바탕으로 모델 파라미터와 비교하여 요청에 대해 이상 탐지 수행
• 커널 함수
  • CPU 자원 : 점유 시간 (cputime)을 측정
    • scheduler_tick() : 타이머 인터럽트
    • finish_task_switch() : 컨텍스트 스위치
    • 스레드가 스케쥴링되어 시작할 때부터 스왑 아웃(CPU에서 내려옴)
  • TCP 자원
    • 송신 바이트(tcp_sent), 수신 바이트 (tcp_rcvd) 추적
      • tcp_sendmsg(), tcp_rcleanbuf()
    • TCP 송신자 유휴 시간 (tcp_idle_time)
      • 두 번의 tcp_cleanup_rbuf() 사이의 경과 시간
      • 데이터를 지연 전송하는 Slowloris나 RUDY와 같은 저속 공격 탐지에 필수적
    • 메모리 자원
      • 힙 메모리 할당량
        • malloc
      • 페이지 폴트 발생 횟수
        • exception:page_fault_user : 커널 트레이스 포인트
• 이외에도 사용자 정의 eBPF 프로그램을 통해 사용자 공간의 임의의 지점(probe points)를 부착할 수 있음
  • 큐 길이나 해시 테이블 점유율과 같은 애플리케이션 특화 지표를 추가로 모니터링하여 탐지 범위 확장

Attack Detection in FINELAME

• 수집한 각 feature에 대한 n 차원 공간에서 전체적인 좌표의 위치를 종합적으로 평가. 여러 feature를 속이는 mutil-vector 공격을 식별
• 알고리즘
  • 선정
    • 학습 복잡도, 예측 복잡도, 학습 데이터의 양 때문에 알고리즘이 제한적
    • 거리 기반 : 정상 Cluster를 형성하여 새로운 데이터와의 거리 측정을 통해 이상 탐지
      • DBSCAN 같은 경우 모든 core와 거리를 측정하기 때문에 학습 복잡도 증가로 힘듦
    • 예측 기반 : function을 만들어서 오차가 큰 값을 통해 이상 탐지
      • 신경망 같은 경우 많은 파라미터의 행렬 곱셈을 무한히 반복해야 하는 데 eBPF 내에서 무한 루프가 불가능. eBPF의 명령어 제한에 걸림
  • K-Means 사용 : user-space에서 학습된 K-means의 centroid를 통해 거리를 측정하여 이상 탐지
    • K 값 설정 : 애플리케이션이 처리하는 요청 유형의 개수를 설정했을 때, 탐지 정확도를 유지하면서 오버헤드를 최소화
    • 학습 과정
      1. 정상 데이터 수집 : 탐지를 보류하고 eBPF 공유맵에 축적
      2. 데이터 전처리 : 모든 자원 지표 단위 차이를 없애기 위해 평균 0, 표준 편차 1로 맞추는 표준화 작업 수행
      3. 학습 후 eBPF로 모델 배포
         • 파라미터 : Centroid, 평균 및 표준편차(데이터들을 표준화 하기 위한 값), 임계값
• 모델 학습 및 배포
  • eBPF에서는 부동 소수점 명령어에 접근이 불가능하여 평균과 표준 편차 등에서 문제가 발생.
    • 고정 소수점 연산 및 비트 시프트. $10^a$를 곱해 정수로 만듦
    • 표준화 공식 :
    \[x_{new} = \frac{x \cdot 10^a - \mu \cdot 10^a}{\sigma \cdot 10^b}\]
  • 반복문 및 루트 연산이 금지되어 유클리디안 거리 대신 절댓값을 더하는 L1 거리 점수를 사용
  • 단순 DDoS 공격은 자원을 극단적으로 적게 사용하기 때문에 이상치로 탐지될 수 있음. 거리 점수에 음수 점수를 추가해 DDoS에 대해서 ADoS 요청만 양수를 갖고 flag를 꽂아 차단함
    • DDoS는 제외하고 ADoS만 타겟팅

Use Case

• Apache 웹 서버 : 다중 처리 모듈(MPM, Multi-Processing Modules)에 의해 구현. 여러 작업자 스레드(worker threads)를 가질 수 있는 여러 프로세스에 의해 처리되며, 각 스레드는 한 번에 하나의 연결(connection)을 처리
  1. 요청이 들어오면 작업자 스레드에 배정(dispatch)되기 전에 이를 담아둘 conn 객체가 core_create_conn 함수에 의해 생성
     • core_create_conn에 1개의 요청-맵퍼를 부착. 고유 식별자를 생성
     • HTTP 처리 함수들에 2개의 요청-맵퍼를 부착
       • 함수 진입 시 호출되는 uprobe
       • 함수 반환 시 호출되는 uretprobe
     • conn 객체를 활용하여 고유 식별자(ID)를 생성하고 이를 처리하는 작업자 스레드에 맵핑
       • 이 맵핑은 함수가 반환(return)되고 요청이 시스템을 빠져나갈 때 해제(undone)
       • 작업자 스레드가 새로운 요청을 실행할 때, 요청-맵퍼는 새로운 요청의 ID로 맵핑을 업데이트
  2. conn 객체는 ap_process_http_sync_connection 또는 p_process_http_async_connection 함수에 의해 처리
• Node.js : 작업 풀에 작업을 떠넘기는 비동기적 모델. 계측이 어려움. 7개 사용자 공간 함수에 eBPF 프로브를 부착
  • uv_accept: 새로운 요청이 초기화되며, 클라이언트와의 통신을 처리하는 uv_stream_t 구조체와 연결됩니다.
  • uv__read 및 uv__write: 클라이언트의 스트림과 연결된 요청이 해당 함수가 실행되는 동안 ‘현재 스레드’에 할당됩니다.
  • uv__work_submit: ‘현재 스레드’에 할당된 요청이 작업 풀(worker pool)에 제출되는 작업 요청(work-request)과 연결됩니다.
  • uv__fs_work 및 uv__fs_done: 작업 요청과 연결된 요청이 현재 (작업자) 스레드에 할당됩니다.
  • uv_async_send: 요청이 현재 스레드에서 할당 해제(unassigned)됩니다.
• DeDoS : 여러 개의 독립적인 소프트웨어 컴포넌트들이 이벤트 큐(Queue)를 통해 통신하는 분산형 구조
  • 프레임워크가 자체적으로 제공하는 ‘분산 요청 추적 ID’를 그대로 가져와 이벤트 핸들러 스레드의 PID와 직접 맵핑
  • 모든 컴포넌트가 공통으로 사용하는 단일 이벤트 수신 함수인 receive() 클래스에 프로브를 부착

Evaluation

Setup

• 하드웨어 및 시스템 인프라
  • 서버 머신: Intel Xeon Silver 4114 (12 Cores, 2.20GHz), 62GB RAM
  • 클라이언트 머신: Intel Xeon E5-2630L v3 (1.80GHz), 62GB RAM
  • 통제 조건: 하드웨어 레벨의 성능 왜곡을 막기 위해 하이퍼스레딩(Hyperthreading) 및 DVFS(동적 전압 및 주파수 스케일링)를 모두 비활성화 처리함
    • 하이퍼스레딩 : 물리적 CPU 1개를 두 개의 논리적인 코어 2개인 것처럼 작동. CPU 사용량 측정이 힘들어짐
    • DVFS : 저부하에서는 전력 소모를 줄이고 고부하 작업에서는 속도를 올리는 전력 관리 기술
• 웹 플랫폼 및 취약점 세팅
  • Apache (v2.4.38)
    • 구조: 멀티 프로세싱 모듈(MPM) 기반, 50개의 Worker threads할당.
    • 콘텐츠 및 제약: 위키피디아 페이지 서비스 제공, 모든 연결에 20초의 타임아웃 강제.
  • Node.js (v12.0.0-pre)
    • 구조: 비동기 이벤트 루프 기반, libuv 작업 풀에 기본값인 4개 Worker threads 할당.
      • 메인 로직은 싱글 스레드이지만 무거운 I/O 작업은 libuv 라이브러리를 통해 worker thread가 작업
    • 취약점 세팅: 파일 경로 탐색을 위해 URI 정규표현식을 파싱하는 과정에서 ReDoS(정규표현식 DoS, CPU 마비) 공격에 취약한 liburi 파서를 연동함.
      • liburi : URL이 맞는 지 분석(Parse) 해주는 모듈
  • DeDoS (이벤트 기반 마이크로서비스 프레임워크)
    • 구조: 소켓 읽기, HTTP 파싱, 파일 서비스, XML 파싱, 정규표현식 파싱, 응답 쓰기 등 여러 컴포넌트로 분산 구현.
    • 취약점 세팅: POST 요청으로 업로드된 무작위 XML 파일을 처리하는 컴포넌트에 Billion Laughs(XML 붐, 메모리 폭파) 공격에 취약한 libxml2 파서를 연동함.
      • libxml2 : XML 문서 파서
• 트래픽 생성 모델
  • 정상 트래픽: 부하 테스트 도구인 Tsung을 활용하여 서버가 제공하는 모든 엔드포인트를 균등하게 탐색.
    • 실제 사용자 접속 패턴과 가장 유사한 지수 분포를 따르도록 유동적인 부하 생성.
      • 정상 트래픽은 몰릴 때가 있고 트래픽이 거의 없을 때도 있음. 이런 패턴과 유사한 통계 모델이 지수 분포
  • 악성 트래픽
    • ReDoS 및 Billion Laughs 공격: 연구진이 자체 제작한 C 언어 기반 공격 클라이언트 사용.
    • Slowloris 공격: 공개된 공격 도구인 pylorys 사용.
    • 정상 트래픽과 달리 공격 효과를 극대화하기 위해 일정한 간격의 고정된 부하(Fixed load)를 지속해서 전송하도록 설정.

FineLame Performance

attack

서버 다운보다는 QoS 저하 수준으로 진행

• 종류
  • ReDoS (정규표현식 DoS)
    • 원리: 악의적으로 조작된 정규표현식을 전송. 악성 문자의 수에 따라 CPU 처리 부하가 기하급수적으로 증가.
    • 영향: CPU 자원 선점으로 인해 정상 요청들이 Queue에 오래 머물게 되어 응답 속도가 현저히 느려짐.
  • Billion Laughs (XML Bomb)
    • 원리: 여러 단계로 중첩된 엔티티를 포함한 XML 파일 전송. 문서 깊이에 비례하여 Parsing. 비용이 기하급수적으로 증가.
    • 영향: ReDoS와 유사하게 시스템 자원을 고갈시킴.
  • SlowLoris
    • 원리: 서버의 타임아웃보다 짧은 주기로 HTTP 헤더를 개별 전송하여 요청을 완료하지 않고 연결을 장시간 유지.
    • 영향: 서버의 Connection pool을 고갈시켜 새로운 정상 요청을 받을 수 없게 만듦. 정상 트래픽 급증 시 서버 대응력을 무력화하는 휴면 공격(Dormant attack)으로도 작용함.

Anomaly Detection Performance

• 임계값의 설정: 훈련 데이터셋 내 각 Cluster의 최외곽 점(가장 자원을 많이 소비한 정상 요청)으로 설정
• 트레이드오프
  • 장점 : 임계값을 높게(보수적으로) 잡음으로써 운영자가 기피하는 오탐률을 낮출 수 있음.
  • 단점 : 공격 강도가 약할 경우 탐지가 늦어지거나 안 될 수 있음.
  • 타당성: 약한 공격만으로는 시스템을 마비시킬 수 없으며, 공격자가 서버를 다운시키려면 공격 방식을 Volumetric으로 전환하여 자원 소비량을 늘려야 하므로 탐지가 가능함.
• 평가 지표 (Metrics):
  • TPR(실제 공격 탐지율), TNR(정상 요청 판별율), F1-Score(정밀도와 재현율의 조화평균)를 종합적으로 활용하여 평가.
• 실험
  • 타임라인
    • 0 ~ 180초: 정상 트래픽만 유입. FINELAME이 데이터를 수집하며 학습 준비.
    • 180 ~ 200초: K-means 이상 탐지 모델 훈련 완료 및 커널(eBPF)에 파라미터 배포.
    • 200 ~ 350초: 해커의 공격(ADoS) 시작 (150초간 지속).
    • 350 ~ 400초: 공격 종료, 다시 정상 트래픽만 유입.
  • 제안 방식인 커널 내 정수 연산 + L1 거리와의 비교를 위해 user-space에서 실수 연산 + L2 거리
  • 설정값 : $K=3$ (요청 유형), 시프트 계수 $a=10, b=6$

• 결과

  

  • ReDoS
    • 타겟 : Node.js / CPU 고갈
    • 공격 강도별 지연 현상
      • 정상 상태 : 0.8ms
      • 약한 공격 (10 req/s): 악성 요청 처리에 23ms(28.75배) 소요. 정상 요청도 4ms로 지연.
      • 중간 공격: 악성 요청 처리에 45.6ms(57배) 소요. 정상 요청 13.5ms로 크게 지연.
      • 강한 공격 (1 req/s): 악성 요청 처리에 90.9ms(113.6배) 소요. 정상 요청 6ms 지연.
    • 방어 성과 : 최소 80.9% ~ 최대 95.3% 더 일찍 탐지. 사용자 공간에서의 원본 K-means와도 정확도 차이가 미미
  • Billion Laughs / XML Bomb
    • 타겟 : DeDoS / 메모리 및 CPU 고갈
    • 공격 강도별 지연 현상 : 트래픽 환경은 250~750 req/s로 변동성 있
      • 정상 상태 : 6.87ms
      • 약한 공격 (15 req/s): 평균 29.28ms (4.26배 지연).
      • 강한 공격 (1 req/s): 평균 203ms (29.55배 지연).
    • 방어 성과 : 약한 공격은 78.83%, 강한 공격은 최대 97% 더 빠르게 탐지
  • SlowLoris
    • 타겟: Apache / 네트워크 연결 고갈
    • 방어 성과 : TCP 유휴 시간이 비정상적으로 길어지는 것을 보고 단 5초 만에 탐지. 75% 빠름

Related Work

In-kernel Detection

• Radmin, Cogo 등 기존의 커널 기반 방어 시스템
  • 학습에 수 분~수 일이 소요되며, 공격을 탐지하는 데 수 초가 걸림
  • 추적 단위가 프로세스나 연결 단위여서 정밀한 악성 요청 판별이 어려움
• FINELAME : 학습은 수 초~마이크로초 내에 완료하며 공격 탐지는 ms 단위의 In-flight 탐지.
  • 개별 요청 단위로 추적하여 정상 트래픽 사이에 섞어 보내는 공격을 탐지 및 원인 분석이 가능

Application-based Detection

• 기존 기술의 한계
  • DSHIELD : 서버의 모든 실행 경로를 사전에 파악하고 있어야 함
  • BreakApp : 개발자가 직접 차단 기준(Threshold)을 수동으로 입력해야 함
  • Rampart : PHP 등 특정 언어나 CPU 자원에만 국한되어 작동함.
• FINELAME : 정상 트래픽을 관찰하여 스스로 학습하므로 사전 지식이나 소스 코드 수정이 전혀 필요 없음
  • 여러 언어나 애플리케이션에서 범용성 있게 탐지

Performance Anomaly Detection

• Magpie, X-trace, X-ray 등의 기존 성능 이상 탐지 : 사후 분석에 머뭄
• FINELAME : In-flight에 실시간으로 탐지

기타 기존 방어 기법

• Volumetric DoS : ADoS에는 무용지물
• 프로그래머 수동 어노테이션 : 개발자가 코드에 직접 자원 한도를 명시하는 것은 비현실적

Contribution

• 역호환성 : 애플리케이션 소스 코드나 리눅스 OS 커널 수정이 필요 없는 플러그인 형태
• in-flight 탐지 체계
• 플랫폼/언어와 상관 없는 자원 모니터 및 관련 라이브러리를 제공
• FINELAME의 eBPF 기반 구현 및 평가
• 커널 내 초경량 ML 구현

내 생각

1. 한계
   • ADoS로 타겟이 작음.
   • 탐지 시 정상 트래픽만 온다는 가정이 있어야 함
   • ML이라 역시 concept drift
   • 유지 보수 : Apache의 core_create_conn이나 Node.js의 uv_stream_t 같은 내부 핵심 함수명과 구조체가 버전에 따라 달라질 수 있음
   • 논문에서는 실험을 위해 서버가 처리하는 요청의 종류(K)를 3개($K=3$)로 단순화했습니다. 하지만 실제 엔터프라이즈 환경(예: 넷플릭스, 아마존)의 마이크로서비스는 수백~수천 개의 서로 다른 API(요청 유형)를 가짐. 실시간으로 모든 중심점(Centroid)과의 거리를 계산한다면 eBPF의 연산 제약(명령어 수 제한)에 걸리거나 오버헤드가 급증할 위험이 있음