BIND 9 취약점 및 해결책 - 캐시 오염 방지를 위한 BIND 패치 (Fedora/CentOS)

저는 여러분 대부분이 BIND의 취약점에 대해 들어봤을 것이라고 확신합니다. Dan Kaminsky는 이달 초에 공격자가 모든 네임 서버를 손상시킬 수 있는 DNS의 대규모 다중 공급업체 문제를 발표했습니다 - 클라이언트도 마찬가지입니다.

저는 BIND 9를 운영하는 시스템 관리자가 이 취약점을 해결하는 데 사용할 수 있는 가장 빠른 솔루션 중 하나를 여러분과 공유하고자 합니다.

3일 간의 테스트와 제 DNS 서버를 가지고 놀면서, 제 문제를 해결하는 것처럼 보이는 무언가를 발견했고, 그래서 여러분과 공유하기로 결정했습니다.

이것이 정말 문제를 해결했는지는 확실하지 않지만, 저에게는 잘 작동했으며 테스트 결과도 훌륭합니다. 하지만 여러분의 제안과 의견은 언제나 환영합니다.

제가 발견한 것은 간단해 보일 수 있지만, Centos 4 또는 5와 Fedora 코어 시스템 이상에서 BIND 9를 운영하는 사람들에게만 적용됩니다… 저는 사무실의 모든 박스에서 테스트했습니다.

시작해 볼까요?

전제 조건 및 가정

방화벽(iptables NAT/PAT 또는 PIX)의 53번 포트가 무작위 포트 선택을 허용하는 방식으로 열려 있어야 합니다.
Centos 4 또는 5 또는 어떤 Fedora 코어 시스템에서 BIND 9를 실행해야 합니다.
BIND는 chrooted 모드에서 실행되어야 하며, 이는 필수 사항은 아니지만 모범 사례입니다.
/etc/named/named.conf 또는 /etc/named.conf 파일에서 재귀 쿼리를 비활성화하고, 자신의 네트워크만 재귀 요청을 허용하는 ACL을 추가해야 합니다. 이를 통해 시스템 관리자는 캐시 오염의 가능성을 자신의 알려진 네트워크로 줄일 수 있습니다.

acl "mynetworks" {
         127/8;  172.16.0.0/12;  10.0.0.0/8;  192.168.0.0/16

view "internal" {
         match-clients { mynetwork; };
         allow-query { mynetwork; };
         allow-recursion { mynetwork; };
         match-recursive-only yes;

view "external" {
         match-clients { any; };
         allow-query { any; };
         allow-recursion { none; };
         match-recursive-only no;

BIND 취약점 수정하기

첫 번째 단계는 시스템이 취약한지 확인하는 것입니다… 아래 명령어를 실행하여 ns1.youdomain.co.tz를 조직의 TLD 또는 ccTLD로 교체합니다.

dig +short @ns1.youdomain.co.tz 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.
“192.168.1.3는 POOR입니다: 26 쿼리 20.0초 동안 1개의 포트에서 std dev 0.00”

POOR —–> 확실히 해당 네임 서버 또는 시스템이 취약하다는 것을 나타내며, 물론 실행 중인 BIND 소프트웨어도 오래되어 패치가 필요합니다…

해결책

CentOS 또는 Fedora 시스템을 운영하는 경우…..yum을 사용하여 시스템을 패치할 수 있습니다. CentOS 5 개발자는 이미 BIND 소프트웨어에 대한 패치를 출시했으며 현재 버전은: bind-9.3.4-6.0.2.P1.el5_2입니다. P1은 패치된 패키지임을 나타냅니다.

패치 후 제 시스템에서 다음과 같은 결과를 얻었습니다..

rpm -q bind

bind-9.3.4-6.0.2.P1.el5_2 —-> 만약 여러분의 bind 버전이 패치되지 않았다면, 패치하세요.

최신 소프트웨어와 패치를 받으려면 다음을 수행해야 합니다.

yum update bind bind-chroot -y

named.conf 파일을 편집하고 다음을 추가해야 합니다. 저장하고 BIND를 다시 로드하세요.

 vi /etc/named.conf

options {
         directory "/var/named";
         allow-transfer {192.168.1.4 ;};
         query-source   address * port 53; ##이 줄을 주석 처리하거나 제거하세요.

무작위 포트 선택을 허용합니다. 이 매개변수가 named.conf 파일의 옵션 아래에서 활성화되어 있는 경우에만 이 작업을 수행하세요.

         dnssec-enable yes;                        ## DNS-SEC를 활성화하기 위해 이 옵션을 추가하세요.

위의 줄을 named.conf 파일에 추가하면 DNS-SEC가 활성화됩니다. DNS-SEC를 설정하되, DNS-SEC가 이 취약점에 대한 궁극적인 해결책이 아니라는 점을 기억하세요. **

BIND를 다시 로드하거나 재시작하세요.

/etc/init.d/named reload

그런 다음 다시 테스트하여 더 나은 결과를 얻는지 확인하세요.

dig +short @ns1.youdomain.co.tz 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.
“192.168.1.3는 GOOD입니다: 26 쿼리 19.6초 동안 26개의 포트에서 std dev 16515.27”

GOOD은 해당 네임 서버가 192.168.1.3에서 안전해 보인다는 것을 나타내지만, 나열된 포트가 명백한 패턴을 따르지 않는지 확인해야 합니다. 즉, 표준 편차가 16515.27인 포트… 그러나 테스트 시계가 (10000.00 std dev)인 경우 DNS 서버가 더 안전하며 클라이언트나 사용자는 걱정할 필요가 없습니다.

조직의 모든 DNS 서버에서 동일한 절차를 수행해야 합니다.