네임서버의 기본 보안 설정 - bind

=== bind의 로그파일 일부 ===
-----------------------------------------------------------------------------------------------

network unreachable resolving 'm90-134-80-80.cust.tele2.hr/NS/IN': 2a00:801:103:9::beef#53 

network unreachable resolving 'm90-134-80-80.cust.tele2.hr/NS/IN': 2a00:801:103:a::f00d#53 

network unreachable resolving 'm90-134-80-80.cust.tele2.hr/NS/IN': 2a00:801:103:b::f00d#53 

network unreachable resolving 'server.nordu.net/A/IN': 2001:948:4:2::19#53 

network unreachable resolving 'server.nordu.net/A/IN': 2001:948:4:1::66#53 

network unreachable resolving 'nn.uninett.no/A/IN': 2001:502:ad09::12#53 

network unreachable resolving 'nn.uninett.no/A/IN': 2001:67c:1010:1::53#53 

network unreachable resolving 'nn.uninett.no/A/IN': 2001:700:0:52d:158:38:8:133#53 

network unreachable resolving 'nn.uninett.no/A/IN': 2001:700:0:412f::40#53 

network unreachable resolving 'nn.uninett.no/A/IN': 2001:8c0:8200:1::2#53 

network unreachable resolving 'nn.uninett.no/AAAA/IN': 2001:502:ad09::12#53 

network unreachable resolving 'nn.uninett.no/AAAA/IN': 2001:700:0:503::aa:5302#53 

  위와 유사한 bind 로그가 보인다면 네임서버가 DNS 증폭공격(DNS Amplification DDoS Attack) 등에 참여하게 되어 본의 아닌게 다른 서버를 공격하고(또는 공격받고) 있다고 보면 된다. 실제로 매우 흔하게 발생한다.

  위의 예에서 모든 주소가 IPv6의 형태이므로 네트워크에 연결할 수 없다는 메시지는 서버(네임서버 - bind)에서 IPv6에 대한 네트워크가 구성되어 있지 않기 때문에 나타나는 것으로 보일 수 있다. 하지만 핵심은 네임서버를 OPEN DNS(recursion DNS)로 사용하고 있기 때문에 공격의 대상이나 도구로 이용되는 것이다. 별로 의미없는 작업일 수 있겠지만 bind의 IPv6를 disable 해보자. /etc/sysconfig/named에 OPTIONS="-4"를 한 줄 추가하는 것으로 아주 간단하다. 변경 내용을 적용시키려면 네임서버를 재시동해야한다.

=== /etc/sysconfig/named의 수정 ===
-----------------------------------------------------------------------------------------------

# BIND named process options

# ~~~~~~~~~~~~~~~~~~~~~~~~~~

#

# OPTIONS="whatever"     --  These additional options will be passed to named

#                            at startup. Don't add -t here, enable proper

#                            -chroot.service unit file.

#                            Use of parameter -c is not supported here. Extend

#                            systemd named*.service instead. For more

#                            information please read the following KB article:

#                            https://access.redhat.com/articles/2986001

#

# DISABLE_ZONE_CHECKING  --  By default, service file calls named-checkzone

#                            utility for every zone to ensure all zones are

#                            valid before named starts. If you set this option

#                            to 'yes' then service file doesn't perform those

#                            checks.

OPTIONS="-4"

  재시동 후에 network unreachable resolving 메시지가 사라졌다면 이제는 아래와 비슷한 그리고 기존보다 조금더 다양한  bind 로그를 볼 수 있을 것이다. 외부(주로 해외IP)로 부터의 dns 쿼리에 대한 상위 네임서버의 응답이 거부당하거나 무시당하는(응답을 받지 못하는) 경우에 발생하는 것들이 대부분이다.

=== IPv6를 disable 한 이후의 named log
----------------------------------------------------------------------------------------------

NOTIMP unexpected RCODE resolving 'www.brassbongs.com/ANY/IN': 35.173.43.182#53
NOTIMP unexpected RCODE resolving 'www.brassbongs.com/ANY/IN': 34.224.202.237#53
NOTIMP unexpected RCODE resolving 'www.brassbongs.com/ANY/IN': 34.202.185.163#53
NOTIMP unexpected RCODE resolving 'www.brassbongs.com/ANY/IN': 34.199.213.55#53
REFUSED unexpected RCODE resolving 'www.specialitycoffee.guide/ANY/IN': 109.169.6.66#53
REFUSED unexpected RCODE resolving 'www.specialitycoffee.guide/ANY/IN': 109.169.6.101#53
REFUSED unexpected RCODE resolving 'elevationinsurancegroup.com/ANY/IN': 216.239.32.100#53 
REFUSED unexpected RCODE resolving 'elevationinsurancegroup.com/ANY/IN': 216.239.34.100#53
SERVFAIL unexpected RCODE resolving 'a1133.gotoip55.com/ANY/IN': 219.138.102.198#53
SERVFAIL unexpected RCODE resolving 'a1133.gotoip55.com/ANY/IN': 211.149.230.100#53
SERVFAIL unexpected RCODE resolving 'a1133.gotoip55.com/ANY/IN': 61.188.37.172#53
SERVFAIL unexpected RCODE resolving 'a1133.gotoip55.com/ANY/IN': 118.123.249.114#53
dispatch 0x7fcbd32824b0: shutting down due to TCP receive error: 64.98.151.2#53: connection reset
dispatch 0x7fcbd32824b0: shutting down due to TCP receive error: 98.124.243.1#53: connection reset
dispatch 0x7fcbd32824b0: shutting down due to TCP receive error: 64.98.151.1#53: connection reset
dispatch 0x7fcbd32824b0: shutting down due to TCP receive error: 98.124.243.2#53: connection reset

  자체 네임서버를 구축하는 이유는 저마다 다르겠지만 테스트나 학습용이 아니고서는 굳이 OPEN DNS (recursion DNS) 방식의 운영으로 모든 dns 쿼리에 응답할 필요는 없다. 이렇게 운영하게 되면 당연한 얘기지만 특정 ip로 부터의 동일한 도메인에 대한 많은 쿼리나 혹은 다양한 ip로 부터의 동일한(혹은 다수의) 도메인에 대한 쿼리가 빈번하게 들어오는 일이  발생한다. 그리고 이러한 쿼리의 정도에 따라서 해당 ip를 차단해야 할지  혹은 그냥 둬야할지 고민할 수도 있다. 차단을 선택했다면 이번에는 수동으로 차단을 할 것인지 fail2ban 등을 이용해서 조건에 부합하는 것들을 필터링 할지를 결정해야 한다.(🐕🔊) 실제로 초당 100~700회 정도의 dns 쿼리를 받는 경우도 있지만 국내의 서버호스팅 업체를 이용한다면 그나마 안전할 수 있다. 대부분의 국내 업체들은 해외로부터의 무분별한 트래픽에 대해서 감시와 필터링 등의 적절한 대응을 하고 있기 때문이다. 물론 국내건 해외건 이러한 정책은 업체마다 다를 수 있으며 경험상 이러한 현상에는 해외보다는 국내 서버가 조금 안전한 것 같다.....

  그렇다면 이제는 네임서버가 자신이 관리는 도메인에만 응답하도록 설정해보자.  "recursion no"를 named.conf에 한 줄 추가하면 된다. 아주 간단하다.

=== named.conf의 수정===
-----------------------------------------------------------------------------------------------

options {

           ~생략~

           recursion no;

           ~생략~

};

  이제부터는 모르는(관리하고 있지 않은) dns 쿼리는 거부한다. 아래의 로그를 보자.

# systemctl status named -l

client @0x7fb58c23e5e0 122.228.19.81#47055 (progetc.com.br): query (cache) 'progetc.com.br/ANY/IN' denied

client @0x7fb58c23e5e0 122.228.19.81#36559 (publicatodo.com): query (cache) 'publicatodo.com/ANY/IN' denied

client @0x7fb58c23e5e0 122.228.19.81#33743 (pulseok.com): query (cache) 'pulseok.com/ANY/IN' denied

client @0x7fb58c1d9080 122.228.19.81#28367 (qualipot.men): query (cache) 'qualipot.men/ANY/IN' denied

client @0x7fb58c1d9080 122.228.19.81#25807 (qromemusic.com): query (cache) 'qromemusic.com/ANY/IN' denied

client @0x7fb58c23e5e0 122.228.19.81#20431 (20): query (cache) '20/ANY/IN' denied

client @0x7fb58c1f5fc0 122.228.19.81#15055 (10): query (cache) '10/ANY/IN' denied

client @0x7fb58c1e7820 122.228.19.81#7119 (10): query (cache) '10/ANY/IN' denied

client @0x7fb58c1e7820 122.228.19.81#4559 (realdealtrift.com): query (cache) 'realdealtrift.com/ANY/IN' denied

client @0x7fb58c1e7820 122.228.19.81#64718 (10): query (cache) '10/ANY/IN' denied

client @0x7fb58c1e7820 122.228.19.81#61902 (redtagdata.com): query (cache) 'redtagdata.com/ANY/IN' denied

client @0x7fb58c1e7820 122.228.19.81#59342 (reflexigul.co.il): query (cache) 'reflexigul.co.il/ANY/IN' denied

client @0x7fb58c1e7820 122.228.19.81#56782 (reignmo.icu): query (cache) 'reignmo.icu/ANY/IN' denied

  눈에 띄는 ip가 하나 보인다. named.conf의 logging 구문에 print-time yes;를 추가하면 각 로그의 발생 시간이 함께 출력된다. 쿼리 거부의 발생 빈도를 간단하게 알아볼 수 있는 방법이다. 지금 테스트한 결과는 평균 15초에 1회 정도이다. 결국 1분에 4회 정도의 dns 쿼리를 지속적으로 보낸다는 것인데 차단하기에도...그냥 두기에도 조금 애매한 상황이다. 일단은 조금 더 지켜보기로 하고 해당 ip를 abuseipdb.com에서 조회해 보았다. 결과는 아래와 같이 나온다.

https://www.abuseipdb.com/ 에서의 해당 ip 조회결과

  1월 27일의 마지막 리포트는 내가 한 것인데 이를 포함해서 총 33건의 리포트가 있다. 아직 네임서버의 설정이 끝나지 않았으므로 중요한 몇 가지 설정을 더 검토해 보자.

allow-transfer { options; };
  이 옵션은 zone 파일의 전송을 허용할지의 여부를 결정한다. 보통 두 개 이상의 네임서버를 운영하는 경우 서버간의  zone파일을 동기화 할 목적으로 사용한다. 주의할 점은 이 설정을 생략하면 모든 호스트로의 전송이 허용되는 것으로 서버에서 운영중인 도메인, 호스트, ip, 네임서버, 메일서버 등의 데이터(zone 파일의 내용)가 노출된다. 따라서 생략하지 말고 전송을 허용할 서버(2차 네임서버)의 ip주소를 명시하거나, 전송금지(none)로 설정하는 것이 바람직하다.

version "strings";
  bind의 버전이 노출되면 알려진 버전별 취약점으로 공격당할 수 있기 때문에 무조건 막아야 한다. " "안에 아무 문자(열)를 넣으면 외부에서 bind의 버전을 확인할 경우 " " 안의 문자가 출력된다. 이 구문을 생략하면 외부서버에서 간단하게(dig, nslookup 등을 통해서) bind의 버전을 알 수 있으므로 주의해야 한다.

recursion [yes | no];
  recursion 구문의 기본값은 yes이기 때문에, 이를 생략하게 되면 yes로 설정한 것과 동일하게 작동한다. yes로 설정하게 되면 dns 쿼리에 대해서 recursive query로 작동하며, no로 설정하게 되면 iterative query로 작동한다.

  recursive query는 네임서버가 자신이 모르는(cache에 있다면 이것으로 응답하겠지만) 도메인에 대해서 루트(root) 네임서버를 시작으로 몇 단계의 dns query를 거쳐서 해당 도메인의 주소를 얻어내고, 이를 클라이언트에게 돌려준다. 이에 반해서 iterative query는 자신이 관리하는 도메인이거나 cache 저장된 도메인이라면 응답하는 것 까지는 동일하지만 그렇지 않은 경우라면 그 이상의 상위 네임서버에 대한 query 작업은 일어나지 않는다. 한마디로 recursion이 일어나지 않는 것이다. 특별한 이유없이 caching name server로 사용하는 것이 아니라면 recursion의 옵션으로 no를 선택하는 것이 바람직하다. 이렇게 설정하면 상위 네임서버로의 query가 없으므로 dns cache의 업데이트도 발생하지 않는다. 따라서 DNS cache poisoning attacks(DNS 캐시 중독 공격)에 대해서도 보다 자유로울 수 있다.

allow-query-cache { options; };
  이 옵션은 cache에 접근할 수 있는 클라이언트를 제한한다. options에 사용할 수 있는 것은 cache로의 접근을 허용할 ip나  localhost, localnets 등이다. allow-query-cache 옵션은 recursion을 no로 설정했을 때에 기본값이 none이다. 또한 recursion을 yes로 설정했을 경우 allow-recursion을 설정한 경우와 그렇지 않은 경우에 따라서 allow-recursion의 기본 값이나 allow-query-cache의 기본값이 변하기도 한다. 네임서버를 recursive로 운영할 것인지 아니면 iterative하게 운영할 것인지가 핵심일 것이고 내부 캐시로의 접근 권한이나 이에 대한 설정은 큰 의미가 없다고 생각한다.(정말 개인적인 생각이다.) 단지 네임서버를 recursive하게 운영함으로써 발생하는 여러가지 위험상황이나 불필요한 트래픽까지 감수할 필요는 없다고 생각한다.

  지금까지의 내용을 바탕으로 named.conf를 수정하면 아래와 비슷하다.

options {
        ~ 생략 ~
        allow-query    { any; };
        allow-transfer { none; };
        allow-query-cache { any; };
        version "^___^";
        recursion no;
        ~ 생략 ~
};

logging {
        channel default_debug {
        file "data/named.run";
        severity dynamic;
        print-time yes;
        };
};        

  서버에 별 타격은 없지만 아직까지도 네임서버로의 공격이 발생하는지 살펴보자. 신경쓰고 싶지 않다면 해당 IP를 차단하자. # iptables -I INPUT -s 122.228.19.81 -j DROP  가급적이면 firewall-cmd를 사용하자. 

---

  DNS를 점검해 볼 수 있는 사이트 몇 군데를 소개한다.

https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/jsp/business/operate/dnsModify.jsp

한국인터넷정보센터(KRNIC)

 

https://dnsdumpster.com/

DNSdumpster.com - dns recon and research, find and lookup dns records

 

https://intodns.com/

intoDNS: checks DNS and mail servers health

  수상한 ip는 아래의 사이트에서 조회해 보자.
https://www.abuseipdb.com/

AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a time