Skip to content

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