eBPF는 무엇을 잘하나: HTTP 탐지가 아니라 런타임 보안

아프로·2026년 10월 30일

해킹 시도를 몇 초 안에 잡는 서버: 실시간 탐지·차단 실전

목록 보기

11/18

eBPF는 무엇을 잘하나 표지

원문은 eBPF를 이렇게 소개합니다. "애플리케이션에 수정이나 오버헤드를 주지 않고, 리눅스 커널에서 소켓 통신을 캡처해 HTTP L7 페이로드까지 디코딩한다." 매력적인 문장이지만 두 군데가 틀렸습니다. 오버헤드는 0이 아니고, 요즘 트래픽 대부분인 TLS는 소켓에서 암호문입니다. eBPF는 훌륭한 기술입니다. 다만 HTTP 공격 탐지의 1순위 자리가 아닙니다.

eBPF란

eBPF는 리눅스 커널 안에서 작은 프로그램을 안전하게 돌리는 기술입니다. 커널 모듈을 만들지 않고도 시스템 콜, 커널 함수, 네트워크 경로, 사용자 프로그램 함수에 훅(갈고리)을 걸어 무슨 일이 일어나는지 보거나 막을 수 있습니다. 훅의 종류는 이렇습니다.

kprobe / tracepoint: 커널 함수와 정해진 커널 이벤트.
uprobe: 사용자 공간 프로그램의 함수(예: TLS 라이브러리의 읽기·쓰기 함수).
LSM 훅: 커널 보안 모듈의 결정 지점.
네트워크 훅(XDP, tc): 패킷 경로.

"오버헤드 0"이 아닌 이유

eBPF 프로그램도 CPU에서 돕니다. 훅이 걸린 이벤트가 일어날 때마다 실행되고, 결과를 사용자 공간으로 넘길 때 복사가 일어납니다. 줄일 수는 있어도 0은 아닙니다.

Tetragon 문서는 커널 안에서 걸러 내는 방식이 오버헤드를 "크게 줄인다"고 설명하지만 숫자는 주지 않습니다.
Pixie(eBPF 기반 관측 도구)는 FAQ에서 보통 노드 CPU 오버헤드가 2~5%라고 적습니다.

훅을 많이 걸수록, 이벤트가 잦은 곳(예: 모든 read 시스템 콜)에 걸수록 비용이 큽니다. 도입 전에 여러분 워크로드에서 직접 재야 합니다.

TLS 문제: 소켓에서는 암호문이다

클라이언트에서 앱까지 TLS 구간과 평문 구간을 표시하고, 소켓 훅·TLS 라이브러리 uprobe·프록시가 각각 무엇을 보는지 나타낸 그림

HTTPS 요청은 앱의 TLS 라이브러리가 풀기 전까지 암호문입니다. 커널의 소켓 단계에서 보이는 것은 암호화된 바이트입니다. 평문 HTTP를 보려면 방법이 셋입니다.

TLS 라이브러리에 uprobe. Pixie는 OpenSSL(동적 링크), Go의 crypto/tls(디버그 정보 필요), BoringSSL의 함수에 uprobe를 걸어 암호화 전·복호화 후 데이터를 읽습니다. 라이브러리와 버전마다 지원이 다르고, 정적 링크나 디버그 정보가 없는 바이너리는 어렵습니다.
TLS를 앞에서 끝내기. 로드밸런서나 사이드카 프록시가 TLS를 풀면 그 뒤 구간은 평문입니다. 그런데 이 경우 프록시가 이미 HTTP를 다 보고 로그를 남깁니다.
L7 프록시로 보내기. Cilium이 이 방식입니다.

Cilium의 L7 가시성은 Envoy다

Cilium은 eBPF 기반 쿠버네티스 네트워킹입니다. 그런데 HTTP 같은 L7 가시성은 순수 eBPF가 아닙니다. L7 규칙이 있는 CiliumNetworkPolicy를 걸면 해당 트래픽을 Envoy 프록시(에이전트 안이나 cilium-envoy 데몬셋)로 돌려 보내고, Envoy가 HTTP를 해석합니다. 규칙에 맞지 않는 L7 트래픽은 떨어집니다. Hubble(Cilium의 관측 도구)은 기본으로 민감 데이터를 가리지 않으니 --hubble-redact-enabled 같은 옵션을 확인하세요.

정리하면 "eBPF로 L7을 본다"는 실제로는 eBPF가 프록시로 길을 바꿔 주고, 프록시가 본다인 경우가 많습니다. 이미 Nginx나 Envoy 로그가 있다면, HTTP 공격 탐지에 eBPF가 더해 주는 것은 적습니다. 그리고 eBPF가 무엇을 보든 주문 100458의 주인은 모릅니다. IDOR은 여전히 앱의 몫입니다.

eBPF가 빛나는 자리: 런타임 보안

HTTP 다음 단계, 즉 공격이 성공한 뒤를 보는 데 eBPF가 강합니다. Tetragon은 스스로를 "eBPF 기반 보안 관측과 런타임 강제" 도구라고 소개합니다.

프로세스 실행. 웹 서버 프로세스가 갑자기 셸을 띄운다(명령 주입이 성공했다는 신호).
파일 접근. 앱이 평소 열지 않던 /etc/ 아래 파일이나 인증서 폴더를 연다.
네트워크. 앱이 처음 보는 외부 주소로 연결한다(정보 유출, 외부 명령 서버).
권한 변화. 컨테이너 안에서 권한 상승을 시도한다.

Tetragon은 TracingPolicy로 kprobe, tracepoint, uprobe, LSM 훅에 규칙을 걸고, 맞으면 기록하거나 프로세스를 죽이는(Sigkill) 등의 조치를 할 수 있습니다. 쿠버네티스 맥락(파드, 네임스페이스)이 함께 붙습니다.

이건 WAF도, 앱 안 탐지도 못 하는 일입니다. 그래서 이 시리즈의 도입 순서에서 eBPF는 마지막이지만, 컨테이너를 많이 돌리고 침해 이후를 봐야 하는 팀에게는 꼭 필요한 방어선입니다.

이 맥에서 못 돌린 이유와 재현 방법

eBPF는 리눅스 커널 기능입니다. 이 시리즈의 실험 장비는 macOS(Apple M1 Pro)라 호스트에서 직접 돌릴 수 없습니다. Docker Desktop의 리눅스 가상 머신 안에서 권한 있는 컨테이너로 시도할 수는 있지만, 그 VM의 커널 설정과 BTF 지원을 확인하지 못했고, 측정 당시 장비 상태도 추가 실험을 하기 어려웠습니다. 그래서 eBPF 관련 숫자는 하나도 싣지 않습니다.

리눅스에서 재현하려면 이렇게 하면 됩니다.

리눅스 장비를 준비합니다. BTF(/sys/kernel/btf/vmlinux)가 있는 최근 커널이어야 합니다(예: Ubuntu 24.04 계열, 정확한 최소 버전은 Tetragon 문서에서 확인 필요).
Tetragon 문서의 "로컬 Docker 설치" 절차로 Tetragon을 띄웁니다. 이미지 태그는 문서의 최신값을 쓰세요(확인 필요).
이 시리즈의 실험실 앱(lab/app.py)을 같은 장비에서 띄웁니다.
프로세스 실행 이벤트를 켠 상태와 끈 상태에서 lab/bench.py로 p50/p99 지연과 처리량을 각각 잽니다.
파일 접근 감시 정책(문서의 파일 모니터링 예제)을 더하고 다시 잽니다.
앱 프로세스에서 셸을 띄우는 시험 코드를 돌려 이벤트가 몇 밀리초 안에 나오는지 봅니다.

결과가 나오면 이 글에 【작성자 실측】으로 더하겠습니다.

정리

eBPF는 커널 안의 훅으로 시스템을 보는 강력한 기술입니다. 하지만 오버헤드는 0이 아니고, TLS 트래픽은 소켓에서 암호문입니다.
L7을 본다는 도구도 실제로는 TLS 라이브러리 uprobe나 Envoy 같은 프록시를 씁니다. 프록시 로그가 이미 있다면 HTTP 탐지에 더해 주는 것은 적습니다.
eBPF의 제자리는 런타임 보안입니다. 셸 실행, 이상한 파일 접근, 처음 보는 외부 연결처럼 침해 이후의 신호를 봅니다.