Tag: bind9

  • วิธีการตั้งค่า CNAME และ TXT เพื่อ Verification กับ Google Site

    Google Site เป็บบริการหนึ่งของ Google ซึ่งให้เราสร้างเว็บไซต์ได้อย่างง่ายๆ เหมาะสำหรับการงานที่ต้องการความรวดเร็วในการสร้าง และสามารถประสานกับเครื่องมือต่างๆของ Google ได้มากมาย เช่น จะสร้างแบบฟอร์มรับสมัครเข้าร่วมโครงการ, ทำรายงานผู้ที่ชำระเงินแล้ว, ผนวกกับ Google Map เพื่อแสดงตำแหน่งที่จัดงาน และสถานที่ท่องเที่ยว หรือ อื่นๆอีกมากมาย (วิธีการสร้าง จะกล่าวในบทความต่อๆไป)

     ในบทความนี้ เป็นการสร้าง เว็บไซต์ของงาน ประชุมสภาข้าราชการ พนักงานและลูกจ้างแห่งประเทศ (ปขมท) ๒๕๕๗ และเน้นที่ การเชื่อม Domain Name ของมหาวิทยาลัย ซึ่งใช้ Bind DNS เข้ากับ Google Site

    โดย Google Site ที่แสดงในตัวอย่าง สร้างที่ https://sites.google.com/site/cuast57/ ซึ่ง ชื่อจะจำได้ยาก จึงขอใช้ Domain Name สั้นๆชื่อ cuast57.psu.ac.th

    วิธีการมีดังนี้

    1. ไปที่ Setting > Manage Site

    2. คลิกที่ Web Address แล้วใส่ cuast57.psu.ac.th จากนั้นคลิกปุ่ม Add

    3. จะขึ้น error ด้านบน “You have not verfified domain ownership with Google. please follow these instructions” ให้คลิกที่ “these instructions”

     4. เลื่อนลงไปล่าสุดของหน้าจอ คลิกที่ “Webmaster Tools home page” (สมมุติว่าท่านเคยใช้งาน Google Webmaster Tools อยู่แล้ว)

    5. คลิกที่ Add A Site ให้ใส่ Domain Name ที่ต้องการ ในที่นี้คือ cuast57.psu.ac.th แล้วคลิก Continue

    6. คลิกที่ Alternate Methods > Domain name provider แล้วเลือก อันล่างสุด คือ other เพราะ Google Site ไม่เปิดให้เรา Upload File ขึ้นไป, ไม่สามารถแก้ไข Header หรืออะไรทำนองนั้นได้ จึงต้องใช้วิธีการนี้ ซึ่งจะต้องอธิบายตรงนี้เพื่อความเข้าใจ

     ในการที่เราคุม Domain Name แต่ใช้ Google Site นั้น สิ่งที่ต้องทำคือ สร้าง CNAME ไปยัง Google Site และ ทำการ Verification

    6.1 สร้าง CNAME ไปยัง ghs.googlehosted.com. เพื่อบอกว่า cuast57.psu.ac.th จะใช้บริการของ Google Site

    6.2 ต้องทำการ Verification โดยสามารถทำได้ 2 วิธีคือ

    1) ถ้าเราได้ Delegate Zone มา ก็จะสามารถใส่ TXT Record ลงไปได้ โดยใช้ค่าดังภาพ

     2) แต่ถ้าเราไม่ได้ Delegate Zone ก็จะต้องสร้าง CNAME ให้คลิกที่ “Add a CNAME record” ดังภาพ

    ให้เลือกวิธีการเอา แต่ในตัวอย่างนี้ เลือกวิธีการ 2) เพราะไม่ Delegate Zone มา และไปทำข้อ 7. ก่อน แล้วจึงกลับมาคลิกปุ่ม Verify ภายหลัง

    7. เพื่อทำการ Verification ให้สร้าง DNS Record ใน Bind DNS Server ดังนี้

    จากนั้น ทำการ sudo rndc reload แล้วกลับไปทำข้อ 6 เมื่อ Verification เสร็จ รอสักครู่ ก็จะสามารถเรียกใช้งาน cuast57.psu.ac.th ได้ครับ

    ขอให้โชคดี

  • update fail2ban after DNS query attack

    หลังจากทิ้งไว้นานกว่า 1 ปี ในที่สุดการโจมตีในลักษณะของการ DOS attack สำหรับ DNS Server ก็กลับมาอีกรอบ

    วันนี้ (2013-12-11) คุณ สงกรานต์ก็ post ข้อความในกลุ่ม PSU Sysadmin บน facebook ว่า DNS Server หลายๆเครื่องที่อยู่ภายในเครือข่ายของ PSU มี traffic เกิดขึ้นมากผิดปกติ และมากกว่าตัว DNS Server หลักของมหาวิทยาลัยเอง {ns1,ns2}.psu.ac.th ซึ่งตัว DNS Server ทั้งสองโดยทั่วไปแล้ว เนื่องจากเป็นเซิร์ฟเวอร์ที่ให้บริการเป็นหลักให้กับเครื่องคอมพิวเตอร์ทั้งหมดภายในมหาวิทยาลัย ก็ควรที่จะมี traffic สูงกว่า DNS Server ตัวอื่นๆ แต่เมื่อเครื่อง DNS Server อื่นๆมี traffic สูงกว่า ก็พอที่จะบอกได้คร่าวๆล่ะว่า มีเหตุการณ์ผิดปกติเกิดขึ้นแน่ๆ

    ในจำนวน server เหล่านั้น มีเครื่องเซิร์ฟเวอร์ที่ผมดูแลอยู่ด้วย เป็นเครื่องที่ใช้สำหรับสอน นศ. ในรายวิชา Linux Server Admin. ซึ่งหัวข้อหนึ่งที่นศ.จะต้องเรียน ก็คือการติดตั้งและให้บริการ Name Service ซึ่งเครื่องเซิร์เวอร์เครื่องนี้ นอกจากจะใช้เป็นตัวอย่างในการ setup แล้ว ยังทำหน้าที่เป็น 2nd DNS ให้กับ domain ของ นศ. ทั้งหมดด้วย (นศ. มี domain ของตัวเองคนละ 1 domain)

    logfile ที่เกิดจากการ query มีขนาดมากกว่า 2GB จากการเก็บ log ของการ query ในช่วงเวลาประมาณ 3 วันครึ่ง (เริ่ม 2013-12-08 16:25 จนถึง 2013-12-11 12:40) เมื่อเทียบกับ log ปกติมีขนาดประมาณ 1-2 MB สำหรับการเก็บ log ในช่วง 1 สัปดาห์

    หรือถ้าเทียบในแง่ของจำนวนของการ query ในช่วง 3 วันที่ผ่านมามีการ query ประมาณ 18 ล้านครั้ง เมื่อเทียบกับการ query ปกติประมาณ 15,000 ครั้งต่อสัปดาห์

    การโจมติมาจากใหนบ้าง?

    7778377 95.211.115.114
    3870621 93.170.4.34
    2596494 94.198.114.135
    2581297 95.211.216.168
    331584 199.59.161.6
    53137 216.246.109.162
    47351 205.251.194.32
    46793 205.251.193.79
    41119 156.154.166.38
    39572 156.154.166.37
    39501 54.230.130.116
    36855 205.251.198.179
    34079 42.112.16.162
    31690 134.255.243.100
    28662 205.251.197.226
    27481 212.118.48.20
    23435 204.188.252.146
    20565 82.221.105.131
    20477 89.184.81.131
    19036 95.141.37.197
    17404 72.20.56.200
    14156 206.72.192.13
    11510 82.221.105.139
    10387 5.135.14.245

    ตัวเลขในคอลัมน์แรกคือจำนวนครั้งที่มีการ query และในคอลัมน์ที่สองเป็น ip address

    query อะไรบ้าง? ถ้าดูข้อมูลคร่าวๆก็จะได้

    08-Dec-2013 06:58:54.295 client 192.99.1.168#9118: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
    08-Dec-2013 06:58:54.296 client 192.99.1.168#19072: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)

    08-Dec-2013 06:58:54.297 client 192.99.1.168#31887: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
    08-Dec-2013 06:58:54.297 client 192.99.1.168#41984: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
    08-Dec-2013 06:58:54.297 client 192.99.1.168#58743: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
    08-Dec-2013 06:58:54.297 client 192.99.1.168#31137: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
    08-Dec-2013 06:58:54.300 client 192.99.1.168#28542: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
    08-Dec-2013 06:58:54.300 client 192.99.1.168#2480: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)

    และถ้าแยกตามการ query ก็จะได้

    17489596 adrenalinessss.cc
    543618 ilineage2.ru
    40400 dnsamplificationattacks.cc

    คอลัมน์แรกเป็นจำนวนครั้งของการ query และคอลัมน์ที่สองเป็น domain ที่มีการ query

    จาก config ของ bind9 บนตัว server ที่ setup เอาไว้ทุก query ที่ส่งมาจากภายนอกเครือข่ายของมหาวิทยาลัย มายัง domain ที่อยู่ในรายการข้างบนทั้งหมด จะถูก refused กลับไป

    เอ่อ: _ควรจะ_ refused กลับไป -_-”

    โดยการกำหนด option recursion ให้มีค่าเป็น “no” — config ตัวนี้สำหรับ debian (และ ubuntu?) จะอยู่ในไฟล์ /etc/bind/named.conf.options เพราะถ้า DNS server ไม่ได้ทำหน้าที่เป็น DNS Cache Server ก็ไม่ควรกำหนดให้ค่านี้เป็น yes

    สาเหตุที่มีบรรทัด “เอ่อ: _ควรจะ_ refused กลับไป” ข้างบน เพราะผมเพิ่งพบว่า ค่า config บน server ที่ผมดูแลอยู่มันยัง set ค่าให้เป็น yes อยู่ … เพราะต้องการให้ นศ. ทดสอบการ query จากภายนอกเครือข่าย PSU Net. แล้วลืม set ค่ากลับให้ถูกต้อง

    เพราะฉะนั้นในช่วงหลายวันที่ผ่านมาตัว Server ที่ผมดูแลอยู่ ก็ทำหน้าที่ช่วย DNS Amplification Attack ให้กับ bot ภายนอกอยู่ครับ -_-”

    ประเด็นหนึ่งที่อาจจะเป็นปัญหา สำหรับ DNS Server ภายในเครือข่ายมหาวิทยาลัย สงขลานครินทร์ ที่อาจจะเจอปัญหานี้ก็คือ DNS Server ที่ setup เอาไว้ในหน่วยงาน นอกจากจะใช้เป็น Authorized DNS Server สำหรับ domain ของตัวเองแล้ว DNS ตัวเดียวกันก็ยังทำหน้าที่เป็น DNS Cache Server สำหรับเครื่องคอมพิวเตอร์อื่นๆภายในเครือข่ายของหน่วยงานตนเองด้วย ซึ่งหน้าที่ทั้งสองนี้ควรจะแยกออกจากกัน

    ถ้ายังจำเป็นที่จะต้องใช้ร่วมกัน ก็อาจจะต้องกำหนด view (สำหรับ DNS Server ที่ใช้ bind9) ที่แตกต่างกัน เพื่อให้บริการการ resolve address แบบ DNS Cache Server ให้กับคอมพิวเตอร์ที่อยู่ภายในเครือข่ายของตนเอง และ ไม่ให้บริการการ resolve address อื่นๆ นอกเหนือจาก domain ของหน่วยงานเอง สำหรับเครื่องคอมพิวเตอร์อื่นๆ ที่อยู่นอกเครือข่ายของหน่วยงาน

    ถ้ามีเวลาเดี๋ยวจะกลับมาเขียนเรื่องนี้อีกรอบ แต่ตอนนี้ขอกลับไปเรื่องของ fail2ban ต่อ

    ผมเคยเขียนเรื่องของการ setup fail2ban เพื่อใช้สำหรับการตอบโต้การโจมตีแบบ DOS ซึ่งอยู่ที่นี่ http://sysadmin.psu.ac.th/2012/11/29/using-fail2ban-for-dns-brute-force-attack/

    ซึ่งจะว่าไปก็เป็นวิธีที่ยังมีปัญหาในตัวมันเองอยู่ เพราะการที่จะตอบโต้ได้ เราก็จะต้องรู้ก่อนว่าการโจมตีเป็นแบบใหน หรือในที่นี้ก็คือ domain ที่ query สำหรับการโจมตีคืออะไร

    มีวิธีการที่จะแก้ปัญหานี้โดยใช้ fail2ban ใหม? ผมยังไม่แน่ใจนัก (พอจะมี idea คร่าวๆ แต่ยังไม่ได้เริ่ม implement idea จริงๆ เลยยังไม่รู้ว่าจะใช้ได้จริงใหม)

    แต่ถ้าจะใช้เครื่องมือที่มีอยู่เพื่อแก้ปัญหาในขณะนี้ก่อน นั่นคือ การโจมตีที่เกิดขึ้น มีการ query กับหลายๆ domain ตามนี้

    17489596 adrenalinessss.cc
    543618 ilineage2.ru
    40400 dnsamplificationattacks.cc

    เราจะปรับปรุง config ของ fail2ban ให้รับมือกับจำนวน domain ที่เพ่ิมขึ้นได้อย่างไร?

    ก็โดยการแก้ไข filter โดยเปลี่ยนส่วนของ failregex ให้เป็นแบบนี้ครับ

    failregex = client <HOST>#.+: view theworld: query: ilineage2.ru
    client <HOST>#.+: view theworld: query: apidown.com
    client <HOST>#.+: view theworld: query: adrenalinessss.cc
    client <HOST>#.+: view theworld: query: isc.org
    client <HOST>#.+: view theworld: query: dnsamplificationattacks.cc
    client <HOST>#.+: view theworld: query: fkfkfkfa.com

    ส่วนของ config ไฟล์อื่นๆ และ ส่วนอื่นของ named-query-dos.conf  ก็ยังเหมือนเดิม อ้างอิงตามบันทึกที่แล้วนะครับ

    หลังจากแก้ไขแล้ว เพื่อที่จะ update config ใหม่ สิ่งแรกที่ควรทำ ถ้าหากว่าไฟล์ query.log มีขนาดใหญ่มากก็คือ copy+compress  ไฟล์ query.log เดิมเก็บไว้ก่อน แล้วค่อย restart ตัว fail2ban เพราะว่า ถ้าจะ restart fail2ban เลย ตัว fail2ban จะต้อง process logfile ทั้งหมดใหม่ก่อน ซึ่งจะใช้เวลานานมาก ซึ่งในกรณีของผมไฟล์ขนาด 2GB ทำให้ดูเหมือนกับว่า fail2ban ไม่ยอมทำงานหลังจาก restart แล้ว จนกระทั่งผมตรวจสอบ regex pattern ใหม่จนแน่ใจว่าเขียนถูกต้องแล้ว 2-3 รอบ ถึงจะมาเอะใจเรื่องของขนาดของ logfile ครับ

    วิธีการจัดการกับ query.log file สามารถทำตามขั้นตอนได้ตามนี้ครับ

    $ cd /var/log/named
    $ sudo service bind9 stop; sudo mv query.log query.log.save; sudo service bind9 start
    $ sudo bzip2 query.log.save &
    $ sudo service fail2ban restart

    ซึ่งคาดว่าจะหยุด bot ที่ใช้ในการโจมตีในตอนนี้ได้ชั่วคราว จนกว่าจะมีการ query โดยใช้ domain ใหม่ซึ่งไม่ปรากฏอยู่ใน list เพิ่มขึ้นมา

    ซึ่งตอนนั้น … ค่อยว่ากันอีกที -_-“

  • การใช้ fail2ban สำหรับการตั้งรับ DNS Brute Force Query Attack

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

    หลังจากวิธีการใช้งาน blackhole เพื่อให้ bind9 ไม่ตอบกลับ query ที่ client ส่งมา แล้วพบว่าวิธีการนี้
    จะมีปัญหากับการโจมตีแบบ DDoS ดังนั้น เราก็ต้องรับมือกับการโจมตีแบบนี้ด้วยเครื่องมืออื่นๆแทน

    เครื่องมืที่ผมใช้งานแล้วพบว่ามีประโยชน์มากตัวนึง สำหรับการป้องกันการโจมตีแบบอัตโนมัติก็คือ fail2ban ซึ่งบน Debian/Ubuntu สามารถติดตั้งได้ด้วยคำสั่ง

    $ sudo apt-get install fail2ban

    ซึ่งจะสร้าง configuration file ของ fail2ban ขึ้นมาอยู่ใน directory /etc/fail2ban
    configuration ของ fail2ban จะแบ่งเป็นส่วนของการตรวจจับ (โดยการใช้ regular expression) จาก log file ที่กำหนดไว้ (ซึ่งจะอยู่ใน directory /etc/fail2ban/filter.d)  และสามารถ กำหนด action (ซึ่งจะอยู่ใน directory /etc/fail2ban/action.d) ซึ่งใช้ในการ ban  การเข้าใช้งาน service ของ server ของเรา หรือตอบสนองแบบอื่นๆ เช่นส่ง email ไปเตือน admin ได้ มี action ที่ได้กำหนดเอาไว้แล้วหลายรูปแบบ ในที่นี้ ผมจะเลือกใช้ iptables filter สำหรับการ filter query packet ที่จะเข้ามา ซึ่ง config นี้ จะอยู่ในไฟล์ /etc/fail2ban/action.d/iptables.conf

    ส่วนของการ ตรวจจับ จะมีตัวอย่างของการ เขียน expression เอาไว้แล้วในไฟล์ตัวอย่าง ที่มีอยู่ใน /etc/fail2ban/filter.d ซึ่งสำหรับกรณีนี้ ผมจะสร้างไฟล์ขึ้นมาใหม่ชื่อ named-query-dos.conf โดยจะมีข้อมูลในไฟล์ดังต่อไปนี้

    [Definition]
    failregex = client <HOST>#.+: query: isc.org IN ANY \+ED .+
    ignoreregex =

    โดยบรรทัด failregex จะเป็น regular expression ที่ได้มาจาก logfile /var/log/named/query.log ซึ่งจะมีรูปแบบของการ query ที่แน่นอน นั่นคือ query “isc.org” แบบ ANY และมี flag ของการ query คือ ‘ED’

    28-Nov-2012 11:23:54.063 client 46.160.80.232#25345: query: isc.org IN ANY +ED

    ส่วน filed ของ วันที่/เวลา จะเปลี่ยนไปเรื่อยๆตามเวลาของการ query ที่เกิดขึ้น หมายเลข ip ของ client จะถูก match กับ <HOST> และส่งกลับไปให้ action ซึ่งจะนำเอาไปใช้ต่อไป

    ส่วนของ action เราจะใช้ iptables สำหรับการ filter ซึ่งจะมี config กำหนดเอาไว้แล้ว ซึ่งไม่ต้องวเปลี่ยนแปลงอะไร ส่วนของการ config ที่จะต้องเพิ่มขึ้นมาก็คือ ระบุให้ตัว fail2ban รู้ว่าจะต้องเอา config ส่วนนี้ไปใช้ โดยการเพิ่มข้อมูลต่อไปนี้ เข้าไปในไฟล์ /etc/fail2ban/jail.conf

    [named-query-dos]
    enaled = true
    banaction = iptables
    port = domain,53
    protocol = udp
    filter = named-query-dos
    logpath  = /var/log/named/query.log
    bantime  = 86400
    maxretry = 5

    ซึ่งจาก config ที่เพิ่มเข้าไป (หรืออาจจะสร้างเป็นไฟล์ใหม่ ในชื่อว่า jail.local ก็ได้)
    [named-query-dos] จะเป็นการระบุว่า config ส่วนนี้ เป็การเริ่มต้น section ใหม่
    enabled = true จะระบุว่าให้เอา config นี้ไปใช้ ซึ่งเราสามารถ disable config ส่วนนี้ได้ โดยไม่ต้องลบ config ออก เพียงแต่เปลี่ยนค่า enable = false
    banaction = iptables เป็นการเลือก action ที่จะใช้ ban client ที่เข้ามาโจมตี
    port = domain,53
    protocol = udp
    ทั้ง port และ protocol จะเป็นการระบุข้อมูลการ ban ให้กับ iptables
    filter = named-query-dos เป็นการเลือก filter (match regular express ที่จะใช้ ซึ่งในที่นี้ก็เป็นการอ้างถึงไฟล์ /etc/fail2ban/filter.d/named-query-dos.conf)
    logpath  = /var/log/named/query.log เป็นการระบุชื่อไฟล์ ที่เป็น input ของการ match expression ซึ่งในที่นี้ก็คือไฟล์ ที่เรากำหนดให้ bind9 สร้างขึ้น
    bantime  = 86400 เป็นระยะเวลาที่ unban สำหรับ ip นั้นๆหน่วยเป็นวินาที
    maxretry = 5 จำนวนครั้งของการ query ที่เกิดขึ้น ก่อนที่จะเริ่ม ban

    ในที่นี้ ระยะเวลาของการ ban — bantime ผมกำหนดให้เท่ากับ 24 ชม. ซึ่งนานพอที่จะป้องกันการกลับเข้ามาโจมตีใหม่ในเวลาอันสั้น เราอาจจะไม่ยกเลิกการ ban เลยก็ได้ แต่สำหรับ iptables แล้วมันจะทำให้ tables โตขึ้นเรื่อยๆ ซึ่งจะทำให้การ process packet ช้าลง เพราะฉะนั้นเวลา ban 24 ชม. น่าจะเหมาะสม และถ้ามีการโจมตีเข้ามาอีก ก็จะถูก ban อีกในรอบ 24 ชม.ถัดไป

    maxretry กำหนดค่า default เป็น 3 ผมเพิ่มให้เป็น 5 เพื่อ ยืนยันว่าเป็นการโจมตีจริง ไม่ใช่ query ผิดพลาด ซึ่งอาจจะเกิดขึ้นได้

    หลังจาก config เสร็จแล้ว เราก็สั่งให้ fail2ban เริ่มต้นทำงานได้โดยใช้คำสั่ง

    $ sudo service fail2ban start

    เราสามารถตรวจสอบผลของการทำงานของ fail2ban จาก logfile ได้ โดยการใช้คำสั่ง

    $ sudo tail -f /var/log/fail2ban.log

    เท่าที่ผมใช้อยู่สามารถ จัดการกับการโจมตีที่เกิดขึ้นได้อย่างดีครับ

  • ตั้งรับและตอบโต้การโจมตี 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

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