نسخه به روز شده Ultimate PCAP من در دسترس است. این پروتکل های شبکه دیگری را نشان می دهد که در این پست وبلاگ به تصویر می کشم. از آنجا که متداول ترین پروتکل ها قبلاً در آنجا موجود بودند ، خاص تر می شود. ؛)
FTP و FTPS
قطعاً یکی از معروف ترین پروتکل ها: FTP. سه ردیف FTP در ردیابی وجود دارد:
- دو جلسه Fv IPv4 بین
ip.addr eq 10.82.185.11 و ip.addr eq 5.35.226.136 – یکی از طریق FTP رمزگذاری نشده (بله ، می توانید رمز عبور و کل پرونده منتقل شده را ببینید!) ، و دیگری با TLS. من از FileZilla نسخه 3.50.0 استفاده کردم. - یک جلسه IPv6 از یک کامپیوتر ویندوز 7 با استفاده از فایل اکسپلورر ، که از FTP رمزگذاری نشده استفاده می کند. آخ. فیلتر نمایشگر:
ipv6.addr eq 2001: 470: 765b: 0: 1965: 111f: 4398: d558 and ipv6.addr eq 2a01: 488: 42: 1000: 50ed: 8588: 8a: c570 .
شما باید به جای استفاده از فیلتر نمایشگر مبتنی بر IP
ftp یا ftp-data به منظور دیدن کل جلسه دست دادن TCP و TLS. زوج
tcp.port در {20 21} به دلیل استفاده از پورت های غیرفعال پویا کافی نیست! Sigh.
در هر سه جلسه وارد سیستم شدم ، پوشه را به "/ Correct Files" تغییر دادم و پرونده "Lorem ipsum dolor sit amet.txt" را بارگیری کردم. (که می توانید در اینجا پیدا کنید: https://testfiles.webernetz.net/.))19659016 navaPlaintext FTP شامل. password
BFD
پروتکل تشخیص هدایت دو طرفه (RFC 5881) بین روترها استفاده می شود تا خرابی پیوند را خیلی سریع تشخیص دهد. در پرونده ردیابی من ، می توانید دو روتر را با استفاده از OSPF همراه با BFD پیدا کنید. از پورت های UDP 3784 برای بسته های کنترل و 3785 برای بسته های echo استفاده می کند. فیلتر نمایشگر Wireshark "bfd" فقط بسته های کنترل را نشان می دهد در حالی که "bfd_echo" بسته های echo را نشان می دهد. همچنین می توانید فیلترهای دیگری مانند
udp.port در {3784 3785} برای فیلتر کردن برای آنها. (این همچنین نشان می دهد یک مقصد ICMP غیرقابل دسترسی به مقصد غیرقابل دسترسی پس از اولین بسته کنترل است که توسط فیلتر "bfd" نشان داده نمی شود.)
در تصویر زیر ، همچنین می توانید یک پورت ICMP را ببینید که درست پس از اولین بار غیرقابل دسترسی است. بسته کنترل به نظر من ، این به این دلیل است که همسایگی BFD هنوز ایجاد نشده است یا روتر ارسال کننده اولین پیام کنترل هنوز پورت دریافت را باز نکرده است.
ردیابی اولین ثانیه های پس از راه اندازی مجدد روتر است ، ProfiShark من.
پیکربندی Cisco IOS برای این نصب استفاده شده است:
|
رابط GigabitEthernet0 / 0 ip آدرس 193.24.225.25.56
نمایش فرمان:
OCSP Staplingشما می توانید برخی بسته های مربوط به OCSP را در Ultimate PCAP پیدا کنید ، به دو قسمت تقسیم شده است:
با استفاده از فیلتر نمایشگر "ocsp" هر دو نوع را پیدا خواهید کرد. توجه داشته باشید که این کل اتصالات TCP / TLS را نشان نمی دهد ، بلکه فقط قطعات OCSP را نشان می دهد. علاوه بر این ، توجه داشته باشید که وضعیت گواهی منگنه شده در اتصال TLS پروتکل OCSP نیست ، بلکه فقط یک لایه ضبط TLS است.   ACME Challengeخوب ، این پروتکل شبکه خود نیست اما از HTTP برای چالش استفاده می کند. از این رو جدا کننده Wireshark یا موارد مشابه دیگری ندارد. چالش های پروتکل HTTP-01 Automatic Certificate Management Environment (ACME) با متن ساده HTTP در پورت 80 است. من آنها را در یک بسته ضبط شده در Raspberry Pi پیدا کردم که میزبان random.weberlab.de و ip.webernetz.net (از جمله) . چندین جلسه کوتاه HTTP را مشاهده خواهید کرد که درخواست مسیر معروف "/.well-known/acme-challenge/cepts19459063]" را می دهد:  OpenPGP HTTP Keyserver Protocol (HKP) [19659003] پروتکل سرور کلید HKP برای انتقال کلیدهای OpenPGP به / از یک سرور استفاده می شود. من از آن در پلاگین Enigmail خود برای Thunderbird استفاده می کنم. در واقع ، این یک پروتکل واقعی نیست اما HTTP روی پورت 11371 است. حتی مقاله ویکی پدیا (تا سال 2020) و نه جدا کننده Wireshark اختصاصی ندارد. ؛) Wireshark آن را به عنوان HTTP لیست می کند:
 هنگام دنبال کردن جریان TCP- یا HTTP ، می توانید انتقال کلید عمومی OpenPGP را مشاهده کنید:  HTTPS اتصال مجدد / از سرگیری جلسهمجدداً ، این در واقع یک پروتکل اختصاصی نیست ، بلکه یک واریانس کوچک در نحوه استفاده HTTPS با نام مستعار TLS است: با از سرگیری جلسه. آزمایش شده با:
با فیلتر نمایشگر پیدا کنید:  mDNSهه ، خنده دار ، من حتی نمی دانستم که بسته های mDNS را در ردیابی خود دارم تا اینکه به طور تصادفی به آن برخورد کردم. ؛) AFAIK همه آنها توسط دستگاه های اپل در طول ضبط های من برای AirPlay و AirPrint تهیه شده اند. ترافیک قدیمی IP و IPv6 ، منبع و مقصد بندر UDP 5353:  متفرقه: منفی دلتا تایمزاین پروتکل نیست ، بلکه یک مشاهده عجیب در Wireshark است: زمان دلتا منفی. چی؟ چطور؟ به اتصالات بین:
من در توییتر کمی بحث داشتم ، در حالی که Sake Blok از SYN-bit سرانجام نکاتی را در مورد آن برای من ارسال کرد: قطعاً مشکل پرش زمان NTP نیست همانطور که بارها و بارها در یک موضوع مشابه اتفاق می افتد. از آنچه می توانم بگویم ، طرف از راه دور یک پاسخ و یک بسته FIN به سرعت یکی پس از دیگری ارسال می کند (به بسته های 6 و 8 مراجعه کنید). در نهایت با همان وقفه توسط سیستم عامل خوانده می شوند و بنابراین تقریباً با همان زمان (2 میکرو ثانیه از هم تفکیک می شوند) که به لحاظ فیزیکی در پیوند 1Gbit / s برای بسته 982 بایت امکان پذیر نیست ، دارای مهر زمان می باشند ، حداقل باید مثل 8 like میلی متر از هم فاصله داشته باشید). از مقدار ACK فریم 7 ، مشخص است که این فقط به 6 پاسخ می دهد ، نه به 6 و 8. بنابراین libpcap در قرار دادن این بسته بین این دو قاب صحیح است. اما ظاهراً ، این بسته بعداً به مهر زمان می رسد. من در کار دقیق داخلی مکانیزم ضبط تخصص ندارم. اما من دو چیز می دانم: متشکرم ، ساک!
|
