hippo 데브옵스
2023. 9. 16. 12:10
2023. 9. 16. 12:10
1. DNS(Domain Name System) 보안 프로토콜
- 최초 DNS는 엄격한 보호 수단이 없었지만, 이후 카민스키(Kaminsky) 버그와 같은 보안상 취약점이 발견되면서 2010년 DNSSEC(Domain Name System Security Extensions)이 탄생
- DNSSEC은 디지털 서명 기반의 암호화로 보안을 강화 → 전 세계 DNS 클라이언트는 DNSSEC을 이용해 DNS 응답이 정상적인 DNS 서버에서 왔으며, 전송 과정에서 변조되지 않았음을 확인
- DNSSEC 등장 이후 DNS 오버 HTTPS(DNS over HTTPS, DoH)와 DNS 오버 TLS(DNS over TLS, DoT)가 등장
- DNSSEC가 DNS 응답의 진정성과 데이터 무결성을 보장하지만 개인정보는 보호하지 않기 때문에 DoH와 DoT 가 개발 → DoH와 DoT 프로토콜은 종단간 암호화를 제공하므로 데이터의 기밀성이 보장
- DNS 트래픽도 HTTPS 사이트 간의 웹 트래픽과 같은 종단간 암호화의 이점을 얻게 됨
1.1. DoH란
- DNS는 전송 제어 프로토콜(Transmission Control Protocol, TCP)에서 사용할 수도 있지만 기본적으로 DNS 프로토콜은 전송 계층 프로토콜인 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)에서 동작
- DoH는 더 빠른 UDP가 아닌 HTTPS를 통해 암호화된 DNS 메시지를 전송
- HTTPS는 전송 계층 보안(Transport Layer Security, TLS)에서 실행되는 HTTP 프로토콜이므로 DoH는 사실상 DNS 오버 HTTP 오버 TLS(DNS over HTTP over TLS)라고 할 수 있음
- DoH에서 DNS 질의와 DNS 응답은 모두 HTTPS를 통해 전송되며 포트 443을 사용 → 다른 HTTPS 웹 트래픽과 거의 구분 불가
- 웹 브라우저에서 구글 DoH 서비스를 사용해서 CSOOnline.com 도메인 해석(resolve)
- 브라우저에 HTTPS URL을 입력해 HTTPS를 통해 도메인 이름을 해석하는 방식은 SSL/TLS를 사용하는 일반 웹사이트를 방문할 때와 차이가 없음
- 구글이 반환하는 DNS 응답은 CSO의 서버 IP 주소(A 레코드)로, 모두 JSON 형식으로 깔끔하게 포장됨
- 사용자와 구글 DoH 사이에 기업 중간자(man-in-the-middle, MitM) 프록시가 없다면, 사용자가 조회하고자 하는 도메인(CSO 온라인)이 무엇인지, 또는 DNS 질의에 대한 응답(JSON 결과)이 무엇인지 누구도 알아낼 수 없음
- DoH를 사용하면 개인정보(데이터 기밀성) 보호와 수신된 정보의 무결성(DNS 응답이 전송 중 변조되지 않음)이 보장
- 종단간 암호화 채널을 통해 DNS를 전송하는 방식에는 문제의 소지도 있음 → 공격자가 DoH 서비스를 악용해 악성 트래픽을 숨긴 사례가 존재 가능
- 공격자는 구글의 DoH 또는 아무 DoH 제공업체를 통해 악성 도메인을 해석할 수 있음
- 반환된 암호화 응답에는 공격자가 제어하는 도메인의 TXT 레코드와 함께 암호화된 악성 페이로드가 포함되고, 악성코드가 페이로드를 파싱할 수 있음
- 기본적으로 위협 행위자가 지휘통제(C2) 활동을 용이하게 하기 위해 보안 DNS 프로토콜을 악용
- DoH 제공업체는 합법적인 비즈니스 사용 사례가 있으므로 기업 네트워크와 DoH 제공업체 간의 인바운드 또는 아웃바운드 트래픽을 단순히 차단하기는 어려움
1.2. DoT란
- DoT는 애플리케이션 계층에 상주하는 HTTPS가 아닌 전송 계층에서 TLS 프로토콜을 통해 DNS 질의를 암호화
- DoT는 DoH와 달리 애플리케이션 수준 HTTPS를 생략
- 기본적으로 DoT는 DNS UDP 요청과 응답을 TLS를 통해 암호화하며 메시지가 전송 과정에서 변경되지 않도록 보장
- DoT는 HTTPS(포트 443) 또는 일반 DNS(포트 53)와는 다른 포트 853을 사용
- DNS 클라이언트와 리졸버 간의 통신이 TLS를 통해 이뤄지므로 DoT 트래픽도 DoH와 마찬가지로 종단간 암호화의 이점을 얻게 됨
2. DoH와 DoT 중 어느 DNS 프로토콜이 더 좋을까
- 네트워크 관리자의 입장에서는 제어가 쉬운 DoT를 선호
- DNS 질의 모니터링 측면에서 더 높은 유연성을 제공하는 DoT 쪽을 선호
- 네트워크에서 악성 DNS 트래픽과 침해 지표(IOC)를 차단하려는 보안 전문가라면 DoT가 유용
- DoH의 경우 사용자의 DNS 질의가 다른 HTTPS 트래픽과 섞이므로 최종 사용자의 개인정보 보호가 더 강화 → 네트워크 관리자는 해석되는 도메인과 반환되는 DNS 응답을 확인 X
- 네트워크 관리자 입장에서는 정상적인 비즈니스 통신에 영향을 미치지 않으면서 DoH를 차단하기가 훨씬 더 어려움
- DoT 차단을 위해 기업 방화벽을 구성해 포트 853을 통해 이동하는 트래픽을 일률적으로 필터링하는 정책을 추가가 쉽지만, 포트 443(DoH) 필터링은 불가능 → 만약 443 포트를 차단할 경우 정상적인 트래픽도 차단될 수 있음
- DNS 패킷이 가벼움
- DoH는 애플리케이션 계층에 위치하는 HTTPS를 사용하지만, DoT는 전송 계층에 위치함으로 가벼움
- DoT는 관여하는 계층의 수가 적으므로 패킷의 크기가 더 작음 → 패킷의 크기가 작음으로 지연 시간이 낮음
- 새롭게 고안된 프로토콜의 상당수는 HTTPS 또는 SOCKS(토르) 같은 암호화된 채널을 사용
- 최종 사용자에게 더 많은 선택권을 제공하지만 트래픽 필터링 측면에서는 보안 전문가에게 더 큰 어려움이 될 수 있음 → DNS 오버 트위터를 차단하면 트위터 전체가 차단될 수 있음
- 프록시와 같은 보조 대책을 사용할 경우 기밀성과 사용자 개인정보 보호 측면에서 DoH가 제공하는 많은 보호 기능이 무효화될 수 있음
- DoT든 DoH든 DNS 프로토콜 사용은 기업의 필요에 따라 결정
- 사용자 개인정보 보호와 적절한 네트워크 모니터링 간의 타협 기준을 어디에 두느냐도 중요
3. 추가 → 클라우드플레어(Cloudflare)
- 클라우드플레어(Cloudflare)는 새로운 DNS로 확장 시도
- DNS 오버 트위터(DNS over Twitter)
- DNS 오버 토르(DNS over Tor)
- DNS 오버 텔레그램(DNS over Telegram)
- DNS 오버 이메일(DNS over Email)
- 클라우드플레어(Cloudflare)는 고객 사이트 방문자가 토르 네트워크를 사용하도록 허용하는 어니언(Onion) 서비스를 제공
- 클라우드플레어의 리졸버(resolver) 1.1.1.1은 DoH와 DoT를 모두 지원하며 어니언 서비스를 통해 제공 → DNS 오버 토르(DNS over Tor)
- 1.1.1.1로 질의를 해석해 결과를 트윗으로 보내는 트위터 봇으로 운영