Tag: fail2ban

  • 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