시만텍 및 맥아피의 연구자들은 네트워크를 감염시키고 정체가 불명한 DHCP 서버를 생성하는 새로운 DNSChange 트로이목마를 발견했다고 합니다. 이 트로이목마가 설치되면 새로운 IP를 요청하는 네트워크 장비에 가짜 DHCP 패킷을 보내어 감염시킵니다.

DNSChange 트로이목마는 DNS 파밍 공격(Pharming Attack)으로 보입니다. 이 트로이목마는 시만텍에서 Trojan.Flush.M이라고 이름지어졌으며, 컴퓨터가 이 트로이목마에 감염되면 가자의 DHCP 서버를 생성합니다.
SANS 인터넷 스톰 센터에 따르면 이 트로이목마는 로컬 컴퓨터의 네트워크 설정에 있는 DNS 정보 또한 변경한다고 합니다.
12월 초에는 이 트로이목마가 널리 퍼져있지 않았지만, 공격의 특성상 성공시에는 꽤 영향을 미칠 것이라고 합니다.

트로이목마가 감염된 컴퓨터가 빠르거나 네트워크 대역폭이 충분하여 DHCP 패킷을 많이 전송할 수 있다면 다른 컴퓨터의 네트워크 구성을 쉽사리 변경할 수 있을 것이라고 시만텍의 엘리어 플로이오가 블로그에서 밝혔다. "정상적인 DHCP 서버와 가짜 DHCP 서버가 경쟁을 벌이게 되면 운이나 성능에 따라 승패가 결정될 수 있으며, 공격이 항상 성공하는 것은 아니라고 한다"

하여튼, 감염된 컴퓨터가 이기는 경우에는 가짜 DNS 서버로 요청을 우회하도록 네트워크의 다른 컴퓨터를 조정하게 됩니다. 감염되지 않은 컴퓨터에 로그온할 때에 사용자가 알 수 없는 상태에서 가짜 사이트로 방문하게 될 수 있습니다.

이 공격을 진단하기 위해서는 DHCP 서버가 아닌 컴퓨터에서 트래픽이 발생하는지 검사하는 방법을 추천합니다. 또한 SANS에 따르면 이 트로이목마는 85.255 네트워크 대역으로 DNS 설정을 변경하므로 85.255.112.0-85.255.127.255 구간을 차단하거나 모니터링하는 방법을 사용해도 됩니다.

reTweet
Posted by 문스랩닷컴
blog comments powered by Disqus

      메일 서버를 운영하는데 있어 가장 중요한 네트워크 부분이 바로 DNS입니다. DNS 구성상 가장 핵심적인 역할을 하는 부분이 바로 루트 DNS인데, 전세계적으로 모두 13대가 운영되고 있습니다. 물론, 국내에서는 이 루트 서버의 사본인 캐시 전용 서버가 2대 정도(?) 운영되고 있읍니다.

    최근 11월 초에 루트서버 중 L.ROOT-SERVERS.NET의 IP v4 주소를 기존의 198.32.64.12에서 199.7.83.42로 변경하였습니다.

    윈도우 2000이나 리눅스 기반의 DNS에서는 루트 서버의 목록을 hints 파일에 저장합니다. 따라서, 이 파일을 업데이트해야만 안정적인 DNS 서버 운영을 기할 수 있습니다. 윈도우 2000 서버의 DNS에서 루트 서버의 목록을 업데이트하는 방법은 다음과 같습니다.

    1. DNS 콘솔을 엽니다.

    2. 서버 이름을 선택하고 마우스 오른쪽 버튼을 눌러 등록정보를 선택합니다.

    3. 루트 참고 탭을 클릭하고 l.root-server.net을 선택합니다.

    4. 확인 버튼을 클릭하여 IP 주소가 바뀌는지 확인합니다.

    5. 확인 버튼을 눌러 창을 닫습니다.

    6. 서비스에서 DNS Server 서비스를 중지했다가 재시작합니다.


    참고로, 2004년 1월 18일에는 B 루트 서버의 IP 주소가 변경된 적이 있습니다. 운영하는 서버의 OS가 윈도우 2003 미만 인 경우에는 B 루트 서버도 IP 주소를 업데이트하는 것이 좋습니다.

    감사합니다.

    reTweet
    Posted by 문스랩닷컴
    blog comments powered by Disqus
      DNS! 인터넷에서 여러가지 서비스를 제공하기 위해 반드시 사용해야 하는 핵심적인 구성요소입니다. 방화벽이 있고 그 안에 DNS 서버가 위치하는 경우에는 DNS 서버를 게시(Publishing)해야 합니다.

      ISAServer.org에서는 DNS 게시에 관련된 자료를 연재하고 있습니다. 필요한 부분만 정리해서 올려 보겠습니다.

      목차

      I. DNS Advertiser 및 Resolver의 이해



      1. DNS Advertiser(공개된 DNS 서버)

      DNS 서버를 게시한다는 의미는 ISA 방화벽 뒷단에 위치한 내부 네트워크에 DNS 서버가 놓여 있다는 의미입니다. DNS 서버를 게시하는 목적은 방화벽의 보호 아래 외부 사용자(주로 인터넷)가 DNS 정보를 조회(이름풀이)할 수 있는 서비스를 제공하는 것입니다. 물론 DNS 서버는 자신이 등록한 도메인에 대한 정보만을 이름풀이하여 사용자에게 반환합니다.

      외부 사용자가 게시된 내부의 DNS 서버로 패킷이 어떻게 전달되는지 살펴 봅니다. 먼저 외부 사용자는 ISA 방화벽의 외부 인터페이스인 공인 IP로 이름풀이를 요청합니다. ISA 방화벽은 게시 규칙을 검토하여 이를 바탕으로 내부의 DNS 서버로 해당 정보를 전달합니다. 이제 DNS 서버는 자신에게 등록된 도메인의 정보를 조회하여 ISA 방화벽으로 반환합니다. 마지막으로 ISA 방화벽은 이 정보를 외부 사용자에게 반환합니다.

      그리고, DNS 서버의 역할 중에 하나가 바로 DNS 정보를 다른 DNS 서버로 부터 조회하여 이 값을 사용자에게 반환할 수 있다는 것입니다. DNS 서버는 자신이 등록한 DNS 정보에 대해서만 책임(Authoritative)이 있으며, 이 값을 정확히 반환하게 되어 있습니다. 하지만, 등록하지 않은 다른 도메인 이름에 대한 조회 요청이 들어오면 이 DNS 서버는 사용자를 대신하여 다른 DNS 서버로 조회 요청을 하여 해당 정보를 가져와 사용자에게 반환합니다. 즉, DNS 서버의 도메인 등록정보는 일반적으로 다른 DNS 서버에서 조회가 가능하고, 사용자 또는 DNS 서버를 관리하는 사람도 조회가 가능한 '도메인 정보를 공개한 DNS 서버'로 관리하게 됩니다. 이 서버를 영어로 DNS Advertiser라고 합니다.

      따라서, 이러한 공개된 서버에서는 회사 네트워크의 중요한 비밀이 담겨 있는 정보를 포함해서는 절대로 안됩니다. 만약 포함하는 경우에는 방화벽에서 DNS 조회(이름풀이)에 관련된 포트를 제한해야 할 수도 있습니다.

      2. DNS Resolver

      관리자의 관리 하에 도메인 이름에 대한 액세스를 공개적으로 허용하도록 DNS Advertiser를 사용하는 경우에는 내부 사용자의 이름풀이 요청은 ISA 방화벽을 통해 아웃바운드 DNS 액세스로 연결합니다. DNS에서 아웃바운드 액세스를 허용할 때 내부 클라이언트와 서버들은 인터넷 상의 도메인 이름을 이름풀이하여 실제로 액세스할 수 있게 됩니다. 예를 들어, 내부 사용자가 웹 브라우저를 통해 http://moonslab.com을 입력하면, moonslab.com 도메인의 정보를 가지고 있고 이를 요청한 클라이언트에게 이름풀이를 제공해야 하는 DNS 서버가 반드시 존재해야 합니다. 이러한 DNS 서버는 인터넷 상의 이름풀이 요청을 처리 또는 내부 네트워크 도메인의 이름풀이도 책임져야 할 수도 있습니다. 이러한 서버를 바로 DNS Resolver라고 하며, 주 목적은 인터넷 상의(외부) 도메인의 이름풀이를 제공하는 것입니다.

      명심해야 할 중요한 사항은 바로 이것입니다. 내부 사용자는 DNS advertiser를 사용하여 이름풀이를 사용할 수 없고, 외부 사용자들은 이름풀이를 위해 내부 DNS Resolver를 사용해서는 안된다는 것입니다. 물론 예외 사항은 VPN 네트워크에 관련된 경우입니다.

      3. DNS의 보안 강화

      DNS 서버를 게시할 때에는 가급적 DNS Advertiser로 게시해야 합니다. 즉, 인터넷 사용자가 내부의 게시된 서버로 이름풀이 요청을 하여 정보를 가져갈 수 있어야 합니다. 만약, 이렇게 하지 않는 경우에는 어느 누구도(심지어 내부 사용자도) 도메인 정보를 알 수 없습니다.

      DNS 서버는 결함 허용 등의 목적을 달성하기 위해 적어도 두 대의 DNS 서버를 두어야 하며, 가급적 네트워크가 다른 즉, 다른 서브넷에 위치하도록 하는 것이 좋습니다.

      그리고, 만약 DNS 서버 컴퓨터에 여러 개의 IP 주소가 할당되어 있고, 특히 내부 네트워크에서 DNS 쿼리를 공유하여 문제가 발생하는 경우라면 DNS 요청을 처리할 인터페이스(NIC)를 강제로 지정할 수 있습니다.
       
      사용자 삽입 이미지

      전달자 탭에서는 전달자 사용을 체크를 해제해야 합니다. 앞에서 설명했다시피, DNS advertiser는 DNS resolver 역할을 수행하도록 하길 원하지 않기 때문입니다. 특히, 전달자를 허용할 경우에는 nslookup 명령어를 통해 DNS 서버의 도메인에 해당하는 모든 정보를 나열하여 볼 수 있으므로 보안상 막아야 합니다.
      사용자 삽입 이미지

      고급 탭에서는 재귀를 사용 안함오염에 대하여 캐시 보안을 선택하는 것이 좋습니다. 
      사용자 삽입 이미지

      루트 참고 탭에서는 인터넷 상에서 운영 중인 루트 서버의 목록을 보여줍니다. 이러한 루트서버는 전세계적으로 13대가 운영되고 있으며, 그 외에는 캐시 서버로 국내에서 운영중입니다. 루트 서버는 DNS 서버가 재귀 호출을 할 때 사용됩니다. 하지만, 우리는 DNS advertiser가 재귀로 사용할 것이 아니므로 루트 서버의 목록을 모두 삭제합니다. 서버를 선택하고 제거 버튼을 눌러 모두 삭제합니다. 아래 그림은  기본적으로 등록된 상태 화면입니다.
      사용자 삽입 이미지

      지금까지 DNS Advertiser와 DNS Resolver에 대해 간략히 설명했습니다. DNS advertiser는 자신이 등록한 도메인 정보에 대한 이름풀이 응답만 제공해 주고, 그 도메인 정보에 대해서는 권한(authoritative)을 갑니다. DNS 서버를 게시하는 경우에는 대부분 DNS advertiser로 구성하게 됩니다. DNS Resolver는 인터넷 상의 호스트에 대한 이름풀이를 제공해 줍니다.

      다음 편에서는 DNS 아웃바운드 액세스에 대해 점더 자세히 알아 봅니다.


      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus
        사용자 삽입 이미지
        Windows 네트워크 환경에서 DNS는 가장 핵심적인 역할을 수행합니다. LongHorn 서버는 기존 DNS 서비스에 비해 다음과 같은 향상된 기능을 제공합니다.

        • 백그라운드 영역 로딩 - 백그라운드에서 영역 데이터를 로드하기 때문에, 많은 수의 DNS 영역을 관리하는 DNS 서버가 액티브 디렉터리 도메인 서비스(AD DS)에 저장된 경우에 좀 더 빨리 클라이언트의 쿼리에 응답할 수 있습니다.
        • IPv6을 지원합니다.
        • 읽기 전용 DC 지원 - RODC에서 읽기 전용 영역을 지원하는 DNS 서버 역할
        • 전역 단일 이름 - 롱혼 서버의 DNS 서버 서비스는 GlobalNames 영역이라는 새로운 영역 형식을 제공합니다.  전체 포리스트에 걸쳐 고유한 단일 이름을 유지할 수 있게 해줍니다. 이는 WINS를 사용할 필요가 없어진다는 의미입니다.
        출처: MS Tech-Net
        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus

          지난 4 13일경, Windows 2000/2003 Server 제품군에서 운영되는 DNS 서비스에 대한 RPC 원격 코드 실행 취약점이 발표되었습니다. 지난 자료에서도 언급했었지만, 현재 공식 패치는 제공되지 않은 상태이며, 대안으로 RPC 관련 레지스트 수정과 방화벽에서 해당 포트 범위(1025-5000)를 차단하는 방법이 소개되었습니다.

           
          하지만, 대안을 조치하지 않은 일부 서버 컴퓨터를 노린 새로운 익스플로잇이 발견되고 있다는 소식이 들려 오고 있습니다.

           
          이러한 공격을 위한 대부분의 패턴들은 TCP 1025번 포트에 집중되는 것으로 보여지고 있으며, 이를 통해 공격이 올 수 있다는 것을 예견할 수 있습니다. 참고로, TCP 1025 RPC 통신을 위해 가장 많이 시도되는 포트입니다.

           
          통상적인 서버의 트래픽을 살펴 보면, TCP 1025번은 초당 30회에서 최대 100회 정도까지 발생합니다. 하지만, 1400회부터 1500회 그리고 최대 8000회까지도 나타납니다.

           
          업무 특성상 패치되지 않은 DNS 서버를 운영하는 관리자는 이 점을 주목해야 할 것으로 생각됩니다.

          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus


            □ 개요

              o Windows DNS 서버 원격 관리를 위해 사용하는 RPC 모듈에 원격 코드 실행 취약점[1]이 발견되어 주의가 필요합니다.

                - 현재, MS社에서  해당 취약점에 대한 보안권고[2]를 발표(4/13)하였으며, 향후 패치를 배포할 예정입니다.

               ※ RPC(Remote Procedure Call) : 네트워크 상의 다른 컴퓨터에서 실행되고 있는

                     프로그램에 서비스를 요청하기 위해 사용되는 프로토콜


            □ 취약점이 있는 운영 체제

               - MS Windows 2000 Server SP4

               - MS Windows Server 2003 SP1

               - MS Windows Server 2003 SP2



            □ 해결방안

              o MS 보안권고에 따르면 취약점을 이용한 공격에 대응하기 위하여 크게 2가지 방법이 제안됨.

                 ※ MS사에서 패치가 발표되면 즉시 적용하기를 권고함.


            DNS 서버 시스템에서 레지스트리 조작을 통해 RPC를 이용한 원격관리기능을 정지

                  1. 시작 메뉴를 클릭하여  실행 창을 오픈한다.

                  2. 입력창에 Regedit를 입력하고 엔터를 누른다. 

                  3. 레지스트리 트리 창에서 다음 아래 레지스트리 항목으로 이동한다.

                      “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS
                       \Parameters”

                  4. 편집 메뉴에서  새로 만들기항목의  DWORD 값을 클릭한다.

                  5. 새 값 #1 이 생성되면 레지스트리 이름을  RpcProtocol으로 변경한다.

                  6. RpcProtocol항목을 더블 클릭하여 데이터 값 ‘4’를 입력한다.

                  7. DNS 서비스를 재시작한다.


            메모장과 같은 텍스트 편집기로 열어서, 다음 사항을 복사해 넣고, 확장자를 REG로 하여 저장하고, 해당 파일을 더블클릭하여 레지스트리에 등록하면 쉽게 가능합니다.

            Windows Registry Editor Version 5.00

            [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters]

            "RpcProtocol"=dword:00000004


            - 주의 사항

            RPC 를 사용하여 원격에서 DNS 서버를 관리하는 기능을 사용할 수 없게 된다. 즉, 원격에서 DNS 관리 콘솔을 연결할 수 없다. DNS 관리 콘솔을 이용하는 방법은 로컬로 이용하는 방법과 원격으로는 터미널 서비스등을 이용하는 방법으로만 가능하게 된다.

            DNS MMC 콘솔뿐만 아니라, DNSCMD.EXE 명령어, DNS WIM Provider에도 해당된다.



            방화벽에서 공격에 사용될 수 있는 1024-5000 포트를 차단

             방화벽이 없는 네트워크 환경에서는 IPSec을 사용하여 포트를 차단할 수 있습니다. 자세한 정보는 KB313190KB813878을 참고하기 바랍니다. 또한, NTFAQ의 IPSec을 통한 웹서비스 보안 정책-필터링(http://www.ntfaq.co.kr/3150), IPSec을 이용하여 특정 IP 및 트래픽 제어하기(http://www.ntfaq.co.kr/3112)을 참고하기 바랍니다.

            - 주의 사항

            포 트 차단으로 인해 다른 서버 서비스의 제공에 영향을 미칠 수 있으므로 적절한 포트 개방/차단이 필요합니다. 예를 들어, SQL Server 서비스와 터미널 서비스를 사용한다면, 1024-5000번 포트에서 1433과 3389 TCP 포트를 반드시 열어야 한다는 점을 주의해야 합니다. 서비스가 제대로 이루어지는 원격에서 한번 더 점검하길 추천합니다.




            □ 참고사이트

            [1] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1748

            [2] http://www.microsoft.com/technet/security/advisory/935964.mspx

            [3] http://www.krcert.or.kr/index.jsp

            reTweet
            Posted by 문스랩닷컴
            blog comments powered by Disqus
              TAG dns, RPC, 취약점

               DNS for ISA


              이 글은 isaserver.org에서 나온 글을 번역하여 정리한 것입니다. DNS는 Windows 2000에서부터 주목받기 시작했으며, 인터넷의 발달에 힘입어 가장 많이 사용하는 그리고 가장 많은 문제점을 가지고 있는 프로토콜이기도 합니다.

              이 글에서는 ISA Server를 구현하고자 하는 네트워크 상에서 사용가능한 DNS의 종류와 사설 공인 DNS의 구현 등 다양한 정보를 제공하고자 합니다.

              목차:


              1. 서문 및 용어 정리
              2. Windows 2000의 이름풀이
              3. 고정 IP
              4. DHCP
              5. ISA DNS Proxy
              6. DNS 구현시 고려사항
              7. 외부 공인 DNS
              8. ISA용 DNS
              9. Split DNS
              10. 내부 독립 DNS
              11. 다중 내부 DNS

              11. 다중 내부 DNS

              사용자 삽입 이미지


              위 그림은 외부 영역을 호스팅하는 DNS서버와 내부 영역을 호스팅하는 DNS 서버가 둘 다 ISA 서버 뒤에 위치한 그림이다.  이는 과히 편집증적인 시나리오로 이 Setup에서는 내부 DNS는 인터넷에서 볼 수 없다. 왜냐하면 EXT DNS 로 포워딩하지 않고는 인터넷 이름들을 풀이할 수 없기 때문이다. 모든 다른 시나리오에서는 ISA를 통해 내부 영역의 DNS 서버를 인터넷으로 액세스할 수 있게 해준다.

              ISA Setup :
              • Packet Filters :     DNS Lookup (UDP-53) out
              • Protocol Rules : DNS Lookup (UDP-53) out
              • DNS Publishing : EXT DNS 로 DNS 쿼리를 사용하는 DNS 서버 게시 규칙

              reTweet
              Posted by 문스랩닷컴
              blog comments powered by Disqus

                 DNS for ISA


                이 글은 isaserver.org에서 나온 글을 번역하여 정리한 것입니다. DNS는 Windows 2000에서부터 주목받기 시작했으며, 인터넷의 발달에 힘입어 가장 많이 사용하는 그리고 가장 많은 문제점을 가지고 있는 프로토콜이기도 합니다.

                이 글에서는 ISA Server를 구현하고자 하는 네트워크 상에서 사용가능한 DNS의 종류와 사설 공인 DNS의 구현 등 다양한 정보를 제공하고자 합니다.

                목차:


                1. 서문 및 용어 정리
                2. Windows 2000의 이름풀이
                3. 고정 IP
                4. DHCP
                5. ISA DNS Proxy
                6. DNS 구현시 고려사항
                7. 외부 공인 DNS
                8. ISA용 DNS
                9. Split DNS
                10. 내부 독립 DNS
                11. 다중 내부 DNS

                10. 내부 독립 DNS

                사용자 삽입 이미지


                여분(redundancy)를 위해 별도의 내부 DNS 서버를 가진 그림이다. W2K AD 환경에서 선택할만 한 시나리오로 DNS와 AD는 쉽게 공존할 수 있어 주 및 보조 AD가 주 및 보조 DNS 서버로 동작하게 할 수 있다. 내부 영역을 AD 통합으로 구축하면 주 및 보조 DNS 영역등이 필요없다.

                ISA Setup :
                • Packet Filters :     DNS Lookup (UDP-53) out
                • Protocol Rules : DNS Lookup (UDP-53) out
                • DNS Publishing : INT DNS01 그리고/또는 INT DNS02 로 DNS 쿼리를 사용하는 DNS 서버 게시 규칙


                reTweet
                Posted by 문스랩닷컴
                blog comments powered by Disqus

                   DNS for ISA


                  이 글은 isaserver.org에서 나온 글을 번역하여 정리한 것입니다. DNS는 Windows 2000에서부터 주목받기 시작했으며, 인터넷의 발달에 힘입어 가장 많이 사용하는 그리고 가장 많은 문제점을 가지고 있는 프로토콜이기도 합니다.

                  이 글에서는 ISA Server를 구현하고자 하는 네트워크 상에서 사용가능한 DNS의 종류와 사설 공인 DNS의 구현 등 다양한 정보를 제공하고자 합니다.

                  목차:


                  1. 서문 및 용어 정리
                  2. Windows 2000의 이름풀이
                  3. 고정 IP
                  4. DHCP
                  5. ISA DNS Proxy
                  6. DNS 구현시 고려사항
                  7. 외부 공인 DNS
                  8. ISA용 DNS
                  9. Split DNS
                  10. 내부 독립 DNS
                  11. 다중 내부 DNS

                  9. Split DNS

                  사용자 삽입 이미지

                  이 그림은 좀더 복잡하다. 하지만 좀더 유연한 시나리오로 분리된 내부 및 외부 DNS resolver를 사용하고 있다. 분리된 내부 및 외부 DNS 영역을 통해 여러분은 클라이언트에게 둘다 제공할 수 있다. “클라이언트 DNS#" 경로는 주어진 DNS 서버를 사용하기 위해 어떤 논리적 경로를 사용하는지 보여준다. 외부 DNS 서버를 ”전달자“로 구성하여 내부 DNS 서버가 클라이언트 DNS resolver로 제한할 수도 있다. 이는 클라이언트 설치를 간단히 하지만 외부 이름들도 쉽게 풀이할 수 있다. ISA Setup은 마찬가지 이다.

                  ISA Setup :
                  • Packet Filters :     DNS Lookup (UDP-53) out
                  • Protocol Rules : DNS Lookup (UDP-53) out
                  • DNS Publishing : INT DNS로 DNS 쿼리를 사용하는 DNS 서버 게시 규칙

                  reTweet
                  Posted by 문스랩닷컴
                  blog comments powered by Disqus

                     DNS for ISA


                    이 글은 isaserver.org에서 나온 글을 번역하여 정리한 것입니다. DNS는 Windows 2000에서부터 주목받기 시작했으며, 인터넷의 발달에 힘입어 가장 많이 사용하는 그리고 가장 많은 문제점을 가지고 있는 프로토콜이기도 합니다.

                    이 글에서는 ISA Server를 구현하고자 하는 네트워크 상에서 사용가능한 DNS의 종류와 사설 공인 DNS의 구현 등 다양한 정보를 제공하고자 합니다.

                    목차:


                    1. 서문 및 용어 정리
                    2. Windows 2000의 이름풀이
                    3. 고정 IP
                    4. DHCP
                    5. ISA DNS Proxy
                    6. DNS 구현시 고려사항
                    7. 외부 공인 DNS
                    8. ISA용 DNS
                    9. Split DNS
                    10. 내부 독립 DNS
                    11. 다중 내부 DNS

                    8. ISA용 DNS

                    사용자 삽입 이미지

                    ISA 서버를 사용하는 단일 DNS 서버 방안이다. 시나리오는 구현하기 쉬울 것으로 보이지만, 개념과 설치에는 다른 점이 꽤 있음을 알아 둬야 한다. ISA 서버는 1차 DNS 서버 주소를 “127.0.0.1”을 가지고 있는 것을 주의해야 한다. DNS 이름풀이에 로컬 서버를 사용하도록 서버의 DNS client 서비스에게 알려주는 것이다. 비록 ISP DNS 서버가 여기서는 보여지지 않았지만, 전달자를 사용하거나 2차 DNS 서버로 사용할 수 있다.

                    ISA Setup :
                    • Packet Filters :     DNS Lookup (UDP-53) out / in
                                                DNS 영역 전송 (TCP-53) out / in
                    • Protocol Rules : DNS Lookup (UDP-53) out
                    • DNS Publishing : 인바운드 패킷 필터를 통해.


                    reTweet
                    Posted by 문스랩닷컴
                    blog comments powered by Disqus


                      Web Analytics Blogs Directory