tcpdump: "จับแพ็คเก็ต" เทียบกับ "รับแพ็คเก็ตที่ได้รับจากตัวกรอง"


11

เรามีสคริปต์ที่เรียก

tcpdump -v src host <IP address> and port <port number> >>out.txt 2>>err.txt -w capture.cap

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

คำถามคือตามที่แนะนำเรื่องอะไรคือความแตกต่างระหว่าง "แพ็กเก็ตที่จับ" และ "แพ็กเก็ตที่ได้รับจากตัวกรอง" มีการจับซึ่งไม่ได้บันทึกแพ็กเก็ตใด ๆ แต่เอาท์พุท "จับแพ็คเก็ต 0, แพ็คเก็ตที่ได้รับจากตัวกรอง 2" ซึ่งฟังดูขัดแย้งกันเพราะถ้าไม่มีการจับแพ็คเก็ต ตอนแรกเรามองหา "0 แพ็กเก็ตที่ได้รับจากตัวกรอง" แต่นั่นไม่ใช่การเขียนไปยังเอาต์พุตข้อผิดพลาดเสมอเมื่อไม่มีแพ็กเก็ตที่ได้รับ ดังนั้นตัวเลขเหล่านี้แสดงอะไร

ฉันจำเป็นต้องรู้ว่าจะค้นหาสิ่งใดถ้าเราต้องการกรองกรณีเหล่านั้นเมื่อไม่ได้รับแพ็กเก็ตตอบกลับ

คำตอบ:


12

ฉันหวังว่านี่จะให้ความกระจ่างในเรื่องนี้ จากmanpage :

เมื่อ tcpdump เสร็จสิ้นการจับแพ็คเก็ตมันจะรายงานจำนวน:

แพ็กเก็ตที่จับ (นี่คือจำนวนของแพ็กเก็ตที่ tcpdump ได้รับและประมวลผล)

แพ็คเก็ตที่ได้รับจากตัวกรอง (ความหมายของสิ่งนี้ขึ้นอยู่กับระบบปฏิบัติการที่คุณใช้งาน tcpdump และอาจเป็นไปได้ที่วิธีการตั้งค่าระบบปฏิบัติการ - หากตัวกรองถูกระบุในบรรทัดคำสั่งในบางระบบจะนับจำนวนแพ็กเก็ต พวกมันถูกจับคู่โดย expression ของตัวกรองและแม้ว่าพวกมันจะถูกจับคู่กับ expression ของตัวกรองโดยไม่คำนึงว่า tcpdump ได้อ่านและประมวลผลแล้วหรือยังใน OS อื่น ๆ จะนับเฉพาะแพ็กเก็ตที่จับคู่โดย expression ของตัวกรองโดยไม่คำนึงว่า และประมวลผลมันและใน OS อื่น ๆ จะนับเฉพาะแพ็กเก็ตที่จับคู่โดยนิพจน์ตัวกรองและถูกประมวลผลโดย tcpdump);

แพ็กเก็ตที่ถูกปล่อยโดยเคอร์เนล (นี่คือจำนวนของแพ็กเก็ตที่ถูกดร็อปเนื่องจากพื้นที่บัฟเฟอร์ไม่เพียงพอโดยกลไกการดักจับแพ็กเก็ตในระบบปฏิบัติการที่ tcpdump ทำงานอยู่หาก OS รายงานข้อมูลนั้นไปยังแอปพลิเคชันถ้าไม่ใช่ จะถูกรายงานเป็น 0)

และมีรายการจดหมายข่าวจากปี 2009 ที่อธิบายว่า:

หมายเลข "แพ็กเก็ตที่ได้รับจากตัวกรอง" คือps_recvหมายเลขจากการโทรถึงpcap_stats(); กับBPFว่าเป็นตัวเลขจากbs_recv BIOCGSTATS ioctlจำนวนนั้นรวมถึงแพ็คเก็ตทั้งหมดที่มอบให้กับ BPF แพ็กเก็ตเหล่านั้นอาจยังอยู่ในบัฟเฟอร์ที่ยังไม่ได้อ่านโดย libpcap (และไม่ส่งไปที่ tcpdump) หรืออาจอยู่ในบัฟเฟอร์ที่อ่านโดย libpcap แต่ยังไม่ได้ส่งไปยัง tcpdump ดังนั้นจึงสามารถนับแพ็กเก็ตที่ ไม่ถูกรายงานว่าเป็น "จับ"

อาจจะเป็นกระบวนการที่ถูกฆ่าตายอย่างรวดเร็วเกินไป? นอกจากนี้ยังมี-c Nธงบอก tcpdump ให้ออกเมื่อNจับแพ็กเก็ต

เนื่องจากคุณกำลังดูเหมือนปัญหาความสวยคุณยังสามารถใช้libpcapโดยตรงหรือผ่านทางหนึ่งในร้อยของการผูกภาษา

สำหรับคำถามของคุณเนื่องจากสิ่งที่คุณได้รับคือแพ็คเกจที่บันทึกในcapture.capไฟล์คุณสามารถดูการวิ่งที่มันไม่ว่างเปล่าและตรวจสอบสิ่งเหล่านี้เช่น uhm นับจำนวนบรรทัดได้หรือไม่

tcpdump -r capture.cap | wc -l

อาจมีวิธีที่ดีกว่าในการใช้ libpcap เพื่อส่งคืนจำนวนรายการในไฟล์การจับภาพ ...


1
นอกจากนี้หากการจัดการแพ็คเก็ตช้าเป็นไปได้ว่าแพ็คเก็ตจะลดลงในฮาร์ดแวร์ NIC ก่อนที่มันจะเคยเห็นเคอร์เนล
Craig

@Craig: กล่องที่เรียกใช้สคริปต์นี้เป็นเสมือนจริงดังนั้นฉันจึงไม่ทราบเกี่ยวกับความเร็วของ NIC
Alex Biro

@sr_: ความคิดที่ดีกับบรรทัดง่ายเกินไป :) ฉันเดาว่าเราไม่ต้องใช้สวิตช์ -w แต่เพียงแค่เปลี่ยนเส้นทางเอาต์พุตไปที่ไฟล์และนับจำนวนบรรทัด จะตรวจสอบโดยเร็วว่า
Alex Biro

@ tuareg85: การวิเคราะห์แพ็กเก็ตที่ดักจับ-wนั้นยอดเยี่ยมมาก คุณสามารถใช้ Wireshark กับมันได้
sr_

1
การฆ่ากระบวนการเร็วเกินไปอาจไม่เป็นปัญหาเนื่องจากเรารอ 3 วินาทีหลังจากหยุดการจราจรฉันคิดว่าควรจะเพียงพอ tcpdump ก็มีเวลาที่จะเสร็จสิ้นข้อผิดพลาดเอาท์พุทเช่นกันและแพ็คเก็ตลดลงโดยเคอร์เนลเสมอ 0
อเล็กซ์ Biro
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.