네트워크보안 v.05 _ DNS 공부

 

DNS 계층

▪ 도메인(URL) 네임스페이스는 계층적 트리 구조로 구성됩니다.
– 각 노드는 상위 도메인을 참조할 때 도메인 또는 하위 도메인이라고 합니다.
– 도메인의 루트는 '.'로 표시되는 ROOT라고 합니다.
▪ ROOT 아래에 최상위 도메인(TLD)이 있습니다.
– 예: www.example.com에서 TLD는 .com입니다.
▪ 도메인 계층의 다음 수준은 일반적으로 회사, 학교 등과 같은 특정 엔터티에 할당되는 두 번째 수준 도메인입니다.

.com은 국가별로 존재하고 example아래에 emunl, ns등 더 존재한다

 

DNS ROOT Servers

▪ 루트 영역을 ROOT라고 합니다. -> 13개가 존재하고 복재된 수백개의 루트 서버가 존재함
– 이 영역에는 13개의 권한 있는 네임서버(DNS 루트 서버)가 있습니다.
▪ 모든 TLD에 대한 네임서버 정보 제공(약 2MB)
– https://www.internic.net/domain/root.zone
▪ DNS 쿼리의 시작점입니다.

 

▪ 루트 서버는 인터넷에서 가장 중요한 인프라입니다.

VeriSign, Inc는 위임받은 기관이다.

Top Level Domain (TLD)

▪ 모든 최상위 도메인의 공식 목록은 새로 제안된 최상위 도메인에 대한 승인 프로세스를 감독하는 IANA(Internet Assigned Numbers Authority)에서 관리합니다. -> 도메인을 다루는 곳은 IANA이다..
– 인프라 TLD: .arpa
– 일반 TLD(gTLD): .com, .net
– 후원 TLD(sTLD): TLD 사용을 위해 민간 기관/조직에서 제안 및 후원: .edu, .gov, .mil, .travel, .jobs -> 국방도 존재
– 국가 코드 TLD(ccTLD): .au(호주), .cn(중국), .fr(프랑스)
– 예약된 TLD: .example, .test, .localhost, .invalid

우리나라는 kr/VIC이고 한국 도메인은 다르다

▪ 각 TLD는 IANA에 의해 레지스트리라고 하는 "지정된 관리자"에게 위임됩니다.
– 지정된 관리자의 선택을 통제하는 엄격한 프로토콜과 정책이 있습니다. [Postel, 1994]

▪ .KR에 대한 위임 기록
– (국가 코드 최상위 도메인)
▪ ccTLD 관리자
– 한국인터넷진흥원(KISA) -> TLD 관리 기관

6개의 서버가 kr 관리중 (IPv6도 있음)

 

▪ kr DNS

백업 위치는 서울에 몰려있고 한구 공격 및 해외에서의 속도 때문에 외국에도 위치 해둠

▪ 한국에서는 IP 주소, AS 번호 및 도메인 이름이 한국법에 의해 엄격하게 관리됩니다.

인터넷 주소에 관한 법률(약칭: 인터넷 주소법)
[시행 2022. 7. 12.] [법률 제18736호, 2022. 1. 11., 일부개정]
제1장 총칙 <개정 2009. 6. 9.>
제1조(사업) 이 법률은 인터넷 네트워크에 지원하는 개발 ㆍ이용을 촉진하고 인터넷주소자원의 안정적인 관리 체계를 구축함으로써 인터넷 사용자의 편익을 증진하고 국가 사회의 정보화에 이바지함을 목적으로 한다

▪ 도메인 관리준칙
제1장 총칙 <개정 2011.3.11> -> 악의적인 비슷한 도메인은 안된다...
제1조(기준) 이 준칙은 인터넷 주소에 관 한법률(이하 “법”) 제13조의 규정에 따른다.

 

▪ TLD의 지정 관리자(레지스트리)는 다른 주체(도메인 등록대행자(도메인 이름 등록대행자)라고 함)와 계약을 체결합니다. 
– 잘 알려진 등록 기관: GoDaddy, eNom, Tucows 등
– 국내: 후이즈, 가비아, 매스컴 등
▪ 등록대행자란?

– 인터넷진흥원(KISA)은 이용자에게 합리적 가격 및 다양한 부가서비스를 제공하기 위해 경쟁체계를 도입하였습니다. 이러한 국가 도메인 등록 업무를 진행하는 도메인 업체는 등록대행자이며, 등록대행자는 인터넷주소자원에 관한 법률에 근거하여 한국인터넷진흥원과 등록대행계약을 맺은 업체입니다.

 

▪ 등록대행자란?

– 등록대행자 수수료 및 서비스

파킹은 미리 점유하는것

DNS Zone

▪ DNS는 영역별로 구성됨(도메인 영역)
– 도메인 계층 트리 구조는 도메인 네임스페이스가 구성되는 방식을 설명하지만 도메인 이름 시스템이 정확히 구성되는 방식은 아닙니다.
▪ DNS 영역은 기본적으로 도메인 트리에서 인접한 도메인과 하위 도메인을 그룹화하고 엔터티에 관리 권한을 할당합니다.
– 각 영역은 권한에 의해 관리되지만 도메인에는 권한 정보가 표시되지 않습니다. -> 관리권한을 밖으로 보여주지 않는다
– 도메인은 여러 기관에서 관리할 수 있습니다(즉, 여러 영역으로 분할). -> 해외에서 다양한 dns존이 있어서 속도를 올림

 

▪ 트리 구조는 example.com 도메인 내의 하위 도메인을 나타냅니다.

– 각 나라에 대해 하나씩 여러 DNS 영역이 존재함

– 각 subdomain에 대해 authority 가 누구에게 있는지 기록을 유지함 (기록은 resurce record, RR)

– example.com 을 위한 영역은 mail.example.com과 같은 subdomain에 속하지 않는 DNS record만 포함함

– 회사는 domain과 subdomain을 모두 중앙의 entity 하나를 통해 관리할 수 있으며 이 경우 영역은 하나만 생성됨

     • 다른 국가 간의 종속성 문제로 바람직하지 않을 수 있음

– 각 국가의 지점간 독립성을 유지하기 위해, 회사는 subdomain의 관리를 delegate (위임)하여 각국이 자신의 DNS 정보를 관리하도록 할 수 있음

zone1은 트리구조며 지역에 대한 RR만 소유

Zone vs Domain

▪ DNS 영역에는 도메인에 대한 DNS 데이터의 일부만 포함됩니다.
– 도메인이 하위 도메인으로 분할되지 않은 경우 영역에 도메인에 대한 모든 DNS 데이터가 포함되어 있으므로 영역과 도메인은 동일합니다.
▪ 도메인이 하위 도메인으로 분할된 경우 해당 DNS 데이터는 여전히 동일한 영역에 배치될 수 있으므로 도메인과 영역은 여전히 동일합니다.
– 그러나 하위 도메인은 자체 영역을 가질 수 있습니다.

Authoritative Name Servers

▪ 각 DNS 영역에는 영역에 대한 정보를 게시하는 권한 있는 이름 서버가 하나 이상 있습니다. -> 직접 응답
– DNS 쿼리에 대한 독창적이고 확실한 답변을 제공합니다.
▪ 권한 있는 이름 서버는 마스터 서버(1차) 또는 슬레이브 서버(2차)일 수 있습니다.
– 마스터 서버는 모든 영역 레코드의 마스터 복사본을 저장하는 반면 -> 모두 복제
   슬레이브 서버는 자동 업데이트 메커니즘을 사용하여 마스터 레코드의 동일한 복사본을 유지 관리합니다. - >기록 업데이트 수행

 

DNS Query Process

▪ 애플리케이션은 로컬 머신의 DNS 확인자에게 IP 주소를 요청합니다.
– resolver는 먼저 자신의 데이터에서 IP 주소를 찾으려고 시도하고, 실패하면 로컬 DNS 서버라고 하는 도우미에게 요청을 보냅니다.
• 예를 들어 1.1.1.1(Cloudflare) 또는 8.8.8.8(Google) DNS 서버를 사용할 수 있습니다.
• 더 명확하게, 로컬 대신 기본 DNS 서버가 오히려 정확합니다.

Local Cache에 첫번째로 물어보고 모를경우 ISP가 제공하는 dns 캐쉬인 dns resolver에 물어보고 모르면 dns search에 물어본다.

리커시브 네임서버의 resolver가 마스터 nameserver에게 질문하면 다른 곳의 서버라고 알려준다. 그러면 그 서버인 두번째 nameserver로 갓 질문하고 답장을 받은뒤 사용에게 응답한다. (recursive는 알아서 처리하라는 뜻)

Local DNS Files

▪ /etc/host: 일부 호스트 이름에 대한 IP 주소를 저장합니다. 머신이 로컬 DNS 서버에 접속하기 전에 먼저 이 파일에서 IP 주소를 찾습니다. -> 별명을 짓는다

▪ /etc/resolv.conf: 로컬 DNS 서버의 IP 주소에 대한 정보를 머신의 DNS 해석기에 제공합니다. DHCP에서 제공하는 로컬 DNS 서버의 IP 주소도 여기에 저장됩니다. -> DHCP는 동적할당하면 IP를 제공햊주면서 어디로 갈지 알려주는데 이것을 etc아래에 저장한다.

Local DNS Server and Iterative(반복) Query Process

▪ 반복 프로세스는 ROOT 서버에서 시작됩니다. IP 주소를 모르면 다음 레벨 서버(.NET 서버)의 네임서버 IP 주소를 되돌려주고, 그 다음 답을 제공하는 마지막 레벨 서버(example.net)를 보낸다.

DNS Resolvers

▪ 재귀적 DNS 확인자, 다시
– 이 모든 DNS 서버에서 재귀 쿼리 허용

루트에서 하지않기에 자원 점유를 하지 않는다.

▪ 재귀적 DNS 확인자
– 이 경우 로컬 DNS 서버만 재귀 쿼리를 허용합니다.

– dig(+재귀) www.example.com
▪ 반복 DNS Resolver
– dig +norecurse www.example.com
– dig + trace www.example.com

dns가 하지 않고&nbsp; dns서버 처럼 local이 활동한다 dig활용하면됨

Emulating Local DNS Server (Step 1: Ask ROOT)

A에 주소를 요청했고 ANSWER은 오지 않았다. / authority에서는 nameserver와함께 3개의 도메인을 보냈다. 172800은 ttl으로 살아있는 시간이고 해당 도메인에 대한 ip도 함께 보냈다.

DNS Resolvers

▪ DNS 응답에는 4가지 유형의 섹션이 있습니다.
– 질문 섹션: 네임서버에 대한 질문을 설명합니다.
– 답변 섹션: 질문에 답변한 기록
– 권한 섹션: 권한 있는 네임서버를 가리키는 레코드
– 추가 섹션: 쿼리와 관련된 레코드입니다.
– 위의 예에서 우리는 루트 서버가 답변을 알지 못하기 때문에 답변 섹션이 없음을 알 수 있지만 추가 섹션(A 레코드)에 IP 주소와 함께 권한 있는 네임서버(NS 레코드)에 대해 알려줍니다.

answer은 알고있을때 사용되고 authority는 가라는 장소정ㅂ를 적고 additional은 ip를 적는다.

Steps 2-3: Ask .net & example.net servers

a로 선택해서 다시 물어보니까 답옴

DNS cache

▪ 로컬 DNS 서버는 다른 DNS 서버로부터 정보를 받으면 해당 정보를 캐싱합니다.
▪ 캐시의 각 정보에는 TTL(Time-to-Live) 값이 있으므로 결국 시간이 초과되어 캐시에서 제거됩니다.

 

Set Up DNS Server and Experiment Environment

– 우리는 이 세 개의 가상 머신을 하나의 물리적 머신에서 실행할 것입니다.
– VM 네트워크 설정의 경우 VirtualBox를 사용하는 경우 각 VM의 네트워크 어댑터로 "NAT Network"를 사용하십시오. Vmware를 사용하는 경우 기본 "NAT" 설정이면 충분합니다.

Setup: User Machine

dns 서버를 할당해주지 않으면 안됨. 직접 함

● /etc/resolv.conf 수정 필요
● DHCP가 이 파일을 덮어쓸 수 있으므로 DHCP 클라이언트에게 이 파일에 DNS 서버를 수동으로 설정하도록 지시한 다음 이후에는 절대로 수정하지 않도록 해야 합니다.

 

Setup: Configure Local DNS Server

▪ BIND 9 DNS 서버 설치: sudo apt-get install bind9
▪ BIND 9 서버 구성
– BIND 9는 /etc/bind/named.conf에서 구성을 가져옵니다.
– 파일에 여러 "포함" 항목이 있습니다.
   항목 중 하나는 "/etc/bind/named.conf.options"입니다.
   이 파일에서 DNS 캐시를 덤프할 위치를 지정할 수 있습니다.

flush는 비워라

Configure Local DNS Server: Simplification

▪ DNSSEC 끄기: DNSSEC는 DNS 서버에 대한 스푸핑 공격으로부터 보호하는 데 사용됩니다. 실험을 단순화하려면 이 기능을 꺼야 합니다. 

 

named.conf.options 수정:
▪ 고정 소스 포트 사용(실험을 단순화하기 위해):
named.conf.options 수정

▪ DNS 서버 재시작: sudo service bind9 restart

3333으로 고정

 

Set Up DNS Zones on Local DNS Server

▪ 영역 생성: DNS 서버에 두 개의 영역 항목을 /etc/bind/named.conf에 추가하여 생성합니다.

02168.192.으로 할수잇는 이유는 ip에서 도메인을 가져오는 기능도 있음

Zone File for Forward Lookup (정방향 조회를 위한)

▪ /etc/bind/example.net.db (파일 이름은 named.conf에 지정)

TTL과 NameSever, email, Address가 존재하고 web에 해당하는 응답 ip도 존재

Zone File for Reverse Lookup

▪ /etc/bind/192.168.0.db: (파일명은 named.conf에서 지정)

Testing Our Setup

DNS Attacks

▪ 서비스 거부 공격(DoS) -> url을 알지만 ip를 모를경우 dns를 한다. 이때 dns 다운되면 문제 발생
– 로컬 DNS 서버와 권한 있는 네임서버가 DNS 쿼리에 응답하지 않으면 기계가 IP 주소를 검색할 수 없어 본질적으로 통신이 중단됩니다.
▪ DNS 스푸핑 공격: -> 피싱 사이트로 준다. 이때 도메인은 다 똑같음(은행을 훔쳐서)
– 주요 목표: 피해자에게 사기성 IP 주소를 제공하여 의도와 다른 시스템과 통신하도록 속입니다.
– 예: 사용자의 의도가 은행 웹사이트를 방문하여 온라인 뱅킹을 하려는 것이지만 DNS 프로세스를 통해 얻은 IP 주소가 공격자의 시스템인 경우 사용자 시스템은 공격자의 웹 서버와 통신합니다.

 

Overview of the Attack Surfaces

1번에서 공격 할경우, 2번에서 패킷을 교환할때 위조로 줄경우, 3번에서 대신 응답을 할경우, 4번에서 거짓된 응답으로 직접 공격할 경우

DNS Attacks on Compromised Machines (쏜상된 시스템에 대한 dns 공격)

▪ 공격자가 머신에 대한 루트 권한을 얻은 경우,
– /etc/resolv.conf 수정: 악성 DNS 서버를 머신의 로컬 DNS 서버로 사용하고 전체 DNS 프로세스를 제어할 수 있습니다.

 -> 임의로 dns 서버를 변경해서 자신 것으로 둔다. 
– /etc/hosts 수정: 파일에 새 레코드를 추가하여 선택한 일부 도메인에 대한 IP 주소를 제공합니다. 예를 들어, 공격자는 www.bank32.com의 IP 주소를 수정하여 공격자의 시스템으로 이어질 수 있습니다.

 -> 은행에 대한 ip를 공격자 ip로 변경

 

<Local DNS Cache Poisoning Attack> -> 내부에서 공격

attacker와 user가 같은 네트워크다

Spoofing DNS Replies (from LAN)

▪ 다음 기준을 충족하는 경우 사용자의 컴퓨터에서 가짜 DNS 응답을 수락합니다.

   -> 가짜로 설정해서 dns 서버나 user 한테 보내도록한다.
1. 소스 IP 주소는 DNS 서버의 IP 주소와 일치해야 합니다.
2. 목적지 IP 주소는 사용자 기기의 IP 주소와 일치해야 합니다.
3. 소스 포트 번호(UDP 포트)는 DNS 요청이 전송된 포트 번호(일반적으로 포트 53)와 일치해야 합니다.
4. 대상 포트 번호는 DNS 요청을 보낸 포트 번호와 일치해야 합니다.
5. UDP 체크섬을 올바르게 계산해야 합니다.
6. 트랜잭션 ID는 DNS 요청의 트랜잭션 ID와 일치해야 합니다.
7. 응답의 질문 섹션에 있는 도메인 이름은 요청의 질문 섹션에 있는 도메인 이름과 일치해야 합니다.
8. 답변 섹션의 도메인 이름은 답변 섹션의 도메인 이름과 일치해야 합니다.
DNS 요청의 질문 섹션.
9. 사용자의 컴퓨터는 적법한 DNS 응답을 받기 전에 공격자의 DNS 응답을 받아야 합니다.

    -> 먼저 로컬dns가 보내면 ttl 때문에 attacker의 답을 업데이트 하지 않는다.

 

Local DNS Cache Poisoning Attack

▪ 목표: 로컬 DNS 서버에서 쿼리를 본 후 DNS 응답 위조

- scapy : 패킷 변경 모듈

IPpkt : dst를 패킷으로 받은 ip 출발지로, src를 패킷으로 받은 ip 도착지로 바꾼다.

UDPpkt : dport에 기존 UDP를 넣고 sport는 53으로 한다.

answer section과 nssection이 있는데 답장에 type를 a로 하고 rdata에 ip를 수정했다. 그리고 ns section에는 기존 id, qd를 넣고 an와 ns에 위에 정의한 것들을 넣었다. 이렇게 만든 ip와 udp, dns 패킷 헤더를 만들어 spoofpkt을 만들어 보낸다. 이때 sniff함수를 통해 호스트의 피해자 ip와 도착 포트인 dns 53일 경우 위 패킷을 보내게 한다.

위에 거에 대한 해당 답변을 보면 ttl도 변경되고 답장에 대한 ip도 변경되어 해당 주소도 변경되었다

Inspect the Cache

▪ “sudo rndc dumpdb –cache”를 실행하여 “/var/cache/bind/dump.db”의 내용을 확인한다.
▪ 공격을 수행하기 전에 "sudo rndc flush"를 사용하여 캐시를 정리합니다.

공격 당한거를 볼수있다.

<Remote DNS Cache Poisoning Attack> -> 외부에서 공격

▪ 과제: 로컬 DNS 서버와 동일한 네트워크에 있지 않은 원격 공격자의 경우, 쿼리 패킷에서 사용하는 두 개의 난수를 추측해야 하기 때문에 스푸핑 응답이 훨씬 더 어렵습니다.
– 소스 포트 번호(16비트 난수)
– 트랜잭션 ID(16비트 난수)
▪ 캐시 효과 없이,
– 공격자가 1초에 1,000개의 스푸핑 쿼리를 보낼 수 있는 경우 2^32번 시도하는 데 50일이 걸립니다.
– 공격자가 수천 개의 호스트로 구성된 봇넷을 사용하여 공격을 시작하는 경우 1.2시간 밖에 걸리지 않습니다.
▪ 캐시 효과: 한 번의 시도가 실패하면 실제 응답이 로컬 DNS 서버에 의해 캐시됩니다. 공격자는 다음 시도를 위해 캐시가 시간 초과될 때까지 기다려야 합니다.

 

The Kaminsky Attack

▪ 캐시 효과에 대해 걱정하지 않고 어떻게 답장을 계속 위조할 수 있습니까?
▪ Kaminsky의 아이디어:
• 매번 다른 질문을 하기 때문에 캐싱은 문제가 되지 않으며 로컬 DNS 서버는 매번 새로운 쿼리를 보냅니다.
• 권한 섹션에서 위조된 답변 제공

The Kaminsky Attack: A Sample Response

Spoofing Replies: IP and UDP headers

Spoofing Replies: DNS Header and Payload

<Attacks from Malicious DNS Server>

▪ 사용자가 공격자32.com과 같은 웹사이트를 방문하면 DNS 쿼리는 결국 공격자32.com 도메인의 권한 있는 네임서버에 도달하게 됩니다.
▪ 응답의 응답 섹션에 IP 주소를 제공하는 것 외에도 DNS 서버는 권한 및 추가 섹션에 정보를 제공할 수도 있습니다.
▪ 공격자는 이 섹션을 사용하여 사기성 정보를 제공할 수 있습니다.

Fake Data in the Additional Section

그것들은 폐기될 것입니다: out of zone. 폐기하지 않으면 보안 문제가 발생합니다.

Fake Data in the Authority Section

Reply Forgery Attacks from Malicious DNS ServersD

▪ 실험을 통해 BIND 네임서버가 추가 섹션의 데이터를 캐싱했지만 추가 섹션에서 얻은 IP 주소를 신뢰하지 않는 것을 알 수 있습니다. 이는 간접 정보이기 때문입니다.

이것은 허용되지 않습니다(영역 외부). 로컬 DNS 서버는 이 호스트 이름의 IP 주소를 자체적으로 가져옵니다.

Reply Forgery in Reverse DNS Lookup

▪ 역방향 조회에서 DNS 쿼리는 주어진 IP 주소에 대한 호스트 이름을 찾으려고 시도합니다.
– 역방향 DNS 조회 211.106.28.244는 security.swu.ac.kr을 제공합니다.
▪ 불행히도 악성 DNS 서버가 거짓말을 하는 것을 막는 것은 없습니다.
– 따라서 www.example에 응답하는 대신. net에서 악성 DNS 서버는 192.168.0.101이 www.facebook.com에 속한다고 말할 수 있습니다.

 

Reply Forgery Attacks from Malicious DNS Servers

▪ 질문: 역 DNS 조회에서 얻은 호스트 이름을 액세스 제어의 기반으로 사용할 수 있습니까?
– 예: 어떤 경우에는 syr.edu의 패킷이 특정 서비스에 액세스할 수 있습니다.
▪ 이 질문에 답하려면 역방향 조회를 수행하는 방법을 알아야 합니다.
▪ 예:
– IP 주소 128.230.171.184가 주어지면 DNS 해석기는 "가짜 이름" 184.171.230.128.in-addr.arpa를 구성한 다음 반복 프로세스를 통해 쿼리를 보냅니다.
– dig 명령에서 @ 옵션을 사용하여 전체 역방향 조회 프로세스를 에뮬레이트합니다.

 

Reverse DNS Lookup

▪ 1단계: 루트 서버에 요청합니다.
in-addr.arpa 영역에 대한 네임서버를 얻습니다.

▪ 2단계: in addr.arpa 영역의 네임서버에 요청합니다. 128.in-addr.arpa 영역에 대한 네임서버를 얻습니다.

Reply Forgery Attacks from Malicious DNS Servers

▪ 3단계: 128.in-appr.arpa 영역의 네임서버에 요청합니다. 203.128.in-addr.arpa 영역에 대한 네임서버를 얻습니다.

▪ 4단계: 230.128.in-appr.arpa 영역의 네임서버에 요청합니다. 우리는 최종 결과를 얻습니다

Review Our Question

▪ 질문: 역 DNS 조회에서 얻은 호스트 이름을 액세스 제어의 기반으로 사용할 수 있습니까?
▪ 답:
– 패킷이 공격자로부터 온 경우 역방향 DNS 조회는 공격자의 네임서버로 돌아갑니다.
– 공격자는 원하는 호스트 이름으로 응답할 수 있습니다.

 

Protection Against DNS Cache Poisoning Attacks

▪ DNSSEC
– DNSSEC는 DNS 데이터에 대한 인증 및 무결성 검사를 제공하는 것을 목표로 하는 DNS 확장 세트입니다.
– DNSSEC를 사용하면 DNSSEC 보호 영역의 모든 응답이 디지털 서명됩니다.
– DNS resolver는 디지털 서명을 확인하여 정보의 진위 여부를 확인할 수 있습니다.
– DNS 캐시 중독은 서명 확인에 실패하므로 가짜 데이터가 감지되므로 이 메커니즘에 의해 패배합니다.

 

<Protecting Against DNS Cache Poisoning Attacks>

▪ DS: 위임 서명자

Protection Using TLS/SSL

TLS/SSL(전송 계층 보안) 프로토콜은 캐시 중독 공격에 대한 솔루션을 제공합니다. ▪ DNS 프로토콜을 사용하여 도메인 이름(www.example.net)에 대한 IP 주소를 얻은 후 컴퓨터는 IP 주소의 소유자(서버)에게 www.example.net임을 증명하도록 요청합니다. ▪ 서버는 신뢰할 수 있는 엔터티가 서명한 공개 키 인증서를 제시해야 하며 www.example.net과 연결된 해당 개인 키를 알고 있음을 보여야 합니다(즉, 인증서 소유자). ▪ HTTPS는 TLS/SSL 위에 구축됩니다. DNS 캐시 중독 공격을 물리칩니다. 

DNSSEC versus TLS/SSL

▪ DNSSEC와 TLS/SSL은 모두 공개 키 기술을 기반으로 하지만 신뢰 체인이 다릅니다. – DNSSEC는 DNS 영역 계층을 사용하여 신뢰 체인을 제공하므로 상위 영역의 네임서버는 하위 영역의 네임서버를 보증합니다. – TLS/SSL은 다른 컴퓨터를 보증하는 CA(인증 기관)가 포함된 PKI(공개 키 인프라)에 의존합니다.

 

DNS Rebinding Attack

▪ SOP(Same Origin Policy): 웹 브라우저는 AJax(Async. Javascript & XML)에 샌드박스 정책을 적용하여 웹 페이지 내의 Ajax 코드만 페이지가 시작된 동일한 서버와 상호 작용할 수 있도록 합니다.

▪ 첫 번째 DNS 쿼리의 경우 TTL을 가능한 한 작게 설정합니다(예: 2초).

▪ 리바인딩 방어 – 브라우저 완화: 세션 중간에 IP 전환 거부 • 프록시, VPN, CDN 등과 제대로 상호 작용하지 않습니다. • 어떤 브라우저에서도 일관되게 구현되지 않음 – 서버 방어 • 1. 인식할 수 없는 도메인에 대한 호스트 헤더 확인 • 2. IP 주소 이외의 다른 것으로 사용자 인증

 

<Denial of Services Attacks on DNS>

 

Denial of Service Attacks on Root Servers

루트 및 TLD 서버에 대한 공격: 루트 네임서버: 공격자가 루트 영역의 서버를 다운시킬 수 있다면 전체 인터넷을 다운시킬 수 있습니다. 그러나 루트 서버를 공격하는 것은 어렵습니다. ▪ 루트 네임서버는 고도로 분산되어 있습니다. 다수의 이중화로 구성된 13(A,B….M) 루트 네임서버(서버 팜)가 있습니다. 신뢰할 수 있는 서비스를 제공하는 컴퓨터. ▪ TLD의 네임서버는 일반적으로 로컬 DNS 서버에 캐시되므로 캐시가 만료될 때까지(48시간) 루트 서버를 쿼리할 필요가 없습니다. 루트 서버에 대한 공격은 상당한 효과를 보기 위해 오래 지속되어야 합니다.

 

Denial of Service Attacks on TLD Servers

▪ TLD의 네임서버는 공격하기 쉽습니다. gov, com, net 등과 같은 TLD는 DOS 공격에 대해 상당히 탄력적인 인프라를 갖추고 있습니다. 그러나 국가 코드 TLD와 같은 특정 모호한 TLD에는 인프라가 충분하지 않습니다. 이로 인해 공격자는 대상 국가의 인터넷을 중단시킬 수 있습니다.

 

Attacks on Nameservers of a Particular Domain

▪ UltraDNS: Amazon, Walmart, Expedia와 같은 많은 주요 전자 상거래 회사를 위한 DNS 공급자. 2004년에 이 공급자에 대한 DOS가 시작되어 한 시간 동안 중단되었습니다.

Attacks on Nameservers of a Particular Domain

DNSPod: 2009년에 중국 도메인 서비스 제공업체의 여러 DNS 서버가 DDoS 공격을 받았습니다. ▪ 공격은 중국에서 널리 알려진 동영상 스트리밍 사이트인 Baofeng.com을 대상으로 한 것입니다. ▪ 공격 다음날 다른 서버에서 이전에 캐시된 DNS 응답이 시간 초과되었을 때 사용자 컴퓨터의 Baofeng 미디어 플레이어는 공격으로 인해 서버의 IP 주소를 찾을 수 없었습니다. ▪ 미디어 플레이어 소프트웨어의 버그로 인해 기다리지 않고 계속해서 더 빠른 속도로 DNS 쿼리를 보냈습니다. 엄청난 수의 DNS 쿼리로 인해 차이나 텔레콤(ISP) 네트워크가 범람하고 혼잡했습니다. 그것은 20개 지방에 영향을 미쳤으며 중국에서 최악의 인터넷 사고로 묘사됩니다.

▪ Dyn 네트워크: 2016년 CNN, BBC, HBO, PayPal 등과 같은 회사의 주요 DNS 서비스 제공업체를 대상으로 다수의 DDoS 공격이 시작되었습니다. 공격은 IP 카메라, 베이비와 같은 다양한 IoT 장치로 구성된 봇넷을 통해 시작된 것으로 추정됩니다. 모니터 등의 주요 인터넷 서비스를 사용할 수 없습니다.

 

summary

▪ DNS 작동 방식

▪ DNS에 대한 스푸핑 공격

– 로컬 DNS 캐시 중독 공격

– 원격 DNS 캐시 중독 공격

– 위조 공격에 응답

▪ DNS 스푸핑 공격 방어

– DNSSEC

– TLS/SSL

▪ DNS에 대한 서비스 거부

 

출처 : Hoorin Park Assistant Professor, Department of Information Security, Seoul Women’s University