Tcpdump - príkaz Linux - príkaz Unix

NÁZOV

tcpdump - skládka prevádzky v sieti

SYNOPSA

tcpdump [ -adeflnNOpqRStuvxX ] [ -c počítať ]

[ -C veľkosť súboru ] [ -F súbor ]

[ -i rozhranie ] [ -m modul ] [ -r súbor ]

[ -s snaplen ] [ -T typ ] [ -U užívateľ ] [ -w súbor ]

[ -E algo: tajné ] [ výraz ]

POPIS

Tcpdump vytlačí hlavičky paketov na sieťovom rozhraní, ktoré zodpovedá booleovskému výrazu . Môže sa tiež spustiť s príznakom -w , čo spôsobí, že uložiť paketové dáta do súboru pre neskoršiu analýzu a / alebo príznak -r , čo spôsobí, že sa číta z uloženého súboru paketov, a nie čítať pakety zo sieťového rozhrania. Vo všetkých prípadoch budú spracované tcpdump iba pakety, ktoré zodpovedajú výrazu .

Tcpdump , ak nie je spustený s príznakom -c , pokračuje v zachytení paketov, až kým nie je prerušený signálom SIGINT (generovaným napríklad zadaním znaku prerušenia, typicky ovládaním C) alebo signálu SIGTERM (1) príkaz); ak je spustený s príznakom -c , bude zachytiť pakety, kým nebude prerušený signálom SIGINT alebo SIGTERM alebo nebol spracovaný špecifikovaný počet paketov.

Keď tcpdump ukončí zachytenie paketov, bude hlásiť počty:

pakety `` prijaté filtrom '' (význam toho závisí od operačného systému, na ktorom spúšťate tcpdump a prípadne od konfigurácie operačného systému - ak bol na príkazovom riadku zadaný filter, v niektorých operačných systémoch sa počíta paketov bez ohľadu na to, či sa zhodovali s výrazom filtra, a na iných operačných systémoch počíta iba pakety, ktoré zodpovedali výrazu filtra a boli spracované pomocou tcpdump );

pakety `` dropped by kernel '' (to je počet paketov, ktoré boli kvôli nedostatku vyrovnávacieho priestoru odstránené mechanizmom zachytávania paketov v operačnom systéme, na ktorom je spustený tcpdump , ak OS hlási informácie do aplikácií; ak nie, bude hlásený ako 0).

Na platformách, ktoré podporujú signál SIGINFO, ako napríklad väčšina BSD, oznámi tieto počty, keď dostane signál SIGINFO (generovaný napríklad zadaním znaku `` status '', zvyčajne control-T) a bude pokračovať v zachytení paketov ,

Čítanie paketov zo sieťového rozhrania môže vyžadovať špeciálne privilégiá:

Pod SunOS 3.x alebo 4.x s NIT alebo BPF:

Musíte mať prístup na čítanie na / dev / nit alebo / dev / bpf * .

V systéme Solaris s DLPI:

Musíte mať prístup na čítanie a zápis do sieťového pseudo zariadenia, napr. / Dev / le . Prinajmenšom na niektorých verziách systému Solaris to však nestačí na to, aby mohol tcpdump zachytiť v promiskuitnom režime; na tých verziách systému Solaris musíte byť root, alebo tcpdump musí byť nainštalovaný nastavený na koreň, aby bol zachytený v promiskuitnom režime. Všimnite si, že na mnohých (možno všetkých) rozhraniach, ak nezaznamenávate v promiskuitnom režime, neuvidíte žiadne odchádzajúce pakety, takže zachytenie, ktoré sa nevykonáva v promiskuitnom režime, nemusí byť veľmi užitočné.

Pod HP-UX s DLPI:

Musíte byť root alebo tcpdump musí byť nainštalovaný nastavený na root.

Pod IRIX s snoopom:

Musíte byť root alebo tcpdump musí byť nainštalovaný nastavený na root.

V systéme Linux:

Musíte byť root alebo tcpdump musí byť nainštalovaný nastavený na root.

Pod Ultrix a digitálny UNIX / Tru64 UNIX:

Každý používateľ môže zachytiť sieťovú komunikáciu pomocou tcpdump . Avšak žiadny používateľ (dokonca ani superužívateľ) nemôže zachytiť v promiskuitnom režime na rozhraní, pokiaľ superužívateľ neumožnil operáciu v promiskuitnom režime na tomto rozhraní pomocou pfconfig (8) a žiadny používateľ (ani super používateľ ) dokáže zachytiť návštevnosť s jednosmernou komunikáciou prijatú alebo odoslanú strojom na rozhraní, pokiaľ superperián neumožní kopírovanie celého režimu na tomto rozhraní pomocou pfconfigu , takže užitočné zachytenie paketov na rozhraní pravdepodobne vyžaduje buď promiskuitný režim alebo kopírovanie - v tomto režime je povolené všetky prevádzkové režimy alebo obidva režimy prevádzky.

Pod BSD:

Musíte mať prístup na čítanie / dev / bpf * .

Čítanie uloženého súboru paketov nevyžaduje špeciálne privilégiá.

MOŽNOSTI

-a

Pokúste sa previesť adresy siete a vysielania na mená.

-c

Ukončite po prijatí početných paketov.

-C

Pred zapísaním nespracovaného paketu do súboru uloženia skontrolujte, či je súbor v súčasnosti väčší ako file_size a ak áno, zatvorte aktuálny súbor uloženia a otvorte nový súbor. Po prvom súbore ukladania súborov Savefiles bude zadaný názov s príznakom -w s číslom za ním začínajúcim od 2 a pokračovaním smerom hore. Jednotky file_size sú milióny bajtov (1 000 000 bajtov, nie 1 048 576 bajtov).

-d

Skomprimujte kompilovaný kód zodpovedajúci paketom v ľudskej čitateľnej forme na štandardný výstup a zastavte.

-DD

Kód vynechania paketu ako fragmentu programu C.

-DDD

Kód pre odpísanie paketov ako desiatkové čísla (pred ktorým je počet).

-e

Vytlačte hlavičku úrovne odkazu na každom výpisovom línii.

-E

Použite algo: tajné pre dešifrovanie paketov IPsec ESP. Algoritmy môžu byť des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc alebo žiadne . Predvolená hodnota je des-cbc . Schopnosť dešifrovať pakety je prítomná iba vtedy, ak bol tcpdump kompilovaný s povolenou kryptografiou. tajný text ascii pre tajný kľúč ESP. V tejto chvíli nemôžeme brať ľubovoľnú binárnu hodnotu. Voľba predpokladá RFC2406 ESP, nie RFC1827 ESP. Možnosť slúži len na účely ladenia a použitie tejto možnosti s skutočne "tajným" kľúčom je odrádzané. Predstavením tajného kľúča IPsec na príkazový riadok ho môžete vidieť pre ostatných prostredníctvom ps (1) a iných príležitostí.

-f

Tlačte zahraničnú internetovú adresu číselne a nie symbolicky (táto možnosť je určená na to, aby sa na serveri Sun servera vyskytlo vážne poškodenie mozgu - zvyčajne to visí naveky prekladaním ne-miestnych internetových čísel).

-F

Použite súbor ako vstup pre výraz filtra. Ďalší príkaz uvedený na príkazovom riadku sa ignoruje.

-i

Počúvajte na rozhraní . Pokiaľ nie je špecifikovaný, tcpdump vyhľadáva zoznam systémových rozhraní pre najnižšie očíslované rozhranie (s výnimkou spätnej väzby). Väzby sa prerušujú výberom najskoršieho zápasu.

V systéme Linux s 2.2 alebo novším jadrom sa môže na zachytenie paketov zo všetkých rozhraní použiť argument rozhrania `` any ''. Všimnite si, že zachytávanie na zariadení `` any '' nebude vykonané v promiskuitnom režime.

-l

Vytvorte buffered stdout line. Užitočné, ak chcete zobraziť údaje počas ich zachytenia. Eg,
`` tcpdump -l | tee dat '' alebo `` tcpdump -l> data & tail -f dat ''.

-m

Načítajte definície modulov SMI MIB zo súborového modulu . Táto možnosť sa môže použiť niekoľkokrát na načítanie niekoľkých MIB modulov do tcpdump .

-n

Nekonvertujte hostiteľské adresy na mená. To sa môže použiť na vyhnutie vyhľadávaniu DNS.

-NN

Neprekonvertujte čísla protokolov a portov atď. Na mená.

-N

Nevytlačte názvy hostiteľských názvov domén. Napríklad, ak zadáte tento príznak, potom tcpdump vytlačí `` nic '' namiesto `` nic.ddn.mil ''.

-O

Nepoužívajte optimalizátor kódov zodpovedajúci paketom. Toto je užitočné iba vtedy, ak máte podozrenie na chybu v optimalizátore.

-p

Neukladajte rozhranie do promiskuitného režimu. Všimnite si, že rozhranie môže byť z iného dôvodu v promiskuitnom režime; preto "-p" nemôže byť použitý ako skratka pre "éter hostiteľa {local-hw-addr} alebo ethernet vysielanie".

-q

Rýchly (tichý?) Výstup. Tlačte menej protokolových informácií, takže výstupné riadky sú kratšie.

-R

Predpokladajme, že pakety ESP / AH budú založené na starých špecifikáciách (RFC1825 až RFC1829). Ak je zadané, tcpdump nebude vytlačiť pole prevencie opakovania. Pretože v špecifikácii ESP / AH neexistuje žiadne pole verzie protokolu, tcpdump nemôže odvodiť verziu protokolu ESP / AH.

-r

Prečítajte si pakety zo súboru (ktorý bol vytvorený s voľbou -w). Štandardný vstup sa používa, ak je súbor `` - ''.

-S

Tlačte absolútne, skôr než relatívne, poradové čísla TCP.

-s

Snarf skopíroval bajty dát z každého paketu namiesto predvoleného 68 (s SunOS NIT, minimálne je v skutočnosti 96). 68 bajtov je primerané pre protokoly IP, ICMP, TCP a UDP, ale môže skrátiť protokolové informácie z paketov mena servera a NFS (pozri nižšie). Pakety zrezané kvôli obmedzenému snímku sú na výstupe označené znakom `` [ proto ] '', kde proto je názov úrovne protokolu, pri ktorej došlo ku skracovaniu. Upozorňujeme, že pri snímaní väčších snímok sa zvyšuje čas potrebný na spracovanie paketov a efektívne znižuje množstvo vyrovnávacej pamäte paketov. To môže spôsobiť stratu paketov. Mali by ste obmedziť nastavenie na najmenšie číslo, ktoré bude zachytiť informácie o protokole, ktoré vás zaujímajú. Nastavenie na 0 znamená použitie požadovanej dĺžky na chytenie celých paketov.

-T

Vynútené pakety vybrané podľa výrazu sa interpretujú s uvedeným typom . V súčasnosti sú známe typy cnfp (protokol Cisco NetFlow), rpc (Remote Procedure Call), rtp (protokol aplikácií v reálnom čase), rtcp (riadiaci protokol aplikácií v reálnom čase), snmp (Simple Network Management Protocol) ) a wb (distribuovaná biela tabuľa).

-t

Na každú skládku nevytlačte časovú pečiatku.

-TT

Tlačte neformátovanú časovú pečiatku na každú výpisovú linku.

-U

Odoberá práva root a zmení ID používateľa na ID používateľa a skupiny na primárnu skupinu používateľov .

Poznámka! Red Hat Linux automaticky odoberie privilégiá užívateľovi `` pcap '', ak nie je špecifikované nič iné.

-ttt

Vytlačte deltu (v mikrosekundách) medzi aktuálnym a predchádzajúcim riadkom na každom výpisovom línii.

-tttt

Vytlačte časovú pečiatku vo východiskovom formáte a postupujte podľa dátumu na každom výpisovom línii.

-u

Vytlačiť nekódované úchyty NFS.

-v

(Trochu viac) podrobný výstup. Napríklad sa vytlačí čas na prežitie, identifikácia, celková dĺžka a možnosti v paketoch IP. Tiež umožňuje ďalšie kontroly integrity paketov, ako napríklad overenie kontrolného súčtu hlavičky IP a ICMP.

-vv

Ešte viac podrobný výstup. Napríklad sú vytlačené ďalšie polia z paketov odpovede NFS a pakety SMB sú plne dekódované.

-vvv

Ešte viac podrobný výstup. Napríklad možnosti telnet SB ... SE sú vytlačené úplne. S možnosťami -X telnet sú vytlačené aj hexadecimálne.

-w

Napíšte surové pakety do súboru , než ich analyzovať a vytlačiť. Neskôr sa môžu vytlačiť pomocou možnosti -r. Štandardný výstup sa používa, ak je súbor `` - ''.

-X

Vytlačte každý paket (mínus jeho záhlavie úrovne odkazu) v šestnástku. Zobrazí sa menšie množstvo paketu alebo bajtov. Všimnite si, že ide o celý paket s odkazovou vrstvou, takže pre vrstvy odkazov, ktoré obsahujú pad (napr. Ethernet), sa budú vytlačené aj bajtky výplne, keď je paket s vyššou vrstvou kratší ako požadované polstrovanie.

-X

Pri tlači hex, vytlačte tiež ascii. Ak sa teda nastaví aj -x , paket sa vytlačí v hex / ascii. To je veľmi užitočné pri analýze nových protokolov. Aj keď -x nie je tiež nastavený, niektoré časti niektorých paketov môžu byť vytlačené v hex / ascii.

vyjadrenie

vyberie, ktoré pakety budú zaťažené. Ak nie je uvedený žiadny výraz , všetky pakety na sieti budú zlikvidované. V opačnom prípade budú zaťažené iba pakety, ktorých výraz je "true".

Výraz pozostáva z jedného alebo viacerých primitívnych prvkov. Primitives obvykle pozostávajú z id (mena alebo čísla), ktorému predchádza jedna alebo viacero kvalifikátorov. Existujú tri rôzne druhy kvalifikácie:

typ

Kvalifikátori hovoria, na akú vec sa uvádza meno alebo číslo id. Možné typy sú hostiteľ , sieť a port . Napríklad "host foo", "net 128.3", "port 20". Ak neexistuje kvalifikátor typu, predpokladá sa hostiteľ .

dir

kvalifikátori špecifikujú konkrétny smer prevodu do a / alebo z id . Možné smery sú src , dst , src alebo dst a src a dst . Napríklad `src foo ',` dst net 128.3', `src alebo dst port ftp-data '. Ak neexistuje žiadny kvalifikátor dir, predpokladá sa src alebo dst . Pre nulové vrstvy odkazov (tj protokoly z bodu na bod, ako je skĺznutie) sa na určenie požadovaného smeru môžu použiť vstupné a výstupné kvalifikácie.

preto

Kvalifikátory obmedzujú zápas na určitý protokol. Možné protóly sú: ether , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp a udp . Napríklad `ether src foo ',` arp net 128.3', `tcp port 21 '. Ak neexistuje žiadna kvalifikácia proto, predpokladajú sa všetky protokoly v súlade s typom. Napríklad `src foo 'znamená` (ip alebo arp alebo rarp) src foo' (okrem toho, že posledná nie je právna syntax), `net bar 'znamená` net (ip alebo arp alebo rarp) net' `(tcp alebo udp) port 53 '.

["fddi" je vlastne alias pre "éter"; analyzátor ich zaobchádza rovnako ako to, čo znamená "úroveň dátového spojenia použitá na určenom sieťovom rozhraní." Hlavičky FDDI obsahujú adresy zdrojového a cieľového typu ako Ethernet a často obsahujú typy paketov typu Ethernet, takže môžete filtrovať na týchto poliach FDDI rovnako ako pri podobných poliach Ethernet. Záhlavia FDDI obsahujú aj iné polia, ale nemôžete ich výslovne uviesť vo výraze filtra.

Podobne, `tr 'je alias pre" éter "; vyhlásenia predchádzajúceho odseku o hlavičkách FDDI sa vzťahujú aj na hlavičky Token Ring.]

Okrem vyššie uvedených existuje niekoľko špeciálnych "primitívnych" kľúčových slov, ktoré nevyhovujú vzoru: brána , vysielanie , menšie , väčšie a aritmetické výrazy. Všetky tieto sú popísané nižšie.

Zložitejšie výrazy filtrov sa vytvárajú pomocou slov a / alebo nie kombinovať primitívne prvky. Napríklad, `host foo a nie port ftp a nie port ftp-data '. Ak chcete uložiť písanie, môžu sa vynechať rovnaké zoznamy kvalifikátorov. Napríklad `tcp dst port ftp alebo ftp-data alebo doména 'je presne rovnaká ako` tcp dst port ftp alebo tcp dst port ftp-data alebo tcp dst port domain'.

Prípustné primitívne prvky sú:

dst hostiteľského hostiteľa

Skutočné, ak je cieľové pole IPv4 / v6 paketu hostiteľom , ktorým môže byť buď adresa, alebo názov.

src hosť hostiteľa

Skutočné, ak je zdrojové pole paketu IPv4 / v6 hostiteľom .

hosť hostiteľa

Je to pravda, ak je hostiteľom zdroj alebo cieľ IPv4 / v6. Ktorýkoľvek z vyššie uvedených výrazov hostiteľa môže byť predbežný s kľúčovými slovami, ip , arp , rarp alebo ip6 ako v:

hostiteľa hostiteľa hostiteľa

čo je ekvivalent:

ether proto \ ip a hostiteľského hostiteľa

Ak je hostiteľ názov s viacerými adresami IP, každá adresa sa skontroluje zhoda.

éter dst ehost

Je pravda, ak je cieľová adresa ethernetu ehost . Ehost môže byť buď názov z / etc / ethers alebo číslo (pozri étery (3N) pre číselný formát).

éter src ehost

Je pravda, ak je zdrojová adresa ethernetu ehost .

éter hostiteľského hostiteľa

Je to pravda, ak je buď ethernetový zdroj alebo cieľová adresa ehost .

hostiteľa brány

Je pravda, ak paket používa hostiteľa ako bránu. Teda, zdroj alebo cieľová adresa ethernetu bola hostiteľom, ale ani zdroj IP ani cieľ IP neboli hostiteľom . Hostiteľ musí byť názov a musí byť nájdený tak mechanizmami rozlíšenia adresy hostiteľa-meno-IP-IP (názov hostiteľa, DNS, NIS atď.) A rozlíšenie adresy hostiteľa-na-Ethernet mechanizmus (/ etc / ethers atď.). (Ekvivalentný výraz je

ether hostiteľského hostiteľa a hostiteľského hostiteľa

ktorý sa môže použiť s názvami alebo číslami pre hostiteľa / ehost .) Táto syntax v tejto chvíli nefunguje v konfigurácii s podporou protokolu IPv6.

dst net net

Je pravda, ak cieľová adresa paketu IPv4 / v6 má sieťové číslo siete . Net môže byť buď názov z / etc / networks alebo číslo siete (podrobnosti nájdete v sieťach (4) ).

src čistá sieť

Je pravda, ak zdrojová adresa IPv4 / v6 paketu má sieťové číslo siete .

čistá čistá sieť

Je pravda, či zdrojová alebo cieľová adresa paketu IPv4 / v6 má sieťové číslo siete .

čistej masky sieťovej masky

Je pravda, ak sa adresa IP zhoduje s určitou sieťovou maskou . Môžu mať kvalifikáciu pomocou src alebo dst . Všimnite si, že táto syntax nie je platná pre sieť IPv6.

čistá čistá / len

Je to pravda, ak sa adresa IPv4 / v6 zhoduje s čistou sieťovou maskou s plochými maskami . Môžu mať kvalifikáciu pomocou src alebo dst .

dst port port

Je pravda, ak je paket ip / tcp, ip / udp, ip6 / tcp alebo ip6 / udp a má cieľovú hodnotu portu portu . Port môže byť číslo alebo názov používaný v / etc / services (pozri tcp (4P) a udp (4P)). Ak sa používa názov, skontroluje sa číslo portu aj protokol. Ak sa používa číselný alebo nejednoznačný názov, je začiarknuté iba číslo portu (napr. Dst port 513 vytlačí návštevnosť tcp / login a návštevnosť udp / who a portová doména budú tlačiť návštevnosť tcp / domain a udp / domain).

port portu src

Je pravda, ak má paket hodnotu portového portu .

port port

Je pravda, či je zdrojový alebo cieľový port paketu port . Ktorýkoľvek z vyššie uvedených výrazov portov môže byť predbežný s kľúčovými slovami tcp alebo udp ako v:

port portu tcp src

ktorý zodpovedá iba paketom tcp, ktorých zdrojový port je port .

menej dĺžky

Je pravda, ak má paket dĺžku menšiu alebo rovnú dĺžke . To zodpovedá:

len <= dĺžka .

väčšiu dĺžku

Je pravda, ak má paket dĺžku väčšiu alebo rovnú dĺžke . To zodpovedá:

len> = dĺžka .

ip proto protokol

Je pravda, ak je paket IP paketom (pozri ip (4P)) protokolového protokolu . Protokol môže byť číslo alebo jedno z názvov icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp alebo tcp . Všimnite si, že identifikátory tcp , udp a icmp sú tiež kľúčové slová a musia uniknúť pomocou spätného lomítka (\), ktoré je \\ v C-shelle. Všimnite si, že tento primitív nesleduje reťazec hlavičky protokolu.

protokol ip6 proto

Je pravda, ak je paket protokolom protokolu protokolu IPv6. Všimnite si, že tento primitív nesleduje reťazec hlavičky protokolu.

protokolu protokolov protokolu ip6

Je pravda, ak je paket paketom IPv6 a obsahuje hlavičku protokolu s typovým protokolom v reťazci hlavičky protokolu. Napríklad,

ip6 protchain 6

zodpovedá akémukoľvek paketu protokolu IPv6 s hlavičkou protokolu TCP v reťazci hlavičky protokolu. Paket môže obsahovať napríklad záhlavie autentifikácie, záhlavie smerovania alebo záhlavie voľby hop-by-hop medzi záhlavím IPv6 a hlavičkou TCP. BPF kód vysielaný týmto primitívom je zložitý a nemôže byť optimalizovaný kódom optimalizácie BPF v tcpdump , takže to môže byť trochu pomalé.

protokol protokol ip

Rovnocenný s protokolom protokolov protokolu ip6 , ale je to pre protokol IPv4.

éterového vysielania

Je pravda, ak je paket ethernetový vysielací paket. Kmeňové slovo éteru je voliteľné.

ip vysielanie

Je pravda, ak je paket vysielaný paketom IP. Kontroluje tak konvencie vysielania všetkých núl a all-one a vyhľadáva lokálnu masku podsiete.

éter multicast

Je pravda, ak je paket ethernetový multicastový paket. Kmeňové slovo éteru je voliteľné. Toto je skratka pre " éter [0] & 1! = 0 ".

IP multicast

Je pravda, ak je paket IP paketom multicast.

IP6 multicast

Je pravda, ak je paket paketom multicast IPv6.

éter protokol

Je pravda, ak je paket typu éterického protokolu . Protokol môže byť číslo alebo jedno z názvov ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx alebo netbeui . Upozorňujeme, že tieto identifikátory sú tiež kľúčové slová a musia uniknúť spätným lomikom (\).

[V prípade FDDI (napr. ` Fddi protocol arp ') a Token Ring ( napr.` Tr protocol arp ') pre väčšinu týchto protokolov identifikácia protokolu pochádza z hlavičky 802.2 Logical Link Control (LLC) je zvyčajne navrstvený nad hlavičkou FDDI alebo Token Ring.

Pri filtrovaní väčšiny identifikátorov protokolov na FDDI alebo Token Ring tcpdump kontroluje len pole ID protokolu v hlavičke LLC v takzvanom SNAP formáte s identifikátorom organizačnej jednotky (OUI) 0x000000 pre enkapsulovaný Ethernet; nekontroluje, či je paket vo formáte SNAP s OUI 0x000000.

Výnimky sú iso , pre ktoré kontroluje polia DSAP (Access Service Access Point) a SSAP (Source Service Access Point) v hlavičke LLC, stp a netbeui , kde kontroluje DSAP hlavičky LLC a atalk , kde kontroluje balík SNAP s OUI 0x080007 a typom Appletalk.

V prípade siete Ethernet tcpdump kontroluje pole typu Ethernet pre väčšinu týchto protokolov; výnimky sú iso , sap a netbeui , pre ktoré kontroluje rámček 802.3 a potom skontroluje záhlavie LLC tak, ako to robí pri FDDI a Token Ring, atalk , kde kontroluje ako etalón Appletalk v rámčeku Ethernet, tak aj pre SNAP ako v prípade FDDI a Token Ring, aarp , kde kontroluje typ príkazu Appletalk ARP v rámčeku Ethernet alebo 802.2 rám SNAP s OUI 0x000000 a ipx , kde kontroluje typ IPX v ethernetový rámec, IPX DSAP v hlavičke LLC, 802.3 bez zapuzdrenia hlavičky LLC IPX a IPX etype v ráme SNAP.]

hostiteľ decnet src

Je pravda, ak je zdrojovou adresou DECNET hostiteľ , čo môže byť adresa formulára `` 10.123 '' alebo názov hostiteľa DECNET. [Podpora názvu hostiteľa DECNET je dostupná iba v systémoch Ultrix, ktoré sú nakonfigurované na spustenie programu DECNET.]

decnet dst hostiteľa

Je pravda, ak je cieľová adresa DECNET hostiteľa .

hostiteľský počítač decnet

Skutočné, ak je hostiteľský zdroj alebo cieľová adresa DECNET.

ip , ip6 , arp , rarp , atalk , aarp , deknet , iso , stp , ipx , netbeui

Skratky pre:

éter protop

kde p je jeden z vyššie uvedených protokolov.

lat , moprc , mopdl

Skratky pre:

éter protop

kde p je jeden z vyššie uvedených protokolov. Všimnite si, že tcpdump momentálne nevie, ako analyzovať tieto protokoly.

vlan [vlan_id]

Je pravda, ak je paket VLAN paketom IEEE 802.1Q. Ak je zadané [vlan_id] , platí len to, že paket má špecifikovaný vlan_id . Všimnite si, že prvé kľúčové slovo vlan vyskytujúce sa vo výraze mení dekódovacie odchýlky pre zvyšok výrazu za predpokladu, že paket je VLAN paket.

tcp , udp , icmp

Skratky pre:

ip proto p alebo ip6 proto p

kde p je jeden z vyššie uvedených protokolov.

protokol iso proto

Je pravda, ak je paket OSI paketom protokolového protokolu . Protokol môže byť číslo alebo jeden z názvov clnp , esis alebo isis .

clnp , esis , isis

Skratky pre:

iso proto p

kde p je jeden z vyššie uvedených protokolov. Všimnite si, že tcpdump vykoná neúplnú prácu pri analýze týchto protokolov.

expr relop expr

Je to pravda, ak relatívny vzťah existuje , kde relop je jeden z>, <,> =, <=, = ,! =, A expr je aritmetický výraz zložený z celých konštánt (vyjadrený v štandardnej syntaxe C), normálne binárne operátory [ , -, *, /, &, |], operátor s dĺžkou a špeciálne paketové dátové príslušenstvo. Ak chcete pristupovať k dátam v pakte, použite nasledujúcu syntax:

proto [ expr : veľkosť ]

Proto je jedným z ether, fddi, tr, ppp, sklzu, odkazu, ip, arp, rarp, tcp, udp, icmp alebo ip6 a označuje protokolovú vrstvu pre indexovú operáciu. ( ether, fddi, tr, ppp, posun a prepojenie sa vzťahujú na vrstvu odkazu.) Všimnite si, že protokoly tcp, udp a iné typy protokolov vyššieho typu sa vzťahujú iba na protokol IPv4, nie na protokol IPv6 (to bude opravené v budúcnosti). Bajtový posun vzhľadom na indikovanú vrstvu protokolu je daný expr . Veľkosť je voliteľná a udáva počet bajtov v príslušnej oblasti. môže to byť jeden, dva alebo štyri a predvolené na jeden. Dĺžka operátora, označená kľúčovým slovom len , udáva dĺžku paketu.

Napríklad " éter [0] & 1! = 0 " zachytáva všetky multicastové prenosy. Výraz " ip [0] & 0xf! = 5 " zachycuje všetky IP pakety s možnosťami. Výraz " ip [6: 2] & 0x1fff = 0 " zachytáva iba nefragmentované datagramy a nulovú fragmentáciu fragmentovaných datagramov. Táto kontrola sa implicitne aplikuje na operácie indexu tcp a udp index. Napríklad tcp [0] vždy znamená prvý bajt hlavičky TCP a nikdy neznamená prvý bajt fragmentu zasahujúceho.

Niektoré odchýlky a hodnoty poľa môžu byť vyjadrené skôr ako mená než ako číselné hodnoty. K dispozícii sú nasledujúce posuny polí hlavičky protokolu: icmptype (pole typu ICMP), icmpcode (pole ICMP kódu) a tcpflags (pole TCP príznakov).

K dispozícii sú nasledujúce hodnoty polí typu ICMP : icmp-echoreply , icmp-unreach , icmp -sourcequench , icmp -redirect , icmp-echo , icmp-routeradvert , icmp -routersolicit , icmp -timxceed , icmp-paramprob , icmp-tstamp , icmp -tstampreply , icmp -ireq , icmp -ireqreply , icmp-maskreq , icmp-maskreply .

K dispozícii sú nasledujúce hodnoty poľa TCP príznakov: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .

Primitivy sa môžu kombinovať pomocou:

Začiarknutá skupina primitivov a operátorov (zátvorky sú špeciálne pre Shell a musia uniknúť).

Negation (` ! 'Alebo` nie ').

Zlučovanie (" && " alebo " a ").

Striedanie (` || 'alebo` alebo ').

Negácia má najvyššiu prioritu. Striedanie a zlúčenie majú rovnakú prioritu a pridružujú sa zľava doprava. Všimnite si, že explicitné a žetóny, nie juxtapozícia, sú teraz potrebné pre zjednotenie.

Ak je identifikátor uvedený bez kľúčového slova, predpokladá sa najnovšie kľúčové slovo. Napríklad,

nie hostiteľ vs a eso

je skratka pre

nie hostiteľské a hostiteľské eso

s ktorými sa nemožno zamieňať

nie (hostiteľské alebo eso)

Argumenty výrazov môžu byť prenesené na tcpdump buď ako jeden argument, alebo ako viaceré argumenty, podľa toho, čo je výhodnejšie. Vo všeobecnosti, ak výraz obsahuje Shell metacharacters, je ľahšie ju odovzdať ako jediný, citovaný argument. Viaceré argumenty sú skombinované s medzerami pred analýzou.

PRÍKLADY

Ak chcete vytlačiť všetky pakety, ktoré prichádzajú alebo odchádzajú z západu slnka :

tcpdump hosťujúci západ slnka

Ak chcete vytlačiť dopravu medzi heliom a horúcim alebo esom :

tcpdump hosť helios a \ (horúce alebo eso \)

Ak chcete vytlačiť všetky pakety IP medzi esom a ľubovoľným hostiteľom s výnimkou helií :

tcpdump ip hostiteľa ace a nie helios

Ak chcete vytlačiť všetku návštevnosť medzi miestnymi hostiteľmi a hostiteľmi v Berkeley:

tcpdump net ucb-éter

Ak chcete vytlačiť všetok prenos ftp prostredníctvom snapu internetovej brány: (všimnite si, že výraz je citovaný, aby sa zabránilo chybnému interpretácii obálok ):

tcpdump 'a (port ftp alebo ftp-data)'

Ak chcete vytlačiť návštevnosť, ktorá nie je získaná ani určená pre lokálnych hostiteľov (ak ste brána k jednej inej sieti, tieto veci by ste nikdy nemali urobiť na vašu lokálnu sieť).

tcpdump ip a netnet localnet

Vytlačiť začiatočné a koncové pakety (pakety SYN a FIN) každej konverzácie TCP, ktorá zahŕňa hostiteľa, ktorý nie je lokálny.

tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0 a nie src a dst net localnet '

Ak chcete vytlačiť IP pakety dlhšie ako 576 bajtov poslaných cez modul snap :

tcpdump 'snap a ip [2: 2]> 576'

Ak chcete vytlačiť pakety IP vysielania alebo multicast, ktoré neboli odoslané cez ethernetové vysielanie alebo multicast:

tcpdump éter [0] & 1 = 0 a ip [16]> = 224 '

Ak chcete vytlačiť všetky pakety ICMP, ktoré nie sú požiadavkami / odpoveďami echo (tj nie ping pakety):

tcpdump 'icmp [icmptype]! = icmp-echo a icmp [icmptype]! = icmp-echoreply'

VÝSTUPNÝ FORMÁT

Výstup tcpdump závisí od protokolu. Nasleduje stručný opis a príklady väčšiny formátov.

Hlavičky úrovne prepojenia

Ak je zadaná voľba "-e", vytlačí sa hlavička úrovne odkazu. Na e-mailoch sa vytlačia zdrojové a cieľové adresy, protokol a dĺžka paketu.

V sieťach FDDI spôsobí voľba "-e" príkaz tcpdump vytlačiť pole "riadenie rámca", zdrojové a cieľové adresy a dĺžku paketu. (Pásma "control frame" riadia interpretáciu zvyšku paketu Normálne pakety (napríklad tie, ktoré obsahujú IP datagramy) sú pakety async s prioritnou hodnotou medzi 0 a 7, napríklad async4 . Predpokladá sa, že pakety obsahujú paket 802.2 Logic Link Control (LLC), hlavička LLC sa vytlačí, ak nie je datagram ISO alebo takzvaný SNAP paket.

Na sieťach Token Ring voľba "-e" spôsobuje, že tcpdump vytlačí polia `control access 'a` control frame', zdrojové a cieľové adresy a dĺžku paketu. Podobne ako v prípade sietí FDDI sa predpokladá, že pakety obsahujú paket LLC. Bez ohľadu na to, či je špecifikovaná voľba "-e" alebo nie, informácie o smerovaní zdroja sú vytlačené pre pakety smerované zdrojmi.

(Poznámka: Nasledujúci popis predpokladá znalosť SLIP kompresného algoritmu opísaného v dokumente RFC-1144.)

Na odkazoch SLIP sa vytlačí smerový indikátor ("I" pre prichádzajúce, "O" pre odchádzajúce), typ paketu a informácie o kompresii. Typ paketu sa vytlačí ako prvý. Tri typy sú ip , utcp a ctcp . Pre IP pakety nie sú vytlačené žiadne ďalšie informácie o prepojení. V prípade paketov TCP sa identifikátor spojenia vytlačí podľa typu. Ak je paket komprimovaný, vytiahne sa jeho zakódovaná hlavička. Špeciálne prípady sú vytlačené ako * S + n a * SA + n , kde n je množstvo, ktorým sa zmenilo poradové číslo (alebo poradové číslo a ack). Ak to nie je špeciálny prípad, tlačia sa nula alebo viac zmien. Zmena je označená symbolom U (urgentný ukazovateľ), W (okno), A (ack), S (poradové číslo) a I (ID paketu), za ktorým nasleduje delta (+ n alebo -n) (= N). Nakoniec sa vytlačí množstvo dát v paketovej a stlačenej hlavičke.

Napríklad nasledujúci riadok zobrazuje odchádzajúci komprimovaný paket TCP s implicitným identifikátorom spojenia; akč sa zmenil o 6, poradové číslo o 49 a ID paketu o 6; existujú 3 bajty dát a 6 bajtov komprimovanej hlavičky:

O ctcp * A + 6 S + 49 I + 6 3 (6)

ARP / RARP pakety

Výstup Arp / rarp zobrazuje typ požiadavky a jej argumenty. Formát je určený na vysvetlenie. Tu je krátka vzorka odobratá od začiatku "rlogin" z hostiteľa rtsg do hostiteľa csam :

arp, ktorý má csam povedať rtsg arp odpoveď csam je v CSAM

Prvý riadok hovorí, že rtsg poslal arp paket s dotazom na ethernetovú adresu internetového hostiteľa csam. Csam odpovie svojou ethernetovou adresou (v tomto príklade sú ethernetové adresy v malých písmenách s čiarami a internetovými adresami).

Toto by vyzeralo menej redundantné, keby sme urobili tcpdump -n :

arp kto má 128.3.254.6 povedať 128.3.254.68 arp odpoveď 128.3.254.6 je na 02: 07: 01: 00: 01: c4

Keby sme urobili tcpdump -e , je viditeľná skutočnosť, že prvý paket je vysielaný a druhý je bod-to-point:

RTSG Broadcast 0806 64: arp ktorý má csam tell rtsg CSAM RTSG 0806 64: arp odpoveď csam je na CSAM

Pre prvý paket to hovorí, že zdrojová adresa ethernetu je RTSG, cieľová adresa je adresa vysielania ethernetu, pole typu obsahovalo hex 0806 (typ ETHER_ARP) a celková dĺžka bola 64 bajtov.

TCP pakety

(Poznámka: Nasledujúci popis predpokladá oboznámenie sa s protokolom TCP popísaným v RFC-793. Ak nie ste oboznámení s týmto protokolom, ani tento popis, ani tcpdump nebudú pre vás veľa dôležité.)

Všeobecný formát linky protokolu tcp je:

src> dst: Flags data-seqno ack okno naliehavé možnosti

Src a dst sú zdrojové a cieľové adresy IP a porty. Vlajky sú nejakou kombináciou S (SYN), F (FIN), P (PUSH) alebo R (RST) alebo jednej "." (žiadne vlajky). Data-seqno popisuje časť sekvenčného priestoru pokrytého údajmi v tomto pakte (pozri príklad nižšie). Ack je poradové číslo ďalších údajov, ktoré sa očakávajú v inom smere na tomto spojení. Okienko je počet bajtov prijímaného vyrovnávacieho priestoru, ktorý je k dispozícii v druhom smere na tomto pripojení. Urg naznačuje, že v pakte sú "naliehavé" dáta. Možnosti sú možnosti tcp uzavreté v uhlových zátvorkách (napr. ).

Src, dst a vlajky sú vždy prítomné. Ostatné polia závisia od obsahu hlavičky protokolov tcp paketu a sú výstupné len v prípade potreby.

Tu je úvodná časť rloginu z hostiteľa rtsg do hostiteľa csam .

rtsg.1023> csam.login: S 768512: 768512 (0) vyhrať 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 vyhrať 4096 rtsg.1023> csam. Prihlásiť sa: . ack 1 win 4096 rtsg.1023> csam.login: P 1: 2 (1) ack 1 win 4096 csam.login> rtsg.1023:. ack 2 win 4096 rtsg.1023> csam.login: P 2:21 (19) ack 1 win 4096 csam.login> rtsg.1023: P 1: 2 (1) ack 21 win 4077 csam.login> rtsg.1023: P 2: 3 (1) ack 21 vyhrať 4077 urg 1 csam.login> rtsg.1023: P 3: 4 (1) ack 21 vyhrať 4077 urg 1

Prvý riadok hovorí, že tcp port 1023 na rtsg poslal balík na prihlásenie do portu na csam. S označuje, že bol nastavený príznak SYN . Číslo sekvencie paketu bolo 768512 a neobsahovalo žiadne údaje. (Označenie je "prvé: posledné (nbytes)", čo znamená " najprv počiatočné čísla sekvencií, ale nie posledné, čo je nbytes bajtov užívateľských údajov".) Neexistovala žiadna záložka, existuje možnosť maximálneho segmentu, ktorá požaduje mss 1024 bajtov.

Csam odpovedá s podobným paketom, okrem toho, že obsahuje akvizíciu pre prasiatko pre SYN pre rtsg. Rtsg potom acks csam SYN. Funkcia `. ' znamená, že neboli nastavené žiadne vlajky. Paket neobsahoval žiadne údaje, takže neexistuje žiadne poradové číslo. Všimnite si, že poradové číslo ack je malé celé číslo (1). Prvýkrát, keď tcpdump vidí tcp `conversation ', vytlačí sekvenčné číslo z paketu. V nasledujúcich paketoch konverzácie sa vytlačí rozdiel medzi poradovým číslom súčasného paketu a týmto počiatočným poradovým číslom. To znamená, že poradové čísla po prvom môžu byť interpretované ako relatívne bajtové pozície v dátovom toku konverzácie (s prvým dátovým bajtom v každom smere je "1"). `-S 'túto funkciu prepíše, čím sa vygenerujú pôvodné sekvenčné čísla.

Na 6. riadku rtsg posiela csam 19 bajtov dát (bajty 2 až 20 v rtsg -> csam strane konverzácie). Príznak PUSH je nastavený v pakte. Na siedmej línii csam hovorí, že je to prijaté dáta poslané rtsg až do, ale bez byte 21. Väčšina z týchto údajov je zjavne sedieť v socketovom bufferi, pretože okná prijímania csam získala 19 bajtov menšia. Csam tiež posiela jeden bajt dát do rtsg v tomto balíku. Na 8. a 9. riadku posiela csam dva bajty naliehavých, posunutých dát na rtsg.

Ak bol snímok dostatočne malý na to, aby tcpdump nezachytil úplnú hlavičku TCP, interpretuje toľko hlavičky, ako je to možné, a potom hlási `` [| tcp ] '' na označenie zvyšku nemožno interpretovať. Ak hlavička obsahuje falošnú možnosť (jedna s dĺžkou, ktorá je buď príliš malá, alebo za koniec záhlavia), tcpdump ju hlási ako `` [ bad opt ] '' a nevytvára žiadne ďalšie možnosti (pretože to nie je možné povedať kde začínajú). Ak dĺžka hlavičky naznačuje, že existujú možnosti, ale dĺžka IP datagramu nie je dostatočne dlhá na to, aby sa možnosti skutočne nachádzali, tcpdump to hlási ako `` [ bad hdr length ] ''.

Zachytávanie paketov TCP s konkrétnymi kombináciami príznakov (SYN-ACK, URG-ACK atď.)

V sekcii riadiacich bitov v hlavičke TCP je 8 bitov:

CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

Predpokladajme, že chceme sledovať pakety použité pri vytváraní TCP spojenia. Pripomeňme si, že pri inicializácii nového pripojenia TCP používa protokol 3-way handshake; sekvencia spojenia vzhľadom na riadiace bity TCP je

1) volajúci vyšle SYN

2) Príjemca reaguje pomocou SYN, ACK

3) volajúci vyšle ACK

Teraz máme záujem o zachytenie paketov, ktoré majú len sadu bitov SYN (krok 1). Všimnite si, že nechceme balíky z kroku 2 (SYN-ACK), len jednoduché počiatočné SYN. Potrebujeme správny filter pre tcpdump .

Vyvolanie štruktúry hlavičky TCP bez možností:

0 15 31 ----------------------------------------------- ------------------ zdrojový port | cieľový port | -------------------------------------------------- --------------- | poradové číslo | -------------------------------------------------- --------------- | číslo potvrdenia -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | veľkosť okna -------------------------------------------------- --------------- | Kontrolný súčet naliehavý ukazovateľ -------------------------------------------------- ---------------

Záhlavie TCP zvyčajne obsahuje 20 oktetov údajov, pokiaľ nie sú k dispozícii možnosti. Prvý riadok grafu obsahuje oktety 0 - 3, druhý riadok zobrazuje oktety 4 - 7 atď.

Začínajúc počítať s 0, príslušné bity riadenia TCP sú obsiahnuté v oktete 13:

0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | veľkosť okna ---------------- | --------------- | --------------- | - --------------- | | 13. oktet | | |

Pozrime sa bližšie na oktet nie. 13:

| | | --------------- | | C | e | U | A | P | R | S | F | | --------------- | 7 5 3 0 |

Toto sú bity riadenia TCP, o ktoré máme záujem. Číslice bitov v tomto oktete sme číslovali od 0 do 7, zľava doľava, takže bit PSH je bit číslo 3, zatiaľ čo bit URG je číslo 5.

Pripomeňme si, že chceme zachytiť pakety len so súbormi SYN. Pozrime sa, čo sa stane s oktetou 13, ak príde TCP datagrama s nastaveným bitom SYN v hlavičke:

| C | e | U | A | P | R | S | F | | --------------- | 0 0 0 0 0 0 1 0 | --------------- | 7 6 5 4 3 2 1 0 |

Pri pohľade na sekciu riadiacich bitov vidíme, že je nastavené len číslo 1 (SYN).

Za predpokladu, že oktetové číslo 13 je 8-bitové nepodpísané celé číslo v poradí sieťového bytu, binárna hodnota tohto oktetu je

00000010

a jeho desatinné reprezentácie

7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2

Už sme takmer hotoví, pretože teraz vieme, že ak je nastavený iba SYN, hodnota 13 oktetov v hlavičke TCP, keď je interpretovaná ako 8-bitové nepodpísané celé číslo v poradí sieťového bytu, musí byť presne 2.

Tento vzťah sa môže vyjadriť ako

tcp [13] == 2

Tento výraz môžeme použiť ako filter pre tcpdump, aby sme mohli sledovať pakety, ktoré majú len SYN nastavenú hodnotu:

tcpdump -i xl0 tcp [13] == 2

Výraz hovorí: "nechajte 13. oktet TCP datagramu desatinnú hodnotu 2", čo je presne to, čo chceme.

Teraz predpokladajme, že potrebujeme zachytiť SYN pakety, ale je nám jedno, či je súčasne nastavený ACK alebo iný riadiaci bit TCP. Pozrime sa, čo sa stane s oktetom 13, keď príde TCP datagram s príkazom SYN-ACK:

| C | e | U | A | P | R | S | F | | --------------- | 0 0 0 1 0 0 1 0 | --------------- | 7 6 5 4 3 2 1 0 |

Teraz sú bity 1 a 4 nastavené v 13. oktete. Binárna hodnota oktetu 13 je

00010010

ktorý sa prekladá na desatinnú

7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 18

Teraz nemôžeme v tcpdump filter použiť 'tcp [13] == 18', pretože by sa vybrali iba tie pakety, ktoré majú nastavenú hodnotu SYN-ACK, ale nie tie, ktoré majú iba SYN nastavenú hodnotu. Pamätajte, že je nám jedno, či je ACK alebo iný riadiaci bit nastavený tak dlho, ako je nastavené SYN.

Aby sme dosiahli náš cieľ, potrebujeme logicky a binárnu hodnotu oktetu 13 s nejakou inou hodnotou na zachovanie SYN bitu. Vieme, že chceme, aby bol SYN nastavený v každom prípade, takže logicky A bude hodnota v 13. oktete s binárnou hodnotou SYN:

00010010 SYN-ACK 00000010 SYN A 00000010 (chceme SYN) A 00000010 (chceme SYN) -------- -------- = 00000010 = 00000010

Vidíme, že táto operácia AND prináša rovnaký výsledok bez ohľadu na to, či je nastavený ACK alebo iný riadiaci bit TCP. Desatinné zobrazenie hodnoty AND, ako aj výsledok tejto operácie je 2 (binárne 00000010), takže vieme, že pre pakety s nastavením SYN musí platiť nasledujúci vzťah:

((hodnota octetu 13) A (2)) == (2)

To poukazuje na výraz tcpdump filter

tcpdump -i xl0 'tcp [13] & 2 == 2'

Všimnite si, že by ste mali používať jednoduché úvodzovky alebo spätné lomítko, aby ste skryli špeciálny znak AND ('&').

UDP pakety

Formát UDP je ilustrovaný týmto paketom rwho:

aktinide.who> vysielanie.who: udp 84

To hovorí, že port, ktorý na hostiteľskom aktinide poslal udg datagram do portu, ktorý na hostiteľskom vysielaní , internetovú adresu vysielania. Paket obsahoval 84 bajtov používateľských údajov.

Niektoré služby protokolu UDP sa rozpoznávajú (z čísla zdroja alebo cieľa portu) a vytlačia sa informácie o protokole vyššej úrovne. Najmä žiadosti o služby doménového mena (RFC-1034/1035) a Sun RPC volania (RFC-1050) do NFS.

Žiadosti o názov servera UDP

(Poznámka: Nasledujúci popis predpokladá oboznámenie sa s protokolom Domain Service popísaný v dokumente RFC-1035.) Ak nie ste oboznámení s týmto protokolom, nasledujúci opis sa bude zobrazovať v gréčtine.)

Žiadosti mena servera sú naformátované ako

src> dst: id op? príznaky qtype qclass name (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

Hostiteľ h2opolo požiadal doménový server na helios o záznam adresy (qtype = A) priradený k názvu ucbvax.berkeley.edu. Identifikátor dotazu bol '3'. Znak "+" označuje požadovanú rekurziu . Dĺžka dotazu bola 37 bajtov, bez záhlaví protokolov UDP a IP. Operácia dotazu bola normálna, Query , takže pole op bolo vynechané. Ak by opica bola niečo iné, bolo by to vytlačené medzi "3" a "+". Podobne, qclass bol normálny, C_IN a vynechal. Akékoľvek iné qclass by boli vytlačené bezprostredne po "A".

Niekoľko anomálií je skontrolovaných a môže to mať za následok zaradenie ďalších polí do hranatých zátvoriek: Ak dotaz obsahuje odpoveď, záznamy o autoritách alebo ďalšie záznamy, ankount , nscount alebo arcount sú vytlačené ako `[ n a] ',` [ n n ] alebo "[ n au]", kde n je príslušný počet. Ak je nastavený ktorýkoľvek z bitov odpovede (AA, RA alebo rcode), alebo akékoľvek bity `musia byť nulové 'sú nastavené v bajtoch dva a tri, vytlačí sa` [b2 & 3 = x ]', kde x je hexadecimálna hodnota hlavičky dvoch a troch.

Odpovede na názov servera UDP

Odpovede mena servera sú naformátované ako

src> dst: id op rcode príznaky a / n / au údaje o triedach (len) helios.domena> h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domena> h2opolo.1537: 2 NXDomain * 0/1/0 (97)

V prvom príklade helios odpovedá na otázku č. 3 z h2opolo s 3 záznamami odpovedí, 3 záznamami mena servera a 7 ďalšími záznamami. Prvým záznamom odpovedí je typ A (adresa) a jeho údaje sú internetová adresa 128.32.137.3. Celková veľkosť odpovede bola 273 bajtov, s výnimkou hlavičiek UDP a IP. Opis (dotaz) a kód odpovede (NoError) boli vynechané, rovnako ako trieda (C_IN) záznamu A.

V druhom príklade helios odpovedá na dotaz 2 s kódom odpovede neexistujúcej domény (NXDomain) bez odpovedí, jedného mena servera a žiadnych záznamov autority. Znak "*" označuje, že bol nastavený autoritatívny bit odpovede . Keďže neboli žiadne odpovede, nebol vytlačený žiadny typ, trieda ani údaje.

Ďalšie znaky vlajky, ktoré sa môžu zobraziť, sú `- '(dostupné rekurzia, RA, nenastavené) a` |' (skrátená správa, TC, nastavenie). Ak sekcia `otázka 'neobsahuje presne jeden záznam, vytlačí sa text [ n q].

Všimnite si, že žiadosti a odpovede na meno servera majú tendenciu byť veľké a predvolená veľkosť 68 bajtov nemusí zachytiť dostatok paketu na tlač. Použite príznak -s na zvýšenie rýchlosti, ak potrebujete vážne prešetriť návštevnosť mena servera. " 128 " fungovalo dobre pre mňa.

Dekódovanie SMB / CIFS

tcpdump teraz obsahuje pomerne rozsiahle dekódovanie SMB / CIFS / NBT pre dáta na UDP / 137, UDP / 138 a TCP / 139. Niektoré primitívne dekódovanie údajov IPX a NetBEUI SMB sa tiež vykonáva.

V predvolenom nastavení je vykonaná pomerne minimálna dekódovanie s oveľa podrobnejšou dekódovaním, ak sa použije -v. Upozorňujeme, že pomocou balíka -va jediného SMB môže zaberať nejakú stránku alebo viac, takže používajte len -v, ak naozaj chcete všetky kruté detaily.

Ak dekódujete relácie SMB obsahujúce reťazce typu unicode, potom by ste mohli nastaviť premennú prostredia USE_UNICODE na hodnotu 1. Je vhodné, aby bola nainštalovaná náplasť na automatické rozpoznávanie zväzkov unicode.

Informácie o formátoch paketov SMB a čo znamenajú všetky polia viz www.cifs.org alebo adresár pub / samba / specs / na vašom obľúbenom zrkadlenom webe samba.org. Záplaty SMB napísal Andrew Tridgell (tridge@samba.org).

Žiadosti a odpovede služby NFS

Požiadavky a odpovede Sun NFS (Network File System) sú vytlačené ako:

src.xid> dst.nfs: Len op args src.nfs> dst.xid: odpovedať stat len ​​op výsledky sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709: odpoveď ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 vyhľadávanie fh 9,74 / 4096.6878 "xcolors" wrl.nfs> sushi.201b: odpoveď ok 128 vyhľadávanie fh 9,74 / 4134,3150

V prvej línii hostiteľské sushi posiela transakciu s ID 6709 na adresu wrl (všimnite si, že číslo nasledujúce po hostiteľovi src je ID transakcie, nie zdrojový port). Požiadavka bola 112 bajtov, s výnimkou hlavičiek UDP a IP. Operácia bola readlink (čítanie symbolického odkazu) na rukoväti súboru ( fh ) 21,24 / 10,731657119. (Ak je človek šťastný, ako v tomto prípade môže byť zväzok interpretovaný ako veľký, malý pár číselných zariadení, po ktorom nasleduje inode číslo a generačné číslo.) Wrl odpovedá "ok" s obsahom odkazu.

V treťom riadku suši požiada WRL o vyhľadanie názvu " xcolors " v adresári 9,74 / 4096,6878. Upozorňujeme, že vytlačené údaje závisia od typu operácie. Formát je určený na vysvetlenie, ak je čítaný v spojení s špecifikáciou protokolu NFS.

Ak je zadaný príznak -v (verbose), vytlačia sa ďalšie informácie. Napríklad:

sushi.1372a> wrl.nfs: 148 čítať fh 21,11 / 12,195 8192 bytov @ 24576 wrl.nfs> sushi.1372a: odpovedať ok 1472 prečítať REG 100664 id 417/0 sz 29388

(-v tiež vytlačí polia hlavičky TTL, ID, dĺžky a fragmentácie, ktoré boli vynechané z tohto príkladu.) V prvom riadku sa sushi pýta, či má wrl čítať 8192 bajtov zo súboru 21,11 / 12,195 v offset bajtov 24576. Wrl odpovedá "ok"; paket uvedený na druhom riadku je prvým fragmentom odpovede a preto je dlhý len 1472 bajtov (ostatné bajty budú nasledovať v nasledujúcich fragmentoch, ale tieto fragmenty nemajú hlavičky NFS alebo dokonca UDP a tak sa nemusia vytlačiť, v závislosti od použitého výrazu filtra). Pretože príznak -v je uvedený, niektoré atribúty súboru (ktoré sa vrátia k údajom súboru) sú vytlačené: typ súboru (`` REG '' pre bežný súbor), režim súboru (v osmičke) uid a gid a veľkosť súboru.

Ak je príznak -v zadaný viackrát, tlačia sa ešte ďalšie podrobnosti.

Upozorňujeme, že žiadosti o NFS sú veľmi veľké a veľa detailov sa nebude vytlačiť, ak sa nezvýši rast. Pokúste sa použiť funkciu ` -s 192 'na sledovanie návštevnosti NFS.

Pakety odpovede služby NFS explicitne neurčujú operáciu RPC. Namiesto toho tcpdump sleduje "` najnovšie '' požiadavky a priraďuje ich k odpovediam pomocou ID transakcie. Ak odpoveď nezodpovedá príslušnej žiadosti, nemusí byť parsovateľná.

Žiadosti a odpovede AFS

Žiadosti a odpovede spoločnosti Transarc AFS (Andrew File System) sú vytlačené ako:

src.sport> dst.dport: rx paketový typ src.sport> dst.dport: rx paketový typ služby call call-name args src.sport> dst.dport: rx paketový typ služby call-name args elvis. 7001> pike.afsfs: rx dáta fs volanie premenovať starý fid 536876964/1/1 ".newsrc.new" nový fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx dáta fs odpoveď premenovať

V prvom riadku vysiela hostiteľský elvis balíček RX na šťuku. Bol to RX dátový paket pre službu fs (fileserver) a je začiatkom volania RPC. Volanie RPC bolo premenovanie so starým číslom adresára 536876964/1/1 a starým názvom súboru `.newsrc.new 'a novým ID adresára 536876964/1/1 a novým názvom súboru`. newsrc '. Šikmý hostiteľ odpovedá odpoveďou RPC na výzvu na premenovanie (čo bolo úspešné, pretože to bol dátový paket a nie paket prerušenia).

Vo všeobecnosti sú všetky RPC RPM AFS dekódované prinajmenšom pomocou volania RPC. Väčšina RPC RPC má aspoň niektoré argumenty dekódované (všeobecne len "zaujímavé" argumenty, niektoré definície sú zaujímavé).

Formát je určený na to, aby sa sám popisoval, ale pravdepodobne to nebude užitočné pre ľudí, ktorí nie sú oboznámení s fungovaním AFS a RX.

Ak je príznak -v (verbose) zadaný dvakrát, tlačia sa potvrdzovacie pakety a ďalšie informácie o hlavičke, ako je ID volajúceho RX, číslo hovoru, poradové číslo, sériové číslo a príznaky RX paketu.

Ak je príznak -v zadaný dvakrát, vytlačia sa ďalšie informácie, napríklad identifikátor RX hovoru, sériové číslo a príznaky paketu RX. Informácie o vyjednávaní MTU sú tiež vytlačené z paketov RX ack.

Ak je príznak -v uvedený trikrát, vytlačí sa bezpečnostný index a ID služby.

Chybové kódy sú vytlačené na zrušenie paketov, s výnimkou paketov Ubik beacon (pretože pakety prerušenia sa používajú na označenie hlasovania áno pre protokol Ubik).

Všimnite si, že požiadavky AFS sú veľmi veľké a mnohé z nich nebudú vytlačené, ak sa nezvýši rastlina . Pokúste sa použiť funkciu ` -s 256 'na sledovanie prevádzky služby AFS.

Pakety odpovedí AFS explicitne neidentifikujú operáciu RPC. Namiesto toho tcpdump sleduje "` najnovšie '' požiadavky a zodpovedá ich odpovediam pomocou čísla hovoru a ID služby. Ak odpoveď nezodpovedá príslušnej žiadosti, nemusí byť parsovateľná.

KIP Appletalk (DDP v UDP)

Pakety Appletalk DDP zapuzdrené v UDP datagramoch sú de-zapuzdrené a vyradené ako DDP pakety (tj všetky informácie hlavičky UDP sú zlikvidované). Súbor /etc/atalk.names sa používa na prekladanie sietí appletalk a názvov uzlov. Linky v tomto súbore majú formu

číslo názvu 1.254 éter 16.1 icsd-net 1.254.110 eso

Prvé dva riadky obsahujú názvy sietí appletalk. V treťom riadku sa uvádza názov konkrétneho hostiteľa (hostiteľ sa líši od siete o 3 octety v čísle - čisté číslo musí mať dva oktety a číslo hostiteľa musí mať tri oktety.) Číslo a meno by mali byť oddelené medzery (medzery alebo karty). Súbor /etc/atalk.names môže obsahovať prázdne riadky alebo riadky komentárov (čiary začínajúce znakom #).

Adresy Appletalk sú vytlačené vo forme:

net.host.port 144.1.209.2> icsd-net.112.220 office.2> icsd-net.112.220 jssmag.149.235> icsd-net.2

(Ak názov /etc/atalk.names neexistuje alebo neobsahuje záznam pre niektoré číslo appletalk hostiteľa / siete, adresy sa vytlačia v číselnej forme.) V prvom príklade je NBP (port DDP 2) na sieti 144.1 uzol 209 posiela na čokoľvek, čo počúva na portu 220 sieťového čipu 112. Druhý riadok je ten istý okrem toho, že je známy celý názov zdrojového uzla ("office"). Tretí riadok je posielanie z portu 235 na sieťovom jssmag uzle 149 na vysielanie na portu NBS icsd-net (všimnite si, že adresa vysielania (255) je označená čistým menom bez hostiteľského čísla - z tohto dôvodu je to dobrý nápad aby názvy uzlov a názvy sietí boli odlišné v /etc/atalk.names).

Protokoly NBP (name binding protocol) a pakety ATP (protokol transakcie protokolu Appletalk) majú interpretované ich obsahy. Ostatné protokoly stačí vynechať názov protokolu (alebo číslo, ak nie je zaregistrované žiadne meno pre protokol) a veľkosť paketu.

NBP pakety sú formátované podľa nasledujúcich príkladov:

icsd-net.112.220> jssmag.2: nbp-lkup 190: "=: LaserWriter @ *" jssmag.209.2> icsd-net.112.220: nbp-reply 190: "RM1140: LaserWriter @ *" 250 techpit.2> -net.112.220: nbp-odpoveď 190: "techpit: LaserWriter @ *" 186

Prvý riadok je žiadosť o vyhľadávanie názvov pre laserové tlačiarne odoslané sieťovým čítačom čiarových kódov 112 a vysielanie na sieti jssmag. Číslo nbp pre vyhľadávanie je 190. Druhý riadok zobrazuje odpoveď na túto požiadavku (poznamenajte si, že má rovnaký identifikátor) z hostiteľa jssmag.209, ktorý hovorí, že má zdroj laserového zápisu s názvom "RM1140" zaregistrovaný na portu 250. Tretí line je ďalšia odpoveď na tú istú požiadavku, ktorá hovorí, že hostiteľský techpit má laserwriter "techpit" registrovaný v portu 186.

Formátovanie paketov ATP je demonštrované nasledujúcim príkladom:

jssmag.209.165> helios.132: atp-req 12266 <0-7> 0xae030001 helios.132> jssmag.209.165: atp-resp 12266: 0 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 1 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 2 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 3 (512) 0xae040000 helios.132> jssmag.209.165: atp- resp. 12266: 4 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 5 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 6 (512) 0xae040000 helios.132> jssmag. 209.165: atp-resp * 12266: 7 (512) 0xae040000 jssmag.209.165> helio.132: atp-req 12266 <3,5> 0xae030001 helios.132> jssmag.209.165: atp-resp 12266: 3 (512) 0xae040000 helios .132> jssmag.209.165: atp-resp 12266: 5 (512) 0xae040000 jssmag.209.165> helios.132: atp-rel 12266 <0-7> 0xae030001 jssmag.209.133> helios.132: atp-req * 12267 <0 -7> 0xae030002

Jssmag.209 iniciuje transakciu id 12266 s hostiteľským heliom tým, že požiada o až 8 paketov (`<0-7> '). Hex číslo na konci riadku je hodnota poľa `userdata 'v žiadosti.

Helios reaguje na 8 512 bajtov. Hodnota `: digit 'nasledujúca po ID transakcie udáva poradové číslo paketu v transakcii a číslo v panech je množstvo dát v pakte okrem hlavičky atp. Písmeno `* 'na paket 7 označuje, že bol nastavený bit EOM.

Jssmag.209 potom požaduje, aby boli pakety 3 a 5 znovu vysielané. Helios ich znova odošle, potom jssmag.209 uvoľní transakciu. Nakoniec jssmag.209 iniciuje ďalšiu požiadavku. Písmeno "*" na žiadosť označuje, že XO ("presne raz") nebolo nastavené.

Fragmentácia IP

Roztrieštené internetové datagramy sú vytlačené ako

(fragment id : veľkosť @ offset +) (fragment id : veľkosť @ offset )

(Prvá forma označuje viac fragmentov, druhá označuje posledný fragment.)

Id je id fragmentu. Veľkosť je veľkosť fragmentu (v bajtoch) s výnimkou hlavičky IP. Odsadenie je kompenzovaný fragment (v bajtoch) v pôvodnom dátovom grafe.

Informácie o fragmentoch sú výstupné pre každý fragment. Prvý fragment obsahuje hlavičku protokolov vyššej úrovne a informácia o fragmentoch sa vytlačí za informáciami o protokole. Úlomky po prvom neobsahujú žiadnu hlavičku protokolov vyššej úrovne a informácie o fragmentoch sa vytlačia po zdrojových a cieľových adresách. Napríklad tu je časť ftp z arizona.edu do lbl-rtsg.arpa cez pripojenie CSNET, ktoré sa nezdá, že spracováva 576 byte datagramy:

arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 víťaz 4096 (fragment 595a: 328 ° 0 +) arizona> rtsg: (fragment 595a: 204 @ 328) rtsg.1170> arizona.ftp-data:. ack 1536 vyhrať 2560

Tu je niekoľko vecí, ktoré je potrebné poznamenať tu: Po prvé, adresy v 2. riadku nezahŕňajú čísla portov. Je to preto, lebo informácie protokolu protokolu TCP sú v prvom fragmente a my netušíme, aké sú čísla portov alebo sekvencií, keď vytlačíme neskoršie fragmenty. Po druhé, informácie o sekvencii tcp v prvom riadku sú vytlačené tak, akoby boli 308 bajtov užívateľských údajov, keď v skutočnosti existuje 512 bajtov (308 v prvom fragmente a 204 v druhom). Ak hľadáte otvory v priestore sekvencií alebo sa snažíte zosúladiť akcie s paketmi, môže vás to oklamať.

Paket s príznakom IP nie je príznak fragmentu označený koncovým (DF) .

časové pečiatky

V predvolenom nastavení pred všetky výstupné riadky je časová pečiatka. Časové označenie je aktuálny čas hodín vo formulári

hh: mm: ss.frac

a je tak presný ako hodiny jadra. Časová značka odzrkadľuje čas, kedy jadro prvýkrát videlo paket. Nevykonáva sa žiadny pokus o zohľadnenie časového oneskorenia medzi tým, kedy ethernetové rozhranie odstránilo paket z drôtu a keď jadro opravilo prerušenie "nového paketu".

POZRI TIEŽ

doprava (1C), nit (4P), bpf (4), pcap (3)

Dôležité: Pomocou príkazu man ( % man ) môžete zistiť, ako sa príkaz používa vo vašom konkrétnom počítači.