나는 이에 관한 많은 기사를 읽었지만 다음과 같은 경우 캐시 중독이 어떻게 가능한지 이해하지 못합니다.
- 응답의 트랜잭션 ID가 일치하지 않으면 쿼리가 취소되고 실패로 표시됩니다. 즉, 공격자는 첫 번째 응답만 수락하므로 트랜잭션 ID를 무차별 대입할 수 없습니다.
- 재귀 확인자는 동일한 도메인/유형/클래스에 대해 한 번에 하나의 요청만 보냅니다. 즉, 공격자는 트랜잭션 ID를 무차별 대입하기 위해 동일한 도메인에 대해 많은 요청을 트리거할 수 없습니다.
기본적으로 보이는 구성에서 공격자가 트랜잭션 ID를 추측해야 하는 경우 캐시 중독이 어떻게 가능합니까? 공격자는 재귀 확인자가 동일한 도메인을 계속해서 확인하도록 강제하여 더 많은 시도를 하게 됩니까? 이 경우에는 몇 시간이 걸릴 수 있습니다.
답변1
주로 부정확한 첫 번째 글머리 기호입니다.
- 응답의 트랜잭션 ID가 일치하지 않으면 쿼리가 취소되고 실패로 표시됩니다. 즉, 공격자는 첫 번째 응답만 수락하므로 트랜잭션 ID를 무차별 대입할 수 없습니다.
알 수 없는 트랜잭션 ID가 수신되면 해당 응답은 삭제됩니다. 그러나 처리되지 않은 쿼리가 실패한 것으로 간주된다는 귀하의 가정은 사실이 아닙니다.
사실상 이 공격 시나리오는 실제 네임서버의 응답이 도착하기 전에 공격자가 유효한 응답을 얻기 위한 경쟁이 됩니다.
가정의 문제는 트랜잭션 ID(+ UDP 소스 포트)의 전체 지점이 처리되지 않은 쿼리에 대한 응답을 일치시키는 것이지만 이러한 값이 잘못된(어떤 쿼리와도 일치하지 않음) 응답이 있는 경우, 어떤 쿼리가 실패했다고 간주해야 하는지 어떻게 알 수 있나요?
그리고 어떤 형태로든 부분 일치를 허용한다면 공격자에게 다소 부담스러운 경쟁을 사소하게 악용할 수 있는 DoS 공격으로 대체하지 않는 방식으로 이를 어떻게 구현하겠습니까?
"실제" 보호를 위한 옵션:
- DNSSEC를 사용하면 쿼리 발신자가 응답에 포함된 레코드의 신뢰성을 확인할 수 있으므로 공격자가 생성한 응답이 서명된 영역의 이름에 대해 허용되지 않습니다.
- 특정 형태의 클라이언트/포워더에서 특히 리졸버 서버로의 쿼리의 경우 DoT 및 DoH는 캐시 중독 문제도 방지합니다.이 특별한 "홉"에 대해(DoT/DoH는 두 호스트 간의 통신 채널만 보호하며, DNS 확인에는 이러한 "홉"이 여러 개 있는 경향이 있습니다.)
(TCP를 통한 쿼리만으로도 문제의 특정 시나리오가 개선되지만 암호화 기반 솔루션은 처리하는 공격 측면에서 분명히 훨씬 더 광범위합니다.)