이것은 공개 DNS 확인자 보안에 관한 정식 질문입니다.
개방형 DNS 서버는 위치에 관계없이 회사 전체에서 일관되게 사용할 수있는 IP 주소를 제공하므로 매우 깔끔하고 편리합니다. Google과 OpenDNS는이 기능을 제공하지만 이러한 회사가 DNS 쿼리에 액세스하기를 원치 않습니다.
나는 우리 회사에서 사용하기 위해 이와 같은 것을 설정하고 싶지만, 이것이 위험한 관행에 대해 (특히 증폭 공격 과 관련하여 ) 많은 것을 듣고 나는 우리가 이것을 올바르게하고 싶습니다. 이러한 유형의 환경을 구축 할 때 명심해야 할 사항은 무엇입니까?
답변
이것을 이해하는 데 필요한 몇 가지 사항이 있습니다.
이것은 네트워크 엔지니어링 문제입니다.
이 유형의 환경을 설정하려는 대부분의 사람들은 시스템 관리자입니다. 멋지다, 나는 시스템 관리자이기도하다! 업무의 일부는 귀하의 책임이 끝나는 곳과 다른 사람의 시작을 이해하는 것이며 시스템 관리자가 스스로 해결할 수있는 문제는 아닙니다. 이유는 다음과 같습니다.
- UDP는 상태 비 저장 프로토콜입니다. 클라이언트 핸드 셰이크가 없습니다.
- DNS 서버에 대한 쿼리는 인증되지 않은 2 단계 트랜잭션 (쿼리, 회신)입니다. 서버가 응답하기 전에 소스 IP가 스푸핑되었는지 여부를 서버가 알 수있는 방법이 없습니다.
- 쿼리가 서버에 도달 할 때 스푸핑 된 UDP 패킷을 방지하기에는 이미 너무 늦습니다. 스푸핑은 BCP 38 및 BCP 84 문서에서 다루는 주제 인 수신 필터링 으로 만 방지 할 수 있습니다 . 이들은 DNS 서버 앞에있는 네트워킹 장치에 의해 구현됩니다.
- 데이터 센터를 처음부터 끝까지 설정하는 방법 또는 이러한 모범 사례를 구현하는 방법에 대한 연습을 제공 할 수 없습니다. 이것들은 여러분의 필요에 따라 매우 다릅니다. Q & A 형식은이 작업에 적합하지 않으며이 사이트는 전문 인력을 고용하여 전문 작업을 대신 할 수 없습니다.
- 10 억 달러 규모의 대기업이 침입 필터링을 올바르게 구현한다고 가정하지 마십시오.
이것은 모범 사례가 아닙니다. 가장 좋은 방법은이 작업을 수행하지 않는 것입니다.
인터넷 연결 DNS 확인자를 설정하는 것은 매우 쉽습니다. 그렇게하는 데 따르는 위험을 이해하는 것보다 하나를 설정하는 것이 훨씬 적은 연구입니다. 이것은 선의의 의도가 타인의 잘못 (및 고통)을 실수로 가능하게하는 경우 중 하나입니다.
- DNS 서버가 표시되는 소스 IP 주소에 응답하면 공개 리졸버를 실행하는 것입니다. 이들은 무고한 사람들에 대한 증폭 공격 에 지속적으로 활용되고 있습니다. 새로운 시스템 관리자는 매일 공개 리졸버 를 세우고 있기 때문에 악의적 인 개인이 지속적으로 검사하는 것이 유리합니다. 2015 년 현재 공개 리졸버가 공격에 사용 될지 여부는 의문의 여지가 없습니다. 즉각적이지 않을 수도 있지만 확실히 일어날 것입니다.
- DNS 소프트웨어 (예 : BIND)를 사용하여 ACL을 적용하더라도 서버가 응답 할 스푸핑 된 DNS 패킷을 제한하기 만하면됩니다. DNS 인프라를 사용하여 ACL의 장치를 공격 할뿐만 아니라 DNS 서버와 해당 장치 사이의 네트워킹 장치를 공격 할 수 있다는 것을 이해해야합니다. 데이터 센터를 소유하고 있지 않다면, 그 이상은 문제가 아닙니다.
Google과 OpenDNS 가이 작업을 수행하므로 왜 할 수 없습니까?
때로는 현실에 대한 열정을 평가해야 할 때가 있습니다. 다음은 스스로에게 어려운 질문입니다.
-
이것은 당신이 변덕에 설정하고 싶습니까, 아니면 올바른 일을하기 위해 몇 백만 달러를 투자해야합니까?
-
전담 보안 팀이 있습니까? 전용 학대 팀? 둘 다 새로운 인프라의 남용을 다루는주기와 외부 당사자로부터받을 불만이 있습니까?
-
당신은 가지고 있습니까 법률 팀?
-
이 모든 것이 말되고 행해질 때,이 모든 노력이 원격으로 스스로를 지불하거나 회사를 위해 이익을 돌리거나이 방향으로 인도 한 불편을 다루는 금전적 가치를 초과 할 것입니까?
마지막으로,이 스레드는 Q & A가 연결되어있는 대부분의 사용자에게 실망스러운 것임을 알고 있습니다. Serverfault는 답변을 제공하기 위해 여기에 있으며 “이것은 나쁜 생각입니다.하지 마십시오”라는 대답은 일반적으로 매우 유용한 것으로 인식되지 않습니다. 일부 문제는 처음에 나타난 것보다 훨씬 복잡하며 이는 그 중 하나입니다.
이 작업을 수행 하려는 경우 이러한 종류의 솔루션을 구현하려고 할 때 여전히 도움을 요청할 수 있습니다. 가장 중요한 것은 문제가 그 자체 로 너무 커서 응답이 편리한 Q & A 형식으로 제공 되기 어렵다는 것 입니다. 이미 주제를 연구하는 데 상당한 시간을 투자하고 구현 과정에서 발생한 특정 논리 문제로 우리에게 접근 해야합니다. 이 Q & A의 목적은 더 큰 그림을 더 잘 이해 하고이 질문만큼 광범위한 질문에 대답 할 수없는 이유 를 이해하는 데 도움 이됩니다.
인터넷을 안전하게 유지하도록 도와주세요! 🙂
답변
개방형 DNS 되풀이를 실행하든 신뢰할 수있는 DNS 서버를 실행하든 문제는 동일하며 가능한 대부분의 솔루션도 동일합니다.
최고의 솔루션
DNS 쿠키 는 DNS 서버에 클라이언트 IP 주소가 스푸핑되지 않았 음을 증명하기 위해 클라이언트가 쿠키를 보내도록 요구하는 방법을 제안하는 표준입니다. 첫 번째 조회에는 추가 왕복 1 회가 소요되며 이는 솔루션이 제공 할 수있는 가장 낮은 오버 헤드입니다.
이전 고객을위한 대체
DNS 쿠키는 아직 표준화되지 않았으므로 현재와 향후 몇 년간 구형 클라이언트를 지원해야합니다.
DNS 쿠키 지원없이 클라이언트의 제한 요청을 평가할 수 있습니다. 그러나 속도 제한으로 인해 공격자가 DNS 서버를보다 쉽게 수행 할 수 있습니다. 일부 DNS 서버에는 신뢰할 수있는 DNS 서버 전용으로 설계된 속도 제한 기능이 있습니다. 재귀 해결 프로그램에 대해 요청하므로 이러한 속도 제한 구현이 적용되지 않을 수 있습니다. 설계상의 속도 제한은 서버의 병목 현상이되므로 공격자는 속도 제한이없는 경우보다 합법적 인 요청을 제거하기 위해 트래픽을 적게 보내야합니다.
속도 제한의 한 가지 장점은 공격자가 DNS 요청으로 DNS 서버를 과도하게 사용하는 경우 서버에 ssh하고 상황을 조사 할 수있는 용량이 남아있을 가능성이 높다는 것입니다. 또한 속도 제한은 주로 많은 요청을 보내는 클라이언트 IP에서 요청을 삭제하도록 설계 될 수 있으며, 이는 스푸핑 클라이언트 IP에 액세스 할 수없는 공격자로부터 DoS로부터 사용자를 보호하기에 충분할 수 있습니다.
이러한 이유로 실제 용량에서 약간의 속도 제한은 실제로 증폭으로부터 보호하지 않더라도 좋은 생각 일 수 있습니다.
TCP 사용
UDP에 대한 응답이 너무 크다는 오류 코드를 전송하여 클라이언트가 TCP를 사용하도록 할 수 있습니다. 여기에는 몇 가지 단점이 있습니다. 두 번의 추가 왕복이 필요합니다. 그리고 일부 잘못된 클라이언트는이를 지원하지 않습니다.
두 번의 추가 왕복 비용은이 방법을 사용하는 첫 번째 요청으로 만 제한 될 수 있습니다.
클라이언트 IP가 확인되지 않으면 DNS 서버는 잘린 응답을 보내 클라이언트가 TCP로 전환하도록 할 수 있습니다. 잘린 응답은 증폭을 제거하는 요청 (또는 클라이언트가 EDNS0을 사용하고 응답이 사용하지 않는 경우 더 짧음)만큼 짧을 수 있습니다.
TCP 핸드 셰이크를 완료하고 연결에서 DNS 요청을 보내는 클라이언트 IP는 일시적으로 화이트리스트에 올릴 수 있습니다. 허용 된 IP는 UDP 쿼리를 보내고 최대 512 바이트 (EDNS0를 사용하는 경우 4096 바이트)의 UDP 응답을받습니다. UDP 응답이 ICMP 오류 메시지를 트리거하면 IP가 화이트리스트에서 다시 제거됩니다.
블랙리스트를 사용하여이 방법을 되돌릴 수도 있습니다. 이는 클라이언트 IP가 기본적으로 UDP를 통해 쿼리 할 수 있지만 ICMP 오류 메시지로 인해 블랙리스트를 해제하려면 TCP 쿼리가 필요한 IP가 블랙리스트에 있음을 의미합니다.
모든 관련 IPv4 주소를 다루는 비트 맵을 444MB의 메모리에 저장할 수 있습니다. IPv6 주소는 다른 방법으로 저장해야합니다.
DNS 서버가이 방법을 구현했는지 여부는 알 수 없습니다.
또한 일부 TCP 스택은 증폭 공격에서 악용 될 수 있다고보고되었습니다. 그러나 이는 DNS뿐만 아니라 모든 TCP 기반 서비스에 적용됩니다. 이러한 취약점은 TCP 스택이 SYN 패킷에 응답하여 둘 이상의 패킷을 보내지 않도록 수정 된 커널 버전으로 업그레이드하여 완화해야합니다.