앱 및 서버의 DNS 보안 강화

안녕하세요 '앱 및 서버의 DNS 보안 강화’ 영상에 오신 걸 환영합니다 제 이름은 Qiaoyu Deng입니다 이 영상에서는 DNS가 안전하지 않은 이유를 다루고 DNSSEC과 DDR을 이용한 DNS 암호화로 지키는 법을 알아보도록 하죠 먼저 DNS가 안전하지 않은 이유를 논하겠습니다

DNS는 인터넷의 전화번호부죠 도메인 이름을 변환하여 사람들이 읽을 수 있고 쉽게 기억하게 합니다 반면 IP 주소는 기계를 위해 만들어졌죠 다른 인터넷 프로토콜인 TCP, TLS, QUIC은 IP 주소를 요구하기 때문에 모든 것이 DNS에서 시작합니다 오늘날, TLS는 안전한 인터넷 통신을 위해 널리 사용되고 있죠 그건 좋은 일이지만 기저에 있는 DNS는 보안 문제가 있습니다 DNS는 역사적으로 안전하지 않았죠 일부 보안 문제만을 고려하여 1983년에 설계됐습니다 이후 많은 DNS 공격이 이루어졌죠 하나의 예는 DNS 캐시 포이즈닝으로 공격자가 DNS 리졸버의 취약점을 이용하여 유효하지 않은 IP 주소를 반환하여 클라이언트가 악성 호스트에 접속하도록 합니다 이를 통해 DNS의 취약점을 알 수 있죠 진위 인증을 하지 않습니다 전통적인 DNS 클라이언트는 응답을 인증할 수 없어 쉽게 스푸핑 할 수 있죠 또 다른 공격 형태는 DNS 스니핑입니다 공격자가 클라이언트와 DNS 서버의 DNS 트래픽을 보고 클라이언트의 이력을 수집하는 거죠 이는 사용자 개인 정보 보호에 심각한 문제를 줍니다 이런 공격이 가능한 이유는 DNS 트래픽이 원래 암호화되지 않았기 때문이죠 프로토콜을 추가할 수 있는 안전한 시작점 역할을 하려면 DNS를 인증하고 암호화하여야 합니다 DNSSEC을 이용하여 DNS 메시지를 서명하면 인증을 제공할 수 있죠 TLS와 HTTPS를 이용하여 DNS 레졸루션을 암호화하면 개인 정보를 보호할 수 있죠 다음은 DNSSEC에 관해 이야기합시다 DNSSEC은 IETF가 만든 익스텐션 사양이죠 DNS 서비스 제공자의 대부분이 이미 지원하지만 클라이언트 지원은 아직도 증가하고 있죠 iOS 16과 macOS Ventura는 클라이언트 측 DNSSEC 인증을 지원합니다 DNSSEC은 전자 서명을 추가하여 데이터를 인증하죠 데이터의 무결성을 보호합니다 응답이 존재하지 않을 때 존재 부정을 인증하죠 암호화된 인증도 제공합니다 DNSSEC은 메시지에 보안 서명을 첨부하여 데이터 무결성을 보호하죠 만약 공격자에 의해 응답이 변경되면 바뀐 데이터의 서명이 원본 데이터와 일치하지 않습니다 그러면 클라이언트가 위조된 응답을 감지하여 삭제하죠 DNSSEC은 구역 내 기록의 존재 여부를 확정할 수도 있는데 NSEC 기록처럼 특수한 형태의 DNS 기록을 사용하기 때문이죠 NSEC 기록은 안전하게 알파벳 순서로 다음 기록의 이름이 뭔지 알려 줍니다 목록에 있는 이름은 존재하고 목록에 없는 이름은 존재하지 않는 거죠 예를 들어, 여기 3개의 NSEC 기록이 있습니다 기록에 의하면 org 영역은 3개의 이름밖에 없죠 A.org, C.org 그리고 E.org입니다 만약 공격자가 A.org는 존재하지 않는다고 하면 클라이언트가 이 공격을 감지할 수 있죠 A.org는 NSEC의 첫 번째 기록에 있으니까요 마찬가지로, 공격자가 D.org가 존재한다고 하면 클라이언트가 감지할 수 있죠 두 번째 NSEC 기록에 의하면 D.org는 C.org와 E.org의 사이에 있어야 하는데 두 이름 사이에는 다른 이름이 존재하지 않으니까요 DNSSEC은 믿음의 사슬을 구축하여 기록을 인증합니다 예를 들어 보죠 특정 기기가 DNSSEC 인증을 활용하여 www.example.org를 리졸브하려고 합니다 기기는 쿼리를 보내 IP 주소와 서명, 키를 요구합니다 응답을 통해 신뢰 관계가 형성되는데 IP 주소와 1번 키를 연결하죠 다음은 클라이언트가 부모 영역인 org에 쿼리를 보내 1번 키를 인증하는데 쓰이는 기록을 요청하여 1번 키에서 2번 키가 신뢰 관계를 형성합니다 기기는 루트에 도달할 때까지 이 과정을 회귀적으로 반복합니다 만약 도표처럼 루트 키가 3번이라는 사실을 믿을 수 있다면 IP 주소와 3번 키 사이의 신뢰 관계를 인증할 수 있죠 루트 키의 해시는 항상 기기에 안전하게 보관합니다 DNSSEC에서는 루트 트러스트 앵커라고 하죠 3번 키의 해시가 미리 설치한 앵커와 일치하면 신뢰의 사슬을 안전하게 구축할 수 있습니다 신뢰의 사슬을 이용하여 www.example.org의 IP 주소를 인증할 수 있죠 만약 DNSSEC 인증을 여러분의 앱에서 요구하려면 다음 절차를 따르면 됩니다 여러분의 도메인에 IPv6를 지원하세요 IPv6 전용 환경에서는 IPv4 전용 주소를 합성된 IPv6 주소로 변환합니다 도메인을 서명하면 합성된 주소는 DNSSEC 인증을 통과할 수 없고 DNSSEC을 활성화했을 때 접근할 수 없죠 그래서 여러분의 도메인이 IPv6를 지원해야 합니다 DNS 서비스 제공자가 DNSSEC으로 도메인을 서명하도록 하십시오 앱에 DNSSEC을 사용하더라도 도메인을 서명하지 않으면 이점이 없지만 서명되지 않은 도메인에 인증을 시도하면서 DNS 트래픽이 추가되고 결정 시간이 늘어납니다 필요한 인프라를 구축했다면 앱에 DNSSEC을 채택할 때 필요한 코드를 사용하십시오 만약 NSURLSession 클라이언트라면 URL 요청 시 DNSSEC 인증을 요구할 수 있습니다 예를 들어 보죠 먼저 기본 세션 구성을 만들어야 합니다 다음으로 DNSSEC 인증을 요구해야 하죠 이후에는 구성을 수정한 세션을 만들어야 합니다 이 세션에서 만들어진 모든 URL 요청에 DNSSEC이 활성화되죠 전체 세션에서 DNSSEC을 활성화하기 싫다면 요청 단계에서 할 수도 있습니다 먼저 기본 구성의 세션을 생성할 때 DNSSEC 인증을 비활성화하고 요청 때 활성화하는 거죠 이 세션은 DNSSEC 인증이 완료됐을 때만 시작합니다 Network.framework의 클라이언트라면 연결에 DNSSEC 인증을 요구할 수 있죠 먼저 DNSSEC 인증을 요구하는 매개 변수 객체를 생성하세요 그리고 매개 변수 객체를 포함한 NWConnection을 만드십시오 연결을 시작할 때 DNSSEC 인증을 완료하고 인증된 IP 주소로 연결이 확립됐을 때만 준비 상태로 넘어갑니다 만약 DNSSEC이 활성화되어 있다면 인증된 주소만이 연결 수립에 사용되죠 HTTPS의 경우 오류는 API를 통해 보고됩니다 DNSSEC 인증 실패 시 오류를 반환하지 않죠 인증에 실패한 메시지 수신은 메시지가 없는 것과 같습니다 이 응답을 변경하는 DNS 제공자가 있다면 주소가 인증 확인을 넘어가지 못하여 즉시 버려집니다 DNS 제공자가 응답을 바꾸지 않는 네트워크에 기기가 접속하는 경우 인증이 다시 절차에 따라 진행되며 결과는 자동으로 정상으로 돌아옵니다

DNSSEC이 실패할 수 있는 몇 가지 사례를 들어 보죠 원본 DNS 응답을 위조하면 서명이 맞지 않아 DNSSEC 확인을 넘어가지 못하고 인증 실패를 유발합니다 만약 기기가 미리 설치된 신뢰 앵커에 접근할 수 없으면 신뢰의 사슬도 형성할 수 없습니다 만약 네트워크가 DNS over TCP나 EDNS0처럼 DNSSEC이 요구하는 프로토콜을 지원하지 않으면 DNSSEC 활성화 비트를 가지게 되죠 만약 서명한 도메인이 IPv6를 지원하지 않으면 인터넷 서비스 제공자가 제공하는 합성 IPv6 주소는 인증에 실패할 겁니다 DNSSEC으로 DNS 응답을 인증하는 방법을 알려 드렸는데 암호화하지 않으면 네트워크에 있는 누구나 볼 수 있죠 다음은 DDR을 이용하여 자동으로 DNS 암호화를 사용하는 방법을 얘기하겠습니다

iOS 14와 macOS Big Sur에서 암호화된 DNS를 도입하여 개인 정보를 보호했죠 앱의 NEDNSSettingsManager를 이용하거나 프로필의 DNSSettings를 활용하여 시스템 전반에 수동으로 DNS 암호화를 구성할 수 있습니다 여러분의 앱에 암호화된 DNS 기능을 위해 NWParameters의 PrivacyContext를 사용해도 되죠 더 많은 정보를 원하신다면 'Enable encrypted DNS'를 보십시오 iOS 16과 macOS Ventura에서 최초로 암호화된 DNS를 자동으로 사용할 수 있습니다 '지정 리졸버 발견'으로 알려진 DDR을 네트워크에서 지원하면 DNS 쿼리가 자동으로 TLS나 HTTPS를 사용하죠 암호화된 DNS를 사용하려면 여러분의 기기가 리졸버의 TLS 또는 HTTPS 지원 여부를 알아야 합니다 또한 포트나 URL 경로도 알아야 하죠 DHCP나 라우터 광고 등의 일반적인 메커니즘은 평범한 IP 주소만 제공합니다 DDR은 Apple이 산업 파트너와 함께 IETF에서 만든 새로운 프로토콜이죠 특수한 DNS 쿼리를 이용하여 DNS 클라이언트가 필요한 정보를 알게 합니다 여러분의 기기가 새로운 네트워크에 합류할 때 '_dns.resolver.arpa'를 위한 서비스 바인딩 쿼리를 발행하죠 만약 DNS 서버가 DDR을 지원하면 하나 이상의 구성으로 응답합니다 그리고 기기는 이 정보를 이용하여 지정된 리졸버에 암호화된 연결을 설정하죠 암호화되지 않은 리졸버의 IP 주소가 지정된 리졸버의 TLS 인증서에 포함되어 있다는 걸 확인합니다 이를 통해 암호화되지 않은 리졸버와 암호화된 리졸버가 같은 엔티티에 속했음을 확인하죠 모두 확인되면 기기는 암호화된 DNS를 기본으로 사용합니다

DDR은 한 번에 하나의 네트워크에 적용하죠 여러분의 기기는 현재 네트워크가 지원할 때만 자동으로 암호화된 DNS를 사용합니다 DNS 서버의 IP 주소가 사적인 IP 주소인 경우 DDR이 작동하지 않는다는 것도 유념하십시오 그 이유는 사적인 IP 주소는 소유권을 인증할 수 없어 TLS 인증서에서 허용하지 않기 때문입니다 iOS 16과 macOS Ventura에서는 구성 설정을 위해 암호화된 DNS를 사용할 때 클라이언트 인증을 지정하는 기능을 지원합니다 NEDNSSettingsManager나 DNSSettings 프로필을 사용하세요

클라이언트 인증은 대규모 기업 환경에서 암호화된 DNS를 사용하여 서버에서 접속을 허가하기 전에 클라이언트를 인증하죠 NEDNSSettings의 identityReference 속성으로 클라이언트 인증서를 구성할 수 있습니다 VPN을 위한 클라이언트 인증서와 동일하게 작동하죠 이는 DNS over TLS와 DNS over HTTPS에 모두 적용됩니다 DNS를 보호하기 위한 절차를 확인하죠 도메인을 DNSSEC으로 서명하고 앱에 DNSSEC 인증을 요구하여 IP 주소를 인증하십시오 네트워크에 DDR을 사용하여 클라이언트가 개인 정보 보호를 위해 암호화된 DNS로 자동 전환하게 하세요 더 나은 접속 제어가 필요한 대규모 기업은 클라이언트 인증을 채택하십시오 앞으로도 여러분의 도움으로 더 안전한 DNS 기반을 만들었으면 좋겠습니다 시청해 주셔서 감사합니다