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 ครับ

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

  • Prospace DIAG WiFi

    DIAG WiFi บริการตรวจเช็คคุณภาพงาน IT (WiFi Assessment)

    DIAG WiFi, Prospace, Wireless

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

โทร : 02-2479898 ต่อ 87 

เรียบเรียงเป็นภาษาไทยโดย : คุณ วุฒิ กิ่งหิรัญวัฒนา

ต้องการอ้างอิง 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 ได้แล้ว

จะเกิดอะไรขึ้นเมื่อถึงวัน 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 แบบทำทีเดียวจบ…

เงื่อนไขของ 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 ครับ