ใน Firebox System Manager หรือ FSM เราสามารถจะดู CPU ของ XTM ได้ว่า ทำงานที่กี่เปอร์เซ็นต์ (Load) และบางครั้งเราก็เห็นว่า แถบสีนั้นขยับเข้าไปอยู่ในช่องสีแดงหรือบางครั้งก็เต็ม scale หรือที่เรียกว่า CPU 100% utilization
เรื่องที่ไม่น่ากังวล
ด้วย ความที่ Fireware OS เป็น Linux based ซึ่งมี Multi-tasking ที่มีเสถียรภาพสูง ดังนั้น แม้ XTM จะใช้ CPU ถึง 100% แต่ Client ก็ยังคงสามารถจะทะลุออกอินเตอร์เน็ตได้ อาจจะมี Delay เกิดขึ้น แต่ก็ไม่ล้มเหลวโดยสิ้นเชิง
สาเหตุอะไรที่ทำให้ CPU ทำงานหนัก
ส่วน ใหญ่เรามักจะเริ่มแก้ในทันที เช่น แก้ที่ policy ที่เพิ่มเข้าไปใหม่ หรือไม่ก็พยายามถอดสาย reboot หรือถึงกับ reset XTM แล้วเซ็ตใหม่หมดเลยก็มี บางทีก็สงสัยไปที่เฟิร์มแวร์ ก็หาทาง Upgrade บ้างหรือไม่ก็ Downgrade กันไป และหวังว่า มันน่าจะแก้ปัญหาได้ แก้ได้บ้าง ไม่ได้บ้าง บางทีก็แก้ได้ไปสักครู่ แล้ว CPU ก็กลับมาทำงานหนักเหมือนเดิมอีก
คำถามแรกที่ต้องตั้งขึ้นมาก่อนจะลงมือแก้ไข คือ อะไรเป็นเหตุให้ CPU ทำงานหนัก ?
สมมติ ว่า เราใส่ policy เป็นจำนวนมากเข้าไปใน XTM และแต่ละ policy ก็เป็น proxy policy ที่มี setting อันนำไปสู่ processing background อีกปริมาณไม่น้อย แต่ไม่มี packet วิ่งเข้าไปใน XTM เลย CPU ก็จะไม่มีการทำงานใดเกิดขึ้น ต่อให้ใส่ policy เข้าไปใน XTM อีกมากมายแค่ไหน ถ้าไม่มี packet ป้อนเข้าไปใน XTM ก็จะไม่เกิดอะไรขึ้นกับ CPU
เพราะไม่ใช่ เรื่องง่ายที่เราจะมีหลักฐานว่า policy ใดใช้ CPU ไปในสัดส่วนเท่าไหร่ แต่อาจจะง่ายกว่าที่จะดูว่า ในแต่ละวินาทีที่ CPU ทำงานเต็มถึง 100% นั้น มี packet อะไรวิ่งเข้าไปที่ XTM บ้าง แล้วค่อยมาดูว่า packet ในวินาทีนั้น ๆ ไปกระตุ้นให้ policy ใดทำงาน หรือไปกระตุ้นให้ default policy (เช่น Default Thread Protection) ตัวใดทำงาน
CPU ทำงานตามคำสั่งที่กำหนดใน policy (หรือ default policy) และ policy ก็ถูกกระตุ้นโดยการไหลผ่านของ packet การจับดูการไหลของ packet จึงเป็นเบาะแสที่ดีในการระบุสาเหตุที่ทำให้ CPU ทำงานหนัก
วิธีการจับตาดู packet ที่ไหลผ่าน XTM ทำได้ 2 วิธี…
วิธีที่ 1 หากทุก ๆ policy ใน XTM ถูกเซ็ตให้มีการส่ง Log เราก็สามารถใช้ Traffic monitor เพื่อติดตามได้ว่า policy ใดถูกกระตุ้นให้ทำงานบ้าง แต่เราก็จะเห็นเพียงแค่ session initiation เท่านั้น ส่วน stream ของ packet ที่เกิดขึ้นภายใน session ที่ถูกสร้างเอาไว้แล้ว คงจะมองไม่เห็น เช่น session ของ FTP file download จะเป็นการ download ไฟล์ 1 เมกะไบต์ หรือ 100 เมกะไบต์ จำนวน Log ที่ปรากฎใน Traffic policy ก็ไม่แตกต่างกัน
วิธีที่ 2 ใช้ TCP Dump จาก Diagnostic Tasks ของ Traffic Monitor เป็นวิธีที่แม่นยำกว่า ทั้งนี้ ต้องไม่ลืมหลักการในการวิเคราะห์คือ เราจะจับดู packet ที่ไหลผ่าน XTM เฉพาะในช่วงที่ CPU ทำงานหนักเท่านั้น ดังนั้น TCP Dump เพียง 2-3 วินาทีก็ได้ข้อมูลมากพอจะวิเคราะห์ได้แล้ว
เมื่อได้ไฟล์ pcap จาก TCP dump เรามักจะสามารถเห็นสาเหตุที่ทำให้ CPU ทำงานหนักได้อย่างรวดเร็ว
ความเป็นไปได้ - XTM เล็กเกินไป หรือ policy คิดเยอะไป
ใน ไฟล์ pcap ไม่กี่วินาที เราอาจจะได้เห็น packet เป็นจำนวนมาก (หลายร้อยไปจนถึงหลายพัน packet ต่อวินาที) จาก source IP ที่หลากหลายและพยายามจะส่งไปยัง destination IP ที่หลากหลาย มีทั้ง TCP port และ UDP port หลายเลขพอร์ต ทั้ง Trusted-to-External และ External-to-Trusted ซึ่งดูเหมือนเป็นเรื่องปกติในระบบที่มี User เป็นจำนวนมากและ XTM อาจจะทำหน้าที่กั้นระหว่าง LAN และ Server ใน DMZ ทำให้ packet ที่จะต้องวิ่งผ่าน XTM นั้น เป็นการวิ่งทะลุจาก Gigabit ethernet ไปยัง Gigabit ethernet จึงทำให้ปริมาณ packet ต่อวินาทีที่ทะลุผ่าน XTM มีเป็นจำนวนมาก
กรณีนี้ มีอยู่ 2 ประเด็นคือ
packet เหล่านั้นผ่าน policy ที่มีกิจกรรมมากเกินไปหรือเปล่า? อาจ จะเป็น proxy policy ที่เราไม่ได้ต้องการผลจากการตรวจสอบของ policy หรือไม่ เช่น เราสร้าง HTTP proxy policy ขึ้นมา แต่เราไม่เคยสนใจที่จะดู HTTP request และ HTTP response ที่เกิดขึ้น แบบนี้เราควรจะใช้ packet filter policy มากกว่า เพื่อประหยัด CPU ไม่ต้องแบกรับภาระที่ไม่จำเป็นจาก proxy การเปลี่ยนประเภทของ policy แบบนี้ CPU ก็จะลดการทำงานลง XTM ตัวเดิมก็จะรองรับปริมาณ packet ที่ไหลผ่านได้ดีขึ้น
หาก เรามีความจำเป็นจะต้องใช้ policy และ feature ต่าง ๆ ภายใน policy โดยหลีกเลี่ยงไม่ได้ และปริมาณ packet ปกติทำให้ CPU ของ XTM ทำงานมาก ก็ชัดเจนว่า XTM มีขนาดเล็กเกินไปสำหรับความต้องการของระบบ คำตอบคือเราจะต้องอัพเกรด XTM เป็นรุ่นใหญ่ขึ้น ซึ่งทาง WatchGuard ก็มี Trade-up program เข้ามาช่วยประหยัดค่าใช้จ่ายในการอัพเกรดได้มาก
ความเป็นไปได้ - Network ผิดปกติ
ย้อน กลับมาที่ไฟล์ pcap หากเราพบ packet เป็นปริมาณมาก เป็น packet ซ้ำ ๆ กันหลายพันหลายหมื่น packet ต่อวินาที ซ้ำในที่นี้มักจะหมายถึง source IP เดียวกัน destination IP เดียวกัน TCP/UDP port เดียวกัน ถ้านั่นคือการทำงานที่ไม่ปกติของ source IP นั้น ๆ เช่น เกิด loop ในระบบ หรือ source IP นั้นทำ packet flooding เข้ามาใน network ข้อสรุปที่ชัดเจนคือ CPU ของ XTM ทำงานหนักจากความผิดปกติของ network นั่นเอง
การแก้ไขในกรณีนี้ จึงจะเป็นการแก้ไขที่ network หรือ source IP นั้น ๆ หาสาเหตุที่ทำให้เกิดความผิดปกติและจัดการที่ต้นเหตุนั้น
ความเป็นไปได้ - ไม่มีอะไรผิดปกติ XTM แค่ไม่ทันใจ
ใน บางกรณี ข้อมูลจากไฟล์ pcap อาจจะไม่ได้มีปริมาณ packet ต่อวินาทีเป็นจำนวนมาก แต่เราเห็นกิจกรรมที่เกิดขึ้นซ้ำ ๆ กันอย่างไม่ควรจะเป็น เช่น ใน Traffic policy มีการแสดง Denied session ที่ซ้ำ ๆ กันอย่างชัดเจน กรณีนี้เป็น Default policy ที่ทำงานอยู่เบื้องหลังที่คอย Denied packet เมื่อไม่มี policy รองรับ หรือ packet นั้นไปตรงกับเงื่อนไขของ Default Thread Protection กรณีนี้ก็ทำให้ CPU ทำงานหนักได้เหมือนกัน
เราสามารถจะสร้าง policy ขึ้นเพื่อหยุดพฤติกรรมนั้นได้ตั้งแต่เนิ่น ๆ โดยไม่ต้องรอให้ Default policy เข้ามาจัดการ และให้ policy ที่ drop session นั้นอยู่เป็นบรรทัดแรก ๆ ของ policy list ก็ทำให้ CPU ทำงานน้อยลงได้เช่นกัน
ยก ตัวอย่างเช่น บริษัทอาจจะมีนโยบายที่จะเลิกใช้ POP3 protocol เนื่องจากเป็น unencrypted protocol ตามปกติเราก็แค่ไม่สร้าง policy สำหรับ POP3 ก็จะไม่มีใครออกเน็ตด้วย POP3 ได้อยู่แล้ว แต่หากว่าในระบบมี client เป็นจำนวนมากพยายามจะออกเน็ตด้วย POP3 ใน Traffic monitor เราจะเห็น Unhandled packet หลาย ๆ บรรทัดปรากฎขึ้นมา และในไฟล์ pcap เราอาจจะเห็น POP3 packet วิ่งมาที่ XTM อย่างต่อเนื่องหลายร้อย packet ต่อวินาทีจากหลาย ๆ source IP และในขณะเดียวกัน เราก็อาจจะสังเกตเห็น CPU ที่ทำงานมากขึ้น Utilization สูงขึ้น
กรณีนี้เราสามารถตัดไฟแต่ต้นลม โดยการสร้าง policy เอาไว้ที่บรรทัดแรกของ XTM เพื่อ drop POP3 packet ในทันที ไม่ต้องให้ packet ล้ำเข้าไป drop กันที่ Default policy ก็ได้ เป็นการตัดขั้นตอนการทำงานของ CPU ให้สั้นลงได้มาก
ความเป็นไปได้ - ข้อบกพร่องของเฟิร์มแวร์
ข้อมูล จากไฟล์ pcap ไม่ได้แสดงความผิดปกติใด ๆ ปริมาณ packet ต่อวินาทีเป็นปกติ ใน Traffic monitor ไม่ได้พบ session ที่ผิดปกติ และดูจากจำนวน session, bandwidth ฯลฯ ก็ไม่พบความผิดปกติ มีโอกาสเป็นไปได้ที่ความผิดปกตินั้นอาจจะมาจากเฟิร์มแวร์เอง
วิธี ดีที่สุดคือ ให้อัพเกรดเฟิร์มแวร์ของ XTM เป็นเวอร์ชั่นล่าสุดก่อน เพราะปัญหาที่เรากำลังจะพยายามแก้นั้น อาจจะถูกแก้ไปแล้วในเฟิร์มแวร์เวอร์ชั่นใหม่ ๆ
หากอัพเกรด เฟิร์มแวร์ของ XTM เป็นเวอร์ชั่นล่าสุดแล้ว ยังพบปัญหาอยู่ เราควรติดต่อกับ WatchGuard support และส่งไฟล์ Support Log ให้กับ WatchGuard โดยเก็บจาก tab Status Report ใน Firebox System Manager พร้อมกับ Save config file และทำตามคำแนะนำของ WatchGuard support ในลำดับถัด ๆ ไป
แก้ได้ แต่ต้องไม่ตกใจ
เมื่อ CPU ของ XTM ทำงานหนัก มักจะมีผลทำให้ระบบออกเน็ตได้ช้าลง เซิร์ฟเวอร์ที่อยู่หลัง XTM ตอบสนองช้าลง และผู้ดูแลระบบมักแก้ปัญหาเฉพาะหน้าด้วยการ reboot XTM ซึ่งในขณะเดียวกันก็เป็นการทำลายหลักฐานทั้งหมดไปพร้อม ๆ กันด้วย หมดโอกาสที่จะสอบสวนถึงต้นเหตุของปัญหา
อย่างน้อยที่สุด เมื่อ CPU ของ XTM ทำงานหนัก ควรหาทาง capture packet อาจจะ capture จาก mirror port ของสวิตช์หรือจะใช้ TCP dump ใน Traffic monitor ของ FSM ก็ได้ capture packet เอาไว้อย่างน้อย 3-5 วินาที แล้วจึงเริ่มแก้ปัญหาเฉพาะหน้าไป อย่างน้อย เราก็จะได้มีหลักฐานเอาไว้สำหรับการสืบสวนหาสาเหตุ สามารถส่งไฟล์ pcap และ config file ไปให้ผู้เชี่ยวชาญช่วยวิเคราะห์ และนำไปสู่การแก้ปัญหาในที่สุด
แก้แล้ว ไม่หายทันที
เมื่อ เราวิเคราะห์ปัญหา และเริ่มลงมือแก้ปัญหา ไม่ว่าจะด้วยวิธีการใดก็แล้วแต่ เมื่อเรา save config ใหม่เข้าไปที่ XTM ให้พึงรำลึกไว้ว่า CPU ของ XTM จะยังคงทำงานหนักอย่างต่อเนื่องไปอีกระยะเวลาหนึ่งหลังการ save config เข้าไปแล้ว เนื่องจากยังมี packet และ session ที่ยังมีค้างเอาไว้ก่อนการ save config
ดังนั้น เมื่อแก้ config และ save config แล้ว อาจจะต้องรอ อาจจะต้องปลดสาย LAN เพื่อ clear session หรืออาจจะต้อง reboot XTM แล้วแต่กรณี ถ้าเราแก้ได้ถูกจุด เราจะเห็น CPU ลดระดับการทำงานลงมาอยู่ในระดับปกติ
และหากต้องการจะมั่นใจ ว่า การแก้ไขนั้นตรงจุดถูกต้องจริง ๆ เราจะต้องสามารถนำ config เดิม (ก่อนการแก้ไข) หรือสภาพแวดล้อมเดิมกลับมาใช้งาน และมีผลทำให้ CPU กลับมาทำงานหนักเหมือนเดิม ลักษณะนี้จึงจะเรียกว่า เราสามารถควบคุมปัญหาได้แล้ว
ควบคุมปัญหา คือ จะสั่งให้ปัญหาเกิด ก็ทำได้ และจะสั่งให้ปัญหานั้นหยุด ก็ทำได้ เป็นระดับของการจัดการที่เหนือกว่าเพียงการระงับปัญหา
หากต้องการสอบถามข้อมูลเพิ่มเติม รวมถึงปรึกษาการสร้างความปลอดภัยที่เหมาะสมกับคุณ ให้ปลอดภัยจากภัยคุกคามต่างๆ เราพร้อมยินดีให้คำปรึกษาติดต่อได้ที่
Tel : 02-2479898 ต่อ 87
Email : [email protected]
จุดประกายโดย : admin optimus