DHCP와 DNS 보안

호스트 설정 프로토콜 종류

- RARP

인터넷 초기에는 RARP 프로토콜이 부팅된 컴퓨터의 IP 주소를 제공하기 위해 만들어졌다. ARP는 IP 주소를 물리 주소로 매핑하고 RARP는 물리주소를 IP 주소로 매핑한다.

 

RARP가 오늘날에 거의 사용되지 않는 이유

· RARP는 데이터링크 계층의 브로드캐스트 서비스로 이용되는데 이는 ARP 서버가 각 망에 존재해야 함을 의미한다.

· 컴퓨터가 다른 망과 통신하기 위해서는 컴퓨터의 IP 주소, 컴퓨터의 해당 서브넷, 라우터의 IP 주소, 네임서버의 IP 주소 이 4가지 항목을 요구하는데 반해 RARP는 오로지 IP 주소만을 제공한다.

 

- BOOTP(Bootstrap)

BOOTP는 DHCP의 이전 주자이다. 이는 RARP 프로토콜의 두 가지 약점을 극복하기 위해 만들어진 클라이언트/서버 프로토콜이다.

먼저 이는 클라이언트/서버 프로그램이므로  BOOTP 서버가 인터넷상의 어디에나 있을 수 있다. IP 주소를 포함하여 4가지 항목을 모두 제공한다.

4가지 항목을 모두 제공하기 위해 RARP 프로토콜에 관한 모든 제약을 제거하였다. 그러나 BOOTP는 정적인 설정 프로토콜이다.

 

- DHCP
DHCP는 처음으로 부팅한 컴퓨터나 디스크가 없는 컴퓨터에게 4가지 정보를 제공하기 위해 설계된 클라이언트/서버 프로토콜이다. DHCP는 BOOTP 프로토콜의 승계자로서 BOOTP와 역방향 호환성을 갖는다.

비록 BOOTP가 거의 사라진 것으로 보이지만 호스트 설정을 위해 BOOTP 프로토콜을 사용하는 시스템이 아직 남아있다. DHCP의 동적인 측면을 제외하면 BOOTP에도 모두 적용 가능하다.

 

DHCP(Dynamic Host Configuration Protocol)

DHCP는 UDP 기반 프로토콜이며, 서버가 네트워크 클라이언트에게 IP 주소를 실시간으로 부여할 수 있도록 한다. 

IP 주소가 수동으로 설정되는 정적 IP 주소와는 다르게 DHCP는 사용 가능한 IP 주소를 자동으로 확인하고 클라이언트에게 IP 주소를 부여한다.

DHCP는 서버-클라이언트 패러다임을 사용하는 응용 계층의 프로그램으로 실질적으로 TCP/IP의 네트워크 계층을 보조한다.

 

- DHCP 동작 절차

DHCP processing (src. cisco)

새롭게 참가하는 호스트는 트랜잭션-ID 필드가 임의의 숫자로 지정된 DHCPDISCOVER 메시지를 생성한다. 사용자 데이터그램은 근원지 주소가 0.0.0.0(this-host), 목적지 주소가 255.255.255.255(broadcast)인 IP 데이터그램으로 캡슐화된다. 그 이유는 참가하는 호스트는 자신의 주소도 서버의 주소도 모르기 때문이다.

 

DHCP 서버(혹은 다수의 서버)는 참가하는 호스트를 위해 your-IP-address 필드를 제안된 IP 주소로 지정하고 server-IP-address는 서버의 IP 주소를 지정하는 DHCPOFFER 메시지로 응답한다. 이 메시지에는 호스트가 해당 IP를 사용할 수 있는 시간도 명시되어 있다.

 

참가하는 호스트는 하나 혹은 그 이상의 제안을 받고 그 중 가장 좋은 것을 고른다. 그리고 DHCPREQUEST 메시지를 가장 좋은 제안을 보내온 서버로 전송한다.

 

마지막으로 선택된 서버는 클라이언트가 요청한 IP 주소가 유효한 경우 DHCPACK 메시지로 클라이언트에게 응답한다. 만약 서버가 그 주소를 받아들일 수 없다면(만약 그 주소가 동시에 다른 호스트에게 제안도니 경우 등) 서버는 DHCPNACK 메시지를 전송하여 클라이언트가 이 과정을 반복하게 한다.

 

+ DHCP Starvation Attack

DHCP 서버의 할당 가능한 IP를 모두 소진하게 만들어 IP할당이 불가능하게 하는 공격이다. discover 메시지를 서로 다른 MAC 주소로 대량으로 보내게 되면 이에 대한 offer가 올 것이고 여기서 request 메시지까지 보낸 후에 실제로는 할당하지 않는다.

 

DNS(Domain Name System)

TCP/IP 프로토콜은 개체를 구분하기 위해서 인터넷에서 호스트 연결을 유일하게 식별하는 IP 주소를 사용한다. 그러나 사람들은 주소보다는 이름을 사용하고자 하는 경향이 있어서 이름을 주소로 바꾸어주고 주소를 이름으로 바꿔주는 시스템이 필요해졌다.

인터넷이 작은 규모일 경우에는 호스트 파일을 사용하여 이러한 매핑을 수행했지만 오늘날에는 단 하나의 호스트 파일로 매핑하는 것이 불가능해졌다.

 

네임 공간

- 도메인

도메인은 도메인 네임 공간의 서브트리이다. 도메인 네임은 서브트리의 맨 상위에 있는 노드에 위치한다.

도메인은 그 자체가 다른 도메인(또는 서브 도메인)으로 나뉠 수 있다.

 

- 네임 서버의 계층

전체 도메인 네임 계층을 하나의 서버에 저장할 수 없기 때문에 여러 서버에 나누게 된다. 서버가 책임을 지거나 권한을 가지는 곳을 영역 즉, zone이라 한다.

이러한 영역을 전체 트리의 연속적인 일부 부분이라고 정의할 수 있다. 서버가 도메인에 대한 책임을 수락하고 이를 더 작은 도메인으로 나누지 않는다면 도메인과 영역은 같은 것을 의미한다.

서버는 영역파일이라는 데이터베이스를 가지며 그 도메인 내의 모든 노드 정보를 여기에 보관한다. 그러나 서버가 도메인을 서브 도메인으로 나누고 일부를 다른 서버에 권한 이양하게 되면 도메인과 영역은 서로 다른 의미가 된다.

 

· zone 파일

개별 도메인에 대한 DNS 정보가 설정되어 있는 파일이 zone 파일이다.

이들 zone 파일은 /etc/named.conf 파일의 directory 지시자에 설정된 디렉터리에 존재해야 하며, 하나의 도메인에 대해서 하나의 zone 파일을 만들어 주는 것이 가장 일반적이다.

 

DNS의 레코드 타입

RR 문자 코드	RR 유형	설명
A(Address)	주소	32비트 IP 주소를 포함한다. 이 유형은 네임 변환을 위한 노드의 주소가 저장되는 곳이기 때문에 DNS의 본질이라고 할 수 있다. AAAA는 IPv6의 주소 유형이다.
NS(Name Server)	네임 서버	DNS 존을 위한 권한 DNS 네임 서버의 네임을 나타낸다. 각 존은 1차 네임 서버를 가리키는 NS 레코드를 하나 이상 가지고 있어야 하며 네임은 유효한 주소 레코드를 가지고 있어야 한다.
CNAME	정규 네임	노드의 실제 네임을 가리키도록 정의한 별칭(alias을 위해 사용한다. CNAME은 기관의 필요에 따라 내부 네임은 수정하면서도 사용자는 변하지 않는 별칭을 사용하게 함으로써 사용자에게 DNS 구조의 내부 변경을 숨기는데 주로 이용한다.
SOA (Start of Authority)	권한 개시 정보	DNS 존의 시작을 표시하는데 사용하며 DNS 존에 대한 중요한 정보를 제공한다. 모든 존은 정확히 하나의 SOA 레코드를 가져야 한다. 이 레코드는 존의 네임, 1차(마스터) 권한 서버의 네임뿐만 아니라 관리자의 이메일 주소, 슬레이브(2차) 네임 서버를 갱신하는 대기 시간 등과 같은 기술적 세부사항까지 포함한다.
PTR	포인터	네임 공간의 다른 위치를 가리키는 포인터를 제공한다. 이 레코드는 IN-ADDR.ARPA 도메인을 통한 역방향 변환에 주로 이용한다.
MX(Mail Exchange)	메일 교환	도메인으로 오는 이메일을 처리하는 위치(장비의 네임)를 명시한다.
TXT	문자열	도메인과 관련해 저장해야 할 임의의 문자를 나타낸다. TXT 레코드에는 대표적으로 SPF(발송자 메일서버 인증) 레코드 정보가 있다.(일반적으로 요청 대비 응답이 크기 때문에 DNS 증폭 DRDoS 공격에 악용됨)
ANY	모든	도메인에 대한 모든 레코드 질의 시에 주로 이용한다. 이 역시 요청 대비 응답이 크기 때문에 DNS 증폭 DRDoS 공격에 악용된다.
AXFR (Authoritative Zone Transfer)	존 전송	존 버전에 상관없이 무조건 존 전송 요청한다. 형식) dig @마스터 네임서버주소 zone name axfr
IXFR (Incremental Zone Transfer)	존 전송	존 버전을 비교하여 상위 버전일 경우 존 전송 요청한다. 형식) dig @마스터 네임서버주소 zone name ixfr=버전정보

 

· 루트 서버

루트 서버는 전체 트리를 영역으로 가지는 서버이다. 루트 서버는 보통 도메인에 대한 어떠한 정보도 가지지 않으며 자신의 권한을 다른 서버들에게 이양하고 자신은 이러한 서버들에 대한 참조만을 가지게 된다.

현재 13개의 루트 서버가 있으며 각각은 전체네임 공간을 다루고 있다. 서버들은 전세계에 분산되어 있다.

 

· 1차(master) 및 2차(slave) 서버

DNS는 1차 서버와 2차 서버의 두 가지 서버를 정의한다. 1차 서버는 자신이 권한을 가지는 영역에 대한 파일을 가진다. 이는 영역 파일에 대한 생성, 관리, 갱신에 대한 책임을 가지며 로컬 디스크에 영역 파일을 저장한다.

2차 서버는 다른 서버(1차 및 2차 서버)로부터 영역에 관한 완전한 정보를 수신하여 로컬 디스크에 파일을 저장하는 서버이다.

2차 서버는 영역파일을 생성하지도 않고 갱신하지도 않는다. 갱신이 필요하면 이는 1차 서버에서 이루어진 후 2차 서버로 갱신된 버전이 보내지게 된다.

 

· 존 전송(Zone Transfer)

마스터 네임 서버상의 레코드는 아무 때나 갱신할 수 있다. 마스터 네임 서버의 레코드가 변경되면 이와 동시에 슬레이브 네임 서버상의 정보 중 일부는 쓸모없는 것이 된다.

물론 2차 서버가 가지고 있는 정보의 대부분은 여전히 정확하며 2차 서버는 가장 최근의 정보로 변환 요청에 응답할 것이기 때문에 이는 일반적으로 큰 문제가 되지 않는다.

그러나 슬레이브 서버를 정기적으로 갱신하는 것은 매우 중요하다. 만약 정기적으로 갱신하지 않는다면 슬레이브 서버는 결국 유효하지 않은 정보만 가지게 되어 더 이상 신뢰하기 힘들어질 것이다. 이러한 이유로 존 전송은 정기적으로 수행해야 한다.

 

DNS 동작방식

- 해석기(resolver)

DNS는 클라이언트/서버 응용으로 설계되었다. 주소를 이름으로, 혹은 이름을 주소로 매핑하기 원하는 호스트는 해석기라고 불리는 DNS 클라이언트를 호출한다.

해석기는 매핑요구를 보내기 위해 가장 가까운 DNS 서버에 접속한다. 만약 서버가 정보를 가지고 있으면 해석기에 대한 응답을 줄 수 있으나, 그렇지 않다면 다른 서버를 참조하게 하거나 다른 서버가 이 정보를 제공하도록 요구한다.

해석기가 매핑 결과를 수신한 후 제대로 온 것인지 아니면 오류가 난 것인지를 알아보기 위해 응답을 해석한 다음, 최종적으로 그 결과를 요청한 프로세스에 전달한다.

 

- 재귀적 해석

클라이언트가 네임 서버에게 재귀적 요청을 보내면 서버는 정보가 있는 경우 그 정보로 응답한다. 만약 해당 정보가 서버에 없는 경우 서버는 실제 클라이언트 대신 스스로 클라이언트가 되어 다른 서버(주로 부모 서버)에게 새로운 요청을 보내는 방법으로 답변을 찾아내야 한다.

 

- 반복적(iterative) 해석

클라이언트가 네임 서버에게 반복적 요청을 보내면 서버는 요청에 대한 답변 또는 해당 정보를 가지고 있거나 그 정보에 좀 더 가까운 다른 서버(질의를 해석할 수 있을 것 같은 서버)의 네임으로 응답한다.

그러면 최초의 클라이언트는 이 서버에 새로운 요청을 보내고 서버는 답변을 주거나 다시 다른 서버의 네임을 제공하는 방식으로 반복해야 한다. 이 과정을 적절한 서버를 찾아낼 때까지 계속한다.

 

DNS 변환 과정

1순위 : Caching

서버는 자신의 도메인에 있지 않은 이름에 대한 문의를 받을 때마다 IP 주소에 대해 데이터베이스에 검색을 요구한다. 이 검색 시간의 감소가 효율 증가를 가져온다. DNS는 이를 위해 캐싱이라는 절차를 이용한다.

서버가 다른 서버에게 매핑 정보를 요청하고 응답을 수신하면 이 정보를 클라이언트에게 전달하기 위해 캐시 메모리에 저장한다.

캐싱은 주소 해석 속도를 높일 수 있지만 문제점도 가지고 있다. 만약 서버가 오랫동안 캐싱 정보를 가지고 있다면 클라이언트에게 잘못된 매핑 정보를 보낼 수도 있다.

대부분의 DNS 서버는 네임 분석과정에 도움이 되는 정보를 저장하는 것뿐 아니라 네거티브 캐싱 기능도 지원한다.

 

2순위 : /etc/hosts 파일

/etc/hosts 파일은 도메인/호스트명과 IP 주소 매핑정보를 담고 있는 파일로 네임서버에 질의하기 전에 먼저 참조되는 파일이다.

파밍 등의 공격을 통해 파밍 사이트로 접속하도록 hosts 파일을 변조하는 사례가 자주 보고되며 관리상의 주의가 필요하다.

 

3순위 : DNS 서버

· Recursive DNS 서버

동일한 작업을 조건이 만족될 때까지 반복적으로 처리한다.

· Authoritative DNS 서버

관리하는/위임받은 도메인을 가지고 있는 네임서버를 말한다. 즉, 특정 도메인에 대한 정보를 관리하면서 해당 도메인에 대한 질의에만 응답해주는 네임서버를 말한다.

 

DNS Lookup 유틸리티

DNS Lookup 유형에는 forward DNS lookup과 reverse DNS lookup이 있다.

순방향 룩업은 도메인명을 통해서 IP주소를 알아내는 질의를 의미하며 역방향 룩업은 IP 주소를 통해서 도메인명을 알아내는 질의를 의미한다.

 

- nslookup 유틸리티

가장 널리 쓰이는 DNS 진단 유틸리티 중의 하나가 오래 전부터 쓰인 nslookup(name server lookup)이다.

이 유틸리티는 보통 대화형 모드 또는 비대화형 모드에서 쓰일 수 있다. 비대화형 버전의 nslookup은 매우 단순하며 관리자가 특정한 호스트 이름을 주소로 또는 그 반대로 빠르게 변환하고 싶을 때 자주 쓰인다.

nslookup <host> [<server>]

명령 형식은 위와 같으며 host는 일반 변환의 경우 DNS 도메인 이름이며 역변환 경우에는 IP 주소이다.

server는 선택적인 인자이며 생략할 경우 nslookup 프로그램은 명령이 실행된 호스트의 기본 네임 서버를 사용한다.

 

- dig(Domain Information Groper) 유틸리티

nslookup 대신 사용할 수 있는 또 다른 대안은 dig이다. dig은 가장 단순한 형태로 실행되었을 경우에도 host 명령보다 훨씬 풍부한 정보를 제공한다.

dig은 다양한 옵션과 기능(여러 도메인에 대한 정보를 수집하는 batch 모드 포함)을 갖춘 복잡한 툴이다.

dig 명령의 기본 문법은 nslookup이나 host와는 다르다. 기본 네임 서버 이외의 네임 서버를 사용하려면 서버 이름 앞에 @를 붙여서 호스트 이름 앞에 입력하면 된다. 그리고 다음과 같이 특정 유형의 자원 레코드를 지정할 수도 있다.

dig [@<server>] <host> [<type>] [options]

@server: 사용할 네임 서버 지정, 생략하면 해당 시스템에 설정된 기본 네임서버를 사용한다.

options : 질의유형을 생략하면 기본적으로 A 유형 질의(도메인의 IPv4 주소 질의)를 수행한다.

 

- host 유틸리티

host 유틸리티는 nslookup의 비대화형 모드에서 수행되는 것과 같은 단순 요청에 쓰이는 경우가 많다. 이 유틸리티는 비대화형 nslookup과 동일한 방법으로 실행된다.

 

- whois 명령어

whois 서버를 통해서 해당 도메인의 등록정보(소유정보), 네트워크 할당 정보 등을 조회하기 위한 명령어이다.

해당 도메인명이 다른 사람에 의해 사용 중인지 여부를 체크하는 용도로 많이 사용한다.

 

DNS 보안

DNS 보안 위협

DNS는 인터넷 하부망에서 가장 중요한 시스템이다. 즉, 인터넷 사용자에게 중요한 서비스를 제공한다. 웹 접속이나 이메일과 같은 응용은 DNS의 적절한 동작에 크게 의존한다. DNS는 아래와 같은 여러 방법으로 공격될 수 있다.

· 공격자는 사용자가 접속하는 사이트의 이름이나 성질을 살피기 위해 DNS 서버의 응답을 읽어볼 수 있다. 이러한 공격을 방지하려면 DNS 메시지의 비밀성이 보장되어야 한다.

· 공격자는 DNS 서버의 응답을 중간에서 읽은 뒤 이를 변경하거나 완전히 새로운 위조 응답을 만들어 공격자가 사용자를 접속시키기 원하는 도메인이나 사이트로 가도록 할 수 있다. 이러한 공격 유형은 메시지 송신자 인증 및 메시지 완전 무결성을 사용해 막을 수 있다.

· 공격자는 DNS 서버가 붕괴되거나 압박받도록 대량 트래픽 공격을 할 수 있다. 이러한 공격 유형은 DoS 공격에 대한 방지책을 사용하여 막을 수 있다.

 

DNS Spoofing

DNS 스푸핑은 희생자에게 전달되는 DNS 응답을 조작하거나 DNS 서버의 캐시 정보를 조작하여 희생자가 의도하지 않은 주소로 접속하게 만드는 공격을 말한다. 따라서 희생자 입장에서는 정상적인 URL로 접속하지만 실제로는 공격자가 만든 가짜 사이트로 접속하게 된다.

 

- Sniffing based DNS Spoofing Attack

희생자가 DNS 질의를 수행하면 공격자가 이를 스니핑하고 있다가 정상 응답보다 빠르게 희생자에게 조작된 웹사이트 IP 정보를 담은 DNS 응답을 보내 정상 주소(URL)를 입력해도 조작된 주소로 접속하게 만드는 공격기법이다.

조작된 응답 이후에 도착하는 정상 응답은 먼저 수신한 응답을 신뢰하는 특성으로 인해 폐기된다.

 

대응책으로는 스니핑을 이용한 DNS 스푸핑 공격은 기본적으로 스니핑을 이용해 탐지하기 때문에 이를 탐지 및 차단하도록 한다.

중요한 사이트의 IP 주소에 대해서는 DNS 질의보다 우선순위가 높은 hosts 파일에 등록하여 관리하도록 한다.

 

- DNS Cache Poisoning Attack

DNS 서버의 캐시정보를 조작하는 공격을 DNS Cache Poisoning 공격이라 한다.

공격자는 공격 대상 DNS 서버(Recursive DNS Server)에 조작할 도메인 질의를 다수 보낸다.

공격자는 공격 대상 DNS 서버가 반복적 질의를 수행하는 동안에 다수의 조작된 DNS 응답을 보낸다. 공격자가 다수의 응답을 보내는 이유는 공격 대상 DNS 서버가 반복적 질의 시 사용하는 Transaction ID와 출발지 Port를 모르기 때문에 랜덤한 Transaction ID와 목적지 Port를 다수 생성하여 응답한다.(스니핑이 불가능한 상황일 때)

공격자의 조작된 응답 중 정상 응답보다 먼저 일치하는 응답이 있으면 조작된 주소정보가 공격 대상 DNS 서버의 캐시에 저장되고 이를 질의하는 사용자느 조작된 사이트의 주소로 접속하게 된다.

 

· 대응책

네임서버의 소프트웨어를 최신 버전 상태로 유지하여 알려진 취약점에 대한 공격이 발생하지 않도록 한다.

도메인 관리용 DNS 서버(Authoritative Name Server)는 재귀적 질의를 허용하지 않도록 설정하고 제한된 사용자가 사용하는 Recursive DNS 서버라면 해당 사용자로 제한해서 허용하도록 한다.

 

DNSSEC(DNS Security Extensions) 기술을 활용한다.

DNS를 보호하기 위해 IETF는 DNSSEC이라고 불리는 기술을 만들어 메시지 송신자 인증과 전자서명이라는 보안 서비스를 사용해 메시지 완전 무결성을 제공한다.

그러나 DNSSEC은 DNS 메시지에 대한 기밀성은 제공하지 않으며, DNSSEC 스펙에는 DoS 공격에 대한 방지책이 없다. 그러나 캐싱 서비스를 이용해 이러한 공격에 대해서는 어느 정도 까지는 상위 계층 서버에 대해 보호하게 된다.

 

DNS 서버 보안 설정

도메인 쿼리순서 설정 파일(/etc/host.conf)

resolver의 옵션을 가지고 있는 파일이다. 즉, host 파일을 먼저 검색할 것인지 아니면 DNS에 의한 쿼리를 먼저 할 것인지의 순서를 정하는 설정이 order 옵션으로 설정되어 있다.

이 파일은 특정 도메인에 대한 IP를 찾고자 할 때 어디에서 먼저 찾을 것인가에 대한 순서를 정해놓은 파일이다.

 

사용할 네임서버 지정파일(/etc/resolv.conf)

이 파일은 서버가 사용할 네임서버를 지정해둔 파일이다.

 

name 설정 파일(/etc/named.conf)

BIND 데몬(가장 많이 사용하는 네임서버 솔루션)인 named의 존 환경설정 파일로 매우 중요한 파일이다.

DNS 서버의 네임서비스를 위한 여러 가지 옵션들이 설정된 파일이다.