บทความนี้สรุปข้อควรพิจารณาและแนวทางปฏิบัติที่ดีในการวางแผนมิเรอร์การรับส่งข้อมูล (Traffic Mirroring) สำหรับการปรับใช้ Sangfor Athena STA ร่วมกับ Athena NDR (เดิมชื่อ Cyber Command) เนื้อหาครอบคลุมหลักการเลือกทิศทางของทราฟฟิก การวาง STA เดี่ยวและหลายตัว สถานการณ์ NAT การทำงานร่วมกับ Load Balancer/Proxy เซิร์ฟเวอร์ DNS ภายใน อุปกรณ์ Scanner/SNMP/OMS ข้อควรพิจารณาสำหรับทราฟฟิกเข้ารหัส และตารางพอร์ตการสื่อสารที่ต้องเปิดระหว่างอุปกรณ์

 

1. ภาพรวม

ผลิตภัณฑ์ประเภท Athena NDR (Cyber Command) แตกต่างจากผลิตภัณฑ์ประเภท Gateway (เช่น WAF, NGAF, IPS เป็นต้น) โดย NDR เป็นแพลตฟอร์มที่ทำงานร่วมกับ Sensor (STA) ซึ่งติดตั้งในรูปแบบ Bypass ดังนั้นการติดตั้งและการปรับใช้จะไม่ส่งผลกระทบต่อเครือข่ายของลูกค้า โดยเพียงต้องตั้งค่า Port Mirroring บนสวิตช์เท่านั้น ซึ่งทำได้ง่ายและรวดเร็ว

อย่างไรก็ตาม ก่อนการปรับใช้จริง มีสถานการณ์เฉพาะบางประการที่ต้องศึกษาและวางแผนให้รอบคอบ เช่น สถานการณ์ที่มีการทำ NAT, สถานการณ์ที่มี Load Balancer/Proxy, สถานการณ์ที่มี DNS Server ภายใน เป็นต้น โดยสรุปแนวทางหลักได้ดังนี้

 

ทิศทางของทราฟฟิก (Traffic Direction): โดยหลักการแล้ว ทราฟฟิกที่นำมามิเรอร์จะพิจารณาจากสามทิศทางหลัก ได้แก่ Outbound Access, Inbound Access และ Lateral Access

• Outbound Access คือทราฟฟิกจากเครื่องภายในหรือ Terminal Server ที่ออกไปสู่อินเทอร์เน็ต
• Inbound Access คือทราฟฟิกจากผู้ใช้งานภายนอกที่เข้ามาใช้งานเซิร์ฟเวอร์ภายใน
• Lateral Access คือทราฟฟิกที่สื่อสารข้าม Security Zone ภายในองค์กร เช่น ระหว่างเครื่อง End User ไปยัง Server ภายใน หรือการเชื่อมต่อระหว่างสาขา (Branch) กับสำนักงานใหญ่ผ่าน Leased Line/VPN

ในการกำหนด Mirroring Policy ควรให้ความสำคัญกับการครอบคลุม Outbound และ Inbound Access เป็นลำดับแรก ส่วน Lateral Access ให้ครอบคลุมให้ได้มากที่สุดเท่าที่จะทำได้

 

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

 

หลักการกระจายจุดมิเรอร์ (Sinking Principle): ในทางทฤษฎี ควรวางจุดมิเรอร์ทราฟฟิกให้กระจายไปอยู่ใกล้กับต้นทางของทราฟฟิกให้มากที่สุดเท่าที่จะเป็นไปได้ เช่น การมิเรอร์ก่อนที่ทราฟฟิกจะเข้าสู่ DHCP Server, DNS Server หรือเซิร์ฟเวอร์ภายในอื่น ๆ ซึ่งจะช่วยให้การดำเนินงานด้านความปลอดภัยภายหลังทำได้ง่ายและแม่นยำยิ่งขึ้น

 

ประเด็นด้านประสิทธิภาพ (Performance): ตัวอย่างเช่น ในสถานการณ์ Data Center ที่ลิงก์ภายในเป็น 10GE และปริมาณ Lateral Access มักจะมากกว่าทราฟฟิกขาเข้า (Inbound) ในกรณีเช่นนี้จำเป็นต้องประเมินว่า STA รุ่นที่ใช้อยู่สามารถรองรับปริมาณ Lateral Access ดังกล่าวได้หรือไม่

 

Mirroring Switches: สำหรับลูกค้าในกลุ่มอุตสาหกรรมบางราย แม้จะทำมิเรอร์เฉพาะทราฟฟิกที่ออกจาก Core Switch เพียงจุดเดียว ปริมาณทราฟฟิกก็อาจสูงมากจนกระทั่ง STA เพียงตัวเดียวไม่สามารถรองรับได้ ในกรณีเช่นนี้ต้องอัปเกรดเป็น STA รุ่นที่ใหญ่ขึ้น หรือในทางกลับกัน อาจต้องใช้ TAP Switch เพื่อแจกจ่ายทราฟฟิกมิเรอร์ไปยัง STA หลายตัว

 

ทราฟฟิกแบบทิศทางเดียว (One-way Traffic): STA วิเคราะห์ข้อมูลโดยอิงกับ Session ที่สมบูรณ์ ดังนั้นในการกำหนด Mirroring Policy จะต้องมั่นใจว่าทราฟฟิกทั้งฝั่ง Request และ Response ถูกมิเรอร์มาครบถ้วน หลีกเลี่ยงการมิเรอร์เฉพาะทิศทางเดียว เพราะโดยส่วนใหญ่ STA จะไม่สามารถวิเคราะห์ได้

 

อุปกรณ์ทั่วไป (General Devices): อุปกรณ์ประเภท NAT, DNS, SNMP, OMS, Scanner และอื่น ๆ ต้องพิจารณาแยกเป็นกรณีเฉพาะ (รายละเอียดเพิ่มเติมดูในหัวข้อถัดไป)

 

2. กรณีใช้งาน STA ตัวเดียว (Single STA)

ให้พิจารณาอินเตอร์เฟซของสวิตช์เป็นหน่วยหลักในการวิเคราะห์ และวิเคราะห์ทราฟฟิกภายในแต่ละพื้นที่ (Zone) เพื่อกำหนดจำนวนขั้นต่ำหรือชุดการผสมผสานของ Observation Port ที่เหมาะสมที่สุดสำหรับการทำมิเรอร์

ตัวอย่าง: อินเตอร์เฟซ ① ② ③ ④ ของ Core Switch เชื่อมต่อกับ 4 พื้นที่ตามลำดับ นโยบาย Mirroring เดิมคือการมิเรอร์ทั้ง 4 พอร์ตตามที่แสดงในภาพด้านล่าง

จากนั้นวิเคราะห์และวาดทิศทางการเข้าถึง เพื่อตรวจสอบว่ามีทราฟฟิกซ้ำซ้อนเกิดขึ้นหรือไม่

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

 

3. กรณีใช้งาน STA หลายตัว (Multiple STAs)

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

ตัวอย่างด้านล่างเป็นกรณีใช้งานจริงของลูกค้า ซึ่งพบปัญหาดังนี้

1. มิเรอร์ทราฟฟิกหลังจากที่ผ่าน Source NAT แล้ว
2. พื้นที่สำคัญบางส่วน เช่น Production Zone และ R&D Test Zone ไม่ได้ถูกครอบคลุม ทำให้ ไม่สามารถใช้ความสามารถของ STA ได้อย่างเต็มที่
3. มีการส่งข้อมูลซ้ำซ้อนระหว่าง STA-01 และ STA-02

 

หลังจากวิเคราะห์ปัญหาแล้ว สามารถปรับตำแหน่งการติดตั้งใหม่ได้ดังนี้

• STA-01 ครอบคลุมสาขาและโซนอื่น ๆ เพื่อตรวจจับภัยคุกคาม
• STA-02 ครอบคลุม Production Zone และ R&D Test Zone เพื่อตรวจจับภัยคุกคาม

 

4. สถานการณ์ที่มี NAT

NAT มีอยู่สามประเภทหลัก ได้แก่ Source NAT, Destination NAT และ Two-way NAT (Bidirectional NAT) สำหรับกรณี Two-way NAT นั้นไม่มีวิธีที่ดีในการวิเคราะห์ความสัมพันธ์ของอุปกรณ์ทั้งก่อนและหลัง NAT เนื่องจากทั้ง Source IP และ Destination IP ถูกแทนที่พร้อมกัน

 

4.1 Source NAT

ต้องมั่นใจว่าจุดที่ทำมิเรอร์ทราฟฟิกอยู่ ก่อน การทำ Source NAT เพื่อให้ STA เห็น Source IP จริงของเครื่องต้นทางในเครือข่ายภายใน

 

4.2 Destination NAT

ต้องมั่นใจว่าจุดที่ทำมิเรอร์ทราฟฟิกอยู่ หลัง การทำ Destination NAT เพื่อให้ STA เห็น Destination IP จริงของเซิร์ฟเวอร์ปลายทาง

 

5. สถานการณ์ที่มี Load Balancer/Proxy

5.1 ความเข้าใจพื้นฐาน

ในสถานการณ์ Multi-level Proxy ฟิลด์ X-Forwarded-For ใน HTTP Request Header จะถูกใช้บันทึกลำดับ IP ของ Proxy ทั้งหมดตั้งแต่ Client Address ไปจนถึง Proxy Server ตัวสุดท้าย ดังภาพด้านล่าง

เมื่อต้องการติดตามหาต้นทางของผู้โจมตีจากฟิลด์ X-Forwarded-For นั้น IP ตัวแรกในฟิลด์นี้โดยทั่วไปจะเป็น Physical Address ของเครื่อง Client จริง ตามตัวอย่างในภาพด้านล่าง ทราฟฟิกที่ผ่าน Proxy 2 ชั้นจะมี IP ดังนี้

• IP ต้นทางจริงของ Resource: 219.76.33.91
• First Proxy: 10.100.86.254
• Second Proxy: 10.100.86.14

 

5.2 ตำแหน่งของจุดมิเรอร์

ในสถานการณ์ Reverse Proxy แนะนำให้วางจุดมิเรอร์ทราฟฟิก STA ไว้ หลัง Reverse Proxy Server เนื่องจาก Athena NDR สามารถตรวจจับและแสดงฟิลด์ X-Forwarded-For ได้ในหน้า Security Alert ทำให้สามารถระบุ IP ต้นทางจริงของ Client ได้

 

6. สถานการณ์ที่มี Internal DNS Server

6.1 คำอธิบายของสถานการณ์

โครงสร้างเครือข่ายด้านบนแสดงถึงสถานการณ์ที่มี Internal DNS Server ในระบบของลูกค้าบางราย หาก STA ได้รับทราฟฟิกเฉพาะส่วนที่อยู่หลัง DNS Server ภายใน จะทำให้ STA เข้าใจผิดว่า DNS Server เป็น Vulnerable Host และไม่สามารถวิเคราะห์เพื่อระบุเครื่องต้นทางที่แท้จริงได้

 

6.2 การอนุมานตำแหน่งมิเรอร์จาก Log

มี 3 เงื่อนไขที่สามารถใช้อนุมานตำแหน่งของทราฟฟิกมิเรอร์ที่เกี่ยวข้องกับ Internal DNS Server ได้

กรณีที่ 1: ตรวจสอบ DNS Log บนแพลตฟอร์ม Athena NDR หาก IP ของ Internal DNS Server ปรากฏเป็นทั้ง Source และ Destination ใน Log แสดงว่าทราฟฟิกทั้งก่อนและหลัง DNS Server ถูกมิเรอร์ทั้งหมด ในกรณีนี้ต้องเพิ่ม IP ของ DNS Server เข้าใน Security Whitelist ในฐานะ Source Address และปรับแก้ Mirroring Policy ให้เหมาะสม

กรณีที่ 2: ตรวจสอบ DNS Log บนแพลตฟอร์ม Athena NDR หาก IP ของ Internal DNS Server ปรากฏเฉพาะในฟิลด์ Destination Address แสดงว่าทราฟฟิกที่มิเรอร์มาคือทราฟฟิก ก่อน ถึง DNS Server ซึ่งถูกต้องแล้ว ไม่ต้องแก้ไขใด ๆ

กรณีที่ 3: ตรวจสอบ DNS Record บนแพลตฟอร์ม Athena NDR หาก Internal DNS Server ปรากฏเป็น Source Address เพียงอย่างเดียว แสดงว่าทราฟฟิกที่มิเรอร์มาคือทราฟฟิก หลัง DNS Server เท่านั้น ในกรณีนี้จะไม่สามารถระบุเครื่องต้นทางที่เป็นปัญหาได้ จำเป็นต้องเปลี่ยนตำแหน่งของ Observation Port เพื่อมิเรอร์ทราฟฟิกที่ถูกต้อง

 

7. สถานการณ์ที่มี Scanner / SNMP / OMS

อุปกรณ์ประเภท Scanner, SNMP และ OMS (Operation Management System) หากไม่มีการจัดการที่เหมาะสมจะทำให้ Athena NDR ตัดสินใจผิดพลาดได้ จึงแนะนำให้เพิ่มอุปกรณ์เหล่านี้เข้า Whitelist ในช่วงการปรับใช้

 

8. ข้อควรพิจารณาสำหรับทราฟฟิกเข้ารหัส

ในปัจจุบัน ระบบงานสำคัญส่วนใหญ่สื่อสารผ่าน HTTPS แทน HTTP ดังนั้นหากไม่ได้ import Private Key ของเซิร์ฟเวอร์ปลายทางเข้า STA ทราฟฟิก Inbound Access จะไม่สามารถถูกถอดรหัสและวิเคราะห์ได้

 

【ขอบเขตที่รองรับ】

โปรโตคอลการเข้ารหัสที่ STA รองรับ ได้แก่

SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2

 

อัลกอริทึมที่ STA รองรับ ได้แก่

• Symmetric Algorithms: DES, 3DES, AES
• Asymmetric Algorithms: รองรับ RSA และ ECDH แต่ไม่รองรับ ECDHE

 

วิธีตรวจสอบว่า HTTPS Traffic ใช้การเข้ารหัสแบบใด

สามารถตรวจสอบได้โดยการ Capture HTTPS Traffic แล้วดูที่ข้อมูลใน Server Hello Response ดังภาพด้านล่าง

 

ตำแหน่งที่ใช้ import Private Key บน STA

ไปที่เมนู: System > Cyber Command

 

หมายเหตุ: เนื่องจากการถอดรหัสบน STA เป็นแบบ Software Decoding ไม่ใช่ Hardware Decoding Card ดังนั้นจะใช้ทรัพยากรของ STA พอสมควรและอาจส่งผลต่อประสิทธิภาพการทำงาน

 

9. ภาคผนวก (Index)

9.1 พอร์ตการสื่อสาร (Communication Ports)

ตารางด้านล่างแสดงพอร์ตและโดเมนที่ Athena NDR (Cyber Command), STA และอุปกรณ์ที่เกี่ยวข้องใช้งานในการสื่อสารระหว่างกัน รวมถึงการเชื่อมต่อออกไปยัง Sangfor Cloud Service สำหรับการอัปเดตฐานข้อมูลและบริการต่าง ๆ

โดเมน / Destination IP	พอร์ต	การใช้งาน
IP Address ของ NDR (Cyber Command): พอร์ต 443, 4430, 4488	443 (TCP), 4430 (TCP), 4488 (TCP)	พอร์ต 443 และ 4430 ของ NDR ใช้สำหรับ STA ในการ Sync Log/Records มายัง NDR พอร์ต 4488 ของ NDR ใช้สำหรับ STA ส่งคำขออัปเดตฐานข้อมูล (Signature Database) ผ่าน NDR
IP Address ของ NDR: พอร์ต 4430 IP Address ของ NGAF: พอร์ต 7443	4430 (TCP), 7443 (TCP)	พอร์ต 7443 ของ NGAF ใช้สำหรับการ Integration ระหว่าง NDR กับ NGAF (NDR push)
IP Address ของ NDR: พอร์ต 7443 IP Address ของ Endpoint Secure (ES): พอร์ต 443	4430 (TCP), 7443 (TCP)	พอร์ต 7443 ของ NDR ใช้สำหรับ Endpoint Secure (ES) Sync Record มายัง NDR พอร์ต 443 ของ ES ใช้สำหรับ NDR push การทำ Integration ไปยัง ES
IP Address ของ IAG: พอร์ต 7443 หรือ 9998 IP Address ของ NDR: พอร์ต 1775 หรือ 7443	7443 (TCP), 9998 (TCP), 1775 (UDP)	พอร์ต 7443 และ 9998 ของ IAG ใช้สำหรับ NDR ในการ Integration กับ IAG พอร์ต 1775 ของ IAG ใช้สำหรับ IAG sync ข้อมูล User มายัง NDR พอร์ต 7443 ของ IAG ใช้สำหรับ IAG ส่งข้อมูล Asset มายัง NDR
update1.sangfor.net	80 (TCP), 443 (TCP), 53 (UDP)	Update Server 1 สำหรับการอัปเดตฐานข้อมูล
update2.sangfor.net	80 (TCP), 443 (TCP), 53 (UDP)	Update Server 2 สำหรับการอัปเดตฐานข้อมูล
update3.sangfor.net	80 (TCP), 443 (TCP), 53 (UDP)	Update Server 3 สำหรับการอัปเดตฐานข้อมูล
121.46.26.221	80 (TCP), 443 (TCP), 53 (UDP)	Update Server 4 สำหรับการอัปเดตฐานข้อมูล
sp1.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	System Patch Update Server 1
sp2.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	System Patch Update Server 2
sp3.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	System Patch Update Server 3
DNS Server บน NDR	53 (UDP)	สำหรับการ Resolve Domain Name
auth.sea.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	บริการยืนยันตัวตน (Authentication)
upd.sea.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	การอัปเดตค่าคอนฟิก (Configuration Update)
clt.sea.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Sync Logs
ti.sea.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Threat Intelligence
intelligence.sea.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Threat Intelligence
analysis.sea.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Threat Intelligence
edrsaas.sangfor.com	8083, 443, 54120, 80	SaaS-EDR (Endpoint Secure SaaS)
edragent.sangfor.com	8083, 443, 54120, 80	การสื่อสารระหว่าง Client/Server ของ Endpoint Agent
x.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Device Management
device.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Device Authorization Server
device.scloud.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Device Management
partner.sangfor.com	80 (TCP), 443 (TCP), 53 (UDP)	Partner Portal
remote0.scloud.sangfor.com	5000 (TCP, UDP)	Device Management (Remote)