IP Spoofing
침입자가 자신의 IP주소를 속여 서버가 진짜로부터 메시지를 받고 있다고 착각하도록 하여 패킷을 보내려는 시도.
IP 스푸핑 공격의 종류에는에는 Blind IP Spoofing(모든 출처에서 공격)과 Non-Blind IP Spoofing(동일한 subnet으로부터의 공격)이 있다.
Blind IP Spoofing
공격자가 어떤 정보도 가지고 있지 않고, 대충 임의의 IP주소를 사용하는 방식이다.
서버는 acknowledgement number를 요구하기 때문에 이런 방법은 쉽게 성공하기 어렵다.
acknowledgement number는 서로 통신하는 두 컴퓨터가 서로 패킷을 정확하게 받았는지 확인하는 역할을 한다.
공격자는 이 확인번호를 모르기 때문에 서버의 검증을 통과하기 어렵다.
Non-Blind IP Spoofing
공격자가 같은 subnet 내에 있는 사용자를 대상으로 하는 IP Spoofing이다. 공격자가 packet sniffer를 사용해 실제 사용자의 packet을 탈취한 후, 사용자의 acknowledgement sequence pattern을 결정한다.
이 도구를 이용해 실제 사용자의 IP 주소와 확인 번호를 복사해 서버에 보내 인증한다.
서버는 확인 번호가 일치한다고 판단하여 공격자를 정상 사용자로 인식하게 된다.
Packet Sniffers
네트워크를 통해 전송되는 정보를 '읽는' 도구이다. 네트워크 패킷을 가로채며, ARP cache poisoning에 사용하기도 한다.
(1) 합법적인 경우로 사용될 경우
네트워크 사용 모니터링, 네트워크 트래픽 필터링, 네트워크 문제 분석
(2) 악의적으로 사용될 경우
password나 대화내용 훔쳐보기
공격 준비를 위한 네트워크 정보 분석
packet sniffer는 소프트웨어 또는 하드웨어 기반일 수 있으며, 네트워크 설정에 따라 달라질 수 있다.
Detecting Sniffers
Sniffer를 탐지하기는 매우 어렵다.
Sniffer는 보통 거의 passive하게(수동적으로) 동작하기 때문이다. sniffer는 단순히 데이터를 수집할 뿐이지 데이터를 훔치기위해서 침입을 하지는 않는다.
sniffering이 의심될 때 탐지하기 위해서는
(1) sniffer에게 response를 유도하는 어떤 형태의 ping(핑)이 필요하다. 이 ping은 sniffer만 응답하게 하는 broadcast여야 한다.
(2) 또 다른 해결책은 ARP watch이다.
ARP 감시는 ARP 캐시에서 동일한 기계의 중복 항목을 모니터링한다. ARP 감시는 ARP 캐시에서 동일한 기계의 중복 항목을 모니터링한다. 하나의 IP 주소에 대해 여러개의 MAC 주소가 존재하는지 확인한 후, 중복 항목이 나타나면 경보를 울린다. 하지만 DHCP같은 네트워크에서는 하나의 기계에 대해 여러 항목이 있을 수 있기 때문에 정상적인 네트워크에 대해 오탐지를 할 가능성이 있다.
*ARP 스푸핑 공격이 일어날 때 중복 MAC 주소가 발생하는 이유는, 공격자가 ARP 프로토콜을 조작해 자신의 MAC 주소를 네트워크 상의 다른 컴퓨터나 장치의 IP 주소와 연결하기 때문이다.
Stooping Packet Sniffing
가장 좋은 방법은 패킷을 안전하게 암호화하는 것이다.
sniffer는 패킷을 캡쳐할 수 있지만, 캡처한 패킷이 쓰레기로 읽힌다면 쓸모가 없다.
SSH 또한 훨씬 더 안전한 연결 방법으로, private key - public key 쌍을 사용하면 sniffing이 거의 무용지물해진다.
switched network에서는 대부분의 공격이 ARP Spoofing을 통해서 이루어진다.
기계를 cache의 영구 저장소에 추가하고 이 장소는 broadcast response로 수정할 수 없다.
따라서 이 sniffer는 주소를 자신에게 redirection 할 수 없다.
가장 좋은 보안은 처음부터 그들이 들어오지 못하게 하는 것이다.
switch는 네트워크 내의 데이터를 목적지 MAC 주소를 기반으로 전달하는 장치이다. switch는 각 포트에 연결된 장치의 MAC 주소를 학습하여 효율적으로 데이터를 전달한다. ARP 스푸핑은 공격자가 네트워크 상의 다른 컴퓨터로부터 데이터를 가로채기 위해, 그 컴퓨터의 IP 주소에 대한 ARP 응답을 위조하는 공격이다.
이러한 ARP 스푸핑을 방지하기 위한 방법은 아래와 같다.
(1) 기계를 캐시의 영구 저장소에 추가한다.
ARP 테이블에 특정 IP 주소와 MAC 주소의 매핑을 영구적으로 저장(정적 매핑)한다. 이렇게 하면 네트워크 장치가 해당 IP 주소에 대해 브로드캐스트로 응답을 받더라도, 매핑이 변경되지 않는다.
(2) 브로드캐스트 응답으로 수정 불가
일반적으로 ARP는 네트워크 내의 다른 장치로부터 브로드캐스트 요청을 보내고, 응답을 받아 ARP 테이블을 업데이트한다. 영구적으로 저장된 ARP 엔트리는 브로드캐스트 응답으로 인해 변경되지 않기 때문에 ARP 스푸핑 공격자가 가짜 ARP 응답을 보내더라도, ARP 테이블의 매핑이 변경되지 않게 된다.
Port Knocking
특정 포트들을 순서대로 접속 시도(=knock)함으로써 방화벽을 통과해 서버에 접근 권한을 얻는 기법이다.
특정 포트들에 순서대로 접속을 시도하는 행위가 사용자가 자신을 인증하는 방식이 되는 것이다.
이 포트들은 기본적으로 차단되어있으며, 올바른 순서로 접속 시도가 이루어졌을 때만 서버의 포트가 열리게 된다.
이 공격은 brute force attack에 상당히 안전하다. 정해진 포트에 대한 노트 조합이 매우 많기 떄문에 올바른 조합을 찾아내기가 매우 어렵다. ex) 65536^k(여기서 k는 노크된 포트 수)
그러나, replay attack에 취약하다. 누군가가 유효한 port knocking sequence를 기록한 후 이를 다시 재생하여 서버에 접근 할 수 있다.
-> 이에 대한 대응 해결책으로는, 'time dependent knock sequence'가 있다.
포트 노킹 시퀀스에 시간 요소를 추가하여 노크 시퀀스가 일정 시간 동안만 유효하도록 설정하여 포트 시퀀스를 기록하여도 시간이 지나면 사용할 수 없게끔 한다.
step 1) 랜덤하게 생성된 포트번호(P1)에 UDP 패킷을 보낸다. 포트 노킹 시퀀스의 시작을 알리는 역할이다.
step 2) 이어서 클라이언트가 포트 노킹 시퀀스에 따라 다른 포트(P2)에 또다른 UDP 패킷을 보낸다.(일련의 포트 노킹 시퀀스 완성을 위해 반복될 수 있는 과정)
step 3) 마지막으로 마지막 포트(P3)에 UDP 패킷을 보내 포트 노킹 시퀀스를 마무리한다. (조회를 위한 노크로 사용되
기도 함.)
step 4) 웹서버가 클라이언트 포트 노킹 시퀀스 확인 후 올바른 시퀀스가 완성되었을 때 서버 측에서 랜덤 포트를 연다.
이후 서버는 클라이언트에게 암호화된 UDP 패킷을 보내 열린 랜덤 포트 번호를 알린다.
step 5) 클라이언트는 서버가 제공한 랜덤 포트를 통해 연결을 시도하고, 연결되면 해당 포트를 통해 서버의 내부 서비스(ex) SSH, Port 22)에 접근할 수 있다.
즉, 정리하자면 무작위로 포트를 열고 닫는 대신, 특저앟ㄴ 포트 시퀀스에 의해서만 네트워크 서비스에 대한 접근을 혀용하는 보다 안전한 방법을 제공하는 것이다.
User Datagram Protocol
UDP는 IP 위에서 작동하는 네트워크 통신을 위한 프로토콜 중 하나로, OSI 모델 4계층인 Transport 계층에 위치한다.
UDP의 특징을 요약하자면, 빠른 데이터 전송을 가능하게 하지만, 전송된 데이터의 도착을 보장하지는 않는다.
(->데이터 손실, 순서 변경, 혼잡 문제 ...)
따라서 신뢰성보다는 속도가 더 중요한 애플리케이션에서 주로 사용된다.
특징 1) 비연결성 및 비신뢰성
UDP는 상태를 유지하지 않는 stateless 프로토콜로 연결 설정 및 유지에 필요한 오버헤드가 없다.
따라서 데이터 전송은 빠르지만 데이터가 도착했는지 확인하지 않고 손실되거나 순서가 바뀌어도 다시 보내지 않는다.
특징 2) 다중 애플리케이션 지원
UDP는 하나의 호스트에서 동시에 여러 애플리케이션에 데이터를 구분하여 전송할 수 있다. IP 주소와 포트 번호를 조합해 데이터를 올바른 대상 애플리케이션으로 전달하기 때문이다.
*신뢰성 부재의 대책?
UDP 사용시에는 데이터 손실이나 오류에 대비해야 한다. 예를 들면 TFTP(Trival File Transfer Protocol)은 UDP를 기반으로 하면서 추가적인 신뢰성을 제공하는 프르토콜이다.(기본적인 오류 검사와 재전송 기능을 제공함. 연결설정은 필요 없어 간단한 요청에 대한 빠른 응답이 가능.)
Network Address Translation
(아웃바운드 트래픽에서 소스 IP 주소를 변환, 목적지 IP 주소는 그대로 유지)
NAT는 1990년대 초반에 IP 주소의 부족 문제를 완화하기 위해 고안된 기술로,
내부 네트워크와 외부 네트워크 간의 IP 주소를 변환하는 역할을 한다.
NAT는 내부 네트워크의 많은 기기들이 하나 또는 소수의 공용 IP 주소를 공유할 수 있도록 함으로써 IP 주소를 절약할 수 있다.
*주소 변환: 내부 네트워크(사설 네트워크)의 IP 주소를 외부 네트워크(공용 네트워크)에서 사용할 수 있는 주소로 변환하고, 이 작업은 일반적으로 router에서 수행한다.
*Router의 역할?
NAT을 구성하는 라우터는 내부 네트워크와 공용 네트워크 사이에 위치하며 둘의 IP 주소를 매핑한다.
해당 라우터는 사설 IP 주소 풀을 관리하며, 외부와의 통신이 필요할 때 이들의 사설 주소를 공용 주소로 변환한다.
*한계점
투명성 부족-> 서비스가 NAT의 존재를 인식하지 못하고 정상적으로 작동해야 하지만, 많은 고수준 통신 프로토콜과 응요프로그램이 IP 주소를 직접적으로 사용하므로 NAT 환경에서는 문제가 발생할 수 있다. P2P 네트워킹 애플리케이션을 사용자간의 직접적인 연결을 위해 서로의 실제 IP주소를 알아야 한다.
IP Packet Modifications
IPv4 헤더 구조를 나타내는 그림이다.
version(IP 프로토콜 버전), 헤더 길이, 서비스 유형, 전체 패킷 길이, 플래그, Fragment Offset(분할된 패킷들 중 하나의
Domain Name System(DNS)
IP 주소를 domain name과 맵핑시켜주는 application-layer protocol이다.
DNS는 여러 유형의 resource record를 저장한다. 아래는 주요 레코드의 유형이다.
ex) www.example.com -> DNS -> 208.77.188.166
| A(주소) 레코드 | 도메인 이름과 연관된 IP 주소를 저장한다. |
| MX(메일 교환) 레코드 | 도메인의 메일 서버 정보를 저장한다. ex) example.com 도메인의 이메일이 mail.example.com 서버를 통해 전송된다면, MX 레코드에 이 정보를 저장한다. |
| NS(네임 서버) 레코드 | 도메인의 권한 있는 서버 정보를 저장한다. ex) example.com 도메인의 DNS 정보를 관리하는 네임 서버가 ns1.example.com과 ns2.example.com이라면, NS 레코드에 이 정보를 저장한다. |
DNS Tree
DNS 트리는 여러 계층으로 구성된다. 각 계층은 점으로 구분된 도메인의 이름의 부분을 나타낸다.
(1) 루트 도메인
트리 최상위 계층이며, 도메인 이름의 맨 끝에 위치하는 부분이다.
흔히 빈문자열로 표현되거나 '.'으로 표시된다.
루트 도메인은 최상위 도메인 TLD 서버의 목록을 보유한 루트네임서버에 의해 관리된다.
(2) TLD(최상위 도메인)
루트 도메인 바로 아래에 위치하는 계층이다. TLD는 일반적으로 '.com', '.org', '.net'과 같은 일반 최상위 도메인과 '.kr', '.us'와 같은 국가 코드 최상위 도메인으로 구분된다.
(3) 2차 도메인
TLD 바로 아래 위치하는 계층으로 기업, 기관, 개인이 등록할 수 있는 도메인이다.
(4) 하위 도메인(subdomain)
2차 도메인 아래에 위치하는 도메인이다. 도메인을 더 세분화할 때 사용된다.
ex) mail.example.com -> 루트 도메인 = '', TLD(최상위 도메인) = '.com', 2차 도메인 = 'example.', 하위 도메인 = 'mail'
Name Servers
권한 있는 네임 서버: 도메인 이름에 대한 정확한 정보를 제공하는 서버이다.
-루트 도메인 정보: 루트 네임 서버는 TLD 네임 서버에 대한 정보를 가지고 있다.
-서브 도메인 정보: 하위 도메인의 A레코드(IP 주소)나 다른 네임 서버(NS 레코드)에 대한 참조 정보를 제공한다.
네임서버의 계층구조는 도메인 계층 구조와 일치한다.
-루트 서버: 최상위에 위치하며, TLD 네임 서버를 가리킨다.
-TLD 서버: 각 TLD에 대해 책임이 있으며 하위 도메인에 대한 네임 서버를 가리킨다.
ex) 루트 서버는 net TLD 서버를 가리키고, net TLD 서버는 cs166.net에 대한 권한 있는 네임 서버를 가리킨다.
루트 서버와 TLD 서버는 안정적인 정보 제공을 위해 거의 변경되지 않는다.
네임 서버는 다른 네임 서버를 이름으로 참조하며, 필요시 글루 레코드를 사용해 IP주소를 제공한다.
*Bootstrap: 네임 서버가 다른 네임 서버의 IP 주소를 알지 못하는 경우, 이름과 함께 IP 주소를 제공해야 한다.
이를 glue record라고 한다.
근데, DNS와 NameServer의 차이가 뭐지?
| DNS(Domain Name System) | Name Server |
| DNS는 인터넷의 전화번호부 같은 역할을 한다. 사람들에게 사이트 주소를 기억하기 쉬운 도메인 이름으로 입력할 수 있게 해주고, 도메인 이름을 IP주소로 변환한다. 전세계적으로 분산된 서버 네트워크로 구성되어 있다. |
DNS 구성 요소 중 하나로 도메인 이름을 IP 주소로 변환하는 실제 서버이다. 네임서버는 DNS 쿼리에 응답하여 요청받은 도메인 이름에 대한 IP 주소 정보를 제공한다. (1) 권한 있는 네임 서버 = 특정 도메인 정보를 관리하는 권한을 소유 (2) 재귀 네임 서버 = 요청을 받고 이를 다른 네임 서버로 전달 |
Name Servers Operation Sequence
Namespace Management
ICANN(=Internet Corporation Assigned Names and Numbers)은 전체 DNS 관리를 책임지고 있다.
루트 도메인을 관리하며 각 최상위 도메인(TLD)에 대한 관리를 도메인 이름 등록 기관에 위임한다.
1999년 이전까지는 com, .net, .org 레지스트리는 Network Solutions Incorporated(NSI)에서 관리했지만, 그 이후부터 ICANN과 NSI는 공유 등록 시스템을 도입했고 현재는 500개 이상의 등록 기관이 있다.
Name Resolution
Zone: 동일한 권한이 있는 DNS 서버를 공유하는 연결된 노드의 모음이다.
권한 있는 DNS 서버란, 특정 도메인에 대한 최종적이고 정확한 정보를 제공하는 서버이다.
Name Resolution은 클라이언트가 도메인 이름을 입력했을 때, 해당 도메인 이름에 대한 IP 주소를 찾는 과정이다.
이 과정은 cache에 없는 경우 수행된다.
step 1) 클라이언트가 'www.example.com'의 IP 주소를 찾기 위해 요청을 보낸다.
클라이언트는 먼저 ISP의 DNS 서버에 요청을 보낸다.
step 2) ISP DNS 서버는 캐시에 'www.example.com'의 IP 주소가 없으면 root name server에 요청을 보낸다.
step 3) 루트 네임 서버는 '.com'에 대한 TLD 네임 서버의 주소를 반환하고 ISP DNS 서버는 '.com' 네임 서버에 'www.example.com'의 IP 주소를 요청한다. '.com' 네임서버는 'example.com' 도메인에 있는 네임 서버의 주소를 반환한다.
Recursive Name Resolution vs Iterative Name Resolution
(1) Recursive Name Resolution
클라이언트가 하나의 DNS 서버에 요청을 보내고, 이 서버가 최종 결과를 찾을 때까지 다른 DNS 서버에 요청을 보내는 방식이다. 로컬 DNS 서버가 요청을 받아 최종 결과를 찾기 위해 여러 DNS 서버를 거쳐 재귀적으로 요청을 보낸다.
클라이언트는 한번의 요청으로 최종 결과를 받는다.
Client -> Server A -> Server B -> Server A -> Client
(2) Iterative Name Resolution
클라이언트의 로컬 DNS 서버가 각 단계에서 DNS 서버로부터 직접 응답을 받아 다음 요청을 보내는 방식이다.
클라이언트가 최종 결과를 얻기까지 여러 단계의 요청을 거친다.
DNS Lookup and Query에서 봤던 그림이 이 방식으로 Name Resolution을 수행한다.
로컬 DNS 서버가 각 단계에서 DNS 서버로부터 직접 응답을 받아 다음 단계의 서버에 반복적으로 요청을 보낸다.
각 단계의 DNS 서버는 자신의 역할을 다하고, 그 다음 단계의 서버를 알려준다.
DNS name resolution example
(왼쪽: Iterative Query, 오른쪽: Recursive Query)
Authoritative Name Servers
권한 있는 네임 서버(Authoritative Name Server, ANS)는 특정 도메인에 대한 최종적이고 정확한 정보를 제공하는 서버로, 주로 하위 도메인에 대한 정보를 관리한다. 루트 도메인과 최상위 도메인(TLD)도 각각의 권한 있는 네임 서버가 있지만, 여기서 말하는 ANS는 주로 개별 도메인과 그 하위 도메인에 대한 정보를 관리한다.
ANS간에 관리가 분산되어있다. 특정 도메인에 대해 책임을 지고, 하위 도메인에 대해 다른 권한 있는 네임 서버를 지정할 수 있다.
ANS는 master 혹은 slave server가 될 수 있다.
-master server: 원본 zone 테이블을 보유하고 있는 서버이다.
-slave server: 마스터 서버의 복제본을 가지고 있으며, 자동으로 업데이트 된다.
이를 통해 DNS Fault Tolerance를 제공하고 자동으로 부하를 분산시킨다.
ANS는 상위 도메인의 "zone" 내에 설치되어야 한다.
예를 들어 'example.com'의 ANS는 '.com' 도메인의 DNS 내에 구성되어 있어야 한다.
Dynamic Resolution
많은 large provider는 하나의 도메인에 대해 여러 authoritative name server를 가지고 있다.
더 빠르고 효율적인 서비스를 제공하기 위해서는 사용자가 요청한 도메인의 인스턴스를 지리적으로 가장 가까운 곳에서 찾을 필요가 있다.
제안된 해결책으로는 재귀 요청시 요청자의 IP 주소의 처음 세 옥텟을 포함시키는 방법이다.
이는 해당 요청을 가장 가까운 서버로 라우팅하는 데 도움이 된다. 예를 들면, 요청자의 IP 주소가 192.168.1.1이라면 192.168.1을 포함시켜 가까운 서버를 찾는다.
CDN(콘텐츠 배포 네트워크)는 이미 adaptive DNS 라우팅을 사용하고 있다. 이는 사용자에게 가장 가까운 서버에서 콘텐츠를 제공하기 위한 시스템이다.
* Adaptive DNS routing은 네트워크의 지연 시간, 서버의 과부하, 지리적 위치 등 다양한 요인을 고려하여 DNS 쿼리를 가장 적합한 서버로 라우팅하는 기술이다.
DNS Caching
DNS 쿼리가 매번 완전한 경로를 따라 처리된다면, 막대한 네트워크 트래픽과 루트 존의 과부하를 초래할 수 있을 것이다.
따라서 DNS 서버의 캐싱 기능을 통해 같은 요청에 대해 더 빠르게 응답할 수 있도록 한다.
DNS 서버는 쿼리 결과를 일정시간동안 캐싱(=저장)하는데, 이 저장 시간은 TTL(Time-to-Live)라는 값으로 정해지며 이는 ANS에서 제공하는 정보에 포함된다.
ex) Windows에서는 'ipconfig / displaydns' 명령어를 통해 현재 캐시된 DNS 정보를 확인할 수 있다.
DNS 쿼리는 대부분 UDP를 사용해 포트 53을 통해 요청된다. 각 DNS 요청에는 16bit의 요청 식별자가 포함되어 서버와 클라이언트간에 정보를 매칭하는데 사용된다.
<동작 과정>
step 1) 쿼리 전송
사용자 기기에서 웹사이트 접속 시도 시 DNS 쿼리가 시작된다. 쿼리는 먼저 사용자 로컬 머신에 있는 DNS resolver로 전송되고, resolver는 cache를 확인해 최근에 요청된 같은 도메인에 대한 정보가 저장되어있는지 확인한다.
캐시에 정보가 없다면, 쿼리는 사용자의 ISP의 로컬 네임 서버로 전송된다. 로컬 네임 서버 역시 자체 캐시를 확인한 후 필요한 정보를 찾지 못하면 ANS로 쿼리를 전송한다.
step 2) 응답 수신 및 캐싱
ANS는 요청받은 도메인의 DNS 레코드를 확인하고, 해당 정보를 로컬 네임 서버로 응답한다.
로컬 네임 서버는 이 응답을 받아 자신의 캐시에 저장하고, 이 정보를 다시 사용자의 로컬 머신으로 전달한다.
사용자 로컬 머신 또한 이 정보를 자체 캐시에 저장한다.
step 3) 캐시된 결과 사용
다음번 같은 도메인에 대한 쿼리가 있을 때, 예를 들어 다른 사용자가 같은 웹사이트에 접속하려고 할 때 이 사용자의 로컬 머신과 로컬 네임 서버는 캐시된 데이터를 사용해 즉시 응답할 수 있다. (추가적인 네트워크 트래픽과 지연 감소)
step 4) 캐시 만료 및 제거
각 캐시된 레코드에 대한 TTL(Time-to-Live)이 만료되면, 해당 정보는 자동으로 캐시에서 제거된다.
Pharming: DNS Hijacking
특정 도메인주소와 매칭되는 IP 주소를 악의적으로 바꾸는 것이다.
DNS Spoofing
real website가 DNS 서버에서 request를 보낼 때, Fake DNS entry를 주입해 Real Website가 아니라 Fake Website로 연결되끔 하는 것이다.
DNS Cache Poisoning
DNS 시스템의 취약점을 이용해 악의적인 공격자가 DNS 캐시에 잘못된 정보를 주입해 트래픽을 조작하는 보안 공격 방법이다.
기본적인 아이디어는, DNS 서버에 잘못된 레코드를 제공하고, 그 정보가 DNS 캐시에 저장되게 만드는 것이다. DNS 쿼리가 잘못된 IP 주소로 라우팅되어 사용자가 의도치 않은 사이트로 유도될 수 있다.
*DNS Request Identifier: DNS는 16비트의 요청 식별자를 사용해 쿼리와 응답을 연결한다. 이 식별자는 쿼리가 발생할 때 생성되고, 해당 쿼리에 대한 응답을 구분하는데 사용된다.
[캐시 오염의 조건]
-식별자 무시: dns server가 응답의 식별자를 제대로 확인하지 않고 어떤 응답이든 받아들이는 경우
-예측 가능한 ID: 공격자가 DNS 쿼리의 식별자를 예측할 수 있다면, 가짜 응답을 보내 이 식별자와 일치시킬 수 있다.
-비요청 DNS 레코드 수용: DNS 서버가 비요청된 DNS 레코드를 수용할 경우, 공격자가 의도적으로 잘못된 정보를 서버에 삽입할 수 있다.
DNS Cahe Poisoning Prevention
DNS 캐시 포이즈닝을 예방하기 위한 방법은 다음과 같다.
1) 임의 식별자 사용
DNS 쿼리에 사용되는 식별자를 무작위로 생성하여 공격자가 예측하고 해당 식별자와 일치하는 가짜 응답을 보내는 것을 어렵게 만든다. 즉, 공격자가 식별자를 추측하는 것을 어렵게 만들어 보안을 강화한다.
2) 식별자 확인
DNS 서버가 받은 응답의 식별자를 항상 확인한다. DNS 쿼리와 응답의 식별자가 일치하는지 검증하여, 일치하지 않는 응답은 무시한다.
3) DNS 요청에 대한 포트 무작위화
DNS 요청을 보낼 때 사용하는 소스 포트를 무작위화하여, 공격자가 요청과 응답을 가로채거나 조작하는 것을 더 어렵게 만든다. 공격자가 트래픽을 조작하여 DNS 캐시를 오염시킬 가능성을 줄여준다.
DNSSEC
DNS 정보의 무결성과 인증을 보장하기 위한 기술이다.
Digital Signature를 사용해 DNS 데이터가 변경되지 않았음을 확인하고, 응답이 신뢰할 수 있는 출처에서 왔는지 검증한다.
DNSSEC의 도입과 실행은 도전적인 측면이 있다.
아직 상용화되어 활발히 사용되지는 않기도 하고, 효과적인 보호를 위해서는 DNS 서버와 클라이언트 양쪽 모두에서 DNSSEC를 지원해야 하기 때문이다.
DNS Signing