티스토리 뷰

Security

DNS security

jacobbaek Jacob_baek 2012. 12. 10. 14:44

1. DNSSEC(DNS Security Extensions)

DNS packet은 UDP base로 위변조(피싱 및 스푸핑 등)에 취약하다. 이를 보완하기 위해 DNSSEC 표준 프로토콜이 출범했다. 해당 프로토콜은 간단하게 말해 DNS protocol에 전자서명을 추가한 개념이라 볼수 있다. 어떠한 암호화가 이루어지는것이 아닌 전자서명 매커니즘만 반영되어 위변조에 대한 검증 및 송신자에 대한 증명을 하는 수단으로 사용된다.

DNSSEC은 기존 DNS를 대체하는것이 아니라 기존 DNS에 공개키 암호화를 추가하여 보안성을 강화시킨것이다.

간단하게 말하자면 DNS Resource Record Set과 함께 암호화된 디지털 서명을 통하여 인증 보장을 하는 것이다.


DNS 보안 취약점 극복을 위한 DNS 확장 표준 프로토콜

spoofing과 같은 공격에 취약한 점을 보완하기 위해 만들어졌다.

DNS cache Poisoning(or Pharming) 과 같은 DNS 데이터 위변조 공격형태를 방어하기 위해 만들어졌다.


발생배경

- DNS는 UDP Protocol을 사용하여 실질적인 security가 고려되지 않았다.

- UDP Protocol 특징상 spoofing 하기 쉽다.

- 쿼리 및 응답에 각각 한번의 UDP packet이 사용된다.

- Source IP에 의존적이다.


새로운 RR 정의

- 전자서명과 서명검증 절차를 지원하기 위한 신규 리소스 레코드를 정의

- RRSIG RR, DNSKEY RR, NSEC(Next Secure) RR, DS RR

 Record

 전자서명

 설명

 RRSIG

 서명

 도메인 네임 시스템의 각 RR 데이터에 대한 전자서명 데이터를 저장하기 위한 RR

 RRSIG는 DNS 응답 메시지에 전자서명 대상 RR과 함께 포함되어 전달된다.

 DNSKEY

 공개키

 도메인 존의 공개키 데이터를 저장하여 제공하기 위한 리소스 레코드

 개인키, 공개키 pair에서 공개키에 해당하는 것이 DNSKEY RR이다.

 KSK나 ZSK 둘중 하나가 될수 있고 Zone에 대한 공개키이다.

 NSEC(3)

 원본데이터

 부정적 대답에 사용된다. 즉, 네임이 존재하는지에 대한 증명에 사용된다.

 DNS 데이터의 부재인증을 위해 정의된 리소스 레코드

 실제로 질의한 도메인이 존재하지 않는 도메인이거나 레코드가 존재하지 않는 경우 

 zone내에 각 도메인들을 sorting하고 그 순서에 맞는 domain을 NSEC으로 응답

 NSEC3는 Return되는 도메인을 Hash 함수처리

 DS

 DNS 고유의 위임체계에 따라 보안측면의 인증된 위임체계 구성을 위한 데이터 저장

 부모, 자식 도메인간에 인증사슬을 형성

 KSK가 포함되고 이것이 싸인되었고 신뢰사슬에 사용됨에 대해 부모 Zone에 제출

 DLV

 

 DS Record와 비슷하고 Zone에서 DS Record가 지원되지 않을때 사용

 또는 레지스터가 DNSSEC을 지원하지 않은 경우 신뢰앵커가 변경하려고 사용

- 참고 : http://www.linuxjournal.com/content/dnssec-part-i-concepts?page=0,1


전자서명에 사용되는 키

 KSK
 (Key Signing Key)

 ZSK를 서명하는데 사용, Zone의 Secure Entry Point(SEP) 키로 사용

 암호화비트를 길게 사용하고 기간을 길게 가져가는 Key로 사용된다.

 ZSK
 (Zone Signing Key)

 zone의 모든 RR을 서명하는데 사용

 암호화비트를 짧게 사용하고 기간을 짧게 가져가는 Key로 사용된다.

실제 ZSK는 Authoritative DNS에 존재한다. 이유는 zone을 가지고 있는 곳이 Authoritative DNS 이기 때문이다.


신뢰앵커

 신뢰앵커(Trust Anchor) 

 이 신뢰앵커부터 Authoritative DNS까지를 신뢰사슬로 생성한다.

 Cache DNS에 수동으로 등록하는 Key, 일반적으로 Root의 DNSKEY를 사용한다.


※ DNSSEC을 적용한다고 하여 기본적인 DNS 구조나 동작환경이 변화되지는 않는다. 다만 전자서명 매커니즘에 필요한 RRSIG, DNSKEY, NSEC/NSEC3, DS Resource Record가 추가되어 처리가 된다. (DNSSEC은 Zone 단위로 적용됨)


전체 동작 원리

1. 각 Resource Record (RR)에 대한 공개키 암호화방식의 전자서명을 사용하여 서명하여 RRSIG RR에 저장한다.

2. RRSIG RR은 질의 응답 절차에서 응답 메세지 포함되어 응답된다.

3. Resolver는 응답에 동봉된 RRSIG RR의 전자서명을 가지고 서명 검증 절차를 수행한다.

4. 검증 절차는 Authoritative Zone 의 원본 데이터와 다르지 않음을 검증한다.


구성요소

signed zone은 각 record에 대한 RRSIG를 가지고 있고 NSEC3, DNSKEY등을 보유하게 된다.


DNSSEC 검증과정

최초는 Authoritative DNS로 질의를 하여 response를 받는다.
당시 response에는 RRSIG(전자서명)도 포함되어 있다.
포함된 RRSIG가 정상인지 여부를 확인하기 위해 Cache DNS(Recursive Query 가능)에서
Root는 검증이 되었다고 가정하고 질의를 수행한다.
(일반적으로 Cache DNS는 Root에 대한 정보를 가지고 있고 root의 검증은 수행이 불가하다.)

Root 다음 .com과 같은 다음 하위도메인에 질의를 한다.


키관리를 위한 만료일자

DNSKEY 의 응답을 확인하면 expire, begin time 이 존재한다. 대략적으로 KSK가 ZSK 기간이 넓게 설정된다.

전자서명은 공인인증서 및 코드 서명등에 사용된다.


설정

zone 의 ksk생성 및 적용 (/var/named 하위 디렉토리에 zone 존재하며 해당 경로에서 작업 수행)

1. testdomain.com zone의 ZSK 생성

# dnssec-keygen -a NSEC3RSASHA1 -r /dev/urandom -b 1024 -n ZONE testdomain.com.

2. testdomain.com zone의 KSK 생성

# dnssec-keygen -a NSEC3RSASHA1 -r /dev/urandom -b 2048 -n ZONE -f KSK testdomain.com.

3. 아래와 같은 키 생성됨을 확인(파일로 생성)

Ktestdomain.com.+007+45966.key            # ZSK (공개키)

Ktestdomain.com.+007+45966.private        # ZSK (개인키)

Ktestdomain.com.+007+46088.key            # KSK (공개키)

Ktestdomain.com.+007+46088.private        # KSK (개인키)

※ ZSK의 private key는 Zone의 모든 RR set 데이터에 대하여 서명

 KSK의 private key는 Zone의 DNSKEY RR set에 대해서만 서명

4. zone 반영(testdomain.com.zone 수정)

# mkdir /var/named/key

# mv Ttestdomain.com.* /var/named/key

# cat key/Ktestdomain.com.+007+45966.key >> testdomain.com.zone

# cat key/Ktestdomain.com.+007+46088.key >> testdomain.com.zone

5. 공개키 Zone에 반영

$INCLUDE Ktestdomain.com.+007+45966.key

$INCLUDE Ktestdomain.com.+007+46088.key

6. zone 서명(zone 파일이 존재하는 디렉토리에서)

# dnssec-signzone -S –K /var/named/key -3 96e920 -o testdomain.com. testdomain.com.zone

7. named.conf 수정

zone "testdomain.com" IN {

    type master;

    file "testdomain.com.zone.signed";

    key-directory "key";

    auto-dnssec maintain;

    update-policy local;

}

8. 시스템 재적용

# /etc/init.d/named reload : named 설정 리로드

9. dnssec 적용 확인

# dig @127.0.0.1 testdomain.com +dnssec


DNSSEC analyzer : http://dnssec-analyzer.verisignlabs.com/google.com


기존에 발생되었던 이슈들

1. 루트 도메인에 대한 미서명

2. DNS Zone 목록화(NSEC) :

NSEC3로 해결 

3. 서명 비용 과다 문제(NSEC) : TLD 도메인에서 변동발생시마다 재서명이 되어야 하는 문제

NSEC3로 해결

3. NameServer S/W에 대한 DNSSEC 지원


※ 닭과 달걀 문제(인과관계에 대한 딜레마 : 닭이 먼저냐 달걀이 먼저냐?)

Root 영역에 대한 서명이 필수적인데 TLD와 Autoritative DNS가 소유한 Domain에 대한 서명과의 관계성


DNSSEC 표준화시에 글로벌 키 배포시스템으로서의 기능이 포함되도록 개발이 시도되기도 하였으나 DNS자체의 안정성을 해칠수 있다는 가능성이 드러남에 따라 표준에서는 제외하고 별도의 레코드를 제안하여 IPSECKEY, SSHFP RR 등이 사용되게 된다.



2. TSIG(Transction Signature)

권한 DNS서버간에 Zone 전송시나 동적업데이트의 인증에 사용됨

대칭키를 기반으로 간단하게 트랜잭션에 대한 인증과 무결성을 지원

존 전송시에 대칭키를 이용한 보안채널 형성이 목적

GSS-API를 기반으로 구현된다.


3. DNS RRL(Response Rate Limit)

DNS 처리를 비율별로 제한시킬수 있는 기능입니다.

RRL의 동작은 다음과 같이 이루어집니다. RRL configuration 을 view별로 설정할 수 있습니다. 설정된 configuration을 load하며 관련하여 entry table을 생성합니다. 생성된 entry table은 MAX value까지 최대 생성될수 있으며 우선은 MIN value에 맞춰 생성됩니다. 

client 로 부터 request가 발생되면 resolve process를 거쳐 response를 생성하기 바로 전 단계까지 진행됩니다. 

question name 및 client ip, type 등에 대한 hash key를 생성하고 해당 key가 entry 에 등록된 key와 동일한지에 대한 

검사를 진행하고 동일한 결과를 찾는다. 

최초 request 에는

- entry 생성, response count, age(과거 바로전 request와의 시간차이) 등에 대한 데이터를 entry 에 추가한다.

동일한 key를 가진 entry를 발견한 경우

- response count 및 age가 view별로 생성한 rrl rule에 적합한지 검사를 수행한다.

위와 같이 검사된 결과를 토대로 response를 drop 할지 slip 할지, log만 남길지를 결정하게 됩니다.


Bind내 옵션

 response-per-second

 1초당 정상 응답을 하는 갯수

 referrals-per-second

 

 nodata-per-second

 

 nxdomains-per-second

 

 error-per-second

 RESPONSE-PER-SECOND와 동일한 기능으로  

 all-per-second

 result에 상관없이 모든 response에 대한 counting을 수행한다.

 window

 측정되어지고 평균내어진 비율을 넘어선 기간이다.

 또한 비율제한을 사용하는 메모리의 유지 기간이다.

 또한 비율제한에 의해 drop되는 기간을 의미한다. (1 ~ 3600 sec 설정가능)

 log-only (yes or no)

 적용전 시뮬레이션을 위한 log 만 남기는 기능

 qps-scale

 

 ipv4-prefix-length

 CIDR 설정으로 32일 경우 IP별로, 24일 경우 C class 별로 counting 수행

 ipv6-prefix-length

 

 slip

 TC(truncated) 로 응답하여 TCP로 재질의하도록 유도하는 기능.

 지정한 횟수마다 TC record로 응답이 발생됨. (default:2)

 exempt-clients

 RRL에서 제외시킬 대상을 지정한다.

 max-table-size  (default : 500)
 min-table-size

 (default : 20000)

http://ss.vix.su/~vixie/isc-tn-2012-1.txt


4. DNS RPZ(Response Policy Zone)

DNS 관리자가 선택적으로 사이트의 DNS 처리를 차단시킬수 있는 기능

- http://www.spamhaus.org/faq/RPZ.FAQ.20110602.pdf


5. DNS 대상 Attack 종류

DNS Spoofing

대체적으로 arp spoofing과 같은 선행 공격을 통해 클라이언트가 DNS query를 공격자에게 수행할수 있도록 한다.

이후 피해자 단말에 DNS query를 통한 특정 URL에 대한 IP를 얻고자 할때 공격자는 공격자 자신이 원하는 IP를 DNS response함으로 피해자가 공격자에 의해 의도된 서버로 접속하게 하고 계정 탈취 및 기타 정보 탈취를 하는 것을 의미한다.


- arp spoofing과 같이 이루어진다.

- local dns 보다 client에 지리적으로 가까운 위치이어야 한다.(위조된 DNS response를 먼저 보내기 위함)


http://blog.naver.com/PostView.nhn?blogId=edyui&logNo=50115926561


DNS Cache Poisoning

일반적인 DNS Recursive 질의 과정에서 Authoritative DNS로부터의 응답을 DOS Attack을 통해 지연시키고 당시의 Transaction ID를 유추해내어 응답을 Authoritative DNS보다 먼저 발생시켜 Cache DNS의 domain 과 매칭되는 IP정보를 변경시키는 공격이다.


DNS reflection/DrDos Attack :

DNS amplification :

TCP/UDP/ICMP floods :

DNS-based exploits : DNS software 의 vulnerability attack

DNS cache poisoing :

Protocol anomalies : send invalid packet or query to server

Reconnaissance : collect to server information

DNS tunneling :

DNS hijacking :

NX Domain attack :

Phantom domain attack :

- 출처 : FireEye infoblox advanced DNS Protection 발표자료


참고사이트

http://blog.pages.kr/514 : DNSSEC 설명

http://wareway.net/archives/1745 : DNSSEC key 관련 자세한 설명

http://dnssec.wikidot.com/setup : DNSSEC 설치 및 설정

http://ds9a.nl/dnssec/

https://www.dnssec-tools.org/wiki/index.php/Main_Page

http://occurs.lineum.org.uk/index.php?pages/DNSSec-Sequence-Flow : diagram

http://sangchul.kr/89 : DNSSEC 설정 및 적용
http://blog.pages.kr/514 : DNSSEC 한글설명

http://dns.kisa.or.kr/index.jsp

http://www.dcwg.org/

- http://technet.microsoft.com/en-us/library/jj200221.aspx

- http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains : TLD들의 DNSSEC 적용현황을 알수 있다.

'Security' 카테고리의 다른 글

DNS security  (0) 2012.12.10
TAG
,
댓글
댓글쓰기 폼
공지사항
최근에 달린 댓글
Total
50,180
Today
6
Yesterday
62
링크
«   2020/11   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
글 보관함