Security_DNS 서버 해킹&보안

DNS 서버 보안 및 안전한 구축 방법

DNS(Domain Name System) 는 도메인 이름을 네트워크상의 IP 주소로 변환해 주는 매우 중요한 역할이다.

DNS의 동작 원리, 관련 보안 위협, 그리고 우분투 환경에서 안전하게 DNS 서버를 구축하는 방법에 대해 작성하였다.

DNS의 기본 동작 원리

DNS는 도메인 이름을 사람이 이해하기 쉬운 형태에서 컴퓨터가 통신에 필요한 숫자 형태의 IP 주소로 변환하는 역할

이 과정은 다음과 같은 단계로 이루어진다:

DNS 기본 동작

  1. 로컬 DNS 서버 요청
    사용자가 웹 브라우저에 도메인을 입력하면, 먼저 로컬 네트워크의 DNS 서버(보통 인터넷 서비스 제공업체(ISP)에서 운영하는 서버)에 질의가 전달한다.
  2. 캐시 확인
    로컬 DNS 서버는 이전에 조회한 결과를 캐시에 저장하고 있음. 캐시에 해당 도메인의 IP 정보가 있으면, 바로 응답하여 빠른 접속을 지원한다.
  3. 계층적 질의
    캐시에 정보가 없다면, 로컬 DNS 서버는 상위 계층으로 질의를 전달한다.
    • 루트 DNS 서버: 도메인 이름의 최상위 정보를 제공
    • TLD DNS 서버: 예를 들어, .com, .net 등과 같이 도메인의 최종 네임서버 정보를 확인
    • 권한 있는 네임서버: 최종적으로 도메인에 할당된 IP 주소 정보를 응답
  4. 최종 응답
    로컬 DNS 서버는 획득한 IP 정보를 캐시에 저장한 후, 클라이언트에게 전달하여 사용자가 해당 웹사이트에 접속할 수 있도록 한다.

 

DNS 공격의 유형

DNS는 특성상 여러 보안 취약점에 노출될 수 있다.

대표적인 공격 유형은 DNS 스푸핑(또는 캐시 포이즈닝)DNS 하이재킹이다.

DNS 스푸핑 (DNS 캐시 포이즈닝)

  • 공격 방식:
    네트워크 상에서 DNS 질의 응답 과정에 개입하여, 정상적인 DNS 응답 대신 잘못된(위조된) 응답을 전달한다.
    이로 인해 로컬 DNS 서버의 캐시나 클라이언트가 받는 응답에 잘못된 IP 주소가 저장되어, 사용자가 의도한 사이트 대신 공격자가 조작한 사이트로 연결될 수 있다.
  • 특징:
    1. 일시적인 효과: 공격자가 DNS 응답 패킷을 조작하여 단기간에 잘못된 정보를 주입한다.
    2. 주로 패킷 변조나 응답 위조를 통해 수행된다.
    3. 공격 대상은 DNS 질의 응답 과정이나 캐시이다.

DNS 하이재킹

  • 공격 방식:
    도메인에 연결된 IP 주소 정보를 직접 변경하거나, DNS 서버의 설정을 변조하여 도메인과 연결된 IP 주소를 공격자가 원하는 악의적인 IP로 변경한다. 이는 도메인의 네임서버 설정이나 호스트 파일, 또는 라우터 등에서 발생할 수 있다.
  • 특징: 
    1. 한 번 설정이 변경되면, 수정 전까지 계속 잘못된 IP 정보가 사용된다.
    2. 공격자가 도메인이나 내부 네트워크의 설정 정보를 무단 변경하여, 외부에서는 정상적으로 보이더라도 내부 네트워크나 특정 환경에서는 악의적인 서버로 연결될 수 있다.
    3. 공격 대상은 DNS 서버의 설정 정보도메인 등록 정보다.

 

안전한 DNS 서버 구축 실습

1. 준비: BIND9 패키지 설치

먼저, DNS 서비스에 많이 사용되는 BIND9와 관련 유틸리티(bind9utils)를 설치한다. 

sudo apt update
sudo apt install bind9 bind9utils

2. BIND9 기본 환경 설정

named.conf 파일 설정

BIND9는 /etc/bind/named.conf 파일을 통해 기본 환경을 구성한다.

이 파일에서는 서버의 기본 설정, include되는 추가 설정 파일들, 로깅, 액세스 제어 등이 정의되어 있다.
※ 이 파일을 수정할 때는 항상 원본 백업을 남겨두는 것이 좋다.

 

named.conf.options 파일 설정

DNS 서비스의 세부 옵션은 /etc/bind/named.conf.options 파일에서 설정한다.

  • allow-query: 모든 호스트에서 질의가 가능하도록 any를 지정하여 외부에서의 요청을 허용
  • allow-transfer: 추후 Slave DNS 서버와의 데이터 동기화를 위해 zone 정보를 조회, 제공할 수 있도록 허용
  • recursion: DNS 서버가 클라이언트의 재귀적 질의를 처리할 수 있도록 설정
options {
    directory "/var/cache/bind";

    // 모든 호스트에서 질의를 허용
    allow-query { any; };

    // Slave 서버와의 zone 전송 허용 (필요 시 특정 IP 주소로 제한)
    allow-transfer { any; };

    // 재귀적 질의 허용 (일반적으로 내부 네트워크에만 허용하는 것이 안전)
    recursion yes;

    // 기타 필요한 옵션들...
};

3. Zone 파일 구성

DNS 서버에 도메인 등록 정보를 제공하려면 zone 파일을 생성해야 한다.

일반적으로 정방향(zone file for forward lookup)과 역방향(zone file for reverse lookup) 두 가지 zone 파일을 설정한다.

 

3-1. 정방향 Zone 파일 설정

정방향 zone 파일은 도메인 이름을 IP 주소로 매핑하는 정보를 담고 있다.

보통 파일 상단에는 TTL(Time-To-Live), 시리얼(serial), 새로고침(refresh) 등의 정보를 설정한다.
예를 들어, dnstest라는 도메인을 추가하고, 해당 도메인의 nameserver(ns)를 지정하는 방식은 다음과 같습니다.

$TTL    86400
@       IN      SOA     ns.example.com. admin.example.com. (
                              2025020701 ; Serial (YYYYMMDDNN)
                              3600       ; Refresh
                              1800       ; Retry
                              604800     ; Expire
                              86400 )    ; Minimum TTL

; Nameserver 지정
        IN      NS      ns.example.com.

; 도메인에 해당하는 A 레코드 추가
ns      IN      A       192.0.2.1
www     IN      A       192.0.2.2

팁: 시리얼 번호는 파일이 수정될 때마다 증가시켜야 하며, 일반적으로 YYYYMMDDNN 형식을 사용한다.

 

3-2. 역방향 Zone 파일 설정

역방향 zone 파일은 IP 주소를 도메인 이름으로 매핑하는 정보를 담는다.

정방향 zone 파일과 유사한 방식으로 작성되며, IP 주소의 마지막 옥텟을 기준으로 PTR 레코드를 설정한다.

$TTL    86400
@       IN      SOA     ns.example.com. admin.example.com. (
                              2025020701 ; Serial
                              3600       ; Refresh
                              1800       ; Retry
                              604800     ; Expire
                              86400 )    ; Minimum TTL

; Nameserver 지정
        IN      NS      ns.example.com.

; PTR 레코드 설정: 192.0.2.2 -> www.example.com.
2       IN      PTR     www.example.com.
1       IN      PTR     ns.example.com.

 

3-3. external-zones 파일에 zone 정보 등록

여러 zone 파일을 관리하기 위해 external-zones와 같이 별도의 파일에 정방향 및 역방향 zone 설정을 모아둘 수 있다.

이 파일에는 각 도메인(zone)과 해당 파일의 경로를 등록하여 관리한다.

zone "dnstest.example.com" {
    type master;   # 이 서버가 해당 도메인(zone)의 주 서버(master)임을 나타냄
    file "/etc/bind/zones/db.dnstest";
};

zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.0.2";
};

이 설정은 BIND 서버에게 "dnstest.example.com 도메인의 DNS 기록은 /etc/bind/zones/db.dnstest 파일에 있고,

192.0.2.x IP 주소에 대한 역방향 조회는 /etc/bind/zones/db.192.0.2 파일에서 확인해"라고 알려주는 역할을 함.


4. 설정 확인 및 서비스 재시작

설정 파일을 수정한 후에는 문법 오류가 없는지 확인해야 한다.

sudo named-checkconf

오류가 없다면 BIND 서비스를 재시작하여 변경 사항을 적용한다.

sudo systemctl restart bind9

또한, DNS 서버가 정상 동작하는지 확인하기 위해 dig 명령어를 사용하여 DNS Lookup 테스트를 진행한다.

dig @<DNS 서버 주소> dnstest.example.com
 

정상적인 응답이 돌아오면, 설정이 제대로 완료된 것이다.


5. DNS 보안 강화: DNSSEC

DNSSEC(DNS Security Extensions)은 DNS 캐시 포이즈닝과 같은 공격으로부터 도메인 정보를 보호하기 위한 보안 확장 표준 프로토콜이다.

  • 전자 서명:
    도메인 zone 파일에 전자 서명을 추가하여, 해당 정보가 위변조되지 않았음을 보장
  • 응답 검증:
    클라이언트나 상위 DNS 서버는 전자 서명을 검증하여, 응답 데이터가 신뢰할 수 있는지를 확인

DNSSEC를 적용하면 공격자가 DNS 응답을 위조하더라도, 전자 서명 검증 과정을 통해 잘못된 응답을 식별할 수 있으므로 보다 안전한 DNS 서비스를 운영할 수 있다.

참고: DNSSEC를 활성화하려면 추가적인 키 생성, 서명 작업 및 설정 파일 수정이 필요하다.
테스트 환경에서 충분히 테스트한 후 프로덕션 환경에 적용하는 것이 좋다.


결론

DNS는 인터넷의 핵심 인프라로서, 그 안전성은 전체 네트워크 보안에 큰 영향을 미친다.

  • DNS 스푸핑DNS 하이재킹 같은 공격은 사용자를 악의적인 사이트로 유도하거나 서비스 거부 상태에 빠뜨릴 수 있으므로,
  • DNSSEC와 같은 보안 확장 기술, 암호화된 DNS 프로토콜 도입, 그리고 올바른 서버 설정과 관리가 필수적이다.

'Security' 카테고리의 다른 글

Security_리눅스 서버 백업 & 복구  (0) 2025.02.11
Security_서버 침입 탐지 시스템  (1) 2025.02.10
Security_메일 서버 보안  (1) 2025.02.04
Security_ 파일 공유 서버 해킹  (0) 2025.01.23
Security_FTP 해킹  (0) 2025.01.23