* DNS(Domain Name System)
- DNS는 도메인 주소를 IP 주소로 해석해주는 역할을 하는 서버이다.
- IP 주소는 10.30.100.45와 같은 숫자로 구성되어 있어서 일반 사용자들이 쉽게 기억하기 힘들기 때문에 사용자들이 좀 더 쉽게 사용할 수 있도록 DNS를 이용하여 숫자로 구성된 주소를 도메인 주소로 연결시켜 주도록 하는 것이다.
* 도메인
- IP 주소를 알기 쉽게 영문으로 표현한 것
- http://www.naver.com/index.html -> 이거는 URL이라고 부른다.
- www.naver.com -> 이거는 FQDN이라고 한다.
- naver.com -> 이거는 도메인이라고 부른다.
- www -> 이거는 호스트명이라고 부른다.
* 도메인 체계
- 도메인은 "." 또는 루트(root)라 불리는 도메인 이하에 역 트리구조로 구성이 되어 있다.
- 루트 도메인 아래의 단계를 1단계 도메인 또는 최상위 도메인(TLD, Top Level Domain)이라고 부르며, 그다음 단계를 2단계(SLD, Second Level Domain) 도메인이라고 부른다.
① 일반 최상위 도메인(gTLD) : 'com(회사)', 'net(네트워크 관련기관)', 'org(비영리기관)', 'biz(사업)' 등
② 국가 최상위 도메인(ccTLD) : 인터넷상으로 국가를 나타내는 도메인으로 kr(대한민국), jp(일본), cn(중국), us(미국) 등 영문으로 구성된 영문 국가 도메인이 있다.
* Root DNS
- 루트 네임 서버는 DNS의 최상단으로 시작점의 역할을 한다. 이 서버는 "루트 영역 파일"(Root zone file)을 인터넷상의 다른 DNS 서버와 클라이언트가 사용할 수 있도록 한다. 루트 영역 파일은 DNS 최상위 도메인(.com, .org, .ca, .ng, .hk, .uk 등)을 위한 서버의 위치를 기록하고 있다.
- 전 세계에 13개의 Root DNS 서버가 있고 13개의 Root DNS 서버중에 10개가 IPv6 방식의 레코드 셋을 완벽히 지원한다.
- 루트 네임 서버는 a.root-server.net, b.root-server.net ..., m.root-server.net과 과 같이 알파벳순으로 이름이 지어졌다.
- 각 나라마다 Root DNS Mirror Server가 존재하는데 우리나라의 대표적인 미러 서버로는 KISA가 있다.
* Zone 파일
- 도메인을 소유한 특정 조직의 DNS 서버는 해당 도메인에 대한 Zone 파일 (영역 파일)을 갖는다.
- 해당 Zone 파일에는 Record라고 불리는 도메인 내부 정보가 존재하고, 해당 정보 조회를 허용하여 외부 Client에게 정보를 제공할 수 있다.
* DNS 레코드(Record)
- SOA(Start of Authority) : DNS zone의 기본 이름 식별
- A(Host Record) : 호스트 이름이 정의된 주 영역
- AAAA(IPv6 DNS Record) : IPv6 주소를 기준으로 하는 레코드
- CNAME(Aliad Record) : 별칭, 다른 도메인 주소를 지정한 주소로 연결할 수 있게끔 해줌
- MX(Mail Exchange Record) : 도메인에서 서비스 이용이 가능한지 식별
- SRV(Service Resources) : 도메인에서 서비스 이용이 가능한지 식별
- NS(Name Server) : 도메인의 모든 네임서버 식별 (DNS Response에 사용함)
- DDNS(Dynamic DNS) : 실시간으로 DNS를 갱신하는 방식
- PTR(Reverse DNS) : 역방향 레코드
(+이 외에도 아래처럼 여러 가지 레코드가 존재한다.)
* SOA(Start Of Authority)
- Serial(일련번호) : 2차 DNS를 운영할 경우 Serial number를 통해 2차 DNS 서버가 1차 DNS의 Zone 파일 정보가 갱신되었는지 알 수 있다. 이는 Zone 파일이 수정될 때 Serial Number가 증가하여 1차 DNS의 Serial number가 2차 DNS Serial number보다 클 경우, 2차 DNS 서버는 1차 DNS 서버로부터 Zone 파일을 재전송받아 업데이트하게 된다.
- Refresh(새로 고침 간격) : 2차 DNS 서버가 1차 DNS 서버의 정보로 갱신하기 위하여 Refresh에 설정된 주기(초 단위)로 Zone 파일이 업데이트 되었는지 체크한다.
- Retry(다시시도 간격) : 2차 DNS 서버가 Refresh에 설정된 시간에 1차 DNS 서버에 연결이 되지 않을 경우 재접속을 시도할 시간을 설정한다.
- Expire(다음 날짜 이후에 만료) : 2차 DNS 서버가 Expire에 설정된 시간 동안 1차 DNS 서버에 접속할 수 없을 때 2차 DNS 서버는 해당 Zone 파일에 대해 응답하지 않는다. 즉, Expire에 설정된 시간 동안만 DNS 정보를 신임하게 된다.
- Default TTL(최소 TTL) : 다른 DNS 서버가 이 도메인에 대한 캐시를 가지고 있을 경우, 얼마 동안 이 정보를 유지할지를 설정하는 것이다. 즉, Hostway의 DNS를 사용하는 사용자가 hajin.net에 대해 질의를 하면 hostway dns는 hajin.net의 IP 주소를 알려주고 hajin.net에 대한 정보를 Default TTL 값 동안 자신도 저장해 놓았다가 또 다른 hostway dns를 사용하는 사용하는 사용자가 hajin.net을 질의하면 저장해 놓은 값으로 응답해 주게 된다. 그러므로 업데이트가 자주 되는 DNS의 경우 TTL 값을 줄여 놓으면 보다 빨리 업데이트된 DNS 정보를 얻을 수 있다.
* 동적 업데이트 (Dynamic Update)
- DNS에서 호스트 레코드(www) 만큼 중요한 것은 없다. 대부분 이름 풀이는 호스트 레코드로 일어난다고 해도 과언이 아니다. 그런데 이 호스트 레코드가 자꾸 바뀐다면? 즉, 어떤 컴퓨터의 IP 주소가 수시로 변경된다면? 관리자는 변경될 때마다 DNS 관리 도구를 열어서 해당 호스트 레코드의 IP 주소를 바꿔 줘야 한다.
- 만약 그 컴퓨터가 DHCP 클라이언트라면 IP 주소가 수시로 바뀔 수 있다. 그래서 윈도 2000부터 동적 업데이트 기능을 지원한다.
- 동적 업데이트는 DNS 클라이언트가 DNS 서버에 자신의 레코드를 등록하거나, 수정하는 기능을 말한다. DNS 클라이언트는 자신의 IP 주소 정보가 변경되거나 컴퓨터 이름이 변경되면 DNS의 영역에 자신의 호스트 레코드를 등록하거나 수정한다.
* 리졸버(Resolver)
- 웹 브라우저와 같은 DNS 클라이언트의 요청을 네임 서버로 전달하고 네임 서버로부터 정보(도메인 이름과 IP 주소)를 받아 클라이언트에게 제공하는 기능을 수행한다.
- 하나의 네임 서버에게 DNS 요청을 전달하고 해당 서버에 정보가 없으면 다른 네임 서버에게 요청을 보내 정보를 받아온다.
- 수 많은 네임 서버에 접근하여 사용자로부터 받은 도메인의 IP 정보를 조회하는 기능을 수행할 수 있어야 한다.
* DNS 쿼리(Query)
- 쿼리는 Recursive(재귀) or Iterative(반복)으로 구분
- DNS 클라이언트와 서버는 서로 쿼리를 교환한다.
(+ 네임 스페이스를 위한 권한이 있는 DNS 서버와 권한이 없는 DNS 서버로 구분)
- 네임 스페이스를 위한 권한이 있는 DNS 서버 : 요청된 IP 주소를 응답
- 네임 스페이스를 위한 권한이 없는 DNS 서버 : 캐시 정보 확인, 전달자 이동, 루트 힌트(DNS 루트 서버의 IP주소를 포함하고 있는 파일)를 이용
* hosts 파일
- 초기에는 IP 주소를 이름으로 변환하기 위해 인터넷에 연결된 모든 컴퓨터에 FTP를 통해 전송된 hosts.txt 파일을 사용하였다. 하지만 호스트의 수가 증가하면서 한 명의 관리자가 모든 호스트를 단일 파일로 관리하는 것이 불가능해졌다. 이 문제를 해결하기 위해 DNS가 나왔다.
- hosts 파일은 호스트 이름과 이에 대응하는 IP 주소가 저장되어 있는 파일로 인터넷 접속 시 컴퓨터가 가장 먼저 확인하는 파일이다.
* DNS 동작 과정 (★중요)
① PC 브라우저에서 www.naver.com을 입력한다. 그러면 PC는 자신의 캐시목록(ipconfig /displaydns로 확인 가능)과 hosts파일을 확인한 후 미리 설정되어 있는 DNS(단말에 설정되어 있는 이 DNS를 Local DNS라 부름)에게 www.naver.com이라는 hostanme에 대한 IP 주소를 물어본다.
② Local DNS에는 www.naver.com에 대한 IP주소가 있을 수도 없을 수도 있다. 만약 있다면 바로 PC에게 IP주소를 주고 끝나겠지만 없다고 가정하겠다.
③ Local DNS는 이제 www.naver.com에 대한 IP주소를 찾아내기 위해 다른 DNS 서버들과 통신(DNS 메시지)을 시작한다. 먼저 Root DNS 서버에게 "너 혹시 www.naver.com에 대한 IP주소 아니?"라고 물어본다. 이를 위해 각 Local DNS 서버에는 Root DNS 서버의 정보(루트 힌트)가 미리 설정되어 있어야 한다.
④ Root DNS 서버는 www.naver.com의 IP 주소를 모른다. 그래서 Local DNS에게 "난 www.naver.com에 대한 IP 주소 몰라. 나 말고 내가 알려주는 다른 DNS 서버(최상위 도메인 서버)에게 물어봐~"라고 응답하며 최상위 도메인 서버의 NS레코드를 알려준다.
⑤ 이제 Local DNS 서버는 COM 도메인을 관리하는 DNS 서버에게 다시 "너 혹시 www.naver.com에 대한 IP주소 아니?"라고 물어본다.
⑥ 역시 COM 도메인을 관리하는 DNS 서버에도 해당 정보가 없다. 그래서 이 DNS 서버는 Local DNS에게 "난 www.naver.com에 대한 IP 주소 몰라. 나 말고 내가 알려주는 다른 DNS 서버(naver.com 도메인 서버)에게 물어봐~"라고 하며 naver.com 도메인 서버의 NS레코드를 알려준다.
⑦ 이제 Local DNS 서버는 naver.com 도메인을 관리하는 DNS 서버에게 다시 "너 혹시 www.naver.com에 대한 IP 주소 있니?"라고 물어본다.
⑧ naver.com을 관리하는 DNS 서버에는 www.naver.com 호스트네임에 대한 IP 주소가 있다. 그래서 Local DNS에게 "응! www.naver.com에 대한 IP 주소는 222.122.195.6이야~"라고 응답을 해준다. (마지막에는 A레코드로 응답함)
⑨ 이를 수신한 Local DNS는 www.naver.com에 대한 IP 주소를 캐싱하고(이후 다른 PC가 물어보면 바로 응답을 줄 수 있도록)그 IP 주소 정보를 요청한 PC에게 전달해준다.
+ 이와 같이 Local DNS 서버가 여러 DNS 서버를 차례대로 물어봐서 그 답을 찾는 과정을 Recursive Query라고 한다.
* 캐싱(Caching)
- 여러 단계의 과정을 거치지만 초기 질의를 받은 네임서버엔 이미 해당 도메인에 대한 데이터베이스가 저장됨
* 역방향, 정방향
- DNS 정방향 : 도메인 이름으로 IP 주소를 찾아줌 (ex. google.com => 172.217.174.110)
- DNS 역방향 : IP 주소로 도메인 이름을 찾아줌 (ex. 172.217.174.110 => google.com)
- nslookup에서 확인 가능(역방향 설정 안하면 unknow이라고 뜸)
* 루트 힌트(Root Hints)
- 나에게 없는 영역에 대한 질의가 들어왔을 때 루트 힌트로 지정한 DNS Server에게 질의를 넘긴다.
- 루트 힌트에는 Root DNS 서버들의 IP 주소가 포함되어 있다.
* 전달자
- 다음으로 질의할 DNS 서버를 정해주는 것
* 조건부 전달자
- Local DNS Server가 모르는 DNS 쿼리에 대해 문의하는 것이 아니라 특정 조건에 대한 DNS 정보만 질의하는 것 (도메인명 ex. google.com = 조건)
- 사용 이유?
① 자주 사용하는 사이트의 DNS를 따로 빼서 부하 감소를 위해 사용 - 별 차이 없음
② 보안적인 이유 - 보안이 필요한 특정 IP에 대한 DNS를 따로 빼둠
* DNS 영역 위임
- 하위 도메인 권한을 다른 영역으로 위임.
- 관리가 간편하다.
- DNS 영역 위임 절차
① DNS 관리도구에서 새 위임 명령으로 자식 도메인 생성
② 위임된 도메인의 이름서버이름 서버 이름은 반드시 부모 도메인의 이름 서버에 의해 풀의 되는 서버이어야 함 (부모 도메인의 영역에 등록된 서버라면 무방)
③ 위임 명령으로 지정된 물리적 DNS 서버에서 정방향조회 영역 작성 후 리소스 등록
④ 클라이언트의 TCP/IP 구성변경 (위임대상 DNS 서버를 바라보도록)
* DNS 영역 전송
- DNS 영역 전송은 DNS 서버 간의 신뢰할 수 있는 DNS 영역 데이터의 동기화
* DNSSEC(DNS Security Extentions)
- DNSSEC은 도메인 네임 시스템(DNS)이 갖고 있는 보안 취약점을 극복하기 위한 DNS 확장 표준 프로토콜이다.
- DNS 프로토콜은 데이터 위-변조 침해 공격에 취약하다는 문제점이 있다. DNS 데이터의 위-변조 침해 공격은 진짜 사이트와 동일한 모습으로 위장하고 있는 가짜 사이트로 사용자들이 접속하게끔 유도할 수 있다.
- 자신이 접속하고 있는 사이트가 가짜 사이트인 줄 모르는 사용자는 자신의 로그인 계정과 암호, 그리고 신용카드 비밀번호와 같은 개인정보를 가짜 사이트의 웹 페이지에서 입력하게 되어, 개인 정보가 악의를 가진 공격자에게 노출되는 사고가 발생할 수 있다.
* DNS 데이터 위-변조 공격(DNS 캐시 포이즈닝)
- DNS 데이터를 위-변조하는 공격 형태를 "DNS 캐시 포이즈닝"이라 하며, 혹은 파밍(Pharming)이라고도 한다.
온라인 뱅킹 서비스를 이용하기 위해 은행 웹 사이트 www.a-bank.co.kr에 접속하는 경우를 예로 들어보자.
위에 그림과 같이, www.a-bank.co.kr의 진짜 주소는 202.31.188.5이지만, 악의의 공격자는 이 www.a-bank.co.kr의 주소가 192.0.2.100인 것처럼 위변조 할 수 있다.
사용자는 PC에서 웹 브라우저의 주소창에 "http://www.a-bank.co.kr"을 입력하고 접속을 시도한다. 웹 브라우저는 접속 사이트의 IP 주소를 알아야 해당 서버에 접근할 수 있으므로, 도메인 네임 www.a-bank.co.kr의 IP 주소를 파악하는 절차를 먼저 수행한다. (도메인 주소와 연결된 IP 확인)
그림에서와 같이, PC 호스트 시스템은 리커시브(재귀) 네임서버에 대해 www.a-bank.co.kr에 대한 IP주소를 질의한다. PC 호스트는 DNS 응답 패킷에서 www.a-bank.co.kr 사이트의 웹 접속에 필요한 IP 주소를 얻게 된다.
리커시브 네임서버는 PC 호스트로부터의 질의에 응답할 때, DNS 데이터를 임시로 저장하는 캐시에서 해당 데이터로서 응답한다. 여기서 문제는 이 캐시에 저장된 DNS 데이터가 위-변조된 데이터일 경우에 발생한다.
www.a-bank.co.kr 은행사이트의 진짜 IP 주소는 201.31.188.5인데, 누군가가 위-변조된 DNS 응답 메시지로 리커시브 네임서버를 속여 www.a-bank.co.kr의 IP주소가 192.0.2.100인 것으로 믿게 하여 이를 캐시에 저장하는 경우가 이에 해당한다.
이렇게 되면 이 리커시브 네임서버를 사용하고 있는 모든 PC 호스트는 www.a-bank.co.kr 사이트에 접속을 하려 할 때, 201.31.188.5 주소의 서버가 아니라 192.0.2.100의 서버에 접속하게 된다.
이 과정은 PC 호스트와 네임서버 간에 일어나는 절차에 의한 것이므로, 사용자는 자신이 가짜 웹 사이트에 접속하고 있다는 것을 알 수가 없다.
특히 이런 경우 192.0.2.100의 가짜 웹 사이트는 www.a-bank.co.kr 사이트와 동일한 모습으로 위장된 웹 사이트이게 된다. 공격자가 사용자의 개인정보를 입력받기 위해서 미리 준비한 위장된 웹 사이트이다.
사용자는 이 접속된 사이트가 www.a-bank.co.kr의 은행 사이트인 것으로 착각하고 아무런 의심 없이 자신의 로그인 정보와 계좌 비밀번호를 입력하게 된다.
악의의 공격자는 사용자가 입력하는 개인정보를 저장하여 금융범죄에 사용하거나 수집된 정보를 다른 악의를 가진 이에게 판매할 수 있다.
이러한 형태의 공격을 "DNS 캐시 포이즈닝"이라고 하며 리커시브 네임서버가 관리하는 캐시에 위-변조된 데이터를 저장하도록 유도하기 위한 공격 형태이다.
* DNSSEC의 필요성 (위에 공격 실제 사례)
- 인터넷 최상위 도메인을 관리하던 InterNIC 사이트에 접속하는 웹 트래픽이 InterNIC 사이트가 아닌 Alternic 사이트에 접속되는 일이 미국에서 발생했다. 이는 Eugene Kashpureff가 도메인 네임 시스템의 데이터를 위-변조하여 리커시브 네임서버의 캐시에 반영토록 하는 조작에 의해 발생하였다. 그는 Alternic의 설립자로서 당시 인터넷 최상위 도메인을 독점 관리하고 있던 InterNIC에 대한 반발을 표시하기 위해 그러한 공격을 시도했다고 알려지고 있다.
- 사용자가 충분한 주의를 기울이면 피할 수 있는 피싱과는 달리, 이러한 DNS 캐시 포이즈닝은 사용자가 정상적인 도메인 네임을 입력하여 서비스 접속을 시도하더라도 이미 네임서버 캐시에 저장된 위-변조된 주소 데이터가 응답되어 오기 때문에 사용자로서는 이에 대응하거나 이를 방지할 수단이 없다. 따라서 이러한 공격에 대해서는 네임서버 시스템 관리자에 의한 DNS 캐시 포이즈닝 방지를 위한 철저한 저한 감시와 관리가 요구된다.
* DNSSEC이 뭔데 공격들을 막냐?
- DNSSEC은 공개키 암호화방식의 전자서명 메커니즘(인증서)을 DNS 체계에 도입하여 적용하는 방법으로써 DNS의 데이터 위-변조 취약점을 보강하여 보안 안정성을 대폭 강화한다.
'IT Network System > Network' 카테고리의 다른 글
| OSI 7 Layer (0) | 2021.01.19 |
|---|---|
| Cloud (0) | 2021.01.19 |
| DHCP (0) | 2021.01.17 |
| Proxy (0) | 2021.01.14 |
| 인증 기관(CA) (0) | 2020.12.17 |
댓글