Transcript Konkuk.ac.kr DNS servers

네트워크 보안
Chapter 3. DNSSEC
김기천
http://mbc.konkuk.ac.kr
1
Chapter 3. DNSSEC
3.1 DNS
1.
2.
3.
DNS 개념
DNS 구조
DNS 보안 취약점
3.2 DNSSEC 개념 및 특징
3.3 DNSSEC 확장
1.
DNSSEC 개념
1.
DNSSEC 표준화 동향
2.
DNSSEC 특징
2.
DNSSEC 보안 사고사례
3.
DNSSEC 구성
3.
DNSSEC 침해 대응책
2
3.1 DNS(Domain Name System)
1
DNS 개념
2
DNS 구조
3
DNS 보안 취약점
3
3.1 DNS(Domain Name System)
• DNS의 개념
‒ 존 포스텔(Jon Postel)과 폴 모카페트리(Paul Mockapetris)에
의해 DNS(Domain Name System)가 RFC 882, 883의 공식
표준 문서로 개발
3.1 DNS(Domain Name System)
• DNS의 개념
‒ TCP/IP 네트워크에서 사용되는 도메인과 IP간의 매핑 서비스
‒ 초기 인터넷환경에서는 HOSTS.TXT라는 파일를 사용하여 IP와
도메인주소가 맵핑된 자료를 보유
‒ 호스트수가 광대해짐에 따라 HOSTS.TXT 파일로는 한계점 발생
 DNS 서버의 발생
‒ 계층적 이름 구조를 갖는 분산형 데이터베이스로 구성
naver.com 접속
naver.com
202.131.30.12
User
DNS Server
3.1 DNS(Domain Name System)
• DNS의 개념
‒ 인터넷 도메인은 하나의 역트리 구조로 구성
‒ 인터넷 도메인 체계에서 최상위는 루트
‒ 루트 아래에 위치한 1단계 도메인을 최상위 도메인이라 하
며 약어로 TLD(Top Level Domain)
3.1 DNS(Domain Name System)
• DNS의 개념
‒ DNS(Domain Name System)은 도메인 이름을 사용하는 거대한
영역의 수직적인 체계
‒ .kr도메인에는 .ac 영역을 표현하는 ac.kr 도메인이 포함
‒ ac.kr 도메인에는 konkuk.ac.kr 도메인이 포함
‒ 도메인 관리자는 해당 도메인이 포함하는 영역을 관리
Ex) konkuk.ac.kr 도메인 관리자는 konkuk.ac.kr 하위에
www.konkuk.ac.kr 또는 domain.konkuk.ac.kr 등 여러 개의 호
스트를 생성하는 등의 도메인 관리가능
.kr DNS Servers
ac.kr DNS servers
Konkuk.ac.kr mbc.com
DNS servers DNS servers
org DNS servers
edu DNS servers
mbc.org
DNS servers
mbc.edu
DNS servers
3.1 DNS(Domain Name System)
• DNS의 개념
‒ DNS의 최상위 루트 도메인 서버는 전세계에서 오직 13개만
이 존재
‒ ICANN 등의 운영주체를 통하여 국내 호스팅 업체인 가비아,
후이즈 등의 업체에서 도메인 서비스 대행
자료 - IANA(Internet Assigned Numbers Authority)
3.1 DNS(Domain Name System)
• DNS 구조
- 트리형의 분산 데이터 베이스로 구성
- 클라이언트(Client)와 서버(Server)패러다임으로 구성
 일반적으로 다음 4가지로 구성
1) 리졸버
2) 네임서버
3) 존
4) 도메인
3.1 DNS(Domain Name System)
• 리졸버 영역
- 리졸버란 호스트 명(Host Name)을 IP 주소로 변환하기 위한 일종
의 모듈
- DNS에서 질의가 발생하면 리졸버가 사용자 응용프로그램(User
Application)으로부터 받아들여 네임서버로 전송하고, 이에 대한
응답이 리졸버로 수신되면 사용자 응용프로그램으로 전송
3.1 DNS(Domain Name System)
• 네임 서버 영역
- 도메인 데이터베이스를 구성하는 정보의 저장소
- DNS 요청 수신시 동작 방식에 따라 결과를 리졸버에 전송
하는 역할
- 네임서버에서 사용하는 동작 방식으로는 순환식과 비순환
식이 존재
3.1 DNS(Domain Name System)
• 존 영역
- 네임서버에 의해 구분되는 DB영역을 지칭
- 서브 트리를 구성하는 RR(Resource Record)의 집합
- 존은 표현 데이터를 여러 RR로 구성
 대표적으로 SOA(Start Of Authority) RR, NS(name server) RR,
A(Internet Address) RR 등을 사용하며 다음을 포함한다.
1)
2)
3)
4)
구역 내의 모든 노드에 대한 신뢰성 데이터
상단 노드를 정의하는 데이터
위임된 하위 존 설명 데이터
하위존 네임 서버들에 대한 접근 허용 데이터
3.1 DNS(Domain Name System)
• 도메인 영역
- 도메인이란 관리대상이 되는 개체들의 추상적인 영역
- DNS에서는 하나의 서브 트리가 하나의 도메인을 구성
- 트리 내에서의 등급에 의한 구분과, 위임에 따른 도메인 분류에
의한 구분이 가능
3.1 DNS(Domain Name System)
• DNS 서버의 구성
- 리눅스/유닉스 계열에서 주로 BIND 소프트웨어로 DNS서버를
구축하며 윈도우 서버 계열에서는 관리 도구의 DNS에서 설정
 네임서버 구축 절차
1) DNS 구축에 필요한 프로그램 설치(BIND)
2) DNS 설정(/etc/named.conf)
3) 호스트 추가(IP-도메인 매핑 정보 등록)
4) 상위 기관에 네임서버 등록(네임 호스트 추가)
3.1 DNS(Domain Name System)
• BIND(Berkeley Internet Name Domain)
- DNS(Domain Name Service)구현을 위해 Paul Mockapetris에 의
해 개발된 JEEVES에서 유래
- Kevin Dunlap에 의해 UNIX용으로 처음 개발되었으며 현재
ISC(Internet Software Consortium)에서 관리
- BIND 세부 설정 파일은 크게 아래의 3가지로 구성
설정 파일
Named.conf
역 할
네임서버의 환경 설정
xxx.zone
도메인이름을 IP주소를 연결하기 위
한 존파일 설정
xxx.in-addr.arpa
IP주소로 도메인이름을 찾기 위한 역
방향 조회 영역 설정
존파일은 도메인을 설정하고 원하는 IP주소로 연결될 수 있도록 하는 정보 보유
리버스 존파일은 IP주소로 도메인이름을 찾을 수 있도록 하는 정보를 보유
3.1 DNS(Domain Name System)
• DNS 질의 과정
– 도메인 질의는 /etc/resolv.conf에 지정된 네임서버로 접속하여
아래와 같은 질의 과정을 수행
www.abc.com에 접속하는 과정
3.1 DNS(Domain Name System)
• 5가지 세부 관점에 따른 DNS 취약점 분류
1) 서비스 관점
2) 공격형태 관점
3) 공격대상 관점
4) 소프트웨어 취약성 관점
5) 기타 관점
3.1 DNS(Domain Name System)
• 서비스 관점
- 질의에 대한 널(Null) 응답을 통한 서비스 마비
- 잘못된 질의 응답(Redirect, inject)을 통한 피싱사이트 연결 및 서버
오작동
- 서비스 거부(Denial of Service) 공격을 통한 가용성 침해
- 보호대상 : 데이터/서버 보호
3.1 DNS(Domain Name System)
• 서비스 거부(Denial of Service)공격을 통한 가용성 침해
– 공격자가 대량의 질의를 발생시켜 도메인 서버가 다른 정상 서비스
요청 처리를 못하게 하는 방법
– 2002년 세계 최상위 13개 루트 서버에 대한 공격사례 : 1시간의
공격동안 관리자의 네트워크 트래픽 필터링 대처로 피해는 미미
– 피해는 없었으나 인터넷 기반시설에 대한 대규모 위협의 현실화
3.1 DNS(Domain Name System)
• 공격형태 관점
-
패킷스니핑를 통한 위/변조 공격
ID추측/질의예측을 통한 위/변조 공격
네임기반공격을 통한 위/변조 공격
신뢰된 서버로의 위장을 통한 위/변조 공격
보호대상 : 데이터 보호
AntiSpoofing
AntiSniffing
3.1 DNS(Domain Name System)
• 패킷스니핑를 통한 위/변조 공격
– 네임서버가 주고 받는 정보를 조작하여 조작된 정보를 유포하는
공격형태
– 도메인네임 변조를 통해 위조된 사이트로 유도하여 피해를
일으키는 사례 다수 발생
• 대표 사건
1) 1997년 11월 인터넷 최상위 도메인 관리
사이트인 InterNIC가 공격을 당해 Alternic
사이트로 접속 변환 사건
2) 최근에는 Birthday Attack 방법으로 DNS
캐시 포이즈닝 공격이 이루어 질 수 있음
이 보고
3.1 DNS(Domain Name System)
• 공격대상 관점
– 서버 : DNS 클라이언트, 네임 서버, 리졸버
– 유저 : Client PC, user Application
- 보호대상 : 데이터/서버 보호
3.1 DNS(Domain Name System)
• 소프트웨어 취약성 관점
-
네임서버에서의 악성코드 실행을 통한 서버정보 유출 및 파괴
네임서버의 루트쉘 권한 획득을 통한 서버장악 및 정보 유출
DDos Attack(서비스 거부 공격)을 통한 가용성 침해
보호대상 : 서버 보호
3.1 DNS(Domain Name System)
• 소프트웨어의 네임서버 취약점
– 네임서버 프로그램 버그에 의한 취약점을 의미하며 UNIX의
BIND(Berkeley Internet Name Domain)가 대표적인 네임서버측의
데몬 프로그램이다.
– 네임서버 프로그램 버그로 인해 서버가 중지되거나 시스템 전체가
장악 가능함
– 대처법으로는 신속한 수정용 패치 프로그램 배포법이 존재
UNIX용 BIND관련 취약점
1)
2)
3)
Inverse Query 취약점 (Buffer Overflow)
NXT버그 (buffer overflow)
solinger버그 (Denial of Service) 등
3.1 DNS(Domain Name System)
• 기타 관점
- 존 트랜스퍼를 통한 위/변조 혹은 정보 누출
 존 트랜스퍼 : DNS 서버간의 zone 파일 동기화 용도로 사용되는 기술
-
DNS 다이나믹 업데이트를 통한 위/변조
DNS 존 복제과정에서의 위/변조
만능문자 질의에 대한 무결성
클라이언트 플러딩(서버접속 과부하)
보호 대상 : 접근제어 / 서버 / 데이터 보호
3.2 DNSSEC의 개념과 특징
1
DNSSEC의 개념
2
DNSSEC 특징
3
DNSSEC 구성
26
3.2 DNSSEC의 개념과 특징
• DNSSEC의 등장배경
– 초기 인터넷 환경에서 DNS를 설계할 때 보안성을 고려하지 않음
– 보안을 고려하지 않은 DNS 설계에 따라 DNS 정보의 위-변조가
가능한 문제가 발생
Root DNS
DNS Cache Poisoning Attack
사용자
2) Q : naver.com ?
3) A : <com DNS>
com DNS
8-2) A : IP = 202.131.30.12 캐시 DNS 서
버
4) Q : naver.com ?
1) Q : naver.com ?
5) A : <naver.com DNS>
naver.com 위장 웹
220.30.41.9
8-1) A : IP = 202.131.30.12
naver.com DNS
6) Q : naver.com ?
위장된 웹
사이트 접속
정상 웹 사이
트 접속
7-2) 위-변조 응답 : IP = 220.30.41.9
공격자
7-1) A : IP = 202.131.30.12
naver.com 웹
202.131.30.12
3.2 DNSSEC의 개념과 특징
• DNSSEC 개념
– 전자데이터로 된 DNS정보에 서명코드를 추가하여 정보를 인증
– DNSSEC은 공개키 암호화 방식(Public Key Cryptography)의 전자
서명 기술을 DNS 체계에 도입
계약서
홍길동 인
계약서 + 도장(사인)
계약서
서명코드
전자 데이터 + 서명코드
3.2 DNSSEC의 개념과 특징
‒ DNSSEC(DNS Security Extensions)은 DNS 데이터를 대상으로
하는 “데이터 위조-변조 공격”을 방지하기 위한 인터넷 표준 기술
‒ DNS 데이터의 위조-변조 가능성을 원천적으로 차단하기 위해
DNSSEC은 공개키 암호화 방식의 전자서명 기술을 도입
‒ DNS 구성체계 중 DNSSEC이 제공하는 보안 안정성 범위
공격유형
방어여부
비고
파밍(캐시포이즈닝)
방어/방지
- DNS 데이터 위-변조 방식 이용 공격에 효과적 대응
피싱
해당없음
- 피싱은 유사 도메인네임을 사용하지만, 데이터 위-변조가 아님
DDoS 공격
해당없음
- DDoS 공격방어 메커니즘이 아님
웜바이러스에 의한
호스트 정보변조
해당없음
- DNSSEC은 DNS 질의응답 절차관련＂데이터 위-변조＂방지기술
3.2 DNSSEC의 개념과 특징
• DNSSEC의 작동원리
– DNSSEC은 공개키 암호화 방식의 전자서명 메커니즘을 DNS
체계에 도입하여 적용하는 방법
– DNS의 “데이터 위-변조” 취약점을 보강해 보안 안정성을 강화
3.2 DNSSEC의 개념과 특징
• DNSSEC
–
–
–
–
DNS Security Extensions
인증과 무결성 서비스 제공
공개키 기반의 서명 알고리즘 사용
보안관련 RR (Resource Record) 적용
RR (Resource Record)
DNSKEY (DNS Public key)
개요
- 도메인 zone의 공개키 데이터를 저장하여 제공하기 위한 RR
- 공개키는 DNSKEY RR 형태로 명시되어 질의응답을 통해 배포
- 개인키는 안전한 장소에 따로 보관
RRSIG (Resource Record Signature)
- 존 안에 있는 RRSet에 대한 개인키의 전자서명한 값을 갖는 RR
- DNS 응답 메시지에 전자서명 대상 RR을 포함하여 전달
NSEC / NSEC3 (Next Secure)
- DNS 데이터 부재 인증을 위해 정의된 RR
- 특정 리소스 레코드가 존재하지 않음을 전자서명을 통해 인증
할 수 있는 메커니즘 제공
- NSEC의 zone목록화 문제를 해결하기 위해 NSEC3 레코드 정의
DS (Delegation Signer)
- 인증된 위임체계 구성을 위한 데이터를 저장하는 RR
- 자식 도메인 zone의 KSK(Key Signing key)를 확증할 수 있는 수
단 제공(부모 도메인과 자식도메인 간에 인증사슬 형성)
기존 DNS에 4개의 RR을 추가하여 전자서명과 서명검증을 지원
3.2 DNSSEC의 개념과 특징
• DNSKEY RR
–
–
–
–
도메인 zone의 공개키 저장
RRSIG RR에서 제공되는 전자서명에 대한 공개키 제공
zone 파일에 설정되며 DNS 질의응답을 통해 공개배포
하나의 도메인 zone에 두 가지 서명키 사용
• ZSK (Zone Signing Key) – 모든 RR을 서명
• KSK (Key Signing Key) – DNSKEY RR을 서명
RR TYPE
TTL
mbc.co.Kr.
86400
Name
(공개키 소유자인
도메인 네임 지정)
DNSKEY
Flag
Protocol
256
3
Signature
Algorithm
7(
AQOvhvXXU61Pr8sCwELcqqq1g4JJCALG
4C9EtraBKVd+vGIF/unwigfLOAO3nHp/cg
GrG6gJYe8OWKYNgq3kDChNDW212+12
ascQWv+/1EPcPweVrqwDfABnn12RQwe
); key id = 28394
KeyTag
3.2 DNSSEC의 개념과 특징
• RRSIG RR
–
–
–
–
DNS의 각 RR Data에 대한 전자서명을 저장하기 위한 RR
전자서명 데이터와 함께 검증처리에 필요한 정보필드 보유
DNS 응답메시지는 대상 RR과 함께 RRSIG RR 추가적으로 응답
전자서명 생성에 사용된 개인키의 공개키인 DNSKEY RR을
지정하는 정보 보유
TTL
ns1.mbc.co.kr.
RR TYPE
86400
서명
TYPE
Covered 알고리즘
Label
Original
Number
TTL
IN RRSIG A 7 4 86400 20150315145440(
20150529145440 62745
서명
개시일자
서명
만료일자
mbc.com.
AQOvhvXXU61Pr8sCwELcqqq1g4JJCALG4C9Etra
BKVd+vGIF/unwigfLOAO3nHp/cgGrG6gJYe8OW
KYNgq3kDChNDW212+12ascQWv+/1EPcPweVr
qwDfABnn12RQwe
Label
Number
Key Tag
3.2 DNSSEC의 개념과 특징
• NSEC RR
– DNS 데이터 부재의 인증을 위해 정의된 RR
– 존재하지 않음을 인증하기 위한 RR
– RR에 대한 위장공격 시도 차단
Next Domain Name
Type Bit Maps
mbc.com
86400
NSEC
ftp.mbc.com
A NS SOA RRSIG NSEC DNSKEY
ftp.mbc.com
86400
NSEC
ns1.mbc.com
A RRSIG NSEC
ns1.mbc.com
86400
NSEC
ns2.mbc.com
A RRSIG NSEC
ns2.mbc.com
86400
NSEC
www.mbc.com
A RRSIG NSEC
www.mbc.com
86400
NSEC
mbc.com
A RRSIG NSEC
3.2 DNSSEC의 개념과 특징
• NSEC3 RR
– 존 목록화 문제 해소
 NSEC는 모든 도메인 네임 리스트와 설정된 RR 종류 파악 가능
– 도메인 네임 정보를 해시(hash) 처리
– 서명처리 과정에 NSEC3PARAM RR 자동 산출
 NSEC3 RR의 도메인네임 부분을 어떤 방식으로 해시 처리할지 지정
Type Bit Maps
7DB2C043CDC224BDF5.mbc.com
7200
IN
NSEC3
1
0
10
96E920
15776A96F69AFA87FB8
A RRSIG
15776A96F69AFA87FB8.mbc.com
7200
IN
NSEC3
1
0
10
96E920
F96CE3F78A53EC079E8
A RRSIG
F96CE3F78A53EC079E8.mbc.com
7200
IN
NSEC3
1
0
10
96E920
A8C960B172AC16D4B6
A NS SOA
RRSIG
DNSKEY
NSEC3PARAM
A8C960B172AC16D4B6.mbc.com
7200
IN
NSEC3
1
0
10
96E920
462CD41FAC22FE7DB2
A RRSIG
462CD41FAC22FE7DB2.mbc.com
7200
IN
NSEC3
1
0
10
96E920
7DB2C043CDC224BDF5
A RRSIG
Hash Algorithm
mbc.co
m
0 NSEC3PARA
M
반복 횟수
Salt
1 0 10 123E56
3.2 DNSSEC의 개념과 특징
• DS RR
–
–
–
–
–
–
–
–
보안측면의 인증된 위임체계 구성을 위한 RR
자식 도메인 zone의 키 서명키(KSK)의 DNSKEY RR에 대한 digest
부모 도메인과 자식 도메인 간의 Authentication Chain 제공
부모 도메인 zone이 자식 도메인 zone의 KSK를 인증하고 검증하는
수단 제공
부모 도메인 zone에 설정
DS RR에 대해 부모 도메인 zone의 ZSK로 서명 처리하여 RRSIG RR
설정함으로써 전자서명 검증에 대한 무결성 보장 제공
DS RR 값은 자식 도메인 zone 파일을 서명 처리할 때 자동 산출
BIND DNS경우 “dsset-”의 형식을 갖는 파일명으로 자동 저장
3.2 DNSSEC의 개념과 특징
• 부모 Zone (com.)
Key Tag : 자식 zone의 KSK의 Key Tag
자식존의 도메인네임
mbc.com.
Algorithm : 자식존의
KSK의 Algorithm
RR TYPE
86400
IN
NS
ns1.mbc.com.
86400
IN
DS
27111
Digest Type : Digest 생성 Algorithm
1 : SHA-1
2 : SHA-256
7 2(
CBD1697A36D2F9E592E472743EA3B0A8CVOP23PQWK42MQ02IEEK2)
86400
IN
RRSI
G
D
S
7 3
8640
0
2015031503292
5
2015061503292
5
1547
3
co
m
Puixe5NMXPIcJT6ZrV08ZCJf4SH56D8xmxjdw … … … Authentication Chain 형성
* 자식 Zone (mbc.com.) – ”dsset-mbc.com.”파일
mbc.com
IN
DS
27111
7 1 5BD9EF8F1C49C364269BAA3B1F3D72B0
mbc.com
IN
DS
27111
7 2 CBD1697A36D2F9E592E472743EA3B0A8CVOP23PQWK42MQ02IEEK2
3.2 DNSSEC의 개념과 특징
• Cache DNS 서버의 서명검증
– DNS 질의응답 과정에서 서명검증은 Cache DNS 서버에서 수행
– Root 부터 최종단 도메인까지 트리 구조
– DS RR과 각 존의 DNSKEY RR의 인증관계에 의해
Authentication Chain 트리 구조 구성
권한 DNS 서버
Cache DNS 서버
Trust Anchor 설정
ROOT(.)
ROOT(.)
kr
co
mbc
com
ac
mbc
Cache DNS 서버 관리자가
ROOT의 공개키 설정
mbc
일치?
DNSKEY RR (KSK
Public Key
com.
RRSIG(DNSKEY) RR
Signature
com.
DNSKEY RR (KSK)
Public Key
mbc.com.
RRSIG(DS) RR
Signature
mbc.com.
DS RR
Digest (hash)
mbc.com
DNSKEY RR (KSK)
Public Key
mbc.com
RRSIG(DNSKEY) RR
Signature
mbc.com
DNSKEY RR (ZSK)
Public Key
www.mbc.com.
RRSIG (A) RR
Signature
www.mbc.com.
A RRSet
일치 확인
서명
검증
OK
서명
검증
해시
일치
OK
OK
서명
검증
OK
서명
검증
최종 검증 완료
3.3 DNSSEC 확장
1
DNSSEC 표준화 동향
2
DNSSEC 보안 사고 사례
3
DNSSEC 침해 대응책
39
3.3 DNSSEC 확장
• DNSSEC 표준화 동향
– IETF에서 1995년경부터 표준화 작업 시작
– 1999년 RFC2535표준 문서를 시작으로 지속 발전
– RFC2535의 DNSSEC 표준의 적용과 시험 운영 가운데 보안 및
적용 운영상 문제점 발생
– 새로운 표준에 대한 개발 -> DNSSECbis
• DNSSECbis 표준화 동향
– 2번째 DNSSEC 표준화라는 의미
– 2005년 RFC 4033, RFC 4034, RFC 4035 표준문서로 표준화
작업 완료
 RFC 4034 : DNSKEY, DS(delegation signer), RRSIG(resource record digital
signature)와 NSEC(authenticated denial of existence) RR 타입을 정의, 각
RR의 형식과 목적 사용 예를 설명
 RFC 4035 : DNSSEC 프로토콜 확장 내용을 담고 있으며 서명된 존 개념,
DNSSEC을 이용하는 요구사항을 포함
(보안-인식 리졸버가 DNS RR들과 공식 DNS 오류를 인증 가능하게 함)
3.3 DNSSEC 확장
• DNSSEC 실제 적용사례
– 2005년 말, 스웨덴의 최상위 국가 도메인인 SE. 도메인에
DNSSEC 적용
– 유럽대륙 RIR(Regional Internet Registries)인 RIPE NCC는
자신의 도메인과 리버스 도메인에 DNSSEC 적용
– ISC(Internet Systems Consortium, Inc)에서 DNSSEC 운영을
위한 네임서버 SW인 BIND DNS를 제작 및 배포하고 DNSSEC
적용
– 2008년 미국정부는 .gov의 연방정부기관 도메인 전체에
DNSSEC 도입하도록 요구하는 지침을 배포
– 2008년, 백악관 예산집행부 / 2009년 미국 조달청의 .gov에
DNSSEC 도입
– 2011년, 베리사인(VeriSign)에서 관리하는 .com 및 .net 에
DNSSEC 도입 서명 적용
– 한국의 경우 go.kr부터 co.kr까지 DNSSEC의 도입 서명을 통해
도입 완료(2011-2012년)
3.3 DNSSEC 확장
• 외부 경로의 공격
– 피해 네트워크 외부에서 수행되는 인프라 공격은 명령 제어
서버나 봇넷을 사용하여 조직의 정상 운영을 방해하는 DDoS
나 다른 형태의 공격으로 서버의 운영을 방해하거나 중단
– 외부 공격으로 서버가 일정시간 중단될 경우 해당 기관은
단순한 기능저하에 상관없이 수익과 평판에 큰 타격 발생
• 내부 경로의 공격
– 멜웨어에 의한 공격을 통해 조직의 서버로 버그나 악성코드를
침투시켜 DNS 퀴리 응답을 통해 정보를 외부로 유출
– 내부 BIND 서버의 침투를 통해 악성코드를 유포하여 내부
정보 유출 또는 서버 중단의 공격을 수행
3.3 DNSSEC 확장
• 1.25 대란
– 2003년 1월 25일 미국/호주 등에서 유입된 슬래머 웜의 DB
공격으로 DNS서버가 마비되어 7시간 가량 국내 인터넷이 마비
– 국 내 감 염 시 스 템 이 전 세 계 의 11% 에 이 를 만 큼 심 각 한
보안피해 발생
– 1.25대란 이후 보안의식 강화 활동, 주기적 보안패치, 사이버
보안센터 설립 등 다양한 보안정책 수립
3.3 DNSSEC 확장
• 슬래머 웜이란?
– 1.25 인터넷 대란의 원인인 감염 프로그램으로 다음 특성을 보유
1) UDP프로토콜의 사용에 따른 데이터 홍수, 네트워크 과부하
결과 초래
2) 작은 크기의 프로그램, 식별이 힘들며 하나의 데이터 패키지로
침입과 감염이 가능
3) 데이터베이스의 감염, 20만대의 DB 서버감염으로 대규모 피해
4) 메모리 상주형태, 하드 디스크에 자료가 남지 않고 RAM에
상주함으로 탐지가 어렵고 빠른 실행이 가능
3.3 DNSSEC 확장
• KDB 대우증권 파밍 사례
– 2014년 5월 30일 접속한 포털사이트에서 금융감독원을 사칭한
팝업화면에 “보안관련 인증절차를 진행하고 있습니다＂라는
메시지와 7개 은행 바로가기 버튼이 제공되는 파밍사고 발생
– 바로가기 클릭하여 해당 은행에서 본인의 이름, 주민번호, 계좌
입력하여 일부 고객들의 피해가 발생
– 인터넷 공유기의 DNS주소 변조에 의한 공격 사례로 해당 기관과
금융감독원 등에서 소비자 경보를 통해 피해 최소화를 위한 노력
파밍사이트
정상사이트
3.3 DNSSEC 확장
• 인터넷 공유기 DNS 변조 공격 방식
– CSRF(Cross-site request forgery)취약점을 활용하여 공유기에
침투하여 DNS변조 공격을 수행
– 특정 침투 스크립트(공격코드)를 실행하여 DNS 설정 변경을
유도하는 패킷을 발생
– 정상 site가 아닌 파밍 site로 희생자 유저의 접속을 유도
3.3 DNSSEC 확장
• DNS 침해 대응 방안
1) 서버관리자
– DNS서버와 BIND S/W에 대한 주기적인 보안패치
– Local Name Server와 root Name Server의 네트워크 대역 분리
운영을 통한 침해 방지
– DNS 서버에서의 클라이언트 응답에 대한 대역폭 제한
– 실시간 관제와 적절한 보안정책을 통한 침해 최소화
2) 개인사용자
– 개인 PC 및 공유기 보안 패치 및 백신 운영 등 보안점검 생활화
– 피싱 홈페이지에서 금융정보 입력요구에 유의
– 경찰청의 파밍방지 프로그램 적극 활용
3) 국가기관
– DNS 침해 동향에 대한 패치자료(DNS Server, BIND S/W) 배포
– DNS 보안 관리에 대한 올바른 관리 정책 수립