بارها و بارها ، من برخی از نمونه های پروتکل را به Ultimate PCAP اضافه می کنم. فقط برای مرجع و چون می توانم ؛ D
HomePlug AV
به طور هم زمان ، با این پروتکل "HomePlug AV" در شبکه خانگی خود روبرو شدم. این روتر خانگی من AVM Fritzbox بود که برخی از آداپتورهای برق دیگر را تشخیص می داد. Wireshark دارای فیلتر نمایشگر است
homeplug-av برای آن ، اما شما همچنین می توانید از فیلتر مبتنی بر EtherType استفاده کنید:
eth.type == 0x88e1 .
4in6
در حالی که 6in4 یک روش معمول برای بسته های IPv6 تونل از طریق شبکه های فقط IPv4 است ، 4in6 برعکس این کار را انجام می دهد: اتصال جزایر v4 به V6 این در مسیر درست پیش می رود. ؛) این امر در اتصالات ISP مسکونی در آلمان که دیگر نسخه بومی دیگر امکان پذیر نیست کاملاً رایج است. آنها آن را DS-Lite می نامند (که اتفاقاً سایر مشکلات فنی را با خود به همراه می آورد).
از نظر فنی ، 4in6 پروتکل اختصاصی نیست (که به یک جداکننده پروتکل خاص در Wireshark نیاز دارد) ، بلکه IPv4 معمولی است بسته ها درست در پشت سرآیند IPv6 قرار دارند. از این رو ، فیلتر نمایشگر فقط مناسب است
ipv6.nxt == 4 از آنجا که قسمت Next Header در هدر v6 به این "کپسوله سازی IPv4" عمومی با شماره پروتکل 4 اشاره می کند. تصویر زیر همچنین جلسه PPPoE و PPP و همچنین VLAN 7 را نشان می دهد ، که VLAN داده پیش فرض برای اتصالات دویچه تلکام است.
DNS RR HTTPS
پیش نویس ركورد منابع (RR) برای DNS وجود دارد كه "HTTPS" نامیده می شود. صادقانه بگویم ، من از این RR آگاه نبودم تا اینکه ورودی های زیادی را در Pi-hole خود برای این امر پیدا کردم: (در ابتدا ، فکر می کردم ارائه اشتباهی برای URL هایی است که با HTTPS شروع می شوند.))
[19659010] مقدار نوع این رکورد منبع HTTPS 65 است. من کاملاً مطمئن نیستم که از این RR چگونه استفاده شده است. به نظر می رسد دستگاه های اپل من در حال جستجو برای آن هستند. توجه داشته باشید که هر درخواست HTTPS با پاسخ مربوطه HTTPS پاسخ داده نمی شود. برای یافتن همه سeriesالات یا پاسخهای HTTPS ، از این فیلتر نمایشگر استفاده کنید:
(dns.qry.type == 65) . به نظر می رسد به این شکل است: (با دو ستون سفارشی ، یکی برای نوع درخواست و دیگری برای نوع پاسخ ]
فقط برخی از پاسخ ها با یک پاسخ می دهند HTTPS RR ،
(dns.resp.type == 65) :
SNMP Trap
هیچ معامله بزرگی وجود ندارد ، اگرچه تاكنون از دست رفته است. برخی از تله های SNMP ، بدون اتصال به پورت UDP 162 ارسال می شوند. فیلتر نمایشگر Wireshark
snmp دقیقاً مانند بسته های معمولی پرس و جو / پاسخ SNMP روی پورت UDP 161 کار می کند:
لطفا توجه داشته باشید که در مورد من دام های SNMP کمی بیشتر از یک بسته UDP بودند ، از این رو پراکنده است. و از آنجا که UDP هیچ تکه تکه ای (مانند TCP) ندارد ، تکه تکه شدن در لایه IP رخ می دهد (به طور کلی توصیه نمی شود). به هر حال در واقع اینگونه به نظر می رسد:
Syslog از طریق TCP
مسئله مهمی هم نیست. این یک ورود به سیستم syslog از طریق TCP است نه UDP. با این حال ، در حالی که IANA پورت UDP 514 را به عنوان "syslog" ذکر می کند ، پورت TCP 514 به عنوان "shell" ذکر شده است. Wireshark این را دنبال می کند ، بنابراین نمی توانید استفاده کنید
syslog به عنوان فیلتر نمایشگر اما
rsh برای پوسته از راه دور. یا استفاده می کنید
tcp.port eq 514 برای دیدن کل جلسه شامل سربار TCP (توصیه می شود). بخش "بسته بایت" از قبل نویسه های ASCII را رمزگشایی می کند ، "Follow TCP Stream" را نیز رمزگشایی می کند.
در تنظیمات Wireshark ، می توانید پورت پیش فرض RSH را از 514 به 0 تغییر دهید (به عنوان مثال) در حالی که پورت TSP syslog را به 514 تغییر می دهید. این پیامهای syslog ارسالی از طریق TCP را شناسایی و تجزیه می کند.
صادقانه بگویم ، من کاملاً مطمئن نیستم که آیا 514 پورت صحیح syslog از TCP است. برخی منابع پورت TCP 601 (RFC 3195) را فهرست می کنند ، در حالی که برخی دیگر بیان می کنند که 514 بیشتر استفاده می شود (RFC 6587). به هر حال ، Wireshark به هیچ عنوان پورت TCP پیش فرض برای syslog ندارد. اگر می خواهید بدون درگیری باشد ، می توانید از پورت TCP 601 برای آن استفاده کنید ، در حالی که این پورت را به عنوان درگاه پیش فرض TCP برای syslog در Wireshark تنظیم می کنید:
یعنی می توانید از فیلتر نمایشگر استفاده کنید
syslog دوباره برای جلسات TCP 601. و جدا کننده پروتکل در بخش جزئیات بسته کار می کند:
به هر حال ، syslog را در جلسات TCP در هر دو درگاه در pcap ، 514 و 601 پیدا خواهید کرد.)
عکس از Sharon Pittaway در Unsplash.
