DNSSEC를 제공하는 보안 취약점은 무엇입니까?


28

DNSSEC로 DNS 영역에 서명 할 계획이었습니다. 내 영역, 등록자 및 내 DNS 서버 (BIND9)는 모두 DNSSEC를 지원합니다. DNSSEC를 지원하지 않는 유일한 사람은 보조 이름 서버 공급자 (즉 buddyns.com )입니다.

웹 사이트 에서 DNSSEC와 관련하여 다음과 같이 설명합니다.

BuddyNS는 대용량 DNS 서비스에 적합하지 않은 일부 취약점에 노출되어 있기 때문에 DNSSEC를 지원하지 않습니다.

글쎄, 나는 대부분의 리졸버가 레코드가 올바르게 서명되었는지 확인하지 않기 때문에 DNSSEC의 사용은 현재 어떻게 든 문제가 있다고 생각했다. 내가 알지 못하는 것은-그들의 진술에 따르면 그것을 제공하면 어떤 종류의 보안 취약점이 노출되는 것처럼 보입니다.

"vulnerabilites"는 무엇입니까?


8
보다 실마리있는 DNS 제공 업체를 찾으십시오.
Alnitak

답변:


103

DNSSEC에는 몇 가지 위험이 있지만, 반사 나 증폭과 직접 관련이 없습니다. 이 경우 EDNS0 메시지 크기 확장은 빨간색 청어입니다. 설명하겠습니다.

이전의 신원 증명에 의존하지 않는 패킷 교환은 인증되지 않은 패킷 교환을 리플렉터 및 증폭기로 사용할 수있는 DDoS 공격자가 남용 할 수 있습니다. 예를 들어 ICMP ( "ping"뒤에있는 프로토콜)는 이러한 방식으로 남용 될 수 있습니다. TCP SYN 패킷은 SYN-ACK 패킷을 원하지 않는 일부 희생자로부터 SYN이 스푸핑 된 경우에도 최대 40 개의 SYN-ACK 패킷을 요청합니다. 물론, 모든 UDP 서비스는 NTP, SSDP, uPNP를 포함한이 공격에 취약하며 DNS를 포함한 여기의 다른 응답에서 언급 한 바와 같습니다.

대부분의 침입 탐지, 침입 방지 및로드 밸런서 어플라이언스는 병목 현상이 발생하여 "라인 속도"트래픽을 유지할 수 없습니다. 또한 많은 라우터가 회선 속도로 작동 할 수없고 일부 스위치도 실행할 수 없습니다. 이러한 병목 현상은 "경로에서"가장 작고 링크 자체보다 작기 때문에 정체 기반 DDoS 공격의 실제 대상입니다. 공격 트래픽으로 누군가의 방화벽을 사용중인 상태로 유지할 수 있으면 링크가 가득 차지 않더라도 트래픽이 제대로 전달되지 않습니다. 방화벽을 느리게 만드는 것은 초당 총 비트 수 (더 큰 메시지를 사용하여 증가 할 수 있고 EDNS0 및 DNSSEC가 수행함)가 아니라 초당 총 패킷 수입니다.

DNSSEC의 큰 메시지 크기로 인해 DNSSEC가 DDoS를 악화시키는 방법에 대한 도시의 전설이 많이 있습니다. 이는 직관적 인 의미와 "좋은 소리"이지만, 그것은 거짓입니다. 그러나이 범례에 대한 진실이 파헤쳐 졌다면 실제 대답은 여전히 ​​다른 곳에 놓여있을 것입니다. [DNSSEC는 항상 EDNS0을 사용하지만 EDNS0은 DNSSEC없이 사용할 수 있기 때문에] 많은 비 DNSSEC 응답은 DNSSEC만큼 큽니다. 응답이 될 것입니다. SPF 정책 또는 DKIM 키를 나타내는 데 사용되는 TXT 레코드를 고려하십시오. 또는 대규모 주소 또는 MX 레코드 세트. 즉, 공격에 DNSSEC가 필요하지 않으므로 DDoS 위험으로 인해 DNSSEC에 중점을 두는 것은 잘못된 에너지입니다.

DNSSEC에는 위험이 있습니다! 사용하기 어렵고 올바르게 사용하기가 어렵습니다. 영역 데이터 변경, 등록자 관리, 새 서버 인스턴스 설치를위한 새로운 작업 흐름이 필요한 경우가 종종 있습니다. 이 모든 것을 테스트하고 문서화해야하며 DNS와 관련된 문제가 발생할 때마다 가능한 원인으로 DNSSEC 기술을 조사해야합니다. 그리고 모든 일을 올바르게 수행하면 최종 서명자로서 자신의 온라인 콘텐츠와 시스템이 고객에게 더욱 취약 해집니다. 파 엔드 서버 운영자는 결과적으로 다른 모든 사람의 컨텐츠와 시스템이 더 취약 해집니다. 이러한 위험은 종종 이점을 능가하는 것으로 보입니다. 유일한 이점은 DNS 데이터를 기내 수정 또는 대체로부터 보호하는 것입니다. 그 공격은이 모든 노력의 가치가 없을 정도로 드물다. 우리는 DNSSEC가 새로운 응용 프로그램으로 인해 언젠가 유비쿼터스가되기를 희망합니다. 그러나 진실은 오늘날 DNSSEC는 모든 비용과 이익이 없으며 위험이 높다는 것입니다.

따라서 DNSSEC를 사용하고 싶지 않다면 그것은 특권이지만 DNSSEC의 문제가 DDoS 증폭기의 역할이라는 것을 다른 사람에게 혼동하지 마십시오. DNSSEC는 DDoS 증폭기로서 필요한 역할을하지 않습니다. DNS를 DDoS 증폭기로 사용하는 다른 더 저렴한 방법이 있습니다. DNSSEC를 사용하고 싶지 않다면 아직 Kool Aid를 취하지 않았고 1 차 무버 (최후)가 아닌 마지막 무인자가되고 싶기 때문입니다.

"인증 서버"라고도하는 DNS 콘텐츠 서버는 DNS가 UDP를 사용하고 스푸핑 된 소스 패킷에 의해 UDP가 악용 될 수 있기 때문에 DNS 반영 증폭기로 남용되지 않아야합니다. 이러한 종류의 악용으로부터 DNS 컨텐츠 서버를 보호하는 방법은 UDP를 차단하거나 TCP를 강제로 사용하지 않거나 (TC = 1 트릭을 사용하여) 모든 쿼리를 차단하거나 DNSSEC를 옵트 아웃하지 않는 것입니다. 그 어떤 것도 당신을 도울 수 없습니다. DNS 응답 속도 제한 이 필요 합니다BIND, Knot 및 NSD를 포함한 여러 오픈 소스 이름 서버에 현재 존재하는 완전 무료 기술인 (DNS RRL). DNS 서버 자체 (RRL이 추가 된)와 같은 콘텐츠 인식 미들 박스 만 공격의 내용과 그렇지 않은 내용을 정확하게 추측 할 수있는 요청에 대해 충분히 알고 있기 때문에 방화벽으로 DNS 반영 문제를 해결할 수 없습니다. 다시 강조하겠습니다. DNS RRL은 무료이며 모든 권한 서버가이를 실행해야합니다.

마지막으로 편견을 드러내고 싶습니다. 나는 대부분의 BIND8을 작성했고, EDNS0을 발명했으며, DNS RRL을 공동 발명했습니다. 1988 년 이래 DNS를 20대로 일해 왔으며, 이제 50 개 정도의 소문이 나고, 문제를 오해하기위한 반도 금 해결책에 대한 인내심이 줄어 들었습니다. 이 메시지가 "아이들 이여, 내 잔디밭에 엎드려!"


7
이것이 Real Paul ™임을 확인합니다.
Andrew B

1
Real Paul ™이 될 수없는 @AndrewB, 그의 게시물에는 대문자가 있습니다! ;-)
Alnitak

6
@kasperd는 현재 IETF를 통해 진행중인 "draft-ietf-dnsop-cookies"를 참조하십시오.
Alnitak

4
kasperd : [속도 제한을 수행하는 DNS 서버 자체가 DDoS 공격을위한 더 쉬운 대상이 될 것입니다.] 나는 바보라는 것을 알고 있지만 그 바보는 아닙니다. dns rrl은 어떤 식 으로든 안전성을 떨어 뜨립니다. 알려진 모든 공격에 대한 방어는 아니지만 새로운 공격이없는 제작자입니다.
Paul Vixie

2
@kasperd 설치 기반은 항상 문제입니다. 비준수 시스템은 물론 호환 설치 기반에서도 작동하는 솔루션은 없습니다. 좋은 소식은 EDNS 쿠키 지원이 이미 BIND 9.11의 코드베이스에 있으며 (AIUI)가 기본적으로 켜져 있다는 것입니다.
Alnitak

7

두 가지 특정 취약점에 대해 알고 있습니다. Håkan이 언급 한 반사 / 증폭이 있습니다. 그리고 영역 열거의 가능성이 있습니다.

반사 / 증폭

리플렉션은 스푸핑 된 소스 IP를 가진 요청이 DNS 서버로 전송되는 공격을 의미합니다. 스푸핑되는 호스트가 공격의 주요 피해자입니다. DNS 서버는 무의식적으로 요청하지 않은 호스트에게 회신을 보냅니다.

증폭은 반사 된 응답이 원래 요청보다 많은 바이트 또는 더 많은 패킷으로 구성된 모든 반사 공격을 말합니다. 이러한 방식으로 DNSSEC + EDNS0 증폭을하기 전에는 최대 512 바이트 만 전송 될 수있었습니다. DNSSEC + EDNS0을 사용하면 일반적으로 3-4 개의 패킷에 걸쳐 4096 바이트를 보낼 수 있습니다.

이러한 공격에 대한 완화가 가능하지만이를 구현하는 DNS 서버를 모르겠습니다.

클라이언트 IP가 확인되지 않으면 DNS 서버는 잘린 응답을 보내 클라이언트가 TCP로 전환하도록 할 수 있습니다. 잘린 응답은 증폭을 제거하는 요청 (또는 클라이언트가 EDNS0을 사용하고 응답이 사용하지 않는 경우 더 짧음)만큼 짧을 수 있습니다.

TCP 핸드 셰이크를 완료하고 연결에서 DNS 요청을 보내는 클라이언트 IP는 일시적으로 화이트리스트에 올릴 수 있습니다. 허용 된 IP는 UDP 쿼리를 보내고 최대 512 바이트 (EDNS0를 사용하는 경우 4096 바이트)의 UDP 응답을받습니다. UDP 응답이 ICMP 오류 메시지를 트리거하면 IP가 화이트리스트에서 다시 제거됩니다.

이 방법은 블랙리스트를 사용하여 되돌릴 수도 있습니다. 이는 클라이언트 IP가 기본적으로 UDP를 통해 쿼리 할 수 ​​있지만 ICMP 오류 메시지로 인해 IP가 블랙리스트에 들어가도록 TCP 쿼리가 필요한 IP가 블랙리스트에 있음을 의미합니다.

모든 관련 IPv4 주소를 포함하는 비트 맵은 444MB의 메모리에 저장 될 수 있습니다. IPv6 주소는 다른 방법으로 저장해야합니다.

영역 열거

영역 열거가 처음에 취약한 지 여부는 논쟁의 대상입니다. 그러나 영역의 모든 이름을 공개적으로 알리지 않으려면 취약한 것으로 간주합니다. 영역 열거는 대부분 NSEC3 레코드를 사용하여 완화 할 수 있습니다.

NSEC3을 사용할 때도 여전히 문제는 공격자가 임의의 이름을 쿼리하여 각 레이블의 해시를 찾을 수 있다는 것입니다. 공격자가 모든 해시를 확보하면 해당 해시에서 오프라인 무차별 대입 공격을 수행 할 수 있습니다.

영역 열거에 대한 적절한 방어를 위해서는 공격자가 추측 할 때마다 권한있는 서버에 쿼리를 수행해야합니다. 그러나 DNSSEC에는 이러한 방어 기능이 없습니다.


2
그러나 영역 열거는 서비스 공급자에게 문제가되지 않습니까? (그들의 의견과 선호도에 따라 영역 "소유자"오히려 가능한 우려.)
는 Håkan 고 Lindqvist

@ HåkanLindqvist 맞습니다. 어쩌면 내 질문이 내가 원하는 것보다 더 구체적이었을 수도 있습니다. 이 정보가 매우 흥미로 웠습니다.
Johann Bauer

TCP를 시도한 클라이언트를 허용 목록에 올리려는 아이디어가 고려되었지만 특허를 받았습니다.
Alnitak

4

염두에 두어야 할 것은 실제로 DNSSEC에만 국한된 것이 아니라 DNSSEC가 의존하는 EDNS0 확장에 관한 것입니다.

EDNS0은 더 큰 UDP 페이로드를 허용하고 더 큰 UDP 페이로드는 더 나쁜 트래픽 반영 / 증폭 공격을 허용 할 수 있습니다.


나는 확인 리졸버의 백분율이 무엇인지 모르지만 인기있는 네임 서버 소프트웨어는 기본적으로 유효성 검사와 함께 제공되는 것으로 보이며 Comcast 및 Google 공개 리졸버와 같이 유효성 검사를 수행하는 공개 서비스 업체를 쉽게 찾을 수 있습니다.

이를 바탕으로 검증 리졸버의 백분율이 서명 된 영역의 백분율보다 훨씬 나은 모양 일 것이라고 생각합니다.


네, 소고기도 EDNS와 함께있을 것 같아요. 그래도 DNSSEC로 뼈를 선택하는 것은 끔찍합니다.
앤드류 B
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.