윈도우 규칙은 언제나 기준값과 씨름합니다. 너무 낮으면 정상 사용자가 걸리고, 너무 높으면 느린 공격자가 빠집니다. 그런데 기준값이 1인데도 오탐이 거의 없는 신호가 있습니다. 정상 사용자라면 절대 닿을 일이 없는 객체에 누군가 닿았을 때입니다. 이것이 미끼 객체입니다.
미끼 객체란
미끼 객체(honeytoken, canary)는 진짜처럼 존재하지만 어떤 정상 경로로도 노출되지 않는 데이터입니다.
- 미끼 주문. 실제 주문 번호 사이에 섞어 만든, 로그인할 수 없는 계정의 주문입니다. 어느 화면, 어느 목록, 어느 내보내기에도 나오지 않습니다.
- 미끼 API 키. 형식은 진짜와 같지만 권한이 없는 키입니다. 설정 저장소나 문서 예시에 일부러 둡니다. 누가 그 키로 부르면 유출 경로를 알 수 있습니다.
- 미끼 계정. 존재하지만 아무도 쓰지 않는 계정입니다. 로그인 시도가 오면 계정 목록이 새어 나간 신호입니다.
원리는 단순합니다. 정상 사용자는 자기 주문 번호를 화면에서 눌러서 엽니다. 화면에 없는 번호에 닿는 방법은 번호를 스스로 만들어 넣는 것뿐입니다. 그게 열거입니다.
실험실의 미끼 주문
실험실 앱(lab/data.py)은 주문 1,365건 중 27건(2%)을 미끼로 만들었습니다. 주인은 로그인할 수 없는 계정 u999이고, 번호는 실제 주문과 섞어 무작위로 배치했습니다. 번호만 봐서는 구별되지 않습니다.
if oid in DECOYS:
# 어느 화면에도 나오지 않는 번호. 접근 자체가 신호다.
sec_event(request, "honeytoken_access", object=oid)미끼 주문도 응답은 다른 남의 주문과 똑같이 404입니다. 공격자는 미끼를 밟았는지 모릅니다.
결과: 오탐 0, 느린 공격도 결국 잡힌다
3부 실험에서 이름표가 붙은 2시간 분량(모의 시각) 트래픽을 흘렸습니다. 미끼 규칙의 결과입니다. 기준은 "한 번이라도 닿으면 경보"입니다.
| 공격 | 미끼에 처음 닿은 요청 | 걸린 시간(모의 시각) |
|---|---|---|
| 빠른 열거(0.2초 간격) | 13번째 | 2.4초 |
| 느린 열거(90초 간격) | 28번째 | 2,430초(약 40분) |
| IP를 바꾸는 열거 | 45번째 | 44초 |
| 계정을 바꾸는 열거 | 7번째 | 12초 |
| 정상 사용자 150명 | 경보 0건 |
눈여겨볼 곳이 두 군데입니다.
느린 열거를 잡았습니다. 60초 윈도우 규칙은 90초 간격 공격을 어떤 기준값에서도 잡지 못했습니다(14편). 미끼는 시간이 아니라 닿은 번호로 판단하니 속도와 상관이 없습니다. 대신 걸린 시간이 40분입니다. 미끼 비율이 2%면 평균 50개쯤 넘겨야 하나를 밟습니다. 운이 나쁘면 더 걸립니다.
IP와 계정을 바꿔도 잡았습니다. 미끼는 세는 규칙이 아니라서 공격자가 기준을 쪼개도 소용이 없습니다. 계정을 바꾸는 열거에서는 그 순간의 계정 하나만 드러나지만, IP와 함께 보면 묶을 수 있습니다.
한계
- 열거가 아닌 공격은 못 잡습니다. 파라미터 퍼징과 폭주 수집은 주문 번호를 건드리지 않아 미끼에 닿지 않았습니다. 미끼는 열거 전용 신호입니다.
- 먼저 새어 나간 것은 못 막습니다. 빠른 열거는 13번째 요청에서 잡혔습니다. 소유권 검사가 없는 앱이었다면 앞의 12건은 이미 나갔습니다. 미끼는 예방(2편)을 대신하지 않습니다.
- 비율과 속도의 맞바꿈. 미끼를 늘리면 빨리 잡지만 데이터가 지저분해집니다. 실험실은 2%만 시험했습니다. 다른 비율은 재지 않았습니다(【작성자 실측】 필요).
운영할 때 조심할 점
미끼의 오탐은 거의 언제나 우리 쪽 코드에서 옵니다.
- 모든 목록과 내보내기에서 뺍니다. 관리자 화면, CSV 내보내기, 검색 색인, 통계 배치. 하나라도 미끼를 보여 주면 정상 사용자가 클릭합니다.
- 내부 작업 계정을 구분합니다. 정산 배치나 데이터 이전 작업은 모든 주문을 훑습니다. 이런 서비스 계정은 미끼 경보에서 빼거나 따로 분류합니다.
- 매출·재고 통계에서 뺍니다. 미끼 주문의 금액이 실적에 섞이면 안 됩니다.
- 누가 무엇이 미끼인지 아는지 줄입니다. 미끼 목록이 새면 공격자가 피해 갑니다. 목록은 보안팀과 탐지 코드만 압니다.
- 경보가 울리면 사람이 봅니다. 미끼는 오탐이 적은 만큼 즉시 강한 대응(세션 폐기, 차단)을 걸기 좋습니다. 그래도 처음 몇 주는 섀도 모드로 실제 오탐을 확인하세요(6편).
숨은 링크(사람 눈에는 안 보이는 링크를 페이지에 넣어 크롤러를 잡는 방법)도 같은 원리입니다. 다만 검색 엔진 크롤러, 화면 낭독기, 접근성 도구가 닿을 수 있어 오탐 관리가 더 까다롭습니다.
정리
- 미끼 객체는 정상 경로로는 닿을 수 없는 데이터입니다. 한 번 닿으면 거의 확실한 공격 신호입니다.
- 실험실에서 미끼 주문 2%로 IDOR 열거 네 가지를 모두 잡았고, 정상 사용자 경보는 0건이었습니다. 느린 열거도 40분 만에 잡았습니다.
- 퍼징·폭주는 못 잡고, 먼저 새어 나간 것은 못 막습니다. 예방 위에 얹는 신호입니다.
- 오탐은 대개 우리 쪽 목록·배치·통계에서 옵니다. 미끼를 모든 정상 경로에서 빼세요.
출처와 확인 날짜
모든 링크는 2026-10-30에 확인했습니다.
- OWASP Logging Cheat Sheet(탐지 지점 예시): https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- 실험 결과: 실험실
lab/results/run-shadow-redis/detectors_default.json의honeytoken행(2026-10-30 실행, 13·14편) - 미끼 데이터 생성: 실험실
lab/data.py(시드 고정, 미끼 비율 2%)
이전 글 방어선 1-②: 신원별 슬라이딩 윈도우로 열거·퍼징 잡기
다음 글 방어선 1-④: 단계적 대응과 섀도 모드
시리즈 전체 목록 해킹 시도를 몇 초 안에 잡는 서버 전체 목록
