กรณีตัวอย่างการโจมตีที่พบใน access log

 (nishtahir.com)
1 คะแนน โดย GN⁺ 2024-01-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • access log ของ IP สาธารณะที่ทำ self-hosting มานานกว่า 10 ปี เผยให้เห็นความพยายามโจมตีที่บริการซึ่งเปิดสู่อินเทอร์เน็ตได้รับเป็นประจำ ตั้งแต่การค้นหาข้อมูลรับรอง ไปจนถึง command injection ที่มุ่งเป้าอุปกรณ์ IoT
  • รูปแบบที่พบบ่อยที่สุดคือ การค้นหาไฟล์ตั้งค่าและไดเรกทอรี โดยไล่ดูพาธอย่าง .env, .aws/credentials, .git/config, backup/, test/ และบางคำขอใช้ User-Agent ที่สะกดผิด เช่น Mozlila/5.0
  • ความพยายามโจมตี Shellshock ใส่ payload รูปแบบฟังก์ชัน Bash ใน User-Agent เพื่อพยายามอ่าน /etc/passwd และเดาพาธ CGI หลายรายการซ้ำๆ
  • การโจมตีที่มุ่งเป้า LuCI และ Zyxel พยายามแทรกคำสั่งเข้าไปในเว็บอินเทอร์เฟซของเราเตอร์และอุปกรณ์ฝังตัว เพื่อดาวน์โหลดและรันสคริปต์ระยะไกลกับไบนารีสำหรับหลายสถาปัตยกรรม
  • ควรลดสิ่งที่เปิดเผยสู่อินเทอร์เน็ตสาธารณะ ใช้การยืนยันตัวตนและการจำกัด IP กับเครื่องมือหรือไดเรกทอรีที่จำเป็น รักษาอุปกรณ์ IoT ให้เป็นเวอร์ชันล่าสุด และแยกออกจากเครือข่ายสาธารณะหากทำได้

ทราฟฟิกที่บริการซึ่งเปิดสู่อินเทอร์เน็ตสาธารณะได้รับ

  • ตลอดเวลากว่า 10 ปีของการทำ self-hosting ผู้เขียนยังคงมีประสบการณ์ในการเป็นเจ้าของข้อมูลของตัวเองโดยตรง และลดการพึ่งพาแพลตฟอร์มนอกเหนือจาก cloud host
  • เมื่อเปิด IP สู่อินเทอร์เน็ตสาธารณะ จะมี ทราฟฟิกอันตราย จำนวนมากเข้ามาทันที และจาก access log สามารถติดตามได้ว่าช่วงหลังถูกโจมตีแบบใดบ้าง
  • การวิเคราะห์นี้ใกล้เคียงกับข้อสังเกตของนักพัฒนาที่อยากรู้อยากเห็น มากกว่าจะเป็น forensic ของผู้เชี่ยวชาญด้านความปลอดภัย
  • มีการปิดบังที่อยู่ IP ของผู้โจมตีและถ้อยคำดูหมิ่นบางส่วนที่ผู้โจมตีใช้ เพื่อความระมัดระวัง

การค้นหาข้อมูลรับรองและไฟล์ตั้งค่า

  • การโจมตีที่พบบ่อยที่สุดคือความพยายามค้นหา ข้อมูลรับรอง ผ่านการไล่ดูไดเรกทอรี โดยเฉพาะคำขอไฟล์ .env ที่พบจำนวนมาก
    • ตัวอย่างพาธคำขอ ได้แก่ /laravel/.env, /backend/.env, /api/.env, /.env, //.env เป็นต้น
    • โดยทั่วไป .env ถูกมองว่าเป็นไฟล์ที่เก็บ secret ของแอปพลิเคชัน
  • ไฟล์ที่เกี่ยวข้องกับ AWS และการตั้งค่า Git repository ก็อยู่ในเป้าหมายของการค้นหาด้วย
    • ตัวอย่างเช่น /aws.yml, /.env.bak, /info.php, /.aws/credentials, /config/aws.yml, /.git/config เป็นต้น
  • ไดเรกทอรีทั่วไปที่อาจถูกทิ้งไว้โดยไม่ได้ตั้งใจก็ถูกขอซ้ำๆ เช่นกัน
    • ตัวอย่างเช่น /old/, /new/, /test/, /backup/, /temp/ เป็นต้น
  • User-Agent บางรายการมี Mozlila/5.0 ซึ่งดูเหมือนเป็นการสะกดผิดของ Mozilla/5.0
    • ผลลัพธ์ การค้นหาบน GitHub ชี้ว่า typo นี้อาจถูกสร้างจากเครื่องมือที่ใช้กันทั่วไป แล้วถูกคัดลอกและวางต่อๆ กัน
  • ยังพบคำขอที่ค้นหาเครื่องมือเข้าถึงระยะไกลหรือเครื่องมือตั้งค่าด้วย
    • ตัวอย่างเช่น /actuator/gateway/routes, /hudson, /ui/login.action, /?XDEBUG_SESSION_START=phpstorm เป็นต้น
  • ควรเปิดเผยสู่อินเทอร์เน็ตสาธารณะเฉพาะรายการขั้นต่ำที่จำเป็นเท่านั้น และหากจำเป็นต้องเปิดเครื่องมือหรือไดเรกทอรี ควรมี ชั้นการยืนยันตัวตน และหากเป็นไปได้ให้จำกัดเฉพาะ IP บางรายการ

ความพยายามโจมตี Shellshock

  • คำขอหลายรายการดูเหมือนมุ่งเป้าช่องโหว่ Shellshock
  • การโจมตีนี้มุ่งหวังการรันคำสั่งตามอำเภอใจบนเว็บเซิร์ฟเวอร์ที่รันสคริปต์ CGI ด้วย Bash เวอร์ชันที่มีช่องโหว่
    • เมื่อโปรแกรม CGI เริ่มทำงาน จะตั้งค่าตัวแปรสภาพแวดล้อมจากเนื้อหาคำขอ และ HTTP_USER_AGENT เป็นหนึ่งในนั้น
    • หากมีอักขระอย่าง () { :; }; Bash จะตีความว่าเป็นฟังก์ชันที่ต้องรัน
  • ใน User-Agent ของ log จริงมี payload ดังนี้
    • () { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
    • () { ignored; }; เป็นรูปแบบการประกาศฟังก์ชันของ Bash
    • echo Content-Type: text/html; echo ; พิมพ์ Content-Type ของ HTTP response และบรรทัดว่าง
    • /bin/cat /etc/passwd เป็นคำสั่งที่พยายามพิมพ์เนื้อหาของ /etc/passwd ซึ่งมีข้อมูลบัญชีผู้ใช้
  • หากการโจมตีสำเร็จ อาจนำไปสู่การเข้าถึงข้อมูลรับรองผู้ใช้และการรันโค้ดตามอำเภอใจบนเซิร์ฟเวอร์
  • ผู้โจมตีเดาพาธทั่วไป เช่น /cgi-bin/status, /cgi-bin/stats, /cgi-bin/test, /cgi-bin/status/status.cgi, /test.cgi, /debug.cgi, /cgi-bin/test-cgi คล้ายกับการไล่ดูไดเรกทอรี

command injection ที่มุ่งเป้า LuCI

  • คำขอหนึ่งดูเหมือนมุ่งเป้าไปที่ LuCI ซึ่งเป็นเว็บอินเทอร์เฟซสำหรับเราเตอร์ OpenWRT
  • URL โจมตีมีโครงสร้างที่แทรกคำสั่งในฟิลด์ country เพื่อดาวน์โหลดและรันเชลล์สคริปต์ tenda.sh จากเซิร์ฟเวอร์ระยะไกล
    • หลังถอดรหัส URL แล้ว คำสั่งมีลำดับคือย้ายไปที่ /tmp, ลบไฟล์, ใช้ wget ดาวน์โหลดสคริปต์, ให้สิทธิ์รัน แล้วรันสคริปต์
  • สคริปต์ที่ดาวน์โหลดมามีเนื้อหาที่พยายามดาวน์โหลดและรันไบนารีเพิ่มเติม
    • มีชื่อที่ดูเหมือนเป็นสถาปัตยกรรมเป้าหมาย เช่น mips, mpsl, x86_64, arm, arm5, arm6, arm7, i586, i686, powerpc, sh4, m68k, sparc เป็นต้น
    • วิธีที่ลองไบนารีสำหรับหลายสถาปัตยกรรมดูเหมือนเป็นการขยายขอบเขตการโจมตีในสถานการณ์ที่ผู้โจมตีไม่รู้สถาปัตยกรรมของอุปกรณ์เป้าหมาย
  • เพื่อสืบสวนเพิ่มเติม ผู้เขียนดาวน์โหลดไบนารีที่ไม่เข้ากันกับสภาพแวดล้อม แล้วดูด้วย Ghidra
    • ตอนแรกมีเพียง 3 ฟังก์ชัน และมีข้อมูลสตริงไม่มาก
    • ในพื้นที่ข้อมูลขนาดใหญ่พบสตริง $Info: This file is packed with the UPX executable packer และ UPX 3.94
  • เป็นไบนารี ELF ที่ถูกบีบอัดด้วย UPX และหาก header ของ UPX หรือ packed binary ไม่ถูกแก้ไข ก็สามารถคลายได้ด้วย upx -d
    • ในความเป็นจริง หลังรัน upx -d mips ขนาดไฟล์เพิ่มจาก 34932 เป็น 93732 และสามารถตรวจดูสตริงได้มากขึ้น
  • ในสตริงของไบนารีที่คลายแล้วมี M-SEARCH * HTTP/1.1, ST: urn:dial-multiscreen-org:service:dial:1 และ XML payload สำหรับอัปเกรดอุปกรณ์ Huawei
    • สิ่งนี้ดูเหมือนเป็นคำสั่ง UPnP ที่ค้นหาอุปกรณ์ในเครือข่ายซึ่งรองรับ DIAL protocol
    • XML payload ดูเหมือนถูกสร้างให้สแกนอุปกรณ์ Huawei ที่มีช่องโหว่ต่อ command injection
    • พฤติกรรมนี้ดูเหมือนถูกระบุว่าเป็นส่วนหนึ่งของ Mirai botnet
  • ไม่สามารถใช้งานไฟล์ yeye.mips ที่ถูกอ้างถึงได้เมื่อพยายามดึงมา
    • หลังรัน nmap กับเซิร์ฟเวอร์ พบเฉพาะพอร์ตที่เปิดคือ 22/tcp ssh และ 646/tcp filtered ldp

command injection ที่มุ่งเป้า Zyxel

  • อีกคำขอหนึ่งมีคำสั่งเชลล์อยู่ใน GET URL และเมื่อเอา shell substitution ${IFS} ออก จะอยู่ในรูปแบบที่อ่านง่ายขึ้น
    • คำสั่งที่จัดรูปแล้วมีลำดับคือย้ายไปที่ /tmp, ลบไฟล์ *mips*, ดาวน์โหลด huhu.mips, ให้สิทธิ์รัน แล้วรันด้วยอาร์กิวเมนต์ zyxel.selfrep
  • การโจมตีนี้ดูเหมือนมุ่งเป้า exploit ของ zhttpd ในอุปกรณ์ Zyxel
  • ไบนารีครั้งนี้ไม่ได้อยู่ในสถานะ packed จึงสามารถดูสตริงใน Ghidra ได้ทันที
    • ในสตริงพบ M-SEARCH * HTTP/1.1, header ST ที่เกี่ยวข้องกับ DIAL, skyljne.arm, skyljne.arm5, skyljne.arm6, skyljne.arm7, skyljne.mips, skyljne.mpsl, skyljne.x86_64, skyljne.sh4 เป็นต้น
    • ยังมี XML payload ที่มุ่งเป้าอุปกรณ์ Huawei เพื่อดาวน์โหลด huhu.mips และรันเป็น selfrep.huawei
  • อีกสตริงหนึ่งมีคำสั่งที่ส่ง POST ไปยัง /goform/set_LimitClient_cfg
    • พยายามแทรกคำสั่งในพารามิเตอร์ mac พร้อม header Cookie: user=admin เพื่อดาวน์โหลดและรัน huhu.mpsl
    • ตาม บทความของ Akamai ช่องโหว่นี้มุ่งเป้าเราเตอร์ และไม่มีการตรวจสอบยืนยันตัวตนหรือการอนุญาตเป็นพิเศษ จึงถูกใช้โจมตีได้โดยไม่ต้องผ่านการยืนยันตัวตนก่อน
  • ไบนารีนี้ถูกประเมินว่ามีความเป็นไปได้สูงที่จะเป็น agent ของ Mirai botnet
    • แหล่งข้อมูลบางแห่งยังระบุความเป็นไปได้ว่าเกี่ยวข้องกับ Linux Medusa

การรับมือในมุมมองการปฏิบัติการ

  • log ที่ตรวจสอบเป็นเพียงส่วนหนึ่งของทั้งหมด และยังมี exploit อื่นๆ อีกมากที่ถูกลองทุกวัน
  • การรักษาอุปกรณ์ โดยเฉพาะ อุปกรณ์ IoT ให้เป็นเวอร์ชันล่าสุดเป็นสิ่งสำคัญ
  • หากเป็นไปได้ ไม่ควรให้อุปกรณ์ IoT เปิดสู่อินเทอร์เน็ตสาธารณะโดยตรง
  • หากจำเป็นต้องเปิดจริงๆ ควรแยกไว้ใน VLAN ต่างหากให้มากที่สุด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-29
ความคิดเห็นบน Hacker News

  • น่าสนใจที่ผู้โจมตีบางรายดูเหมือนจะเฝ้าดู บันทึก Certificate Transparency เพื่อหาใบรับรองที่ออกใหม่
    ถ้าเปิดเซิร์ฟเวอร์ใหม่ไว้บน IP ใหม่เกินหนึ่งสัปดาห์ บันทึกการเข้าถึงจะเห็นแค่การสแกนแบบสุ่มไม่กี่ครั้ง แต่พอได้รับใบรับรอง Let’s Encrypt ไปประมาณหนึ่งชั่วโมง หลายครั้งก็มีคำขอแบบที่กล่าวถึงในบทความถาโถมเข้ามาเป็นร้อย ๆ รายการ
    สรุปคือบริการใหม่ควรถูกทำให้ปลอดภัยให้เร็วที่สุดเท่าที่ทำได้ และถ้าเป็นไปได้ควรทำตั้งแต่ ก่อนเปิดให้เห็นบนอินเทอร์เน็ต

    • รู้สึกว่าตั้งแต่วินาทีแรกที่เปิดสู่สาธารณะ อย่างน้อยก็ควรวางอะไรอย่าง Basic Authentication ไว้ด้านหน้า
      หรืออาจใช้ CA ของตัวเอง แล้วใช้ใบรับรอง self-signed กับ mTLS จนกว่าจะสลับไปใช้งานจริง
      ตัวอย่างเช่น ถ้าซอฟต์แวร์บางตัวเปิดหน้าติดตั้งเริ่มต้นสำหรับสร้างบัญชีแอดมิน เชื่อมต่อ DB ฯลฯ ออกมาตรง ๆ แบบนั้นจะเสี่ยงกว่าการกำหนดค่าตั้งแต่แรกผ่านตัวแปรสภาพแวดล้อม ไฟล์คอนฟิก หรือเครื่องมือจัดการความลับโดยเฉพาะ
    • ช่วงนี้ลองดูบันทึก Certificate Transparency แล้วสงสัยว่ามีเครื่องมือหรือวิธีที่สะดวกสำหรับ query CT log ไหม
      เช่น ค้นหาโดเมนในช่วงเวลาหนึ่ง
      Merkle Town[0] ของ Cloudflare มีประโยชน์สำหรับดูภาพรวม แต่ยังไม่เจอวิธี query CT log ได้ง่าย ๆ และ ct-woodpecker[1] ก็ดูมีแวว
      [0] https://ct.cloudflare.com/
      [1] https://github.com/letsencrypt/ct-woodpecker
    • การใช้ ใบรับรองไวลด์การ์ด ให้มากขึ้นก็มีประโยชน์ เพราะจะทำให้ระบุซับโดเมนเป้าหมายที่จะโจมตีจาก CT log เพียงอย่างเดียวได้ยากขึ้น
    • หลายกรณีนี่ไม่ใช่ผู้โจมตี แต่เป็น บริการอย่าง urlscan.io ที่เฝ้าดู CT log แล้ว crawl เว็บเพื่อหามัลแวร์มากกว่า
    • ผมโฮสต์บริการเองหลายอย่าง แต่เลิกคิดที่จะเปิดมันออกสู่อินเทอร์เน็ตตรง ๆ ไปโดยสิ้นเชิงแล้ว
      ทุกวันนี้ VPN ดีมากจนสบายใจขึ้นเยอะ และของอย่างโฮสต์รูปหรือแบ็กอัปนี่ไม่อยากเปิดสาธารณะเป็นพิเศษ

  • ตอนเริ่มดูแลเว็บที่โฮสต์เอง ผมเคยดูบันทึกการเข้าถึง และช่วงหนึ่งก็ใช้ ระบบตรวจจับการบุกรุก ที่รวบรวมข้อมูลแล้วแสดงความพยายามโจมตีที่เข้ามา
    สุดท้ายก็เลิกทั้งการตรวจทาน log เชิงรุกและเลิกจ่ายเงินให้ระบบตรวจจับการบุกรุก เพราะเป็นการเสียเวลาและทำให้เสียสมาธิ
    เอกสารที่สรุปช่องโหว่และการโจมตีที่พบบ่อยนั้นหาได้ง่าย ดังนั้นใช้สิ่งนั้นเป็นเกณฑ์ในการดูแลเซิร์ฟเวอร์ก็พอ เทคโนโลยีเว็บเซิร์ฟเวอร์ยอดนิยมแต่ละอย่างมีคู่มือแนวปฏิบัติที่ดีอยู่มากมาย และแค่ทำตามให้ได้ 100% ก็จะนำหน้าผู้โจมตีแทบทั้งหมดไปไกลแล้ว
    สิ่งถัดมาที่ใช้เวลาและทรัพยากรได้คุ้มค่าคือให้ความสำคัญกับ รอบการแพตช์ ที่เร็วที่สุดเท่าที่ทำได้ การโจมตีส่วนใหญ่เล็งช่องโหว่ที่เปิดเผยต่อสาธารณะแล้ว
    เวลาที่ log มีประโยชน์เป็นพิเศษคือหลังเกิดปัญหาแล้วต้องวินิจฉัย ผมเคยใช้ซอฟต์แวร์วิเคราะห์ log เพื่อเก็บและค้นหา จนช่วยหาสาเหตุรากของการโจมตีที่สำเร็จได้ 2–3 ครั้ง และทุกครั้งต้นเหตุคือช่องโหว่ที่รู้จักกันแล้วแต่แพตช์ช้าเกินไป

    • ถ้าทุกกรณีเป็นช่องโหว่ที่รู้จักกันแล้วแต่แพตช์ช้าเกินไป วิธีที่ พึ่งพาแพตช์อย่างเดียว ก็ย่อมล้มเหลวสักวัน อาจเป็นช่องโหว่ 0-day หรือผู้โจมตีอาจเร็วกว่า
      ทางแก้คือการป้องกันหลายชั้น และสำหรับการโฮสต์บริการส่วนตัวเอง ส่วนใหญ่ก็ทำได้ค่อนข้างง่าย
      วางไฟร์วอลล์ไว้ด้านหน้า หรือซ่อนไว้หลัง VPN/Tailscale และถ้าซ่อนไว้ในโฟลเดอร์ย่อยอย่าง /mawer/phpmyadmin/ แทน /phpmyadmin/ ที่การโจมตีอัตโนมัติมักเล็งไว้ 99.9% ก็จะหาไม่เจอ สิ่งนี้เรียกว่า security through obscurity และไม่ควรพึ่งพามันเพียงอย่างเดียว แต่ในฐานะชั้นเสริมแล้วมีประโยชน์มาก
      ควรใส่แอปไว้ใน sandbox และแยกเซิร์ฟเวอร์ออกจากกัน เพื่อให้แม้ถูกเจาะก็ย้ายไปที่อื่นได้ยาก พร้อมทั้งบันทึก log เพื่อให้ตรวจสอบได้ว่ามีการโจมตีหรือไม่และสำเร็จหรือเปล่า
      ประเด็นหลักคือไม่ควรพึ่งพา มาตรการป้องกันเพียงอย่างเดียว ไม่ว่าจะเป็นแพตช์หรือไฟร์วอลล์ สุดท้ายอย่างใดอย่างหนึ่งก็จะล้มเหลว
    • สนใจตรงที่บอกว่าให้ความสำคัญกับรอบการแพตช์ที่เร็วที่สุด อยากรู้ว่าเวลาตัดสินใจว่าเมื่อไรควรแพตช์ ใช้เครื่องมือช่วยหรืออิงตามช่วงเวลา
      ตอนนี้พยายาม[0] อัปเดตแพ็กเกจทุกไตรมาส แต่ถ้ามีเครื่องมือที่แจ้งช่องโหว่ที่รู้จักเพื่อให้ตอบสนองได้ทันทีคงดี
      [0] คำว่า “พยายาม” ในที่นี้หมายถึง ถ้ามีการเปลี่ยนแปลงที่ทำให้เข้ากันไม่ได้และยากจะย้ายไปเวอร์ชันล่าสุด หรือเป็นรีลีส X.0.0 ที่ยังไม่เชื่อถือ ก็อาจอัปเกรดทันทีไม่ได้

  • ผู้เขียนบอกว่าไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย ดังนั้นขอแก้จุดเล็ก ๆ คือ ตัวอย่างช่วงต้นเป็น การค้นหาข้อมูลรับรองและคอนฟิก ไม่ใช่ directory traversal
    เท่าที่รู้ directory traversal เป็นคำที่ใช้กับเทคนิคที่ผู้โจมตี “หลุดออก” จากเว็บรูท หรือหลอกให้เซิร์ฟเวอร์ส่งไฟล์ที่อยู่นอกไดเรกทอรีปกติ

    • ถ้าเป็นวิธีที่รวมไฟล์ซึ่งเดิมไม่ควรถูกโฮสต์ไว้ ก็ในเชิงเทคนิคอาจเป็นได้ทั้งสองอย่าง เช่นกรณี "/../../passwd/etc"

  • อย่างน้อยจากประสบการณ์ของผม ประเด็นสำคัญคือการโจมตีจำนวนมากแบบนี้มาจาก ผู้ปฏิบัติการของรัฐที่เป็นปฏิปักษ์
    อาจเป็นเรื่องถกเถียงได้ แต่การบล็อกทั้งช่วง IP ของประเทศที่เป็นปัญหาและเราไม่มีธุรกิจต้องติดต่อด้วยอาจมีประโยชน์ ผมเคยทำแบบนี้แล้วหยุดความพยายามสแกนที่เข้ามายังบริการใหม่บริการหนึ่งได้ 100%

    • นั่นไม่ใช่ปัญหาหลักหรอก แค่หลายคนไม่อยากบล็อก ผู้ใช้ปกติ ในภูมิภาคนั้นไปด้วยเท่านั้น
    • ถ้าผู้ปฏิบัติการของรัฐไม่มีทางซื้อเซิร์ฟเวอร์ในประเทศอื่นแล้วใช้มันโจมตีได้เลยก็คงดี
    • กว่า 15 ปีก่อน ตอนดู log เซิร์ฟเวอร์ของธุรกิจท้องถิ่นเล็ก ๆ ที่เราโฮสต์อยู่ เราสรุปว่า ที่อยู่ IP ของ APNIC ทั้งหมดบล็อกไปได้เลย
    • การบล็อกตามภูมิภาคสุดท้ายก็แค่กันทราฟฟิกที่ถูกต้อง และทำให้ผู้โจมตีที่ตั้งใจจริงหันไปใช้พร็อกซีไม่ใช่หรือ
    • ถ้าทำอย่างนั้นก็ต้องบล็อก สหรัฐฯ และเนเธอร์แลนด์
      การสแกนที่เข้ามาเซิร์ฟเวอร์ผมส่วนใหญ่มาจากสหรัฐฯ และอันดับสองที่ตามมาห่าง ๆ คือเนเธอร์แลนด์ คงส่วนใหญ่มาจาก AWS และดาต้าเซ็นเตอร์อื่น ๆ

  • ทำงานด้านความปลอดภัยของแอปพลิเคชัน/ผลิตภัณฑ์ และเคยดูแล WAF ของบริษัทระดับมูลค่าหลายพันล้านดอลลาร์มาหลายปี
    แค่ย้าย DNS ไป Cloudflare แล้วใส่กฎ WAF ไว้บนไซต์สักสองสามข้อก็พอ เช่น ถ้าคะแนนบอตต่ำกว่า 2 ก็ให้เจอ managed challenge หรือจัดการเมื่อคะแนนการโจมตีถึงค่าหนึ่ง เป็นต้น ค่าใช้จ่ายก็น่าจะน้อยมาก และจะแก้ปัญหาได้หลายอย่าง
    แต่ก่อนย้ายขึ้นโปรดักชันต้องทดสอบให้แน่ใจ จะมีโดเมนทดสอบไว้สักโดเมนก็ได้ WAF ไม่ใช่คำตอบสารพัดประโยชน์ แต่ใกล้เคียงกับการแก้ขัดชั่วคราวมากกว่า และถ้าตัวแอปเองไม่ได้ถูกเสริมให้ทนต่อการโจมตี ต่อให้ใช้ WAF ขั้นสูงหรือการป้องกันบอตแค่ไหนก็ช่วยไว้ไม่ได้

    • ฝากไว้สำหรับคนที่ไม่คุ้นเคย: https://blog.cloudflare.com/waf-for-everyone/
      ดูเหมือนว่า Free Managed Ruleset จะถูก deploy เป็นค่าเริ่มต้น และ Cloudflare เก็บ change log ไว้ที่นี่: https://developers.cloudflare.com/waf/change-log
    • ในฐานะคนที่โฮสต์เอง ผมใช้ WAF ของ CloudFlare และ กฎ mutual TLS เพื่อปล่อยผ่านเฉพาะผู้เรียกที่ถูกต้องซึ่งผมรู้จักเท่านั้น
      ใช้งานได้ดีมาก เพราะคนที่เข้าถึงมีแค่ครอบครัว การตั้งค่าก็เลยง่าย และแต่ละคนได้รับใบรับรองเฉพาะตัว สามารถเพิกถอนได้เมื่อจำเป็น
    • ทุกวันนี้โดยทั่วไปผมดูแลแค่แอปพลิเคชันสำหรับใช้ภายใน พื้นผิวการโจมตีจึงเล็กกว่าบริการสาธารณะมาก
      ดูเหมือนคุณจะรู้ด้านนี้ดี เลยอยากถามว่าเคยดูแลโซลูชันที่ใช้ Azure infrastructure ร่วมกับ Cloudflare ไหม และถ้าเคย มีจุดไหนที่คนมักมองข้ามบ้าง นอกเหนือจากเรื่องทั่วไปอย่าง OWASP
    • เหมาะกับไซต์ WordPress มาตรฐาน และเสริมอีกชั้นด้วย ปลั๊กอิน GuardGiant และ Sucuri ก็ได้
    • การวาง WAF ไว้หน้าแอปแล้วถือว่าจบ ก็ไม่ต่างจากการทาลิปสติกให้หมู
      ถ้าบริษัทไหนมีเหตุผลบางอย่างที่จำเป็นต้องรันของที่ไม่อัปเดตจริง ๆ มันอาจจำเป็น แต่สุดท้ายก็เป็นแค่การแก้ขัดชั่วคราวเท่านั้น

  • ผมโฮสต์เซิร์ฟเวอร์ HTTP/S 400 บรรทัดที่ออกแบบเองมาประมาณ 1 ปีแล้ว และ ทราฟฟิกโจมตี ที่เข้ามาทางพอร์ตที่เปิดไว้ 3 พอร์ต (22, 80, 443) มีมากจนน่าตกใจ
    แต่ผมยังไม่ได้หาเวลามาวิเคราะห์ว่าผู้โจมตีพยายามจะทำอะไรจริง ๆ บทความนี้ช่วยเติมช่องว่างได้เยอะ
    ถ้าเอาสิ่งแปลก ๆ ที่เห็นใน /var/log/auth.log มาวิเคราะห์แบบเดียวกันก็น่าจะดี
    โค้ดทั้งหมดเป็นโอเพนซอร์ส และฝั่งเซิร์ฟเวอร์ก็ไม่มีสถานะอะไร เลยแปลกใจว่าผู้โจมตีจะเจาะจงผมไปทำไม อย่างดีที่สุดที่ผู้โจมตีจะได้ก็คือสิทธิ์ root บน VPS เดือนละ 5 ดอลลาร์ กับการแก้ไขโดเมนที่ไม่มีใครเข้าแบบชั่วคราวเท่านั้น

    • ทั้งหมดนี้คือ บอตอัตโนมัติ ไม่มีใครมาตั้งใจสนใจเป็นพิเศษหรอก
      ถ้าเปิดพอร์ตที่เป็นที่รู้จักที่สุด 3 พอร์ต ก็จะมีการเชื่อมต่อเข้ามาอยู่แล้ว และพวกมันไม่รู้ด้วยซ้ำว่าคุณรันอะไรอยู่ แถมไม่สนใจด้วย
    • ถ้าเข้าถึง VPN ของคุณได้ ก็เหมาะจะใช้เป็นจุดเริ่มต้นโจมตีเครื่องอื่น และเพิ่มอีกชั้นหนึ่งในการซ่อนร่องรอย
      ยังใช้โฮสต์มัลแวร์หรือรัน เครื่องขุดคริปโต ได้ด้วย
    • สำหรับพอร์ต 22 น่าพิจารณาให้อนุญาตเฉพาะ IP ของตัวเอง และบล็อกที่เหลือ
      ISP ของผมแทบไม่เปลี่ยน IP จริง ๆ และถ้าเปลี่ยน ก็ล็อกอินเข้าแผงผู้ดูแลเว็บโฮสติ้งเพื่ออัปเดตกฎได้

  • ผมรัน fail2ban บนทุกเซิร์ฟเวอร์เสมอ และเพิ่ม custom jail เพื่อจับการโจมตีที่เข้ากับประเภทฟังก์ชันของไซต์ที่เปิดให้ใช้งาน
    แต่ไม่ได้ตรวจมานานแล้วว่าค่าเริ่มต้นอื่น ๆ ของ fail2ban ยังพอจะกันการโจมตีที่พบบ่อยได้หรือไม่ คงต้องบุ๊กมาร์กลิงก์นี้ไว้ดูทีหลัง

    • ถ้ามีช่องโหว่ที่ตกเป็นเป้าได้ง่ายขนาดนี้เปิดอยู่ในระบบ fail2ban ก็ช่วยคุณไม่ได้

  • ผมก็ดู access log ของบริการที่โฮสต์เองเหมือนกัน และมีรายละเอียดหนึ่งที่บทวิเคราะห์นี้ขาดไปอย่างเห็นได้ชัด
    คำขอประสงค์ร้ายจำนวนมากคือคนทั่วไปที่รัน security scanner ซึ่งหาได้ง่ายจากที่อย่าง GitHub โดยมากเป็นการโจมตีที่ไม่ซับซ้อน และอินสแตนซ์ของโปรเจกต์แบบนี้ก็มักจะเคาะเซิร์ฟเวอร์โดยไม่ดู response และไม่สนด้วยว่าถูก rate limit หรือไม่
    การโจมตีบางแบบไม่ได้เล็ง IP โดยตรง แต่เฝ้าดูโดเมนและซับโดเมน แล้วทำสแกนแบบเดิมซ้ำเป็นระยะจากช่วง IP เดียวกัน
    ที่ทำงานเก่าของผมเคยมีการสแกนซ้ำ ๆ จาก IP คงที่เดียวในตุรกี จนทีมเริ่มเรียกกันว่า “ชาวตุรกี” และเมื่อเห็นรูปแบบคำขอแปลก ๆ ขั้นตอนหนึ่งในการตอบสนองเหตุการณ์ก็คือเช็กก่อนว่าคนนั้นกำลังมายุ่งกับบริการของเราหรือไม่

  • ถ้าคุณเห็นล็อกแบบนี้บน AWS ขอแนะนำจริง ๆ ว่าควรวาง AWS WAF ไว้หน้า VPC
    มันไม่แพง และค่อนข้างช่วยลดเรื่องปวดหัวในสถานการณ์แบบนี้ได้มาก ถึงจะไม่ได้บล็อกทุกอย่างก่อนถึงบริการ แต่ก็ช่วยได้มาก

    • เป็นข้อเสนอที่ดี แต่ต้องระวังชุดกฎพื้นฐาน เราเปิด AWS WAF เพราะต้องปฏิบัติตาม SOC 2
      มีกฎบางข้อที่ทำงานแรงเกินไปและทำให้บางส่วนของแอปพังแบบเนียน ๆ
      มีกฎสำหรับ request body ที่บล็อกถ้าในเนื้อหาคำขอมี "localhost" และมีกฎที่บล็อกคำขอที่ไม่มี User-Agent header ด้วย ก่อนหน้านี้เราไม่ได้บังคับให้ API request ต้องมี User-Agent เลยทำให้ API ของผู้ใช้บางรายพังทั้งชุดจนกว่าจะหาสาเหตุเจอ
    • การโจมตีที่กล่าวในบทความไม่น่าจะเป็นปัญหากับเว็บแอปพลิเคชันสมัยใหม่ใด ๆ ดังนั้นผมเลยไม่เข้าใจว่าทำไมต้องเพิ่ม WAF
    • การใช้กฎพื้นฐานของ AWS WAF ไม่ได้ง่ายขนาดนั้น ในแอปพลิเคชันของเรา คำขอและ IP ที่ถูกต้องจำนวนมากถูกบล็อก
      ต้องรู้ว่าอะไรถูกบล็อกและตรวจสอบก่อน ไม่อย่างนั้นบางกรณีจะเสียลูกค้าได้
    • จริง ๆ แล้ว WAF มักให้โทษมากกว่าประโยชน์
      มันถูกเลี่ยงได้ง่ายแต่ทำให้เกิดภาพลวงว่าปลอดภัย มีต้นทุนด้านประสิทธิภาพสูง และมีโอกาสไม่น้อยที่จะบล็อกทราฟฟิกที่ถูกต้อง: https://www.macchaffee.com/blog/2023/wafs/
    • WAF มีแนวโน้มจะบล็อกแบบกว้าง ๆ และบางครั้งเหตุผลก็คลุมเครือ
      เช่น นักวิจัยในมหาวิทยาลัยของเราศึกษาข้อมูล Twitter แต่เพียงเพราะตามลิงก์จากตัวอย่างสุ่มเล็ก ๆ ของทวีต IP ของมหาวิทยาลัยก็ถูก WAF ส่วนใหญ่บล็อก

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