Debian Etch에서 DNS 캐시 오염 방지를 위한 BIND9 패치 방법

버전 1.0
저자: Falko Timme

이 문서는 Debian Etch 시스템에서 BIND9 네임서버를 수정하여 DNS 캐시 오염에 더 이상 취약하지 않도록 하는 방법을 설명합니다.

이 문서는 어떠한 종류의 보증 없이 제공됩니다! 이것이 당신에게 작동할 것이라는 보장을 하지 않습니다!

1 BIND가 취약한지 확인하기

다음 명령어를 네임서버에 실행하여 취약한지 확인하십시오 (ns1.example.com을 자신의 네임서버 주소로 교체):

dig +short @ns1.example.com porttest.dns-oarc.net TXT

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 is POOR: 26 queries in 4.4 seconds from 1 ports with std dev 0.00”
mh1:~#

POOR는 BIND가 취약하다는 것을 나타냅니다. 이 경우 BIND를 반드시 패치해야 합니다.

전혀 응답이 없으면, 이는 DNS 서버가 재귀적 해석기가 아니라는 것을 의미합니다. 즉, 권한이 없는 도메인에 대한 쿼리에 응답하지 않습니다. 이 경우 캐시 오염에 취약하지 않지만, 여전히 BIND를 업데이트할 것을 강력히 권장합니다!

2 BIND 패치하기

이것은 패치라기보다는 업데이트입니다. 간단히 실행하십시오

apt-get install bind9 bind9-host

이 명령어는 Debian 저장소에서 업데이트된 BIND 패키지를 설치합니다.

그 후 /etc/bind/named.conf를 열고 옵션 섹션을 수정하십시오. 재귀적 해석기가 필요하지 않다면 (즉, 네임서버가 책임이 있는 도메인에 대해서만 쿼리에 응답해야 하는 경우) allow-recursion { none; };를 추가하십시오. 이렇게 하면 다른 도메인에 대한 캐싱이 꺼집니다. 추가해야 할 두 번째 줄은 dnssec-enable yes;입니다. 이는 BIND가 해커가 추측하기 어려운 임의의 포트에서 쿼리에 응답하도록 만듭니다 (1장에서의 dig 명령어에 대한 응답을 기억하십시오: […]26 queries in 4.4 seconds from 1 ports[…] - BIND는 단 하나의 포트에서만 응답하고 있었습니다…).

수정: Alan Clegg로부터 다음과 같은 이메일을 방금 받았습니다:

안녕하세요! 저는 당신의 글을 읽었습니다: https://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-debian-etch 그리고 몇 가지 의견이 있습니다. 우선, 이 글을 작성해 주셔서 감사합니다. 이 문제를 해결하기 위해 가능한 많은 사람들이 필요합니다. 둘째, 수정해야 할 작은 오류가 있습니다. 당신은 다음과 같이 말합니다: “추가해야 할 두 번째 줄은 dnssec-enable yes;입니다. 이는 BIND가 해커가 추측하기 어려운 임의의 포트에서 쿼리에 응답하도록 만듭니다” 사실, 이 줄은 질문에 “DO” (DNSSEC OK) 비트가 설정된 경우 DNSSEC 레코드로 응답하도록 서버를 활성화합니다. 사람들이 찾아야 할 것은 다음과 같은 문장입니다: query-source […] port XX; 여기서 XX는 이 시스템에서 쿼리를 보낼 고정 포트 번호입니다. 이는 BIND의 새로운 버전이 UDP 소스 포트를 무작위화하는 모든 것을 무효화합니다. 질문이 있으면 언제든지 이메일을 보내주십시오. Alan Clegg
인터넷 시스템 컨소시엄 (ISC)
교육 및 지원

vi /etc/bind/named.conf

| [...] options { pid-file "/var/run/bind/run/named.pid"; directory "/etc/bind"; auth-nxdomain no; allow-recursion { none; }; dnssec-enable yes; /* * 당신과 대화하고자 하는 네임서버 사이에 방화벽이 있다면, * 아래의 query-source 지시어의 주석을 해제해야 할 수도 있습니다. * 이전 버전의 BIND는 항상 포트 53을 사용하여 질문을 했지만, * BIND 8.1은 기본적으로 비특권 포트를 사용합니다. */ // query-source address * port 53; }; [...] |

BIND를 다시 시작하십시오:

/etc/init.d/bind9 restart

(ISPConfig를 사용하는 경우, 변경 사항이 ISPConfig에 의해 덮어씌워질 것입니다. 이를 방지하기 위해 /root/ispconfig/isp/conf/named.conf.master의 named.conf 템플릿 파일을 가져와 위와 같이 수정하고, 수정된 템플릿을 /root/ispconfig/isp/conf/customized_templates 디렉토리에 저장하십시오 => /root/ispconfig/isp/conf/customized_templates/named.conf.master. 또한 위와 같이 /etc/bind/named.conf도 수정하십시오.)

3 BIND 다시 확인하기

이제 1장에서의 쿼리를 다시 실행합니다:

dig +short @ns1.example.com porttest.dns-oarc.net TXT

모든 것이 잘 진행되었다면, 이제 POOR 대신 GOOD을 표시해야 하며, 단 하나의 포트만 사용하는 것이 아니라 여러 포트를 사용해야 합니다:

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 is GOOD: 26 queries in 4.4 seconds from 26 ports with std dev 20195.32”
mh1:~#

축하합니다, BIND를 방금 수정했습니다!

ISP의 네임서버에 대해 dig 명령어를 실행하여 그들의 네임서버가 여전히 취약한지 확인할 수도 있습니다. 만약 그렇다면, ISP에게 그들의 네임서버를 업데이트하도록 촉구해야 합니다!