[여기보기]는 “여기서 보안의 기본을 챙기고 가자”의 약자로, 개발 과정에서 꼭 최소한으로 챙기면 좋을 보안 기초 설정을 앞으로 하나씩 공유할 예정입니다. 기초 내용이 주를 이루겠지만, 혹시라도 빼먹고 계신 것이 없는지 가끔 한 번씩 둘러봐 주세요.
안녕하세요, 넷마블 보안실 보안개발팀 전희창입니다.
이번에는 리눅스 서버의 DNS 관련 내용을 살펴보겠습니다. DNS(Domain Name System)가 어떤 역할을 하는지는 자세히 설명하지 않아도 기본 개념은 다들 아시리라 생각합니다.
일반적으로 우리가 작업하는 대부분은 DNS 서버 자체가 아닙니다. DNS 서버로 접속해서 쓰는 DNS 클라이언트가 내장된 VM이나 애플리케이션이죠. 그래서 DNS 관련 보안 사항은 동작 방식을 기준으로 DNS 클라이언트와 DNS 서버로 나눠서 봐야 합니다.
DNS 클라이언트
‘DNS 클라이언트’라는 용어가 어색한 분들도 있을 것 같습니다.
DNS 클라이언트란 DNS 서비스에 접근해 도메인 이름을 IP 주소로 받거나, IP 주소를 도메인 이름으로 해석하는 역할을 하는 소프트웨어 또는 기능을 말합니다. DNS 클라이언트는 사용자 또는 응용 프로그램이 DNS 서버에 쿼리를 보내고 DNS 응답을 받아오는 역할을 합니다.
일반적으로 컴퓨터 운영체제나 네트워크 장비에 DNS 클라이언트 기능이 내장돼 있습니다. 예를 들어, 운영체제는 네트워크 스택에 DNS 클라이언트 기능이 들어 있어, 인터넷에서 도메인 이름을 IP 주소로 해석하거나, 로컬 네트워크의 DNS 서버에 쿼리를 보내서 로컬 도메인 이름을 해석합니다. 일반 사용자의 경우, 웹 브라우저나 이메일 클라이언트 같은 응용 프로그램이 가진 DNS 클라이언트 기능으로 도메인 이름을 IP 주소로 해석해 웹 페이지에 접근하거나 이메일 서버와 통신합니다.
리눅스 서버는 DNS 관련 설정을 resolv.conf 파일과 hosts 파일에 담고 있습니다. 이 두 파일은 기능은 비슷하나 목적과 동작 방식이 사뭇 다릅니다.
resolv.conf 파일
resolv.conf 파일은 DNS 이름을 리졸브(resolve)하기 위한 설정 파일입니다. 주로 시스템 전체 DNS 설정을 관리할 때 사용합니다. nameserver 항목은 시스템이 사용할 DNS 서버의 IP 주소를 지정하는 항목이고, search 항목을 활용하면 도메인 이름을 리졸브할 때 도메인 접미사를 추가할 수 있습니다.
hosts 파일
hosts 파일은 IP 주소와 호스트 이름의 정적인 매핑 정보가 들어있는 로컬 호스트 설정 파일입니다. 시스템이 호스트 이름을 IP 주소로 해석할 때 가장 먼저 참조하는 로컬 데이터베이스라고도 할 수 있습니다. 작고 간단한 네트워크 환경에서 호스트 이름을 리졸브할 때 사용하기도 합니다.
조치 방안
‘여기보기’를 꾸준히 보신 분들이라면, resolv.conf나 hosts 같은 시스템 설정 파일 확인에 대해 바로 감이 오실 겁니다. 소유자와 사용 권한을 확인해서 악의적인 침투로 인해 의도하지 않은 변경이 생기지 않도록 방어해야 합니다.
$ ls -l /etc/resolv.conf /etc/hosts
-rw-r--r-- 1 root root 533 Jun 12 15:19 /etc/hosts
lrwxrwxrwx 1 root root 39 Jun 6 11:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
// 심볼릭 링크까지 같이 확인하려면
$ ls -l /etc/resolv.conf /etc/hosts /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 root root 533 Jun 12 15:19 /etc/hosts
lrwxrwxrwx 1 root root 39 Jun 6 11:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 929 Jun 12 15:19 /run/systemd/resolve/stub-resolv.conf
위 두 파일의 소유자(root나 시스템 계정)와 사용 권한 확인을 마쳤다면, 신뢰할 수 있는 DNS 서버 IP주소가 들어가 있는지 확인할 차례입니다. 개발이나 특별한 작업을 위해 추가한 값이 아닌 불필요한 값이 있다면 삭제해야 합니다.
DNS 서버
요즘은 DNS 서버를 직접 구축하는 경험보다는, AWS Route 53을 사용할 기회가 더 많을 것 같습니다. DNS 서버라는 영역 자체가 점점 특수 목적용이 아닐 때에는 개인이나 소그룹이 직접 만들어서 쓰지 않더라도 활용할 퍼블릭 DNS가 많으니까요. 국내 통신망 사업자나 호스팅 업체에서 제공하는 DNS 서버도 있고, 구글(8.8.8.8, 8.8.4.4)이나 클라우드플레어(1.1.1.1, 1.0.0.1) 등에서 제공하는 퍼블릭 DNS 서비스도 있습니다.
그럼에도 불구하고, 망분리 환경 구축 같은 특수 목적으로 인해 직접 꾸려서 써야 하는 일도 가끔 생깁니다. DNS 서버 솔루션 자체가 탑재된 네트워크 하드웨어 장비를 구하거나, VM을 직접 세팅해야 하는 상황에 마주하는 순간이죠.
취약점 대응 업데이트
DNS 서버를 직접 구축할 때 사용하는 솔루션은 생각보다 종류가 많습니다. BIND, PowerDNS, Knot DNS, NSD, Unbound, MaraDNS, djbdns, CoreDNS 등 다양합니다. 솔루션마다, 오픈 소스와 상용 라이선스가 혼재된 경우도 있으므로 사용할 때 사용 조건을 꼭 확인하고 결정해야 합니다.
이런 소스를 직접 사용한다면, 취약점 보안 패치를 꼭 추적 관찰하고 대응해야 함을 잊지 말아야 합니다. 결국 DNS 서버 자체는 기본적으로는 파일이나 테이블을 활용하는 데이터베이스 형태를 취하고 있어, 버퍼 오버플로(Buffer Overflow)나 서비스 거부 공격(Denial of Service, DoS) 등으로 인한 침해나 침투 관련 취약점이 꾸준히 생겨나기 때문입니다.
DNS 서버 자체가 뚫리면, 해당 DNS 서버를 활용하는 사용자 모두에게 영향을 즉시 곧바로 주게 됩니다. 방어를 위한 취약점 패치 과정도 마찬가지입니다. 사용자 모두에게 영향을 즉시 곧바로 주는 만큼 시스템 및 서비스 영향 정도를 충분히 고려해서 작업 계획을 세워야 합니다.
DNS Zone Transfer
DNS 존 전송(DNS Zone Transfer)는 DNS 서버 간에 DNS 존 데이터를 동기화하기 위해 사용하는 기능입니다. DNS 존은 특정 도메인의 DNS 레코드 집합을 포함하고 있으며, 이 정보는 DNS 서버가 도메인 이름을 해석할 때 사용합니다.
일반적으로 DNS 존은 마스터(Master) 서버와 슬레이브(Slave) 서버로 구성합니다. DNS 존 작업 권한이 있는 사용자는 마스터 서버에서 DNS 레코드를 수정하고 관리합니다. 슬레이브 서버는 마스터 서버로부터 DNS 존의 복사본을 받아오는 역할을 합니다. 수정 내역 발생 시, 마스터 서버에서 변경된 DNS 존 데이터를 슬레이브 서버로 전송하는 프로세스가 동작합니다. 이 프로세스를 통해 슬레이브 서버는 항상 최신 DNS 존 데이터를 유지하며, 사용자의 DNS 쿼리에 신속하게 응답할 수 있습니다.
보통 DNS 존 전송은 두 가지 유형이 있습니다.
- 전체 존 전송(Full Zone Transfer): 프라이머리(Primary) 서버에 기록한 DNS 존 전체를 세컨더리(Secondary) 서버로 복사합니다. 초기 설정 또는 DNS 서버 간 동기화를 위해 사용합니다.
- 증분 존 전송(Incremental Zone Transfer): 프라이머리 서버에서 변경한 부분만 세컨더리 서버로 전송합니다. 이는 데이터 전송 양을 최소화하므로 동기화 효율을 높일 수 있습니다.
그래서 DNS 존 전송에는 적절한 인증 및 암호화 기술을 사용해, DNS 존 데이터의 무단 접근을 방지하고 안전한 전송을 보장해야 합니다. 이 속에 들어있는 존 정보로 호스트 정보, 시스템 정보, 네트워크 구성 형태 등 많은 정보를 파악할 수 있기 때문입니다.
조치 방안
DNS 존 전송 설정은 전체 공개 또는 불분명한 IP 주소가 아니라, 각자 용도에 맞춘 고정값 또는 비활성화 상태로 반영돼 있어야 합니다.
특히, DNS 존 전송 설정 방법은 같은 솔루션이더라도 버전별로 설정 방법이 다른 경우가 많습니다. 관련 취약점 업데이트 등으로 인해 설정값 구현 방식이 꾸준히 바뀌어 왔고, 앞으로도 바뀔 여지가 있음을 꼭 기억하고, 각자 사용하는 솔루션과 버전을 같이 확인해야 합니다.
아래는 짤막한 예시입니다.
위 이미지는 우분투 22.04에 설치한 BIND 9.18.12 버전 구성 파일 예시입니다. BIND 9.18.12버전 기준의 매뉴얼에서 DNS 존 설정 부분을 찾았습니다.
- Configurations and Zone Files – BIND v9.18.12
- Configuration File (named.conf) – BIND v9.18.12
- allow-transfer – BIND v9.18.12
설치한 패키지의 named.conf 파일을 열어보면, 매뉴얼에 나온 기본 설명 예시와 내용이 많이 다릅니다. 파일을 참조해서 쓰는 방식이나 참조 파일명 등이 다르다고 헤매지 마시고, 매뉴얼을 꼭 먼저 읽어보시는 것이 좋습니다.
// 설치한 패키지의 named.conf 파일
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
DNS 존 전송을 존마다 따로 구성하려는 경우, 매뉴얼을 참고해서 allow-transfer 옵션을 존 별로 따로 설정하는 것이 좋습니다. 먼저 프라이머리 서버 쪽입니다.
// 전역 설정으로 고정할 때
Options {
type primary;
allow-transfer {
192.168.1.101;
192.168.1.102;
};
// 존마다 따로 구성할 때
zone "example1.com" {
type primary;
file "example1.com";
notify yes;
allow-transfer {
192.168.1.101;
192.168.1.102;
};
};
zone "example2.com" {
type primary;
file "example2.com";
notify yes;
allow-transfer {
192.168.1.201;
192.168.1.202;
};
};
프라이머리 서버 설정을 마쳤으니, 세컨더리 서버에서도 설정을 맞춰야 합니다.
// 전역 설정으로 고정할 때
Options {
type secondary;
allow-transfer {
192.168.1.11;
};
// 존마다 따로 구성할 때
zone "example1.com" {
type secondary;
file "example1.com.saved";
primaries {
192.168.1.11;
};
};
BIND 구버전에는,
primary와secondary로 구분하는 설정값을master와slave로 쓰기도 합니다.
홍대 어떻게 가요?
DNS 클라이언트와 DNS 서버의 보안은 온라인 환경에서 매우 중요한 역할을 합니다. DNS는 인터넷 사용의 핵심 요소이며, 웹 브라우징, 이메일, 애플리케이션 통신 등 다양한 온라인 활동의 핵심 기반을 제공합니다.
DNS 클라이언트에서는 악성 쿼리 방지를 위해 DNSSEC(Domain Name System Security Extensions) 활성화도 같이 검토하는 것도 좋습니다. 신뢰할 수 있는 DNS 서버를 사용해야 하니까요. DNSSEC는 데이터 위조와 DNS 캐싱 독립성 공격 등을 방지해 안전한 DNS 응답을 제공합니다. 또한, 안티 스팸이나 악성 도메인을 차단하도록 신뢰할 수 있는 DNS 필터링 서비스를 활용하는 것도 좋은 방법입니다.
DNS 서버 보안을 강화하기 위해서는 최신 보안 패치를 적용하고, 취약점을 모니터링해 적시에 대응해야 합니다. 또한, 접근 제어 목록(ACL)을 설정해 불필요한 외부 접근을 차단하고, DNS 서버의 로그를 모니터링해 이상 활동 탐지 시스템 도입도 함께 고려하는 것이 좋습니다.
“홍대 어떻게 가요? 뉴진스 하입보이요.”
DNS에 평화가 깃들길 기원합니다.