หลังจากทิ้งไว้นานกว่า 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 เพิ่มขึ้นมา
ซึ่งตอนนั้น … ค่อยว่ากันอีกที -_-“