ความแตกต่างการการใช้งาน filter ในการมองหาปัญหาที่อาจจะเกิดขึ้น

ซินจ่าวววววววว 😉

อาทิตย์นี้มาทำงานที่เวียดนามครับ ขอสลับโหมดจากงานมาเขียน Blog สักหน่อยแก้ปวดหัว ^^”

จากใน Facebook page ครั้งก่อนมีการเกริ่นว่าจะแนะนำข้อแตกต่างของการใช้งาน Command filter สองตัวคือ tcp.port และ telnet ซึ่ง Telnet ก็เป็น Application ตัวหนึ่งซึ่งใช้ Protocol TCP ในการสื่อสาร และเมื่อใช้ Command ตัวอย่างไปแล้วก็ได้ผลลัพธ์ออกมาคล้ายกันมากทีเดียว แล้วการใช้งาน Command ในรูปแบบไหนจะดีกว่ากัน วันนี้เราจะมาอธิบายกันในหัวข้อวันนี้ครับ

ก่อนจะไปไกลที่ Application เรามาเริ่มที่ Protocol กันก่อน โดยส่วนตัวแล้วคิดว่าใครก็ตามที่ได้เรียนด้าน Computer มาก็จะรู้จักคำว่า TCP handchecking กันมาบ้างแน่นอน (ผมเพิ่งมารู้จักตอนทำงานนี่ล่ะ ข้อเสียของการจบไม่ตรงสาย ^^”) โดยทั่วไปแล้วจะมีการกล่าวถึง TCP handchecking กันอยู่ 2 packet คือ

1. Sync
2. Sync/Ack
3. Ack

ตามที่เรียนมาทั้ง 3 packet นั้นก็จะอยู่ในรูปด้านบนในส่วนของ Open connaction ที่เขียนด้วยตัวอักษรสีม่วงด้านซ้ายมือ เมื่อสามารถ Open connection ได้แล้วตัว Application ก็จะเริ่มเข้าสู่การสื่อสาร โดยจะเริ่มส่งข้อมูลกันในลำดับถัดไปนั่นเอง และเมื่อได้ข้อมูลครบแล้ว เมื่อเลิกใช้งานก็จะมีการปิดการสื่อสารตรงส่วนนี้เองก็จะเกิด Close connection ในส่วนของตัวหลังสือสีแดงด้านซ้ายมือในรูป เป็นอันจบเรื่องของ TCP แบบคร่าวๆครับ

คราวนี้ลองมาดูใน Wireshark กันดีกว่า ในตัวอย่างนี้เอามาจากใน Lab ที่สอนในห้องเรียนมาเพื่อที่จะได้ประหยัดเวลา ตัวอย่างที่ใช้เป็นการ Telnet เข้าไปที่ Cisco router ตัวหนึ่งซึ่งเราใช้ EVE-NG จำลองขึ้นมาตามในรูปด้านล่างนี้ แล้วก็เปิด Terminal ขึ้นมาเพื่อ Telnet เข้าสู่ Virtual router ตัวนี้ และก็ได้เก็บ Packet ตัวอย่างออกมาครับ

คราวนี้เรามาลองใช้งาน Command filter กันเลยเริ่มต้นด้วย “telnet” ที่เป็นชื่อของ Application ที่เราใช้ลงในช่อง Filter expression ตามในรูปด้านล่างนี้ สิ่งที่ Wireshark แสดงผลออกมาให้คือ

จากผลที่ได้จะเห็นว่า Packet แรกที่ได้เป็น Data ที่ถูกส่งมาเป็น Packet แรกถูกส่งออกมาจากฝั่ง Server และหลังจากนั้นจะเป็น Packet ที่มีการรับส่งระหว่างกันไปเรื่อยๆ ตราบเท่าที่มีการร้องขอ Data

ต่อมาก็ลองใช้ Filter command ใหม่อีกตัวหนึ่ง “tcp.port==23” การใช้ Command นี้ก็มาจากพื้นฐานของ Application Telnet ใช้ Protocol TCP และใช้ Port หมายเลข 23 ดังนั้นจึงเป็นที่มาของ Command filter นี้

จากผลที่ได้จะเห็นว่า Packet แรกที่ได้เป็น TCP handcheck แล้ว และเป็นการเปิด Connection มาจาก Client ตามที่ได้เรียนมาตามทฤษฎีเป๊ะเลย

มาต่อกันที่ว่าไอ้แบบที่ใช้ Command filer “telnet” กับ “tcp.port==23” จะเอามาใช้ในกรณีไหนบ้าง

1. ใช้ Command “telnet” ก็ต่อเมื่อไม่ได้มีปัญหาในการเชื่อมต่อ และต้องการดูเฉพาะข้อมูลที่อยู่ข้างใน หัวข้อนี้เดี๋ยวมาต่อในบทความหน้านะครับ ^^
2. ใช้ Command “tcp.port==23” ข้อดีจากที่เห็นจากตัวอย่างคือ การที่เราเห็นขั้นตอนตั้งแต่การเปิด TCP connection แบบ TCP handcheck ดังนั้น การใช้งาน Command นี้จะใช้ในกรณีที่การเชื่อต่อมีปัญหา ดังนั้นเมื่อเราไม่สามารถใช้งาน Application ได้ เราก็จะต้องมาให้ความสนใจกับการเปิด TCP connection นั่นเองครับ

สำหรับบทความนี้ก็ขอจบไว้เท่านี้ครับ

ตัวอย่างการใช้งาน Filter เพื่อหาข้อมูล Protocol ที่ต้องการ

บทความแรกของปี 2019 หลังจากหายไปเกือบ 2 ปี!!!

เป็นตัวอย่างการใช้งาน Filter ใน Wireshark เพื่อให้เราสามารถเลือกเฉพาะ Protocol ที่เราสนใจมาแสดงผลได้อย่างเหมาะสมต่อไป ทำไมเราต้องใช้ Filter? คำตอบคือ Packet มีเป็นล้านแล้วคุณจะหาข้อมูลที่คุณต้องการได้ยังไงถ้าไม่ใช้มัน!!!

จากการที่เราหายไปเป็นปีๆ เรามีตัวอย่างจาก Diagram ด้านล่างนี้เราเอามาทำเป็น Lab เล็กๆใน EVE-NG สักหน่อย สังเกตุว่าในรูปจะมี Client แค่ตัวเดียว แต่ในงานจริงอาจจะมีได้เป็นแสนหรือล้าน Client นะครับ

พอลองจับ Packet ที่ Gatewat ที่รับข้อมูลเข้ามาจาก Access ในเวลาไม่เกิน 5 นาทีจากรูปด้านล่างนี้เราจะได้ Packet มาทั้งหมด 3,967 Packet ถ้าเราต้องการการการเปิด PPPoE discovery session จาก Client โดยไม่ใช้การ Filter เลยเราก็อาจจะเสียเวลาไปอาจจะหลายชั่วโมงเลยทีเดียว

คราวนี้ลองมาใส่ Filter กันดูบ้างว่าจะได้ผลเป็นยังไงบ้าง

จากตัวอย่างเรารู้ว่าเราต้องการหาการเปิด PPPoE discovery session จาก Client เราก็ลองใส่ Filter ลงไปเลยในช่องของ Expression ถ้าเราใส่ Filter ถูกต้องสีของช่อง Expression ก็จะเป็นสีเขียวแล้วเราก็จะได้ PPPoE discovery ออกมาแล้ว

สำหรับ Packet ของ PPPoE discovery จะมีอยู่ 5 ตัวย่อยคือ PADI, PADO,PADR, PADS กรณีปิด session เราจะเจอ PADT เป็นตัวสุดท้ายนะครับ

เช่นกันในฝั่งของ RADIUS เราก็จะลองใช้ Filter เข้ามาช่วยดูกันด้วยจากจากใน Lab ที่เตรียมมาจะได้ผลแบบนี้

สุดท้ายเราก็มาดูตัวอย่างจากข้อมูลที่ได้จาก Message ของ RADIUS access-accept กันดู

จากตัวอย่างนี้จะเห็นข้อมูลใน Message access-accept ที่มาจาก RADIUS server กันแล้ว คำถามคือแล้วยังไงต่อล่ะครับ??

แน่นอนพอเราเห็นข้อมูลได้แบบนี้แล้วเราก็จะสามารถคาดเดาการทำงานได้ประมาณนี้

1. เนื่องจากเป็น Message access-accept ดังนั้น กรณีนี้จึงเป็นการใช้ที่เป็นไปตามปกติ
2. แต่ถ้าเป็น Message access-reject แสดงว่าอาจจะเกิดจากสาเหตุ ต่างๆได้อีกดังนี้
   • ใส่ Username หรือ Password ผิด
   • Session ที่ใช้งานเต็ม

ซึ่งจะต้องเอาข้อมูลที่ได้จาก Message เหล่านี้มาลองวิเคราะห์ปัญหาที่เกิดขึ้นต่อไปนั่นเอง อย่างกรณีของ RADIUS อาจจะให้ส่ง Message เพิ่มเติมในความผิดปกติเกี่ยวกับการ Login แบบนี้ได้ด้วย เช่น การส่งค่า Redirect page หรือส่งค่า IP address แบบเฉพาะเจาะจงให้ User เข้าไปอยู่ใน Screen zone ทำให้ไม่สามารถใช้งานได้เป็นต้นครับ