요약

  • DNS Response Rate Limiting(RRL)는 위조된 UDP 쿼리가 권위 서버를 반사 증폭기로 만들 수 있는 상황에서, 서버가 반복적으로 내보내는 유사한 응답의 양을 줄이는 기능이다.
  • Paul Vixie의 역할은 실질적이었지만 공동 기여였다. ISC는 그와 함께한 방어 전략 세션을 언급하며, BIND 개발 기록은 해당 패치에 Vixie와 Vernon Schryver를 함께 명시한다.
  • RRL은 응답 클래스와 클라이언트 주소 범위를 그룹화한다. 이는 악성 트래픽 양을 억제할 수 있지만, 이 그룹화는 트래픽 정책이지 인증, 귀속 또는 의도의 증명이 아니다.

응답 자체가 페이로드가 될 수 있다

DNS 반사 공격에서는 피해자의 주소를 표면상의 발신지로 위조해 권위 서버에 쿼리를 보낸다. 그러면 서버의 응답이 피해자에게 전달된다. 응답이 쿼리보다 훨씬 크면, 공격자는 서버를 이용해 자신이 직접 보낸 트래픽보다 많은 트래픽을 피해자로 보내게 된다.

ISC의 2014년 발표 자료는 구체적인 예를 제시한다. isc.org에 대한 36바이트 ANY 쿼리가 3,576바이트의 응답을 낳을 수 있다는 것이다. 이 예는 반사 공격의 매력을 설명할 뿐, 보편적인 증폭 비율이 아니다. 크기는 쿼리, 존 데이터, DNSSEC 상태, 전송 방식과 응답에 따라 달라진다. 운영상의 질문은 더 좁다. 요청들이 서로 비슷해 보일 때, 하나의 권위 서비스는 어느 정도까지 반복 응답 트래픽을 계속 내보내야 하는가?

ISC에 따르면 Paul Vixie와 회사 내에서 진행된 방어 전략 세션이 RRL로 이어졌다. BIND 개발 티켓은 BIND 9 패치를 Vixie와 Vernon Schryver의 것으로 기록한다. 공개 기록은 Vixie의 핵심적 관여를 뒷받침하지만, 단독 발명자 서사는 뒷받침하지 않는다. 이 구분이 중요한 이유는, RRL이 조직적 작업과 구현, 이후의 조정을 통해 모인 운영 문제에 대한 대응이었기 때문이다.

Internet Hall of Fame 프로필은 이 사건을 더 넓은 DNS 경력 안에 놓는다. Vixie는 1988년 Digital Equipment Corporation에서 BIND 4 유지 관리를 시작했고, 이후 BIND 8의 주 저자이자 기술 설계자가 되었으며, MAPS, PAIX, Internet Software Consortium을 설립했다고 기록한다. 또한 게이오 대학교에서 DNS와 DNSSEC에 관한 박사 연구를 했다고 적는다. 이러한 이정표들은 그의 작업 범위를 보여주지만, 패치 기록에 Schryver도 함께 이름이 올라 있는 RRL의 공동 기여를 바꾸지는 않는다.

BIND 9.9.4는 RRL을 선택적 빌드 기능으로 도입했다. ISC의 “BIND 9.10 Significant Changes” 페이지에 따르면, RRL은 이후 기본 빌드 구성의 일부가 되었다. 이는 BIND에서의 가용성에 관한 서술이지, 모든 권위 운영자가 이를 켰다는 증거도, 모든 DNS 제품이 같은 방식으로 동작한다는 증거도 아니다.

버킷은 유사성을 세지, 신원을 세지 않는다

현재 BIND 9.20.29 매뉴얼은 유사한 응답과 DNS 클라이언트를 중심으로 형성되는 토큰 또는 크레딧 버킷을 설명한다. 응답이 크레딧을 소모하며, 설정된 비율이 일정 기간에 걸쳐 이를 회복시킨다. 운영자는 비어 있지 않은 응답, NODATA, NXDOMAIN, 리퍼럴, 오류 또는 모든 UDP 응답과 같은 클래스에 한도를 둘 수 있다. 버킷이 설정 비율을 초과하면 BIND는 선택된 응답을 드롭하거나 변경할 수 있다.

“클라이언트”라는 단어 뒤에는 정책 선택이 숨어 있다. BIND의 문서화된 기본값은 IPv4 주소를 /24로, IPv6 주소를 /56으로 묶는다. 즉, 각 블록 안의 주소들은 해당 회계에서 함께 계산된다. 리졸버, 기업 네트워크, 캠퍼스 또는 접속 제공자는 서로 무관한 많은 사용자를 같은 프리픽스 뒤에 둘 수 있다. 한 발신지가 버킷을 한도 이상으로 밀어 올리면, 같은 버킷을 공유하는 다른 사용자가 지연되거나 잘린, 혹은 생략된 응답을 만날 수 있다.

이것이 프리픽스 집계가 틀렸다는 증명은 아니다. 주소별 한도는 여러 주소에 쿼리를 흩어 우회할 수 있고, 서버는 홍수 상황에서 희소한 아웃바운드 용량을 어떻게 배분할지 선택해야 한다. 프리픽스, 응답 클래스, 비율은 가용성 비용을 지닌 제어 설정이다. 이는 클라이언트가 “실제로” 누구인지에 대한 중립적 관찰이 아니라, 명시적인 운영 정책으로 다뤄져야 한다.

BIND에 문서화된slip동작은 이 트레이드오프를 드러낸다. 기본값slip=2에서는 유효한 서버 쿠키 없이 온 속도 제한 요청이 두 번마다 한 번, 더 작은 응답을 받는다. 쿠키를 제시한 클라이언트는 BADCOOKIE를 받을 수 있고, 그렇지 않으면 BIND는 단편화 비트를 설정해 리졸버가 TCP로 재시도하도록 한다. 일부 오류는 단편화할 수 없어 slip 비율대로 통과한다.slip=1은 제한된 모든 응답에 단편화된 응답을 보내 최대 반사 억제보다 응답 무결성과 클라이언트 전달을 우선하고,slip=0은 제한된 모든 응답을 드롭한다. 재시도 경로는 부수적 세부 사항이 아니라 방어의 일부다.

경계는 운영 역할이다

ISC는 권위 서버에 대해 RRL을 권한다. 그 지침은 재귀 사용이 오탐(false positive)을 만들고 같은 이름을 반복 요청하는 클라이언트를 느리게 할 수 있다고 경고하며, 개방된 재귀는 RRL에 의존해 “보호”하기보다 닫아야 한다고 말한다. 같은 기능도, 공개 권위 쿼리에 응답하는 서비스와 최종 사용자 집단을 서비스하는 서비스에서는 다른 비용을 지닐 수 있다.

BIND는 강제 전에 후보 한도를 관찰할 수 있도록log-only를 제공하며,RateDropped,QryDropped,RateSlipped,RespTruncated같은 카운터를 함께 둔다. 이 카운터들은 설정된 메커니즘이 무엇을 했을지, 또 했는지에 관한 운영 증거다. 공격자의 신원을 드러내지는 않는다. 관찰된 발신지 주소 자체가 위조되었을 수 있고, RRL의 버킷 소속은 귀속 시스템이 아니다.

Lu Heng의 노트 65는 여기서 편집적 관점을 제공한다. 즉, 실행되는 코드의 실제 동작이 구현이 실제로 무엇을 제어하는지의 시험이라는 것이다. 이는 Vixie에 관한 역사적 증거도, RRL에 관한 기술적 사실도 제공하지 않는다. 이 기능에서 관련된 증거는 배포된 BIND 버전, 구성, 버킷 카운터, 클라이언트 재시도 동작이지, 문서에 RRL 지시문이 있다는 사실만이 아니다.

지지 가능한 결론은 의도적으로 한정되어 있다. RRL은 권위 서버가 반사 트래픽에 기여하는 반복적·유사한 응답의 양을 줄일 수 있다. 동시에 정당한 사용자를 한데 묶고 전달을 억제와 맞바꿀 수 있다. 이는 요청을 인증하지 않고, 동기를 확립하지 않고, 보편적 채택을 측정하지 않으며, 피해자가 반사 트래픽을 전혀 받지 않을 것을 보장하지도 않는다. Vixie의 기여는, 운영적 방어를 운영자가 한도를 점검할 수 있는 구성 가능한 구현으로 만드는 데 기여한 것으로 이해하는 것이 가장 적절하다.

출처