Single Sign On แบบไม่เหนื่อย ปรับ Windows Firewall Rule ด้วย Group Policy

เมื่อ Firebox ได้รับ Packet จาก Trusted Interface ตาม Routing table ใน Firebox ในเวลานั้น กำหนดให้ Packet นั้นจะต้องถูกส่งออกไปทาง External Interface และที่ XTM ก็มี Firebox เปิดทำงานอยู่ คือได้มีการป้อน IP ของ SSO Agent เอาไว้ใน Firebox

SSO Agent เป็นซอฟต์แวร์ตัวเล็กมาก ซึ่งส่วนใหญ่เราจะนำไปติดตั้งกับ AD server

Firebox จะติดต่อกับ SSO Agent นี้เพื่อถามว่า Source IP ของ Packet นี้คือ User อะไร ซึ่ง Agent จะใช้หลาย ๆ วิธีในการค้นหาว่า Username ใดเป็นเจ้าของหมายเลข IP ดังกล่าว วิธีหนึ่งในนั้นก็คือ การติดต่อกับ Event log monitor

Event Log monitor เป็นส่วนหนึ่งของ SSO Agent ที่จะสามารถติดตั้งแยกตัวออกจาก SSO Agent ก็ได้ แต่เรามักจะติดตั้ง SSO Agent และ Event Log monitor ในเครื่องเดียวกัน และติดตั้งลงไปพร้อม ๆ กัน

ขั้นตอนคือ Firebox ถามไปที่ SSO Agent และ SSO Agent ถามไปที่ Event Log monitor จากนั้น Event Log monitor ก็จะติดต่อไปที่ Client ตามหมายเลข Source IP ของ packet นั้นที่พอร์ต 445 เพื่อดูใน Log ของ Client ว่าใช้ Username อะไร Login เข้า มาที่ AD

โดยสรุปคือ เราจะใช้ Event Log monitor อย่างได้ผล SSO สามารถแสดงชื่อของ Logon client ได้อย่างถูกต้องครบทุก User เราจะต้องเปิดพอร์ต TCP-445 ที่ Client เอาไว้นั่นเอง

การเปิดพอร์ต TCP-445 นั้น จะเดินไปทำทีละ Client ก็ได้ ก็คือ Logon เข้าไปที่ Client ด้วย User ที่มี Administrative right (ง่ายสุดก็คือ Logon ด้วย administrator account) จากนั้นก็ไปแก้ Firewall ที่ Client เครื่องนั้นให้เปิด TCP-445 หรือจะเปิด File and Print sharing เลยก็ได้ เท่านี้ก็เรียบร้อย…สำหรับ 1 เครื่อง

แต่ถ้าเรามี Client หลายสิบเครื่องหรือหลายร้อยเครื่อง การมาเปิดพอร์ต TCP-445 ทีละเครื่อง คงจะทำไม่ไหว เราจะต้องใช้ Group policy เข้ามาช่วย

Group Policy Object ที่ใช้สำหรับการเซ็ต Firewall มีเส้นทางตามภาพด้านล่างนี้

และเมื่อเปิดเข้าไปที่ Property ของ “Define port exceptions” ก็จะพบว่า การป้อน Exception TCP-445 นั้น เราจะต้องเขียนข้อความในรูปแบบเฉพาะ คือ “<Port>:<Transport>:<Scope>:<Status>:<Name>”

หากเราต้องการจะเปิด Firewall ที่ Client ให้เปิดพอร์ต 445 เราจะต้องป้อนว่า 445:TCP:*:enabled:WG-SSO”

แต่ เนื่องจากพอร์ต TCP-445 เป็นพอร์ต SMB ของ Windows ซึ่งมักจะตกเป็นเป้าโจมตีของ Malware ทั้งหลาย หากคิดจะเปิด TCP-445 บนเครื่อง Client ก็ควรจะเปิดเป็นช่วงแคบ ๆ อนุญาตให้เฉพาะ AD server เท่านั้นที่เข้าถึง TCP-445 บน Client ได้

สมมติว่า AD server มี IP 192.168.0.10 เราก็จะใส่ใน Group policy แบบนี้
“445:TCP:192.168.0.10:enabled:WG-SSO”

ป้อนเสร็จแล้วก็ Save Group policy ให้เรียบร้อย

ปกติ แล้ว เรามักจะคุ้นเคยกับ Group policy object ที่ link เข้ากับ Organization Unit หรือ OU ที่เป็น User OU ใน AD แต่ถ้าสังเกตให้ดี จะเห็นว่า Group Policy Object หรือ GPO ที่เพิ่งสร้างเสร็จไปนี้ ไม่ได้อยู่ในโครงสร้างของ User Configuration แต่อยู่ในภาคของ Computer Configuration

หมายความว่า เราจะต้อง Link GPO นี้ไปที่ Computer OU ด้วย

ใน Active Directory Users and Computers จะเห็นว่ามี OU สำหรับคอมพิวเตอร์รออยู่แล้ว นั่นคือ “Computers” แต่เมื่อเราพยายามจะ Link OU นี้เข้าไปที่ GPO ที่เราสร้างขึ้นโดยใช้ Group policy manager จะเห็นว่า ไม่มี OU ชื่อ Computers ให้เลือก

ก็เพราะว่า Computers OU นั้นเป็น System object ที่ไม่อนุญาตให้มี GPO ใด ๆ เข้าไปควบคุมได้

หาก เราต้องการจะให้ Group policy เข้าไปควบคุม Firewall policy ที่เครื่อง Client เราจะต้องสร้าง Computer OU ขึ้นมาเอง และย้าย Client Computer จาก Computers OU มาใส่ใน Computer OU ที่เราสร้างขึ้นใหม่ จากนั้นจึงค่อย Apply GPO เข้าไป

เมื่อ Client เปิดเครื่องขึ้นมาใหม่ ก็จะได้รับ Group policy ใหม่ไปใช้ Client จะเริ่มเปิดพอร์ต TCP-445 ให้กับ AD server ซึ่งจะทำให้ Event log monitor สามารถตรวจสอบชื่อของ Logon user ได้อย่างถูกต้อง และทำให้ SSO สามารถทำงานได้อย่างสมบูรณ์ทั้งระบบในคราวเดียว

CPU ขึ้นถึง 100 เพราะอะไร แกะที่ไหน แก้อย่างไร

ใน 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 

จุดประกายโดย : admin optimus

Firmware ใหม่ จะอัพเดตเลย หรือจะรอ

GA ย่อมาจาก General Availability และ MR ย่อมาจาก Maintenance Release ซึ่งเวลาที่ทาง Vendor เขาจะนำเฟิร์มแวร์ใหม่เข้าสู่ตลาด เขาจะปล่อยเวอร์ชั่น GA ออกมาก่อน

เมื่อเวลาผ่านไป อาจจะมีการแก้ไขข้อบกพร่องที่พบในเวอร์ชั่น GA ตามที่ได้รับแจ้งจากลูกค้า หรืออาจจะมีฟีเจอร์หรือการแก้ไขอื่น ๆ ที่อยู่ในรายการผลิตอยู่แล้ว แต่ทำไม่ทันใน เวอร์ชั่น GA สิ่งต่าง ๆ เหล่านี้ ก็จะถูกใส่เพิ่มเข้ามาในทีหลัง และออกเฟิร์มแวร์เวอร์ชั่นตามมา เป็นเวอร์ชั่น MR

ไม่มีความเสี่ยงที่จะใช้เวอร์ชั่น GA ไม่ได้แปลว่า GA คือเวอร์ชั่นหนูทดลอง ทุก ๆ เวอร์ชั่นคือความรับผิดชอบของ Vendor ผ่านการทดสอบ ผ่าน QA process ผ่านขบวนการตรวจสอบอีกมากมาย ดังนั้น เราสามารถใช้เวอร์ชั่น GA ได้อย่างปลอดภัย

แต่หากระบบของคุณสามารถรอได้ อ่านจาก Release note ของเวอร์ชั่นนั้น ๆ แล้วก็ไม่พบว่า จะต้องอัพเกรดเฟิร์มแวร์อย่างเร่งด่วน การรอเวอร์ชั่น MR ก็นับเป็นความคิดที่ดี

รู้อย่างนี้แล้ว ในครั้งถัดไปที่จะอัพเกรดเฟิร์มแวร์

1. เลือกว่าจะใช้ GA หรือ MR

2. อ่าน Release note ครับ Vendor เขาบอกทุกอย่างในนั้น สิ่งที่แก้ไข สิ่งที่เพิ่มใหม่ สิ่งที่ไม่ได้แก้ ปัญหาที่ทราบอยู่แล้ว เงื่อนไขการ upgrade/downgrade ทุกอย่างจิปาถะที่ควรทราบ โปรดอ่าน Release note ก่อนการอัพเกรดครับ

3. วางแผนการอัพเกรด ก็ขึ้นอยู่กับความวิกฤตของระบบ ระบบที่ยิ่งแบกรับความวิกฤตของธุรกิจได้มาก ก็ต้องวางแผนการ Upgrade ให้มากและรอบคอบ

GA มักจะเป็นการก้าวกระโดดของเวอร์ชั่นหลัก เช่น 10.0 ไปเป็น 10.1 หรืออาจจะเป็นก้าวใหญ่ (Major change) เช่น 10.0 เป็น 11.0 ส่วน MR มักจะเป็นก้าวเล็ก ๆ ที่เป็นการปรับแต่งส่วนประกอบ เช่น 10.0.1 เป็น 10.0.2 เป็นต้น ถ้าจะเน้นว่าไม่อยากอัพเกรดบ่อย และเมื่ออ่านจาก Release note แล้วก็ไม่พบสิ่งที่จำเป็นเร่งด่วน ในการอัพเกรด เราสามารถอัพเกรดเป็น Last MR ได้ เช่น ปัจจุบันใช้ 10.0.2 และมีเวอร์ชั่น GA ออกมาใหม่เป็น 10.1 ออกใหม่ ในระหว่างนั้น ก็มีเวอร์ชั่น MR ตามออกมาเรื่อย ๆ 

ติดตั้ง VPN กันแล้ว อย่าลืมนึกถึงเรื่องความปลอดภัยนะ

ติดตั้ง VPN กันแล้ว อย่าลืมนึกถึงเรื่องความปลอดภัยนะ

ตั้งแต่มีข่าวว่า กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม หรือ DES ปิดระงับการใช้เว็บไซต์ Pornhub  ในประเทศไทย ก็มีรายงานว่า ยอดติดตั้ง VPN ในไทยพุ่งขึ้นถึง 644% กันเลยทีเดียว (ข้อมูลจากอัตราการติดตั้งเฉลี่ย 30 วัน) ทั้งนี้ มีรายงานว่า ก่อนหน้านี้ การใช้ VPN ในประเทศไทยยังไม่ได้รับความนิยมมากนัก และได้เปิดเผยข้อมูลว่าที่ผ่านมาคนไทยใช้ VPN เฉลี่ยเพียง 1.17% หรือ 1 คนจาก 85 คนเท่านั้น

แหล่งข่าวยังมีการรายงานเพิ่มเติมอีกว่า ที่ผ่านมารัฐบาลได้สั่งแบนบริษัทที่ให้บริการ Proxy และ VPN รวมถึงเว็บไซต์ที่ยังเปิดให้บริการ Torrent เนื่องจากคนไทยพยายามใช้วิธีการเหล่านี้เพื่อเข้าถึงข้อมูลต่างๆ โดยหน่วยงานของรัฐไม่ได้ปิดกั้นเว็บไซต์เหล่านั้นด้วยตนเอง แต่กระทรวงเทคโนโลยีสารสนเทศและการสื่อสาร (MICT) จะขอความร่วมมือกับผู้ให้บริการอินเทอร์เน็ตให้บล็อคเว็บไซต์ต่างๆ และหากไม่ปฏิบัติตาม ก็จะถูกเพิกถอนใบอนุญาต ISP หรือใบอนุญาตการให้บริการอินเทอร์เน็ต

แล้วทำไมจู่ๆ การใช้ VPN ก็มีการติดตั้งพุ่งสูงขึ้นมาขนาดนี้ภายใน 1-2 วันเท่านั้นกันนะ?

ขออธิบายเพิ่มเติมว่า VPN หรือ Virtual Private Network คือ ฟังก์ชันที่สร้างขึ้นเพื่อให้ผู้ใช้รับส่งข้อมูลได้ปลอดภัยมากขึ้น แม้ว่าจะยังใช้อินเทอร์เน็ตในการผ่านข้อมูล แต่จะมีการเข้ารหัสข้อมูลทั้งหมด ผู้ที่ไม่มี Password ก็จะไม่สามารถเข้าถึงข้อมูลนี้ได้ ดังนั้นการใช้ VPN จึงเป็นอีกหนึ่งตัวช่วยเพื่อเข้าถึงเว็บไซต์ที่ถูกปิดกั้นภายในประเทศ

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

ยังคงย้ำอยู่เสมอว่าคุณอาจจะคิดว่า ข้อมูลของคุณไม่ได้สลักสำคัญอะไร อยากจะเอาไป หรือจะแฮกไปก็เชิญ แต่อย่าลืมว่า คุณอาจคิดผิด คุณอาจเป็นบันไดสู่หนทางในการล้วงข้อมูลลับสุดยอดของหน่วยงานของคุณก็เป็นได้

ดังนั้น การปกป้องข้อมูลและการรักษาความปลอดภัยจากการใช้งานเครือข่าย หรืออินเตอร์เน็ตก็มีความสำคัญไม่แพ้กัน​

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

02-2479898 ต่อ 87 

ขอขอบคุณที่มาของแหล่งข่าว Thai CERT และ  The Matter

https://atlasvpn.com/blog/vpn-installs-in-thailand-surge-by-644-due-to-porn-site-bans?fbclid=IwAR300xyH1KeI0JWfalu0mR4Lo5XEWMD-TB_st4XihVrnvGUHpBFZ51qM9WA

www.thematter.co/

 

Google Chrome โดนโจมตีเข้าแล้ว

Google Chrome โดนโจมตีเข้าแล้ว ใครใช้งานอยู่ ควรรีบอัพเดต!!!!

เมื่อวันที่ 2 พฤศจิกายน ที่ผ่านมา  บริษัท Google ระบุว่ามีอย่างน้อย 2 ช่องโหว่ที่ถูกใช้ในการโจมตีจริง แต่ยังไม่ได้แจ้งรายละเอียดหรือขอบเขตของการโจมตีดังกล่าว

 

ช่องโหว่แรกที่ถูกใช้โจมตีเป็นช่องโหว่ใน Google Chrome เวอร์ชั่น desktop ที่ส่งผลให้ผู้ไม่หวังดีสามารถสั่งประมวลผลโค้ดอันตรายเพื่อควบคุมเครื่องของเหยื่อได้จากระยะไกล โดยเป็นช่องโหว่ประเภท  remote code execution (RCE)  ช่องโหว่นี้มีหมายเลข CVE-2020-16009 มีผลกระทบกับ Google Chrome ทั้งบนระบบปฏิบัติการ Windows, Mac และ Linux

 

อีกหนึ่งช่องโหว่ที่ตรวจพบ จะมีผลกระทบกับ Google Chrome เวอร์ชั่น Android โดยเป็นช่องโหว่ประเภท heap overflow ทำให้ผู้ไม่หวังดีสามารถรันคำสั่งนอก sandbox ได้ ช่องโหว่นี้มีหมายเลข CVE-2020-16010

 

ทาง Google ระบุว่าจะปล่อยอัปเดต Google Chrome เวอร์ชัน 86.0.4240.183 สำหรับผู้ใช้งานบน desktop และเวอร์ชัน 86.0.4240.185 สำหรับผู้ใช้งานบน Android ในเร็ว ๆ นี้ ผู้ที่ใช้งาน Google Chrome เป็นประจำ ควรติดตามข่าวสารและอัปเดตโปรแกรมให้เป็นเวอร์ชันล่าสุดเพื่อลดความเสี่ยง

 

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

มาเริ่มวางแผนการปกป้อง และแผนความปลอดภัยเครือข่ายในองค์กรของคุณได้แล้ว อย่ารอช้า จนสายเกินไป

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

02-2479898 ต่อ 87 

อยากรู้เรื่อง WebBlocker

WebBlocker ทำงานภายใต้ HTTP Proxy และแยกแยะหมวดหมู่ (Categorize) ไม่ใช่เพียงแค่ระดับ Domain แต่เจาะจงลงไปที่ระดับ URL

วิธีการตรวจสอบ URL คือ XTM จะส่ง URL นั้นไปตรวจสอบที่ Cloud ของ WebSense และ Cloud จะให้คำตอบว่า URL นั้นจัดอยู่ในหมวดหมู่ไหน

เราสามารถติดต่อการทำงานของ WebBlocker ได้ด้วยการ Enable Log ที่ WebBlocker setting ใน HTTP Proxy ตัวอย่างของ Log ที่จะแสดงใน Traffic policy ใน FSM (Firebox System Manager) จะเป็นแบบนี้ (แสดงแบบเว้นบรรทัดเพื่อให้ดูง่ายขึ้น)

2013-09-20 01:23:22
Allow 10.0.1.10 202.57.155.203 http/tcp 2626 80
1-Trusted 0-External
ProxyAllow: HTTP Request categories
(HTTP-proxy-00) HTTP-Client.3
proc_id=”http-proxy”
rc=”590″
proxy_act=”HTTP-Client.3″
cats=”News and Media” op=”GET” dstname=”www.manager.co.th”
arg=”/” msg_id=”262177″ Traffic

โดยใน Traffic Monitor สามารถใช้ Filter คำว่า “Request cat” เพื่อค้นหาเฉพาะการทำงานของ WebBlocker ได้

ตามตัวอย่าง แสดงให้เห็นว่า WebBlocker จัดให้ www.manager.co.th อยู่ใน Category “News and Media”

เราสามารถทดสอบว่า WebBlocker จะจัดให้ URL นั้นอยู่ในหมวดใด ไปที่ http://csi.websense.com

บางครั้ง เราพยายาม Block web ประเภทนั้น ๆ แล้ว เช่น Category Sex แต่กลับมีบางเวบที่ผู้ใช้ยังสามารถเข้าถึงได้ เพราะ WebBlocker ไม่ได้เก็บ URL บนอินเตอร์เน็ตของทั้งโลกเอาไว้ เราเรียก URL พวกนี้ว่า Uncategorized ซึ่งดูจาก Traffic Policy จะได้ผลดังนี้ แสดงให้เห็นว่า ผู้ใช้สามารถเข้าถึง www.thaix2.com ได้ เพราะ Website นั้นยังไม่ได้จัดหมวดหมู่

2013-09-17 10:24:33
Allow 10.0.1.10 108.162.196.104 http/tcp 2104 80
1-Trusted 0-External
ProxyAllow: HTTP Request categories
(HTTP-proxy-00) HTTP-Client.3
proc_id=”http-proxy”
rc=”590″
proxy_act=”HTTP-Client.3″
cats=”Uncategorized” op=”GET” dstname=”www.thaix2.com”
arg=”/” msg_id=”211243″ Traffic

เราสามารถแจ้ง URL นี้ไปที่ WebSense ได้โดยตรง (csi.websense.com) และใช้วิธี “Suggest a different classification” ภายใน 24 ชั่วโมง เราสามารถจะตรวจสอบกลับไปที่ WebSense ได้ว่า Category ถูกเปลี่ยนตามที่เราแจ้งไปหรือไม่

เมื่อตรวจสอบแล้วในวันถัดไป ก็จะพบว่า ทาง WebSense ได้จัดหมวดหมู่ของ URL เอาไว้แล้ว เป็นประเภท Sex

แต่เมื่อลองเข้า Website นี้โดยผ่านทาง XTM ก็ยังพบว่า สามารถเข้าถึง Website นี้ได้เหมือนเดิม โดย WebBlocker บน XTM ยังคงแสดงเป็น Uncategorized เหมือนเดิม (ไม่ได้แสดงเป็น Sex เหมือนบน Cloud) นั่นก็เป็นเพราะ XTM ได้มีการเก็บคำตอบของ Cloud เอาไว้ใน Cache คำตอบครั้งที่ผ่านมาสำหรับ Website แห่งนี้คือ Uncategorized ผู้ใช้จึงยังคงสามารถเข้าถึงเว็บไซต์ได้

เราสามารถตรวจสอบได้ว่า คำตอบของ WebBlocker เป็นคำตอบจาก Cloud หรือจาก Cache โดยการปรับให้ XTM แสดง Log ของ WebBlocker ในระดับ Debug (Policy Manager -> Setup -> Logging) และกดที่ปุ่ม “Diagnostic Log Level”

ลองเข้าดู web site อีกครั้ง และกลับมาตรวจสอบที่ Traffic monitor ก็พบว่า คำตอบของ WebBlocker นั้นมาจาก Cache จริง ตามภาพ (cache node found for str=www.thaix2.com)

XTM จะเก็บคำตอบเอาไว้ใน Cache นาน 7 วัน นานกว่านั้นก็จะถูกลบออกจาก Cache
หากเราต้องการที่จะ Clear cache ทันที สามารถทำได้ 2 วิธี
1. Restart XTM
2. บังคับให้ XTM ไม่ต้องเก็บคำตอบของ WebBlocker cloud เอาไว้ในตัวเองก็ได้ เปิด Policy manager และดูที่นี่ Subscription Services -> WebBlocker -> Configure ไล่ดู Proxy policy ทีละบรรทัดโดยการกดปุ่ม Configure และปรับ Cache size เป็น 0 ในทุก ๆ policy

การจัดให้ WebBlocker cache มีค่าเป็น 0 แปลว่า XTM จะไม่มีการเก็บ Cache ของ WebBlocker เอาไว้เลย แต่จะตรวจสอบ URL กับ Cloud ทุกครั้ง

แต่เนื่องจาก Category ของ URL ก็ไม่ได้เปลี่ยนบ่อย ๆ จึงไม่แนะนำให้ยกเลิก Cache ของ WebBlocker เปิด Cache ให้ทำงานเอาไว้ เพื่อเพิ่มความเร็วของ WebBlocker ดีกว่า

ถ้าไม่มี APT ป่านนี้คงเละไปแล้ว

APT Security

APT Security เรื่องของเรื่องก็คือ ที่ออพติมุสเราใช้ Kerio Connect เป็น Mail server และ e-mail ที่ผ่านเข้าออกเซิร์ฟเวอร์นี้ก็จะถูกสแกนทั้ง Spam และ Attachment ด้วย Security feature ของ XTM โดยทั้ง Spam engine และ Antivirus เป็น Cloud engine กล่าวคือ มีการทำงานร่วมกับฐานข้อมูลขนาดใหญ่บน Cloud database

แต่ ณ เวลานั้น…XTM ตัวนี้ไม่มี APT Blocker ทำงานอยู่

และเมื่อไม่นานมานี้ พนักงานได้รับ e-mail ที่ (ดูเหมือนว่า) ส่งมาจากธนาคารกรุงเทพ ข้อความดังนี้

ถ้าเป็นซักปีที่แล้ว ไฟล์ที่แนบมากับ mail ก็จะเป็นไฟล์ virus ที่ถูก zip และส่งมา ซึ่ง XTM สามารถจะ unzip, scan และ Delete attachment ก่อนที่ e-mail จะเข้าถึง mailbox ของผู้ใช้ ซึ่ง XTM สามารถจะ unzip ลึกลงไปได้ถึง 5 ชั้น และ XTM ยังสามารถสแกนไฟล์ที่มีขนาดใหญ่ถึงระดับเมกะไบต์ได้

ไฟล์นี้ไม่ใช่ไวรัส

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

APT น่ากลัวกว่าไวรัส ร้ายแรงกว่า เสียหายหนักกว่า

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

แต่ APT ซึ่งเป็นภัยคุกคามรูปแบบใหม่นี้ เน้นการขโมยข้อมูล การล้วงความลับ การฝังตัวอย่างเงียบ ๆ ในระบบ เพื่อเก็บข้อมูลต่าง ๆ ส่งออกไปเรื่อย ๆ โดยเฉพาะ Password สำหรับทำธุรกรรมทางธุรกิจ APT มีชื่อเรียกเต็ม ๆ ว่า Advanced Persistent Thread

APT เคยเป็นปฏิบัติการลับของรัฐบาลชาติหนึ่ง (การพัฒนาหนุนหลังโดยรัฐบาล) เพื่อโจมตีในทางลับกับระบบคอมพิวเตอร์ของอีกชาติหนึ่ง เป็นส่วนหนึ่งของปฏิบัติการตามยุทธการทางทหารหรือทางการเมือง เราคงเคยได้ยินเรื่องแบบนี้ไม่มากก็น้อยจากข่าวทั่ว ๆ ไปรวมถึงจาก WikiLeaks

เวลาผ่านไป เทคนิควิธีการแบบ APT กลายเป็นเครื่องมือให้กับผู้ร้ายนำมาใช้โจรกรรมข้อมูลจากภาคธุรกิจหรือจากองค์กรของรัฐบาลก็ตาม และนำข้อมูลนั้นไปประกอบอาชญากรรมอื่น ๆ

APT เลือกและเจาะจงเป้าหมาย มีปฏิบัติการที่ชัดเจน และมีคนคอย Operate อยู่เบื้องหลัง ดังนั้น APT มีความฉลาด มีทีมอาชญากรคอยเป็นผู้วิเคราะห์ข้อมูลที่ขโมยออกมา APT สร้างความเสียหายทางตรงกับธุรกิจ เสียหายทางการเงิน เสียชื่อเสียง สูญเสียความน่าเชื่อถือ และในทางกลับกัน สร้างผลกำไรมหาศาลให้กับคนร้ายอย่างตรงไปตรงมา หรือบางครั้งอาจเป็นปฏิบัติการล้างแค้น โจมตีตอบโต้ ก็เป็นได้ อย่างไรก็ดี เป็นการโจมตีที่มีการเลือกเป้าหมาย

ยกตัวอย่างเช่น การขโมย Password ของ hotmail เพื่อล้วงเข้าไปใน Mailbox ฉก Invoice ตัวจริง แล้วนำ Invoice นั้นมาปลอมแปลง เปลี่ยนแค่เลขที่บัญชีโอนเงิน และส่ง Invoice นั้นไปให้กับคู่ค้า เพื่อหลอกให้คู่ค้าโอนเงินไปเข้าอีกบัญชีหนึ่งของผู้ร้าย

คู่ค้าในอีกประเทศหนึ่ง ไม่มีโอกาสรู้ได้เลยว่า e-mail หรือ Invoice นั้นของปลอม เพราะ e-mail ถูกส่งออกจาก Account ตัวจริง (ที่ถูกขโมย password) ส่ง Invoice จริง (ที่แก้ไขเลขบัญชี) และ e-mail ก็ถูกส่งมาตามเวลาที่เกิด Transaction ของ shipment ที่เกิดขึ้นจริง ๆ ทั้งหมดนี้ คนร้ายอาจจะใช้เวลา Logon เข้า mailbox เพื่อเรียนรู้จังหวะเวลาของการส่งเอกสารไปมาระหว่างคู่ค้า และลงมือปฏิบัติการในช่วงเวลาที่เหมาะสม

มาดูว่า attach file ใน e-mail นี้ ทำงานอย่างไร

เมื่อแตกไฟล์ zip ออกมาก็จะได้ไฟล์ EXE อยู่ข้างใน สแกนด้วย Microsoft Security Essential ก็ไม่พบสิ่งผิดปกติ (signature ล่าสุด ณ วันที่ได้รับ e-mail นี้) ซึ่งเป็นเรื่องปกติของ APT ที่จะสามารถหลุดรอดจากการสแกนของ Virus scanner ทั่ว ๆ ไป แต่เมื่อส่งไฟล์นี้ไปสแกนด้วย APT scanner online ซึ่งมีอยู่หลายแห่ง

http://www.malware-analyzer.com/malware-auto-analysis

โดยสรุปคือ ไฟล์นี้มีการแทรกซึม Process ภายในของ Windows เช่น Explorer, cmd.exe เพื่อสร้างไฟล์ EXE (tetyin….exe) และมีการติดต่อกับ host ภายนอก (พบ DNS query ชื่อ globsocial.org) ยังไม่ทราบจุดประสงค์ว่า ติดต่อเพื่อนำข้อมูลเข้ามาเพิ่ม ครอบครองสิทธิ์ admin หรือส่งข้อมูลออก

เมื่อทราบเช่นนี้แล้วว่า APT มีความร้ายแรงอย่างไร จึงไม่มีการรอช้า ในวันรุ่งขึ้น ออพติมุสจึงได้อัพเกรด XTM ที่ใช้อยู่กับ Mail server ให้มีออพชั่น APT Blocker ในทันที

APT Blocker บน XTM เป็น Security feature ที่ต้องสั่งซื้อเพิ่ม คุ้มหรือไม่ ต้องนึกถึงความน่ากลัวของ APT และ APT Blocker สามารถตรวจจับได้มากแค่ไหน ดูได้จาก Firebox System Manager ในหัวข้อ Subscription services ตามรูปด้านล่าง

APT Blocker ที่ติดตั้งบน XTM ที่ออพติมุส ได้เริ่มทำงานเมื่อวันที่ 26 พฤศจิกายน 2014 และวันที่เก็บภาพนี้คือ 8 ธันวาคม 2014 หมายความว่า ภายในเวลาเพียง 13 วันเท่านี้ มี e-mail ที่แนบ APT ส่งเข้ามาที่ Mail server ของออพติมุสถึง 610 e-mail

ลองดูข้อมูลจาก Dimension ว่า 610 e-mail นี้ มี APT ตัวไหน แต่ละตัวมีฤทธิ์เดชอย่างไร ความเลวร้ายแบบเต็ม ๆ ดูได้จากไฟล์แนบ ด้านล่างนี้เป็นตัวอย่างฉบับย่อ

– Command & Control traffic observed
– Modifying System dlls in memory
– Disabling firewall or Windows Security Center or Windows Update or Antivirus
– Disabling User Account Control notification
– Creating executables masquerading system files (fake cmd.exe, for example)
– Reading system license info
– Read FTP client or Mail client credential
– Read browser stored credential
– Keystroke logging
– Attempting to download remote executable contents

ลองเอากิจกรรมข้างบนมาประกอบกันดูว่า เราอาจจะเร่ิมสงสัยว่า เราถูกขโมยอะไรออกไปบ้างแล้ว APT สามารถเริ่มทำงานได้เพียงแค่ User ลอง Double click ที่ attach file ที่มากับ e-mail เท่านั้น การโจรกรรมข้อมูลก็เริ่มต้นทันทีที่วินาทีนั้น

ข่าวดี ก็คือ ทั้งหมดนี้ APT Blocker สกัดเอาไว้ได้ทั้งหมด “ปลอดภัย หายห่วง”

ตื่นตัว ก่อนจะต้องตื่นตระหนก

ลองถามไปที่ผู้ให้บริการ Mailbox หรือหากคุณเป็น Mail admin เอง ลองตั้งคำถามว่า Antivirus ที่คุณใช้อยู่กับ Mail server มีความสามารถในการสแกนและสกัด APT ได้หรือไม่

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

เกร็ดเล็กเกร็ดน้อย: การตรวจจับ APT เขาทำกันอย่างไร

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

การตรวจหา APT จึงเป็นการสร้างสภาพแวดล้อมของ OS ขึ้นมาปลอม ๆ (Virtual) และนำ APT file ไปทำงานในสภาพแวดล้อมที่ปลอมขึ้นมานั้น และรวบรวมว่า APT file นั้นทำอะไรกับระบบบ้าง เช่น มีการตรวจจับคีย์บอร์ด, มีการอ่านไฟล์ที่ Browser เก็บเอาไว้, มีการสร้าง process ขึ้นมา, มีการติดต่อกับอินเตอร์เน็ต นำข้อมูลเข้าจากที่ไหน หรือส่งข้อมูลออกไปที่ไหน และรวบรวมทั้งหมด มาวิเคราะห์หาพฤติกรรมที่ “ต้องสงสัย” หรือ “เข้าข่าย” ว่าเป็นการโจรกรรม

ในขณะเดียวกัน APT ก็ไม่โง่ แต่กลับฉลาดพอที่จะตรวจจับได้ว่า ขณะนี้มันกำลังทำงานอยู่ในสภาพแวดล้อมจริง หรือกำลังโดนแหกตาภายใต้สภาพแวดล้อมเทียม (Virtual) ให้เปิดเผยตัวเอง ดังนั้น APT detection ของแต่ละค่าย จึงมีความสามารถไม่เท่ากัน APT detection ที่เก่ง จะสามารถต้ม APT จนเปื่อย จนมันยอมเปิดเผยตัวเองออกมาอย่างหมดเปลือก

 

เมื่อได้ข้อสรุปว่า ไฟล์นั้นคือ APT ระบบตรวจจับก็จะเก็บ Checksum ของ file นั้นเอาไว้ เพื่อนำไปเป็น Signature ให้กับระบบอื่น ๆ นำไปสแกน APT ตัวนี้ได้อย่างรวดเร็ว

ทั้งนี้ทางบริษัท ออพติมุส (ประเทศไทย) จำกัดยังเป็นตัวแทนจำหน่าย  APT Security ด้วย หากสนใจหรือต้องการข้อมูลเกี่ยวกับผลิตภัณฑ์เพิ่มเติมสามารถติดต่อมาได้ที่แผนก Marketing

Phone : 0-2247-9898
Email : [email protected]
Line : @optimusthailand
Facebook : optimusthailand

APT Security, APT Blocker, Antivirus Scanner, Advanced Persistent Thread, APT Scanner

MU-MIMO ทำงานอย่างไร?

R710 เป็น 802.11ac wave 2 AP ที่เปิดตัวมาระยะหนึ่งแล้ว และออพติมุสก็ได้จัดงานสัมมนาแนะนำสินค้าไปเมื่อไม่กี่เดือนที่ผ่านมา เนื้อหาสำคัญในงานก็คือ ช่วงที่มีการอธิบายหลักการทำงานของ MU-MIMO ซึ่ง MU-MIMO เป็นเทคโนโลยีที่ซับซ้อนและยากแก่การทำความเข้าใจ

แต่ในงานสัมมนานี้ ได้มีการสรุปมา MU-MIMO จาก White paper หลาย ๆ ชิ้น นำมาอธิบายและเรียบเรียงใหม่ ใช้ Slide ของ Ruckus เป็นภาพประกอบ ทำให้เข้าใจได้ง่าบขึ้นไปอีก

ใครที่เคยสงสัยเรื่อง MU-MIMO และไม่อยากเสียเวลาอ่านหลาย ๆ ชั่วโมง ลองอ่านบทย่อจากที่นี่

11ac wave1 ก็คือ wifi chip ที่ออกมาในตลาดรุ่นแรก รองรับส่วนหนึ่งของมาตรฐาน 802.11ac เช่น
ทำงานบน 5GHz เท่านั้น (11ac ไม่ทำงานบน 2.4GHz)
ทำ Channel bonding กว้างถึง 80MHz (11n สูงสุดที่ 40MHz)
มี Modulation 256-QAM (11n สูงสุดที่ 64-QAM)
มีการใช้เสาเพิ่มขึ้นเพื่อทำ Transmit beam forming (หรือบางทีเรียกตาม Protocol process ว่า Beam steering) ซึ่งใน 11n นั้น Beam forming เป็นเพียง Optional feature แต่ใน 11ac กำหนดให้ Beamforming เป็นส่วนหนึ่งของ 11ac

Wifi chip 11ac wave2 มีอะไรที่เพิ่มขึ้นมา
– รองรับถึง 160MHz (แต่ R710 ของ Ruckus ยังไม่รองรับ 160MHz)
– มี 4 spatial stream หมายความว่า ในแต่ละครั้งที่ AP ใช้ความถี่ ก็สามารถส่งปริมาณข้อมูลออกไปได้มากขึ้น
– รองรับ Multi-User MIMO หรือ MU-MIMO ก็คือการใช้แต่ละ Stream เพื่อส่งข้อมูลไปให้ client แต่ละเครื่องพร้อมกัน ในเวลาเดียวกัน

MIMO - Spatial Multiplexing

Spatial stream แปลตรงตัวคือ Stream ที่อยู่กันคนละ space ซึ่งแต่ละ space ก็คือ OFDM subcarrier ของ channel

Spatial stream ทำให้เพิ่ม Throughput โดยการใข้ MIMO เพื่อทำ Spatial stream ในการส่งข้อมูลออกไปหลาย ๆ element ให้เสาแต่ละ element ส่งข้อมูลแต่ละชุด ตามภาพเป็นการจำลองการทำงานของ Spatial stream

การแสดง Spatial stream specification ของอุปกรณ์ wifi จะเขียนเป็น Tx x Rx : SS หมายความว่า จำนวน element ของ antenna สำหรับส่ง และรับ และจำนวน stream ที่ทำได้

ในภาพคือการที่ AP จะใช้ 3 stream เพื่อส่งข้อมูลไปให้กับ Client ที่รองรับ 3 stream ในขณะที่อีก 1 stream ที่เหลือบน AP จะนำมาใช้ทำเป็น Beamforming ให้กับ antenna element ตัวใดตัวหนึ่งก็ได้

Mobile Clients - More Radio Waste

ในความเป็นจริงแล้ว AP คุณภาพสูงในสถานที่ Public มักจะต้องทำงานกับ Mobile device ซึ่งส่วนใหญ่จะเป็น 1 stream ก็เลยกลายเป็นว่า AP แบบ 4 stream กลับจะต้องมารับส่งแค่ 1 stream เท่านั้นเมื่อทำงานกับ Mobile device ทางเลือกในอดีตหากต้องการจะใช้ antenna element หรือ MIMO ให้คุ้มค่า Beamforming อาจจะเป็นตัวเลือกเข้ามาช่วยเพิ่ม SNR และทำให้ PHY data rate ที่ตัว client สูงขึ้น

แต่ PHY rate ที่สูงขึ้นภายใน stream เดียว (ไม่ดีไปกว่า 433Mbps) ก็ยังเทียบไม่ได้กับการ “ได้ใช้ทุก stream” พร้อมกัน (เทียบกับ 1.3Gbps ที่ 3 stream) คำตอบของการ “ได้ใช้ทุก stream” เมื่อ AP ต้องทำงานร่วมกับ single stream client ก็คือ MU-MIMO

MU-MIMO - Mobile Optimized

แนวคิดของ MU-MIMO คือการส่งข้อมูลของ Client แต่ละเครื่องออกไปพร้อมกัน โดยใช้ stream แต่ละ stream

MU-MIMO

แต่ในความเป็นจริงแล้ว Client แต่ละเครื่องก็ได้รับ data stream ทุก ๆ stream ดังนั้น Beam forming จึงเข้ามาทำงานร่วมกัน โดย Wifi chip บน AP จะทำงานร่วมกับ client เพื่อหาดูว่า จะเลือก signal phase angle อย่างไรเพื่อให้ Constructive interference หรือ in-phase signaling (ด้านที่คลื่นกระทบกันแล้ว dB สูงขึ้น) ชี้ตรงไปยังทิศทางของ Client นั้น ๆ

ในขณะเดียวกัน ก็พยายามทำให้ Beam forming นั้นมีรูปแบบที่ Destructive interference หรือ out-of-phase signaling (ด้านที่คลื่นกระทบกันแล้ว dB ลดลง) ชี้ไปยัง client อื่น ๆ ตามภาพ วิธีการนี้เราเรียกว่าเป็นการทำให้เกิด Null signaling นั่นเอง

สรุปก็คือการทำให้ dB ของ stream ที่จะส่งไปหา client เครื่องนั้น ๆ สูงที่สุดเมื่อเทียบกับ dB ของ stream ที่จะส่งไปให้กับ client อื่น


เมื่อ dB ของ stream ที่ส่งไปหา client นั้น ๆ สูงกว่า dB ของ stream อื่น ๆ (ซึ่งถือว่าเป็น Noise ของ Client เป้าหมาย) ก็หมายความว่า SNR (Signal per Noise Ratio) ของ Client นั้น ๆ สูงขึ้น ก็จะทำให้โอกาสที่ Client นั้นสามารถใช้ Data rate ที่สูงขึ้นก็เป็นไปได้

Opportunity for Differentiation

ปัญหาคือ การจะทำให้ Beam forming มีรูปร่างที่ Narrow (ไม่เป็น Forming pattern ที่อ้วน ๆ แต่มี dB ที่มีรูปร่างเป็นปลายแหลม) จะต้องใช้เสาหลาย element มาประกอบกัน ซึ่งการมีเสาหลายต้น มักจะหมายถึง
– AP มีขนาดใหญ่ขึ้น
– CPU มี Processing มากขึ้นอย่างมหาศาล เพราะเสาแต่ละ element ก็หมายถึงการคำนวณ phase บนเสานั้นอย่างทวีคูณบน Matrix number calculation
cost ของ AP ก็จะแพงขึ้น

เมื่อ TxBF ไม่สามารถสร้าง Signal level สำหรับแต่ละ stream ให้แตกต่างจาก signal ของ stream อื่น ๆ (Noise) ย่อมหมายความว่า client ของ stream นั้น ๆ ก็มี SNR ที่ต่ำ คือ Signal อาจจะสูงกว่า noise เพียงแค่ 3dB เท่านั้น SNR ที่ต่ำลง ก็คือ data modulation rate ที่ต่ำด้วยเช่นกัน โดยสรุปคือ TxBF ไม่ช่วยเพิ่มประสิทธิภาพให้กับ MU-MIMO ได้ดีเท่าไหร่นัก

ในขณะที่ BeamFlex ซึ่งเป็นเสาทิศทางอยู่แล้ว เมื่อมาทำงานร่วมกับ Beam forming ก็ยิ่งทำให้เกิดความแตกต่างของ dB มากขึ้นในแต่ละ stream และเกิด Null signaling ได้ดียิ่งขึ้นไปอีก ผลคือ client ใน stream นั้น ๆ จะได้รับ signal สูงขึ้นเมื่อเทียบกับ Noise เมื่อ SNR สูงขึ้น data rate ของ cleint ก็จะสูงขึ้นตามไปด้วย

นอกจากนี้ TxBF ที่ได้ผล ยังต้องการ Explicit feedback จาก client เพื่อประเมิน Beam steering ที่ดีที่สุด หาก client ไม่มี Explicit response ผลคือ TxBF ก็จะด้อยประสิทธิภาพลงไปอีก

ในขณะที่ BeamFlex มีกลไกที่จะหา Best path โดยไม่อาศัย Explicit feedback จาก client แต่ BeamFlex module ใน AP จะประเมินหา Best pattern ด้วยตัวเองจาก Legacy feed back ที่มีอยู่แล้วใน 802.11 control frame ไม่ต้องพึ่งพากลไกพิเศษฝั่ง client เลย TxBF ของ Ruckus ที่ทำงานร่วมกับ BeamFlex จึงทำงานได้มีประสิทธิภาพแม้กับ client ทั่ว ๆ ไป

จากภาพ จะเห็นว่า MU-MIMO จะทำงานได้ดีขึ้น เมื่อ Client มีตำแหน่งที่อยู่รอบตัว Client ไม่กระจุกตัวเป็นกลุ่ม AP ที่ตั้งอยู่ตรงกลางระหว่าง Client จะทำ MU-MIMO ได้ดี

NAT Loopback คืออะไร ทำงานอย่างไร และใช้ในโอกาสไหน

บางคนอาจจะบอกว่า ก็ 3Tx คูณ ตามภาพข้างบนนี้ ใครที่ config XTM เป็นแล้ว จะรู้ทันทีว่า เพื่อให้เซิร์ฟเวอร์ตามภาพนี้ทำงานได้ เราจะต้องสร้าง 2 policy ให้กับเซิร์ฟเวอร์ตัวนี้ ได้แก่ Incoming policy และ Outgoing policy

Incoming Policy (จากอินเตอร์เน็ต เข้าหาเซิรืฟเวอร์ที่พอร์ต TCP-888 โดยใช้ SNAT)
From: Any External
To: SNAT 172.16.13.223 -> 10.0.1.3
Service: TCP-888

Outgoing Policy (ให้เซิร์ฟเวอร์ออกเน็ตได้ โดยใช้ IP 172.16.12.223)
From: 10.0.1.3
To: Any External
Service: Any
ซึ่งเราจะสร้าง 1-1 NAT เพื่อบังคับให้ Local IP 10.0.1.3 ออกเน็ตด้วยหมายเลข IP 172.16.13.223 เท่านั้น และหมายเลข IP 172.16.13.223 ก็จะถูกกำหนดไว้เป็น Secondary IP ของ External Interface ของ XTM ด้วยเช่นกัน

สำหรับ Client 10.0.1.2 หากจะติดต่อเซิร์ฟเวอร์ที่หมายเลข IP 10.0.1.3 ก็ไม่ใช่เรื่องยากอะไร เพราะเป็นการติดต่อภายใน Subnet เดียวกัน ไม่มีอะไรวิ่งผ่าน XTM

แต่...

หลาย ๆ ระบบมีข้อจำกัดที่ทำให้ Client ไม่สามารถติดต่อกับเซิร์ฟเวอร์ที่ IP 10.0.1.3 ได้ แต่ไปใช้ 172.16.13.223 แทน เช่น

DNS ที่ Client ใช้อ้างถึงเซิร์ฟเวอร์ ให้คำตอบเป็น Net-IP (แทนที่จะเป็น Local-IP)
ซอฟต์แวร์ที่เขียนให้ทำงานกับเซิร์ฟเวอร์ เจาะจงว่าจะติดต่อกับเซิร์ฟเวอร์ที่ Net-IP ไม่รองรับการติดต่อกับเซิร์ฟเวอร์ด้วย Local-IP
ซึ่ง Policy ทั้ง 2 นี้ จะไม่ช่วยให้ Client สามารถติดต่อกับเซิร์ฟเวอร์ที่ Net-IP (172.16.13.223) ได้

สิ่งที่เราต้องการคือ ให้เกิด connection แบบไหนย้อนกลับ จาก External Interface ให้วนกลับมาที่ Trusted interface

ถ้า Client พยายามติดต่อกับ 172.16.13.223 ที่ TCP-888 จะได้ข้อความใน Traffic Monitor ดังนี้

2015-07-14 13:18:59 Deny 10.0.1.2 172.16.13.223 888/tcp 50894 888 1-Trusted Firebox Denied 52 128 (Unhandled Internal Packet-00) proc_id=”firewall” rc=”101″ msg_id=”3000-0148″ tcp_info=”offset 8 S 2845639353 win 32″ Traffic

วิธีทำให้ Client ใน LAN ติดต่อกับเซิร์ฟเวอร์ด้วย Net-IP ได้ ง่ายอย่างเหลือเชื่อครับ คือใน Incoming policy ที่มี SNAT นั้น ก็เพียงใส่ Any Trust เข้าไปเท่านั้น ตามภาพด้านล่าง

การทำงานเบื้องหลัง

มาติดตามดูกันครับ

อันนี้เป็น Traffic Monitor Log สำหรับการ Access Server จากขา External
2015-07-14 13:41:08 Allow
172.16.13.12 172.16.13.223 888/tcp 57771 888
0-External 1-Trusted
Allowed 64 63 (Server-Incoming-00) proc_id=”firewall” rc=”100″ msg_id=”3000-0148″ dst_ip_nat=”10.0.1.3” tcp_info=”offset 11 S 2455518075 win 65535″ Traffic

ส่วนอันนี้เป็น Traffic Monitor Log สำหรับการ Access Server จาก LAN client (10.0.1.2) ไปยัง Net-IP (172.16.13.223) ของเซิร์ฟเวอร์
2015-07-14 13:40:17 Allow
10.0.1.2 172.16.13.223 888/tcp 51228 888
1-Trusted 1-Trusted
Allowed 52 127 (Server-Incoming-00) proc_id=”firewall” rc=”100″ msg_id=”3000-0148″ src_ip_nat=”10.0.1.1″ dst_ip_nat=”10.0.1.3” tcp_info=”offset 8 S 3358614933 win 32″ Traffic

สิ่งที่น่าสนใจคือ มีการทำ src_ip_nat ปรากฏขึ้นมา โดยไม่ใช่ส่วนหนึ่งของการทำงานของ SNAT (ซึ่งจะ Translate เฉพาะ dst_ip เท่านั้น) หรือ Dynamic NAT (ซึ่งจะทำงานกับ External interface ตามค่า default)

การทำ src_ip_nat เป็นกลไกภายในของ Fireware OS เอง ที่จะเริ่มทำ NAT ให้กับ src_ip เพื่อป้องกันการเกิด Asymmetric routing เรียกสิ่งนี้ว่า NAT loopback

NAT loopback จะเริ่มทำงานโดยอัตโนมัติ เมื่อพบว่า Trusted network จะพยายามเข้าถึง IP ที่อยู่ใน Trusted network ด้วยกัน ผ่านทาง External IP โดยอ้างอิงความสัมพันธ์ที่ระบุเเอาไว้ใน SNAT หรือ 1-1 NAT

มาดูภาพด้านล่างว่า ถ้า XTM ทำ NAT เฉพาะ dst_ip จะเกิด Asymmetric routing ได้อย่างไร และทำไม Loopback NAT (ที่เพิ่มการทำ NAT ของ src_ip ด้วย) จึงทำให้ทุกอย่างทำงานได้อย่างถูกต้อง

เปรียบเทียบเส้นทางที่ 3 (สีแดง) ที่จะเกิดขึ้นหากไม่มีการทำ NAT ที่ src_ip ซึ่งเป็นผลไม่ดีแน่ หากจู่ ๆ client ได้รับการติดต่อกลับมาจากเซิร์ฟเวอร์ในอีกเส้นทางหนึ่ง

ถือเป็นความฉลาดของ Fireware OS ที่ได้มีการออกแบบให้ NAT loopback เริ่มทำงานในเงื่อนไขพิเศษนี้

Spatial stream คืออะไร ทำไมยิ่งเยอะ ยิ่งดี และ ยิ่งแพง

ตอนนี้ AP ที่มีขายในตลาด ก็ล้วนแต่เป็น 11n Dualband กันหมดแล้ว และฐานของตลาดก็จะขยับขึ้นไปเป็น 11ac wave1 ในไม่ช้า ในขณะที่หลายคนยังไม่รู้เวลาว่า สเปคของ AP ที่เขียนว่า 3×4:3 แปลว่าอะไร

บางคนอาจจะบอกว่า ก็ 3Tx คูณ 4Rx กับอีก 3 Spatial stream นั่นไง แต่ส่วนใหญ่ก็ตอบไม่ได้อยู่ดีว่า แล้ว Tx กับ Rx สัมพันธ์กันอย่างไร และ Spatial stream ช่วยอะไร…

เอาสั้น ๆ ง่าย ๆ คนทำเทคนิคเข้าใจ คนขายก็เอาไปอธิบายลูกค้าได้ ไม่ต้องลึกมาก

Tx
Tx แปลว่า จำนวนของ Transmit Radio Chain ยิ่งมีมาก ยิ่งดี แต่ละ Transmit Radio chain (วงจรวิทยุเพื่อส่งสัญญาณ) จะต้องใช้เสา 1 ต้น

RX
Rx ก็เหมือนขาส่ง แต่เป็นวงจรขารับสัญญาณ (Receive radio chain) ใช้เสา 1 ต้นในแต่ละ Receive Radio chain เหมือนกัน

Tx และ Rx จะผลัดกันใช้เสาได้ เพราะ Tx และ Rx ผลัดกันทำงาน ตอน Tx ใช้เสา Rx ก็อยู่เฉย ๆ

ดังนั้น ถ้าเราเห็น AP มีเสาแทงออกมา 4 ต้น ก็อาจจะเป็นได้ว่าเป็นแบบ 4×3 หรือ 3×4 หรือ 4×4 อย่างน้อยต้องมีเลข 4 ห้อยอยู่ตัวนึง ไม่งั้นสเปคที่เขียนก็จะขัดแย้งกับฮาร์ดแวร์ที่เห็น

Spatial stream
Spatial stream แปลว่า จำนวนชุดของข้อมูลที่ส่งออกไปพร้อมกันในอากาศ AP ที่เก่ง (และมักจะแพง) จะส่งได้หลายชุดพร้อมกัน ยิ่งส่งได้หลายชุด ก็ยิ่งดี (และยิ่งแพง) ข้อแต่ละชุดเรียกว่า แต่ละ stream

ย้ำนะครับ “ส่ง” ไม่ใช่ “รับ” ดังนั้น AP ตัวหนึ่งที่ทำ Spatial stream ได้มากกว่าอีกตัวหนึ่ง ก็แปลว่ามีสเปคในการส่งข้อมูลที่ดีกว่าเท่านั้น ส่วนจะรับได้ดีกว่ากันหรือไม่ ไม่เกี่ยวกับเลข Spatial Stream (SS)

1 Spatial stream จะต้องใช้ Tx อย่างน้อย 1 เลข เช่น 3×3:3 แบบนี้เป็นไปได้ ดังนั้น ถ้าเราเห็น AP มีเสาแทงออกมา 3 ต้น เราก็จะบอกด้วยตาได้ว่า AP ตัวนี้ มี Spatial stream ไม่เกินกว่า 3 stream แน่นอน (ถ้าสเปคเขียนมากกว่า 3 stream ก็แสดงว่า ขี้โม้)

ถ้าจะทำให้ Spatial stream ทำงานได้ดีขึ้น คือมี dB ในการส่งสูงขึ้น ก็จะใช้เทคนิค TxBF (Transmit Beamforming เข้ามาช่วยในการทำ Spatial Stream ย่อว่า SS) ดังนั้น แทนที่จะใช้ 1Tx เพื่อทำ 1SS ก็จะกลายเป็น 2Tx ต่อ 1SS แบบนี้ก็เป็นไปได้ (ไม่แน่ใจว่าจะมี Wifi chip ใช้ถึง 3Tx ในการทำ 1SS หรือเปล่า)

ดังนั้น ถ้าจะบอกว่า 4×3:3 ก็เป็นไปได้ หรือ 3×3:2แบบนี้ก็เป็นไปได้ ไม่ผิด ซึ่งพอเห็นเลขแบบนี้ (Tx มากกว่า SS) ก็รู้ได้เลยว่า AP ตัวนั้น น่าจะทำ Transmit Beamforming ได้ (ย้ำอีกครั้งนะครับ “Transmit” Beamforming ดังนั้น จะเพิ่ม dB แค่ขาส่งออกจาก AP เท่านั้น)

Transmit Beamforming บางทีก็เขียนสั้น ๆ ว่า TxBF (BF ไม่ใช่ Boy Friend หรือ Best Friend นะครับ)

ข้อที่น่าคิดอีกข้อคือ ถ้าเขาเขียนว่า 3×2:3 ก็แปลว่า AP ตัวนั้นทำงานที่ 3 Spatial stream จะไม่มีการทำ TxBF เพราะการทำ TxBF จะต้องใช้ Tx มากกว่า 1 แต่ถ้า AP นั้นจะส่งข้อมูลให้กับ Client ที่รองรับแค่ 2 Spatial Stream ก็อาจจะเป็นไปได้ที่จะมีการทำ TxBF ที่ AP เพราะมี Tx เหลือ คือ 1Tx สำหรับ Stream ที่ 1 และอีก 2Tx เอามาทำ TxBF กันสำหรับ Stream ที่ 2 ขึ้นอยู่กับสเปคของ AP (Wifi chip ที่ใช้ใน AP) นั้นว่า มีความสามารถในการทำ TxBF หรือไม่

สำหรับ R710 ที่ยกตัวอย่างมาในภาพ 4×4:4 ก็แสดงว่า AP ตัวนี้รองรับ 4 stream โดยเมื่อใช้งานที่ 4 stream ก็จะไม่มีการทำ Transmit Beamforming (เพราะไม่มี Tx เหลือ) และถ้า AP นี้ทำงานกับ Client ที่น้อยกว่า 4 stream ก็จะมีการทำ TxBF เพื่อช่วยเพิ่ม dB ให้กับ stream นั้น ๆ

และถึงแม้ว่า R710 จะทำงานที่ 4 stream และไม่มี TxBF แต่ R710 ก็ยังมี BeamFlex ที่ช่วย dB ให้กับแต่ละ stream อยู่ดี Ruckus AP ทุกรุ่นจึงเหนือกว่า AP อื่น ๆ ในตลาด ที่สามารถสร้างทิศทางได้ โดยใช้ Tx เพียงแค่ 1 ก็สร้างทิศทางเป็น Beam ได้แล้ว

AP ที่ดี จึงจะต้องมี Tx เยอะ ๆ และ Rx เยอะ ๆ และ SS เยอะ ๆ และเลข SS จะไม่มีทางมากกว่าเลข Tx

TxBF ใน 11n และ 11ac

ถามว่า – ตอบว่า
11n AP ทำ TxBF ได้ทุกตัวหรือไม่ ตอบว่า “ไม่แน่” ดูที่สเปคของ AP ตัวนั้น ๆ
11ac AP ทำ TxBF ได้ทุกตัวหรือไม่ ตอบว่า “ใช่” เพราะ TxBF เป็นข้อกำหนดของ 11ac

ถ้า Tx เยอะกว่า SS แปลว่า AP จะเอา Tx ที่เหลือมาทำ TxBF ใช่หรือไม่?

ไม่แน่ครับ การใช้ Tx หลาย chain มาส่งข้อมูลชุดเดียวกัน มีอยู่หลายวิธี หลัก ๆ เลยคือ จะเน้น “ช้าแต่ชัวร์” หรือจะเอา “แรงและเร็ว” แล้วแต่คนเขียนเฟิร์มแวร์จะให้ความสำคัญกับอะไรมากกว่ากัน ซึ่งจะเลือกแบบไหน ก็ไม่มีใครผิด ไม่มีใครถูก แล้วแต่แนวคิดของแบรนด์นั้น ๆ ไม่มีใครชนะใคร ไม่มีใครแพ้ใคร แล้วแต่เราจะเอาอะไรมาเครื่องชี้วัด

แต่จะเอา 2 อย่างพร้อมกัน มันไม่ได้นะครับ

ถ้าเอาช้า แต่ชัวร์ ข้อมูลชิ้นเดียวกัน จะถูกส่งด้วย Tx ทุก ๆ Chain (แต่ละ Tx Chain จะนำข้อมูลชุดนั้นส่งออกไปด้วยตัวเองในคนละเวลากับ Tx chain อื่น ๆ โดยแต่ละ Tx Chain ก็จะใช้ Subcarrier ของ OFDM Radio แตกต่างกัน) เพิ่มโอกาสให้ผู้รับได้ข้อมูลจากหลาย (Sub carrier) Space และ Time ที่แตกต่างกัน เรียกว่า ทำ Space Time Block Code (STBC)

ถ้าจะเอา “เร็ว-แรง” ก็จะเอาหลาย Tx นั้นมาทำงานประกอบกัน ปรับ Vector ของ phase ของคลื่นนิดหน่อย เมื่อเอาคลื่นของแต่ละ Tx chain มาชนกันก็จะกลายเป็น TxBF คือรวมกันเป็นคลื่น Tx chain เดียวที่มี dB สูงขึ้น (In phased หรือ Constructive interference) นั่นเอง เมื่อ dB สูงขึ้น client ก็จะสามารถรับด้วย data rate ที่สูงขึ้นได้ แต่ก็จะมีข้อมูลนั้นแค่ชุดเดียวถูกส่งออกไปในอากาศ ความเร็ว-แรงนี้ จึงแลกมาด้วยความชัวร์ที่ด้อยกว่าแบบ STBC

แล้ว Rx เยอะ ๆ มีไว้ทำไม

แต่ละ Rx chain ต่างคนต่างก็รับข้อมูลเข้ามาครับ และ AP ก็จะเอาข้อมูลที่ได้จากแต่ละ Rx chain มาประกอบกัน (Combine) เรียกว่า Maximal Ratio Combining เป็นหลักการ MIMO ทั่วไป

แต่เดิมก่อนจะมี MIMO เราใช้ Rx ชุดเดียวรับข้อมูล (ตั้งแต่สมัย 11g นู่น) หากรับพลาดก็พลาดเลย เป็นหลักการแบบ Diversity antenna

ต่อเรา เราใช้ Rx หลายชุด (MI หรือ Multiple Input) รับข้อมูล บาง Rx chain อาจจะรับข้อมูลแล้วพลาดข้อมูลส่วนหัว บาง Rx chain อาจจะรับข้อมูลแล้วไปพลาดข้อมูลส่วนหาง ถ้าเอาข้อมูลจาก 2 Rx chain นี้มาประกอบกัน (Combine) แกะหัว แปะหาง ในที่สุดก็จะได้ข้อมูลที่สมบูรณ์มาใช้งาน ทำให้การรับข้อมูลเก่งขึ้น มีโอกาสสำเร็จมากขึ้น

Rx เลขยิ่งเยอะ ก็ยิ่งดี คือเพิ่มโอกาสในการรับข้อมูล

ในทางปฏิบัติ MRC ก็ทำงานได้ไม่สมบูรณ์ เพราะ Mobile Client มีการบิดแกนของเสา (Polarity) ไปมา ตือบางทีก็ตั้งหน้าจอขึ้น บางทีก็ใช้หน้าจอเป็นแนวนอน สัญญาณที่ส่งออกมาจาก Client จึงมาได้ทั้งแกนตั้งและแกนนอน (Vertical polarization และ Horizontal polarization)

หากเป็น AP อื่น ถ้าเสาของเขาเป็นแกนตั้ง สัญญาณเข้ามาเป็นแกนนอน ต่อให้มีกี่ Rx ก็รับสัญญาณได้ไม่ดี หรือรับได้ก็ได้ dB ที่ต่ำกว่า เมื่อ dB ต่ำก็จะหมายถึง data rate (Mbps) ขารับที่ต่ำตามลงไปด้วย นั่นก็เพราะแกนเสากับแกนสัญญาณไม่ตรงกัน

แต่สำหรับ Ruckus AP ที่มีเสา 2 แกน ไม่ว่าสัญญาณจะเข้ามาแกนตั้งหรือแกนนอน เราก็มีเสารอรับเอาไว้ได้ทั้ง 2 แกน ขารับของ Ruckus จึงมักจะรับสัญญาณได้ดีกว่า AP อื่น ๆ ถึง 4dB ซึ่งอาจจะหมายถึง data rate (Mbps) ที่แตกต่างกันถึงเท่าตัว !!!

ดังนั้น AP อื่น ๆ ในตลาดจะมี Rx ที่ทำได้แค่ MRC (Maximal Ratio Combining) แต่ของ Ruckus AP จะเหนือกว่าด้วย PD-MRC (Polarization Diversity – MRC) เป็นลิขสิทธิ์เฉพาะของ Ruckus เท่านั้น

Tx คูณ Rx : SS ไม่มากเกินกว่าจะจดจำ ไม่ลำบากเกินกว่าจะทำความเข้าใจ