วันนี้ขอนำเสนอการใช้งาน Wireshark เพื่อนำมาใช้สร้าง Firewall Rules กันแบบง่ายๆกันครับ
โดยทั่วไปแล้วคนที่ทำงานด้าน Network จะไม่ค่อยถูกโรคกับการทำงานด้าน Security มากนัก ในบางครั้งการสร้าง Access Control List (ACL) หรือจะให้สร้าง Firewall Rule บน Firewall ขึ้นมาเอง ซึ่งจะต้องคิดทั้ง IP ต้นทางปลายทาง Protocol และ Port ต่างๆ จะเห็นได้ว่าค่าที่เกี่ยวข้องก็จะเยอะพอสมควร ซึ่งคนที่ทำงานด้าน Network เองก็อาจจะมีงงๆกันบ้าง ไหนจะเป็นรูปแบบการใส่คำสั่งบนอุปกรณ์ยี่ห้อต่างๆที่ไม่เหมือนกันอีก แบบนี้ก็ทำให้เกิดความงุนงงสับสนได้ง่ายๆ ^^”
ดังนั้นแนวทางการแก้ปัญหาของคนที่ไม่เก่งก็คือการใช้เครื่องมือมาช่วยครับ และแน่นอนเพจเราตอนนี้กะลังเขียนเรื่อง Wireshark อยู่เรามาใช้ Wireshark ในการช่วยในการสร้าง ACL หรือ Firewall Rule กันครับ
หมายเหตุ: Packet ตัวอย่างผมใช้งาน Internet ตามปกติ ดังนั้นทุกคนก็สามารถลองทำตามเองได้ บทความนี้เน้นให้ idea และให้รู้จักการใช้เมนูของ Wireshark เท่านั้น การใช้งานจริงจะต้องมีการเก็บ Packet ที่ต้องการจากหน้างานจริงนะครับ
แนวคิดในการสร้าง Firewall Rule จะต้องมี IP ต้นทางปลายทาง Protocol และ Port ตามที่บอกไว้ก่อนหน้านี้แล้ว จากใน Packet ตัวอย่างที่มีรอบสีแดงจะเห็นว่า Wireshark มีข้อมูลตามที่บอกไว้แล้ว ที่นี้ก็ง่ายแล้วครับ
กรณีสมุมติ ถ้าเรามองว่า Packet ที่มากจาก IP address 61.90.189.208 มีการส่งข้อมูลที่ผิดปกติเข้ามาที่เครื่อง Client IP address 192.168.43.197 โดยใช้ UDP Port 60674 ถ้าเราต้องการสร้าง Firewall Rule เพื่อ Drop packet จาก Source 61.90.189.208 เราจะสร้าง Firewall Rule โดยใช้ IPFilter โดยใช้งานคำสั่งอะไรบ้าง???
กรณี่ถ้าต้องการสร้าง IPFilter Rule อันนี้ผมเองก็ไม่รอดแน่นอนเพราะ ใช้ IPFilter ไม่เป็นครับ!!!
แต่เรามี Wireshark แล้ว และเราก็เจอ Packet ที่เราคิดแล้วว่าจะ Drop packet นั้นมาแล้วขั้นตอนต่อไปก็ไปที่เมนูนี้ครับ
Tools -> Firewall ACL Rules ตามรูปด้านบนครับ แค่ชื่อเมนูก็ยิ้มแล้วครับ เรามาถูกทางแล้ววววว
ลองมาดู Output ที่ได้มาจากเมนูนี้กันครับ
ได้คำสั่งของ IPFilter ที่จะใช้ Drop packet ที่เราเลือกมาแล้วง่ายแค่คลิก ต่อมาลองมาเลือกที่ Create rules for กันครับ
ฮั่นแน่!! มี Cisco IOS ด้วยมีทั้ง Cisco IOS standard และ extended เลยลองเลือกแบบ extended มาดูกันครับ
แค่นี้ก็ได้ Cisco extended ACL มาแล้วแค่นี้ก็ Copy มาใช้งานต่อได้แล้ว และที่สำคัญคือเราก็เอา Template นี้ที่ได้มาปรับค่า parameter ต่างๆต่อไปได้อีก เช่น เปลี่ยน IP address หรือ port ต่างๆ
สรุปแนวคิดที่ได้จากบทความนี้คืออะไร
หวังว่าบทความนี้น่าจะเป็นประโยชน์กับเพื่อนๆบ้างนะครับ เจอกันใหม่บทความหน้าครับ ^^
ซินจ่าวววววววว 😉
อาทิตย์นี้มาทำงานที่เวียดนามครับ ขอสลับโหมดจากงานมาเขียน Blog สักหน่อยแก้ปวดหัว ^^”
จากใน Facebook page ครั้งก่อนมีการเกริ่นว่าจะแนะนำข้อแตกต่างของการใช้งาน Command filter สองตัวคือ tcp.port และ telnet ซึ่ง Telnet ก็เป็น Application ตัวหนึ่งซึ่งใช้ Protocol TCP ในการสื่อสาร และเมื่อใช้ Command ตัวอย่างไปแล้วก็ได้ผลลัพธ์ออกมาคล้ายกันมากทีเดียว แล้วการใช้งาน Command ในรูปแบบไหนจะดีกว่ากัน วันนี้เราจะมาอธิบายกันในหัวข้อวันนี้ครับ
ก่อนจะไปไกลที่ Application เรามาเริ่มที่ Protocol กันก่อน โดยส่วนตัวแล้วคิดว่าใครก็ตามที่ได้เรียนด้าน Computer มาก็จะรู้จักคำว่า TCP handchecking กันมาบ้างแน่นอน (ผมเพิ่งมารู้จักตอนทำงานนี่ล่ะ ข้อเสียของการจบไม่ตรงสาย ^^”) โดยทั่วไปแล้วจะมีการกล่าวถึง TCP handchecking กันอยู่ 2 packet คือ
ตามที่เรียนมาทั้ง 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” จะเอามาใช้ในกรณีไหนบ้าง
สำหรับบทความนี้ก็ขอจบไว้เท่านี้ครับ
บทความแรกของปี 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 กันแล้ว คำถามคือแล้วยังไงต่อล่ะครับ??
แน่นอนพอเราเห็นข้อมูลได้แบบนี้แล้วเราก็จะสามารถคาดเดาการทำงานได้ประมาณนี้
ซึ่งจะต้องเอาข้อมูลที่ได้จาก Message เหล่านี้มาลองวิเคราะห์ปัญหาที่เกิดขึ้นต่อไปนั่นเอง อย่างกรณีของ RADIUS อาจจะให้ส่ง Message เพิ่มเติมในความผิดปกติเกี่ยวกับการ Login แบบนี้ได้ด้วย เช่น การส่งค่า Redirect page หรือส่งค่า IP address แบบเฉพาะเจาะจงให้ User เข้าไปอยู่ใน Screen zone ทำให้ไม่สามารถใช้งานได้เป็นต้นครับ
อันนี้เป็นหัวข้อสั้นๆและจะยังไม่ลงเนื้อหาทางเทคนิคนะครับ โดยบทความนี้จะต่อจากบทความที่แล้วในเรื่อง มาทลายกำแพงของ Wireshark เพื่อนำไปใช้งานกันเถอะ ในหัวข้อนี้เป็นการยกตัวอย่างการนำโปรแกรม Wireshark ไปใช้ในส่วนของการดูภาพรวมที่เกิดขึ้นในระบบ Network กันดีกว่าครับ
คำถามที่เกิดขึ้นเลยคำถามแรกคือจะเอามาดูภาพรวมทำไมในเมื่อโปรแกรม Wireshark สามารถดูข้อมูลได้ล฿กได้ถึงข้อมูลในระดับ Bit ของ Protocol อย่างเช่น DSCP หรือ Reset flag ใน TCP header!!! ทำไมไม่เอาความสามารถของโปรแกรมที่มีอยู่มาใช้ให้ถูกต้อง!!!
ลองมาดูการแสดงผลของ Wireshark ที่แสดง TCP reset bit กันก่อนว่ามีหน้าตาเป็นยังไงกันตามรูปนี้เลยครับ
คำถามนี้เราจะไม่ตอบเพราะเราจะถามกลับไปว่าถ้าไม่ดูสรุปในภาพรวมก่อนแล้วเราจะมีจุดเริ่มต้นให้เรานำไปใช้ในการหาข้อมูลที่อยู่ในส่วนที่ลึกลงไปได้อย่างไรเพราะตัวโปรแกรม Wireshark เองสามารถแสดงผลได้ถึงระดับ Bit แต่ว่าการที่เราจะไปเริ่มหาข้อมูลในระดับ Bit จากข้อมูลที่แสดงผลของแต่ละ Packet ในช่วงเวลา 15 นาทีซึ่งมีอยู่เป็นหลัก 1,000,000 บรรทัดแล้วพิจารณาความสัมพันธ์ต่างๆที่เกิดขึ้นและทำให้เกิดผลคือปัญหาที่เกิดขึ้นในช่วงเวลาหนึ่งๆคงจะไม่สามารถทำงานได้ทันตามเวลาอย่างแน่นอน!!!
ลองดูตัวอย่าง Packet ที่เคยเอามาเขียนบทความดูครับว่าเราใช้จำนวน Packet เป็นจำนวนเท่าไรในการเอาข้อมูลนั้นๆมาหาความสัมพันธ์และสาเหตุของปัญหาที่เกิดขึ้นกัน
ดังนั้นจะดีกว่าหรือไม่ที่เราสามารถที่จะเอาโปรแกรม Wireshark มาใช้ในการแสดงภาพรวมของ Packet ที่เรามีอยู่มาแสดงผลก่อนที่จะลงมือค้นหาสาเหตุที่อยู่ในระดับที่ลึกลงไปอีกทีหนึ่ง อย่าลืมว่า Packet ที่เรานำมาเปิดด้วยโปรแกรม Wireshark นั้นอาจจะไม่ใช่ Packet ที่มีปัญหาอยู่ด้วยก็ได้ ลองนึกย้อนกลับไปในส่วนของการทำงานจริงดูว่าปัญหาจะเกิดขึ้นได้ในช่วงเวลาได้ได้บ้าง ตำตอบคือไม่รู้!!! เพราะถ้าเรารู้แล้วเราก็จะสามารถหาทางแก้ไขได้อย่างแน่นอน แต่ในชีวิตจริงเราไม่สามารถรู้ได้เลยว่าปัญหาจะเกิดขึ้นได้ในช่วงไหน ดังนั้นการจับ Packet ก็อาจจะต้องทำทิ้งไว้เป็นเวลาหลายชั่วโมง หรืออาจจะเป็นวันเลยก็ตาม เพื่อให้ครอบคลุมในช่วงเวลาที่มีปัญหาเกิดขึ้น ซึ่งอาจจะเกิดขึ้นแค่เพียง 1 หรือ 2 นาทีในเวลา 24 ชั่วโมง (เราจะไม่จับ Packet ค้างไว้ทั้งวันเพราะเราจะไม่สามารถเปิดไฟล์ที่มีขนาดใหญ่เกินไปได้ ให้ลองนึกถึงการเปิด .txt ที่มีขนาด 1GB ดูครับ) ดังนั้นการไล่เปิดไฟล์และค้นหาเหตุการณ์ต่างๆจะเสียเวลามากไปถ้าใช้การพิจารณาในระดับที่ละเอียดมากเกินไปนั่นเอง (ยังไม่นับกรณีที่ปัญหาเกิดในช่วงเวลาที่คาบเกี่ยวกันในระหว่างที่เราแยกไฟล์เป็นชิ้นตามช่วงเวลาและต้องนำไฟล์มารวมกันเป็นก้อนใหม่เพื่อวิเคราะห์ปัญหาอีกต่างหาก ผมเคยต้องเอาไฟล์มารวมกันจนได้ขนาด 16GB และเอามาหาความผิดปกติ T^T)
ส่วนนี้จะเป็นตัวอย่างการใช้งานจริงในส่วนของการนำเอา Wireshark มาใช้ในการดูภาพรวมของปัญหากันครับ
ตัวอย่าง เบื้องต้นเราต้องการทราบว่าโมเด็มที่เราใช้งานอยู่มีอาการ Disconnect ในทุกวันเราก็นำโมเด็มนั้นมาทดสอบใน Lab และกำหนดค่า Timeout ให้เป็น 15 นาทีเพื่อดูปัญหาที่เกิดขึ้นในระยะเวลาที่จำกัด หลังจากการทดสอบและเก็บข้อมูลใน Lab ออกมาได้จะพบว่าปัญหาที่เกิดขึ้นเกิดจากการที่ Session ไม่ Reestablish ใหม่หลังจากหมดช่วงเวลา Timeout จาก Protocol LCP เมื่อได้ผลารุปมาแล้วก็นำไปหาวิธีการแก้ปัญหา โดยแบ่งวิธีการแก้ปัญหาเป็น 2 ส่วน ดังนี้
จากรูปตัวอย่างที่ผมเอามาทำบทความนี้เอามาจากการแก้ไขโดยใช้ Command บนอุปกรณ์ที่เชื่อมต่ออยู่ด้วยช่วยแก้ไขการทำงานในส่วนที่ 1 เมื่อลองใส่ Command ใหม่ลงไปแล้วก็ทดสอบใน Lab เหมือนเดิมและก็ไม่ลืมที่จะเก็บ Packet มาวิเคราะห์ปัญหาด้วยเหมือนเดิม จากรูปด้านล่างที่เห็นคือหลังจาก Session timeout แล้วอุปกรณ์สามารถกลับมาเชื่อมต่อได้อย่างปกติ
ซึ่งการนำ Wireshark มาช่วยในส่วนนี้จะพบว่า Command ที่เราใส่ลงไปนั้นสามารถแก้ปัญหาได้อย่างแท้จริงจาก Root cause โดยสามารถยืนยันได้จากผลที่เกิดขึ้นในกราฟที่แสดงให้ดูครับ และสามารถย้อนกลับไปดูในรายละเอียดในส่วนของ Packet ที่เกิดขึ้นในช่วงเวลานั้นๆได้อีกด้วย
ที่สำคัญเมื่อผลที่ทดสอบสามารถทำออกมาได้เป็นกราฟแล้ว ดังนั้นการนำผลที่ได้ไปนำเสนอต่อไปกับหัวหน้าหรือลูกค้าก็สามารถนำไปใช้ได้ทันที และสามารถนำไปสื่อสารได้อย่างตรงจุดเข้าใจได้ในทันที ดีกว่าการเปิด Wireshark และให้หัวหน้าดู Packet ที่เกิดขึ้นทีละบรรทัดแล้วก็ไม่เข้าใจสิ่งที่เราจะนำเสนออยู่ดีครับ
หวังว่าบทความนี้จะเป็นตัวอย่างการเอา Wireshark ไปใช้งานได้ดีขึ้นในส่วนนึงนะครับ
แล้วเจอกันในบทความหน้า (ถ้าพอมีเวลาและขยันเขียน) ขอบคุณที่เสียสละเวลาอันมีค่าเข้ามาอ่านด้วยครับ _/|\_
วันนี้เป็นเรื่องการแสดงค่า Round Trip Time (RTT) หรือค่าเวลาที่ Packet ใช้เวลาในการเดินทางใน Network จากต้นทางไปยังปลายทางและกลับมาที่เครื่องต้นทางอีกครั้งหนึ่ง “ซึ่งค่าที่ได้นี้จะเป็นค่าอ้างอิงของเวลาที่ Packet ใช้เวลาในการเดินทางระหว่างอุปกรณ์ต้นทางและอุปกรณ์ปลายทาง คู่หนึ่งเท่านั้น” ไม่ใช่ค่าเวลาที่สามารถใช้อ้างอิงเวลาที่ใช้ในระบบ Network ของอุปกรณ์ทุกตัวได้
ตัวอย่างการหาค่า RTT อาจจะเป็นการใช้งานคำสั่ง Ping ไปที่ปลายทางต่างๆ ดังนี้
จากรูปด้านบนทั้งสองรูปเราก็จะเห็นว่าค่า “time” ที่อยู่ในกรอบสีแดงทั้งสองค่ามีค่าไม่เท่ากันซึ่งค่าที่เปลี่ยนไปนี้จะมีค่าไม่ท่ากันในทุกๆปลายทาง ซึ่งค่านี้จะเปลี่ยนไปตามอุปกรณ์ต้นทางและอุปกรณ์ปลายทางคู่หนึ่งเท่านั้น ดังที่อธิบายไปแล้วก่อนหน้านี้
สำหรับ Diagram ที่ใช้อธิบายการทำงานของ RTT จะมีรูปแบบดังรูปด้านล่างนี้
หรือถ้าจะมองในรูปแบบของคู่การสื่อสารในรูปแบบการ Request data แบบ peer-to-peer ก็จะได้รูปแบบเป็นตาม Diagram ตามรูปด้านล่างนี้
คราวนี้กลับมาที่หัวข้อของเรากันดีกว่า คราวนี้เราจะนำค่า RTT พวกนี้มาแสดงให้เป็นกราฟเพื่อนำกราฟที่ได้มาใช้ในการดูค่า RTT ของแต่ละ peer ได้อย่างไรบ้าง
ก่อนอื่นก็ให้เราเปิด Packet ที่เรามีอยู่ขึ้นมาด้วยโปรแกรม Wireshark ก่อนจากนั้นก็ให้ทำการเลือกเพ็คเก็ตที่เราต้องการหาค่า RTT จากในรูปตัวอย่างผมจะเลือก Packet ที่มี Source IP address = 172.16.4.115 และมี Destination IP address = 192.168.1.2 ซึ่งการทำแบบนี้ก็คือการที่เราเลือกอุปกรณ์ต้นทางและปลายทางนั่นเอง
ต่อมาให้ไปที่เมนู Statistics -> TCP StreamGraph -> Round Trip Time Graph ตามรูปด้านล่างนี้
จากนั้นก็รอสักพักนึงเพื่อให้โปรแกรม Wireshark ทำการคำนวนค่า RTT ของอุปกรณ์ที่มีค่า IP address = 172.16.4.115 ไปที่อุปกรณ์ปลายทางที่มีค่า IP address = 192.168.1.2 ตามกราฟด้านล่างนี้
กรณีที่เราต้องการแสดงค่า RTT ของคู่การสื่อสารอื่นๆก็สามารถทำได้โดยการเลือก Packet ใหม่โดยอาจจะเปลี่ยน Source IP address หรือ Destination IP address ไปตามที่เราต้องการ จากรูปตัวอย่างด้านล่างผมจะเปลี่ยน Destination IP address = 192.168.1.3
หลังจากที่ได้กราฟที่มีค่า RTT แล้วต่อมาเราจะสามารถสรุปอะไรได้บ้าง ผมขอยกตัวอย่างการสรุปข้อมูลที่ได้จากกราฟดังนี้ครับ
หนึ่งภาพสามารถแทนความหมายมากมาย ภาพที่เกิดจากการ monitor อุปกรณ์ network ก็ทำได้ในแนวเดียวกัน ^^
ภาพที่อยู่ด้านล่างเป็น graph ที่เกิดจากการ “ping” ไปที่ปลายทาง “แค่นั้น” แต่ความหมายที่แสดงอยู่มีค่ามากกว่านั้น ยกตัวอย่างที่เห็นจากภาพไม่ต้องคิดเลยก็มีประมาณนี้
1. ค่าเฉลี่ยของการตอบสนอง ping ไปที่ปลายทางคือ 30 ms.
2. มีบางช่วงที่ ping ไปที่ปลายทางไม่ได้
3. link ที่ใช้ไม่ค่อยจะเสถียรเท่าไร แต่ยอมรับได้
4. ต้องไปมีใครสักคนเปลี่ยนอะไรสักอย่างในช่วง week 20 – week 30
แล้วกราฟนี้มาจากไหน??
ตามหัวข้อ IP SLA เลยกราฟนี้มากจากการใช้ IP SLA command บน Catalyst 3750X ทำการส่งคำสั่ง ping ไปที่ปลายทางที่ต่างประเทศผ่าน internet ส่วน command ก็ประมาณนี้
เท่านี้ L3 ของเราก็จะ ping ไปที่ IP Y.Y.Y.Y แล้วก็เอามาพล็อตกราฟก็จบ แต่ประโยชน์ของมันไม่ได้มีแค่นั้นถ้าเรารู้เบื้องหลังและที่มาก็จะได้ข้อมูลเพื่อเอามาใช้ประโยชน์ได้อีกประมาณนี้
1. เนื่องจากการต่อใช้งาน internet แบบ BGP multihome ทำให้รู้ว่า Best path ไปที่ปลายทาง Y.Y.Y.Y ของ ISP1 แย่กว่า ISP2 จากกราฟในช่วงที่ใช้ ISP1 ทำงานเป็น default route ในหมายเลข 1 และ 4 มี respond time ที่เกิดจากการ ping สูงกว่าเมื่อช่วงที่ ISP2 ทำงานแทนในหมายเลข 3
2. ในช่วงหมายเลข 2 อาจจะมีการ cutoff ระบบแล้วเกิดปัญหากับ ISP1 ทำให้ ISP1 ไม่สามารถทำงานได้แต่ BGP ยังคงทำงานเมื่อ on ระบบขึ้นมาหลังจากทำงานเสร็จแล้ว ISP2 สามารถใช้งานได้ทำให้อุปกรณ์ใน site สามารถใช้งานได้เป็นปกติ
3. ในช่วงที่ ISP2 ทำงานพบว่า respond time ไปที่ IP Y.Y.Y.Y ต่ำกว่าตอนที่ ISP1 ทำงานแสดงว่า ISP2 มี Best path ไปที่ IP Y.Y.Y.Y ดีกว่า ISP1 จุดนี้สามารถนำไปทำ Optimize route ต่อได้อีก
4. เมื่ออุปกรณ์ของ ISP1 กลัมาทำงานได้เป็นปกติ Respond time ของ IP Y.Y.Y.Y กลับมาอยู่ที่ค่าเฉลี่ยประมาณ 70 ms เท่าเดิมแสดงว่าสำหรับ IP ปลายทางนี้ ISP2 มี best path ดีกว่า ISP1 แน่นอน
5. ถ้าลองตรวจสอบย้อนกลับไปที่ช่วงเวลา week ที่ 20 จะพบว่ามีการเปลี่ยนแปลงระบบทำให้สามารถ focus ความผิดพลาดที่เกิดขึ้นได้ว่าพอจะมาจากสาเหตุอะไรกันแน่ได้แม่นยำขึ้น
6. อันนี้ไม่ได้ใส่รูป graph ของ IP ปลายทางตัวอื่นแต่จะพบว่าถึงแม้ ISP2 จะทำงานแต่ Respond time ของ IP ปลายทางอื่นๆยังเท่าเดิมแสดงว่าไปทำการ optimize route แค่ชุดเดียวก็พอ
จะเห็นได้ว่าแค่การ ping ก็สามารถบอกข้อมูลได้เยอะแล้วดังนั้นใครที่ยังไม่ได้ทำระบบ monitor ก็ไปทำเพิ่มซะหน่อยดีกว่าปล่อยให้ระบบ network เป็น black box เวลามีปัญหาก็แก้ไขอะไรไม่ได้ จะเริ่มตรงไหนก็ไม่ถูก เมื่อตอบปัญหาไม่ได้ก็ต้องตกเป็นจำเลยของชาวบ้านเขาเรื่อยไป 😛
ผมคิดว่าเพื่อนๆที่ทำงานตำแหน่ง Network admin หรือ System admin ในบริษัทหลายท่านอาจจะมีความรู้สึกว่า “User ของท่านหลายๆคนจะรู้ว่าจะรบบที่ทำงานอยู่นั้นมีปัญหาได้เร็วกว่าคนที่ทำงานด้าน Network หรือ System ที่ดูแลระบบด้านนั้นๆอยู่เสมอ” ไม่ว่าจะเป็นเรื่องการใช้งานระบบ Database หรือการใช้งาน Internet จนทำให้เวลาที่ระบบมีปัญหาเรามาักจะใช้ “User เป็น Alert system ได้ดีกว่า” การเปิดหน้าจอโปรแกรม System monitor เพื่อดูสถานะของระบบไว้ซะอีก 🙂
ทำไม User จึงสามารถรับรู้ว่าระบบนั้นๆมีปัญหาได้เร็วกว่าเรา? ผู้ดูแลระบบหลายคนก็อาจจะคิดเช่นนั้น รวมทั้งผมเองในช่วงแรกๆ 🙂 แต่เมื่อมองถึงการใช้งานของ User ในด้านที่แตกต่างๆจากผู้ดูแลระบบก็จะพบว่าการที่ User นั้นรับรู้ปัญหาที่เกิดขึ้นได้เร็วกว่าเราก็คือ “พฤติกรรมการใช้งาน” ที่มีมากกว่าเรานั่นเอง เช่น ฝ่ายบัญชีมักจะมีการเรียกข้อมูลหรือเพิ่มข้อมูลลงไปที่ Database บ่อยๆ หรือกำลังดู Youtube อยู่แล้วภาพกระตุก 😛 ในขณที่เราอาจจะพิมพ์ Word อยู่ก็เป็นด้ายยยยย!!! จากพฤติกรรมการใช้งานที่เกี่ยวข้องกับระบบ Network นี้เองทำให้ User รับรู้ได้ถึงการเปลี่ยนแปลงบางอย่างที่เปลี่ยนแปลงไปจากเดิม ความแตกต่างที่ User สามารถรับรู้ได้นั้นจึงเป็นที่มาของการแจ้งความผิดปกติเข้ามาที่ผู้ดูแลระบบอย่างเราๆนั่นเอง
เมื่อเข้าใจถึงพฤติกรรมที่เกิดขึ้นดังนั้นผู้ผลิตอุปกรณ์หลายรายจึงได้ทำการพัฒนา Feature บนอุปกรณ์ขึ้นมาเพื่อให้ผู้ดูแลระบบมาไปใช้งานเพื่อนำค่าที่ได้มาเปรียบเทียบว่าทีอะไรเกิดขึ้นในระบบ Network บ้าง เช่น
ซึ่ง Feature ที่ได้กล่าวถึงไว้ที่ด้านบนจะทำหน้าที่เป็นตัว “สร้าง Traffic” การใช้งานระบบ Network แทน User นั่งเอง โดยเรามาสามารถกำหนดให้อุปกรณ์ทำการตรวจสอบ(หรือใช้งานระบบ) Network เป็นช่างเวลา หรือตรวจสอบการใช้งานตลอดเวลาก็ได้ในกรณีที่เราต้องการนำมาใช้งานเป็นระบบ Real-time monitor
ประโยชน์ของการนำ Feature เช่น IP SLA มาใช้งานเป็นระบบ Real-time monitor คือ Network หรือ System admin จะได้ทราบถึงพฤติกรรมบนระบบที่เกิดขึ้นและเปลี่ยนแปลงไปในช่วงเวลาต่างๆ ซึ่งการใช้งานระบบ Network monitor ทั่วไปที่ให้แต่ผลการใช้งานแค่เรื่อง Traffic (Bandwidth) ที่เกิดขึ้นในระบบทั่วๆไปไม่สามารถให้คำตอบได้ เช่น
1.การตอบสนองการ Query ของ DNS server ว่ามีการตอบสนองการ Query ได้เร็วหรือช้าเป็นเวลาเท่าใด
2.การตอบสนองของ WAN ที่เชื่อมต่อระหว่างสาขานั้นมีค่า Round Trip Time(RTT) ใน WAN เส้นนั้นๆเป็นเวลาเท่าใด
3. การตอบสนองของ Service port บน Server ที่เปิดใช้งานบน Server เครื่องหนึ่งนั้นมีค่าเป็นเท่าใด
4. ค่าเวลาตอบสนองในการทดสอบการ Download ไฟล์จาก FTP server มีค่าเป็นเท่าใด
5. การใช้งาน Web site หนึ่งมีค่าตอบสนองของ TCP/DNS/HTTP เพื่อทำให้โหลดข้อมูลหน้านั้นๆขึ้นมาได้มีค่าเป็นเท่าไร
จากตัวอย่างที่กล่าวมาด้านบนทั้ง 5 แบบเป็นข้อมูลที่ผู้ดูและระบบส่วนใหญ่ต้องการทราบเพื่อนำไปตรวจสอบความผิดปกติหรือทำให้ทราบถึงพฤติกรรมการใช้งานเชิงลึกในระบบ Network ได้มากขึ้นเพื่อให้สามารถนำไปปรับปรุงหรือตรวจสอบการใช้งานที่ผิดปกติได้นั่นเอง
ผมขอยกตัวอย่างสำหรับการนำใช้งานข้อมูลไปใช้งานในบางกรณีดังนี้
ระบบ Internet มีปัญหาในช่วงเวลา 9.30น. ทำให้ User ใช้งาน Internet ไม่ได้ ต่อมา Internet กลับมาใช้งานได้ในช่วงเวลา 9.35น. ในช่วงเวลาที่เหลื่อมกันนั้นเวลา 9.34น. Network admin ได้โทรไปที่ ISP ให้ทำการตรวจสอบ Internet ต้องรอสายจนเวลา 9.36น.จึงจะได้คุยกับ Engineer ของ ISP และ Engineer ได้ขอผล Ping และ Traceroute ไปเพื่อนำไปตรวจสอบ Network admin จึงได้ส่งผลไปให้แต่เป็นผลการ Ping และ Traceroute ที่เวลา 9.37น.
กรณีที่ 1 ไม่มี Proactive monitor: จากช่วงเวลาด้านบน เมื่อส่งผล Ping/Traceroute ไปให้ Engineer ของ ISP ตรวจสอบก็จะพบว่าไม่มีความผิดปกติเกิดขึ้นในการเชื่อมต่อ Internet และเมื่อใช้โปรแกรม Monitor ทั่วไปดูจะพบว่ามี Bandwidth ที่ Interface จากมี Traffic เกิดขึ้นที่ Interface ที่เชื่อมต่อกับ Router ของ ISP ซึ่งอาจจะมีข้อมูลหากันตามปกติ เช่น Routing protocol หรือ L2 protocol อื่นๆ
กรณีที่ 2 มี Proactive monitor: เราจะมีผลการเชื่อต่อของ WAN-to-WAN, การตอบสนองของ Web site ปลายทาง หรือเวลาในการตอบสนองของ DNS server แล้วส่งเป็นกราฟไปให้ ISP ดูซึ่งจำทำให้เกิดความชัดเจนมากกว่าเพราะการทำ Real-time monitor จะต้องมีการเก็บข้อมูลไว้เป็น History ในระดับชั่วโมง วัน เดือน และปี ดังนั้นการที่เราเห็นความผิดปกติที่เกิดขึ้นจะทำให้เรามองเห็นปัญหาได้ชัดเจนและรวดเร็วขึ้นได้เป็นอย่างมาก
จากการแนะนำ Feature pro-active monitor และตัวอย่างการนำไปใช้งานในบทความนี้หวังว่าจะทำให้เพื่อนๆหลานคนได้ Idea ในการทำ Pro-active monitor ไว้ใช้งานในบริษัทของตัวเองกันมากขึ้น เพื่อใช้ในการตรวจสอบและใช้ในการประกอบการวิเคราะห์ปัญหาที่เกิดขึ้นกันได้นะครับ 🙂
ลองหาข้อมูลเพิ่มเติมเกี่ยวกับ Cisco IP SLA เพื่อใช้งานต่อได้ที่
http://www.bloggang.com/mainblog.php?id=likecisco&month=09-07-2015&group=3&gblog=50
http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c/hsoverv.html
ปล. รูปตัวอย่างในบทความมากจาก Cacti โดยใช้ Template ที่ Modify ใหม่เองครับ เพื่อนๆที่สนใจสามารถหา Software อื่นๆมาใช้งานได้เองเช่นเดียวกันนะครับ 🙂
หมายเหตู: การทำ Pro-active monitor ไม่สามารถตอบคำถามทุกอย่างที่เกิดขึ้นได้ จะต้องมีการทำงานที่เกี่ยวข้องกับ Resource monitor อื่นๆด้วยเพื่อทำให้การวิเคราห์ปัญหาทำได้สะดวกและชัดเจนมากขึ้นด้วย การใช้เครื่องที่ดีตัวหนึ่ง อาจจะไม่ได้เหมาะสมกับทุกปัญหาที่เกิดขึ้นครับ
Wireshark for network troubleshooting เป็นหัวข้อ Workshop ที่คิดขึ้นเพื่อให้ผู้เรียนที่เป็นผู้ดูและระบบ Network ให้มีความเข้าใจในการทำงานของพื้นฐานการทำงานของระบบ Network โดยใช้รูปแบบการทำงานของ Protocol TCP มาอธิบายให้เห็นว่าในระหว่างการทำงานในระบบ Network ถ้ามีปัญหาเกิดขึ้นกับส่วนใดในการสื่อสารแบบ TCP จะมีปัญหาอย่างไรเกิดขึ้น และจะนำไปสู่การวิเคราะห์ปัญหาที่เกิดขึ้นในลักษณะต่างๆต่อไปได้อย่างเป็นรูปธรรม
Workshop จะเน้นให้ลงมือทำโดยเนื้อหาจะถูกแบ่งออกเป็น 3 ส่วนที่สำคัญคือ
Workshop ทั้ง 3 ส่วนจะใช้เวลาทั้งหมด 2 วันเพื่อให้ผู้เรียนได้ทำความเข้าใจการนำโปรแกรม Wireshark ไปใช้งานได้อย่างมีประสิทธิภาพ เนื้อหาทั้งหมดได้ผ่านกระบวนการคิดทดสอบและลงมือทำผ่านโปรแกรมอย่าง EVE-NG จากผู้สอนก่อนที่จะลงมือทำเอกสารทุกขั้นตอน เพื่อให้แน่ใจว่าผู้เรียนจะสามารถกลับไปทำการทดลองซ้ำต่อที่บ้านหรือบริษัทต่อไปได้ ทำให้มีความสะดวกในการทบทวนเนื้อหาที่ได้เรียนผ่านไป โดยสามารถทำการทดลองซ้ำตามเอกสารเพื่อให้เกิดความชำนาญจนสามารถนำไปประยุกต์ใช้งานได้อย่างสะดวกตามความต้องการต่อไป
สำหรับเนื้อหาการใช้งานโปรแกรม Wireshark ที่ผู้สอนได้มีการเผยแพร่เป็นวิทยาทานแก่ผู้สนใจได้ทำการอ่านและศึกษาได้ฟรีมีตามหัวข้อดังต่อไปนี้
จากตัวอย่างบทความที่แนะนำมาข้างต้นผู้ที่สนใจ Workshop สามารถใช้อ่านและพิจารณาเนื้อหาเบื้อต้นก่อนสมัครเรียน Workshop ได้ทันทีครับ
ค่าใช้จ่ายในการเรียน 5,000 บาท
สิ่งที่จะได้รับในการเรียน
หมายเหตุุ: เนื่องจากมีการใช้งาน EVE-NG ในการทดลอง ดังนั้นผู้เรียนจึงควรมี Notebook ที่มี Spec ขั้นต่ำดังนี้ เพื่อให้การทดลองได้ประโยชน์สูงสุด
1. CPU Intel core i3
2. Free space on HDD 80G (SSD for best performance)
3. RAM 8G
ระยะเวลาในการอบรม : จะแจ้งให้ทราบผ่านหน้าเพจอีกครั้ง
จำนวนผู้เข้าอบรม : สูงสุด 12 ท่าน
ค่าอบรม : ท่านละ 5,000 บาท
สถานที่อบรม : Comscicafe ติดสถานีรถไฟฟ้า BTS แบริ่ง (มีที่จอดรถให้ผู้เข้าอบรมทุกท่าน)
แผนที่ของ ComSci cafe ใน Google maps คลิกดู ที่นี่
กรณีที่มีความสนใจ Workshop นี้สามารถติดต่อสอบถามได้ที่ Email: info@virtualnetsystems.com หรือ Dowload รายละเอียดเพื่อนำเสนอหน่วยงานได้ ที่นี่
หลังจากเขียนเรื่องเกี่ยวกับ Wireshark มาระยะหนึ่งแล้วหลายๆท่านก็น่าจะได้แนวคิดในการใช้งานโปรแกรมนี้กันมากขึ้นกันแล้ว วันนี้ผมขอเสนอการเอาโปรแกรม Wireshark มาใช้วิเคราะห์ความผิดปกติของ Application ที่เกิดขึ้นโดยใช้งาน Feature IO graph เพื่อแสดงให้เห็นการทำงานที่ผิดปกติได้ชัดเจนและเป็นรูปธรมมมากขึ้น
วันนี้จะขอสมมติเหตการณ์ที่เกิดขึ้นใน Office แห่งหนึ่งซึ่งมีปัญหาการใช้งาน Application server ดังนี้
จากการตรวจสอบปัญหาของโปรแกรมเมอร์ที่เขียนโปรแกรม App 1 ที่ติดตั้งลงใน Application server 1 และ 2 รายงานว่าโปรแกรมไม่มีความผิดปกติใดๆ คาดว่าการที่ App 1 บน Application server 2 ใช้งานไม่ได้นั้นน่าจะเกิดจากการที่ ผู้ดูแลระบบ Network มีการทำ QoS ทำให้เมื่อมีการใช้เข้าใช้งาน Network ในช่วงเช้าที่มีปริมาณข้อมูลจำนวนมากทำให้ App 1 บน Application server 2 มีปัญหา
จากรายงานของโปรแกรมเมอร์ที่ได้ส่งไปให้หัวหน้าทีม Network ทำให้ Network engineer ทำการหาสาเหตุของปัญหาที่เกิดขึ้นโดยใช้โปรแกรม Wireshark เพื่อหาสาเหตุที่แท้จริงมารายงานต่อไป
ตอนนี้เราจะใช้ข้อมูลจากบทความตอนที่แล้วนำมาแยกเป็นชุดการสื่อสารแบบ Client-server มาแยกเป็นชุดไว้จะทำให้ได้ชุด Filter string ดังต่อไปนี้
แต่ก่อนที่จะทำการแยกแยะการใช้งานเป็นแบบ Client-server ให้ลองทำการพิจารณาภาพรวมการใช้งานระบบ Network ก่อนโดยใช้ Feature IO graph จะได้ผลดังนี้
ต่อมาลองดูภาพรวมของการเชื่อมต่อไปที่ Application server 2 จากเครื่อง Front end จะได้ดังนี้ (Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.2)
จากกราฟภาพรวมของระบบ Network ในรูปแรกและการเชื่อมต่อไปที่ Application server 2 ไม่พบการทำงานของการทำงานของ QoS ซึ่ง Throughput จะต้องมีลักษณะราบเรียบลงในส่วนที่ QoS ทำงานอยู่
ต่อมาลองพิจารณาการทำงานของ App 1 และ App 2 ที่อยู่ที่เครื่อง Application server 2 โดยใช้ Filter string ดังนี้
จากกราฟที่ได้จะพบว่าที่เครื่อง Application server 2 จะมีความผิดปกติที่ App 1 เท่านั้นซึ่งตรงกับที่ User A, C รายงาน
ต่อมาให้ทำการเปรียบเทียบการทำงานของ App 1 และ App 2 ที่ติดตั้งลงบนเครื่อง Application server 2 จะได้ผลดังนี้
จะเห็นได้อย่างชัดเจนว่า App 1 บน Application server 2 มีปัญหาเกิดขึ้นเพียง App เดียวจริง
เพื่อความแน่ใจลองตรวจสอบการทำงานของ App 1 ที่เครื่อง Application server 1 เพื่อลองหาความผิดปกติที่อาจจะเกิดขึ้้นด้วย Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.9 && tcp.port==2074 จะได้ผลดังนี้
จากผลที่ได้จะตรงกับที่ User B รายงานว่าสามารถใช้งาน App 1 บนเครื่อง Application server 1 ได้อย่างปกติ
ต่อมาลองทำการเปรียบเทียบค่า Throughput ของ App 1 บน Application server 1 และ Application server 2 เพื่อหาความแตกต่างว่าถ้า QoS เป็นต้นเหตุของปัญหาค่า Throughput ของทั้ง 2 server ควรจะมีค่าที่ต่างกันมากจนทำให้ QoS ทำงานจนตัด Connection ของ Application server 2
จากกกราฟที่ได้แสดงให้เห็นว่า Throughput ของ App 1 บน Application server 1 และ Application server 2 มีค่าใกล้เคียงกันมากในช่วงเข้าจนกระทั่งช่วงเวลาประมาณ 9.30น. App 1 บน Application server 2 จึงเกิดปัญหาไม่สามารถใช้งานได้ และหลังจากที่ App 1 กลับมาใช้งานได้ค่า Throughput ของ App 1 ก็ยังมีค่าใกล้เคียงกันทั้ง 2 server (มีค่าต่างกันบ้างอาจจะเกี่ยวกับการดึงข้อมูล) ดังนั้นการที่กล่าวว่า QoS เป็นสาเหตุของปัญหาที่เกิดขึ้นจึงเป็นเรื่องที่ไม่เป็นความจริงและไม่มีหลักฐานใดที่ระบุได้ว่าระบบ Network มีปัญหาในช่วงเวลาดังกล่าว
และเมื่ออพิจารณาจากภาพรวมที่ได้จากระบบ Network ทั้งหมดจะเห็นได้อย่างชัดเจนว่าปัญหาที่เกิดขึ้นนั้นน่าจะเกิดจาก App 1 ที่มีการใช้งานระหว่างเครื่อง Frontend (172.16.4.115) และ Backend (192.168.1.2) มากกว่าจะมาจากระบบ Network
ผมหวังว่าบทความนี้น่าจะเป็นตัวอย่างการนำโปรแกรม Wireshark ไปประยุกต์ใช้งานให้กับหลายๆท่านได้ต่อไปนะครับ
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
กลับมาอีกครั้งหลังจากหายไปหลายอาทิตย์ ^^
รอบนี้กลับมาลองใช้ Wireshark ทำงานในส่วนของ Network forensics กันดูบ้างว่ามันจะเป็นเช่นไร……….
เข้าเรื่องกันเลยดีกว่าวันนี้เราจะขอเสนอฟังก์ชั่น “Export Objects” ซึ่งฟังก์ชั่นนี้จะทำหน้าที่ในการ “สกัด” สิ่งที่อยู่ในรูปแบบของแพ็คเก็ตที่ดูแล้ว “ไม่เข้าใจ” ให้ออกมาเป็นในรูปแบบของไฟล์ หรือ URL เนื่องจากวันนี้เราจะเน้นให้ทำการ “สกัด” เนื้อหาที่อยู่ในรูปแบบของ HTTP โปรโตคอลออกมานั่นเอง
โดยปกติแล้วเมื่อเปิด Wireshark ขึ้นมาและทำการจับข้อมูลที่วิ่งผ่านเข้ามาในเครื่องของเรา สิ่งที่เห็นจะมีรูปแบบในรูปด้านล่างนี้ คือ Source-Destination IP Address, Port, Packet information ซึ่งโดยปกติแล้วเราจะไม่มีทางรู้ได้เลยว่าข้อมูลที่อยู่ภายในนั้นคืออะไร ยกตัวอย่างเช่น URL อะไร หรือรูปที่เปิดขึ้นมาอยู่ที่ URL ไหน?
ยกตัวอย่างการใช้งานในรูปแบบของ Network forensic ในหัวข้อนี้จะลองทำการ “ประกอบร่าง” แพ็คเก็ตที่ได้มาจาก Wireshark ให้กลายเป็นข้อมูลที่สมบูรณ์และย้อนกลับไปได้ว่าไฟล์ที่เปิดขึ้นมาอยู่ที่ URL ใดและลองโหลดไฟล์ที่ได้จากการ “ประกอบร่าง” ลงมาในเครื่องของเราเพื่อทำการตรวจสอบต่อไปได้นั่นเอง
ก่อนที่จะใช้ฟังก์ชั่นนี้ได้อย่างสมบูรณ์เราจะต้องมาการเตรียมการให้เรียบร้อยก่อนตามขั้นตอนดังนี้
โดยการตั้งค่าทั้งหมดนี้ให้เข้าไปทำที่เมนู Edit Preference… ตามรูปด้านล่างนี้
เมื่อทำการตั้งค่าทั้งหมดเสร็จเรียบร้อยแล้วให้เข้าไปที่เมนู File -> Export Objects -> HTTP ก็จะมีหน้าต่างเปิดขึ้นมาใหม่คือ “Wireshark: HTTP object list” โดยในหน้านี้จะแสดงรายละเอียดของสิ่งที่ได้จากการ “ประกอบร่าง” เช่น Hostname ซึ่งก็คือ เวบไซท์ที่เราได้เข้าไป Content Type คือชนิดของไฟล์ที่ได้จากการเข้าไปที่เวบไซท์นั้น Size คือขนาดของไฟล์ที่โหลดขึ้นมา และสุดท้าย Filename คือชื่อของไฟล์ที่โหลดมานั่นเอง
ในตัวอย่างนี้ผมจะทำการเซฟไฟล์ชื่อ “UNL%20diagram.png” ลงมาที่เครื่องโดยการเลือกที่ไฟล์ที่ต้องการและกด “Save As” จากนั้นให้ทำการเลือกตำแหน่งที่ต้องการเซฟลงในเครื่องและทำการตั้งชื่อตามที่ต้องการ หลังจากนั้นให้ทำการเปิดไฟล์ที่ได้จากการเซฟเมื่อสักครู่นี้ขึ้นมา สำหรับผมจะได้ผลจากการเปิดไฟล์ขึ้นมาตามรูปด้านล่างนี้ครับ
สำหรับตัวอย่างการประยุกต์ใช้งานในส่วนของ Network forensics คือการนำไปใช้หาข้อมูลการดาวน์โหลดไฟล์ที่ไม่ได้รับอนุญาตจากทั้งในส่วนของภายในและภายนอกบริษัท หรือในส่วนของตัวอย่างจะเป็นการดาวน์โหลดไฟล์จาก Internet มาซึ่งสามารถระบุได้ถึง Hostname และชื่อไฟล์ซึ่งเป็นหลักฐานที่ดีในระดับนึงเลยทีเดียว
หมายเหตุ: การ “สกัด” เนื้อของไฟล์ที่ต้องการจำเป็นที่จะต้องมีปริมาณของแพ็คเก็ตในปริมาณที่มากพอและครบถ้วนเพื่อที่จะได้ไฟล์หรือเนื้อหาตามที่ต้องการได้อย่างถูกต้องสมบูรณ์ด้วยเช่นกัน
หวังว่าคงจะได้แนวคิดในการนำไปประยุกต์ใช้งานกันต่อแล้วนะครับ ขอบคุณทุกท่านที่ติดตามนะคร้าบบบบบ _/|\_
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
ความเห็นล่าสุด