시리즈를 시작할 때 질문은 "해킹 시도를 몇 초 안에 잡을 수 있나"였습니다. 실험실의 답은 이렇습니다. 잡을 수 있습니다. 다만 가장 빨리, 가장 정확하게 잡은 것은 비싼 도구가 아니라 앱 안의 작은 코드였습니다. 이번 글은 측정 결과를 모아 도입 순서를 정합니다. 숫자는 모두 이 실험실의 합성 트래픽(정상 150명, 공격 6종, 모의 시각 2시간, 2026-10-30~31 실행)에서 나왔습니다.
효과가 컸던 것
| 방법 | 잰 결과 |
|---|---|
| 객체마다 인가 검사 | 남의 주문 유출 657건 → 0건 |
| 거부된 서로 다른 객체 수(신원 기준, 10분·3개) | IDOR 열거 4종 모두, 오탐 0명 |
| 미끼 주문(2%) | IDOR 열거 4종 모두, 오탐 0명. 느린 열거도 40분(모의 시각)에 |
| 검증 실패 수(5분·3개) | 파라미터 퍼징을 3번째 요청에, 오탐 0명 |
| 섀도 모드로 먼저 재기 | 대응받은 정상 사용자 6명 → 1명 |
공통점이 있습니다. 모두 앱이 이미 내린 판단(주인이 아니다, 스키마에 없다, 미끼다)을 셉니다. 판단이 정확하니 세는 것도 정확합니다.
기대보다 약했던 것
| 방법 | 잰 결과 |
|---|---|
| WAF(OWASP CRS) | 교과서 공격 표본 10건은 모두 막음. IDOR 요청 660건은 PL1~4 모두 하나도 못 막음. PL3부터는 한국어 검색어가 막혀 정상 사용자 112명이 403 |
| 403·404 급증(1분·10개) | 빠른 열거만. 느린 열거와 계정 바꾸기 놓침 |
| 요청 수(1분·120개) | 폭주 수집은 잡음. 열거는 빠른 것 하나만 |
| IP 기준으로 세기 | IP를 바꾸는 열거를 어떤 규칙으로도 못 잡음. CGNAT 뒤 정상 50명을 한 덩어리로 |
| 탐지 + 단계적 대응(소유권 검사 없을 때) | 유출 657건 → 194건. 줄었지만 0은 아님 |
약했다는 말이 쓸모없다는 뜻은 아닙니다. WAF는 자기 일(주입 범주)을 잘했고, 요청 수 규칙은 폭주를 잘 잡았습니다. 다만 IDOR과 느린 열거에는 맞지 않는 도구였습니다.
쓰면 안 되는 것
JWT.sub != Path.ID. 객체 ID가 따로 있는 경로에서 정상 사용자 146/150명에게 경보를 울렸습니다.- IP 영구 차단. 실험실의 CGNAT 주소 하나를 막았다면 정상 사용자 25명이 함께 막혔습니다.
- Jaccard 90%·엔트로피 같은 모양 비교. 정상 페이지 넘기기와 구별할 근거가 없습니다. 검증 실패 수가 같은 일을 오탐 없이 했습니다.
도입 순서
- 객체 인가(방어선 0). 탐지가 아니라 예방입니다. 이것 없이는 나머지가 유출을 줄일 뿐 막지 못합니다.
- 인가 거부 이벤트 + 신원 윈도우(방어선 1). Redis 정렬 집합 하나면 됩니다. 기준값은 여러분의 정상 트래픽으로 정하세요.
- 미끼 객체(방어선 1). 데이터 몇 건과
if하나로 오탐이 가장 적은 신호를 얻습니다. 모든 목록·배치·통계에서 빼는 것만 조심하세요. - 단계적 대응과 섀도 모드(방어선 1). 영구 차단 없이 TTL로. 규칙은 섀도로 먼저 켭니다.
- WAF(방어선 2). 주입 범주와 가상 패치를 위해. PL1부터, 높은 레벨은 탐지 레벨로 먼저 봅니다. 관리형(Cloudflare, AWS WAF)도 좋습니다.
- IP 평판(방어선 2). 결정이 아니라 점수 재료로. 차단에는 만료를.
- 파이프라인(방어선 3). 서비스가 여러 개가 되어 한곳에서 엮어야 할 때. 보안 이벤트만 보내면 작게 시작할 수 있습니다.
- eBPF(런타임 보안). 컨테이너가 많고 침해 이후(셸 실행, 이상한 파일 접근, 처음 보는 외부 연결)를 봐야 할 때.
원문 그림과 비교하면 순서가 거의 뒤집혔습니다. 원문은 eBPF와 Kafka·Flink를 앞에 놓았지만, 실험실에서 가장 효과가 컸던 것은 앱 안의 1·2·3번이었습니다.
비용
탐지 미들웨어의 비용도 쟀습니다(15편, 실제 시간).
- 탐지 끔: p50 3.86ms
- 메모리 윈도우: p50 4.12ms
- Redis, 요청당 파이프라인 1회: p50 5.44ms(처리량 약 19% 감소)
- Redis, 규칙마다 왕복: p50 7.06ms(처리량 약 41% 감소)
같은 기능이라도 왕복 횟수가 비용을 정합니다. 요청당 Redis 왕복을 한 번으로 묶으세요.
이 실험의 한계
- 합성 트래픽입니다. 정상 사용자의 모양도, 공격자의 영리함도 제가 정했습니다.
- 모의 시각으로 돌렸습니다. "몇 초 만에 잡았다"는 요청 간격 기준이고, 실제 시스템의 처리 지연은 15편에서 따로 쟀습니다.
- 로그인 공격, 15분 이상 간격의 아주 느린 공격, 다른 미끼 비율, eBPF, 파이프라인 끝에서 끝까지 지연은 재지 않았습니다.
- 한 대의 맥, uvicorn 작업자 하나입니다. 지연 숫자는 운영 장비와 다릅니다.
그래서 이 시리즈의 결론은 숫자 자체보다 방법입니다. 여러분의 정상 트래픽과 여러분이 걱정하는 공격으로 같은 실험을 하세요. 실험실 코드는 그대로 쓸 수 있습니다.
정리
- 가장 효과가 컸던 것은 앱 안의 작은 코드였습니다. 객체 인가, 인가 거부 이벤트를 신원별로 세기, 미끼 객체, 검증 실패 세기.
- WAF, 요청 수 제한, IP 평판은 자기 일을 잘하지만 IDOR과 느린 열거에는 맞지 않습니다.
JWT.sub != Path.ID, IP 영구 차단, 모양 비교 규칙은 쓰지 마세요.- 탐지 규칙도 코드처럼 시험하세요. 탐지율과 오탐률과 지연을 같은 표에 놓으면 무엇부터 할지 보입니다.
출처와 확인 날짜
- 모든 측정: 실험실
lab/results/(2026-10-30~31 실행). 각 숫자의 원본 파일은 12~15편에 있습니다. - 사실 확인에 쓴 공식 문서는 00~11편의 "출처와 확인 날짜"에 있습니다(확인 2026-10-30).
이전 글 검증 4: WAF(CRS)와 지연 비용
시리즈 전체 목록 해킹 시도를 몇 초 안에 잡는 서버 전체 목록
고인물 개발자(OG)