Category: Security

  • ตั้งรับและตอบโต้การโจมตี DNS Brute Force Query Attack

    ต่อเนื่องจาก บทความนี้

    หลังจากรู้แล้วว่า DNS Server ของเราถูกโจมตีล่ะนะ
    ทีนี้จะตอบโต้อย่างไรดี?

    ถ้าหากการโจมตีมันไม่ได้เป็น distribution คือตรวจสอบแล้วมาจาก host เพียงตัวเดียวหรือไม่กี่ตัว ก็สามารถตอบโต้แบบง่ายๆได้ โดยใช้ความสามารถของ bind9 เอง bind9 จะมี option ที่จะสามารถ block การ query จาก client ได้ โดยสามารถระบุเป็น ip เดี่ยวๆ หรือเป็น block ของ ip network โดยการเพิ่มเป็น blackhole ใน named.conf.options แบบนี้ครับ

    สมมติ options config เดิมของ bind9 คือ

    options {
        directory “/var/cache/bind”;
        forward only;
        forwarders {
             192.100.77.2;
             192.100.77.5;
        };
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
    };

    เราสามารถเพิ่ม

    include “/etc/bind/blackhole.list”;

    เข้าไปก่อน บรรทัด “};” ซึ่งเป็นบรรทัดล่างสุดของ options เป็น

    options {
        directory “/var/cache/bind”;
        forward only;
        forwarders {
             192.100.77.2;
             192.100.77.5;
        };
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
    include “/etc/bind/blackhole.list”;
    };

    โดยข้อมูลในไฟล์ /etc/bind/blackhole.list จะมีข้อมูลดังนี้

    blackhole {
        174.127.92.85;
        31.210.155.237;
        178.32.76.101;
       …
    };

    ซึ่งวิธีการนี้ ทำให้เราสามารถแก้ไขเฉพาะไฟล์ blackhole.list โดยไม่ต้องไปแก้ไข named.conf.options เมื่อมีการโจมตีโดยใช้ ip address ใหม่เกิดขึ้น

    อย่างไรก็ตาม ผมพบว่า วิธีการนี้ ไม่ค่อยได้ผลสักเท่าไหร่ ถ้าการโจมตีเป็นแบบ DoS หรือ DDoS เพราะ ผู้ที่โจมตี ไม่ได้สนใจข้อมูลที่ DNS Server ของเราจะส่งกลับไป เพียงแต่ต้องการทำให้ Server ทำงานหนักขึ้นเท่านั้น การระบุ blackhole list จะทำให้ DNS Server ส่งคำตอบกลับไปยัง client ที่ query มาว่า REFUSED แต่ก็จะยังมีการตอบกลับ และมีการบันทึกการ query ลงสู่ record อยู่
    นอกจากนี้ ถ้าเป็น DDoS ซึ่งจะมี client ที่มี ip address ใหม่ๆ โจมตีเข้ามาเรื่อยๆ การแก้ไขไฟล์ blackhole.list เพื่อให้ทันสมัยอยู่เสมอ ก็แทบที่จะทำให้วิธีการนี้ ใช้ป้องกันจริงๆไม่ได้

    ซึ่งก็จะขอเสนอเป็นบทความต่อไปครับ การใช้ fail2ban เพื่อป้องกันการโจมตีแบบ Brute Force DNS Quert Attack

  • สร้าง log สำหรับ DNS Query เมื่อใช้ bind9 เป็น DNS Server

    เนื่องจากปัญหาของ DNS Query Brute Force Attack ที่เกิดขึ้นกับ DNS Server บางตัวภายในเครือข่ายของมหาวิทยาลัย สงขลานครินทร์ วิธีการแรกที่ควรจะเอามาใช้ในการที่จะแก้ปัญหานี้ก็คือ “identify your enemy”.

    ใครคือคนที่ส่งคำสั่ง query เข้ามา? query อะไร? และ query บ่อยขนาดใหน?
    หลังจากแยกแยะข้อมูลในส่วนนี้ได้แล้ว เราค่อยตัดสินใจกันต่อว่าจะทำอย่างไรต่อไป

    สำหรับบทความนี้ จะพูดถึง Bind9 เท่านั้น Bind version ต่ำกว่า 9 ยังไม่ได้ทดสอบว่าใช้งานได้หรือเปล่า ส่วน version สูงกว่า 9, ถ้ามีก็น่าจะใช้งานได้ ส่วน DNS Server ตัวอื่นๆ ก็ยังไม่ได้ใช้อย่างจริงจังก็เลยไม่รู้เหมือนกันครับว่าจะจัดการอย่างไร แต่โดยหลักๆแล้วก็เหมือนกันครับ ก็คือ

    สร้าง log แล้วตรวจสอบจาก log

    สำหรับ bind9 ในส่วนของ option configuration จะมี keyword “logging” อยู่ ซึ่งสามารถใช้ระบุการ log ข้อมูลแบบต่างๆได้หลายอย่าง และ หลายรูปแบบมาก ในที่นี้ สมมติ เราสนใจเฉพาะส่วนของการ query นะครับ ก็อาจจะสร้าง config ได้แบบนี้

    logging {
          channel query_logging {
                 file “/var/log/named/query.log”;
                 print-time yes;
          };
          category queries { query_logging; };
    };

    เป็นการสร้าง channel สำหรับ log ขึ้นมาชื่อว่า “query_logging” โดยข้อมูลที่ถูกส่งมาที่ channel นี้จะเก็บลงไว้ในไฟล์ที่ชื่อว่า query.log ซึ่งไฟล์นี้จะเก็บอยู่ใน directory ที่ชื่อว่า /var/log/named

    config ข้างต้นจะเก็บเอาไว้ในไฟล์ /etc/bind/named.conf.options (สำหรับ Debian หรือ Ubuntu)
    โดยเพิ่มต่อท้ายเข้าไป

    ในส่วนของ directory ที่ใช้ในการเก็บ log (/var/log/named) ถ้ายังไม่มีอยู่ ก็ต้องสร้างขึ้นมาใหม่ก่อน และกำหนดให้เป็นของ user ซึ่ง run ตัว named daemon ซึ่งสำหรับบน Debian/Ubuntu จะใช้ user ที่ชื่อว่า bind ดังนั้น สามารถสร้าง diectory ขึ้นมาใช้งานได้โดยใช้คำสั่งดังนี้

    $ sudo mkdir -p /var/log/named
    $ sudo chown bind:bind /var/log/named

    หลังจากแก้ไขไฟล์ /etc/bind/named.conf.options แล้ว เราก็ควรที่จะตรวจสอบก่อนว่า config ไฟล์ที่แก้ไขไปยังอยู่ใน format ที่ถูกต้องก่อนที่จะใช้งาน ซึ่งทำได้โดยการใช้คำสั่ง

    $ sudo named-checkconf /etc/bind/named.conf

    ซึ่งถ้าไม่มีข้อความใดๆแสดงออกมา ก็แสดงว่า config ถูกต้อง เราก็สามารถสั่งให้ named อ่าน config ใหม่เข้าไปใช้ได้ โดยการใช้คำสั่ง

    $ sudo service bind9 reload

    หรือ

    $ sudo rndc reconfig

    หลังจากนั้น ก็สามารถตรวจสอบการทำงานของตัว named server ได้โดยใช้คำสั่ง

    $ host www.mydomain.net localhost

    เปลี่ยน ‘www.mydomain.net’ เป็น host ที่ตัว name server ของเราให้บริการอยู่
    หลังจากนั้นก็ไปตรวจสอบดูว่าในไฟล์ /var/log/named/query.log มีข้อมูลเพิ่มขึ้นมาหรือไม่

    ซึ่งถ้าการ config ทุกอย่างถูกต้อง ก็ควรที่จะมีข้อมูลของการ query เกิดขึ้น
    ตัวอย่างของข้อมูลที่ตัว named จะ log เอาไว้ครับ

    28-Nov-2012 11:54:14.911 client 174.127.97.86#25345: query: isc.org IN ANY +ED (172.30.0.85)
    28-Nov-2012 11:54:15.589 client 174.127.97.86#25345: query: isc.org IN ANY +ED (172.30.0.85)

    ซึ่งในที่นี้ client ที่ส่งคำสั่ง query มาก็คือ 174.127.97.86 โดย server ก็คือ 172.30.0.85 และข้อมูลที่ query ก็คือ isc.org ชนิดของข้อมูลเป็น any (ข้อมูลทั้งหมดเท่าที่มี)

    ในสภาวะที่ตัว Server ของเราถูกโจมตี ขนาดของ query.log ก็จะเพิ่มขึ้นอย่างรวดเร็วมาก
    จากตัวอย่างข้างต้น query ทั้งสองครั้งเกิดขึ้นในช่วงเวลาน้อยกว่า 1 วินาที (ครั้งแรกเวลา 11:54:14, ครั้งถัดมา 11:54:15 ตัวเลข 3 ตัวหลังจุด จะเป็นส่วนย่อยของวินาที)

    เราจะรู้ได้อย่างไรว่า client ตัวใหนบ้างที่กำลังโจมตี server ของเราอยู่ ตัวใหนที่ใช้งานแบบปกติ?
    เราสามารถใช้เครื่องมือบน linux/unix ในการช่วยตรวจสอบได้ครับ โดยการนับ

    $ cat /var/log/named/query.log | cut -f4 -d’ ‘ | cut -f1 -d’#’ | sort | uniq -c | sort -rn | head -20

    ตัวอย่าง output ที่ผมได้จาก server ที่ถูกโจมตีคือ

      18174 178.32.76.101
      10924 64.120.228.188
       5297 194.8.75.57
       4584 37.77.82.161
       1744 72.20.55.30
       1548 88.232.24.58
       1356 216.119.157.90
       1242 69.64.58.160
       1189 5.47.41.41
       1155 128.204.201.22
       1115 5.135.60.245
        872 31.214.144.181
        629 37.59.93.86
        513 88.228.212.44
        467 94.121.242.57
        438 178.32.239.65
        382 37.59.194.200
        343 174.127.92.85
        325 174.127.103.234
        296 88.245.53.247

    ตัวเลขข้างหน้าคือจำนวนครั้ง และตัวเลขข้างหลังคือ ip address ของ client ที่ส่งคำสั่ง query เข้ามาทั้งหมดนี้ query ช้อมูลตัวเดียวกันก็คือ “isc.org” type ANY

    เรารู้ตัวว่าผู้โจมตีเป็นใครแล้ว หลังจากนี้ก็จะเป็นคำถามว่า แล้วจะแก้ปัญหาอย่างไร
    ขอยกไปเป็นบทความหน้าครับ

  • เบราว์เซอร์กับเว็บไซต์ https ที่ใช้ Self-signed Certificate

    คำถามที่ผมต้องการคำตอบ คือ ผมจะทำให้ Chrome บน Windows 8 สามารถติดตั้ง PSU CA (certificate authority) จากหน้า passport.psu.ac.th ได้อย่างไร เพราะว่าผมทำ self-signed certificate verified by PSU CA จึงจำเป็นต้องให้เบราวเซอร์ที่ใช้ได้รับการติดตั้ง PSU CA ก่อน บน Ubuntu ผมใช้งานได้แล้ว จำไม่ได้ว่ามันเอา PSU CA เข้าไปตอนไหน

    คำตอบที่ผมได้รับจากการสอบถามผู้รู้ ก็พบว่า

    certificate ที่ซื้อมาเป็น cert สำหรับ *.psu.ac.th คงใช้กับ *.in.psu.ac.th ไม่ได้ครับ

    Web ขอ CA passport.psu.ac.th รองรับเฉพาะ IE/Firefox เท่านั้นครับ ส่วน server cer ในกรณีที่ไม่ใช่ x.psu.ac.th ใช้ self sign cer ได้เลยครับ ถ้าแนะนำอยากให้พี่จดเป็น sysadmin.psu.ac.th หลังจากนั้นแจ้งมาที่ผมได้ครับ เดี๋ยวผมส่ง server ca ที่เป็น *.psu.ac.th ให้ (CA ที่พี่ขอจากหน้า passport.psu.ac.th เป็น User CA ครับไม่ใช่ Server CA, แต่ก็ขอได้ครับ แต่จะมีวิธีต่างจากการขอทั่วไป แนะนำให้ใช้ self sign ดีกว่า เพราะคนใช้งานต้องลง cer psu ถึงจะ trust cer ที่เป็น self sign ของระบบ psu passport ที่ออกให้อีกที แบบนั้นใช้ self sign ไปเลยดีกว่า)

    ผมมีตัวอย่างบน ubuntu นะครับ เข้าเบราว์เซอร์ chrome และไปยังเว็บไซต์ sysadmin.in.psu.ac.th มันไม่ฟ้อง “ไม่ปลอดภัย” และ URL แสดงรูปกุญแจสีเขียว https เพราะผมคงติดตั้ง PSU CA แล้ว (ไม่รู้ตอนไหน) ต่อไปผมลองใช้จาก Windows 8 มันฟ้อง “ไม่ปลอดภัย” เลยจะพยายามติดตั้ง PSU CA จากหน้า passport.psu.ac.th ครับ และทำไม่ได้ฟ้องว่ารอบรับ IE/Firefox เดาว่าผมคง import เข้า chrome

    จริงๆ chrome มันใช้ตัวจัดการ cert ของ IE ครับ

    หมายความว่า ถ้าผมไปเข้าเบราว์เซอร์ IE ติดตั้ง PSU CA ให้เสร็จแล้วกลับมาเข้า Chrome ก็ใช้งานได้ (จริงป่ะ)

    ใช่ครับ

    โอ้ ท่านใหญ่ เกรียงไกร ท่านยอดมาก ขอคารวะ ทดสอบแล้วในขั้นตอนติดตั้ง PSU CA จาก passport.psu.ac.th ต้องเปลี่ยนตัวเลือกจาก Automatic เป็น Place all certificates in the following store และเลือก Trusted Root Certificated Authorities (จะเอาไปเขียนลงในบล็อก sysadmin)

  • Windows 8 ไม่สามารถเข้า Oracle Enterprise Manager 11gr2 ได้

    แจ้ง Error. ว่า There is a problem with this website’s security certificate.

    (more…)