인터넷 통신 원리와 DNS 보안 쉽게 알자

IT 네트워크는 라우터와 DNS의 집합체라고 해도 과언이 아니다. 그래서 인터넷의 통신 원리를 IT 인프라 관점에서 깊게 정리해 봤고, 인터넷 통신의 핵심인 DNS 보안에 대해 알기 쉽게 작성해봤다.

인터넷에 google 주소를 쳤을 때 내부에서 일어나는 과정은?

직무 면접에서 나올 수 있는 질문인데 이것을 조금 딥하게 정리해보고자 한다. 

 

기본적으로 DNS는 "www.google.com"이라는 문자를 주소창에 입력하면 172.217.25.164 라는 ip 주소로 바꿔주어 접속을 가능하게 만들어 준다. https://www.ibm.com/kr-ko/topics/dns 에서 자세하게 보면 된다.

 

 

내 PC에서 google 주소를 입력했을 때 맨 처음에는 host file과 DNS Cache를 순차적으로 검색하여 DNS 서버를 거치지 않고 접속을 할 수 있다. 하지만 그럼에도 없는 경우엔 DNS 서버에 질의를 하여 접속을 하게 되는데, 이때 PC의 설정에 따라서 DNS에 질의를 하게 된다. 가정용 공유기라면 공유기에 설정되어 있는 DNS 설정으로 질의를 할 것이고, 그것도 아니라면 ISP에서 설정해 준 DNS 설정값을 통해서 질의를 하게 되어있다. 이때 내 PC에서 google의 IP주소를 알게 되어 Google 서버와 TCP 통신을 맺게 된다. 그렇게 TCP 연결이 된 상태에서 HTTP Request를 보내면 HTTP Response를 받아 화면에 Google 페이지가 보이게 된다.

 

1. host file, DNS Cache, DNS 직접 질의를 통한 IP 획득

2. TCP 연결 후 HTTP Req, Res를 주고받으며 페이지 접속

 

여기까지가 인터넷 통신을 하는 아주 기본적인 원리다. 

 

하지만 여기서 google이나 naver 같이 규모가 큰 웹서버라면 CDN을 사용하게 돼있고, GSLB가 적용되어 있다.

 

GSLB와 CDN?

우선 CDN(Content Delivery Network)이란 지리적으로 분산된 여러 개의 서버다.

 

이렇게 여러개의 지역에 구글의 서버를 두었고,

내 IP 주소에서 지리적으로 가장 가까운 서버에서 웹 콘텐츠를 전송받아 속도가 향상되는 이점이 있다.

 

GSLB(Global Server Load Balancing)란 가장 가까운 CDN 서버가 만약 DDoS 같은 공격을 받아 서버가 다운됐다면, 그다음으로 가까운 CDN 서버로 재연결 시켜주는 로드밸런싱 역할을 하는 기술이다.

 

만약 1.1.1.1 서버가 DDoS 공격을 받는 등의 장애를 발생하여 사용하지 못하게 됐을 때 일어나는 과정을 쉽게 설명하면 다음과 같다.

 

1) 내 PC에서 google 주소를 DNS 서버에 질의를 한다.
2) DNS에서는 GSLB 서버에게 연결 가능한 주소를 요청한다.
3) GSLB의 DB에 기록돼 있는 여러 CDN 서버들을 각각 Health Check 한다.
4) 1.1.1.1 이 장애가 일어났기 때문에 지리적으로 가깝고 정상 운영 서버인 2.2.2.2를 반환한다.
5) 마지막으로 내 PC에 2.2.2.2 서버에 접속할 수 있게 되어 정상적으로 Google을 이용할 수 있다.

 

---

DNS 보안

DNS Spoofing 공격은 크게 Sniffing 기반의 공격과 DNS Cache Poisoning 공격으로 나뉜다.

 

1) Sniffing 기반 공격

이는 DNS 질의응답 과정에 쓰이는 UDP 프로토콜의 비연결 특성을 악용한 공격이다. 가장 먼저 응답 온 DNS 응답을 신뢰하게 된다면 이후에 오는 모든 DNS 응답은 폐기해 버리는 성질을 이용한 것이다. 아래 그림처럼 DNS 질의를 하는 것을 해커가 도청하고, 실제 DNS 응답이 가기 전에 해커의 변조된 DNS 응답을 보내 잘못된 접근을 하게 만든다.

 

1) DNS에 질의한다.
2) DNS 질의를 도청하고 있던 해커가 x.x.x.x 주소로 반환되는 응답 메시지를 보낸다.
3) 원래 2.2.2.2가 응답되어야 하는데, 이전에 해커가 보낸 응답을 신뢰해 버리는 바람에 이 응답은 폐기 됐다.
4) 해커가 의도한 x.x.x.x 서버에 접속하게 된다.

 

<대응방법>

DNS 스니핑을(도청) 사전에 차단하고, 중요한 접속 정보는 DNS 질의보다 더 우선순위가 높은 host file에 등록해 관리해야 한다.

 

2) DNS Cache Poisoning 공격

DNS 서버를 아예 장악해서 DNS Cache 정보를 조작한다. 그래서 다수의 사용자들이 조작된 DNS 응답을 수신하기 때문에 대규모 보안 사고를 발생시키는 공격이다.

 

DNS 서버에 질의하는 과정을 자세하게 보면 사실 DNS Cache 서버에 질의를 하고 거기에 해당 ip가 존재하지 않는다면 DNS 서버에 요청을 하게 된다. 그래서 아래의 그림처럼 중간에 Cache Server를 거친다고 생각하면 된다.

 

1) 내 PC에서 DNS 쿼리를 보낸다.
2) Cache Server에 만약 해당 도메인 정보가 없다면 DNS 서버에 요청한다.
3) 해당되는 ip를 DNS Server로부터 받아서 Cache Server의 Cache table에 저장한다. 
4) DNS 서버에 해당 ip를 응답해 준다.

 

그런데 이 특성을 이용해서 공격자는 DNS Cache Server에 데이터를 변조한다.

 

 

이처럼 공격자는 다량의 DNS 질의와 변조된 응답을 보내어 DNS Cache를 변조시킨다. 목적지/출발지 주소와 TxID (Transaction id)가 일치한 응답을 DNS Server에서 나오는 정상응답이 먼저 닿기 전에 보낸다면 Cache 정보를 변조시킬 수 있다. 그래서 이 DNS 서버를 사용하게 되는 다수의 사용자는 해당 도메인을 접속하려다가 공격자가 의도한 악성 페이지로 접속하게 된다.

 

<대응방법>

DNS S/W를 업데이트하고, 도메인 관리용(Authoritative) DNS Server는 Recursive Query를 허용하지 않게 설정하여야 한다. 그럼에도 필요하다면 사용자들 제한하는 방법을 사용.

또한, 수신자가 공개키 암호화로 검증하는 기능을 제공하며 DNS 신뢰성 인증 및 무결성을 보장하는 프로토콜인 DNSSEC을 적용하여 DNS의 근본적인 문제를 해결해야 한다.

 

---

DNS 취약점 정리

- DNS 프로토콜의 취약점

1) 비연결성인 UDP의 성질을 이용한 취약점
2) 외부 노출을 해야 하는 포지션
3) 운영 중인 DNS 변경 불가
4) 53 Port Flooding

 

- DNS Server 취약점

1) DDoS 공격 타깃이 되기 쉽다.
2) 정상과 비정상 메시지에 대한 구분이 어렵다.
3) 처리 가능한 질의 수가 제한적이다.
4) 단일 실패 지점으로 작용한다 (SPoF - Single Point of Failure)