เรื่องสยองขวัญจากโลกของเครือข่าย

ใกล้ถึงเทศกาลฮาโลวีนแล้ว นี่คือเรื่องสยองขวัญเกี่ยวกับ firewall policy ที่เกิดขึ้นจริง (เพื่ออรรถรส ลองจินตนาการว่าอ่านด้วยน้ำเสียงแหบต่ำชวนขนลุก หรือจะเป็นเสียงของ Morgan Freeman ก็ได้ตามใจ)

ในฐานะ Sales Engineer ผมใช้เวลาส่วนใหญ่ไปกับการสาธิตผลิตภัณฑ์ของเรา และพูดคุยกับ Security Engineer ทีมด้าน compliance ผู้จัดการฝ่าย DevOps และ CISO เกี่ยวกับ firewall และความปลอดภัยของเครือข่าย บางครั้งเรื่องเล่าจากคนที่อยู่หน้างานจริงก็เหลือเชื่อ และบางครั้งก็น่าขนลุกอย่างแท้จริง ต่อไปนี้คือเรื่องเล่าล่าสุดจากลูกค้ารายหนึ่งที่จะทำให้ firewall engineer ทุกคนนอนไม่หลับ

สถานการณ์:
องค์กรแห่งนี้เพิ่งนำแนวคิด “Zero Trust” มาใช้ และทุ่มเวลาอย่างมากเพื่อขยับเข้าใกล้เป้าหมายดังกล่าว ตลอดปีที่ผ่านมาทีมงานมุ่งเน้นไปที่การจัดระเบียบ firewall policy ด้วยการเขียน rule ให้ตรงกับความต้องการทางธุรกิจเท่านั้น ไม่มากไปกว่านั้น คือเปิดเฉพาะ IP และเครือข่ายที่จำเป็นต้องเข้าถึงจริง ๆ ทุกอย่างคืบหน้าไปได้ด้วยดี จนกระทั่งวิศวกรคนหนึ่งพบสิ่งที่น่าสะพรึง นั่นคือ rule “Any – Any – Any – Accept” ที่ซ่อนอยู่กลาง policy

ทีมงานเร่งหาคำตอบว่าเหตุใดจึงมี rule นี้อยู่ ในที่สุดก็พบว่าวิศวกรเครือข่ายระดับจูเนียร์คนหนึ่งสร้าง rule นี้ขึ้นมาเพียงเพราะต้องการให้ระบบใช้งานได้ rule เพียงข้อเดียวนี้ลบล้างความคืบหน้าทั้งหมดที่ทำมาเพื่อเป้าหมาย Zero Trust และเปิดให้เครือข่ายเผชิญความเสี่ยงมหาศาล

แน่นอนว่า rule นี้ต้องถูกลบออก แต่มันอยู่ใน policy โดยไม่มีใครตรวจพบมาแล้วอย่างน้อย 6 เดือน และย่อมอนุญาตทราฟฟิกที่สำคัญต่อธุรกิจอยู่ด้วย ข้อมูล log ยังชี้ว่านี่เป็น rule ที่มีการใช้งานหนักมาก และแน่นอนว่ามันไม่ได้อนุญาตแค่ทราฟฟิกที่สำคัญต่อธุรกิจเท่านั้น แต่มีแนวโน้มสูงที่จะเปิดทางให้ทราฟฟิกที่เป็นอันตรายผ่านเข้ามาด้วย ทีมงานจึงต้องเร่ง remediation ปัญหานี้โดยเร็ว

ขั้นแรก ทีมงานประชุมร่วมกับฝ่ายเครือข่ายและคาดเดากันว่าทราฟฟิกที่วิ่งผ่านน่าจะเป็นอะไรบ้าง ระดมสมองถึงแอปพลิเคชันและทราฟฟิกสำคัญที่ผู้ที่คุ้นเคยกับเครือข่ายพอจะรู้ว่าอาจใช้ rule นี้อยู่ แต่สุดท้ายก็ตัดสินใจว่าต้องกัดฟันลบ rule ออกไป แล้วดูว่าใครจะร้องขึ้นมาบ้าง

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

—

องค์กรของคุณอาจไม่เคยเจอฝันร้ายแบบที่เล่ามาข้างต้น แต่ FireMon ก็ยังช่วยให้งานของคุณง่ายขึ้นได้ด้วยการจัดระเบียบ firewall policy ต่อไปนี้คือแนวทางที่ FireMon ใช้ป้องกันไม่ให้เกิดสถานการณ์ข้างต้น และหากวันหนึ่งคุณพบ rule ที่เปิดกว้างเกินไปอย่างน่ากลัวใน policy ของคุณ อย่าลืมดูข้อ 6 ด้านล่างสำหรับวิธีแก้ปัญหาแบบไม่ต้องเจ็บตัว

1) การแจ้งเตือนและการรายงานด้าน compliance:
เราจะแจ้งเตือนทีมงานทันทีหาก rule ที่เปิดกว้างเกินไปในลักษณะนี้ถูกนำขึ้นใช้งานจริง คุณสามารถ “ปรับระดับ” ได้ว่าจะยอมให้ rule เปิดกว้างได้แค่ไหน เช่น “rule ที่อนุญาตการเข้าถึงปลายทางมากกว่า 60,000 แห่ง” หรือ “rule ที่มี Source ใหญ่กว่าเครือข่าย /16”

2) การแจ้งเตือนการเปลี่ยนแปลง:
rule นี้จะปรากฏในมุมมองแบบ normalized ของเรา ไม่ว่าจะเป็น firewall ของผู้ผลิตรายใด และมองเห็นได้ชัดเจนว่ามีการเพิ่มเข้ามา จึงไม่สามารถ “แอบใส่” เข้ามาได้ วิศวกรและผู้จัดการบางรายเลือกรับรายงานการเปลี่ยนแปลง policy ทางอีเมลโดยอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลง หรือจะรับเป็นสรุปภาพรวมทุกการเปลี่ยนแปลงในรอบ 30 วันก็ได้

3) หากมีเครื่องมืออัตโนมัติของเราอย่าง FireMon Policy Planner อยู่ในระบบ rule ที่มีความเสี่ยงนี้จะถูกสกัดตั้งแต่ต้นทาง ก่อนที่จะถูก push ด้วยซ้ำ ด้วยฟังก์ชัน “pre-change analysis” rule ดังกล่าวจะถูกตรวจพบและทำเครื่องหมายไว้ก่อนที่จะถูก push ขึ้น production แม้แต่แพ็กเก็ตเดียวก็ยังไม่ทันผ่าน นี่คือเหตุผลที่ทีม compliance ชื่นชอบเรา เพราะเราไม่ได้แค่แนะนำ rule ที่ควรสร้างตามความจำเป็นเท่านั้น แต่ยังรันอัลกอริทึมด้าน compliance ของเราก่อนที่จะ push rule โดยอัตโนมัติ เสมือนอยู่ในสภาพแวดล้อมแบบ sandbox ลูกค้าบางรายเลือกใช้ Policy Planner เพียงเพราะฟีเจอร์นี้ และเข้าถึงผ่าน API ของเรา

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

5) ในแง่ของเอกสารประกอบ FireMon ทำหน้าที่เป็นแหล่งข้อมูลอ้างอิงเพียงหนึ่งเดียวสำหรับคำถามอย่าง “ใครเป็นผู้ร้องขอ ใครเป็นเจ้าของแอปพลิเคชัน rule นี้ถูกทบทวนครั้งล่าสุดเมื่อใด” ดังนั้นการกรองและจัดเรียง rule พร้อมเอกสารประกอบจะช่วยให้ตรวจพบกรณีแบบนี้ได้เร็วขึ้นเช่นกัน

6) ข้อนี้เก็บของดีไว้ท้ายสุด หากคุณมี rule ที่เปิดกว้างเกินไปอยู่จริง เช่น กรณีที่ผู้ดูแลคนก่อนใช้แนวทางสร้าง rule แบบ “เปิดกว้าง/ยืดหยุ่น” ต่างจากคุณ เรามีวิธีจัดระเบียบ rule เหล่านี้ได้อย่างง่ายดาย ด้วย Traffic Flow Analysis เครื่องมือของเราจะตรวจสอบทุก IP address ที่วิ่งผ่าน rule นั้น แล้วแยกย่อย any/any/any ออกเป็น flow ที่เฉพาะเจาะจง คุณสามารถส่งออก flow เหล่านี้และสร้าง rule ที่เจาะจงจากข้อมูลดังกล่าวได้