Tcpdump - příkaz Linux - příkaz Unix

NÁZEV

tcpdump - skládání provozu v síti

SYNOPSE

tcpdump [ -deflnNOpqRStuvxX ] [ -c počet ]

[ -C velikost souboru ] [ soubor F ]

[ -i rozhraní ] [ -m modul ] [ -r soubor ]

[ -s snaplen ] [ -T typ ] [ -U uživatel ] [ -w soubor ]

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

POPIS

Tcpdump vytiskne záhlaví paketů na síťovém rozhraní, které odpovídá výrazu boolean. Může být také spuštěn s příznakem -w , který způsobí, že uloží paketová data do souboru pro pozdější analýzu a / nebo s příznakem -r , což způsobí, že se přečte ze uloženého paketového souboru namísto čtení paketů ze síťového rozhraní. Ve všech případech budou pakety tcpdump zpracovávány pouze pakety odpovídající výrazu .

Tcpdump , pokud není spuštěn s příznakem -c , pokračuje v zachycování paketů, dokud není přerušeno signálem SIGINT (generovaným například zadáním znaku přerušení, typicky control-C) nebo signálu SIGTERM (obvykle generovaného s kill (1) příkaz; pokud je spuštěn s příznakem -c , zachycuje pakety, dokud není přerušen signálem SIGINT nebo SIGTERM nebo je zpracován zadaný počet paketů.

Když tcpdump ukončí zachycování paketů, bude hlásit počty:

balíčky `` přijaté filtrem '' (význam toho závisí na operačním systému, na kterém spouštíte tcpdump a případně na způsobu konfigurace operačního systému - pokud byl na příkazovém řádku zadán filtr, v některých operačních systémech se počítá pakety bez ohledu na to, zda byly splněny výrazem filtru, a na jiných operačních systémech se počítají pouze pakety, které odpovídaly výrazu filtru a byly zpracovány tcpdump );

pakety `` droped by kernel '' (to je počet paketů, které byly kvůli nedostatku místa na vyrovnávací paměti vynechány mechanismem zachycení paketů v operačním systému, na kterém běží tcpdump , pokud OS hlásí tyto informace do aplikací; pokud ne, bude hlášeno jako 0).

Na platformách, které podporují signál SIGINFO, jako je většina BSD, oznámí tyto počty, když přijme signál SIGINFO (generovaný například zadáním znaku `` status '', typicky control-T) a bude pokračovat v zachycování paketů .

Čtení paketů ze síťového rozhraní může vyžadovat speciální oprávnění:

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

Musíte mít přístup k čtení / dev / nit nebo / dev / bpf * .

Pod Solaris s DLPI:

Musíte mít přístup k čtení a zápisu k síťovému pseudo zařízení, např. / Dev / le . Přinejmenším na některých verzích Solarisu však toto není dostačující k tomu, aby umožňovalo tcpdump zachytit v promiskuitním režimu; na těch verzích Solaris musíte být root, nebo tcpdump musí být nainstalován setuid root, aby byl zachycen v promiskuitním režimu. Všimněte si, že na mnoha (možná všech) rozhraních, pokud nezachycujete v promiskuitním režimu, neuvidíte žádné odchozí pakety, takže zachycení neprovedené v promiskuitním režimu nemusí být velmi užitečné.

Pod HP-UX s DLPI:

Musíte být root nebo tcpdump musí být nainstalován setuid na root.

Pod IRIX s snoopem:

Musíte být root nebo tcpdump musí být nainstalován setuid na root.

Pod Linuxem:

Musíte být root nebo tcpdump musí být nainstalován setuid na root.

Pod zařízeními Ultrix a Digital UNIX / Tru64 UNIX:

Každý uživatel může zachytit síťovou komunikaci pomocí tcpdump . Žádný uživatel (dokonce ani superuživatel) však nemůže zachytit v promiskuitním režimu na rozhraní, pokud superuživatel neprovedl promiskuitní režim na tomto rozhraní pomocí pfconfig (8) a žádný uživatel (ani superuživatel ) dokáže zachytit provoz unicast přijatý nebo odeslaný zařízením na rozhraní, pokud superuživatel nepoužívá v tomto rozhraní funkci pfconfig , takže užitné zachycení paketů v rozhraní pravděpodobně vyžaduje buď promiskuitní režim nebo kopii - v tomto režimu je povoleno ovládání všech režimů nebo oba režimy ovládání.

Pod BSD:

Musíte mít přístup k čtení / dev / bpf * .

Čtení uloženého souboru paketů nevyžaduje zvláštní oprávnění.

MOŽNOSTI

-A

Pokus o převedení adresy sítě a vysílání na jména.

-C

Ukončit po obdržení počtu paketů.

-C

Před zapsáním nesprávného paketu do souboru uložení zkontrolujte, zda je soubor aktuálně větší než file_size, a pokud ano, zavřete aktuální soubor uložení a otevřete nový. Po prvním uložení souboru Savefiles bude zadán název s příznakem -w s číslem po něm začínajícím od 2 a pokračováním nahoru. Jednotky file_size jsou miliony bajtů (1 000 000 bajtů, nikoli 1 048 576 bajtů).

-d

Vypusťte zkompilovaný kód pro shodu paketů ve formě čitelné pro lidi na standardní výstup a zastavení.

-dd

Kopírovat kód odpovídajících paketu jako fragment programu C.

-ddd

Kód pro shodu paketu jako desítková čísla (předchází počet).

-E

Vytiskněte záhlaví úrovně odkazu na každém řádku výpisu.

-E

Použijte algo: tajné pro dešifrování paketů IPsec ESP. Algoritmy mohou být des-cbc , 3des-cbc , blowfish -cbc , rc3-cbc , cast128-cbc nebo žádné . Výchozí hodnota je des-cbc . Schopnost dešifrovat pakety je přítomna pouze tehdy, pokud byla kompilována tcpdump se zapnutou kryptografií. tajný text ascii pro tajný klíč ESP. V tuto chvíli nemůžeme mít libovolnou binární hodnotu. Volba předpokládá ESP RFC2406, nikoliv RFC1827 ESP. Tato možnost je určena pouze pro účely ladění a použití této možnosti se skutečným tajným klíčem je odrazeno. Předkládáním tajného klíče IPsec na příkazový řádek je viditelný pro ostatní, přes ps (1) a jiné příležitosti.

-F

Vytiskněte `cizí 'internetové adresy numericky a ne symbolicky (tato možnost je určena k získání vážných poškození mozku na serveru Sun serveru --- obvykle to visí navěky překládání ne-místních internetových čísel).

-F

Použijte soubor jako vstup pro výraz filtru. Další příkaz uvedený na příkazovém řádku je ignorován.

-i

Poslouchejte na rozhraní . Není-li to blíže specifikováno, tcpdump prohledá seznam systémových rozhraní pro nejmenší, nakonfigurované rozhraní (kromě loopback). Vazby jsou porušeny výběrem nejčasnějšího zápasu.

V systémech Linux s 2.2 nebo novějšími jádry lze použít argument rozhraní `` any '' pro zachycení paketů ze všech rozhraní. Všimněte si, že zachycení na zařízení `` žádné '' nebude provedeno v promiskuitním režimu.

-l

Vytvořte stdout linku vyrovnávací paměť. Užitečné, chcete-li zobrazit data při jejich zachycení. Např,
`` tcpdump -l | tee dat '' nebo `` tcpdump -l> dat & tail -f dat ''.

-m

Vložte definice modulu SMI MIB z modulu souborů. Tato volba může být použita několikrát k načtení několika MIB modulů do tcpdump .

-n

Nepřevádějte hostitelské adresy na jména. To lze využít k vyloučení vyhledávání DNS.

-nn

Nepřevádějte čísla protokolů a portů atd. Na jména.

-N

Nevytiskněte název domény pro názvy hostitelů. Například, pokud dáte tento příznak, pak tcpdump vytiskne `` nic '' namísto `` nic.ddn.mil ''.

-Ó

Nepoužívejte optimalizátor kódů odpovídajících paketu. To je užitečné pouze v případě, že máte podezření na chybu v optimalizátoru.

-p

Neumísťujte rozhraní do promiskuitního režimu. Všimněte si, že rozhraní může být v promiskuitním režimu z nějakého jiného důvodu; proto "-p" nemůže být použit jako zkratka pro "éter host" {local-hw-addr} nebo ether broadcast ".

-q

Rychlý (tichý?) Výstup. Tiskněte méně protokolových informací, takže výstupní řádky jsou kratší.

-R

Předpokládejme, že pakety ESP / AH budou založeny na starších specifikacích (RFC1825 až RFC1829). Pokud je zadáno, tcpdump nebude tisknout pole prevence přehrávání. Vzhledem k tomu, že ve specifikaci ESP / AH neexistuje pole verze protokolu, tcpdump nemůže odvodit verzi protokolu ESP / AH.

-r

Přečtěte si pakety ze souboru (který byl vytvořen s volbou -w). Standardní vstup se používá, pokud je soubor `` - ''.

-S

Vytiskněte čísla absolutních, nikoliv relativních, TCP.

-s

Snarf zachycuje bajty dat z každého paketu spíše než výchozí 68 (s SunIT NIT, minimálně je 96). 68 bajtů je vhodný pro protokoly IP, ICMP, TCP a UDP, ale může zkrátit protokolové informace ze jmenného serveru a paketů NFS (viz níže). Pakety zkrácené z důvodu omezeného snímku jsou na výstupu označeny znakem `` [| proto ] '', kde proto je název úrovně protokolu, ve které došlo ke zkrácení. Všimněte si, že zvětšení snímků zvyšuje čas potřebný pro zpracování paketů a efektivně snižuje množství vyrovnávací paměti paketů. To může způsobit ztrátu paketů. Měli byste omezit snaplen na nejmenší číslo, které zachycuje informace o protokolu, které vás zajímají. Nastavení snaplen na 0 znamená použít požadovanou délku pro zachycení celých paketů.

-T

Vynutit pakety vybrané " výrazem ", aby byl interpretován zadaný typ . Aktuálně známé typy jsou cnfp (protokol Cisco NetFlow), rpc (vzdálený volání procedur), rtp (protokol aplikací v reálném čase), rtcp (řídící protokol v reálném čase), snmp (Simple Network Management Protocol) ) a wb (distribuovaná bílá tabulka).

-t

Na každou výpisovou linku nevytiskněte časové razítko.

-tt

Tiskněte neformátované časové razítko na každou výpisovou linku.

-U

Dostane oprávnění root a změní ID uživatele na ID uživatele a skupiny na primární skupinu uživatelů .

Poznámka! Red Hat Linux automaticky uděluje oprávnění uživateli `` pcap '', pokud není zadáno nic jiného.

-ttt

Vytiskněte delta (v mikrosekundách) mezi aktuální a předcházející čárou na každé linii výpisu.

-tttt

Vytiskněte časové razítko ve výchozím formátu, které bude pokračovat podle data na každé výpisové lince.

-u

Tiskněte nekódované NFS úchyty.

-proti

(Mírně více) podrobný výstup. Například čas tisku, identifikace, celková délka a možnosti v IP paketu jsou vytištěny. Umožňuje také další kontroly integrity paketů, jako je ověření kontrolního součtu hlaviček IP a ICMP.

-vv

Dokonce více podrobný výstup. Například další pole jsou vytištěna z paketů odpovědí NFS a pakety SMB jsou plně dekódovány.

-vvv

Dokonce více podrobný výstup. Například volby telnet SB ... SE jsou vytištěny v plném rozsahu. Možnosti volby -X telnet jsou také vytištěny v hex.

-w

Napište surové pakety do souboru, nikoli analyzovat a vytisknout. Mohou být později vytištěny pomocí volby -r. Standardní výstup se používá, pokud je soubor `` - ''.

-X

Vytiskněte každý paket (minus jeho záhlaví úrovně odkazu) v šestnáctce. Vytiskne se menší z celého paketu nebo bajtů. Všimněte si, že se jedná o celý paket propojovací vrstvy, takže pro vrstvy propojení, které obsahují pad (např. Ethernet), budou vytištěné bajty vycpávky, pokud je paket s vyšší vrstvou kratší než požadovaný polštář.

-X

Při tisku hex se také tiskne ascii. Takže pokud -x je také nastaven, paket je vytištěn v hex / ascii. To je velmi užitečné pro analýzu nových protokolů. I když není -x také nastaveno, některé části některých paketů mohou být vytištěny v hex / ascii.

výraz

vybírá, které pakety budou vyhozeny. Není-li zadán žádný výraz , budou všechny pakety na síti vyřazeny. V opačném případě budou vyloučeny pouze pakety, jejichž výraz je "true".

Výraz se skládá z jednoho nebo více primitiv. Primitivy obvykle sestávají z id (jména nebo čísla), kterému předchází jedna nebo více kvalifikátorů. Existují tři různé druhy kvalifikací:

typ

kvalifikanti říkají, na jakou věc se jména nebo číslo odkazuje. Možné typy jsou host , net a port . Například "host foo", "net 128.3", "port 20". Pokud neexistuje typový kvalifikátor, předpokládá se hostitel .

dir

kvalifikátory určují konkrétní směr přechodu do a / nebo z id . Možné směry jsou src , dst , src nebo dst a src a dst . Např. `Src foo ',` dst net 128.3', `src nebo dst port ftp-data '. Pokud neexistuje žádný kvalifikátor dir, předpokládá se src nebo dst . U nelineárních vrstev odkazů (tj. Bodových bodů, jako je sklouznutí) mohou být pro určení požadovaného směru použity vstupní a výstupní kvalifikátory.

proto

Kvalifikátory omezují shodu na určitý protokol. Možné protos jsou: ether , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp a udp . Například "ether src foo", "arp net 128.3", "tcp port 21". Pokud neexistuje žádný proto kvalifikátor, předpokládají se všechny protokoly odpovídající typu. Např. `Src foo 'znamená` (ip nebo arp nebo rarp) src foo' (s výjimkou toho, že to není legální syntaxe), `net bar 'znamená` net (ip nebo arp) `(tcp nebo udp) port 53 '.

["fddi" je vlastně alias pro "ether"; analyzátor je považuje za stejný jako `` úroveň datového spojení použitého na určeném síťovém rozhraní. '' Záhlaví FDDI obsahují adresy zdrojové a cílové jako Ethernet a často obsahují typy paketů typu Ethernet, takže můžete filtrovat tato pole FDDI stejně jako u analogových polí Ethernet. Záhlaví FDDI také obsahují další pole, ale nemůžete je výslovně pojmenovat ve výrazu filtru.

Podobně, `tr 'je alias pro" ether "; příkazy předchozího odstavce o hlavičkách FDDI se vztahují také na hlavičky Token Ring.]

Navíc k výše uvedeným existuje několik speciálních "primitivních" klíčových slov, která nesledují vzor: brána , vysílání , menší , větší a aritmetické výrazy. Všechny tyto informace jsou popsány níže.

Složitější výrazy filtru jsou sestavovány pomocí slov a nebo kombinovat primitivy. Například "host foo a ne port ftp a ne port ftp-data". Chcete-li uložit psaní, mohou být vynechány stejné seznamy kvalifikací. Například `tcp dst port ftp nebo ftp-data nebo domain 'je přesně stejný jako` tcp dst port ftp nebo tcp dst port ftp-data nebo tcp dst port domain'.

Přípustné primitivy jsou:

dst host hostitele

Je pravdivé, pokud je cílové pole IPv4 / v6 balíčku hostitele , což může být buď adresa, nebo název.

src host hostitele

Je pravdivé, pokud je zdrojové pole paketu IPv4 / v6 hostitelem .

host hostitele

Je pravda, zda je hostitelem zdroj IPv4 / v6 nebo cíl paketu. Kterýkoli z výše uvedených výrazů hostitele může být předstižen klíčovými slovy, ip , arp , rarp nebo ip6 jako v:

ip hostitelský hostitel

který je ekvivalentní:

ether proto \ ip a hostitelský hostitel

Pokud je hostitel jméno s více adresami IP, bude každá adresa zkontrolována pro shodu.

ether dst ehost

Je pravda, pokud je cílová adresa ethernetu ehost . Ehost může být buď název z / etc / ethers nebo číslo (viz ethery (3N) pro číselný formát).

éter src ehost

Je pravda, pokud je zdrojová adresa ethernetu ehost .

éter hostitele ehost

Je pravda, pokud je ethernetový zdroj nebo cílová adresa ehost .

host gateway

Je pravda, pokud paket používal host jako bránu. Tzn. Zdrojová nebo cílová adresa ethernetu byla hostitelem, ale ani zdroj IP ani cíl IP nebyly hostitelem . Hostitel musí být jméno a musí být nalezen jak mechanismem rozlišení hostitele-jméno-IP-adresy (soubor názvu hostitele, DNS, NIS atd.), Tak i rozlišení adresy hostitele-jméno-Ethernet mechanismus (/ etc / ethers atd.). (Ekvivalentní výraz je

ether hostitelský hostitel a hostitelský hostitel

který lze použít s jmény nebo čísly pro host / ehost .) Tato syntaxe v této chvíli nefunguje v konfiguraci s povoleným protokolem IPv6.

dst net net

Je pravda, že cílová adresa IPv4 / v6 paketu má síťové číslo sítě . Net může být buď název z / etc / networks nebo číslo sítě ( podrobnosti viz sítě (4) ).

src čistá síť

Je pravda, pokud má zdrojová adresa IPv4 / v6 paketu síťové číslo sítě .

čistá síť

Je pravda, jestli má zdrojová nebo cílová adresa IPv4 / v6 paket síťové číslo sítě .

síťová maska čisté sítě

Je pravda, pokud se adresa IP shoduje s konkrétní maskou sítě . Může být kvalifikován pomocí src nebo dst . Všimněte si, že tato syntaxe není platná pro síť IPv6.

čistá čistá / čistá

Je to pravda, pokud se adresa IPv4 / v6 shoduje s čistým bajtem síťové masky. Může být kvalifikován pomocí src nebo dst .

dst port portu

Je pravda, pokud je paket ip / tcp, ip / udp, ip6 / tcp nebo ip6 / udp a má hodnotu portu cílového portu . Port může být číslo nebo název používaný v / etc / services (viz tcp (4P) a udp (4P)). Používá-li se název, jsou kontrolovány jak číslo portu, tak protokol. Používá-li se číslo nebo dvojznačný název, je zaškrtnuto pouze číslo portu (např. Dst port 513 vytiskne jak provoz tcp / login, tak provoz udp / who a portová doména vytiskne přenosy tcp / domain a udp / domain).

port portu src

Je pravda, pokud paket má hodnotu portu portu .

port portu

Je pravda, jestli je zdrojový nebo cílový port paketu port . Některé z výše uvedených výrazů portů mohou být předem přidány klíčovými slovy, tcp nebo udp , jako v:

port portu tcp src

který odpovídá pouze paketům tcp, jejichž zdrojový port je port .

méně délky

Je pravda, že paket má délku menší nebo rovnou délce . To odpovídá:

len <= délka .

větší délka

Je pravda, že paket má délku větší nebo rovnou délce . To odpovídá:

len> = délka .

protokol ip proto

Je pravda, pokud je paket IP paket (viz ip (4P)) protokolového protokolu . Protokolem může být číslo nebo jeden z názvů icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp nebo tcp . Všimněte si, že identifikátory tcp , udp a icmp jsou také klíčová slova a musí uniknout zpětným lomítkem (\), což je \\ v C-shellu. Všimněte si, že tento primitiv nesleduje řetězec hlaviček protokolu.

protokol ip6 proto

Je pravda, pokud je paket protokolem protokolu protokolu IPv6. Všimněte si, že tento primitiv nesleduje řetězec hlaviček protokolu.

protokolu protokolů ip6

Je pravda, že paket je paket IPv6 a obsahuje hlavičku protokolu s typem protokolu v řetězci hlavičky protokolu. Například,

ip6 protochain 6

odpovídá jakémukoli paketu IPv6 s hlavičkou protokolu TCP v řetězci hlavičky protokolu. Paket může obsahovat například hlavičku ověřování, záhlaví směrování nebo hlavičku volby hop-by-hop, mezi záhlaví protokolu IPv6 a hlavičkou TCP. BPF kód vysílaný touto primitivou je složitý a nemůže být optimalizován kódem optimalizace BPF v tcpdump , takže to může být poněkud pomalé.

protokol protokol ip

Ekvivalent protokolů pro protokol ip6 , ale je to pro protokol IPv4.

éteru

Je pravda, pokud paket je ethernetový vysílací paket. Klíčové slovo éteru je volitelné.

ip vysílání

Je pravda, pokud paket je paket vysílání IP. Zkontroluje jak konvence vysílání všech nuly, tak i všechno a vyhledá lokální masku podsítě.

ether multicast

Je pravda, pokud je paket ethernetovým multicastovým paketem. Klíčové slovo éteru je volitelné. Toto je zkratka pro " éter [0] & 1! = 0 ".

ip multicast

Je pravda, pokud paket je paket IP pro vícesměrové vysílání.

ip6 multicast

Je pravda, pokud paket je paket multicast IPv6.

ether protokol

Je pravda, pokud je paket ethernetového protokolu . Protokol může být číslo nebo jeden z názvů ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx nebo netbeui . Upozorňujeme, že tyto identifikátory jsou také klíčová slova a musí uniknout zpětným lomítkem (\).

[V případě FDDI (např. ` Fddi protocol arp ') a Token Ring ( např.` Tr protocol arp ') pro většinu z těchto protokolů pochází protokolová identifikace ze záhlaví 802.2 Logical Link Control (LLC) je obvykle navrstvena nad záhlaví FDDI nebo Token Ring.

Při filtrování většiny identifikátorů protokolů na FDDI nebo Token Ring tcpdump zkontroluje pouze pole protokolu ID záhlaví LLC v tzv. SNAP formátu s identifikátorem organizační jednotky (OUI) 0x000000 pro zapouzdřený ethernet; nekontroluje, zda je paket ve formátu SNAP s OUI 0x000000.

Výjimky jsou iso , pro které kontroluje pole DSAP (Access Service Access Point) a SSAP (Source Service Access Point) pole hlavičky LLC, stp a netbeui , kde kontroluje DSAP záhlaví LLC a atalk , kde to kontroluje balíček formátu SNAP s OUI 0x080007 a typem Appletalk.

V případě sítě Ethernet tcpdump kontroluje pole typu Ethernet pro většinu těchto protokolů; výjimky jsou iso , sap a netbeui , pro které kontroluje rámec 802.3 a poté zkontroluje záhlaví LLC stejně jako u FDDI a Token Ring, atalk , kde kontroluje jak etalon Appletalk v rámci Ethernet, tak i SNAP paket ve formátu SNAP jako u FDDI a Token Ring, aarp , kde kontroluje typ e-mailu Appletalk ARP buď v rámci Ethernet, nebo v rámci 802.2 SNAP s OUI 0x000000 a ipx , kde kontroluje typ IPX v ethernetový rámec, IPX DSAP v záhlaví LLC, 802.3 bez zapouzdření hlavičky LLC IPX a IPX etype v rámci SNAP.]

hostitel decnet src

Je pravda, pokud je zdrojová adresa DECNET hostitelem , což může být adresa formuláře `` 10.123 '' nebo název hostitele DECNET. [Podpora názvu hostitele DECNET je k dispozici pouze v systémech Ultrix, které jsou nakonfigurovány pro spuštění služby DECNET.]

decnet dst host

Je pravda, pokud je cílová adresa DECNET hostitelem .

hostitel hostitele hostitele

Je pravda, pokud je hostitelský zdroj buď DECNET nebo cílová adresa.

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

Zkratky pro:

éter proto p

kde p je jeden z výše uvedených protokolů.

lat , moprc , mopdl

Zkratky pro:

éter proto p

kde p je jeden z výše uvedených protokolů. Všimněte si, že tcpdump momentálně neví, jak analyzovat tyto protokoly.

vlan [vlan_id]

Je pravda, pokud paket je paket IEEE 802.1Q VLAN. Pokud je zadán parametr [vlan_id], je pravda, že paket má zadaný parametr vlan_id . Všimněte si, že první klíčové slovo vlan, které se vyskytuje ve výrazu, změní dekódovací offsety pro zbytek výrazu za předpokladu, že paket je paket VLAN.

tcp , udp , icmp

Zkratky pro:

ip proto p nebo ip6 proto p

kde p je jeden z výše uvedených protokolů.

protokol iso proto

Je pravda, pokud je paket OSI paket protokolu protokolového typu. Protokolem může být číslo nebo jeden z názvů clnp , esis nebo isis .

clnp , esis , isis

Zkratky pro:

iso proto p

kde p je jeden z výše uvedených protokolů. Všimněte si, že tcpdump provádí neúplné zpracování těchto protokolů.

expr relop expr

Je pravda, že pokud vztah platí, kde relop je jeden z>, <,> =, <=, = ,! =, A expr je aritmetický výraz složený z celočíselných konstant (vyjádřených ve standardní syntaxi C), normální binární operátory [ , -, *, /, &, |], operátor délky a speciální paketové datové příslušenství. Pro přístup k datům uvnitř paketu použijte následující syntaxi:

proto [ expr : velikost ]

Proto je jeden z ether, fddi, tr, ppp, skluzu, odkazu, ip, arp, rarp, tcp, udp, icmp nebo ip6 a označuje vrstvu protokolu pro operaci indexu. ( ethernet, fddi, tr, ppp, sklouznutí a odkaz se vztahují na odkazovou vrstvu). Všimněte si, že typy protokolů tcp, udp a dalších protokolů vyšší vrstvy platí pouze pro protokol IPv4, nikoliv pro protokol IPv6 (to bude v budoucnu opraveno). Bajtový posun, vztažený na označenou vrstvu protokolu, je dán expr . Velikost je volitelná a udává počet bajtů v poli zájmu; může to být jeden, dva nebo čtyři a výchozí je jeden. Operátor délky, označený klíčem len , udává délku paketu.

Například " éter [0] & 1! = 0 " zachycuje veškerou multicastovou komunikaci. Výraz ` ip [0] & 0xf! = 5 'zachycuje všechny IP pakety s volbami. Výraz ` ip [6: 2] & 0x1fff = 0 'zachycuje pouze nefragmentované datagramy a nulovou fragmentaci fragmentovaných datagramu. Tato kontrola je implicitně použita pro operace indexu tcp a udp . Například tcp [0] vždy znamená první bajt hlavičky TCP a nikdy neznamená první bajt fragmentu zasahujícího.

Některé offsety a hodnoty pole mohou být vyjádřeny jako názvy spíše než jako číselné hodnoty. K dispozici jsou následující offsety záhlaví záhlaví protokolu: icmptype (pole typu ICMP), icmpcode (pole ICMP kódu) a tcpflags (pole příznaků TCP).

K dispozici jsou následující hodnoty pole 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 dispozici jsou následující hodnoty pole TCP: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .

Primitivy mohou být kombinovány pomocí:

Skupina s primitivními operátory a operátory (závorky jsou speciální pro Shell a musí být vynechány).

Negace (` ! 'Nebo` ne ').

Zřetězení (` && 'nebo` a ').

Střídání (` || 'nebo` nebo ').

Negace má nejvyšší prioritu. Střídání a zřetězení mají stejnou přednost a spojují se zleva doprava. Všimněte si, že pro zřetězení je nyní nutné explicitní a žetony, nikoliv juxtapoziční.

Pokud je identifikátor zadán bez klíčového slova, předpokládá se nejnovější klíčové slovo. Například,

ne hostitele vs a eso

je zkratka pro

ne hostitele vs a host eso

což by se nemělo zaměňovat

ne (host vs nebo eso)

Argumenty výrazu mohou být předány tcpdump jako jeden argument nebo jako více argumentů, podle toho, co je výhodnější. Obecně platí, že pokud výraz obsahuje Shell metacharacters, je jednodušší jej předat jako jediný citovaný argument. Vícenásobné argumenty jsou spojeny s mezerami před analýzou.

PŘÍKLADY

Chcete-li vytisknout všechny pakety přicházející nebo odlétající od západu slunce :

tcpdump hostující západ slunce

Chcete-li vytisknout provoz mezi helios a buď horký nebo eso :

tcpdump host helios a \ (horké nebo eso \)

Chcete-li vytisknout všechny pakety IP mezi esem a libovolným hostitelem kromě helios :

tcpdump ip hostitelské eso a ne helios

Vytisknout veškerou komunikaci mezi místními hostitelemi a hostitelemi v Berkeley:

tcpdump net ucb-ether

Chcete-li vytisknout veškerý přenos ftp prostřednictvím snapu pro internetovou bránu: (všimněte si, že výraz je citován, aby se zabránilo chybnému interpretaci obálky):

tcpdump 'snap brány a (port ftp nebo ftp-data)'

Chcete-li vytisknout provoz, který není určen ani pro místní hostitele (pokud je brána k jiné síti, nikdy by se to nemělo dostat do vaší lokální sítě).

tcpdump ip a netnet localnet

Vytisknout počáteční a koncové pakety (pakety SYN a FIN) každé konverzace TCP, která zahrnuje hostitele, který není lokální.

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

Chcete-li vytisknout IP pakety delší než 576 bajtů odeslaných přes sběrnici brány:

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

Chcete-li vytisknout pakety IP vysílání nebo vícesměrového vysílání, které nebyly odeslány přes ethernetové vysílání nebo vícesměrové vysílání:

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

Chcete-li vytisknout všechny pakety ICMP, které nevyžadují echo požadavků / odpovědí (tj. Ne ping pakety):

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

VÝSTUPNÍ FORMÁT

Výstup tcpdump závisí na protokolu. Následuje stručný popis a příklady většiny formátů.

Hlavičky úrovně propojení

Je-li zadána možnost "-e", vytiskne se hlavička úrovně propojení. Na adresách ethernets se vytisknou zdrojové a cílové adresy, protokol a délka paketu.

V sítích FDDI volba '-e' způsobuje, že tcpdump vytiskne pole `control frame ', zdrojové a cílové adresy a délku paketu. (Norma paketů (např. Ty, které obsahují IP datagramy) jsou pakety `async 's hodnotou priority mezi 0 a 7, například' async4 '. pakety předpokládají, že obsahují paket 802.2 Logical Link Control (LLC), hlavička LLC se vytiskne, pokud není datagram ISO nebo takzvaný SNAP paket.

V sítích Token Ring volba '-e' způsobuje, že tcpdump vytiskne políčka `control access 'a` control frame', zdrojové a cílové adresy a délku paketu. Stejně jako u sítí FDDI předpokládáme, že pakety obsahují paket LLC. Bez ohledu na to, zda je zadána možnost "-e", informace o směrování zdroje jsou vytištěny pro pakety směrované zdrojovými kódy.

(Pozn .: Následující popis předpokládá znalost SLIP kompresního algoritmu popsaného v dokumentu RFC-1144.)

U odkazů SLIP se vytiskne ukazatel směru ("I" pro příchozí, "O" pro odchozí), typ paketu a informace o kompresi. Typ paketu je vytištěn nejprve. Tři typy jsou ip , utcp a ctcp . Pro IP pakety nejsou vytištěny žádné další informace o spojení. Pro pakety TCP se identifikátor připojení vytiskne podle typu. Je-li paket komprimován, vytiskne se jeho zakódovaná hlavička. Zvláštní případy se vytisknou jako * S + n a * SA + n , kde n je množství, kterým se změnilo pořadové číslo (nebo pořadové číslo a ack). Není-li to zvláštní případ, vytisknou se nula nebo více změn. Změna je označena znaky U (urgentní ukazatel), W (okno), A (ack), S (pořadové číslo) a I (paketové ID), následované delta (+ n nebo -n) (= n). Nakonec se vytiskne množství dat v paketu a délka komprimované hlavičky.

Například následující řádek zobrazuje odchozí komprimovaný paket TCP s implicitním identifikátorem připojení; se změnilo číslo 6, pořadové číslo o 49 a ID paketu o 6; existují 3 bajty dat a 6 bajtů komprimované hlavičky:

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

ARP / RARP pakety

Výstup Arp / rarp zobrazuje typ požadavku a jeho argumenty. Formát má být vysvětlen. Zde je krátký vzorek odebraný od začátku "rlogin" od hostitele rtsg po host csam :

arp kdo-má csam říct rtsg arp odpověď csam je-v CSAM

První řádek říká, že rtsg poslal arp paket s žádostí o ethernetovou adresu internetového hostitele csam. Csam odpovídá svou ethernetovou adresou (v tomto příkladu jsou ethernetové adresy v malých písmenách označeny čepy a internetové adresy).

To by vypadalo méně redundantní, kdybychom provedli tcpdump -n :

arp kdo má 128.3.254.6 řekne 128.3.254.68 arp odpověď 128.3.254.6 je-na 02: 07: 01: 00: 01: c4

Pokud bychom provedli tcpdump -e , bude vidět skutečnost, že první paket je vysílán a druhý je bod-k-bod:

RTSG Broadcast 0806 64: arp kdo má csam říká rtsg CSAM RTSG 0806 64: arp odpověď csam je-na CSAM

U prvního paketu se říká, že zdrojová adresa ethernetu je RTSG, cílová adresa je Ethernetová vysílací adresa, pole typu obsahuje hex 0806 (typ ETHER_ARP) a celková délka byla 64 bajtů.

TCP pakety

(Poznámka: Následující popis předpokládá obeznámenost s protokolem TCP popsaným v dokumentu RFC-793. Pokud nejste obeznámeni s protokolem, ani tento popis, ani tcpdump nebudou pro vás hodně užitečné.)

Obecný formát linky protokolu tcp je:

src> dst: příznaky dat-seqno ack okno naléhavé volby

Src a dst jsou zdrojové a cílové adresy IP a porty. Vlajky jsou nějakou kombinací S (SYN), F (FIN), P (PUSH) nebo R (RST) nebo jediné `. ' (bez příznaků). Data-seqno popisuje část prostoru sekvence pokrytou daty v tomto paketu (viz příklad níže). Ack je pořadové číslo dalších dat, které se očekávají v tomto směru jiným směrem. Okno je počet bajtů přijímaného vyrovnávací paměti, který je k dispozici v druhém směru. Urg označuje, že v paketu jsou "naléhavé" data. Možnosti jsou volby tcp uzavřené v úhlových závorách (např. ).

Src, dst a vlajky jsou vždy přítomny. Ostatní pole závisí na obsahu záhlaví protokolu tcp paketu a jsou výstupní pouze v případě potřeby.

Zde je úvodní část rloginu z hostitele rtsg do host csam .

rtsg.1023> csam.login: S 768512: 768512 (0) vyhrajte 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 win 4096 rtsg.1023> csam. přihlásit se: . 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 vyhrát 4077 urg 1 csam.login> rtsg.1023: P 3: 4 (1) ack 21 vyhrát 4077 urg 1

První řádek říká, že tcp port 1023 na rtsg poslal paket na přihlášení na csam. S označuje, že byl nastaven příznak SYN . Pořadové číslo paketu bylo 768512 a neobsahovalo žádné údaje. (Označení je "první: poslední (nbytes)", což znamená "pořadí sekvencí nejprve , ale nezahrnující poslední, což je nbytes bajtů uživatelských dat".) Nebyl zde žádný zálohovaný ack, dostupné přijímací okno bylo 4096 bajtů a byla volba velikosti maximálního segmentu vyžadující mss 1024 bajtů.

Csam odpovídá s podobným paketem, kromě toho, že obsahuje akvizici pro praporčík SYN. Rtsg potom acks csam SYN. ``. ' znamená, že nebyly nastaveny žádné vlajky. Paket neobsahoval žádná data, takže neexistuje žádné datové pořadové číslo. Všimněte si, že číslo řetězce ack je malé celé číslo (1). Když tcpdump poprvé vidí tcp `conversation ', vytiskne pořadové číslo z paketu. Na následujících paktech konverzace se vytiskne rozdíl mezi sekvenčním číslem aktuálního paketu a počátečním pořadovým číslem. To znamená, že počáteční čísla po prvním lze interpretovat jako relativní pozice bajtů v datovém toku konverzace (první datový byte v každém směru je "1"). `-S 'tuto funkci přepíše, což způsobí výstupní počáteční čísla.

Na 6. řádku odesílá rtsg csam 19 bajtů dat (bajty 2 až 20 v rtsg -> csam straně konverzace). Příznak PUSH je nastaven v paketu. Na 7. řádku csam říká, že se jedná o přijatá data odeslaná rtsg až po bajt 21. Většina těchto dat je zřejmě seděna v soketovém vyrovnávacím paměti, protože csam je přijímací okno získalo 19 bajtů menší. Csam také odesílá jeden bajt dat do rtsg v tomto paketu. Na osmém a devátém řádku odesílá csam dva bajty naléhavých, posunutých dat na rtsg.

Pokud byl snímek dostatečně malý, aby tcpdump nezachytil úplnou hlavičku TCP, interpretuje tolik hlaviček, kolik dokáže, a poté hlásí `` [| tcp ] '' pro označení, že zbytek nelze interpretovat. Pokud záhlaví obsahuje falešnou možnost (jedna s délkou, která je buď příliš malá nebo za koncem záhlaví), tcpdump ji hlásí jako `` [ bad opt ] '' a nevytváří žádné další možnosti (protože nelze vyčíst kde začínají). Pokud délka záhlaví naznačuje, že jsou k dispozici možnosti, ale délka datagramu IP není dostatečně dlouhá na to, aby existovaly možnosti, tcpdump jej hlásí jako `` [ bad hdr length ] ''.

Zaznamenávání paketů TCP s konkrétními kombinacemi příznaků (SYN-ACK, URG-ACK atd.)

V sekci Řídicí bity v hlavičce TCP je 8 bitů:

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

Předpokládejme, že chceme sledovat pakety používané při vytváření připojení TCP. Připomeňme si, že protokol TCP používá protokol 3-way handshake při inicializaci nového připojení; sekvence připojení s ohledem na řídicí bity TCP je

1) volající pošle SYN

2) Příjemce reaguje pomocí SYN, ACK

3) volající pošle ACK

Nyní máme zájem zachytit pakety, které mají pouze sadu bitů SYN (krok 1). Všimněte si, že nechceme pakety z kroku 2 (SYN-ACK), jen prostý počáteční SYN. Potřebujeme správný výraz pro tcpdump .

Vyvolat strukturu záhlaví TCP bez možností:

0 15 31 ----------------------------------------------- ------------------ | zdrojový port | cílový port | -------------------------------------------------- --------------- | pořadové číslo | -------------------------------------------------- --------------- | číslo potvrzení | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | velikost okna | -------------------------------------------------- --------------- | Kontrolní součet TCP | naléhavý ukazatel -------------------------------------------------- ---------------

Záhlaví protokolu TCP obvykle obsahuje 20 oktetů dat, pokud nejsou k dispozici možnosti. První řádek grafu obsahuje oktety 0 - 3, druhý řádek obsahuje oktety 4 - 7 apod.

Začíná-li se počítat s 0, příslušné řídicí bity TCP jsou obsaženy v oktetu 13:

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

Podívejme se blíže na oktet ne. 13:

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

Jedná se o řídicí bity TCP, o které nás zajímá. Počty bitů v tomto oktetu byly číslovány od 0 do 7, zprava doleva, takže bit PSH je bit číslo 3, zatímco bit URG je číslo 5.

Připomeňme, že chceme zachytit pakety pouze s nastavením SYN. Podívejme se, co se stane s oktetem 13, jestliže přijde datový blok TCP s nastaveným bitem SYN v jeho záhlaví:

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

Když se podíváme na část řídicích bitů, zjistíme, že je nastaveno pouze číslo 1 (SYN).

Za předpokladu, že octetové číslo 13 je 8bitové celé číslo bez znaménka v pořadí síťových bajtů, binární hodnota tohoto oktetu je

00000010

a jeho desítkové reprezentace je

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

Jsme skoro hotovi, protože nyní víme, že pokud je nastaven pouze SYN, hodnota 13 oktetu v hlavičce TCP, když je interpretována jako 8-bitové celé číslo bez znaménka v pořadí síťových bajtů, musí být přesně 2.

Tento vztah lze vyjádřit jako

tcp [13] == 2

Tento výraz můžeme použít jako filtr pro tcpdump , abychom mohli sledovat pakety, které mají pouze SYN:

tcpdump -i xl0 tcp [13] == 2

Výraz říká "nechte 13. oktet TCP datagramu desetinnou hodnotu 2", což je přesně to, co chceme.

Nyní předpokládejme, že potřebujeme zachytit pakety SYN, ale je nám jedno, zda je současně nastaven ACK nebo jakýkoli jiný řídicí bit TCP. Podívejme se, co se stane s oktetem 13 při příchodu TCP datagramu s množinou 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 |

Nyní jsou bity 1 a 4 nastaveny v 13. oktetu. Binární hodnota octetu 13 je

00010010

který se přenáší na desetinnou čárku

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

Teď nemůžeme v tcpdump filtru použít tcp [13] == 18 ', protože by se vybraly pouze ty pakety, které mají sadu SYN-ACK, ale ty, které mají pouze SYN set. Nezapomeňte, že je nám jedno, zda je ACK nebo jakýkoli jiný ovládací bit nastaven tak dlouho, dokud je nastaven SYN.

Abychom dosáhli našeho cíle, musíme logicky AND binární hodnotu oktetu 13 nějakou jinou hodnotu zachovat bit SYN. Víme, že chceme, aby SYN byl nastaven v každém případě, takže logicky A bude hodnota v 13. oktetu s binární hodnotou SYN:

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

Vidíme, že tato operace AND přináší stejný výsledek bez ohledu na to, zda je nastaven ACK nebo jiný řídicí bit TCP. Desítková reprezentace hodnoty AND, jakož i výsledek této operace je 2 (binární 00000010), takže víme, že pro pakety s nastavením SYN platí následující vztah:

((hodnota oktetu 13) AND (2)) == (2)

To nás vede k výrazu filtru tcpdump

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

Všimněte si, že byste měli ve výrazu použít jednoduché uvozovky nebo zpětné lomítko, aby jste skryli zvláštní znak AND ('&').

UDP pakety

Formát UDP je ilustrován tímto balíčkem rwho:

aktinide.who> vysílání.who: udp 84

To říká, že port, který na hostitelském aktinidu poslal udg datagram do portu, který v hostitelském vysílání , internetovou adresu vysílání. Paket obsahoval 84 bajtů uživatelských dat.

Některé služby protokolu UDP jsou rozpoznávány (ze zdrojového nebo cílového čísla portu) a vytištěny vyšší protokolové informace. Zejména požadavky služby služby Domain Name (RFC-1034/1035) a Sun RPC volání (RFC-1050) do NFS.

Požadavky na název serveru UDP

(Poznámka: Následující popis předpokládá obeznámenost s protokolem Domain Service popsaným v dokumentu RFC-1035. Pokud se vám tento protokol netýká, zobrazí se následující popis v řečtině.)

Požadavky jména serveru jsou formátovány jako

src> dst: id op? příznaky qtype qclass jméno (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

Hostitel h2opolo požádal server domény na helios o záznam adresy (qtype = A), který je spojen s názvem ucbvax.berkeley.edu. Číslo dotazu bylo `3 '. Značka "+" označuje, že požadovaná vlajka byla nastavena. Délka dotazu byla 37 bajtů, bez záhlaví protokolů UDP a IP. Operace dotazu byla normální, Query , takže pole op bylo vynecháno. Pokud by op, bylo něco jiného, ​​bylo by vytištěno mezi "3" a "+". Podobně byla qclass normální, C_IN a vynechána. Jakýkoli jiný qclass by byl vytištěn bezprostředně za `A '.

Několik anomálií je zkontrolováno a může vést k uzavření dalších polí v hranatých závorkách: Pokud dotaz obsahuje odpověď, záznamy o autoritě nebo další záznamy, ankount , nscount nebo arcount se vytisknou jako `[ n a] ',` [ n n ] nebo "[ n au]", kde n je příslušný počet. Je-li nastaven některý z bitů odezvy (AA, RA nebo rcode) nebo kterýkoli z bajtů `musí být nulový ', jsou nastaveny v bajtech dva a tři, vytiskne se` [b2 & 3 = x ]', kde x je hex hlavičkové bajty dva a tři.

Odpovědi název serveru UDP

Odpovědi jména serveru jsou formátovány jako

src> dst: id op rcode příznaky a / n / au typ dat třídy (len) helios.domain> h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain> h2opolo.1537: 2 NXDomain * 0/1/0 (97)

V prvním příkladu helios odpovídá na dotaz č. 3 z h2opolo s 3 záznamy odpovědí, 3 záznamy o jmenném serveru a 7 dalších záznamů. První záznam záznamu je typ A (adresa) a jeho data jsou internetová adresa 128.32.137.3. Celková velikost odpovědi byla 273 bajtů, s výjimkou hlaviček UDP a IP. Kód op (Query) a odpověď (NoError) byly vynechány, stejně jako třída (C_IN) záznamu A.

Ve druhém příkladu helios odpovídá na dotaz 2 s kódem odpovědi neexistující domény (NXDomain) bez odpovědí, jednoho jmenného serveru a žádných záznamů autority. Hodnota `* 'označuje, že byl nastaven autoritativní bit odpovědi . Vzhledem k tomu, že nebyly žádné odpovědi, nebyl vytištěn žádný typ, třída nebo data.

Další znaky, které se mohou objevit, jsou `- '(dostupné rekurze, RA, nenastaveno) a` |' (zkrácená zpráva, TC, nastavení). Pokud se v sekci `question 'neobjeví přesně jedna položka, bude vytištěn` [ n q]'.

Všimněte si, že požadavky a odpovědi jmenného serveru mají tendenci být velké a výchozí snaplen 68 bajtů nemusí zachytit dostatek paketu k tisku. Použijte příznak -s, chcete-li zvýšit hodnotu snaplen, pokud potřebujete seriózně prošetřit návštěvnost jmenného serveru. ` 128 je dobré pro mě.

Dekódování SMB / CIFS

tcpdump nyní obsahuje poměrně rozsáhlé dekódování SMB / CIFS / NBT pro data na UDP / 137, UDP / 138 a TCP / 139. Některé primitivní dekódování dat IPX a NetBEUI SMB se také provádí.

Ve výchozím nastavení se provádí poměrně minimální dekódování s mnohem podrobnějším dekódováním, pokud se používá -v. Upozorňujeme, že s balíčkem -va jediný SMB může trvat stránku nebo více, takže použijte pouze -v, pokud opravdu chcete všechny hrůzné detaily.

Pokud dekódujete relace SMB obsahující řetězce unicode, pak byste chtěli nastavit proměnnou prostředí USE_UNICODE na hodnotu 1. Byla by vítána oprava automatického rozpoznávání sérií unicode.

Informace o formátech paketů pro SMB a co znamenají všechna pole viz www.cifs.org nebo adresář pub / samba / specs / na vašem oblíbeném zrcadle serveru samba.org. Nápady SMB napsal Andrew Tridgell (tridge@samba.org).

Požadavky a odpovědi NFS

Požadavky a odpovědi systému Sun NFS (síťový souborový systém) jsou vytištěny jako:

src.xid> dst.nfs: pouze op args src.nfs> dst.xid: reply stat len ​​op výsledky sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709: odpověď ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 vyhledávání fh 9,74 / 4096,6878 "xcolors" wrl.nfs> sushi.201b: odpověď ok 128 vyhledávání fh 9,74 / 4134,3150

V prvním řádku hostitelské sushi posílá transakci s id 6709 do wrl (všimněte si, že číslo následující po hostiteli src je ID transakce, nikoliv zdrojový port). Požadavek byl 112 bajtů, s výjimkou hlaviček UDP a IP. Operace byla readlink (číst symbolický odkaz) na souboru handle ( fh ) 21,24 / 10,731657119. (Pokud má člověk štěstí, jako v tomto případě lze popisovač souboru interpretovat jako hlavní, malý pár čísel zařízení, následovaný číslem inode a generačním číslem.) Wrl odpovídá `ok 's obsahem odkazu.

Ve třetím řádku se sushi zeptá wrl, aby vyhledal název " xcolors " v souboru adresáře 9,74 / 4096.6878. Všimněte si, že vytištěné údaje závisí na typu operace. Formát je určen k tomu, aby byl vysvětlující, pokud je čten ve spojení s specifikací protokolu NFS.

Je-li zadán příznak -v (verbose), vytisknou se další informace. Například:

sushi.1372a> wrl.nfs: 148 čtení fh 21,11 / 12,195 8192 bytů @ 24576 wrl.nfs> sushi.1372a: odpověď ok 1472 číst REG 100664 ids 417/0 sz 29388

(-v také vytiskne IP hlavičky TTL, ID, délka a fragmentační pole, které byly z tohoto příkladu vynechány.) V prvním řádku se sushi zeptá wrl, aby četl 8192 bajtů ze souboru 21,11 / 12,195 při posunu bajtů 24576. Wrl odpověděl `ok '; paket uvedený na druhém řádku je prvním fragmentem odpovědi a je tedy pouze 1472 bajtů dlouhý (další bajty budou následovat v následujících fragmentech, ale tyto fragmenty nemají hlavičky NFS ani hlavičky UDP a tak se nemusí tisknout, v závislosti na použitém výrazu filtru). Vzhledem k tomu, že je uveden příznak -v, jsou vytištěny některé atributy souborů (které jsou vráceny k souborům): typ souboru (`` REG '' pro běžný soubor), režim souborů (v osmičce) uid a gid a velikost souboru.

Pokud je parametr -v zadán více než jednou, vytisknou se ještě další podrobnosti.

Všimněte si, že požadavky NFS jsou velmi velké a většina detailů nebude vytištěna, pokud se nezvýší snaplen . Pro sledování provozu NFS zkuste použít ` -s 192 '.

Pakety odpovědi NFS výslovně neidentifikují operaci RPC. Místo toho tcpdump udržuje přehled o "nedávných" požadavcích a shoduje se s odpověďmi pomocí ID transakce. Pokud se odpověď neodpovídá na odpovídající žádost, nemusí být parsovatelná.

Žádosti a odpovědi AFS

Žádosti a odpovědi společnosti Transarc AFS (Andrew File System) jsou vytištěny jako:

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 odpověď service call-name args elvis. 7001> pike.afsfs: rx data fs volání přejmenovat starý fid 536876964/1/1 ".newsrc.new" nový fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx data fs odpověď přejmenovat

V prvním řádku vysílá hostitelský elvis balíček RX na štiky. Jednalo se o datový paket RX do služby fs (fileserver) a je zahájením volání RPC. Volání RPC bylo přejmenování se starým ID adresáře 536876964/1/1 a starým názvem `.newsrc.new 'a novým adresářovým číslem 536876964/1/1 a novým jménem` `. newsrc '. Šikovný hostitel reaguje odpovědí RPC na volání přejmenování (což bylo úspěšné, protože to byl datový paket a ne paket přerušení).

Obecně platí, že všechny RPC služby AFS jsou dekódovány přinejmenším pomocí volání RPC. Většina RPC RPC má alespoň některé z argumentů dekódované (obecně jen "zajímavé" argumenty, některé definice zajímavé).

Formát je určen k popisu sebe sama, ale pravděpodobně nebude užitečný pro lidi, kteří nejsou obeznámeni s fungováním AFS a RX.

Pokud je příznak -v (podrobný) zadán dvakrát, vytisknou se potvrzovací pakety a další informace o záhlaví, jako je ID volajícího RX, číslo hovoru, pořadové číslo, sériové číslo a příznaky RX paketu.

Pokud je parametr -v zadán dvakrát, vytisknou se další informace, jako je ID volajícího RX, sériové číslo a příznaky paketu RX. Informace o vyjednávání MTU jsou také vytištěny z paketů RX ack.

Pokud je parametr -v uveden třikrát, vytiskne se bezpečnostní index a ID služby.

Chybové kódy jsou vytištěny pro zrušení paketů, s výjimkou paketů Ubik beacon (protože pakety pro zrušení se používají k označení ano hlasu pro protokol Ubik).

Všimněte si, že požadavky AFS jsou velmi velké a mnohé argumenty nebudou vytištěny, dokud se nezvýší snaplen . Pro sledování provozu AFS zkuste použít ` -s 256 '.

Pakety odpovědi AFS explicitně neurčují operaci RPC. Místo toho tcpdump udržuje přehled o `` nejnovějších '' požadavcích a odpovídá jim na odpovědi pomocí čísla hovoru a ID služby. Pokud se odpověď neodpovídá na odpovídající žádost, nemusí být parsovatelná.

KIP Appletalk (DDP v UDP)

Pakety Appletalk DDP zapouzdřené v UDP datagramech jsou de-zapouzdřeny a vyřazovány jako DDP pakety (tj. Všechny informace hlavičky UDP jsou vyřazeny). Soubor /etc/atalk.names se používá k překladu appletalk net a uzlových čísel k jménům. Linky v tomto souboru mají formu

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

První dva řádky obsahují jména sítí appletalk. Třetí řádek udává název konkrétního hostitele (hostitel se odděluje od sítě třetím oktetem v čísle - čisté číslo musí mít dva oktety a číslo hostitele musí mít tři oktety.) Číslo a jméno by měly být odděleny podle prázdných polí (polotovary nebo karty). Soubor /etc/atalk.names může obsahovat prázdné řádky nebo řádky komentářů (řádky začínající znakem #).

Adresy Appletalk jsou vytištěny ve formě:

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

(Pokud /etc/atalk.names neexistuje nebo neobsahuje záznam pro některé číslo appletalk host / net, adresy jsou vytištěny v číselné podobě.) V prvním příkladu NBP (port DDP 2) na síti 144.1 uzel 209 posílá na všechno, co naslouchá na portu 220 síťového uzlu 112. Druhý řádek je stejný, kromě úplného názvu zdrojového uzlu (`office '). Třetí řádek je odeslání z portu 235 na síťovém jssmag uzlu 149, který vysílá na portu icsd-net NBP (všimněte si, že vysílací adresa (255) je označena čistým jménem bez hostitelského čísla - z tohoto důvodu je to dobrý nápad aby názvy uzlů a názvy sítí byly odlišné v /etc/atalk.names.

Protokoly NBP (name binding protocol) a pakety ATP (protokol transakce protokolu Appletalk) mají jejich obsah interpretován. Jiné protokoly stačí vypsat název protokolu (nebo číslo, pokud není pro protokol zaregistrován žádný název) a velikost paketu.

NBP pakety jsou formátovány jako následující příklady:

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: odpověď nbp 190: "techpit: LaserWriter @ *" 186

První řádek je požadavek na vyhledání názvů pro laserové tiskárny odesílané sítí net icsd 112 a vysílání na síťovém jssmagu. Číslo nbp pro vyhledávání je 190. Druhý řádek ukazuje odpověď na tuto žádost (poznamenejte si, že má stejný identifikátor) z hostitele jssmag.209, který říká, že má zdroj laserového zápisu s názvem "RM1140" zaregistrovaný na portu 250. Třetí line je další odpověď na stejný požadavek říká host techpit má laserwriter "techpit" registrována na portu 186.

Formát paketů ATP je demonstrován následujícím příkladem:

jssmag.209.165: atp-resp 12266: 0 (512) 0xae040000 helios.132> jssmag.209.165: atp-resp 12266: 1 jssmag.209.165> helios.132: atp-req 12266 <0-7> 0xae030001 helios.132> (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> helios.132: atp-req 12266 <3,5> 0xae030001 helios.132> jssmag.209.165: atp-resp 12266: 3 .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 transakční id 12266 s hostitelským heliosem vyžádáním až 8 paketů (`<0-7> '). Šestnáctkové číslo na konci řádku je hodnota pole "userdata" v požadavku.

Helios reaguje na 8 512 bajtů. Hodnota `: digit 'po id transakce udává pořadové číslo paketu v transakci a číslo ve sloupcích je množství dat v paketu s výjimkou atp hlavičky. `* 'Na paketu 7 označuje, že byl nastaven bit EOM.

Jssmag.209 pak požaduje, aby pakety 3 a 5 byly znovu vysílány. Helios je znovu odesílá, jssmag.209 uvolní transakci. Nakonec jssmag.209 iniciuje další požadavek. "#" Na žádost znamená, že XO ("přesně jednou") nebylo nastaveno.

Fragmentace IP

Roztříštěné internetové datagramy jsou vytištěny jako

(fragment id : velikost @ offset +) (fragment id : velikost @ offset )

(První formulář označuje, že existuje více fragmentů. Druhý indikuje, že se jedná o poslední fragment.)

Id je identifikátor fragmentu. Velikost je velikost fragmentu (v bajtech) s výjimkou hlavičky IP. Offset je offset tohoto fragmentu (v bajtech) v původním datagramu.

Informace fragmentu se vygeneruje pro každý fragment. První fragment obsahuje hlavičku protokolů vyšší úrovně a informace o fragmentu se vytisknou po informacích o protokolu. Fragmenty po prvním neobsahují záhlaví protokolů vyšší úrovně a informace o frag jsou vytištěny po zdrojové a cílové adrese. Například zde je část ftp z arizona.edu na lbl-rtsg.arpa přes připojení CSNET, které se nezdá, že zpracovává 576 byte datagramy:

arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 vyhrát 4096 (fragment 595a: 328 @ 0 +) arizona> rtsg: (fragment 595a: 204 @ 328) rtsg.1170> arizona.ftp-data:. ack 1536 vyhrát 2560

Zde je několik věcí, které je třeba uvést zde: Nejprve adresy ve 2. řádku nezahrnují čísla portů. Je tomu tak proto, že informace o protokolu TCP jsou všechny v prvním fragmentu a my netušíme, jaké jsou čísla portů nebo sekvencí při tisku pozdějších fragmentů. Za druhé, informace o sekvenci tcp v prvním řádku jsou vytištěny, jako by tam byly 308 bajtů uživatelských dat, když ve skutečnosti existuje 512 bajtů (308 v prvním fragmu a 204 v druhém). Pokud hledáte otvory v sekvenčním prostoru nebo se snažíte sladit akky s pakety, může vás to oklamat.

Paket s příznakem IP není příznak fragmentu označen koncovým (DF) .

Časové razítko

Ve výchozím nastavení předchází všem výstupním řádkům časová značka. Časové razítko je aktuální čas ve formátu

hh: mm: ss.frac

a je stejně přesný jako hodiny jádra. Časová značka odráží čas, kdy jádro poprvé vidělo paket. Nečiní se žádný pokus o to, aby se zohlednilo časové zpoždění mezi tím, kdy ethernetové rozhraní odstranilo paket z drátu a jádro opravilo přerušení "nového paketu".

VIZ TAKÉ

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

Důležité: Použijte příkaz man ( % man ), abyste zjistili, jaký příkaz se používá v konkrétním počítači.