การทำให้ดีเอ็นเอสเซิร์ฟเวอร์ทำงานอย่างปลอดภัย - การทำให้ดีเอ็นเอสเซิร์ฟเวอร์ทำงานอย่างปลอดภัย นิยาย การทำให้ดีเอ็นเอสเซิร์ฟเวอร์ทำงานอย่างปลอดภัย : Dek-D.com - Writer
    มีสาระ > ความรู้กลเม็ด เทคนิค ฯลฯ

    การทำให้ดีเอ็นเอสเซิร์ฟเวอร์ทำงานอย่างปลอดภัย

    โดย ปากกาหิมะสีขาว

    การติดต่อดังกล่าวมีความเป็นไปได้สูงที่จะนำมาซึ่งปัญหาการบุกรุกหลายรูปแบบ เช่น ผู้บุกรุกสามารถทำการจู่โจมที่เรียกกันว่าดีโอเอส (DOS = Denial of Service Attack)

    ผู้เข้าชมรวม

    470

    ผู้เข้าชมเดือนนี้

    0

    ผู้เข้าชมรวม


    470

    ความคิดเห็น


    0

    คนติดตาม


    0
    เรื่องสั้น
    อัปเดตล่าสุด :  9 มิ.ย. 49 / 19:09 น.
    แชร์ไปยังเฟซบุ๊ก แชร์ไปยังทวิตเตอร์ แชร์ไปยังอีเมล คัดลอกลิงก์ คัดลอก Embed


    ข้อมูลเบื้องต้นของเรื่องนี้

    เนื้อเรื่อง

    bookmark

      ตั้งค่าการอ่าน

      ค่าเริ่มต้น

      • เลื่อนอัตโนมัติ

        ดีเอ็นเอสเซิร์ฟเวอร์หรือเรียกอีกอย่างว่าเนมเซิร์ฟเวอร์โดยทั่วไปจะมีการติดต่อเชื่อมโยงออกไปสู่อินเทอร์เน็ต การติดต่อดังกล่าวมีความเป็นไปได้สูงที่จะนำมาซึ่งปัญหาการบุกรุกหลายรูปแบบ เช่น ผู้บุกรุกสามารถทำการจู่โจมที่เรียกกันว่าดีโอเอส (DOS = Denial of Service Attack) เพื่อทำให้ดีเอ็นเอสเซิร์ฟเวอร์ของเราไม่สามารถให้บริการได้ การจู่โจมที่เรียกว่า Spoofing Attack  ซึ่งเป็นผลให้ดีเอ็นเอสเซิร์ฟเวอร์ (จะขอเรียกสั้น ๆ ว่าดีเอ็นเอสจากนี้ไป) เก็บค่า IP Address  ที่ผิดไปจากค่าที่แท้จริง ซึ่งเมื่อมีการนำค่าดังกล่าวไปใช้งาน จะทำให้ผู้ใช้กำลังเข้าถึงเครื่องที่ใช้ IP Address หนึ่งที่ไม่ใช้ IP Address ที่แท้จริง ให้ผู้อ่านลองนึกดูถึงสถานการณ์ที่หากผู้อ่านคีย์ http://www.amazon.com เข้าไปทางเว็ปเบราเซอร์แล้วผลที่สุดปลายทางของการสื่อสารไม่ได้เป็น IP Address ของเว็ปเซิร์ฟเวอร์ของอเมซอน แต่กลับกลายเป็น IP Address ของผู้บุกรุกและให้ลองคิดต่อไปว่า หากผู้อ่านกำลังซื้อหนังสือกับอเมซอนด้วยหมายเลขบัตรเครดิตของท่าน อะไรจะเกิดขึ้น

        การป้องกันดีเอ็นเอสของเราสามารถทำได้หลายวิธี เช่น

        • การทำให้ Transaction ของดีเอ็นเอส มีความปลอดภัย คำว่า Transaction  หมายถึง ข้อความหนึ่ง ๆ ที่ใช้ในการสื่อสารระหว่างดีเอ็นเอสกับผู้สอบถามซึ่งปกติจะเป็นคำถาม (queries) คำตอบ (response) หรือข้อความอื่น ๆ ที่ดีเอ็นเอสส่งไปมานั่นเอง
        • การปฏิเสธไม่ตอบคำถามบางประเภทที่ถามมา
        • การไม่อนุญาตให้ทำ Zone Transfer (Zone หรือโซนโดยทั่วไปจะหมายถึง อาณาบริเวณของเครือข่ายที่อยู่ภายใต้การบริหารและจัดการขององค์กรแห่งหนึ่ง เช่น โซน nectec.or.th จะอยู่ภายใต้การดูแลของเนคเทค เป็นต้น นอกจากนั้นแล้ว โซนยังหมายถึงกลุ่มของเครื่องที่จัดให้อยู่ในกลุ่มเดียวกันซึ่งอาจจะไม่ได้ตั้งอยู่ในบริเวณหรือพื้นที่เดียวกันก็ได้ ทั้งนี้เพื่อการบริหารและจัดการโดยดีเอ็นเอส) ซึ่งก็คือการไม่อนุญาตให้ทำการโอนย้ายข้อมูลที่อยู่ในโซนหนึ่ง ๆ นั่นเอง

        ในบทความนี้จะได้กล่าวถึงการสร้างความปลอดภัยให้กับดีเอ็นเอสโดยวิธีการเหล่านี้ บทความจะแบ่งออกเป็น 2 ตอน ตอนที่ 1 นี้จะเริ่มต้นจากการแนะนำคอนเซ็ปต์การใช้ลายเซ็นต์กำกับไปกับ Transaction เพื่อให้ Transaction มีความปลอดภัยสูงในหัวข้อที่ 1  ถัดมาในหัวข้อที่ 2 คือรายละเอียดของเครื่องดีเอ็นเอสและไฟล์คอนฟิกที่จะใช้ในการทดสอบตลอดบทความนี้ทั้งสองตอน และหัวข้อสุดท้ายที่ 3 จะแสดงวิธีการต่าง ๆ ที่จะทำให้ดีเอ็นเอสทำงานอย่างปลอดภัย ซึ่งในตอนที่ 1 นี้จะประกอบไปด้วยการจำกัดเวอร์ชั่นของดีเอ็นเอส  การจำกัดการสอบถาม และการป้องกันการทำ Zone Transfer  ส่วนในตอนที่ 2 ซึ่งเป็นตอนจบในคราวถัดไปจะประกอบไปด้วยวิธีการต่าง ๆ ที่เหลือที่จะทำให้ดีเอ็นเอสทำงานอย่างปลอดภัย ได้แก่ การสตาร์ทการทำงานของดีเอ็นเอสโดยการจำกัดสิทธิ์ให้น้อยที่สุด และการแบ่งดีเอ็นเอสแยกตามหน้าที่การทำงาน 

        บทความนี้ได้รับแรงจูงใจจากหนังสือ DNS and BIND [1] ในบทเรื่อง DNS Security ซึ่งเมื่ออ่านแล้ว ยังรู้สึกว่าน่าจะอธิบายให้ชัดเจนกว่าที่เป็นอยู่ในหนังสือได้ พร้อมทั้งควรมีตัวอย่างการทดสอบตามสคริปต์ตามที่นำเสนอในหนังสือเพื่อความเข้าใจได้ดีขึ้นของผู้อ่าน จึงเกิดเป็นบทความนี้ขึ้นมา

        ตลอดบทความนี้เมื่อกล่าวถึงคำว่า Bind ส่วนใหญ่จะหมายถึงตัวซอฟต์แวร์ของดีเอ็นเอสนั่นเอง รวมทั้งตัวอย่างทั้งหมดที่ใช้ในการอธิบายในบทความนี้จะสามารถใช้ได้กับ Bind ตั้งแต่เวอร์ชั่น 9 เป็นต้นไป ในการทำความเข้าใจเนื้อหาในบทความนี้ ผู้อ่านควรมีความคุ้นเคยกับคอนเซ็ปต์ของดีเอ็นเอสและวิธีการคอนฟิกดีพอสมควร จึงจะทำให้เข้าใจเนื้อหาได้ง่าย

        1. TSIG

        TSIG หรือ Transaction Signature หมายถึง ในการทำให้ Transaction ของดีเอ็นเอสมีความ        ปลอดภัย วิธีการหนึ่งที่เราสามารถทำได้คือ การใช้ลายเซ็นต์อิเล็กทรอนิกส์ (Digital Signature) กำกับไปกับ Transaction (คำถาม/คำตอบ/ข้อความอื่น ๆ) ที่ส่งไปมาระหว่างดีเอ็นเอสกับผู้สอบถาม ลายเซ็นต์อิเล็กทรอนิกส์ปกติจะเป็นสิ่งที่เฉพาะตัวและโดยปกติจะปลอมแปลงไม่ได้ (เช่นเดียวกับลายเซ็นต์ที่เราเซ็นต์อยู่ในชีวิตประจำวันของเรา) ในการใช้ลายเซ็นต์อิเล็กทรอนิกส์ปกติแล้วผู้ใช้จะต้องมีคีย์เพื่อเอาไว้ใช้ในการเซ็นต์ชื่อ และผู้ใช้จะต้องเก็บคีย์นี้ไว้เป็นความลับ ดังนั้นจะเห็นได้ว่าด้วยวิธีการ TSIG ข้อความที่ส่งไปมาระหว่างดีเอ็นเอสจึงปลอมแปลงไม่ได้

        TSIG ใช้แฮ็ชฟังก์ชั่นแบบ One-way (จะอธิบายฟังก์ชั่นนี้เพิ่มเติมข้างล่าง) ซึ่งใช้ในการตรวจสอบข้อความที่ได้รับว่าเป็นของแท้หรือไม่ รวมทั้งการตรวจสอบทางด้านความสมบูรณ์ของข้อความ (Integrity) ว่าถูกเปลี่ยนแปลงระหว่างทางหรือไม่ ฟังก์ชั่นนี้จะรับเอาข้อความที่จะส่งออกไปโดยดีเอ็นเอสที่มีขนาดเท่าไรก็ได้ร่วมกับฟิลด์ข้อมูลอีกจำนวนหนึ่ง เช่น ฟิลด์เวลา เป็นอินพุท และสร้างเอ้าท์พุทเป็นค่าแฮ็ช (Hash Value) ที่มีขนาดคงที่ เช่น ขนาด 128 บิต เป็นต้น ค่าเอ้าท์พุทที่ได้นี้ เรียกกันว่า TSIG Record จะถูกส่งออกไปพร้อมกับตัวข้อความตั้งต้นนั้น

        ลักษณะเด่นของฟังก์ชั่น One-way คือ แต่ละบิตของค่าแฮ็ซ (ที่ถูกสร้างขึ้นมา) จะขึ้นอยู่กับ ทุก ๆ บิตของอินพุท (ข้อความ) กล่าวคือ การเปลี่ยนแปลงแม้กระทั่งบิตเดียวของอินพุทจะทำให้ค่าแฮ็ชที่เป็นผลลัพธ์เปลี่ยนแปลงไปอย่างมากมายจนไม่สามารถคาดเดาได้ ดังนั้นจึงเป็นไปไม่ได้ในทางการคำนวณที่จะคำนวณย้อนกลับไปหาค่าอินพุทตั้งต้น ถึงแม้ว่าเราจะทราบค่าแฮ็ชค่าหนึ่งก็ตาม และนั่นเป็นสาเหตุที่เราเรียกฟังก์ชั่นนี้ว่า One-way เพราะเราไม่สามารถคำนวณจากค่าเอ้าท์พุทย้อนกลับไปได้หาค่าอินพุทตั้งต้นได้นั่นเอง

        TSIG ใช้ฟังก์ชั่น One-way ที่อยู่ในประเภท MD5 ที่เรียกว่า HMAC-MD5 ซึ่งในการคำนวณค่าเอ้าท์พุทจำเป็นต้องใช้ทั้งข้อความและคีย์ประกอบเข้าด้วยกัน ในการตรวจสอบว่าข้อความที่ได้รับมีความสมบูรณ์หรือไม่ ผู้รับจะใช้คีย์ตัวเดียวกันกับผู้ส่งเพื่อทำการคำนวณค่าเอ้าท์พุทออกมา ดังนั้นหากข้อความและคีย์เหมือนกันในทั้งสองฝั่งของผู้รับและผู้ส่ง ค่าเอ้าท์พุทหรือ TSIG Record เมื่อคำนวณที่ปลายทางฝั่งผู้รับย่อมต้องเหมือนกับค่าที่คำนวณที่ต้นทางฝั่งผู้ส่ง

        ค่า TSIG Record เมื่อไปถึงที่ปลายทาง หลังจากที่ถูกใช้เพื่อตรวจสอบข้อความที่ได้รับว่าเป็นของแท้และถูกเปลี่ยนแปลงมาหรือไม่ ก็จะถูกกำจัดทิ้งไป

        TSIG สามารถนำมาใช้งานได้กับการทำ Zone Transfer และ Dynamic Update  (ซึ่งก็คือการส่งข้อความไปมาระหว่างผู้ส่งและผู้รับ) เพื่อให้ข้อความที่ส่งไปมาระหว่างผู้ส่งและผู้รับมีความปลอดภัยสูง ไม่สามารถปลอมแปลงได้

        1.1 การคอนฟิก TSIG   

        ในการใช้งาน TSIG ผู้ใช้ (ผู้ดูแลระบบ) จำเป็นต้องคอนฟิกคีย์ในทั้งสองฝั่งของการสื่อสารทั้งฝั่งผู้รับและผู้ส่ง อาทิ ถ้าเราต้องการให้การทำ Zone Transfer สำหรับโดเมน iss.th (ซึ่งเป็นชื่อโดเมนสมมติ) มีความปลอดภัยสูงระหว่างดีเอ็นเอสหลัก (Primary DNS Server) และดีเอ็นเอสรอง (Slave DNS Server) ให้ทำการคอนฟิกดีเอ็นเอสทั้งสองให้ใช้คีย์ร่วมกันดังนี้

        key ns1-ns2 {
        algorithm       hmac-md5;
        secret " UhflICLxcwBlAzlqQHiW2A==";
        };

        ค่าที่ตามหลังคำสั่ง key คือชื่อของคีย์ ข้อมูลจาก RFC (Request for Comment) สำหรับ TSIG ได้แนะนำไว้ว่าให้ตั้งชื่อคีย์ตามชื่อของเครื่องดีเอ็นเอสที่ต้องการใช้คีย์นั้น เช่น ในที่นี้เครื่องดีเอ็นเอส ns1.iss.th และ ns2.iss.th ต้องการใช้ TSIG จึงตั้งชื่อคีย์เป็น ns1-ns2.iss.th  แต่เพื่อความสั้นและกระชับเราขอตั้งชื่อคีย์นี้เป็นเพียง ns1-ns2  RFC ยังได้แนะนำเพิ่มเติมว่าในแต่ละคู่ของเครื่องดีเอ็นเอสที่ต้องการใช้ TSIG ให้กำหนดคีย์ขึ้นมาใช้งานโดย 1 คีย์ต่อ 1 คู่ดีเอ็นเอส

        ในการสร้างคีย์และกำหนดชื่อคีย์ ให้ใช้โปรแกรม dnssec-keygen เช่น

        # /usr/sbin/dnssec-keygen -a HMAC-MD5 -b 128 -n HOST ns1-ns2

        Kns1-ns2.+157+18565

        ออฟชั่น –a ใช้กำหนดชื่อของแฮ็ชฟังก์ชั่นที่ต้องการใช้งานร่วมกับคีย์ที่จะสร้างขึ้นมา –b ใช้กำหนดความยาวของคีย์เป็นจำนวนบิตซึ่งในที่นี้คือ 128 บิต และ –n HOST ใช้กำหนดชื่อของคีย์  โปรแกรม      dnssec-keygen จะทำการสร้างไฟล์ 2 ไฟล์ที่ประกอบไปด้วยคีย์ลงในไดเร็คทอรี่ปัจจุบัน ในรูปคำสั่งข้างบน Kns1-ns2.+157+18565 คือชื่อไฟล์ที่ dnssec-keygen สร้างขึ้นมาซึ่งประกอบไปด้วย 2 ไฟล์ดังนี้

        Kns1-ns2.+157+18565.key

        Kns1-ns2.+157+18565.private

        ข้อมูลที่อยู่ในไฟล์ทั้งสองจะมีลักษณะคล้าย ๆ กัน และจะมีคีย์ปรากฏร่วมอยู่ด้วยดังนี้

        ไฟล์ Kns1-ns2.+157+18565.key จะประกอบไปด้วยบรรทัด

        ns1-ns2. IN KEY 512 3 157 UhflICLxcwBlAzlqQHiW2A==

        และไฟล์ Kns1-ns2.+157+18565.private จะประกอบไปด้วยบรรทัด

        Private-key-format: v1.2

        Algorithm: 157 (HMAC_MD5)

        Key: UhflICLxcwBlAzlqQHiW2A==

        ให้สังเกตุฟิลด์ UhflICLxcwBlAzlqQHiW2A== ในทั้งสองไฟล์ซึ่งก็คือคีย์นั่นเอง ผู้ดูแลระบบจะต้องเก็บคีย์นี้ไว้เป็นความลับ รวมทั้งจะต้องทำการกำหนดสิทธิ์ในการเข้าถึงไฟล์ named.conf ซึ่งจะมีคีย์รวมอยู่ในไฟล์นี้ด้วย โดยจำกัดให้เฉพาะผู้มีสิทธิ์เท่านั้นจึงจะสามารถจัดการ เช่น อ่านหรือเขียนไฟล์นี้ได้ หรือในการโอนย้ายไฟล์คีย์ทั้งสองข้ามไปอยู่บนดีเอ็นเอสอีกตัวหนึ่ง เช่น ดีเอ็นเอสรอง การโอนย้ายควรใช้ ssh (secure shell) เป็นต้น


        2. รายละเอียดของเครื่องดีเอ็นเอสและไฟล์คอนฟิกที่ใช้ในการทดสอบ

        เครื่องดีเอ็นเอสหลักซึ่งมี IP Address เป็น 10.226.43.38 มีรายละเอียดดังนี้

        • ระบบปฏิบัติการที่ใช้ :   Linux TLE 4.1a kernel 2.4.9-13
        • สเป็คเครื่อง :      CPU  P166 MHz, RAM 96 MB, H/D 3.0 GB
        • เวอร์ชันของ Bind :       9.1.3-4

        เครื่องดีเอ็นเอสรองซึ่งมี IP Address เป็น 10.226.43.33 มีรายละเอียดดังนี้

        • ระบบปฏิบัติการที่ใช้ :   Linux RH7.3 kernel 2.4.18-3
        • สเป็คเครื่อง :      P166 MHz, RAM 96 MB, H/D 3.0 GB
        • เวอร์ชันของ Bind :       9. 1.3-4

        ไฟล์คอนฟิก named.conf ของดีเอ็นเอสหลัก มีรายละเอียดดังนี้

        zone "43.226.10.in-addr.arpa" IN {

        type master;
        file "master/10.226.43";

        };

        zone "iss.th" IN {

        type master;
        file "master/iss.th";

        };

        ไฟล์ 10.226.43 (ในคำสั่ง file "master/10.226.43";) มีรายละเอียดดังนี้

        @       IN      SOA     ns1.iss.th. root.iss.th. (

        2002070101       ; serial, todays date + todays serial
        21600     ; refresh, after 6 hours
        3600     ; retry, after 1 hour
        604800     ; expire, after 1 week
        86400 )   ; minimum, TTL of 1 day
        NS      ns1.iss.th.

        ;

        ; Internal Workstations Name

        ;

        33     PTR    ns2.iss.th.
        35     PTR    chaba.iss.th.
        38     PTR    ns1.iss.th.
        40     PTR    non.iss.th.

        และไฟล์ iss.th (ในคำสั่ง file "master/iss.th";) มีรายละเอียดดังนี้

        @       IN      SOA     ns1.iss.th. root.iss.th. (

        2002070801       ; serial, todays date + todays serial
        21600     ; refresh, after 6 hours
        3600     ; retry, after 1 hour
        604800     ; expire, after 1 week
        86400 )   ; minimum, TTL of 1 day

        NS      ns1.iss.th.

        localhost       A       127.0.0.1

        ;

        ; Canonical  Name

        ;

        ftp        CNAME   ns1
        www        CNAME   ns1
        proxy      CNAME   ns1

        ;

        ; Internal Workstations Name

        ;

        ns2        A       10.226.43.33
        chaba      A       10.226.43.35
        ns1        A       10.226.43.38
        non        A       10.226.43.40


        สำหรับไฟล์คอนฟิก named.conf ของดีเอ็นเอสรอง จะได้แสดงให้ดูเมื่อแสดงตัวอย่างการคอนฟิกที่เกี่ยวข้องกับดีเอ็นเอสนี้ในหัวข้อต่าง ๆ ข้างล่างนี้


        3. วิธีการในการสร้างความปลอดภัยให้กับดีเอ็นเอส

        3.1 จำกัดเวอร์ชั่นของ Bind

        ให้ใช้ซอฟต์แวร์เวอร์ชั่นล่าสุดของ Bind ถ้าเป็นไปได้ เวอร์ชั่นของ Bind เก่า ๆ เช่น ก่อน 8.2.3 ย้อนหลังลงไปล้วนแล้วมีปัญหาทางด้านความปลอดภัยในลักษณะใดลักษณะหนึ่ง ผู้ใช้สามารถตรวจสอบจุดอ่อนของ Bind เวอร์ชั่นต่างๆ ได้จากเว็ปไซต์ http://www.iso.org/product/BIND/bind-security.html อย่างไรก็ตามจุดอ่อนต่าง ๆ รวมทั้งจุดอ่อนใหม่ ๆ สามารถเกิดขึ้นได้ตลอดเวลา เพราะฉนั้นอีกทางหนึ่งซึ่งควรปฏิบัติคือควรตรวจสอบข่าวต่าง ๆ ใน Newsgroup ต่าง ๆ เช่น comp.protocols.dns.bind อย่างสม่ำเสมอ ซึ่งจะมีการพูดถึงข้อมูลต่าง ๆ เกี่ยวกับ Bind รวมทั้งจุดอ่อนใหม่ ๆ ที่เพิ่งเกิดขึ้นด้วย

        สำหรับเวอร์ชั่นของ Bind อีกมุมหนึ่งที่ควรระวัง คือ ไม่ควรเปิดเผยเวอร์ชั่นของ Bind ที่องค์กรใช้งานอยู่ออกไป เพราะเมื่อผู้บุกรุกทราบเวอร์ชั่นของท่านแล้ว และหากเวอร์ชั่นที่ท่านใช้อยู่มีจุดอ่อนหนึ่ง ๆ ที่ท่านอาจยังไม่ทราบ ผู้บุกรุกก็อาจใช้เป็นช่องทางในการบุกรุกระบบของท่านได้ ในคอนฟิกไฟล์ของดีเอ็นเอส named.conf ถ้าสังเกตที่บรรทัดที่มีคำว่า version.bind ท่านจะพบเวอร์ชั่นของ Bind ที่ท่านใช้งานอยู่แสดงอยู่ ณ ที่นั้น คำสั่ง dig บนลินุกซ์สามารถแสดงมันออกมาได้ เช่น

        # dig txt chaos version.bind.

        ; <<>> DiG 9.1.3 <<>> txt chaos version.bind.
        ;; global options:  printcmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5482
        ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

        ;; QUESTION SECTION:
        ;version.bind.         CH      TXT

        ;; ANSWER SECTION:
        version.bind.  0       CH      TXT     "9.1.3"

        ;; Query time: 13 msec
        ;; SERVER: 10.226.43.38#53(10.226.43.38)
        ;; WHEN: Wed Jul 10 2002
        ;; MSG SIZE  rcvd: 48
        #
        ซึ่งในกรณีนี้จะเห็นได้ว่าคือเวอร์ชั่น 9.1.3  เวอร์ชั่นของ Bind นับตั้งแต่ 8.2 เป็นต้นไปมีคำสั่ง version ที่ใช้ในการควบคุมปัญหาการแสดงเวอร์ชั่นนี้ได้ เช่น
        options {
        version "None of your business";
        };

        โดยคำสั่งนี้ เมื่อถูกสอบถามโดยดีเอ็นเอสอื่น ๆ เกี่ยวกับเวอร์ชั่นของดีเอ็นเอสของท่าน ดีเอ็นเอสของท่านที่ใช้คำสั่งนี้ก็จะแสดงคำว่า “None of your business” ออกไป เช่น ภายหลังการคอนฟิกด้วยคำสั่งนี้ และใช้คำสั่ง dig หน้าจอจะแสดงดังนี้

        # dig txt chaos version.bind.

        ; <<>> DiG 9.1.3 <<>> txt chaos version.bind.
        ;; global options:  printcmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4409
        ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

        ;; QUESTION SECTION:
        ;version.bind.         CH      TXT

        ;; ANSWER SECTION:
        version.bind.  0       CH      TXT     "None of your business"

        ;; Query time: 14 msec
        ;; SERVER: 10.226.43.38#53(10.226.43.38)
        ;; WHEN: Wed Jul 10 2002
        ;; MSG SIZE  rcvd: 55
        #

        3.2 การจำกัดการสอบถาม

        ในเวอร์ชั่นของ Bind ก่อนหน้า 4.9 ดีเอ็นเอสขององค์กรไม่มีทางที่จะควบคุมการสอบถามจากดีเอ็นเอสอื่น ๆ ได้ กล่าวอีกนัยหนึ่งก็คือดีเอ็นเอสอื่นเหล่านั้นสามารถสอบถามดีเอ็นเอสขององค์กรได้ทั้งหมดในทุกรูปแบบ ในอดีตคอนเซ็ปต์ที่สามารถสอบถามได้ทุกรูปแบบนี้เป็นคอนเซ็ปต์ที่ยอมรับได้ ทั้งนี้เพราะจุดประสงค์ดั้งเดิมของดีเอ็นเอสก็คือ ให้ข้อมูลเกี่ยวกับชื่อโดเมนทุกอย่างแก่ผู้ถาม อย่างไรก็ตามปัจจุบันคอนเซ็ปต์ดังกล่าวไม่เป็นจริงอีกต่อไปแล้วโดยเฉพาะอย่างยิ่งทางด้านความปลอดภัยของระบบ เช่น การสอบถามได้ทุกอย่างจะทำให้ผู้บุกรุกทราบรายละเอียดเกี่ยวกับเครื่องภายในเครือข่ายของเราทั้งหมด เช่น รู้ว่าเครื่องไหนเป็นเมล์เซิร์ฟเวอร์  เครื่องไหนเป็นดีเอ็นเอส อันจะใช้เป็นช่องทางในการบุกรุกระบบได้

        นับตั้งแต่  Bind เวอร์ชั่น 8 เป็นต้นมามีคำสั่ง allow-query ซึ่งสามารถใช้ควบคุมผู้สอบถามได้ ผู้ดูแลระบบสามารถกำหนดเป็น IP Address ของผู้สอบถามที่จะอนุญาตให้ทำการสอบถามได้


        การจำกัดการสอบถามในโซนบางโซน

        จากคอนฟิกเดิมในไฟล์ named.conf ที่กำหนดไว้ในหัวข้อที่ 2 สำหรับเครื่องดีเอ็นเอสหลัก 10.226.43.38  เครื่องอื่น ๆ อาทิ เบอร์ 10.226.43.40 (non.iss.th) จะสามารถทำการสอบถามดีเอ็นเอสเครื่องนี้ได้เพราะยังมิได้มีการจำกัดใด ๆ ซึ่งสามารถทดลองสอบถามดูได้โดยอาจถามเป็นชื่อโดเมนหรือเบอร์ IP Address ก็ได้  คำสั่ง nslookup เป็นคำสั่งที่ใช้ในการทดสอบนี้ได้

        #nslookup

        > 10.226.43.33          
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        Name:    ns2.iss.th
        Address:  10.226.43.33

        > non.iss.th
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        Name:    non.iss.th
        Address:  10.226.43.40

        > www.nectec.or.th
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        Non-authoritative answer:
        Name:    www.nectec.or.th
        Address:  202.44.204.33

        >

        ให้สังเกตด้วยว่าแม้ไม่ได้เป็นข้อมูลจากโซนทั้งสอง 43.226.10.in-addr.arpa และ iss.th เช่น www.nectec.or.th เครื่องเบอร์ 10.226.43.40 ก็สามารถสอบถามได้ด้วย ทั้งนี้เนื่องจากมิได้มีการจำกัดใด ๆ

        ผู้ดูแลระบบสามารถจำกัดการสอบถามไปยังโซนใดโซนหนึ่งของเครื่องดีเอ็นเอสหลักให้สามารถทำได้เฉพาะจากบางเครื่องเท่านั้น เช่น
        acl "allow-nets" { 10.226.43.33; 10.226.43.35; 10.226.43.38; };

        zone "43.226.10.in-addr.arpa" IN {
        type master;    
        file "master/10.226.43";
        };

        zone "iss.th" IN {
          type master;
          file "master/iss.th";
          allow-query { "allow-nets"; };
        };

        ตัวอย่างนี้เป็นการจำกัดการสอบถามไปยังโซน iss.th  ให้สังเกตบรรทัด allow-query คำสั่งนี้จะอนุญาตให้ผู้สอบถาม (ซึ่งอาจเป็นเครื่องอื่นหรือดีเอ็นเอสอื่นก็ได้) ที่มาจากเบอร์ 10.226.43.33, 10.226.43.35 หรือ 10.226.43.38  (acl  ในคำสั่งข้างบนหมายถึง Access Centrol List ซึ่งหมายถึงเครื่องหรือกลุ่มของเครื่องที่มี IP Address กลุ่มหนึ่งที่องค์กรอนุญาตให้ทำสิ่งหนึ่งได้) ให้สามารถสอบถามข้อมูลในโซน iss.th ของดีเอ็นเอสหลักได้

        เพราะฉะนั้นผู้ที่อยู่นอกเหนือจากเบอร์ IP Address ที่กำหนดไว้ใน acl จะไม่สามารถสอบถามดีเอ็นเอสหลักในโซน iss.th ได้ เช่น เครื่องเบอร์ 10.226.43.40 จะไม่สามารถสอบถามได้ ให้ทำการทดสอบดังนี้ (คำสั่ง server 10.226.43.38 เป็นคำสั่งเซ็ตเซิร์ฟเวอร์ดีเอ็นเอสเป็นเบอร์ 10.226.43.38 (ดีเอ็นเอสหลัก) ให้กับเครื่อง 10.226.43.40)    

        #nslookup
        > server 10.226.43.38
        Default Server:  [10.226.43.38]
        Address:  10.226.43.38

        > 10.226.43.40
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        Name:    non.iss.th
        Address:  10.226.43.40

        > www.nectec.or.th
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        Non-authoritative answer:
        Name:    www.nectec.or.th
        Address:  202.44.204.33

        > ns2.iss.th
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        *** [10.226.43.38] can't find ns2.iss.th: Query refused
        > non.iss.th
        Server:  [10.226.43.38]
        Address:  10.226.43.38

        *** [10.226.43.38] can't find non.iss.th: Query refused

        >

        จากผลการทดสอบ จะเห็นได้ว่า เนื่องจากเราไม่ได้จำกัดการสอบถามของเครื่อง 10.226.43.40 ไปยังโซน 43.226.10.in-addr.arpa (ในไฟล์ 10.226.43) ดังนั้นเครื่อง 10.226.43.40 จะยังคงสามารถสอบถามข้อมูลในโซนดังกล่าวได้ ซึ่งเป็นการสอบถามโดยใช้เบอร์ IP Address แล้วจะได้ชื่อโดเมนกลับคืนมา  ส่วนในสองคำถามสุดท้าย ns2.iss.th และ non.iss.th จะไม่สามารถสอบถามได้ เนื่องจากเป็นข้อมูลในโซน iss.th


        การจำกัดการสอบถามแบบ Global

        นอกจากการจำกัดการสอบถามในโซนใดโซนหนึ่งแล้ว ผู้ดูแลระบบสามารถจำกัดการสอบถามกับโซนทั้งหมดทุก ๆ โซนที่อยู่ภายในเครือข่ายขององค์กรได้ ซึ่งเป็นการจำกัดแบบ Global ดังนั้นคำว่า Global ในที่นี้จึงหมายถึงทั่วทั้งหมดทุกโซนนั่นเอง

        วิธีการคือแทนที่เราจะใส่คำสั่ง allow-query เข้าไปยังโซนหนึ่งโซนใดก็ตามที่ต้องการควบคุม ให้ใส่คำสั่งดังกล่าวเข้าไปในบล็อกคำสั่ง options เช่น

        acl "allow-nets" { 10.226.43.33, 10.226.43.35, 10.226.43.38; };

        options {

          allow-query { "allow-nets"; };
        };

        สมมุติในที่นี้ว่าองค์กรมี 2 โซน ได้แก่ โซน 43.226.10.in-addr.arpa และโซน iss.th โซน  (จริง ๆ แล้วข้อมูลโซนทั้งสองเป็นข้อมูลโซนที่กลับค่ากัน อันแรกเป็นการกำหนดจากเบอร์ IP Address ไปสู่ชื่อโดเมน ส่วนอันหลังจะกำหนดจากชื่อโดเมนไปสู่เบอร์ IP Address) ผู้ดูแลระบบสามารถใช้คำสั่งดังนี้

        acl "allow-nets" { 10.226.43.33, 10.226.43.35, 10.226.43.38; };

        options {

        allow-query { "allow-nets" };

        };

        zone "43.226.10.in-addr.arpa" IN {

        type master;
        file "master/10.226.43";

        };

        zone "iss.th" IN {

        type master;

        file "master/iss.th";

        };

        คำสั่ง allow-query ในบล็อกคำสั่ง options จะควบคุมการสอบถามที่มาจาก allow-nets เพื่อไปยังโซนทั้งสองให้สามารถกระทำได้


        3.3 การป้องกันการทำ Zone Transfer

        การป้องกันการทำ Zone Transfer หมายถึง การป้องกันมิให้ผู้ที่ไม่มีสิทธิ์ในการโอนย้ายข้อมูลโซนขององค์กร ทำการโอนย้ายข้อมูลดังกล่าวไป (ข้อมูลโซนจะมีข้อมูลชื่อโดเมนของเครื่องและเบอร์ IP Address ของเครื่องเหล่านั้น) ซึ่งนั่นหมายถึงว่าผู้ที่ได้รับข้อมูลโซนไปจะทราบ “แผนที่เครือข่าย” ของเรานั่นเอง เช่น รู้ว่าเมล์เซิร์ฟเวอร์มี IP Address อะไร เว็ปเซิร์ฟเวอร์ใช้ IP Address อะไร เป็นต้น Bind เวอร์ชั่น 8 และ 9 มีคำสั่ง allow-transfer ที่ใช้ในการควบคุมการทำ Zone Transfer ได้


        การจำกัดการทำ Zone Transfer สำหรับบางโซน

        ผู้ดูแลระบบสามารถทำการคอนฟิกให้ดีเอ็นเอสขององค์กร เช่น ดีเอ็นเอสหลักเบอร์ 10.226.43.38 อนุญาตให้ทำ Zone Transfer ได้เฉพาะกับบางเครื่อง เช่น ดีเอ็นเอสรองเบอร์ 10.226.43.33 คำสั่ง         allow-transfer ดังนี้

        zone "43.226.10.in-addr.arpa" IN {
        type master; 
        file "master/10.226.43";
        allow-transfer { 10.226.43.33; };
        };

        zone "iss.th" IN {
        type master; 
        file "master/iss.th";
        };

        ที่ใช้กับเครื่องดีเอ็นเอสหลักขององค์กรจะอนุญาตให้ดีเอ็นเอสรองสามารถทำ Zone Transfer จากโซน 43.226.10.in-addr.arpa ได้  ให้สังเกตว่ามีคำสั่ง allow-transfer ในโซน 43.226.10.in-addr.arpa แต่ไม่มีคำสั่ง allow-transfer ในโซน iss.th ซึ่งหมายความว่าเครื่องดีเอ็นเอสหลักจะไม่อนุญาตการทำ Zone Transfer ในโซน iss.th นั่นเอง

        ไฟล์คอนฟิก named.conf ของเครื่องดีเอ็นเอสรองจะต้องมีคำสั่งเพื่อรองรับการทำ Zone Transfer ดังนี้

        zone "43.226.10.in-addr.arpa" IN { 
        type slave; 
        file "slave/10.226.43"; 
        masters { 10.226.43.38; };
        };

        zone "iss.th" IN {
        type slave;
        file "slave/iss.th"; 
        masters { 10.226.43.38; };
        };

        คำสั่ง masters เป็นคำสั่งที่ใช้กำหนดว่าใครคือดีเอ็นเอสหลักของดีเอ็นเอสเครื่องนี้  ให้สังเกตด้วยว่าถึงแม้จะมีคำสั่งรองรับการทำ Zone Transfer สำหรับโซน iss.th แต่การโอนย้ายโดยเครื่องดีเอ็นเอสรองก็จะไม่สามารถกระทำได้เนื่องจากไม่มีสิทธิ ผลที่เกิดขึ้นก็คือเครื่องใด ๆ ก็ตามที่ทำการสอบถามมายังโซน iss.th ของเครื่องดีเอ็นเอสรองนี้ จะไม่ได้รับคำตอบ ข้างล่างนี้เป็นการทดสอบการสอบถามจากเครื่อง 10.226.43.40 ไปยังเครื่องดีเอ็นเอสรอง

        # nslookup

        > server 10.226.43.33
        Default Server:  [10.226.43.33]
        Address:  10.226.43.33

        >10.226.43.40
        Server:         10.226.43.33
        Address:        10.226.43.33#53

        40.43.226.10.in-addr.arpa       name = non.iss.th.
        > www.nectec.or.th
        Server:         203.185.132.234
        Address:        203.185.132.234#53

        Non-authoritative answer:
        Name:   www.nectec.or.th
        Address: 202.44.204.33
        > ns2.iss.th
        Server:         10.226.43.33
        Address:        10.226.43.33#53

        ** server can't find ns2.iss.th: SERVFAIL
        > ns1.iss.th
        Server:         10.226.43.33
        Address:        10.226.43.33#53

        ** server can't find ns1.iss.th: SERVFAIL

        >

        คำสั่งแรกเป็นการเซ็ตเซิร์ฟเวอร์ดีเอ็นเอสให้กับเครื่อง 10.226.43.40

        คำสั่งที่สองเป็นคำสั่งค้นหาชื่อโดเมนของเครื่องที่ใช้ IP Address 10.226.43.40 ผลที่ได้คือ non.iss.th ทั้งนี้เพราะข้อมูลนี้อยู่ในโซน 43.226.10.in-addr.arpa ซึ่งได้ทำการโอนย้ายมาจากเครื่องดีเอ็นเอสหลักมาไว้ที่เครื่องดีเอ็นเอสรองแล้ว   

        คำสั่งที่สามคือการค้นหาชื่อโดเมน www.nectec.or.th ซึ่งแม้เครื่องดีเอ็นเอสรองจะไม่มีคำตอบโดยตรง ก็จะสามารถไปสอบถามมาจากดีเอ็นเอสอื่น ๆ ได้ และได้คำตอบตามที่แสดงไว้

        คำสั่งที่ 4 และ 5 คือการค้นหาชื่อโดเมน ns2.iss.th และ ns1.iss.th คำตอบที่ได้คือ SERVFAIL (Server Failure) นั่นคือดีเอ็นเอสรองไม่สามารถหาคำตอบได้ ซึ่งตรงตามที่คาดหมายไว้


        การจำกัดการทำ Zone Transfer แบบ Global

        นอกจากการจำกัดการทำ Zone Transfer สำหรับโซนใดโซนหนึ่งแล้ว ผู้ดูแลระบบสามารถจำกัดการทำ Zone Transfer กับโซนทั้งหมดทุก ๆ โซนที่อยู่ภายในเครือข่ายขององค์กรได้ ซึ่งเป็นการจำกัดแบบ Global  (เช่นเดียวกับการจำกัดการสอบถามแบบ Global)

        วิธีการคือแทนที่เราจะใส่คำสั่ง allow-transfer เข้าไปยังโซนหนึ่งโซนใดก็ตามที่ต้องการควบคุม ให้ใส่คำสั่งดังกล่าวเข้าไปในบล็อกคำสั่ง options แทน เช่น

        acl "allow-nets-transfer" { 10.226.43.33; };

        options {
        allow-transfer { "allow-nets-transfer"; };
        };

        zone "43.226.10.in-addr.arpa" IN { 
        type master; 
        file "master/10.226.43";
        };

        zone "iss.th" IN {
        type master;
        file "master/iss.th";
        };

        จากคำสั่งนี้ผู้ดูแลระบบต้องการจำกัดการทำ Zone Transfer กับโซนทั้งหมดทุกโซนขององค์กร ซึ่งประกอบด้วย 2 โซน ได้แก่ 43.226.10.in-addr.arpa และ iss.th และให้สามารถทำการโอนย้ายได้โดยเครื่องจาก allow-nets-transfer ซึ่งประกอบด้วยเครื่องดีเอ็นเอสรอง 10.226.43.33 เท่านั้น

        ไฟล์คอนฟิก named.conf ของดีเอ็นเอสรองต้องใช้คำสั่งดังนี้ เพื่อรองรับการโอนย้ายข้อมูลของทั้งสองโซน

        zone "43.226.10.in-addr.arpa" IN {
        type slave;
        file "slave/10.226.43"; 
        masters { 10.226.43.38; };
        };

        zone "iss.th" IN {
        type slave;
        file "slave/iss.th"; 
        masters { 10.226.43.38; };
        };

        ณ ที่เครื่องดีเอ็นเอสรอง ไฟล์โซนทั้งสองชื่อ 10.226.43 และ iss.th จะได้รับการโอนย้ายจากเครื่องดีเอ็นเอสหลัก 10.226.43.38 มายังเครื่องรองนี้


        การจำกัดการทำ Zone Transfer โดยใช้ TSIG

        โดยใช้ TSIG ผู้ดูแลระบบสามารถจำกัดการทำ Zone Transfer ให้ทำได้เฉพาะผู้ที่มีคีย์ (ลายเซ็นต์อิเล็กทรอนิกส์) ที่ถูกต้องเท่านั้น จึงจะสามารถทำการโอนย้ายข้อมูลโซนได้

        ผู้ดูแลระบบจะต้องทำการคอนฟิกดีเอ็นเอสทั้งสองเครื่องที่จะอนุญาตให้ทำการโอนย้ายข้อมูลโซนกันได้ เช่น หากต้องการให้เครื่องดีเอ็นเอสรอง 10.226.43.33 สามารถทำการโอนย้ายข้อมูลโซนจากเครื่องดีเอ็นเอสหลัก 10.226.43.38 ได้ ผู้ดูแลระบบจะต้องใช้คำสั่งดังนี้บนเครื่องดีเอ็นเอสหลัก

        key ns1-ns2 {
        algorithm  hmac-md5;
        secret "UhflICLxcwBlAzlqQHiW2A==";
        };

        zone "43.226.10.in-addr.arpa" IN {
        type master;
        file "master/10.226.43";
        allow-transfer { key ns1-ns2; };
        };

        zone "iss.th" IN {
        type master;
        file "master/iss.th";
        allow-transfer { key ns1-ns2; };
        };

        ให้สังเกตว่าคำสั่ง allow-transfer { key ns1-ns2; }; เป็นคำสั่งที่กำหนดว่าการทำ Zone Transfer ในทั้งสองโซนนี้จะต้องใช้คีย์ชื่อ ns1-ns2 เท่านั้น จึงจะสามารถทำได้

        ณ ที่เครื่องดีเอ็นเอสรอง 10.226.43.33 ผู้ดูแลระบบจะต้องคอนฟิกให้เครื่องดีเอ็นเอสรองนี้ทำการกำกับลายเซ็นต์ไปกับการขอทำ Zone Transfer ไปยังเครื่องดีเอ็นเอสหลัก 10.226.43.38 ดังนี้

        key ns1-ns2 {
        algorithm       hmac-md5;
        secret " UhflICLxcwBlAzlqQHiW2A==";
        };
           
        server 10.226.43.38 {
        transfer-format many-answers;
        keys { ns1-ns2; };

        };

        zone "43.226.10.in-addr.arpa" IN {

        type slave;
        file "slave/10.226.43";
        masters { 10.226.43.38; };
        };
         
        zone "iss.th" IN {
        type slave;
        file "slave/iss.th";
        masters { 10.226.43.38; };
        };

        ให้สังเกตที่บล็อกคำสั่ง key ในไฟล์คอนฟิกของทั้งดีเอ็นเอสหลักและดีเอ็นเอสรองทั้งสองจะต้องเหมือนกัน ไม่เช่นนั้นแล้ว การโอนย้ายจะไม่สามารถกระทำได้

        บล็อกคำสั่ง server นั้นเป็นการผูกคีย์ ns1-ns2 เข้ากับการขอทำ Zone Transfer ไปยังเครื่องดีเอ็นเอสหลัก 10.226.43.38


        เอกสารอ้างอิง

        [1] DNS and Bind – Help for System Administrators, 4th Edition, Paul Albitz and Cricket Liu, O’ Reilly & Associates, 2001

        นิยายที่ผู้อ่านนิยมอ่านต่อ ดูทั้งหมด

        loading
        กำลังโหลด...

        คำนิยม Top

        ยังไม่มีคำนิยมของเรื่องนี้

        คำนิยมล่าสุด

        ยังไม่มีคำนิยมของเรื่องนี้

        ความคิดเห็น

        ×