วิวัฒนาการของ Web Application Firewall: จากไฟร์วอลล์ไปจนถึงระบบป้องกันบนคลาวด์พร้อมการเรียนรู้ของเครื่อง

ในเนื้อหาก่อนหน้าของเราเกี่ยวกับหัวข้อระบบคลาวด์ เรา บอก, วิธีปกป้องทรัพยากรไอทีในระบบคลาวด์สาธารณะ และเหตุใดโปรแกรมป้องกันไวรัสแบบเดิมจึงไม่เหมาะสมกับวัตถุประสงค์เหล่านี้โดยสิ้นเชิง ในโพสต์นี้ เราจะพูดถึงหัวข้อความปลอดภัยของระบบคลาวด์ต่อ และพูดคุยเกี่ยวกับวิวัฒนาการของ WAF และตัวเลือกที่ดีกว่า: ฮาร์ดแวร์ ซอฟต์แวร์ หรือระบบคลาวด์ 

WAF คืออะไร

การโจมตีของแฮ็กเกอร์มากกว่า 75% มุ่งเป้าไปที่ช่องโหว่ของเว็บแอปพลิเคชันและเว็บไซต์ การโจมตีดังกล่าวมักจะมองไม่เห็นในโครงสร้างพื้นฐานด้านความปลอดภัยของข้อมูลและบริการด้านความปลอดภัยของข้อมูล ช่องโหว่ในเว็บแอปพลิเคชันในทางกลับกันก็มีความเสี่ยงของการบุกรุกและการฉ้อโกงบัญชีผู้ใช้และข้อมูลส่วนบุคคล รหัสผ่าน และหมายเลขบัตรเครดิต นอกจากนี้ ช่องโหว่ในเว็บไซต์ยังทำหน้าที่เป็นจุดเริ่มต้นสำหรับผู้โจมตีเข้าสู่เครือข่ายองค์กร

Web Application Firewall (WAF) เป็นหน้าจอป้องกันที่บล็อกการโจมตีบนเว็บแอปพลิเคชัน: การแทรก SQL, การเขียนสคริปต์ข้ามไซต์, การเรียกใช้โค้ดจากระยะไกล, การบังคับแบบเดรัจฉานและการบายพาสการอนุญาต รวมถึงการโจมตีที่ใช้ประโยชน์จากช่องโหว่แบบ Zero-day ไฟร์วอลล์แอปพลิเคชันให้การป้องกันโดยการตรวจสอบเนื้อหาหน้าเว็บ รวมถึง HTML, DHTML และ CSS และกรองคำขอ HTTP/HTTPS ที่อาจเป็นอันตราย

การตัดสินใจครั้งแรกคืออะไร?

ความพยายามครั้งแรกในการสร้าง Web Application Firewall เกิดขึ้นในช่วงต้นทศวรรษที่ 90 เป็นที่รู้กันว่าวิศวกรอย่างน้อยสามคนเคยทำงานในสาขานี้ คนแรกคือศาสตราจารย์ด้านวิทยาการคอมพิวเตอร์ Gene Spafford จากมหาวิทยาลัย Purdue เขาอธิบายสถาปัตยกรรมของไฟร์วอลล์แอปพลิเคชันพร็อกซีและตีพิมพ์ในปี 1991 ในหนังสือ "การรักษาความปลอดภัยของ UNIX ในทางปฏิบัติ".

คนที่สองและสามเป็นผู้เชี่ยวชาญด้านความปลอดภัยของข้อมูล William Cheswick และ Marcus Ranum จาก Bell Labs พวกเขาพัฒนาหนึ่งในต้นแบบไฟร์วอลล์แอปพลิเคชันแรกๆ จัดจำหน่ายโดย DEC - ผลิตภัณฑ์นี้เผยแพร่ภายใต้ชื่อ SEAL (Secure External Access Link)

แต่ SEAL ไม่ใช่โซลูชัน WAF เต็มรูปแบบ เป็นไฟร์วอลล์เครือข่ายแบบคลาสสิกพร้อมฟังก์ชันขั้นสูง - ความสามารถในการบล็อกการโจมตี FTP และ RSH ด้วยเหตุนี้ โซลูชัน WAF แรกในปัจจุบันจึงถือเป็นผลิตภัณฑ์ของ Perfecto Technologies (ต่อมาคือ Sanctum) ในปี 1999 เธอ นำเสนอ ระบบแอพชิลด์ ในเวลานั้น Perfecto Technologies กำลังพัฒนาโซลูชันความปลอดภัยของข้อมูลสำหรับอีคอมเมิร์ซ และร้านค้าออนไลน์ก็กลายเป็นกลุ่มเป้าหมายของผลิตภัณฑ์ใหม่ของพวกเขา AppShield สามารถวิเคราะห์คำขอ HTTP และการโจมตีที่ถูกบล็อกโดยอิงตามนโยบายความปลอดภัยของข้อมูลแบบไดนามิก

ในช่วงเวลาเดียวกับ AppShield (ในปี 2002) WAF โอเพ่นซอร์สตัวแรกก็ปรากฏขึ้น เขากลายเป็น ModSecurity. มันถูกสร้างขึ้นโดยมีจุดประสงค์เพื่อทำให้เทคโนโลยี WAF เป็นที่นิยมและยังคงได้รับการสนับสนุนจากชุมชนไอที (นี่คือ พื้นที่เก็บข้อมูลบน GitHub). ModSecurity บล็อกการโจมตีแอปพลิเคชันตามชุดมาตรฐานของนิพจน์ทั่วไป (ลายเซ็น) - เครื่องมือสำหรับตรวจสอบคำขอตามรูปแบบ - ชุดกฎหลักของ OWASP.

เป็นผลให้นักพัฒนาสามารถบรรลุเป้าหมายได้ - โซลูชั่น WAF ใหม่เริ่มปรากฏสู่ตลาดรวมถึงโซลูชั่นที่สร้างขึ้นบนพื้นฐานของ ModSecurity

สามชั่วอายุคนเป็นประวัติศาสตร์ไปแล้ว

เป็นเรื่องปกติที่จะแยกแยะความแตกต่างของระบบ WAF สามรุ่นซึ่งพัฒนาไปพร้อมกับการพัฒนาเทคโนโลยี

รุ่นแรก. ทำงานร่วมกับนิพจน์ทั่วไป (หรือไวยากรณ์) ซึ่งรวมถึง ModSecurity ผู้ให้บริการระบบศึกษาประเภทของการโจมตีแอปพลิเคชันและสร้างรูปแบบที่อธิบายคำขอที่ถูกต้องและอาจเป็นอันตราย WAF จะตรวจสอบรายการเหล่านี้และตัดสินใจว่าจะทำอย่างไรในสถานการณ์เฉพาะ - เพื่อปิดกั้นการรับส่งข้อมูลหรือไม่

ตัวอย่างของการตรวจจับตามนิพจน์ทั่วไปคือโปรเจ็กต์ที่กล่าวถึงแล้ว ชุดกฎหลัก โอเพ่นซอร์ส. ตัวอย่างอื่น - นักซีซึ่งเป็นโอเพ่นซอร์สด้วย ระบบที่มีนิพจน์ทั่วไปมีข้อเสียหลายประการ โดยเฉพาะอย่างยิ่งเมื่อมีการค้นพบช่องโหว่ใหม่ ผู้ดูแลระบบจะต้องสร้างกฎเพิ่มเติมด้วยตนเอง ในกรณีของโครงสร้างพื้นฐานด้านไอทีขนาดใหญ่ อาจมีกฎเกณฑ์หลายพันข้อ การจัดการนิพจน์ทั่วไปจำนวนมากนั้นค่อนข้างยาก ไม่ต้องพูดถึงความจริงที่ว่าการตรวจสอบสามารถลดประสิทธิภาพของเครือข่ายได้

นิพจน์ทั่วไปยังมีอัตราผลบวกลวงที่ค่อนข้างสูงอีกด้วย นักภาษาศาสตร์ชื่อดัง Noam Chomsky เสนอการจำแนกไวยากรณ์โดยแบ่งความซับซ้อนออกเป็นสี่ระดับตามเงื่อนไข ตามการจัดหมวดหมู่นี้ นิพจน์ทั่วไปสามารถอธิบายกฎไฟร์วอลล์ที่ไม่เกี่ยวข้องกับการเบี่ยงเบนไปจากรูปแบบเท่านั้น ซึ่งหมายความว่าผู้โจมตีสามารถ "หลอก" WAF รุ่นแรกได้อย่างง่ายดาย วิธีหนึ่งในการต่อสู้กับสิ่งนี้คือการเพิ่มอักขระพิเศษลงในคำขอแอปพลิเคชันที่ไม่ส่งผลกระทบต่อตรรกะของข้อมูลที่เป็นอันตราย แต่ละเมิดกฎลายเซ็น

รุ่นที่สอง. เพื่อหลีกเลี่ยงปัญหาด้านประสิทธิภาพและความแม่นยำของ WAF จึงได้มีการพัฒนาแอพพลิเคชั่นไฟร์วอลล์รุ่นที่สองขึ้น ขณะนี้พวกเขามีตัวแยกวิเคราะห์ที่รับผิดชอบในการระบุประเภทการโจมตีที่กำหนดไว้อย่างเคร่งครัด (บน HTML, JS ฯลฯ ) ตัวแยกวิเคราะห์เหล่านี้ทำงานร่วมกับโทเค็นพิเศษที่อธิบายการสืบค้น (เช่น ตัวแปร สตริง ไม่ทราบ หมายเลข) ลำดับโทเค็นที่อาจเป็นอันตรายจะถูกจัดไว้ในรายการแยกต่างหาก ซึ่งระบบ WAF จะตรวจสอบเป็นประจำ วิธีการนี้แสดงให้เห็นครั้งแรกในการประชุม Black Hat 2012 ในรูปแบบของ C/C++ ไลบรารี libinjectionซึ่งช่วยให้คุณตรวจจับการฉีด SQL ได้

เมื่อเปรียบเทียบกับ WAF รุ่นแรก ตัวแยกวิเคราะห์เฉพาะจะเร็วกว่า อย่างไรก็ตาม พวกเขาไม่ได้แก้ไขปัญหาที่เกี่ยวข้องกับการกำหนดค่าระบบด้วยตนเองเมื่อมีการโจมตีที่เป็นอันตรายใหม่ปรากฏขึ้น

รุ่นที่สาม. วิวัฒนาการในตรรกะการตรวจจับรุ่นที่สามประกอบด้วยการใช้วิธีการเรียนรู้ของเครื่องที่ทำให้สามารถนำไวยากรณ์การตรวจจับให้ใกล้เคียงกับไวยากรณ์ SQL/HTML/JS จริงของระบบที่ได้รับการป้องกันมากที่สุด ตรรกะการตรวจจับนี้สามารถปรับเครื่องทัวริงให้ครอบคลุมไวยากรณ์ที่นับได้แบบเรียกซ้ำ ยิ่งไปกว่านั้น ก่อนหน้านี้งานสร้างเครื่องจักรทัวริงที่ปรับเปลี่ยนได้นั้นไม่สามารถแก้ไขได้จนกว่าจะมีการเผยแพร่การศึกษาเกี่ยวกับเครื่องจักรทัวริงประสาทครั้งแรก

การเรียนรู้ของเครื่องมอบความสามารถพิเศษในการปรับไวยากรณ์ให้ครอบคลุมการโจมตีทุกประเภท โดยไม่ต้องสร้างรายการลายเซ็นด้วยตนเองตามที่จำเป็นในการตรวจจับรุ่นแรก และไม่ต้องพัฒนาโทเค็น/พาร์เซอร์ใหม่สำหรับการโจมตีประเภทใหม่ เช่น Memcached, Redis, Cassandra, SSRF injectors ตามที่กำหนดโดยระเบียบวิธีรุ่นที่สอง

ด้วยการรวมลอจิกการตรวจจับทั้งสามรุ่นเข้าด้วยกัน เราสามารถวาดไดอะแกรมใหม่โดยแสดงการตรวจจับรุ่นที่สามด้วยโครงร่างสีแดง (รูปที่ 3) รุ่นนี้ประกอบด้วยหนึ่งในโซลูชันที่เราใช้งานในระบบคลาวด์ร่วมกับ Onsek ผู้พัฒนาแพลตฟอร์มสำหรับการป้องกันแบบปรับเปลี่ยนได้ของเว็บแอปพลิเคชันและ Wallarm API

ขณะนี้ตรรกะการตรวจจับใช้ผลตอบรับจากแอปพลิเคชันเพื่อปรับแต่งตัวเอง ในแมชชีนเลิร์นนิง ฟีดแบ็กลูปนี้เรียกว่า "การเสริมกำลัง" โดยทั่วไปแล้ว การเสริมแรงดังกล่าวมีหนึ่งประเภทขึ้นไป:

• การวิเคราะห์พฤติกรรมการตอบสนองของแอปพลิเคชัน (พาสซีฟ)
• สแกน/ฟิวเซอร์ (ใช้งานอยู่)
• รายงานไฟล์/ขั้นตอนสกัดกั้น/กับดัก (ภายหลังข้อเท็จจริง)
• คู่มือ (กำหนดโดยหัวหน้างาน)

ด้วยเหตุนี้ ตรรกะการตรวจจับรุ่นที่สามจึงจัดการปัญหาที่สำคัญด้านความแม่นยำด้วย ขณะนี้ไม่เพียงแต่จะหลีกเลี่ยงผลบวกลวงและผลลบลวงเท่านั้น แต่ยังสามารถตรวจสอบผลลบจริงที่ถูกต้องได้ด้วย เช่น การตรวจหาการใช้องค์ประกอบคำสั่ง SQL ในแผงควบคุม การโหลดเทมเพลตหน้าเว็บ คำขอ AJAX ที่เกี่ยวข้องกับข้อผิดพลาด JavaScript และอื่นๆ

ต่อไป เราจะพิจารณาความสามารถทางเทคโนโลยีของตัวเลือกการใช้งาน WAF ต่างๆ

ฮาร์ดแวร์ ซอฟต์แวร์ หรือคลาวด์ - จะเลือกอะไรดี?

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

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

ตัวเลือกที่สามคือการตั้งค่า WAF จากคลาวด์ ผู้ให้บริการคลาวด์ให้บริการโซลูชันดังกล่าวในรูปแบบบริการสมัครสมาชิก บริษัทไม่จำเป็นต้องซื้อและกำหนดค่าฮาร์ดแวร์พิเศษ งานเหล่านี้ตกเป็นภาระของผู้ให้บริการ จุดสำคัญคือ WAF บนคลาวด์สมัยใหม่ไม่ได้หมายความถึงการย้ายทรัพยากรไปยังแพลตฟอร์มของผู้ให้บริการ ไซต์นี้สามารถติดตั้งได้ทุกที่ แม้แต่ในองค์กร

เราจะอธิบายเพิ่มเติมว่าเหตุใดผู้คนจึงหันมาสนใจ Cloud WAF มากขึ้น

WAF ทำอะไรได้บ้างในระบบคลาวด์

ในแง่ของความสามารถทางเทคโนโลยี:

• ผู้ให้บริการมีหน้าที่รับผิดชอบในการอัพเดต. WAF ให้บริการโดยการสมัครสมาชิก ดังนั้นผู้ให้บริการจึงตรวจสอบความเกี่ยวข้องของการอัพเดตและใบอนุญาต การอัปเดตไม่เพียงเกี่ยวข้องกับซอฟต์แวร์เท่านั้น แต่ยังรวมถึงฮาร์ดแวร์ด้วย ผู้ให้บริการอัปเกรดที่จอดเซิร์ฟเวอร์และบำรุงรักษา นอกจากนี้ยังรับผิดชอบในการจัดสรรภาระงานและความซ้ำซ้อน หากเซิร์ฟเวอร์ WAF ล้มเหลว การรับส่งข้อมูลจะถูกเปลี่ยนเส้นทางไปยังเครื่องอื่นทันที การกระจายการรับส่งข้อมูลอย่างมีเหตุผลช่วยให้คุณหลีกเลี่ยงสถานการณ์เมื่อไฟร์วอลล์เข้าสู่โหมดเปิดที่ล้มเหลว - ไม่สามารถรับมือกับโหลดและหยุดการกรองคำขอ
• การแพตช์เสมือน. โปรแกรมแก้ไขเสมือนจะจำกัดการเข้าถึงส่วนที่ถูกบุกรุกของแอปพลิเคชันจนกว่านักพัฒนาจะปิดช่องโหว่ เป็นผลให้ลูกค้าของผู้ให้บริการคลาวด์ได้รับโอกาสในการรออย่างใจเย็นจนกว่าซัพพลายเออร์ของซอฟต์แวร์นี้หรือซอฟต์แวร์นั้นจะเผยแพร่ "แพตช์" อย่างเป็นทางการ การดำเนินการนี้โดยเร็วที่สุดถือเป็นเรื่องสำคัญสำหรับผู้จำหน่ายซอฟต์แวร์ ตัวอย่างเช่น ในแพลตฟอร์ม Wallarm โมดูลซอฟต์แวร์แยกต่างหากจะรับผิดชอบในการแพตช์เสมือน ผู้ดูแลระบบสามารถเพิ่มนิพจน์ทั่วไปที่กำหนดเองเพื่อป้องกันคำขอที่เป็นอันตราย ระบบทำให้สามารถทำเครื่องหมายคำขอบางรายการด้วยแฟล็ก "ข้อมูลที่เป็นความลับ" จากนั้นพารามิเตอร์จะถูกปิดบัง และจะไม่ถูกส่งออกไปนอกพื้นที่ทำงานของไฟร์วอลล์ไม่ว่าในกรณีใดก็ตาม
• เครื่องสแกนขอบเขตและช่องโหว่ในตัว. สิ่งนี้ช่วยให้คุณกำหนดขอบเขตเครือข่ายของโครงสร้างพื้นฐานด้านไอทีได้อย่างอิสระโดยใช้ข้อมูลจากคำสั่ง DNS และโปรโตคอล WHOIS หลังจากนั้น WAF จะวิเคราะห์บริการที่ทำงานอยู่ภายในขอบเขตโดยอัตโนมัติ (ทำการสแกนพอร์ต) ไฟร์วอลล์สามารถตรวจจับช่องโหว่ทั่วไปทุกประเภท - SQLi, XSS, XXE ฯลฯ - และระบุข้อผิดพลาดในการกำหนดค่าซอฟต์แวร์ เช่น การเข้าถึงที่เก็บ Git และ BitBucket โดยไม่ได้รับอนุญาต และการเรียก Elasticsearch, Redis, MongoDB โดยไม่ระบุชื่อ
• การโจมตีได้รับการตรวจสอบโดยทรัพยากรคลาวด์. ตามกฎแล้ว ผู้ให้บริการคลาวด์มีพลังการประมวลผลจำนวนมาก สิ่งนี้ช่วยให้คุณวิเคราะห์ภัยคุกคามได้อย่างแม่นยำและรวดเร็ว คลัสเตอร์ของโหนดตัวกรองถูกปรับใช้ในระบบคลาวด์ ซึ่งการรับส่งข้อมูลทั้งหมดจะผ่านไป โหนดเหล่านี้จะบล็อกการโจมตีบนเว็บแอปพลิเคชันและส่งสถิติไปยังศูนย์การวิเคราะห์ ใช้อัลกอริธึมการเรียนรู้ของเครื่องเพื่ออัปเดตกฎการบล็อกสำหรับแอปพลิเคชันที่ได้รับการป้องกันทั้งหมด การดำเนินการตามโครงการดังกล่าวแสดงไว้ในรูปที่ 4 XNUMX. กฎความปลอดภัยที่ได้รับการปรับแต่งดังกล่าวจะช่วยลดจำนวนการแจ้งเตือนไฟร์วอลล์ที่ผิดพลาด

ตอนนี้เล็กน้อยเกี่ยวกับคุณสมบัติของ Cloud WAF ในแง่ของปัญหาองค์กรและการจัดการ:

• การเปลี่ยนไปใช้ OpEx. ในกรณีของ Cloud WAF ค่าใช้จ่ายในการใช้งานจะเป็นศูนย์ เนื่องจากผู้ให้บริการได้ชำระเงินฮาร์ดแวร์และใบอนุญาตทั้งหมดแล้ว การชำระค่าบริการจะดำเนินการโดยการสมัครสมาชิก
• แผนภาษีที่แตกต่างกัน. ผู้ใช้บริการคลาวด์สามารถเปิดหรือปิดใช้งานตัวเลือกเพิ่มเติมได้อย่างรวดเร็ว ฟังก์ชันได้รับการจัดการจากแผงควบคุมเดียวซึ่งมีความปลอดภัยเช่นกัน เข้าถึงได้ผ่าน HTTPS นอกจากนี้ยังมีกลไกการตรวจสอบสิทธิ์แบบสองปัจจัยที่ใช้โปรโตคอล TOTP (อัลกอริทึมรหัสผ่านครั้งเดียวตามเวลา)
• การเชื่อมต่อผ่าน DNS. คุณสามารถเปลี่ยน DNS ได้ด้วยตัวเองและกำหนดค่าการกำหนดเส้นทางเครือข่าย เพื่อแก้ไขปัญหาเหล่านี้ ไม่จำเป็นต้องรับสมัครและฝึกอบรมผู้เชี่ยวชาญเป็นรายบุคคล ตามกฎแล้ว ฝ่ายสนับสนุนด้านเทคนิคของผู้ให้บริการสามารถช่วยในการตั้งค่าได้

เทคโนโลยี WAF พัฒนาจากไฟร์วอลล์ธรรมดาที่มีกฎง่ายๆ ไปสู่ระบบการป้องกันที่ซับซ้อนด้วยอัลกอริธึมการเรียนรู้ของเครื่อง ปัจจุบันไฟร์วอลล์แอปพลิเคชันนำเสนอคุณสมบัติที่หลากหลายซึ่งยากต่อการใช้งานในยุค 90 ในหลาย ๆ ด้าน การเกิดขึ้นของฟังก์ชันการทำงานใหม่เกิดขึ้นได้ด้วยเทคโนโลยีคลาวด์ โซลูชัน WAF และส่วนประกอบต่างๆ มีการพัฒนาอย่างต่อเนื่อง เช่นเดียวกับการรักษาความปลอดภัยของข้อมูลด้านอื่นๆ

ข้อความนี้จัดทำโดย Alexander Karpuzikov ผู้จัดการฝ่ายพัฒนาผลิตภัณฑ์ความปลอดภัยของข้อมูลที่ผู้ให้บริการคลาวด์ #CloudMTS

ที่มา: will.com