지난 글은 기본 기준값 하나로 비교했습니다. 하지만 기준값은 정하기 나름입니다. "5가 아니라 3이었다면?", "1분이 아니라 1시간이었다면?" 이번 글은 같은 기록을 기준값과 윈도우를 바꿔 가며 재생한 결과입니다. 재생은 앱 안에서 실제로 난 경보와 똑같이 동작하는 것을 확인한 같은 코드로 했습니다(12편).
거부된 서로 다른 객체 수: 윈도우 × 기준값
신원 기준입니다. "잡은 IDOR 공격"은 A1~A4 네 종류 중 몇 개를 잡았는지입니다.
| 윈도우 | 기준값 2 | 3 | 5 | 10 | 20 |
|---|---|---|---|---|---|
| 1분 | 3/4 · 오탐 14명 | 3/4 · 0명 | 2/4 · 0명 | 2/4 · 0명 | 2/4 · 0명 |
| 10분 | 4/4 · 14명 | 4/4 · 0명 | 3/4 · 0명 | 2/4 · 0명 | 2/4 · 0명 |
| 1시간 | 4/4 · 15명 | 4/4 · 0명 | 3/4 · 0명 | 3/4 · 0명 | 3/4 · 0명 |
읽는 법입니다.
- 기준값 2는 너무 낮습니다. 가족이 보낸 주문 링크 두 개를 연 정상 사용자 14~15명이 걸렸습니다. 이 사람들의 존재를 미리 알지 못하면 기준값을 정할 수 없습니다.
- 10분 윈도우·기준값 3(1시간·3도 같음)이 이 트래픽에서 가장 좋았습니다. 네 종류를 다 잡고 오탐이 없습니다.
- 1분 윈도우는 느린 열거를 절대 못 잡습니다. 90초 간격이니 1분 안에 두 건이 들어오지 않습니다. 기준값을 아무리 낮춰도 마찬가지입니다.
- 긴 윈도우는 느린 공격을 잡지만 늦습니다. 1시간·기준값 20이면 느린 열거를 20번째 요청, 모의 시각 1,710초(28분)에 잡았습니다.
느린 공격은 윈도우를 피한다
느린 열거(A2, 90초 간격)를 규칙별로 보면 이렇습니다.
| 규칙 | 결과 |
|---|---|
| 요청 수(1분 60~300) | 모두 놓침 |
| 403·404 급증(1분 3~20) | 모두 놓침 |
| 거부된 서로 다른 객체(10분 3) | 3번째 요청, 180초 |
| 거부된 서로 다른 객체(1시간 10) | 10번째 요청, 810초 |
| 미끼 주문 | 28번째 요청, 2,430초 |
공격자가 윈도우보다 느리면 윈도우 규칙은 보지 못합니다. 윈도우를 늘리면 잡지만, 그만큼 메모리와 오탐이 늘고 늦어집니다. 이 실험에서는 90초 간격만 시험했습니다. 15분에 한 번처럼 더 느린 공격은 재지 않았습니다(【작성자 실측】 필요). 그런 공격에는 두 가지가 남습니다.
- 미끼 객체. 속도와 상관없이 닿은 번호로 판단합니다.
- 방어선 3의 긴 윈도우. 며칠 치 보안 이벤트를 모아 "한 계정이 지난 24시간 동안 거부당한 서로 다른 객체 수"를 배치로 봅니다(9편).
신원 기준 vs IP 기준
| 규칙 | 신원 기준: IP 바꿈 / 계정 바꿈 / 오탐 | IP 기준: IP 바꿈 / 계정 바꿈 / 오탐 · 그 IP를 쓰는 정상 사용자 |
|---|---|---|
| 거부 객체 3개/10분 | 잡음 / 잡음 / 0명 | 놓침 / 잡음 / 3명 · 50명 |
| 거부 객체 5개/1시간 | 잡음 / 놓침 / 0명 | 놓침 / 잡음 / 10명 · 50명 |
| 403·404 10개/1분 | 잡음 / 놓침 / 0명 | 놓침 / 잡음 / 0명 |
| 연 주문 10개/10분 | 잡음 / 놓침 / 5명 | 놓침 / 잡음 / 51명 · 60명 |
| 요청 120개/1분 | 놓침 / 놓침 / 1명 | 놓침 / 놓침 / 1명 · 1명 |
두 가지가 분명합니다.
- IP 기준은 IP를 바꾸는 공격을 어느 규칙으로도 못 잡았습니다. 신원 기준은 대부분 잡았습니다.
- IP 기준은 CGNAT에서 오탐이 커집니다. 공유 IP 두 개 뒤의 정상 사용자 50명은 각자 조금씩 한 행동이 한 주소에 합쳐져 기준을 넘었습니다. 그 IP를 막았다면 50명이 함께 막혔을 것입니다.
반대로 계정을 바꾸는 공격(A4)은 IP 기준이 더 잘 잡았습니다. 그래서 둘 다 셉니다. 대응은 신원 기준에 걸고, IP 기준 경보는 기록하고 다른 신호와 합칠 때 씁니다(6·8편).
퍼징: 검증 실패를 세면 깔끔하다
파라미터 퍼징(A5)은 검증 실패 수(5분 윈도우)로 셌습니다.
| 기준값 | 잡은 요청 | 오탐 사용자 |
|---|---|---|
| 3 | 3번째(0.6초) | 0명 |
| 5 | 5번째(1.2초) | 0명 |
| 10 | 10번째(2.7초) | 0명 |
| 20 | 20번째(5.7초) | 0명 |
정상 트래픽에도 검증 실패가 6건 있었습니다. 옛 앱 버전이 모르는 파라미터(utm_source)를 붙인 요청입니다. 하지만 한 사람이 5분 안에 3번 이상 낸 적이 없어 경보가 나지 않았습니다. 앱이 스키마로 판단한 결과를 세기 때문에, 원문의 "Jaccard 유사도 90%" 같은 모양 비교 없이도 정상 페이지 넘기기와 퍼징이 쉽게 갈렸습니다(4편).
폭주 수집과 요청 수 규칙
요청 수 규칙(1분 윈도우)의 기준값별 결과입니다.
| 기준값 | 잡은 공격 | 오탐 사용자 |
|---|---|---|
| 60 | A1, A5, A6 (+신원 기준은 A3) | 1명 |
| 120 | A1, A5, A6 | 1명 |
| 200 | A1, A5, A6 | 0명 |
| 300 | A1, A6 | 0명 |
오탐 1명은 0.4초마다 목록을 부르는 잘못 만든 앱(1분에 150번)입니다. 기준값 200이면 빠지고, 폭주 수집(1분에 600번)은 여전히 잡힙니다. 요청 수 규칙은 폭주에는 좋지만 열거에는 약합니다. 느린 열거, IP 바꾸기, 계정 바꾸기를 모두 놓쳤습니다.
정리
- 기준값은 정상 트래픽이 정합니다. 이 트래픽에서는 "거부된 서로 다른 객체 3개/10분"이 오탐 0으로 IDOR 네 종류를 다 잡았고, 2로 낮추면 정상 사용자 14명이 걸렸습니다.
- 윈도우보다 느린 공격은 윈도우 규칙에 보이지 않습니다. 1분 윈도우는 90초 간격 열거를 어떤 기준값으로도 못 잡았습니다. 미끼와 긴 윈도우의 배치 분석으로 메웁니다.
- IP 기준은 IP를 바꾸는 공격을 하나도 못 잡았고, CGNAT 뒤 정상 사용자 50명을 한 덩어리로 묶었습니다. 신원 기준을 먼저 쓰세요.
- 퍼징은 검증 실패 수로, 폭주는 요청 수로 깔끔하게 잡혔습니다. 요청 수만으로는 열거를 잡기 어렵습니다.
출처와 확인 날짜
- 기준값·윈도우 재생 결과: 실험실
lab/results/run-shadow-redis/sweeps.csv(2026-10-30 실행) - 기본 기준값 결과:
lab/results/run-shadow-redis/detectors_default.json - RFC 6269 Issues with IP Address Sharing: https://www.rfc-editor.org/rfc/rfc6269.html (2026-10-30 확인)
이전 글 검증 2: IDOR, 무엇이 잡나
다음 글 검증 4: WAF(CRS)와 지연 비용
시리즈 전체 목록 해킹 시도를 몇 초 안에 잡는 서버 전체 목록
