어느 날 주문 조회 API 로그를 보니, 한 계정이 주문 번호를 1씩 올려 가며 300번 조회했습니다. 응답은 전부 404였습니다. 막기는 했습니다. 그런데 누가, 언제부터, 무엇을 찔러 봤는지는 아무도 몰랐습니다. 이 시리즈는 이런 시도를 몇 초 안에 알아채고, 필요하면 자동으로 늦추거나 막는 방법을 다룹니다. 그리고 그 방법이 정말 효과가 있는지 직접 재 봅니다.
흔히 도는 "표준 아키텍처"
검색해 보면 이런 설명이 자주 나옵니다. 이 시리즈의 출발점이 된 원문도 비슷합니다.
모든 요청을 eBPF와 OpenTelemetry로 모아 Kafka에 넣고, Flink로 실시간 분석한다. 앱 안의 RASP가 JWT의 사용자 ID와 경로의 ID를 비교해 IDOR을 잡고, 요청 패턴의 Jaccard 유사도가 90%를 넘으면 퍼징으로 본다. 걸리면 IP를 블랙리스트에 넣는다.
큰 그림은 맞습니다. 도구 하나로 끝나지 않고 수집 → 분석 → 차단 층으로 나눠야 합니다. 네트워크 앞단(WAF)만으로는 IDOR을 알 수 없고, 앱 안의 정보가 필요합니다. 같은 주체의 반복은 슬라이딩 윈도우(최근 N초 동안의 횟수를 계속 세는 방식)로 셉니다.
그런데 세부를 그대로 옮기면 곤란한 곳이 많습니다.
그대로 쓰면 안 되는 곳
| 원문의 주장 | 문제 | 이 시리즈의 입장 |
|---|---|---|
| IDOR은 탐지로 막는다 | 탐지는 사후입니다. IDOR의 해결은 모든 객체 접근의 인가 검사입니다 | 막기가 먼저, 탐지는 막은 결과를 센다 |
JWT.sub != Path.ID면 IDOR | 주문·문서 ID는 사용자 ID가 아닙니다 | 신호는 인가 결정 결과(허용/거부). 소유권은 DB만 안다 |
| 같은 IP로 세서 차단 | 공격자는 IP를 바꾸고, 정상 사용자는 IP를 나눠 씁니다(CGNAT) | 신원(계정·세션·API 키) 먼저, IP는 보조 |
| Jaccard 90%↑면 퍼징 | 정상 페이지 넘기기도 같은 모양입니다. 90%의 근거가 없습니다 | 검증 실패(400·422), 서로 다른 거부 객체 수가 더 강한 신호 |
| eBPF는 오버헤드 0으로 L7까지 본다 | 0이 아니고, TLS는 소켓에서 암호문입니다 | eBPF의 제자리는 런타임 보안 |
| Kafka + Flink가 표준 | 작은 팀에는 운영 부담이 탐지 이득보다 큽니다 | 지연 예산으로 고른다 |
| 차단 = 블랙리스트 등록 | 영구 차단은 오탐 비용이 크고 되돌리기가 없습니다 | 단계적 대응, TTL, 섀도 모드로 먼저 재기 |
표의 오른쪽은 이 시리즈의 주장입니다. 주장만 하지 않으려고, 3부에서 작은 실험실을 만들어 숫자로 확인합니다. 예를 들어 JWT.sub != Path.ID 규칙은 실험에서 공격 다섯 종류를 첫 요청에 잡았지만, 정상 사용자 150명 중 146명에게도 경보를 울렸습니다.
다시 그린 지도: 지연 시간으로 나눈 네 개의 방어선
방어 수단을 도구 이름이 아니라 얼마나 빨리 반응해야 하는가로 나눕니다. 이 시리즈는 이것을 네 개의 방어선이라고 부릅니다.
- 방어선 0 · 예방(코드 안). 객체마다 인가를 검사하고, 입력을 스키마로 검증하고, 추측하기 어려운 ID를 쓰고, 로그인을 보호합니다. 탐지할 일이 생기기 전에 코드에서 막습니다.
- 방어선 1 · 앱 안 탐지(밀리초). 인가 거부를 보안 이벤트로 남기고, 사용자(신원)별 슬라이딩 윈도우로 셉니다. 미끼 객체에 누가 닿으면 바로 경보를 냅니다. 수상하면 429 응답이나 챌린지로 속도를 늦춥니다.
- 방어선 2 · 엣지(밀리초, 앱 앞단). 요청이 앱에 닿기 전에 WAF(OWASP CRS), 속도 제한, 봇 관리, IP 평판으로 거릅니다.
- 방어선 3 · 상관 분석(초~분, 서버 여러 대). OpenTelemetry와 Vector로 이벤트를 모아, Redis Streams나 SIEM에서 여러 서버에 흩어진 같은 사용자의 행동을 엮어 봅니다. 규모가 크면 Kafka와 Flink를 씁니다.
네 방어선이 내린 결정은 결정 API 한 곳에 모입니다. 결정은 TTL(만료 시간)이 붙은 차단 목록이나 세션 폐기 같은 모양이고, 방어선 0·1·2가 이것을 읽어 적용합니다. 그래서 상관 분석이 몇 분 늦게 찾아낸 공격자도 다음 요청부터는 앞쪽 방어선에서 걸립니다.
원칙은 다섯 가지입니다.
- 막을 수 있는 것은 코드에서 막는다. 탐지는 그렇게 막힌 시도를 세는 일이다.
- 가장 정확한 신호는 앱만 아는 것이다. 인가 거부, 검증 실패, 미끼 접근이 그렇다.
- 세는 기준은 신원이 먼저, IP는 그다음이다.
- 차단은 단계적으로 한다. 섀도 모드로 먼저 재고, TTL과 되돌리기를 갖춘 뒤에 켠다.
- 탐지 규칙도 시험한다. 탐지율과 오탐률을 숫자로 낸다.
시리즈 구성
- 1부 개념과 지도(00~01). 공격마다 어느 층에서 보이는지 정리합니다.
- 2부 방어선별 기술(02~11). 예방, 보안 이벤트, 슬라이딩 윈도우, 미끼 객체, 단계적 대응, WAF, IP 평판, 파이프라인, eBPF, 클라우드 매핑.
- 3부 검증(12~16). 127.0.0.1에서만 도는 실험실에서 이름표가 붙은 정상·공격 트래픽을 흘려 탐지율, 오탐률, 탐지까지 걸린 요청 수와 시간, 지연 증가를 잽니다.
이 시리즈의 약속
- 방어 중심입니다. 공격 예시는 탐지를 설명하는 데 필요한 교과서 수준만 씁니다. 특정 WAF를 피하는 기법이나 남의 시스템을 공격하는 방법은 쓰지 않습니다.
- 계정, 주문 번호, IP는 모두 가짜 값입니다. IP는 문서용 대역(RFC 5737)과 CGNAT 대역(RFC 6598)에서 골랐습니다.
- 숫자는 실제로 잰 것만 씁니다. 날짜와 장비, 트래픽 모양을 함께 적습니다. 못 잰 것은 【작성자 실측】 또는 "확인 필요"로 표시합니다.
- 합성 트래픽은 운영 트래픽이 아닙니다. 결과는 언제나 "이 조건에서"입니다.
정리
- 실시간 탐지는 도구 조합보다 어떤 신호를 어느 방어선에서 셀지의 문제입니다.
- 가장 정확한 신호는 앱 안에 있습니다. 인가 거부, 검증 실패, 미끼 접근.
- 널리 도는 설명 중
JWT.sub != Path.ID, IP 기준 차단, "오버헤드 0 eBPF"는 그대로 쓰면 안 됩니다. 3부에서 숫자로 확인합니다.
출처와 확인 날짜
모든 링크는 2026-10-30에 확인했습니다.
- OWASP API Security Top 10 2023, API1 Broken Object Level Authorization: https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization
- RFC 6269 Issues with IP Address Sharing: https://www.rfc-editor.org/rfc/rfc6269.html
- OWASP CRS 문서: https://coreruleset.org/docs/
- Tetragon 개요: https://tetragon.io/docs/overview/
- 이 시리즈의 실험 코드와 원시 결과: 실험실 폴더
lab/(README에 재현 명령)
다음 글 공격은 어디서 보이나: IDOR·열거·퍼징·로그인 공격·봇
시리즈 전체 목록 해킹 시도를 몇 초 안에 잡는 서버 전체 목록
