เตือนด้วยความหวังดี เพราะ URL Phishing ออกอาละวาด (อีกแล้ว)

เตือนด้วยความหวังดี เพราะ URL Phishing ออกอาละวาด (อีกแล้ว) 600X300

มีรายงานจาก Microsoft Office 365 ว่ามีผู้ไม่ประสงค์ดีใช้วิธีที่มีความซับซ้อนและหลากหลายในการหลบเลี่ยงการป้องกัน รวมถึง การวิเคราะห์และการตรวจจับอัตโนมัติ จาก Microsoft Office 365 (ขยันเนอะ) เช่น การใช้ sandbox ซึ่งหนึ่งในวิธีการหลบเลี่ยงการตรวจจับที่ถูกใช้ในการโจมตี และขโมย credential ขององค์กรที่เป็นเป้าหมาย

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

นอกจากนี้ ยังมีเรื่องของ Email ที่เมื่อผู้ใช้งานมีการใช้รูปแบบหัวอีเมล์อย่างเช่น “Password Update”, “Exchange protection”, “Helpdesk-#”, “SharePoint” และ “Projects_communications” ก็ยังสุ่มเสี่ยงที่จะถูกใช้เป็นตัวล่อในด้าน social engineering เพื่อเพิ่มความน่าสนใจที่เป้าหมายจะทำการไปยัง Link Phishing URL ที่ฝังอยู่ในอีเมล์แต่ละฉบับอีกด้วย

ก็อย่างที่เคยเตือนไปก่อนหน้านี้ เพื่อความปลอดภัยของผู้ใช้งานและองค์กรของเราเอง เราเองก็ต้องเช็คให้ชัวร์ก่อนว่าเมลล์ที่ส่งมา มีที่มาที่ไปที่น่าเชื่อถือ และปลอดภัยใช่หรือไม่ และถ้าหากมีอีเมล์แปลกๆ เข้ามา ก็ต้องตั้งสติ คิดพิจารณาก่อนว่ามันเกี่ยวข้องกับเราหรือไม่ และเมล์นั้นมีความเป็นไปได้ที่จะเกี่ยวเนื่องกับงานของเราจริงๆ ใช่หรือไม่ แต่ ถ้าอยากให้ชัวร์ และปลอดภัยมากขึ้น ออพติมุสก็อยากจะแนะนำให้รู้จักกับ “DNSWatchGO” ซึ่งเป็นตัวช่วยให้กับคุณเพื่อป้องกันและปกป้องจากการหลอกลวงทางอินเตอร์เน็ต (Phishing) ในรูปแบบของ Cloud-based service หลักการทำงานของ “DNSWatchGO” คือจะทำหน้าที่กรองข้อมูลของ DNS ของเว็บไซต์ เพื่อตรวจจับและทำการบล็อกจากอันตรายต่างๆ ไม่ว่าจะเป็น URL ปลอม หรือ Virus ,Ransomware ที่แอบแฝงในเว็บ ที่ต้องการจะมาโจมตีของเรา

 

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

02-2479898 ต่อ 87 

ทำให้ Firebox System Manager แสดงผลเร็วขึ้น

มีอยู่บาง Tab ใน Firebox System Manager เช่น Bandwidth meter หรือ Service Watch ที่แสดงผลในรูปของเส้นกราฟ ที่จะขยับขึ้นลงตาม Bandwidth ซึ่ง Default refresh rate สั้นที่สุดที่เลือกได้คือ 5 วินาที

บางครั้ง 5 วินาทีก็นานเกินไป สมมติว่า เราอยากจะทำให้เส้นกราฟมีการอัพเดตทุก ๆ 1 วินาที

ก็แก้ได้ง่าย ๆ ด้วยการคลิกไปที่เลข 5 และแก้ให้เป็นเลข 1 เท่านี้ ก็จะทำให้ Refresh rate กลายเป็น 1 วินาที ตามภาพด้านล่าง

SSID น้อย ๆ หน่อย

Ruckus AP สามารถจะทำงานในโหมด Standalone ได้ และเราสามารถใช้ Web UI เพื่อ config ให้ Ruckus AP นั้น เปิด SSID ให้กับแต่ละ Band (2.4/5GHz) ได้ถึง 8 SSIDs

เมื่อนานมาแล้ว ผมเคยได้ยินคน ๆ หนึ่ง เขาหยิบ Standalone AP ตัวนี้ขึ้นมา เขาบอกว่า

“ผมตั้งให้ทั้ง 8 SSID ในแต่ละ Band มีชื่อเดียวกันทั้งหมด เพราะจะทำให้ Client ในระบบ หันมาเกาะกับ AP ของผมก่อนเป็นอันดับแรก แทนที่จะไปเลือกเกาะ AP ของคนอื่นก่อน”

ผมได้แต่รำพึงในใจว่า "ทำไปได้ -_-"

วันนี้ ผมอ่านไปถึง website แห่งหนึ่ง ซึ่งเขามีเครื่องมือที่น่าสนใจ เรียกว่า SSID Overhead Calculator ต้นฉบับดูได้จากที่นี่ครับ

http://revolutionwifi.blogspot.com/p/ssid-overhead-calculator.html

Wifi คือ การแก่งแย่งกันใช้ความถี่

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

ไม่มี Wifi client ใด “จองใช้ความถี่” ได้ ใน Wifi control frame / management frame ไม่มีตัวเลือกให้ทำแบบนั้นได้ เป็นกฎง่าย ๆ มาก่อน ได้ก่อน

ดังนั้น Wifi network ที่ดี คือการใช้ความถี่ในเวลาสั้นที่สุด ใช้เมื่อจำเป็น และต้องได้ประโยชน์ ซึ่ง Beacon frame เป็น Management Frame ที่ส่งออกมาจาก AP ด้วย Data rate ต่ำสุด (1Mbps หรือ 6Mbps) จึงเป็น Frame ที่ปรากฏตัวในอากาศ (ใช้ความถี่) เป็นระยะเวลานานมาก แปลง่าย ๆ คือ Beacon frame ถ้ามีเยอะเกินไป ก็จะกลายเป็นตัวลด Wifi performance

สมมุติว่า 1 AP เราเปิด 2 SSID โดย AP นั้น (ตามปกติ) จะส่ง Beacon frame ออกมาทุก ๆ 100mS (Beacon interval = 10) ดังนั้น AP ตัวนี้จะส่ง 2 Beacon ในทุก ๆ 100mS ซึ่งตามตารางของ website “Revolusion Wifi” นี้ เขาคำนวณว่า จะมี Overhead ของ Airtime = 6.45%

หมายความว่า เวลาของความถี่ จะหายไป 6.45% เป็นตัวเลขที่เกิดขึ้นกับทุกยี่ห้อ ทุกราคา

ยิ่งมี AP ในพื้นที่เดียวกันมากขึ้น ถ้า AP เหล่านั้นใช้ความถี่เดียวกัน ก็จะยิ่งระดมส่ง Beacon ออกมา ทำให้เปลืองเวลาของความถี่มากขึ้นไปอีก

บางครั้งด้วยความไม่รู้ บางคนก็ยิ่งไปตั้ง Beacon rate หรือ Beacon interval จาก 10 กลายเป็น 100 ก็ยิ่งทำให้ Wifi performance ห่วยหนักลงไปกว่าเดิมอีก 10 เท่า !!!

ย้อนกลับมาที่เรื่องเล่า

ที่คนนั้น เขาบอกว่า “เขาจะเปิด SSID เป็นชื่อเดียวกันทั้ง 8 SSID บน AP ตัวเดียวกัน” ตามตารางของ Revolution wifi คน ๆ นั้นเขากำลัง “ลดประสิทธิภาพของ Wifi ของเขาลง 25.80%”

ในทางกลับกัน ถ้าเขาทำในสิ่งที่คนปกติเขาทำกัน คือ เปิดใช้แค่ 1 SSID Overhead จะลดลงมาเหลือ 3.22% (ได้ Airtime คืนมา 22% ประสิทธิภาพต่างกันกี่เท่า ลองประเมินดูครับ)

การเปิด SSID ใหม่ ถ้าไม่ได้ทำให้เกิด Overhead มาก ก็สามารทำได้ ความพยายามทำให้ Overhead ต่ำที่สุด ย่อมดีกับ Wifi performance เสมอ

สำรวจระบบของเรา

ลองดูว่า Wifi network ของคุณว่า มีกี่ SSID ประเมินร่วมกับจำนวน AP ที่ทำงานใน Channel เดียวกันในพื้นที่เดียวกัน และลองหาดูว่า Overhead ในระบบของคุณที่เกิดจาก Beacon frame นั้น อยู่ที่กี่เปอร์เซ็นต์ คุ้มหรือไม่ที่คุณจะเปิด SSID เพิ่มขึ้นมาใหม่

บางที…คุณปิด SSID ที่ไม่จำเป็น ยุบรวม SSID ลง ความเข้าใจที่ถูกต้องเกี่ยวกับ Client roaming, Dynamic VLAN, VLAN pooling ช่วยให้คุณตัดสินใจยกเลิกบาง SSID ออกได้

ลด SSID ช่วยเพิ่มประสิทธิภาพของ Wifi ได้ครับ

ZD อ่าน OS ของ Wifi client ได้อย่างไร

เป็นหลักการทำงานของ Process to identify wifi client OS หรือจะเรียกสั้น ๆ ว่า Client Fingerprint ก็ได้

ZD ตั้งแต่เวอร์ชั่น 9.4 ขึ้นมา (กลางปี 2012) Ruckus ได้เพิ่มความสามารถให้ ZD แสดง OS ของ Client ออกมาใน Monitor screen ได้ ช่วยให้ Admin มองเห็นตัวตนของ Client ได้ชัดเจนขึ้น มีประโยชน์มากในการ Diagnostic และ Trouble shooting เรียกความสามารถนี้ว่า Client Fingerprint

Client fingerprint คือความพยายามที่เราจะขุดคุ้ย หาดูว่า OS บน client เครื่องนั้นคืออะไร โดยไม่แตะต้องและไม่ติดต่อกับ client เครื่องนั้น ใช้เพียงแต่วิธีการดักจับ packet ที่ client เครื่องนั้นส่งออกมา แล้ววิเคราะห์ว่า มันน่าจะเป็น OS อะไร

ใน ZD เมื่อเราสร้าง WLAN จะมีออพชั่น Enable Client FingerPrint เปิดเอาไว้เป็นค่า Default

หมายความว่า packet ของ client ที่ส่งเข้ามาทาง WLAN นี้ AP จะคอยสอดส่องและวิเคราะห์ว่าเป็น OS อะไร และนำไปแสดงผลที่ Monitor ของ ZD

OS ไหน ดูอย่างไร

การทำ Client Fingerprint นั้น ไม่ใช่เรื่องใหม่ มีมานานแล้ว มีมาก่อน Wifi จะเกิด และมีมากมายหลายวิธีที่จะใช้วิเคราะห์ได้ว่า Packet ที่จับมาได้นั้น มาจาก OS ไหน

วิธีที่นิยม คือดูจาก DHCP packet ครับ เวลาที่ client เริ่มเปิดขึ้นมาทำงาน สิ่งแรก ๆ ที่ Client จะทำคือส่ง DHCP process หรือที่บางทีก็เรียกหรู ๆ ว่า DORA (Discovery, Offer, Request, Acknowledge) ซึ่งจะเรียกว่าเป็น DHCP DORAemon ก็ว่ากันไป

ใน DHCP Request packet ปกติแล้ว Client จะใส่ Class ID (option 60) และ Parameter Request List (Option 55) เข้ามาใน DHCP Request ด้วย
       – Class ID จะบอกยี่ห้อ (และรุ่น) ของ Client
       – ส่วน Parameter Request List คือรายการที่ Client ใช้บอกว่า ต้องการจะให้ DHCP server กำหนดค่าอะไรให้บ้าง

เช่น ถ้าเราจับ DHCP Request packet ของ Client มากางออกดู หน้าตาของ Option 60 และ Option 55 จะเป็นแบบนี้

Option 60 และ 55 หน้าตาแบบนี้...มันคือ Windows XP

แค่จะขอ IP ทำไม Client ต้องแจ้งให้ DHCP server รู้ด้วยเหรอว่า "ฉันคือ OS อะไร"

ในระบบที่ไม่ซับซ้อน DHCP จะทำหน้าที่เพียงการกำหนด IP, Subnet, Gateway, DNS ให้กับ Client เท่านั้น หลายครั้ง DHCP จึงมักจะถูกมองว่า “ทำได้แค่นี้”

แต่ DHCP server ถูกออกแบบมาตามชื่อ คือ Dynamic Host Configuration Protocol Server คือ IP Setting ทุกอย่างที่เราสามารถจะเซ็ตให้กับ Client ได้ เราสามารถจะฝากให้ DHCP เป็นผู้ส่ง IP Setting นั้นให้ Client ได้ เช่น เราต้องการให้ Client ใช้ NTP ตัวไหน, SMTP server IP อะไร หรือเครื่องไหนจะต้องกำหนด Host name เป็นชื่ออะไร กำหนดเอาไว้ที่ DHCP ได้หมดเลย

IP Setting แต่ละหัวข้อ เรียกว่า Option ซึ่งแต่ละ Option ก็มีเลขกำกับ ต้องดูตาราง Option แบบเต็ม ๆ (มีอยู่ 200 กว่า option) จึงจะรู้ว่า DHCP server ทำอะไรได้บ้าง ดูที่นี่

ซึ่งใคร จะได้รับ Config ไหนไปใช้ ถ้า admin ไม่ได้กำหนดอะไร ก็จะใช้ Main scope option ร่วมกัน แต่ถ้าต้องการแยกแยะรายการ option ให้แตกต่างกันไปตามในแต่ละ client ก็ทำได้ ก็ขึ้นอยู่กับ Client identity ซึ่ง Client ID ที่เราคุ้นเคยกันก็คือ MAC address วิธีที่เราใช้กันมากที่สุดคือ IP address reservation ด้วย MAC address หรือบางทีก็เรียกติดปากว่า MAC regis

ทีนี้ลองขยายความคิดของเรา ให้เงื่อนไขมันยากขึ้นมาอีกหน่อยครับ สมมติว่าเราต้องดูแลองค์กรที่มีเครื่องเป็นจำนวนมาก และมี Subnet เป็นจำนวนมาก และพอดีว่า องค์กรนี้ก็มี Organization ทางด้าน IP config ที่เข้มงวด จู่ ๆ วันหนึ่ง มีนโยบายออกมาว่า Network Printer ทั้งองค์กร จะต้องชี้ DNS ไปที่ 192.168.10.33 ส่วน Client อื่น ๆ ให้ใช้ DNS ที่ใช้อยู่ปัจจุบัน เหมือนเดิม

ในขณะที่ Network Printer ขององค์กรนี้ มีอยู่ 130 เครื่อง วิธีที่เรารู้ว่า เราสามารถจะทำ MAC address reservation เพื่อกำหนด IP config ที่แตกต่างให้กับ MAC address นั้น ยังคงใช้งานได้อยู่ ตราบเท่าที่เรายินดีจะไปตามล่าสืบเสาะหา MAC address ของ Network Printer ทั้ง 130 มาได้จนครบ รวมถึงว่า ทุกครั้งที่มีการซื้อหรือปลด Network printer เข้า-ออกจากระบบ เราก็ต้องมาตามเก็บ DHCP config เพิ่ม-ลด MAC address ใน DHCP server ก็จะเป็นภาระหนักสำหรับงาน admin

วิธีที่ง่ายกว่านั้นคือ การใช้ DHCP option 60 หรือ Class ID นั่นเอง

แสดงการกำหนดว่า หาก Vendor class เป็น Ruckus CPE ก็ให้แจ้งกับ Client ไปว่า Option 43 มีค่าเท่ากับ 10.0.1.5, 10.0.1.6

ดังนั้น สมมติว่าองค์กรนี้ มี Network printer อยู่ 3 ยี่ห้อ เราก็สร้าง Vendor class ขึ้นมา 3 ตัวตาม Class ID ของยี่ห้อนั้น ๆ และใส่ DNS option เข้าไปในแต่ละ Vendor class ก็จบแล้ว

3 บรรทัดเพื่อจัดการ 130 client ไม่ใช่ 130 reservation โดยใช้ client MAC address เหนื่อยน้อยกว่ากันเยอะ

และนั่นคือสาเหตุว่า ทำไม client จึงจะต้องแจ้ง OS หรือ Vendor class ให้กับ DHCP server ได้ทราบ มันเป็นข้อตกลงที่ดี ที่ปฏิบัติกันมาเงียบ ๆ หลังฉากตั้งนานแล้ว

แล้ว Vendor class มีอะไรบ้าง

อย่างที่ผมบอกไว้แต่ต้นแล้วว่า Client FingerPrint เป็นวิธีที่มีใช้มานานแล้ว และ Vendor class (Option 60) และ Parameter Request List (Option 55) ก็เป็น 2 ออพชั่นที่ใช้คู่กันในการประเมินว่า OS ของ Client นั้นคืออะไร ก็เป็นวิธีที่ใช้กันอย่างกว้างขวาง

จะบอกว่า Enterprise Wifi vendor ที่มีความสามารถในการแสดง OS ของ Client ก็ใช้วิธีนี้ทั้งสิ้น ก็ไม่ผิด

โลกนี้ ยี่ห้อไหน ใช้ Class ID อะไร และมี Request list เป็นอย่างไร ดูที่นี่ครับ

https://api.fingerbank.org/devices

Detect OS อะไรได้บ้าง

เป็นคำถามยอดฮิตเวลาที่เราได้ยินว่า Ruckus AP จะสามารถแสดง OS ของ Client ออกมาได้ ก็มักจะถามกันต่อว่า ถ้าเป็น PlayStation, Smart TV, IP Camera, IP phone ฯลฯ มันจะแสดง OS ออกมาเป็นอะไร

คำตอบคือ จะ Detect ได้ ปัจจัยเหล่านี้ต้องครบถ้วนครับ
       – Client ต้องเซ็ตให้เป็น DHCP client (ไม่ใช่ Fixed IP) เพราะการ Detect อาศัย Option 60 และ 55 จาก DHCP Request ของ Client
       – OS ของ client เอง จะต้องประกาศ Vendor class ออกมาใน DHCP Request ซึ่ง Vendor ของ Client device นั้น ๆ มักจะไม่พลาดเรื่องนี้
       – Vendor class นั้นจะต้องมีอยู่ในตาราง fingerprint.conf
       – ข้อสุดท้ายที่ผมไม่แน่ใจคือ โปรแกรมเมอร์ของ Ruckus ใช้ Fingerprint ตามตารางที่ผมให้ link นี้หรือไม่ (คิดว่าใช่) และโปรแกรมเมอร์ของ Ruckus ได้นำทั้งตารางใส่เข้าไปใน Firmware “เต็มทั้งตาราง” หรือไม่ เพราะจะทำให้ขนาดของเฟิร์มแวร์ใหญ่ขึ้นพอควร ในเรื่องนี้ ผมล้วงเข้าไปถึงไส้ในของ Ruckus ขนาดนั้นไม่ได้ครับ เขามักไม่บอก

AP เก่า ๆ ไม่มี Client fingerprint (หรือถ้ามี ก็ไม่ควรเปิดขึ้นมาใช้) เพราะ...

การทำ Client fingerprint เป็นภาระของ CPU ของ AP ที่จะต้องคอยหาและแกะ DHCP client request ซึ่งใน AP รุ่นเก่า ๆ อย่าง 2942 หรือ 2741 ที่เป็น 11g นั้น CPU จะเน้นไปที่ Wifi frame handling มากกว่า High level function อย่าง Client fingerprint การเปิดฟีเจอร์นี้ขึ้นมาใช้จะทำให้ AP ทำงานช้าลงจนไปกระทบกับ Data communication

ประโยชน์ของ Client finger คือ...

นอกจากจะทำให้เราเห็นภาพของ Client ได้ดีขึ้น เราสามารถเอามาใช้สร้างเป็น Access Policy สำหรับ BYOD device ได้ เช่น เราจะกำหนดว่า WLAN (SSID) นี้ หากอุปกรณ์ที่เป็น Android และ iOS ต่อเข้ามา ขอให้อยู่ใน VLAN-20 และจำกัด Bandwidth เอาไว้ที่ 10Mbps/client ในขณะที่ Windows client ขอให้เป็น VLAN-30 โดยไม่มีการจำกัด Bandwidth เป็นต้น เราเรียกอันนี้ว่า Device Access Policy

Disassociation Reason บอกอะไรกับเราบ้าง

หลายครั้งที่เราดู Log ของ AP หรือของ ZD และพบคำว่า DISASSOC reason=0

บรรทัดนี้ บอกให้เรารู้ว่า Client ได้ Disassociate ออกจาก AP ด้วยสาเหตุอะไร เป็นความผิดปกติหรือไม่

Disassociation reason code เป็นรหัสแจ้งเหตุผล ที่ใช้กันอย่างแพร่หลาย Ruckus ไม่ได้ตั้งขึ้นเอง แต่เป็นรหัสอ้างอิงที่เป็นมาตรฐาน ใช้กันทั่วโลก สามารถค้นหาได้จาก Google โดยใช้คำว่า Wifi disassociation code

ลองดูที่หน้านี้ก็ได้ครับ ครบถ้วนดีทีเดียว…

http://www.aboutcher.co.uk/2012/07/linux-wifi-deauthenticated-reason-codes/

ติดตั้ง SSL certificate ให้กับ XTM

เมื่อเราเปิดใช้ Authentication page ใน XTM เราจะได้รับคำถามจากผู้ใช้แทบจะทันที ถามว่า “จะทำให้ HTTPs warning page หายไปได้หรือไม่”

HTTPs warning ใน Browser นั้นเตือนขึ้นมาเพราะ XTM ใช้ Self signed certificate หากต้องการให้ Warning หายไป เราก็ต้องไปซื้อ “Signed certificate” มาติดตั้งให้กับ XTM ซึ่ง Certificate จะซื้อจากไหน ราคาเท่าไหร่ ลองค้นจาก google ใช้คำว่า “Buy SSL certificate”

ขั้นตอนของการยื่นคำขอ-ซื้อ-ติดตั้ง Certificate มีอยู่ 3 ขั้นตอน

       1. สั่งให้ XTM สร้างไฟล์ CSR (Certificate Signing Request) ขึ้นมาก่อน และส่งให้กับผู้ขาย Certificate หรือ CA – Certificate Authority
       2. CA ส่ง Certificate กลับมาให้เรา เราก็จะนำมาติดตั้งที่ XTM
       3. สั่งให้ XTM เลิกใช้ Self signed certificate และหันมาใช้ Certificate ที่เราติดตั้งลงไป

การสร้าง CSR

เริ่มจากตัดสินใจก่อนว่า URL ที่เราจะ Redirect user มาที่ web captive portal เพื่อ Login นั้น จะเป็น URL อะไร เช่น Domain ของเราคือ mycompany.com และเราต้องการให้ Redirect URL เป็น xtm.mycompany.com

ให้ดูที่ DNS ในระบบว่า เรามี A record บน DNS ทีจะชี้กลับมาที่ IP ของ XTM เช่น เวลาผู้ใช้ที่ยังไม่ได้ Login พิมพ์ URL ว่า www.google.com เขาจะถูก Redirect มาที่ https://xtm.mycompany.com:4100 เราจะต้องมั่นใจว่า DNS จะให้คำตอบว่า xtm.mycompany.com นั้นเป็นหมายเลข IP ของ XTM (ส่วนใหญ่จะเป็น IP ของ Trusted interface ของ XTM)

เมื่อ URL เลือกแล้ว DNS ก็จัดแล้ว ก็เริ่มสร้าง CSR โดยเปิด FSM (Firebox System Manager) และไปที่เมนู View -> Certificates… และกดปุ่ม Create Request

จุดสำคัญของการป้อนข้อมูลเพื่อสร้าง CSR ก็อยู่ที่ Domain ของ CN เพราะทาง CA เขาก็จะติดต่อกับ Mail address ของ Domain ตามที่เราป้อนเท่านั้น ดังนั้น Domain ที่จะป้อนเป็น CN ก็จะต้องมีตัวตน ติดต่อได้ ซึ่งก็มักจะเป็น Domain ของบริษัทนั่นเอง

เป็นความคิดที่ดีที่จะเว้นช่อง IP Address เอาไว้ไม่ระบุ เพื่อให้ Certificate ที่จะขอนั้น ไม่ผูกติดกับหมายเลข IP เลขใดเลขหนึ่ง ซึ่งจะทำให้ Certificate นั้นใช้ได้กับ IP ของ External interface หรือ Trusted interface ขอเพียงแต่ให้ Request URL ที่ Browser จะถูก redirect ไปนั้น เป็น xtm.mycompany.com ก็พอแล้ว

ที่แสดงเป็นข้อความที่อ่านไม่ออกนี้ ก็คือ CSR ที่เราจะส่งให้กับ CA นั่นเอง

เมื่อสร้าง CSR เรียบร้อย จะเห็นว่า มีบรรทัดใน Certificates ที่แสดงสถานะเป็น Pending นั่นคือ Request ที่ถูกสร้างออกไปแล้ว และรอการติดตั้ง Certificate

ในกรณีใด ๆ ที่เราต้องการจะสร้าง CSR ขึ้นมาใหม่ ก็ทำได้ทุกเมื่อ ทุก ๆ CSR ก็จะกลายเป็นบรรทัด Pending ขึ้นมาใหม่ บรรทัดไหนที่ไม่ใช้ (ไม่ใช่ CSR ตัวที่เราส่งให้กับ CA) เราก็ลบบรรทัดนั้นออกได้ โดยกดปุ่ม Delete

รับ Certificate จาก CA มาติดตั้งใน XTM

คุณอาจจะติดต่อซื้อ Certificate จาก Intermediate CA ดังนั้น คุณจะได้รับ Certificate มาอย่างน้อยก็ 3 ไฟล์ ได้แก่
       1. ไฟล์ Root certificate เป็น Certificate ของ CA ที่เป็นพ่อของ Intermediate
       2. ไฟล์ Intermediate certificate เป็น Certificate ของ CA ที่คุณติดต่อด้วย
       3. ไฟล์ Certificate ของ XTM

สิ่งที่คุณจะต้องทำ “อย่างเป็นขั้นตอน” คือ Import Certificate ของ Root ตามด้วย Intermediate และตามด้วย Device โดยกดปุ่ม Import Certificate จาก FSM

หลังจากที่ Import device certificate เข้าไปใน XTM แล้ว คำว่า Pending จะต้องหายไป เปลี่ยนเป็นคำว่า Signed ขึ้นมาแทน

จากจุดนี้ ถ้าเราลองเปิดเข้าไปดูที่ Web captive portal พอร์ต 4100 จะเห็นว่า Browser จะยังคงแสดง HTTPs warning อยู่ เพราะ XTM ยังไม่ได้หันมาใช้ certificate ตัวใหม่

สั่งให้ XTM เปลี่ยนมาใช้ Signed certificate

โดยใช้ Policy manager

1. เข้าไปที่เมนู Setup -> Authentication -> Authentication settings ในช่อง “Redirect traffic sent to the IP…” ให้ป้อน URL ตามที่ได้ติดตั้ง Certificate ไป

ในช่องนี้ เป็นการแจ้ง XTM ว่า ให้ Redirect browser ไปที่ URL แทนที่จะเป็นหมายเลข IP

2. ที่เมนู Setup -> Authentication -> Web server certificate ให้เลือกใช้ certificate ที่ติดตั้งเข้าไป เป็นอันว่าจบขบวนการติดตั้ง certificate ลองเข้าไปดู HTTPs (พอร์ต 4100) อีกครั้ง จะพบว่า ไม่มีคำเตือนอีกต่อไปแล้ว

ข้างต้นเป็นขั้นตอนการติดตั้ง Device certificate ในกรณีของ Wildcard certificate ซึ่งมี CSR เดียว, Private key เดียว, และ Certificate เดียว ที่จะต้องนำไปใช้หลายอุปกรณ์ภายใต้ Domain เดียวกัน

สิ่งที่ควรทราบคือ XTM เป็นอุปกรณ์ที่มีความปลอดภัยสูง ดังนั้น Fireware OS บน XTM จึงไม่เปิดโอกาสให้เราสามารถอ่าน Private key กลับออกมาจากอุปกรณ์ได้ ดังนั้น เราจึงจำเป็นจะต้องเตรียม Certificate ด้วยอุปกรณ์หรือซอฟต์แวร์อื่น ที่เปิดให้เราสามารถอ่าน Private key กลับออกมาได้ และสามารถนำ Private key นั้นไปติดตั้งต่อให้กับอุปกรณ์อื่น ๆ ได้

ยกตัวอย่างเช่น เราสร้าง CSR ด้วย Kerio Connect จากนั้น ก็ส่ง CSR เพื่อไปขอ CER เมื่อได้ CER มาแล้วก็นำมาติดตั้งใน Kerio Connect ทดสอบว่า CER นั้นใช้งานได้ถูกต้อง แล้วจึง Export Private key ออกมาตามรูปด้านล่าง

การติดตั้ง Wildcard certificate บน XTM โดยไม่มีการสร้าง CSR ก่อน เราสามารถทำได้ ด้วยขั้นตอนที่ไม่แตกต่างจากเดิมมากนัก

1. ติดตั้ง Certificate ของ Root CA และ Intermediate CA ลงไปก่อน
2. ให้ประกอบ CER และ Private key (ที่ได้มาจากอุปกรณ์อื่น) เข้าด้วยกันเป็นไฟล์เดียว ตามตัวอย่างด้านล่าง (แบบย่อ ๆ) และโหลดเข้าไปใน XTM

—–BEGIN PRIVATE KEY—–
MIIEvgIBADANBgkqhki…………………………………………………………
G9w0BAZ8DCJlecSquiWc+KSWce34+7qxvsbetIOxxqsN
3/FasE8P6woMNU+DH8ma+mU8
—–END PRIVATE KEY—–
—–BEGIN CERTIFICATE—–
MIIFDjCCA/agAwIBAgIR……………………………………………………….
wmEcrCQ0Ix4D0B/VcYApJTidvU8995EJwk7JtoLQ1nYdSR
oBM=
—–END CERTIFICATE—–

WiFi จะเสถียร ดี เร็ว อยู่ที่ Channel capacity

คำถามที่ 1 : AP ตัวที่ผมมี user ล้น 100 คน ตลอด จะมีแนวทางแก้ไขปัญหาอย่างไรดีครับ ผมปรับ Max Client เป็น 150 หรือ 200 ได้หรือไม่ครับ? แล้วประสิทธิภาพจะลดลงเยอะไหมครับ ??

ตอบ : การปรับ Max Client ให้ทำ 2 ที่นะครับคือ
       – Advance setting ของ WLAN นั้น ๆ
       – Configure -> Access Point และดูที่ setting ของ AP Group ครับ

หลายครั้งที่เรามักจะเข้าใจว่า จำนวน Client ขึ้นอยู่กับความสามารถหรือข้อจำกัดของ AP แต่ในความเป็นจริง ความสามารถของ Enterprise AP เช่น Ruckus มี Processor และ Memory เกินกว่าความสามารถของ Radio frequency เสมอ คำถามที่ถูกต้องคือ หากเพิ่ม Client เป็น 150 หรือ 200 แล้ว ความถี่ในอากาศจะมีเวลาพอในการรับส่งข้อมูลของ Client ทั้งหมดได้หรือไม่

เพราะการใช้ความถี่ ใช้ทีละเครื่องครับ คือ AP ใช้ที แล้ว Client ก็ใช้ที ผลัดกันไปคนละเวลา

WiFi packet จะอยู่ในอากาศประมาณ 20-50 micro-second ดังนั้น ใน 1 วินาที เราสามารถจะใส่ packet เข้าไปได้ไม่มากกว่า 50,000+ packet ในจำนวน 50,000 นี้ แบ่งกันใช้ทุก client ของทุก AP ของทุก network ที่ใช้ความถี่เดียวกัน แม้ว่าจะมี AP ของคนอื่นที่ติดตั้งในบริเวณเดียวกันนั้น เช่น มือถือที่ทำตัวเป็น AP หากอยู่ในความถี่เดียวกัน ก็จะแบ่งเอา 50,000 นี้ไปใช้ด้วย

การ แบ่งเวลาไปใช้งาน เป็นคนละประเด็นของการรบกวนทางความถี่ การแบ่งเวลาไม่ถือว่าเป็นการรบกวน แต่เป็นสภาพแวดล้อมของการใช้ความถี่ด้วยจำนวนเครื่องที่หนาแน่น หรือเรียกว่า High density environment

และในสภาพแวดล้อมเอง ก็มีสัญญาณอื่น ๆ ในย่านความถี่ของ WiFi ปะปนอยู่ด้วย สัญญาณเหล่านี้คือสัญญาณรบกวนที่จะรบกวน WiFi packet ได้ก็ต่อเมื่อ “สัญญาณรบกวนและ WiFi packet มีการใช้ความถี่พร้อมกันเท่านั้น” เมื่อมีการรบกวนเกิดขึ้น ก็มักจะทำให้ WiFi packet เสียหาย ต้องส่ง Packet ใหม่ ก็จะทำให้เสียเวลาของความถี่มากขึ้นไปอีก จำนวน Packet ต่อ 1 วินาทีก็จะน้อยกว่า 50,000+ packet ลงไปอีก

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

บริหารเวลา

       – เมื่อมีการส่ง WiFi packet ออกไปในอากาศ หาก Client ไม่ได้รับ ผู้ส่งจะไม่ได้รับ Acknowledgement จาก client ผู้ส่งก็จะต้องรอจนกว่าจะ Timeout แล้วก็ค่อยส่ง packet นั้นใหม่ ยิ่งพลาดมาก ก็ยิ่งเสียเวลาในความถี่ซ้ำไปซ้ำมามาก เวลานั่งรอ Timeout ก็ยิ่งมาก ทำอย่างไรให้พลาดน้อย ก็ต้องเพิ่ม SNR

เพิ่ม SNR หมายความว่า Signal ของเรามีระดับสัญญาณสูงกว่า Noise signal เมื่อปลายทางได้รับสัญญาณของเราที่ดังกว่า Noise ก็จะสามารถ Demodulate data ออกมาจากความถี่ได้สำเร็จ

การเพิ่ม SNR มักจะถูกคิดไปเฉพาะการเพิ่มเสาหรือกำลังส่ง แต่การเพิ่มเสาหรือเพิ่มกำลังส่ง จะเป็นการเพิ่มพื้นที่ครอบคลุม ยิ่งเพิ่มพื้นที่ครอบคลุม ก็จะทำให้ Channel นั้นมีโอกาสรับ Client มากขึ้น ก็ยิ่งทำให้สภาพแวดล้อมของ High density สาหัสขึ้นไปอีก

จึงจะต้องเพิ่ม SNR แต่ไม่เพิ่มพื้นที่ครอบคลุม วิธีคือทำให้ Client ใกล้ AP มากขึ้น แนวโน้มของการทำระบบ Wifi จึงเป็นการใช้ AP ตัวเล็กลง แต่จำนวน AP ในระบบมากขึ้น เพื่อครอบคลุมพื้นที่เท่าเดิม เพื่อรองรับจำนวน Client ต่อพื้นที่ที่มากขึ้นนั่นเอง ในอดีตจำนวน Client มาจากหลายคนแต่มีแค่ 1 เครื่อง มาเป็นปัจจุบันที่ 1 คนถือกันคนละ 1 เครื่อง และจะกลายเป็น 1 คนหลายเครื่องในอนาคต แปลว่าความหนาแน่นของ Wifi network ก็จะเพิ่มมากขึ้น การเพิ่ม SNR ก็ยิ่งมีความสำคัญมากขึ้น

       – ลดเวลาด้วยการทำให้แต่ละ packet นำพาจำนวนบิตได้มากขึ้น หรือเป็นการเพิ่ม PHY rate นั่นเอง การเพิ่ม PHY rate ก็มักจะหมายถึงการใช้มาตรฐานใหม่ ๆ ที่ให้ PHY rate หรือ Mbps ที่สูงขึ้น เช่น 11ac ทั้งนี้ เงื่อนไขที่จะทำให้เทคโนโลยีอย่าง 11ac ทำงานที่ PHY rate สูง ๆ ได้ ก็มักจะต้องพึ่งพา SNR ที่สูง เช่น Modulation 256QAM ของ 11ac ก็ต้องการ SNR ที่สูง เงื่อนไขเหมือนข้อแรก คือ ทำ SNR ให้สูงอย่างเหมาะสม โดยไม่เพิ่มความหนาแน่น คำตอบเดิมคือ การเพิ่มจำนวน AP เข้าไปในระบบ

บริหารพื้นที่ครอบคลุม

ต้องไม่หลุดประเด็นว่า เป็นการประเมินพื้นที่ครอบคลุมของความถี่ ไม่ใช่พื้นที่ครอบคลุมของ AP ดังนั้น ช่องสัญญาณหนึ่งบน AP 1 ตัวจะครอบคลุมพื้นที่กว้างไกลเท่าไหร่ ก็จะต้องดูว่า พื้นที่นั้นควรจะมี Client ไม่เกินกว่า 200 เครื่อง เมื่อได้พื้นที่แล้วก็หาจุดติดตั้ง AP ที่เหมาะสมซึ่งส่วนใหญ่ก็มักจะเป็นตรงกลางของพื้นที่

พื้นที่ ครอบคลุมของแต่ละ Channel บนแต่ละ AP จึงไม่ควรใหญ่เกินไป ไม่ใหญ่จนกระทั่งจำนวน Client มีมาก ก็ขึ้นอยู่กับพื้นที่ใช้งานประเภทนั้น ๆ เช่น การใช้ในห้องเรียนและโรงอาหาร ก็ใช้งานแตกต่างกัน เปิดปิดเครื่องแตกต่างกัน การ Upload/Download ก็แตกต่างกัน

บางครั้งเราพยายามจะแขวน AP บนเพดานสูงในห้องประชุมใหญ่ หากทำแบบนั้น พื้นที่ครอบคลุมของ AP ตัวนี้จะรองรับผู้ใช้ 800 คนทั้งห้องประชุมทันที เพราะทุก ๆ คนสามารถมองเห็น AP ตัวนี้แบบ Line-of-Sight ซึ่งเราอาจจะพิจารณาติดตั้ง AP ตัวเล็กรอบห้องประชุม AP (แทนจะเป็นตัวใหญ่ตรงกลาง) แต่ละตัวก็จะรองรับ Client ที่ไกลจากตัวไม่เกิน 25-30 เมตรก่อนที่ Client จะไปเจอกับ AP ตัวถัดไปและ Roaming ไปยัง AP ตัวที่ดีกว่า เป็นต้น

จากปัจจัย 2 ข้อข้างต้น ก็จะทำให้ประเมินได้ดียิ่งขึ้นว่า พื้นที่และจำนวน AP เท่าไหร่ จึงจะเหมาะสม

นอกจากนี้ การรองรับ Client เป็นจำนวนมาก ยังหมายถึงการเพิ่ม Band จาก Single band (2.4GHz) เป็น Dual band (2.4/5GHz) ก็เท่ากับเป็นการเพิ่ม Capacity อีก 1 เท่าตัว และยังรวมถึงความพยายามในการใช้ 11n หรือ 11ac ในลักษณะ Spatial streaming หลาย ๆ stream พร้อมกัน ก็ยิ่งทำให้การใช้ความถี่ใน 1 ช่วงเวลานั้น รับส่งจำนวน bit ได้มากขึ้นไปอีก สรุปคือ พยายามใช้ AP รุ่นใหม่ ๆ และไม่ยึดติดกับ AP รุ่นเดิม ๆ เช่น 11g หรือ 11n single band ก็จะช่วยให้ Wifi capacity เพิ่มขึ้นได้ ในทางกลับกัน ความพยายามที่จะใช้ AP รุ่นเก่า ๆ มารองรับ Client จำนวนมาก ก็มักจะพบกับความล้มเหลวอย่างตรงไปตรงมา

คำถามที่ 2 : ผลจากการทำ Dynamic PSK มี 2 SSID ทำให้ผู้ใช้รู้สึกว่ามันช้าลงกว่าตอนมี SSID เดียว มีวิธีแก้ปัญหาหรือไม่ครับ ???

ตอบ : การ มี 2 SSID เท่ากับการเพิ่มจำนวน Beacon packet ในอากาศให้มากขึ้น ไม่ได้เป็นข้อด้อย แต่การเปลืองเวลาในความถี่ ก็จะต้องเป็นการใช้ SSID นั้นเพื่อตอบจุดประสงค์ครับ เช่น เพื่อการแยก VLAN ระหว่าง User group ที่แตกต่างกัน แบบนี้ก็ถือว่าคุ้มค่าและเหมาะสมที่จะมี 2 SSID ครับ

ปกติ แล้ว Beacon packet สำหรับแต่ละ SSID คือ 10 beacon ต่อวินาที (Time interval = 100mS) การมี SSID เพียงแค่ 2 จะไม่ทำให้ผู้ใช้รู้สึกถึงช้าหรือเร็วครับ

แต่ผลของการมี SSID เพิ่มขึ้นมา ก็ทำให้เกิด Wifi Management Packet เพิ่มขึ้นมาด้วย เช่น
       – มี Probe request และ Probe response เพิ่มขึ้น
       – มี Association / De-association / Re-assocation เพิ่มขึ้น

ดังนั้น การมี SSID เพิ่มขึ้นมาเป็น 2 SSID นั้น ในระบบปกติ User จะไม่สามารถสังเกตเห็นความช้า/เร็วที่เปลี่ยนแปลงไปได้ แต่สำหรับระบบที่อยู่ในสภาพ High density มีโอกาสเป็นไปได้ที่ SSID ที่เพิ่มขึ้นจะมีผลต่อ User ซึ่งการ Monitor ตัวแปร (parameter) ต่าง ๆ ของ AP ตัวนั้น ๆ ผ่านทาง ZoneDirector สามารถให้คำตอบที่ชัดเจนได้ครับ

คำถามที่ 3 : เนื่องจากผมใช้ Firewall เป็นตัว DHCP จึงทำ Subnet ไว้แจกเลขได้แค่ ประมาณ 500 เครื่อง (ใช้ Class C )
แต่เลขเหล่านั้นไม่พอแจกผู้ใช้แล้วครับ ผมจึงอยากจะขยายไปใช้ Class B ซึ่งรองรับได้หลัก 1000 up
แน่นอนว่า Broadcast จะต้องมีเยอะมาก ที่ปรึกษาด้าน Firewall เป็นห่วงเรื่องการ Broadcast ในกลุ่มผู้ใช้มาก ๆ จึงแนะนำให้ทำ VLAN ซึ่งแบ่งเป็น ย่อย ๆ (ผมว่าลำบากครับ) จึงอยากปรึกษาว่า ถ้าผมเปิดแจกเลขไอพีจำนวนมาก จะมีผลจากการ Broadcast มากหรือน้อยเพียงใด ?

แล้ว ฟังก์ชัน Isolate ที่ป้องกันการ Broadcast ของ Ruckus มี หรือไม่ครับ ป้องกันได้มากน้อยเพียงใด
อยากสอบถามมาว่า Ruckus มีระบบ Isolate ที่ป้องกันการ Broadcast หรือไม่ ตั้งค่ายังไง
และใช้แล้วจะมีประสิทธิภาพในการจัดการ Broadcast หรือไม่

หรือปัญหาแบบนี้ ทาง Optimus จะแนะนำผมอย่างไรในการแก้ปัญหา IP ไม่พอครับ ??? ขอบคุณมากครับ

ตอบ : เป็นประเด็นที่คิดไปคนละทิศคนละทาง ในทาง Radio และในทาง Network

ถ้า คิดในทาง Network สมมติว่าเรามี 2 VLAN แต่ละ VLAN อยู่กันคนละ SSID ดังนั้น เรามี 2 Broadcast domain บน Network ซึ่ง Broadcast packet ของ VLAN หนึ่งจะไม่ไปรบกวนในอีก VLAN หนึ่ง

แต่คิดในทาง Radio ทั้ง 2 SSID นั้นก็อยู่บน AP ตัวเดียวกันบน Radio band เดียวกัน หมายความว่า เมื่อ VLAN-A ส่ง Broadcast ออกมาใช้ Radio แล้ว VLAN-B ก็จะส่ง Broadcast ออกมาบน Radio เดียวกันนั้นไม่ได้ เพราะ Radio band ถูกใช้งานอยู่ แตกต่างจาก VLAN บน Network ที่ทั้ง 2 VLAN สามารถจะส่ง Broadcast packet พร้อมกันได้

ดังนั้น การแยก Broadcast domain บน Network จึงไม่ได้ช่วยให้สถานการณ์ของการใช้ Radio ดีขึ้นเท่าไหร่นัก เพราะ Broadcast packet ของทุก ๆ VLAN ยังคงมาพบกันบนอากาศอยู่ดี

การลด Broadcast บน Radio domain จึงจะมุ่งประเด็นไปที่ Client isolation มากกว่า ซึ่งเป็นการลด Broadcast packet ที่ตัว Client ไม่ให้เข้าสู่ระบบ ไม่ว่า Client นั้นจะอยู่ VLAN ใด

ใน ZoneDirector จะมี “Isolate wireless client traffic from all hosts on the same VLAN/subnet”

ความหมายตามคู่มือ เขียนว่า

โดย สรุปคือ Client จะสามารถติดต่อรับส่ง ARP ที่เกี่ยวข้องกับหมายเลข IP และ MAC address ของ Gateway เท่านั้น ที่เหลือจะถูก Drop ที่ AP ทั้งหมด และไม่มีโอกาสเลยที่ ARP นั้นจะถูกส่งออกไปในอากาศ (เว้นแต่ในกรณีของ Mesh)

เมื่อเราสกัด ARP จาก Wifi client ได้ Wifi client แต่จะเครื่องจะมองไม่เห็นกันโดยสิ้นเชิง กิจกรรมต่าง ๆ ที่ก่อให้เกิด Broadcast packet ถูกลดจำนวนลงไปเป็นอย่างมาก ก็จะทำให้ Broadcast packet น้อยลง ผลก็คือ VLAN จะรองรับจำนวน Client ได้มากขึ้น เพราะความกังวลเรื่อง Broadcast flooding หมดไปแล้ว ความจำเป็นในการแยก VLAN ก็น้อยลง ก็จะสามารถเพิ่มจำนวน Host ใน Subnet โดยใช้ Subnet ที่ใหญ่ขึ้นได้

อีกฟีเจอร์หนึ่งที่จะช่วยให้แต่ละ VLAN สามารถรองรับจำนวน Client มาก ๆ ได้ คือ Rate limit ผมแนะนำให้ตั้ง Rate limit เอาไว้สำหรับแต่ละ Client ใน WLAN ไม่มากกว่า 20 Mbps ซึ่งไม่ใช่ Internet rate limit แต่เป็น Network access rate limit หมายความว่า เราจะสร้างข้อจำกัดเพื่อลดความสามารถในการโจมตีระบบของ Client เอาไว้ที่ไม่เกินกว่า 20Mbps (ทุกวันนี้ Client 11ac สามารถโจมตีระบบด้วย Throughput สูงถึง 400-500Mbps) ส่วน Internet bandwidth limit นั้นปล่อยให้เป็นหน้าที่ของ Firewall/Router ไปครับ

Rate limit setting ดูที่ Advance setting ของ WLAN ครับ

สินค้าที่เกี่ยวข้อง

สอบถามข้อมูลเพิ่มเติม สามารถติดต่อได้ที่ ติดต่อแผนก Marketing

โทร : 02-2479898 ต่อ 87 

Email : [email protected]

ต้องการอ้างอิง User จาก AD

สำหรับ Setting เรื่อง Authenticate user ให้ใช้ Policy manager นะครับ และเปิดเข้าไปที่เมนู Setup -> Authentication -> Authentication server

       – ถ้าต้องการใช้ Local user ของ XTM ก็ให้ตั้ง Username/Password จาก Tab “Firebox” ได้เลยครับ
       – ถ้าต้องการใช้ User จาก AD ให้ดูที่ Tab “Active Directory” และกด Add และป้อน้อมูลของ AD ที่ต้องการติดต่อด้วย มี 3 ช่องที่จะต้องกำหนดครับ ได้แก่
       – Domain name
       – IP address
       – Search base สมมติว่า Domain ตั้งเอาไว้เป็น company.co.th ให้ป้อน Search base เป็น DC-company,DC=co,DC=th

ในกรณีที่เราใช้ Local user ของ XTM นั้น จะถือว่า User และ Group ที่สร้างขึ้นทั้งหมด จะเป็น Authorized user โดยปริยาย คือสามารถนำ Username และ Group ไปอ้างอิงในส่วนอื่น ๆ ของ XTM ได้เลยครับ แต่สำหรับ User ที่มาจาก AD เราจะต้องกำหนดว่า User หรือ Group ใดจาก AD บ้างที่จะกำหนดให้เป็น Authorized user and group

กำหนดในเมนูนี้ครับ Setup -> Authentication -> Authorized Users/Groups จากนั้นก็กด Add
       Name: ให้ป้อนชื่อของ Group บน AD โดยจะต้องระบุตัวอักษรพิมพ์ใหญ่/พิมพ์เล็ก เหมือนกับที่ป้อนใน AD (Case sensitive)
       Type: เลือกว่า เราจะ Authorized User หรือ Group จาก AD
       Authentication server: ให้เลือก AD ตามที่เราได้ป้อนเอาไว้ใน Authentication server

เท่านี้ เราก็สามารถจะนำ User และ Group จาก AD ไปอ้างอิงในส่วนต่าง ๆ ของ XTM ในลักษณะของ Authorized user/group ได้แล้ว

ไม่รอด! แอพช้อปปิ้งออนไลน์ดังของไทยถูกแฮกแล้ว ใครใช้งานงานอยู่อ่านด่วน

มีข่าวล่ามาแรงว่า แอพช้อปปิ้งออนไลน์ชื่อดังของไทยเราโดนแฮกข้อมูลส่วนตัวของบัญชีผู้ใช้งานกว่า 13 ล้านรายการ แถมข้อมูลยังถูกเอาไปขายใน DarkWeb หรือตลาดมืดเรียบร้อยแล้ว แต่ยังไม่กำหนดราคาขาย

มาถึงตรงนี้ ออพติมุสก็ขอนำเสนอตัวช่วยดีๆ ที่ครอบคลุมการโจมตีเหล่านี้ได้ นั่นก็คือ  “WatchGuard Passport”  ซึ่งเป็น Bundle Solution Security Service ที่รวบรวมทุกๆ Solution ในด้านความปลอดภัยของ WatchGuard เอาไว้ ได้แก่

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

หรือ อีกวิธีที่ง่ายกว่านั้น ก็คือ  พยายามเปลี่ยนรหัสผ่านบ่อยๆ โดยไม่ซ้ำกัน เช่น ทุกๆ 1 เดือน หรือ 3 เดือน คุณจะต้องเข้ามาเปลี่ยนรหัสผ่าน แต่วิธีนี้ อาจจะยุ่งยากสักหน่อยสำหรับคนที่มีหลายบัญชีที่ต้องเข้าใช้งานบ่อยๆ  ข้อดีคือ คุณไม่ต้องลงทุนเพิ่ม แต่อาจจะต้องใช้ความจำเป็นเลิศในการป้องกันตัวคุณเองให้ปลอดภัยมากขึ้นนะ!

 

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

02-2479898 ต่อ 87 

Capcom hit by Ragnar Locker ransomware, 1TB allegedly stolen

capcom-street-fighter

Capcom บริษัทพัฒนาเกมสัญชาติญี่ปุ่นได้รับความเดือดร้อนจากการโจมตีของ Ragnar Locker ransomware ซึ่งผู้คุกคามอ้างว่าขโมยข้อมูลที่ละเอียดอ่อนกว่า 1TB จากเครือข่ายองค์กรของพวกเขาในสหรัฐอเมริกาญี่ปุ่นและแคนาดา

Capcom เป็นที่รู้จักกันดีในแฟรนไชส์เกมที่โด่งดัง ได้แก่ Street Fighter, Resident Evil, Devil May Cry, Monster Hunter และ Mega Man

เมื่อวานนี้ Capcom ประกาศว่าพวกเขาถูกโจมตีทางไซเบอร์เมื่อวันที่ 2 พฤศจิกายน 2020 ซึ่งนำไปสู่การหยุดบางส่วนของเครือข่ายองค์กรเพื่อป้องกันการแพร่กระจายของการโจมตี

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

นับตั้งแต่เกิดการโจมตี Capcom ได้แสดงประกาศบนไซต์เพื่อเตือนผู้เยี่ยมชมว่าอีเมลและคำขอเอกสารจะไม่ได้รับคำตอบเนื่องจากการโจมตีส่งผลกระทบต่อระบบอีเมล

Announcement

Ragnar Locker ransomware  อ้างว่าขโมยไฟล์ 1 TB

ในบันทึกค่าไถ่ที่สร้างขึ้นระหว่างการโจมตีของ Ragnar Locker ระบุว่าพวกเขาได้ขโมยไฟล์ที่ไม่ได้เข้ารหัส 1 TB จากเครือข่ายขององค์กรในญี่ปุ่นสหรัฐอเมริกาและแคนาดา

“เราได้ละเมิดขอบเขตความปลอดภัยของคุณและเข้าถึงเซิร์ฟเวอร์ทุกเครือข่ายของ บริษัท ในสำนักงานต่างๆที่ตั้งอยู่ในญี่ปุ่นสหรัฐอเมริกาแคนาดา ดังนั้นเราจึงได้ดาวน์โหลดข้อมูลส่วนบุคคลของคุณในปริมาณมากกว่า 1TB รวมถึง

– ไฟล์บัญชี, ใบแจ้งยอดธนาคาร, ไฟล์งบประมาณและรายได้ที่จัดประเภทเป็นข้อมูลลับเอกสารภาษี

– ทรัพย์สินทางปัญญาข้อมูลธุรกิจที่เป็นกรรมสิทธิ์ลูกค้าและพนักงานข้อมูลส่วนบุคคล (เช่น หนังสือเดินทางและวีซ่า), เหตุการณ์ที่เกิดขึ้น

–  ข้อตกลงและสัญญาของ บริษัท , ข้อตกลงการไม่เปิดเผยข้อมูล, ข้อตกลงที่เป็นความลับ, สรุปการขาย

– นอกจากนี้เรายังมีการสนทนาส่วนตัวขององค์กรอีเมลและการสนทนาเกี่ยวกับข้อความการนำเสนอทางการตลาดรายงานการตรวจสอบและข้อมูลที่ละเอียดอ่อนอื่น ๆ อีกมากมาย

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

นอกจากนี้ในบันทึกค่าไถ่ยังเป็นลิงก์ไปยังหน้าข้อมูลส่วนตัวที่รั่วไหลบนเว็บไซต์ของ Ragnar Locker ซึ่งมีไฟล์เก็บถาวรขนาด 24MB ที่มีเอกสารที่ถูกขโมยเพิ่มเติมรวมถึงการคาดการณ์รายได้สเปรดชีตเงินเดือน NDA แบบฟอร์มการย้ายถิ่นฐานการสื่อสารองค์กรและรายงานค่าลิขสิทธิ์

บันทึกค่าไถ่มีลิงก์ไปยังไซต์การเจรจา Ragnar Locker Tor ซึ่ง Capcom สามารถพูดคุยเกี่ยวกับความต้องการค่าไถ่กับผู้โจมตีได้ ในขณะนี้ Capcom ยังไม่ได้ใช้หน้าแชทดังนั้นจึงไม่มีข้อบ่งชี้ว่า Ragnar Locker เรียกร้องจำนวนเงินค่าไถ่

Pancak3 บอกกับ BleepingComputer ในคืนนี้ว่า Ragnar Locker อ้างว่าได้เข้ารหัสอุปกรณ์ 2,000 เครื่องบนเครือข่ายของ Capcom และเรียกร้อง bitcoins มูลค่า 11,000,000 เหรียญสหรัฐสำหรับตัวถอดรหัส

ค่าไถ่นี้ยังรวมถึงสัญญาว่าจะลบข้อมูลที่ถูกขโมยและรายงานความปลอดภัยในการเจาะเครือข่าย

Ragnar Locker ได้มีส่วนเกี่ยวข้องในการโจมตีขนาดใหญ่อื่น ๆ ในปีนี้รวมทั้งคนในโปรตุเกสข้ามชาติ Energias พลังงานยักษ์เดอโปรตุเกส (EDP) ซึ่งเป็น  ค่าไถ่ $ 10.9M ได้รับการเรียกร้อง ในเดือนกันยายนพวกเขาได้โจมตี บริษัท ขนส่งทางทะเลและโลจิสติกส์ของฝรั่งเศส CMA CGM ซึ่งทำให้เครือข่ายและการปฏิบัติการหยุดทำงานอย่างมีนัยสำคัญ

 

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

02-2479898 ต่อ 87 

Arista | Awake AI-Driven Security

องค์ประกอบ 3 อย่าง เรื่องทัศนคติของศูนย์กลางระบบรักษาความปลอดภัย (The Security Operation Center Visibility Triad – SOC) ซึ่งเป็นครอบคลุมในระบบโครงข่ายประกอบไปด้วย การสื่อสาร (communication), อุปกรณ์ปลายทาง (Endpoint), และ เหตุการณ์ต่างๆ (events) มันจะมีองค์ประกอบเรื่องของความปลอดภัย ด้งนี้

NDR

[Network Detection & Response]

เป็นการใช้ความสามารถของ ML – Machine Learning เทคโนโลยีในการเขามาควบคุมเพื่อที่จะระบุตัวผู้บุกรุก ซึ่งระบุและจำแนกลักษณะของการโจมตี ทั้งแบบตั้งใจ

SIEM/UEBA

[Security information and event management / User and entity behavior analytics]

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

EDR

[Endpoint Detection & Response]

เป็นการนำ Endpoint Agent ไปฝังที่อุปกรณ์ปลายทาง และเมื่อมีความผิดปกติจากการทำงานของ CPU, Memory, และจากการเปิด Application จะมีการรายงานและแจ้งเตือนกลับมาที่ศูนย์กลางการควบคุม

Awake

The Awake AI-Driven Security Platform​

Awake Security คือการพัฒนาหรือเพิ่มประสิทธิภาพในการตรวจจับและตอบกลับโซลูชั่น ที่สามารถส่งคำตอบ ไม่ใช่การแจ้งเตือน โดยการนำความสามารถของ AI หรือปัญญาประดิษฐ์ รวมกับความสามารถพิเศษของมนุษย์ Awake ทำงานอัตโนมัติในการออกล่าผู้โจมตีไม่ว่าจะมาจากปัจจัยภายในหรือภายนอก ขณะที่เป็นการเตรียมองค์ประกอบ 3 อย่างที่กล่าวไปข้างต้น เข้ามาช่วยเหลือไม่ว่าจะเป็น Campus network, data center, Internet of Things (IoT) / operational technology (OT) และ cloud networks

Awake AI-drive Security Platform เป็นระบบที่จะมาวิเคราะห์ในเชิงลึก ไม่ว่าจะมีเป็นล้านล้านโครงข่าย จนไปถึงระบบที่ไม่ระบุตัวตน อุปกรณ์ทุกชิ้น ผู้ใช้งานและแอพพลิเคชั่นต่างๆ ทั่วทั้งระบบโครงข่าย Awake สามารถทำงานในระบบที่ซับซ้อนได้ ไม่ว่าจะมาจากคาดคะเนจากพฤติกรรมโดยการใช้ Machine Learning และการตรวจจับสิ่งแปลกปลอกโดยการเชื่อต่อกับจุดต่างๆ เวลา โปรโตคอล และขั้นตอนการโจมตี

The Awake AI-driven Security Platform มีความแม่นยำมากกว่า 2 เท่า และสามารถลดความเสี่ยงได้เกือบ 1500% เมื่อนำไปเปรียบเที่ยบกับคู่แข่ง

ที่มาข่าว : Click!!!

สนใจผลิตภัณฑ์เรามีพันธมิตรพร้อมให้คำปรึกษา ติดต่อแผนก Marketing 

โทร : 02-2479898 ต่อ 87 

เดาไม่ยากเลย! รหัสผ่านยอดฮิตอย่าง 123456 ครองแชมป์คนใช้งานเยอะที่สุดในปี 2020

เดาไม่ยากเลย! รหัสผ่านยอดฮิตอย่าง 123456 ครองแชมป์คนใช้งานเยอะที่สุดในปี 2020 600x300

มีรายงานจาก NordPass ว่า รหัสผ่านยอดนิยมเช่น  ‘naruto’ ถูกใช้ซ้ำกันกว่า 112  และ ‘yukioh’ ถูกใช้ซ้ำกันกว่า  142 ครั้ง  แต่ก็น่าตกใจกว่านั้น คือมีรายงานว่า รหัสผ่านอย่าง  ‘123456’ มีจำนวนการถูกใช้ไปกว่า 2,543,285 ครั้ง และนอกจากนี้ ยังมีรายงานว่า มีเพียง 44% ของรหัสผ่านใหม่ๆ เท่านั้น ที่มีเอกลักษณ์เฉพาะตัว อธิบายง่ายๆ ก็คือ เป็นรหัสที่แปบกใหม่ ไม่ค่อยซ้ำใครในรายงานนี้ของระบบ NordPress จ๊ะ  และอีก 56% จะเป็นรหัสซ้ำ ๆ กัน ซึ่ง ส่วนใหญ่จะหนีไม่พ้น ‘password’ ‘12345678’ ‘111111’ และ ‘12345’ ซึ่งแน่นอนว่า เหล่านี้ติด 10 อันดับรหัสผ่านที่ผู้คนใช้ซ้ำกันมากที่สุดกันเลยทีเดียว

จากข่าวเบื้องต้น ก็คงจะหนีไม่พ้น เรื่องการออกมาเตือนภัย  (อีกแล้ว) เพราะ ช่วงนี้ เรียกได้ว่าโจรชุกชุมจริงๆ รหัสผ่านที่ว่าแน่ ยังแพ้การแปะโพสอิท  แล้วเราจะต้องตั้งรหัสผ่านให้ปลอดภัยได้อย่างไรล่ะ?  (นาทีนี้ เอาเป็น ตั้งรหัสเยอะไป ก็เสี่ยงตัวเองจะจำไม่ได้นี่แหละ) คำแนะนำแรก คือ คุณควรใช้การลงชื่อเข้าใช้งานระบบต่างๆ ด้วยระบบสองชั้น (two-factor authentication) หรือที่รู้จักกันดีว่า  2FA ซึ่งวิธีนี้ จะเป็นการเพิ่มความซับซ้อนในการเข้าระบบด้วยการยืนยันตัวตนผ่านอีเมล์หรือข้อความทาง  SMS บนโทรศัพท์ (OTP) อีกชั้นหนึ่ง  ซึ่งการใช้วิธีนี้จะทำให้พวกแฮคเกอร์ไม่สามารถแอบเข้าระบบผ่านบัญชีผู้ใช้ของคุณได้  (ยกเว้นแต่ว่าแฮคเกอร์ได้ขโมยโทรศัพท์มือถือของคุณไปด้วย)

หรือ อีกวิธีที่ง่ายกว่านั้น ก็คือ  พยายามเปลี่ยนรหัสผ่านบ่อยๆ โดยไม่ซ้ำกัน เช่น ทุกๆ 1 เดือน หรือ 3 เดือน คุณจะต้องเข้ามาเปลี่ยนรหัสผ่าน แต่วิธีนี้ อาจจะยุ่งยากสักหน่อยสำหรับคนที่มีหลายบัญชีที่ต้องเข้าใช้งานบ่อยๆ  ข้อดีคือ คุณไม่ต้องลงทุนเพิ่ม แต่อาจจะต้องใช้ความจำเป็นเลิศในการป้องกันตัวคุณเองให้ปลอดภัยมากขึ้นนะ!

แต่หากจะให้ดี เราก็ต้องมีตัวช่วยกันหน่อย ออพติมุสขอแนะนำ  “WatchGuard AuthPoint” ซึ่ง เป็นโซลูชัน Multi-factor Authentication แบบ Cloud-based ซึ่งสามารถใช้งานได้ผ่านทางแอพพลิเคชั่นบนอุปกรณ์พกพาโดยไม่จำเป็นต้องใช้  Hardware Tokens  โดยที่ผู้ใช้แต่ละคนจะใช้ AuthPoint บนอุปกรณ์พกพากี่เครื่องก็ได้ ไม่จำกัดจำนวนแอพพลิเคชั่นและอุปกรณ์ ที่สำคัญคือ AuthPoint ทำงานอยู่บน WatchGuard Cloud Platform ซึ่งเป็นระบบ Cloud ความมั่นคงปลอดภัยสูง ดูแลโดยทีมวิศวกรผู้เชี่ยวชาญของ WatchGuard ซึ่งจะคอยอัพเดทซอฟต์แวร์และแพตช์ด้านความมั่นคงปลอดภัยอยู่เสมอ แถมรองรับการใช้งานร่วมกับผลิตภัณฑ์ที่หลากหลาย เช่น อุปกรณ์บนระบบเครือข่าย, VPN, Social Media, Web & Cloud Applications รวมไปถึงแอพพลิเคชั่นอื่น ๆ ที่รองรับมาตรฐาน SAML นอกจากนี้ยังมีฟีเจอร์ Web Single Sign-on ซึ่งช่วยให้การล็อกอินผ่าน AuthPoint เพียงครั้งเดียวก็สามารถเข้าถึงแอพพลิเคชั่นและบริการได้ทั้งหมด สะดวก สบาย และปลอดภัยขนาดนี้ อย่ามัวลังเล

ขอขอบคุณ ที่มาข่าว : Most common passwords of 2020 | NordPass

 

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

02-2479898 ต่อ 87 

จะเกิดอะไรขึ้นเมื่อถึงวัน Expire ของ LiveSecurity License บน Firebox

เมื่อ License ของ WatchGuard หมดอายุ XTM จะหยุดทำงานจนกว่าลูกค้าจะต่อ License จริงหรือไม่ ? คำตอบสั้น ๆ คือ ไม่จริงครับ

คำตอบอยู่ในคู่มือของ XTM

สิ่งที่ควรทราบคือ

       1. ก่อนที่ subscription จะหมดอายุ จะมีการเตือนผ่านทางหน้าจอ config ของ XTM ว่า License จะหมดอายุแล้ว ซึ่งจะเตือนล่วงหน้า 60 วัน, 30 วัน, 15 วัน, และ 1 วันก่อนหมดอายุ นอกจากนี้ ในรุ่นที่มีหน้าจอเล็ก ๆ ที่ตัวอุปกรณ์ ก็จะมีข้อความเตือนที่หน้าจอเล็ก ๆ นี้อีกด้วย

       2. ในกรณีที่ลูกค้าต่ออายุ License หลังจากที่ License ได้หมดอายุไปแล้ว นอกเหนือจากค่า License ตามปกติแล้ว จะมีค่า Reinstatement fee เพิ่มเข้าไปด้วย หรือจะแปลว่า เป็น “ค่ากลับเข้าระบบ” ก็ได้

       3. ในกรณีที่ลูกค้าซื้อ subscription ในเวลาที่แตกต่างกัน เช่น ซื้อ XTM ไปเมื่อต้นปี พอเดือน 3 ก็มาซื้อ Gateway AV แล้วในเดือน 6 ก็ซื้อ WebBlocker เพิ่ม พอเดือน 9 ก็ซื้อ Application Control เพิ่มอีก แบบนี้ก็จะทำให้หมดอายุไม่เท่ากัน ซึ่งเป็นเรื่องยุ่งยากกับลูกค้า

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

Subscription หมดอายุแล้วเกิดอะไรขึ้นบ้าง ก็ว่ากันตามแต่ละ Subscription ไปครับ แต่โดยส่วนใหญ่คือ ฟีเจอร์นั้น ๆ จะหยุดทำงาน และหน้าจอที่เอาไว้ config ฟีเจอร์นั้น ๆ ก็จะเข้าไม่ได้ด้วย แต่ XTM ยังคงทำงานต่อไปครับ

เมื่อ Gateway AntiVirus (GA) หมดอายุ
       – Virus signature update หยุดทำงาน
       – หยุดการสแกนไวรัส และหยุดการ Block ไปด้วย
       – ทั้งนี้ ถ้า Setting ของ GA ยังคงสั่งให้สแกนต่อไป ผลที่ได้จะเป็นไปตาม Setting ของ GA ว่า ถ้าสแกนไม่สำเร็จจะให้ทำอย่างไร จะปล่อยผ่านไปหรือไม่ อย่างไรก็ดี ทุกครั้งที่สแกนไม่สำเร็จ (เพราะ Subscription หมดอายุ) ก็จะมีบันทึกอยู่ใน Log ด้วย
       – เข้าหน้า config ของ Gateway AntiVirus ไม่ได้ แต่ยังสามารถสั่ง Disable Gateway AntiVirus ได้

เมื่อ Intrusion Prevention Service (IPS) หมดอายุ
       – หยุดการอัพเดต IPS database
       – IPS หยุดการตรวจจับ และหยุดการ Block ไปด้วย
       – หน้าจอที่เอาไว้ config IPS ก็จะใช้งานไม่ได้

เมื่อ WebBlocker หมดอายุ
       – หยุดการอัพเดต WebBlocker
       – หยุดการสแกน web content
       – ใน WebBlocker setting จะมีให้กำหนด License Bypass setting ซึ่งถ้าไปกำหนดว่า Block access to all websites ก็จะมีผลทำให้ผู้ใข้ไม่สามารถเข้า website ใด ๆ ได้อีกหลังจากที่ WebBlocker ได้ expire ไปแล้ว ซึ่งวิธีแก้ ก็สั่งซื้อ Feature มาโหลดเข้าไปใหม่ ให้ WebBlocker ทำงานต่อ หรือไม่ก็ไปยกเลิก WebBlocker บน XTM ให้หยุดทำงาน
       – ไม่สามารถเข้าหน้า config ของ WebBlocker ได้ แต่ยังสามารถสั่งหยุดการทำงานของ WebBlocker ได้v

เมื่อ SpamBlocker หมดอายุ
       – หยุดการตรวจจับและ Block spam
       – ไม่สามารถเข้าหน้า config ของ SpamBlocker ได้ แต่ยังสามารถสั่งให้ SpamBlocker หยุดทำงานได้

เมื่อ Reputation Enabled Defense (RED) หมดอายุ
       – หยุดการตรวจสอบ Reputation
       – ไม่สามารถเข้าหน้า config ของ RED ได้

เมื่อ Application Control หมดอายุ
       – หยุดการอัพเดต Application signature
       – หยุดการตรวจจับ และหยุดการ Block application
       – ไม่สามารถเข้าหน้า config ของ Application control ได้

เมื่อ LiveSecurity Subscription หมดอายุ
       – ไม่สามารถอัพเกรด Fireware XTM OS หรือ Reinstall ก็ไม่ได้ แม้ว่าเวอร์ชั่นที่จะติดตั้งหรือจะอัพเกรดนั้น จะออกมาก่อน LiveSecurity จะหมดอายุก็ตาม
       – WatchGuard จะไม่ตอบสนองต่อ Phone support, web-based support, software update, และ Hardware replacement และ RMA ซึ่งตามปกติแล้ว รวมไปถึง Local partner ตามนโยบายก็จะไม่ตอบสนองด้วยเช่นกัน แต่จะ favor ลูกค้ากันอย่างไร ก็เป็นอีกเรื่องหนึ่ง แต่จะไม่ใช่การ support หรือความรับผิดชอบตามหน้าที่
       – ฟังก์ชั่นเหล่านี้ ยังคงทำงานต่อไปตามปกติ ได้แก่ XTM Pro upgrade, VPN, การเก็บ Log ต่าง ๆ, การ config device
       – ยังคงสามารถทำ Device Management ผ่านทางซอฟต์แวร์ Policy Manager หรือ Web UI ได้ตามปกติ
       – สามารถ Backup config ออกจากอุปกรณ์ได้ตามปกติ

ไล่จับ Packet ด้วย TCPdump

ในการแก้ปัญหา บางครั้งก็ดูแค่ Log ใน Traffic Monitor ของ FSM (Firebox System Manager) ก็พอจะมองภาพออกและแก้ปัญหาได้ แต่ในการแก้ปัญหาบางประเภท เราต้องการข้อมูลที่ลึกกว่านั้น

ลองคลิกขวาที่ Traffic Monitor และเลือกเมนู Diagnostic Task… และเลือกหัวข้อ Task เป็น TCP Dump ซึ่ง TCP Dump เป็นเครื่องมือที่มีใน Linux OS มานานแล้ว และใน FSM ก็มี TCP Dump ที่จะช่วยเราในการ Capture packet ที่วิ่งผ่าน Interface ต่าง ๆ

Packet ที่ Capture ได้จาก Interface จะถูกส่งมา Save เป็นไฟล์นามสกุล PCAP ที่เราสามารถจะเปิดอ่านได้ด้วยโปรแกรม Wireshark

จะป้อนอะไรในช่องนี้ดีหว่า

Parameter ที่จะป้อนในช่องนี้ คือตัวที่จะกำหนดว่า เราต้องการจะ Dump อะไรออกมาจาก Interface ไหน หรือจะเรียกว่าเป็น Filtering parameters ก็ได้

Parameter ของ TCP Dump นั้น ไม่แตกต่างไปจาก TCP Dump ที่เราใช้งานกันใน Linux OS สามารถค้นจาก Google ด้วยคำว่า “TCP Dump parameters” และอ้างอิงตามนั้นได้เลย แต่เพื่อความง่าย ผมมีตัวอย่างที่เข้าใจง่าย ๆ มาให้ดู

       – i eth3 udp port 53
       – i vlan105 tcp port 80
       – i vlan105 icmp
       – i vlan105 port http
       – i vlan105 port http or icmp
       – i vlan1 port http or icmp or smtp
       – i vlan1 src 10.0.0.166
       – i vlan1 dst 10.0.0.166 and port http
       – i vlan1 dst port http
       – i vlan1 net 10.253.0.0/16
       – i vlan1 port http and not host 10.0.0.166

แต่ละตัวอย่าง คงจะไม่ต้องอธิบายว่า มีความหมายว่าอย่างไร แต่ละบรรทัดก็อ่านได้ตรงไปตรงมา ค่อนข้างเข้าใจง่ายอยู่แล้ว ตามวิธีการของ Packet capture filtering ทั่ว ๆ ไป ยิ่งใครที่ใช้ Wireshark บ่อย ๆ จะยิ่งเข้าใจได้ทันที

อย่าลืมเลือกที่ช่อง “Stream data to file” และชี้ไปที่โฟลเดอร์ที่เราต้องการจะใช้เก็บไฟล์ PCAP ด้วยนะครับ

เปิด TCP Dump จับหลาย ๆ Interface พร้อมกันก็ได้

ในบางครั้ง เราต้องการจะเห็น Packet ขาเข้าและ Packet ขาออก เพื่อติดตามว่า การทำ Address translation ได้เกิดขึ้นตามที่ต้องการ แบบนี้เราก็จะต้องทำ TCP Dump ทั้ง Interface ขาเข้าและ Interface ขาออก ซึ่งก็ทำได้เช่นกันครับ

ไม่มีกฎเกณฑ์ข้อไหนที่ห้ามไม่ให้เราเปิด TCP Dump มากกว่า 1 ตัว อยากจะเปิดขึ้นมากี่ตัว และแต่ละตัวจะจับแต่ละ Interface ได้เป็น PCAP file มาเปิดดูเปรียบเทียบกัน ก็ทำได้เลยครับ จับทั้ง Interface ขาเข้าและ Interface ขาออก ผลิตเป็นไฟล์ PCAP หลายไฟล์ก็ทำได้เลย

TCP Dump ไม่น่าเปิดทิ้งเอาไว้นาน ๆ

TCP Dump เป็นเครื่องมือสำหรับการวิเคราะห์ในเชิงลึก ไม่ได้มีไว้สำหรับการทำ Data Logger ดังนั้น หากพยายามเปิด TCP Dump ทิ้งเอาไว้นาน ๆ เช่น หลาย ๆ นาทีหรือเป็นชั่วโมง หันมาดูอีกที จะพบว่า TCP Dump นั้นจะหยุดทำงานไปเอง ก็เป็นเรื่องที่เกิดขึ้นได้

บางครั้ง TCP Dump ก็สามารถจับ Packet ต่อเนื่องได้นานกว่า 1 ชั่วโมง บางครั้งแค่ 10 กว่านาที ก็หยุดไปซะแล้ว

เมื่อไหร่ถึงจะใช้ TCP Dump

ปัญหาบางปัญหา จะต้องวิเคราะห์ด้วยข้อมูลที่ลึกกว่า Log จาก Traffic monitor เช่น
       – เราอยากเห็น MAC address ของ IP address
       – เราอยากเห็น Packet ที่วิ่งไปมาหลังจากที่เกิด ACK แล้ว
       – เราใน Traffic Monitor เราจะได้เห็นบรรทัดของ Log เมื่อ TCP ACK ทำสำเร็จ แต่ TCP Dump จะทำให้เราได้เห็น FIN ACK ด้วย

แนะนำให้ฝึกใช้ TCP Dump ไว้ให้คล่อง จะทำให้เราแก้ปัญหาได้เร็วกว่าคนอื่น และแก้ได้อย่างตรงจุด

ใช้ RegEx ใน Traffic monitor เพื่อ Filter แสดงเฉพาะบรรทัดที่ต้องการ

เมื่อเปิดดู Traffic monitor ใน Firebox System Manager สิ่งหนึ่งที่เรามักจะต้องทำอยู่เสมอคือ การป้อนคำเพื่อใช้เป็น filter ให้แสดงผลหรือให้ highlight เฉพาะบรรทัดที่มีคำที่ต้องการ

ตามปกติ Traffic monitor จะรับคำเพียงแค่ 1 คำเท่านั้น นำไปเป็น filter หากเราต้องการจะ filter ด้วยคำที่มากกว่า 1 คำ วิธีคือเราจะต้องใช้ตัวแปรในรูปแบบ Regular Expression หรือเรียกว่า RegEx

RegEx สำหรับคนที่ทำงานพัฒนา website หรือใช้ Linux บ่อย ๆ คงจะไม่ใช่เรื่องยาก เพราะ RegEx ก็มีใช้ในงานพัฒนา website หรือ Linux command line แต่ RegEx สำหรับหลาย ๆ คน เป็นสิ่งที่ไม่คุ้นเคย และไม่ง่ายที่จะทำความเข้าใจในเวลาอันสั้น

เนื้อหาต่อไปนี้จึงเป็น Syntax ของ RegEx แบบที่ใช้บ่อย นำมาให้เป็นตัวอย่างเพื่อนำไปใช้งาน โดยไม่ต้องเสียเวลาเรียนรู้ RegEx

ก่อนอื่น Enable RegEx ใน Traffic monitor ขึ้นมาก่อน

ต้องการบรรทัดที่มี wordA และ wordB (wordA and wordB)
ให้ป้อนว่า wordA.*wordB

ต้องการบรรทัดที่มี wordA หรือ wordB (wordA or wordB)
ให้ป้อนว่า wordA|wordB

ต้องการบรรทัดที่มี wordA และ wordB หรือในบรรทัดนั้นมีคำว่า wordC คำเดียวก็ได้ ( [wordA and wordB] or wordC)
ให้ป้อนว่า wordA.*wordB|wordC

ต้องการบรรทัดที่มี wordA แต่ไม่มีคำว่า wordB (wordA and not wordB)
ให้ป้อนว่า (?!.*wordB)^.*wordA

ลองนำไปใช้ดูครับ น่าจะช่วยให้การ filter บรรทัดใน traffic monitor ทำได้ตรงจุดมากขึ้น

ใช้ Performance Console เพื่อวิเคราะห์ CPU ของ XTM

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

บทความนี้ จะสาธิตวิธีการใช้ข้อมูลจาก Performance console ของ XTM มาประกอบการวิเคราะห์ปัญหา

มักมีข้อสันนิษฐานว่า เปิดเว็บได้ช้าเพราะ CPU Utilization สูง

และเมื่อตั้งข้อสันนิษฐานอย่างนี้ ก็มักจะเริ่มการ Disable policy ต่าง ๆ เพื่อพยายามจะลดการใช้ CPU ของ XTM ทั้ง ๆ ที่ยังไม่ได้มีตัวเลขใด ๆ ยืนยันว่า CPU เป็นสาเหตุที่ทำให้เปิดเว็บได้ช้า

จะดูว่า CPU ถูกใช้ไปเท่าไหร่ ให้เปิด System Manager และดูที่เมนู Tools -> Performance console ในหัวข้อ System Information เมื่อเราเลือกที่ CPU Utilization เราสามารถจะเลือกได้ว่า จะให้ Console อ่านตัวเลขมาทุก ๆ กี่วินาที (Poll interval) และตัวเลขที่อ่านได้ จะให้เก็บเป็น CSV file ที่เราจะไปเปิดจาก Excel เพื่อ Plot เป็นกราฟต่อก็ได้

ภาพด้านล่างนี้ เป็นภาพของ Performance console และอีกภาพเป็นกราฟที่ใช้ Excel ไปอ่าน CSV มาสร้างเป็นกราฟ

แบบนี้เราก็จะรู้แล้วว่า ที่เปิดเวบได้ช้านั้น เกี่ยวกับ CPU ถูกใช้จนเต็ม 100% หรือเปล่า ซึ่งดูเหมือนว่า ผลที่ได้จะไม่เกี่ยวกัน เพราะ CPU ถูกใช้ไปแค่ 30% เท่านั้น ซึ่งเราอาจจะใช้ Performance console ไปดูต่อที่ Send/Receive ของ Interface อีกทีก็ได้

แล้วใครใช้ CPU กันบ้าง

ใน XTM มี Process มากมาย แต่สำหรับผู้ใช้อย่างเรา Setting ของเราที่จะมีผลกับ CPU ได้ ก็จะเป็นเรื่องของ Policy ดังนั้น จะเป็นประโยชน์มากหากเราสามารถจะบอกได้ว่า Policy ใดใช้ CPU ไปเท่าไหร่

แต่…Performance console ไม่ได้ให้ข้อมูลในทางตรงในลักษณะที่เราต้องการ เพราะการปฏิบัติงานตามแต่ละ Policy นั้น มาจาก Process หลาย ๆ ตัวมาประกอบกัน ดังนั้น เราจะใช้วิธีอ้อม ๆ ที่พอจะแสดงผลได้ใกล้เคียง โดยเราอาจจะใช้จำนวน connection ของ policy นั้น ๆ มาประกอบการวิเคราะห์ได้

ตัวอย่างที่จะแสดงต่อไปนี้ เป็นการใช้ Performance console เก็บข้อมูลของ policy แบบ HTTP proxy, HTTPS proxy, และ Protocol อื่น ๆ ที่ไม่ใช่ HTTP และไม่ใช่ HTTPS ซึ่งจัดการด้วย Packet filter policy วิธีคือ เราจะเก็บ Counter แต่ละตัวในรูปแบบของ CSV file และนำมาเปรียบเทียบกันใน Excel ด้วยรูปกราฟ

Counter ที่เก็บมา ได้แก่
       – Counter ของ CPU
       – Counter ของ Current connection (Raw value) ของ Policy แบบ HTTP-Proxy, HTTPS-Proxy และ Packet filter

CPU vs. All types (1)

CPU vs. All types (2)

CPU vs. All types (3)

CPU vs. All types (4)

CPU vs. All types (5)

CPU vs. All types (6)

สิ่งที่เห็นได้จากภาพที่ 1 ถึงภาพที่ 6 คือ Non-proxy session หรือ Packet filter policy นั้น ไม่ได้มีควาสอดคล้องกับการใช้ CPU เท่าไหร่เลย หรือ Packet filter policy นั้นใช้ CPU น้อยมากนั่นเอง ยิ่งในภาพที่ 6 ก็ยิ่งสวนทางเพราะ CPU เริ่มต่ำลงแล้ว ในขณะที่ Non-Proxy session ยังคงเท่าเดิม

สำหรับ HTTP Proxy และ HTTPS Proxy ดูเหมือนว่าจะมีผลกับ CPU พอสมควร แต่ในภาพที่ 1-5 นั้น HTTP และ HTTPS session เป็นเส้นขนานกัน วิ่งคู่กันไปตลอด จึงบอกได้ยากว่า ใครมีผลกับ CPU มากกว่ากัน จนมาถึงภาพที่ 6 HTTP session ยังคงระดับการใช้งานเท่าเดิม แต่เมื่อ HTTPS ลดการใช้งานลง จะเห็นว่าการใช้ CPU ก็ลดระดับตามลงมาในทันที แสดงให้เห็นว่า HTTPS proxy session มีผลต่อการใช้ CPU มากกว่า HTTP proxy session

สรุป

การวิเคราะห์ข้างต้น มาจากรุ่น XTM-525 ซึ่งได้ข้อสรุปว่า
       – HTTPS-Proxy มีการใช้ CPU สูงกว่า HTTP-Proxy
       – Packet filter policy แทบไม่มีผลต่อ CPU utilization เลย

ทั้งนี้ ก็ยังมีความจริงอื่น ๆ ที่น่าสนใจอีก เช่น กิจกรรมประเภทที่เป็น SSL อื่น ๆ อย่างเช่น VPN จะมีผลกับ CPU หรือไม่ เพราะใน XTM บางรุ่นก็มี Accelerator chip ที่เข้ามาเร่งความเร็วของ SSL activity โดยไม่เป็นภาระกับ CPU เราก็สามารถนำ Performance console มาช่วยเก็บข้อมูลในลักษณะเดียวกันกับข้างต้น และยังมี Tool ที่เป็นประโยชน์อีกมากใน System Manager ที่น่าลองเปิดใช้งานดู

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

ลองใช้ Performance console เป็นเครื่องมือในการรวบรวมข้อมูล เพื่อมาเป็นฐานของการวิเคราะห์ และนำไปสู่ข้อสรุปที่หนักแน่น และนำไปสู่ Solution แบบทำทีเดียวจบ…

ตกเก่งเหมือนแข่งเกมตกปลา เตือนผู้ใช้งาน Facebook ระวังบัญชีตัวเอง ไปเทรด Bitcoin ไม่รู้ตัว

ตกเก่งเหมือนแข่งเกมตกปลา เตือนผู้ใช้งาน Facebook ระวังบัญชีตัวเอง ไปเทรด Bitcoin ไม่รู้ตัว 600x300

ยังคงมีข่าวมาอยู่เรื่อยๆ ไม่หยุดหย่อน สำหรับข่าวการโจมตีจากผู้ไม่หวังดีที่นับวันจะมีอยู่รอบตัวเรา และเมื่อไม่กี่วันมานี้ มีรายงานว่า มีการพบกลุ่ม Hacker กลุ่มหนึ่ง ได้แสร้งทำเว็บไซต์ Phishing ขึ้นมาหลอกให้ผู้ใช้งาน Facebook  กรอก username, password แล้วเจ้าผู้ร้าย หรือ Hacker กลุ่มนี้ก็เอา credential เหล่านั้นไปโพสต์ หลอกเพื่อนๆ ที่อยู่ในบัญชีของผู้ใช้งานตัวจริง โพสต์เชิญชวนเชิงชักจูงกันไปเทรด bitcoin อีกที โดยผู้ร้ายได้เอา credential เหล่านั้นไปใส่ Elasticsearch server ซึ่งก็ไม่ได้มีการป้องกันการเข้าถึง ส่งผลให้ข้อมูลบัญชีของผู้ใช้ของ Facebook กลุ่มนั้นหลุดออกมา (โดยที่ไม่ได้หลุดมาจากทาง Facebook เองนะ อย่าไปโทษเฮียมาร์คเขาล่ะ) ซึ่งจากรายงานมีบัญชีที่ได้รับผลกระทบนี้ถึง 13.5 ล้านบัญชี (โดยประมาณ) กันเลยทีเดียว

จากรายงานก็ถือว่า โดนตกกันไปชุดใหญ่ อาจเป็นเพราะผู้ร้ายมีความเก่งขึ้น ทำเว็บไซต์หลอกลวง หรือทำ Phishing ได้แนบเนียนจนผู้ใช้งานไม่เอะใจ แต่อย่าลืมนะจ๊ะ ออพติมุสเคยนำเสนอตัวช่วยอย่าง “DNSWatchGO” ของ WatchGuard ที่จะช่วยป้องกันและปกป้องภัยคุกคามจากการล่อลวงทางอินเตอร์เน็ตแบบนี้ เพราะ “DNSWatchGO” จะทำหน้าที่กรองข้อมูลของ DNS ของเว็บไซต์ เพื่อตรวจจับและทำการบล็อกจากอันตรายต่างๆ ไม่ว่าจะเป็น URL ปลอม หรือ Virus ,Ransomware ที่แอบแฝงในเว็บ ที่ต้องการจะมาโจมตีของเรา

 

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

02-2479898 ต่อ 87 

เงื่อนไขของ Auto เงื่อนไขของ Auto Feature key synchronization

ตามปกติแล้ว หลังจากเราต่ออายุ Subscription ของ Firebox แล้ว เราจะได้ Product key มา ถ้าจะให้เข้าใจง่าย ก็คิดซะว่า Product key นั้นก็คือคูปองที่เราจะเอามาต่ออายุ Firebox นั่นเอง

คูปองนี้ไม่ได้จำกัดว่าจะต้องนำไปต่อ Subscription ของ Firebox เจาะจงตัวไหน แต่คูปองหรือ Product key นี้ ก็เป็นไปตามเงื่อนไขที่ซื้อ เช่น ซื้อ Subscription 3 ปี สำหรับ Basic security ของรุ่น M200 คูปองหรือ Product key ที่ได้รับมาจาก WatchGuard เราจะนำไปต่อ Subscription ของ Firebox M200 ตัวไหนก็ได้ ที่เป็น Basic security

สิ่งที่จะต้องทำก็คือ Logon เข้าไปที่ WatchGuard web portal ด้วย Logon account ที่เราเคยสมัครเอาไว้ และเคยใช้ account นั้นสำหรับ activate Firebox รุ่นที่เรากำลังจะต่อ Subscription และวิธีการต่อ Subscription ก็ง่ายมาก เลือกเข้าไปที่หัวข้อ Activate product และป้อน Product key (คูปอง) เข้าไป ซึ่งที่หน้า web ก็จะเลือกเฉพาะ Firebox รุ่นที่ตรงกับคูปองออกให้เราเลือกต่ออายุ เมื่อเราดำเนินการไปจนจบ สิ่งที่จะได้ก็คือ Feature key ใหม่ที่มีวันหมดอายุต่อเนื่องออกไปตาม Subscription ใหม่ เราสามารถนำ Feature key นั้นมาใส่ใน Firebox ได้เลย

อีกทางเลือกหนึ่งคือ เราใช้ Auto Feature key synchronization ของ Firebox เพื่อให้ Firebox ต่ออายุด้วยตัวเองผ่าน Cloud

แต่…ก็มีผู้ใช้เป็นจำนวนมาก ที่ได้ต่ออายุของ Fireobx ผ่านหน้า web portal แล้ว และได้ Enable Auto Feature key sync แล้ว แต่ Feature key บน Firebox กลับยังไม่มีการอัพเดตเป็น Feature key ใหม่ เพราะอะไร ???

1. ฟีเจอร์ Auto Feature key sync ที่ตั้งค่าเอาไว้ใน Firebox หรือ XTM จะ Sync Feature key กับข้อมูลบน WatchGuard web ก็ต่อเมื่อ

                  – Feature key ที่อยู่บนอุปกรณ์ ถึงวันหมดอายุแล้ว
                  – Feature key ที่อยู่บนอุปกรณ์ จะหมดอายุใน 3 วัน

       ดังนั้น กรณีที่ลูกค่าต่ออายุ subscription แล้ว แต่ Feature บนตัวอุปกรณ์ยังไม่หมดอายุ ก็จะไม่มีการอัพเดต Feature key ใหม่ลงไปที่อุปกรณ์นะครับ จนกว่าจะถึงวันหมดอายุ ฟีเจอร์ Feature key auto sync ก็จะทำงานโดยอัตโนมัติครับ

2. หากเป็นการซื้อฟีเจอร์เพิ่ม เช่น ลูกค้าใช้เป็น Security bundle แล้วซื้อ APT เพิ่ม เป็นต้น แบบนี้ลูกค้าจะต้องโหลด Feature key ใหม่ลงไปเองนะครับ เพราะ Auto Sync ทำงานตามเงื่อนไขวันหมดอายุ ไม่ได้ดูจากการเพิ่มฟีเจอร์ใหม่

3. ทำไม Auto sync ไม่อัพเดต Feature key ให้ตรงกับหน้า web ตลอดเวลา
เพราะมีโอกาสเป็นไปได้ที่ Feature key ใหม่ อาจจะด้อยกว่า Feature key เดิมที่ใช้อยู่บนอุปกรณ์ครับ
ยกตัวอย่างเช่น ลูกค้ามี Firebox ที่ทำงานโดยมีทั้ง Security Bundle และ APT
และลูกค้าก็วางแผนว่า เมื่อ Firebox นี้หมดอายุในสิ้นปีนี้ ก็จะปล่อยให้หมดอายุไป ซึ่งก็ซื้อเฉพาะ Live security เท่านั้นก็พอเพื่อให้มี Hardware warranty และ Firmware upgrade แต่ไม่ต้องการ Security subscription

ในกรณีนี้ ถ้าลูกค้าสั่งซื้อ LiveSecurity ของปีหน้ามาล่วงหน้าก่อน 2 เดือน และสั่ง activate ไป Auto sync ควรจะรู้ว่า จะต้องไม่รีบเอา Live security ของใหม่ในอนาคต ของเขียนทับ Security Bundle ที่ใช้อยู่ในปัจจุบัน ไม่งั้นแล้ว Security feature บน Firebox จะหยุดทำงานทันที เพราะ Firebox ใช้ Feature key ใหม่ที่ไม่มี Security subscription ก็เท่ากับเสียสิทธิ์ไป 2 เดือน

ด้วยเหตุนี้ Firebox จะพยายามใช้ Feature key เดิมไปเรื่อย ๆ จนกว่าจะหมดอายุขัยของ Feature key เดิม ก่อนที่จะโหลด Feature key มาอัตโนมัติ

ทั้งนี้ หากต้องการให้มีการอัพเดต Feature key ในทันที ก็จะต้องใช้วิธี Manual update ก็ใช้วิธีดั้งเดิมคือ Upload feature key ตัวใหม่ขึ้นไปที่ Firebox แบบนี้ Feature key ใหม่ก็จะเริ่มทำงานทันที

เก็บ Log ตามพรบ.ได้ 100%…จริงหรือ ?

เก็บ Log ตามพรบ.ได้ 100%…จริงหรือ

ลูกค้าที่กำลังคิดจะซื้อ Firewall ย่อมจะต้องถามผู้ขายว่า Firewall ของคุณสามารถเก็บ Log ตามพรบ.ได้ใช่ไหม ซึ่งผู้ขายมักจะตอบว่า “ทำได้ 100% จ้า” ซึ่งมักจะเป็นคำตอบที่ถูกเพียงบางส่วน

มีความจริงอยู่ 2 เรื่องที่อยู่บนหน้าจอของเราตลอดเวลา 

ความจริงที่ 1 : เรื่องของ POST และ GET

หน้า web ที่เราเห็นผ่าน Browser ก็คือ Command ที่ใช้คุยกันระหว่าง Browser และ Web server ซึ่งมีอยู่ 2 Command ที่ พรบ. ให้ความสนใจคือ คำสั่ง POST (Browser ทำการ Post ข้อมูลไปยัง Web site) และคำสั่ง GET (Browser ขอ Get ข้อมูลมาจาก Website)

เราโหลดอะไรจาก website มาแสดงบน Browser ของเรา พรบ.ต้องการให้เราเก็บว่า มีการใช้คำสั่ง GET จาก Client เครื่องนั้น ๆ และ พรบ.ก็ต้องการให้เราเก็บว่า ผู้ใช้ (Browser) มีการใช้คำสั่ง POST เพื่อส่งข้อมูลไปยัง website เช่น การโพสข้อความต่าง ๆ ไปยังกระทู้

ความจริงเรื่อง 2 : HTTPS

สังเกตว่า เวลาที่จะทำธุรกรรมกับ webiste ของธนาคาร หรือ Login เข้า Facebook ที่บรรทัด URL ของ Browser จะมีรูปกุญแจสีเขียวขึ้นมา แสดงว่า เรากำลังติดต่อกับ website ด้วย HTTPS ตัว S ก็แปลว่า มีการเข้ารหัสข้อมูล

เข้ารหัส แปลว่า Encrypte ข้อมูลก่อนส่งออกจาก Browser อุปกรณ์ตรงกลาง เช่น AP, Switch, Router, Firewall, ฯลฯ จะไม่สามารถอ่านข้อมูลเหล่านั้นได้เลย ได้แต่เพียงส่งข้อมูลให้ web server เท่านั้น คนเดียวที่มีกุญแจในการแกะข้อมูล (Decrypte) นั้นออกมาได้คือ web server

การเข้ารหัส เกิดขึ้นทั้งขาไปและขากลับ

การเข้ารหัส ไว้ใจได้มากพอที่คนเป็นจำนวนมากทั่วโลก สามารถจะส่ง Password ของ Facebook ผ่านทาง Browser เดินทางข้ามอินเตอร์เน็ต ไปถึง Facebook ได้อย่างปลอดภัย เช่นเดียวกับ website ของธนาคารทุกแห่ง

1 + 2 ทำให้คิดได้ว่า...

ยกตัวอย่างเช่น เราใช้ Browser เปิดหน้า Login ของธนาคาร เราป้อน Username และ Password เมื่อกดปุ่ม Login นั่นคือ Browser ของเราก็ผลิตคำสั่ง POST ขึ้นมาเพื่อส่ง Username และ Password ไปให้ธนาคาร

คำสั่ง POST ถูกเข้ารหัสก่อนออกจากเครื่อง ตามเงื่อนไขของ HTTPS

Firewall ไม่สามารถแกะ HTTPS ได้ ก็ไม่สามารถเก็บคำสั่ง POST นั้นได้ ก็เท่ากับผิดตาม พรบ.นั่นเอง

ยกตัวอย่างเช่น เราเปิดหน้า Facebook และเราก็ป้อนข้อความดูหมิ่นผู้อื่น ซึ่ง Facebook ก็ใช้ HTTPS แปลว่า Firewall ย่อมไม่สามารถมองเห็นคำสั่ง POST นั้นได้ จึงไม่สามารถเก็บ Log เอาไว้ได้

คำถาม-คำตอบ

ถาม: แล้วอย่างนี้ จะต้องเรียงหน้าเข้าคุกกันทั่วประเทศ ?
ตอบ: เพราะ HTTPS ออกแบบมาเพื่อต่อต้านการแกะรหัส ปกปิดข้อมูล แต่ พรบ.บังคับให้เราต้องเก็บข้อมูลในสิ่งที่ถูกเข้ารหัส สิ่งที่เจ้าของข้อมูลจงใจปกปิดไว้ด้วยการเข้ารหัส ย่อมทำได้ยากมาก กฎหมายขัดแย้งกับความจริงทางเทคโนโลยี ขัดแย้งกับคนทั้งโลก การไม่เก็บ Log จาก HTTPS ก็ถือเป็นการกระทำความผิด (ไม่ได้เก็บ Log ตาม พรบ.) ในลักษณะที่ศาลน่าจะให้ความเป็นธรรมได้

ถาม: ไม่เก็บ Log ของคำสั่ง POST หรือ GET งั้นเก็บ URI ก็ยังดี (URL บน Address bar ของ Browser)
ตอบ: เวลาที่เปิดเวบธนาคาร และเรากดที่ Link สิ่งที่เกิดเบื้องหลังคือ Browser ของเราก็จะส่ง Link นั้นไปยัง web server ผ่าน HTTPS เช่นกัน คือ แม้แต่ URI ที่เราจะเปิด Address ก็ถูกเข้ารหัสด้วยเช่นกัน

ถาม: แล้วปัจจุบัน มีอะไรที่ใช้ HTTPS ที่เราเก็บ Log ไม่ได้ และเป็นความผิดตาม พรบ.บ้าง
ตอบ: คำตอบคือ แทบจะทุกอย่าง เช่น
              – Dropbox (จัดเป็นบริการโอนแฟ้มข้อมูล)
              – E-mail ที่ติดต่อกันด้วย TLS (จัดเป็นบริการจดหมายอิเล็กทรอนิคส์)
              – Web server ทุกแห่งที่ใช้ HTTPS สำคัญ ๆ เช่น Facebook, Twitter, (จัดเป็นบริการ web)
              – Line ก็เข้ารหัสข้อมูลด้วยเช่นกัน (จัดเป็นบริการโต้ตอบกันบนเครือข่าย) และบริการเหล่านี้ ก็เริ่มหันมาเข้ารหัสกันมากขึ้น

ถาม: แล้ว Firewall ยี่ห้อที่เขาอ้างว่า เก็บข้อมูลได้ตาม พรบ. 100% หมายความว่าอย่างไร
ตอบ: เขาพูดไม่ครบ มันจะมีคำว่า “แต่….” แฝงอยู่ด้วยเสมอ ซึ่งลูกค้ามักไม่ถามต่อ แค่ได้ยินว่า 100% ก็ซื้อแล้ว บทความนี้คือการนำเบื้องหลังของคำว่า “แต่…” มาขยายให้ได้อ่านกัน

ถาม: อยากรู้ว่า Firewall ที่ใช้อยู่ หรือที่กำลังจะซื้อ เก็บตาม HTTPS ตามพรบ.ได้ หรือไม่ จะทดสอบได้อย่างไร
ตอบ: วิธีตรวจสอบว่า เก็บตาม พรบ.ได้ 100% หรือไม่ ก็แค่การทดสอบเดียวง่าย ๆ คือ เราเปิด Facebook และโพสข้อความ หรือเปิด web ของธนาคาร และ Login จากนั้น ให้ผู้ขายหรือ Admin แสดง Log ว่า Browser ของเราได้มีการส่งคำสั่ง POST ไปยังผู้ให้บริการ (Facebook หรือธนาคาร)

ถ้าไม่สามารถแสดงได้ แสดงว่า Firewall นั้นเก็บ Log ตาม พรบ.ไม่ 100%

ถ้าแสดงได้ และแสดง Password ที่คุณป้อนที่หน้า web ของธนาคารนั้นออกมาด้วย แนะนำให้ติดต่อกับ Vendor ของ Firewall นั้นโดยด่วน เพราะอันตรายมากที่ Password รั่วไหล

Log ที่ดี จะแสดงเพียงคำสั่ง POST, GET และคำสั่งอื่น ๆ เท่านั้น ไม่แสดงข้อมูล

สำหรับ WatchGuard เราสามารถแสดงคำสั่ง POST และ GET ของ HTTPS ได้ โดยจะแสดงเฉพาะคำสั่ง ส่วนข้อมูลของคำสั่ง (Password หรือ post Message) จะไม่มีการแสดงออกมา และ XTM ได้ถูกออกแบบมาให้

การถอดรหัสข้อมูลนั้น เกิดขึ้น “ภายใน Silicon chip ตัวเดียว” ไม่สามารถจะ Tab ข้อมูลที่ถูกถอดรหัสแล้ว ออกมาแงะดูข้อมูลภายในคำสั่ง POST หรือ GET ได้

ทั้งนี้ การแกะ HTTPS อาจจะทำให้การเปิดดู website บางแห่งทำไม่ได้ ตามมาตรการรักษาความปลอดภัยที่เข้มงวดของ website นั้น ๆ นอกจากนี้ การแกะ HTTPS ยังใช้ CPU เพื่อการ Encrypt/Decrypt ค่อนข้างมาก

ดังนั้น XTM ส่วนใหญ่เรามักจะไม่ได้เปิด DPI (Deep Packet Inspection) ให้กับ HTTPS ซึ่งทำให้การใช้อินเตอร์เน็ตลื่นไหลได้ดีกว่า แม้การเก็บ Log จะมีบกพร่องไปบ้างก็ตาม

หมายเหตุ
       ในหลาย ๆ คดีเกี่ยวกับอาชญากรรมทางเทคโนโลยี ทางกองปราบฯ (บก.ปอท.) ก็ได้ขอความร่วมมือจากแหล่งอื่น ๆ เช่น เจ้าของ website หรือเจ้าของ Hosting server หรือ ISP ในการรวบรวมข้อมูลผู้กระทำความผิดเพื่อมาเป็นหลักฐานประกอบการพิจารณาคดี (หลักฐานไม่ได้มาจาก Log ของ Firewall ฝั่งผู้ใช้เพียงฝ่ายเดียว) และยังไม่

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

แม้ว่าพวกเราจะเก็บ Log จาก HTTPS ได้หรือไม่ได้ก็ตาม…

Traffic Monitor บรรทัด Log เป็นสีเขียวแล้ว แต่มันไม่ไป…

Traffic monitor ใน Firebox System Manager หรือ FSM เป็นเครื่องมือหากินสำหรับคนทำ XTM ที่ใช้ในการแก้ปัญหา ติดตามการทำงานของ Policy และช่วยแสดงข้อมูลอีกหลาย ๆ อย่าง เรียกได้ว่า การตรวจจับและจัดการปัญหาใด ๆ 99.99% จะต้องมีการเปิด Traffic monitor ขึ้นมาใช้งาน

สีของบรรทัดใน Traffic monitor เป็นสิ่งแรก ๆ ที่เราสังเกตเห็นได้ และเข้าใจได้ง่ายว่า สีเขียวแปลว่า ดี ส่วนสีแดงก็แปลว่า ไม่ดี

สีแดง ไม่ได้แปลว่า "โดนบล๊อก" เสมอไป

บรรทัดสีแดง มีความหมายว่า “ผ่านไม่ได้” หรือ “ไม่รับ” ซึ่งสาเหตุที่ XTM ไม่ยอมรับ packet ที่มาถึง interface นั้น ก็เป็นไปได้หลายสาเหตุ ในบรรทัดนั้น ๆ จะมีข้อความในวงเล็กที่เป็นสีแดง ซึ่งจะบอกว่า Packet ผ่านไม่ได้ เพราะอะไร เช่น

Unhandled internal/external packet – คือ Packet นี้ไม่ตรงกับ policy ใด ๆ เลย XTM จึงไม่รู้ว่าจะต้องจัดการกับ packet ที่ได้รับมานี้อย่างไร (Unhandled) จึงทิ้งไป โดยอาจจะเป็น packet ที่เข้ามาทาง Internal interface หรือ External interface

Internal policy – คือ Packet นั้นไปขัดแย้งกับ Internal policy เช่น TCP SYN check failed เป็นต้น คือ XTM ได้รับ TCP packet ในลักษณะที่ไม่ถูกต้องตามขั้นตอนของ TCP connection แบบนี้ packet ก็จะถูก Drop เช่นกัน

ผ่านไม่ได้ เพราะถูก Block – ก็คือจะต้องมีการสร้าง Policy ขึ้นมา และในเนื้อหาของ Policy นั้นก็กำหนดให้ Drop packet แบบนี้ในวงเล็บสีแดงจะแสดงเป็นชื่อของ Policy นั้น ๆ

สีแดงจึงมีความหมายหลากหลาย แต่โดยรวมคือ ไม่มีการ Forward packet เกิดขึ้น

ทั้งนี้ การไม่ Forward packet นั้น ไม่ได้หมายความว่า Drop TCP connection นั้น ๆ ทิ้งไป ดังนั้น การ Drop packet สามารถเกิดขึ้นได้อย่างเฉพาะเจาะจง โดยไม่มีผลกระทบกับ TCP connection ก็ทำได้

สีเขียว แปลว่า ไปได้ แต่...

XTM ไม่ได้รับประกันว่า…
       – Packet นั้นจะไปถึงปลายทาง
เช่น เรา ping ไปที่ 1.2.3.4 จากเครื่องใน LAN แบบนี้ XTM จะได้รับ ICMP request จากเครื่องของเรา และ XTM ก็จะส่งต่อออกไปยัง Internet router ทาง External interface
ส่วน packet นั้นจะไปถึงปลายทางหรือไม่ หรือปลายทางมีตัวตนหรือไม่ XTM ไม่สน รู้แต่ว่าได้ Forward packet ออกไปแล้ว แบบนี้บรรทัดใน Traffic monitor ก็จะขึ้นเป็นสีเขียว

       – ปลายทางจะตอบกลับหรือไม่
เช่น เรา ping จากเครื่องใน Subnet-A ไปยังอีกเครื่องใน Subnet-B โดยมี XTM อยู่ตรงกลาง แต่เครื่องใน Subnet-B นั้นเขาเปิด Firewall เอาไว้ จึงไม่ตอบ ping กลับมา ซึ่งสำหรับ XTM แล้ว ไม่สนใจว่าจะตอบกลับหรือไม่ XTM สนใจแต่ว่า ได้ Forward ping packet ไปยังเครื่องปลายทางเรียบร้อยแล้ว Traffic monitor ก็จะแสดงออกมาเป็นสีเขียว

ผลจากการ ping ทั้ง 2 แบบข้างต้น จะได้บรรทัดใน Traffic monitor เป็นสีเขียวทั้งคู่ และผลที่ปรากฎที่เครื่อง ก็เป็น Request Timed out ทั้งคู่ เช่นกัน

ใช้ Traffic monitor อย่างตรงไปตรงมา

Traffic monitor รายงานผลเท่าที่ได้เกิดการ Forward หรือ Drop/Deny packet เท่านั้น และเป็นการแสดงผลอย่างตรงไปตรงมา มีเงื่อนไขที่ชัดเจน เราก็จะต้องใช้ Traffic monitor อย่างเข้าใจในเงื่อนไขนั้น ๆ ไม่เสริม ไม่เพิ่มความเข้าใจของเราเข้าไปเอง

Private Access โดยไม่ใช้ VPN

หลายครั้งที่เรามีกล้องวงจรปิด หรือเซิร์ฟเวอร์บางอย่างในออฟฟิศ ที่เราต้องการจะ Access จากอินเตอร์เน็ต หรืออย่างน้อยเราก็อยากจะ Config XTM จากอินเตอร์เน็ต ซึ่งวิธีที่ทุกคนคิดออกก็คือ การทำ Port forwarding

และผลก็คือ คุณลองสแกนกลุ่มของหมายเลข IP บนอินเตอร์เน็ต ก็จะได้พบกับ IP จำนวนไม่น้อย ที่มีการเปิดพอร์ต 8080 หรือพอร์ต 80 หรือพอร์ตอื่น ๆ ทิ้งเอาไว้ พร้อมกับหน้า Login ที่สามารถจะใช้ลองป้อน Username/Password ได้ และบางครั้ง เราก็ลองป้อน Default username/password ของอุปกรณ์นั้น ๆ ก็สามารถเข้าไปดูข้อมูลภายในได้ นอกจากนี้ อุปกรณ์หลายตัวก็ไม่มีกลไกในการป้องกันตัวเองจาก Brute force attack หรือ Dictionary attack หมายความว่า ผู้บุกรุกสามารถเดา password ไปได้เรื่อย ๆ จนกว่าจะหมดความ
พยายามไป

เราคงไม่อยากให้ IP ของเราถูกเปิดให้ใครต่อใครลองป้อน Password อยู่ทุกวัน

หมายเหตุ: การเข้าไปดูข้อมูลของผู้อื่น ซึ่งผู้อื่นได้ทำการป้องกันเอาไว้

มีความผิดตาม พรบ.อาชญากรรมคอมพิวเตอร์

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

From: External, To: Firewall, Service: WG-Auth (TCP-4100)

เมื่อสร้าง Policy แล้ว ลองเปิดเข้ามาดูที่ https://<XTM WAN IP>:4100 ก็จะได้หน้า Login

ใน Policy Manager ที่เมนู Setup -> Autnentication -> Authentication Servers ดูที่ Firebox tab ลองสร้าง Username ขึ้นมา สมมติว่าเป็น user1

ที่หน้าจอ login ให้ป้อน user1 เพื่อ login

เปิด Firebox System Manager และดูที่ Authentication List จะเห็นว่า Username ที่ป้อน (user1) สามารถใช้อ้างอิงหมายเลข IP ได้แล้ว (ตัวอย่างในภาพ ที่ IP Address เป็น Local IP เนื่องจากการทดสอบนี้ ทำใน LAN หากเป็นการทดสอบบนอินเตอร์เน็ต หมายเลข IP ในตารางก็จะเป็น Internet IP)

กุญแจสำคัญอยู่ที่ Username นี่เอง กล่าวคือ ก่อนหน้านี้เวลาเราจะทำ Port forward เราก็จะทำกับ External interface แต่เมื่อมีการ Login เกิดขึ้น เราก็จะทำ Port forward โดยมี Source เป็น Username แทนที่จะเป็น Internet IP หรือ External interface

จากนั้น เราก็มาสร้าง Policy ให้เกิด Port forwarding สมมติว่า เรามีเซิร์ฟเวอร์เป็น TCP-8080 อยู่ในระบบ LAN ที่หมายเลข IP 10.0.1.3 Policy ที่ได้ จะมีหน้าตาเป็นแบบนี้

หมายความว่า ในโลกนี้ ก็จะมีแต่หมายเลข IP ที่ Login ด้วย user1 เท่านั้น ที่จะเปิดดู service TCP-8888 ได้ ไม่จำเป็นจะต้องใช้ VPN แต่ก็สามารถสร้างความปลอดภัยให้กับการ Access service จาก Internet ได้ และที่สำคัญคือ ความสะดวกที่ได้มาจากการไม่ต้อง Install VPN client หรือ Setup VPN client เราจะเปิดดู Service จากเครื่องไหนก็ได้จากอินเตอร์เน็ต

วิธีการนี้ ให้ข้อคิดอีกหลายข้อ เช่น

       – หลายครั้งที่เราอยากจะเปิดให้สามารถ config XTM ผ่านทางอินเตอร์เน็ตได้ ก็สามารถใช้วิธีนี้เพื่อจำกัดคนที่เข้าถึง Management interface ของ XTM ได้

       – วิธีนี้ นอกจากจะจำกัดการเข้าถึง Service จากทาง External แล้ว ยังสามารถประยุกต์วิธีนี้เพื่อจำกัดคนที่เข้าถึงเซิร์ฟเวอร์จากทาง DMZ ได้ด้วย

       – หากเรา Login เข้า XTM มาจากอินเตอร์เน็ต โดยที่เราอยู่ใน LAN ที่มีการทำ NAT ย่อมหมายความว่า เครื่องทุกเครื่องที่อยู่ใน LAN เดียวกับเรา ก็จะสามารถเข้าถึง Service นี้ได้เช่นกัน

       – เราสามารถประยุกต์เอา Property ของ User มาใช้งานได้อีกด้วย เช่น

                1.) Session timeout เพื่อบังคับให้ Login ที่เข้ามานั้น ถูกตัดทิ้งเมื่อครบเวลา
                2.) Idle timeout ที่ทำให้เราไม่ต้องเสียเวลา Logout เพียงแต่ทิ้งเอาไว้จนถึงเวลา Idle timeout ก็จะถูกตัดไปเอง
                3.) Limit concurrent session ที่ใช้จำกัดไม่ให้ Username ถูกใช้โดยหลาย ๆ คนพร้อม ๆ กัน

       – พอร์ตที่ XTM ใช้เองกับ External interface เช่น TCP-443 หรือ TCP-8080 เราจะต้องเลี่ยงไม่ทำ
Forwarding กับพอร์ตที่ XTM ใช้อยู่ หรือไม่งั้นก็จะต้องเข้าไปเปลี่ยนใน XTM ไม่ให้พอร์ตต่าง ๆ เหล่านี้

ลองนำวิธีนี้ไปประยุกต์ใช้ให้เกิดความปลอดภัยใน Remote access ครับ

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 

Author picture

จุดประกายโดย : 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 ตามออกมาเรื่อย ๆ