2008년의 교훈 — 병행 질의와 단기 대책
2008년에 널리 알려진 문제를, 고수준의 공격 발상과 단기 대책으로서 이해합니다.
이전 장의 복습: 제 3 장에서는 응답 수락 조건(question / ID / address / port)과 race window, 그리고 entropy 와 시도 횟수의 관계를 정리했습니다. 본 장에서는 그 틀을 사용하여, 2008년에 널리 알려진 문제가 "왜 심각했는가", 그리고 그때부터 이어지는 단기 대책의 조합을 확인합니다.
주의: 이 장은 역사적 교훈과 방어 의도를 다룹니다. 실제 환경에 대한 공격 절차나 exploit code 는 다루지 않습니다.
2008년의 무엇이 심각했는가
DNS cache poisoning 자체는 오래전부터 알려져 있었지만, 2008년에 Dan Kaminsky 가 널리 알린 문제(일반적으로 「Kaminsky 공격」이라 불립니다)는 "uncached 한 질의 기회를 여러 번 만들어내면, 짧은 race window 라도 attempts 를 늘릴 수 있다"라는 점을 선명하게 드러냈습니다. 자세한 공격 절차는 여기서 다루지 않지만, 고수준의 발상으로는 "random123.example.com 같은 존재하지 않는 라벨에 차례차례 질의를 발생시키고, 그때마다 fresh miss 를 만들어 race 를 다수 시도한다"는 것입니다.
한 번의 race 가 짧더라도 fresh miss 가 반복해서 만들어지면 누적 위험은 올라갑니다. RFC 5452 가 attempts 와 outstanding queries 를 나누어 설명하는 것은, 이 이미지를 잡아주기 위함입니다.
연습 4-1 — attempts 가 늘어나면 무엇이 곤란한가
한 번의 race 가 짧더라도, fresh miss 가 반복해서 만들어지면 누적 위험은 올라갑니다.
Q1. 2008년에 널리 알려진 DNS cache poisoning 문제의 교훈으로 가장 가까운 것은 무엇입니까.
무엇이 '시도 횟수'를 늘렸는지가 포인트입니다.
2008년에 널리 알려진 문제의 교훈은, uncached 한 질의 기회를 여러 번 만들어내면 위조 응답과의 race 시도 횟수가 늘어나 위험이 높아지기 쉽다는 점입니다. 여기서는 구조의 이해에만 그칩니다.
Q2. 다른 조건이 같고, identical outstanding queries 의 개수 D 만 작은 범위에서 1 에서 2 로 늘어났을 때, 하나의 window 당 spoof 성공 확률은 대체로 어떻게 변합니까.
RFC 5452 는 작은 D 에서는 거의 비례로 생각할 수 있다고 설명합니다.
다른 조건이 같다면, identical outstanding queries 의 개수 D 가 늘어날수록 동일 window 에서 어느 하나에 적중할 확률은 올라갑니다. 작은 D 의 범위에서는 대체로 비례로 봐도 되므로, 1 에서 2 라면 대체로 2 배 방향입니다.
open recursion 과 모니터링
연습 4-1 에서 본 대로, 위험을 늘리는 최대 요인은 「attempts(fresh miss 의 발생 횟수)」입니다. 그러면 그 attempts 를 누가 늘릴 수 있을까요? 한 가지 답이 open recursion 입니다. resolver 가 누구나 사용할 수 있는 상태이면, 제삼자가 외부에서 자유롭게 query 를 일으킬 수 있기 때문에, 결과적으로 fresh miss 와 attempts 를 의도적으로 늘리기 쉽습니다. 즉 open recursion 은 「공격자에게 있어 attempts 증가의 입구」를 넓히는 구성이라고 할 수 있습니다.
이는 부하 · 관측 노이즈 · race opportunity 의 증가라는 의미에서 exposure 를 넓힙니다. 운용에서는 "random 한 라벨에 대한 query 급증", "특정 zone 에 대한 miss 의 편중", "NAT 에 의한 port entropy 의 저하" 등을 모니터링 지표로 두면, 동작 변화를 눈치채기 쉬워집니다.
연습 4-2 — open recursion 과 단기 대책
누구든 resolver 에 query 를 일으킬 수 있는 상태는 exposure 를 넓힙니다. 한 측면만의 단기 대책으로는 불충분합니다.
Q3. open recursion 이 cache poisoning 의 관점에서 위험도를 올리기 쉬운 이유로 가장 가까운 것은 무엇입니까.
누가 query 를 일으킬 수 있는지, 입구의 넓이를 생각합니다.
open recursion 에서는 누구나 resolver 에 query 를 일으키기 쉬워집니다. 이로써 cache miss 나 부하가 늘고, race 의 시도 기회도 만들어지기 쉬워지므로, 노출이 커집니다.
Q4. 단기 대책으로 해당하지 않는 것은 무엇입니까.
부작용이 크고 방어로도 불충분한 것이 무엇인지 생각합니다.
단기 대책으로는 patch / update, source port / transaction ID 의 난수성 확보, recursion 을 신뢰된 클라이언트로 제한, query 급증이나 random label 의 스파이크 모니터링이 적절한 조합입니다. TTL 을 무한으로 고정하는 것은 운용상의 부작용이 크고 방어로서도 불충분하여, 단기 대책에 포함해서는 안 됩니다.
Q5. 다음 중 틀린 것은 무엇입니까.
DNSSEC 이 '서명에 의한 검증'인지 '비밀 유지'인지를 떠올립니다.
틀린 것은 세 번째 선택지입니다. DNSSEC 은 query 이름이나 response 본문의 비밀 유지를 제공하지 않습니다. 나머지 세 개는 모두 이치에 맞는 설명이며, 특히 patch 후에도 기존 cache 의 TTL 이 남으면 오래된 응답이 한동안 보일 수 있습니다.
제 4 장의 정리
- 짧은 race window 라도 fresh miss 와 attempts 가 늘어나면 위험은 누적된다
- open recursion 은 exposure 를 넓히므로, trusted clients 로 좁히는 것이 기본이다
- patch / entropy / recursion control / 모니터링은 단기 hardening 의 토대이다