DoT(DNS-over-TLS) 및 DoH(DNS-over-HTTPS) 사용 위험 최소화

DoH 및 DoT 사용 위험 최소화

DoH 및 DoT 보호

DNS 트래픽을 제어합니까? 조직에서는 네트워크 보안을 위해 많은 시간, 돈, 노력을 투자합니다. 그러나 종종 충분한 관심을 받지 못하는 영역 중 하나가 바로 DNS입니다.

DNS가 가져오는 위험에 대한 좋은 개요는 다음과 같습니다. Verisign 프레젠테이션 인포시큐리티 컨퍼런스에서

조사에 참여한 랜섬웨어 클래스 중 31%는 키 교환을 위해 DNS를 사용했습니다.

조사에 참여한 랜섬웨어 클래스 중 31%는 키 교환에 DNS를 사용했습니다.

문제는 심각합니다. Palo Alto Networks Unit 42 연구소에 따르면 악성 코드의 약 85%가 DNS를 사용하여 명령 및 제어 채널을 설정하므로 공격자가 쉽게 네트워크에 악성 코드를 삽입하고 데이터를 훔칠 수 있습니다. DNS 트래픽은 처음부터 대부분 암호화되지 않았으며 NGFW 보안 메커니즘을 통해 쉽게 분석할 수 있습니다. 

DNS 연결의 기밀성을 높이기 위한 새로운 DNS 프로토콜이 등장했습니다. 주요 브라우저 공급업체 및 기타 소프트웨어 공급업체에서 적극적으로 지원합니다. 암호화된 DNS 트래픽은 곧 기업 네트워크에서 증가하기 시작할 것입니다. 도구로 제대로 분석 및 해결되지 않은 암호화된 DNS 트래픽은 회사에 보안 위험을 초래합니다. 예를 들어 이러한 위협은 DNS를 사용하여 암호화 키를 교환하는 암호 잠금 장치입니다. 공격자들은 이제 데이터에 대한 액세스를 복원하기 위해 수백만 달러의 몸값을 요구하고 있습니다. 예를 들어 Garmin은 천만 달러를 지불했습니다.

적절하게 구성되면 NGFW는 DNS-over-TLS(DoT) 사용을 거부하거나 보호할 수 있으며 DNS-over-HTTPS(DoH) 사용을 거부하는 데 사용될 수 있으므로 네트워크의 모든 DNS 트래픽을 분석할 수 있습니다.

암호화된 DNS란 무엇입니까?

DNS 란 무엇입니까?

DNS(Domain Name System)는 사람이 읽을 수 있는 도메인 이름(예: 주소)을 확인합니다. www.paloaltonetworks.com )을 IP 주소(예: 34.107.151.202)로 변경합니다. 사용자가 웹 브라우저에 도메인 이름을 입력하면 브라우저는 DNS 서버에 DNS 쿼리를 보내 해당 도메인 이름과 연결된 IP 주소를 요청합니다. 이에 대한 응답으로 DNS 서버는 이 브라우저가 사용할 IP 주소를 반환합니다.

DNS 쿼리와 응답은 네트워크를 통해 암호화되지 않은 일반 텍스트로 전송되므로 응답을 염탐하거나 변경하고 브라우저를 악성 서버로 리디렉션하는 데 취약합니다. DNS 암호화를 사용하면 전송 중에 DNS 요청을 추적하거나 변경하기가 어렵습니다. DNS 요청 및 응답을 암호화하면 중간자 공격으로부터 사용자를 보호하는 동시에 기존 일반 텍스트 DNS(도메인 이름 시스템) 프로토콜과 동일한 기능을 수행합니다. 

지난 몇 년 동안 두 가지 DNS 암호화 프로토콜이 도입되었습니다.

1. DNS-over-HTTPS(DoH)

2. DNS-over-TLS(DoT)

이러한 프로토콜에는 한 가지 공통점이 있습니다. 즉, 모든 가로채기 및 조직의 보안 요원으로부터도 DNS 요청을 의도적으로 숨깁니다. 프로토콜은 주로 TLS(전송 계층 보안)를 사용하여 일반적으로 DNS 트래픽에 사용되지 않는 포트를 통해 쿼리를 작성하는 클라이언트와 DNS 쿼리를 해결하는 서버 간에 암호화된 연결을 설정합니다.

DNS 쿼리의 기밀성은 이러한 프로토콜의 큰 장점입니다. 그러나 네트워크 트래픽을 모니터링하고 악성 연결을 탐지 및 차단해야 하는 보안 요원에게는 문제가 됩니다. 프로토콜의 구현이 다르기 때문에 DoH와 DoT의 분석 방법도 다릅니다.

HTTPS를 통한 DNS (DoH)

HTTPS 내부의 DNS

DoH는 HTTPS에 잘 알려진 포트 443을 사용합니다. RFC는 "동일한 연결에서 DoH 트래픽을 다른 HTTPS 트래픽과 혼합"하고 "DNS 트래픽 분석을 어렵게 만들고" 기업 통제를 우회하려는 의도를 구체적으로 명시하고 있습니다. ( RFC 8484 DoH 섹션 8.1 ). DoH 프로토콜은 TLS 암호화와 일반적인 HTTPS 및 HTTP/2 표준에서 제공하는 요청 구문을 사용하여 표준 HTTP 요청 위에 DNS 요청 및 응답을 추가합니다.

DoH와 관련된 위험

일반 HTTPS 트래픽과 DoH 요청을 구별할 수 없는 경우 조직 내의 애플리케이션은 DoH 요청에 응답하는 타사 서버로 요청을 리디렉션하여 로컬 DNS 설정을 우회할 수 있습니다. 이는 모니터링을 우회합니다. DNS 트래픽을 제어합니다. 이상적으로는 HTTPS 복호화 기능을 사용하여 DoH를 제어해야 합니다. 

И Google과 Mozilla는 DoH 기능을 구현했습니다. 최신 버전의 브라우저에서 두 회사 모두 모든 DNS 요청에 대해 기본적으로 DoH를 사용하기 위해 노력하고 있습니다. 마이크로소프트도 계획을 개발 중 DoH를 운영 체제에 통합하는 방법. 단점은 평판이 좋은 소프트웨어 회사뿐만 아니라 공격자들도 전통적인 기업 방화벽 조치를 우회하는 수단으로 DoH를 사용하기 시작했다는 것입니다. (예를 들어 다음 문서를 검토하세요. PsiXBot은 이제 Google DoH를 사용합니다. , PsiXBot은 업데이트된 DNS 인프라를 통해 계속 발전하고 있습니다. и Godlua 백도어 분석 .) 두 경우 모두 좋은 DoH 트래픽과 악의적인 DoH 트래픽 모두 감지되지 않으므로 조직은 DoH를 악성 코드(C2)를 제어하고 민감한 데이터를 훔치는 통로로 악의적으로 사용하는 것을 알 수 없습니다.

DoH 트래픽에 대한 가시성 및 제어 보장

DoH 제어를 위한 최상의 솔루션으로 HTTPS 트래픽을 해독하고 DoH 트래픽(애플리케이션 이름: dns-over-https)을 차단하도록 NGFW를 구성하는 것이 좋습니다. 

먼저 NGFW가 HTTPS를 해독하도록 구성되어 있는지 확인하세요. 최고의 암호 해독 기술에 대한 가이드.

둘째, 아래와 같이 애플리케이션 트래픽 "dns-over-https"에 대한 규칙을 만듭니다.

Palo Alto Networks NGFW 규칙으로 DNS-over-HTTPS 차단

임시 대안으로(조직에서 HTTPS 암호 해독을 완전히 구현하지 않은 경우) "dns-over-https" 애플리케이션 ID에 "거부" 작업을 적용하도록 NGFW를 구성할 수 있지만 효과는 특정 웰을 차단하는 것으로 제한됩니다. DoH 서버는 도메인 이름으로 알려져 있으므로 HTTPS 암호 해독 없이는 DoH 트래픽을 완전히 검사할 수 없습니다(참조  Palo Alto Networks의 Applipedia   "dns-over-https"를 검색하세요).

DoT(DNS over TLS)

TLS 내부의 DNS

DoH 프로토콜은 동일한 포트에서 다른 트래픽과 혼합되는 경향이 있지만 DoT는 대신 기본적으로 해당 목적으로 예약된 특수 포트를 사용하며 심지어는 기존의 암호화되지 않은 DNS 트래픽에서 동일한 포트를 사용하는 것을 특별히 허용하지 않습니다( RFC 7858, 섹션 3.1 ).

DoT 프로토콜은 TLS를 사용하여 잘 알려진 포트 853( RFC 7858 섹션 6 ). DoT 프로토콜은 조직이 포트의 트래픽을 더 쉽게 차단하거나 트래픽을 허용하지만 해당 포트에서 암호 해독을 활성화할 수 있도록 설계되었습니다.

DoT와 관련된 위험

Google은 클라이언트에 DoT를 구현했습니다. 안드로이드 9 파이 이상 , 가능한 경우 DoT를 자동으로 사용하도록 기본 설정되어 있습니다. 위험을 평가하고 조직 수준에서 DoT를 사용할 준비가 되었다면 네트워크 관리자가 이 새로운 프로토콜에 대한 경계를 통해 포트 853의 아웃바운드 트래픽을 명시적으로 허용하도록 해야 합니다.

DoT 트래픽에 대한 가시성 및 제어 보장

DoT 제어를 위한 모범 사례로 조직의 요구 사항에 따라 위 중 하나를 권장합니다.

• 대상 포트 853에 대한 모든 트래픽을 해독하도록 NGFW를 구성합니다. 트래픽을 해독하면 DoT는 구독 활성화와 같은 모든 작업을 적용할 수 있는 DNS 애플리케이션으로 나타납니다. 팔로알토 네트웍스 DNS 보안 DGA 도메인 또는 기존 도메인을 제어하기 위해 DNS 싱크홀링 그리고 스파이웨어 방지.

• 대안은 App-ID 엔진이 포트 853에서 'dns-over-tls' 트래픽을 완전히 차단하도록 하는 것입니다. 이는 일반적으로 기본적으로 차단되며 조치가 필요하지 않습니다('dns-over-tls' 애플리케이션 또는 포트 트래픽을 특별히 허용하지 않는 한). 853).

출처 : habr.com