Tcpdump - Linux Command - Unix parancs

NÉV

tcpdump - dump forgalom a hálózaton

SZINOPSZIS

tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]

[ -C file_size ] [ -F fájl ]

[ -i felület ] [ -m modul ] [ -r fájl ]

[ -s snaplen ] [ -T típus ] [ -U felhasználó ] [ -w fájl ]

[ -E algo: titkos ] [ kifejezés ]

LEÍRÁS

A Tcpdump kinyomtatja a csomagok fejlécét egy olyan hálózati interfészen, amely megfelel a logikai kifejezésnek . Az is futtatható a -w jelzővel, amely a csomag adatokat egy későbbi elemzéshez és / vagy a -r flag-hoz menteti fájlként tárolja, ami miatt elolvassa a mentett csomagot, nem pedig a csomagok olvasását egy hálózati felületről. Minden esetben csak a megjelenéshez illeszkedő csomagokat fogja feldolgozni a tcpdump .

Ha a tcpdump nem fut a -c jelzővel, folytassa a csomagok rögzítését, amíg meg nem szakítja a SIGINT jel (amelyet például a megszakítási karakter, jellemzően a vezérlő C), vagy a SIGTERM jel (általában a kill (1) parancs); Ha a -c jelzővel fut, akkor a csomagokat mindaddig lefogja, amíg meg nem szakítja a SIGINT vagy a SIGTERM jel vagy a megadott számú csomagot.

Amikor a tcpdump befejezi a csomagok elfogadását, akkor a következő számok jelentkeznek:

a szűrők által fogadott "csomagok (ennek jelentése attól függ, hogy az operációs rendszer melyikben tcpdumpot futtat, és esetleg az operációs rendszert konfigurálta - ha a parancssorban megadott egy szűrőt, egyes operációs rendszereken számít csomagok függetlenül attól, hogy a szűrő kifejezéssel illesztették-e őket, és más OS-eken csak olyan csomagokat számít, amelyeket a szűrő kifejezés illesztett és a tcpdump feldolgozott);

a `` kernelrel leeresztett '' csomagok (ez a csomagtartományok hiánya, a pufferhely hiánya miatt, a tcpdump futó operációs rendszerének csomagmeghúzási mechanizmusa, ha az operációs rendszer ezt az információt továbbítja az alkalmazásoknak; ha nem, akkor 0-ként fogják jelenteni.

A SIGINFO jelzést támogató platformokon, például a legtöbb BSD-nél, a SIGINFO jelet (amelyet például a "status" karakter, tipikusan a control-T beírásával generál) generál, majd továbbítja a csomagok rögzítését .

A hálózati felületen lévő csomagok olvasása megkövetelheti, hogy különleges jogosultságokkal rendelkezzen:

SunOS 3.x vagy 4.x alatt NIT vagy BPF esetén:

El kell olvasnia a / dev / nit vagy a / dev / bpf * hozzáférést .

A Solaris a DLPI használatával:

El kell olvasnod / írnod ​​kell a hálózati pszeudo eszközhöz, pl. / Dev / le . A Solaris legalább néhány változatán azonban ez nem elegendő ahhoz, hogy a tcpdump átvészelt módban lehessen elfogni; a Solaris ezen verzióiban gyökérnek kell lennie, vagy a tcpdumpnak telepítenie kell a setuid-ot a gyökérbe, annak érdekében, hogy átvészelt módban rögzítse. Ne feledje, hogy sok (esetleg minden) interfészen, ha nem veszi át a szóváltás módot, nem fog látni kimenő csomagokat, ezért a felesleges módban végzett rögzítés nem feltétlenül hasznos.

A HP-UX a DLPI használatával:

Gyökérnek kell lennie, vagy a tcpdumpnak telepítenie kell a setuid-ot a gyökérbe.

Az IRIX alatt snoop:

Gyökérnek kell lennie, vagy a tcpdumpnak telepítenie kell a setuid-ot a gyökérbe.

Linux alatt:

Gyökérnek kell lennie, vagy a tcpdumpnak telepítenie kell a setuid-ot a gyökérbe.

Az Ultrix és a Digital UNIX / Tru64 UNIX alatt:

Bármely felhasználó rögzítheti a hálózati forgalmat a tcpdump segítségével . Azonban egyetlen felhasználó sem (még a szuperfelhasználó sem) képes átvészelt módban rögzíteni egy interfészt, hacsak a szuper felhasználó a pfconfig (8) használatával tiltott üzemmódú műveletet engedélyezett ezen a felületen, és egyetlen felhasználó sem (még a szuperfelhasználó sem ) rögzítheti a gép által egy interfészen keresztül fogadott vagy elküldött unicast forgalmat, hacsak a szuperfelhasználó nem engedélyezte a pfconfig használatával a felületen történő másolás módját , így a felületek kényelmes fogása valószínűleg megköveteli, hogy vagy a promiscuous mode vagy a copy -Az összes üzemmód vagy mindkét mód működik ezen a felületen.

A BSD szerint:

El kell olvasnia a / dev / bpf * hozzáférést .

A mentett csomagfájl olvasása nem igényel különleges jogosultságokat.

LEHETŐSÉGEK

-a

Kísérlet a hálózati és broadcast címek nevekre való átváltására.

-c

Kilépés a számlálási csomagok fogadását követően.

-C

Mielőtt egy nyers csomagot mentene egy mentési fájlba, ellenőrizze, hogy a fájl jelenleg nagyobb-e a file_size- nél, és ha igen, zárja be az aktuális mentési fájlt, és nyisson meg egy újat. A mentési fájlok az első mentési fájl után a -w jelzővel vannak megadva, egy szám után, a 2-től kezdődően, és továbblépve. A file_size méretei több millió bájt (1 000 000 bájt, nem 1 048 576 bájt).

-d

A lefordított csomagkapcsolt kódot emberi formában olvasható formában kell eljuttatni a szabványos kimenetre és a leállításra.

-DD

Dump csomagkészletezési kódot C programfájlként.

-DDD

Dömödje meg a csomagkapcsolt kódot decimális számokként (megelőzve a számlálást).

-e

Nyomtassa ki a linkszintű fejlécet minden egyes dump vonalon.

-E

Használja az algo: titkot az IPsec ESP csomagok visszafejtéséhez. Az algoritmusok lehet des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc vagy sem . Az alapértelmezés a des-cbc . A csomagok dekódolásának képessége csak akkor jelenik meg, ha a tcpdump kriptográfiai eszközökkel készült. titkolja az ASP titkos kulcs ASCII szövegét. Ebben a pillanatban nem tudunk tetszőleges bináris értéket venni. Az opció feltételezi az RFC2406 ESP-et, nem az RFC1827 ESP-t. Az opció csak hibakeresési célokra szolgál, és ennek az opciónak a használata valóban titkos kulcs nélkül. Az IPsec titkos kulcsnak a parancssorba történő megjelenítésével mások számára láthatóvá tehetők, ps (1) és egyéb alkalmak segítségével.

-f

A "külföldi" internetes címeket inkább numerikusan, mint szimbolikusan nyomtassa ki (ez a lehetőség a Sun yp szerverében komoly agysérülést szán, általában a nem helyi internetes számok lefordítására szolgál).

-F

Fájl használata bemenetként a szűrő kifejezéshez. A parancssorban megadott további kifejezést figyelmen kívül hagyja.

-én

Hallgassa az interfészt . Ha nincs megadva , a tcpdump a legkisebb számozott konfigurált felülettel (a visszacsatolás nélkül) keresi a rendszerinterfészlista listáját. A legrégebbi mérkőzés kiválasztásával a kötelékek megszakadnak.

A 2.2 vagy újabb rendszermagokkal rendelkező Linux rendszereken a "` bármely "' interfész argumentumot használhatjuk a csomagok lekérdezésére az összes interfészről. Ne feledje, hogy a `` bármely '' eszközön végzett rögzítések nem lesznek szórványos módban.

-l

A stdout vonal pufferelése. Hasznos, ha az adatokat rögzíteni szeretné. Például,
`` tcpdump -l | tee dat '' vagy `` tcpdump -l> dat és tail -f dat ''.

-m

Load SMI MIB modul definíciók a fájlmodulból . Ez az opció többször használható több MIB modul betöltésére tcpdump-ba .

-n

Ne konvertálja a gazdagépeket nevekké. Ez a DNS-keresések elkerülésére használható.

-nn

Ne konvertálja a protokollt és a portszámokat stb.

-N

Ne nyomtassa ki a gazdagépek nevének minősítését. Pl. Ha megadja ezt a zászlót, akkor a tcpdump "` nic '' -t nyomtat a `nic.ddn.mil 'helyett.

-O

Ne futtassa a csomagkészletezési kód optimalizálóját. Ez csak akkor hasznos, ha gyanít egy hibát az optimalizálóban.

-p

Ne tegye át a felületet átszúrásos üzemmódba. Ne feledje, hogy az interfész valamilyen más okból kifogástalan módban lehet; ezért a `-p 'nem használható az` ether host {local-hw-addr} vagy éteres sugárzás' rövidítéseként.

-q

Gyors (csendes) kimenet. Nyomtasson kevesebb protokollt, így a kimeneti vonalak rövidebbek.

-R

Tételezzük fel, hogy az ESP / AH csomagok régi specifikáción (RFC1825-RFC1829) alapulnak. Ha meg van adva, a tcpdump nem fogja kinyomtatni a visszajátszás megakadályozás mezőt. Mivel az ESP / AH specifikációban nincs protokollverzió mező, a tcpdump nem tudja deduktálni az ESP / AH protokoll verzióját.

-r

Olvassa el a csomagok fájljait (amelyet a -w opcióval hoztak létre). A szabványos bemenet akkor használható, ha a fájl `` - ''.

-S

Az abszolút, nem relatív TCP sorszámok nyomtatása.

-s

Az összes csomagból származó adatokat a 68-as alapértelmezés helyett a SunOn NIT-ből, a legkisebb pedig 96-ból származik. 68 bájt megfelelő IP, ICMP, TCP és UDP számára, de csonkolhatja a protokollinformációkat a névszerverről és az NFS csomagokról (lásd alább). A korlátozott pillanatfelvétel miatt csonkolt csomagok a kimeneten jelennek meg a `` [| proto ] '', ahol a proto azon protokollszint neve, amelyen a csonkolás történt. Vegye figyelembe, hogy a nagyobb pillanatfelvételek készítése mindkettő növeli a csomagok feldolgozásához szükséges időt, és hatékonyan csökkenti a csomagcsomagolás mennyiségét. Ez a csomagok elvesztését okozhatja. A snaplen- t a legkisebb számra kell korlátozni, amely rögzíti az érdekelt protokoll-információkat. A snaplen beállítása 0-ra azt jelenti, hogy a szükséges hosszúságokat a teljes csomag fogásához használd.

-T

A " kifejezés " által kiválasztott erőcsomagokat a megadott típushoz kell értelmezni. Jelenleg ismert típusok: cnfp (Cisco NetFlow protokoll), rpc (távoli eljáráshívás), rtp (valós idejű alkalmazások protokoll), rtcp (valós idejű alkalmazások vezérlő protokollja), snmp (Simple Network Management Protocol) ) és wb (elosztott White Board).

-t

Ne nyomtasson időbélyeget minden egyes dump vonalon.

-tt

Nyomtasson egy formázatlan időbélyeget minden egyes dump vonalra.

-U

Csökkenti a gyökér jogosultságait, és megváltoztatja a felhasználói azonosítót a felhasználó és a csoport azonosító számára az elsődleges felhasználói csoporthoz.

Jegyzet! A Red Hat Linux automatikusan kivonja a jogosultságokat a felhasználó "pcap" -ra, ha nincs más megadva.

-ttt

Nyomtassa ki a delta (mikroszekundumban) az aktuális és az előző sor között minden egyes dump vonalon.

-tttt

Nyomtasson ki egy időbélyegzőt az alapértelmezett formátumban, mely dátum szerint halad minden egyes dump vonalon.

-u

Nyomtassa ki a dekódolt NFS kezeléseket.

-v

(Enyhén több) verbose output. Például az IP-csomagban az élettartam, az azonosítás, a teljes hossz és az opciók kinyomtathatók. Ezenkívül további csomagintegritási ellenőrzéseket is lehetővé tesz, például az IP és az ICMP fejléc ellenőrző összegének ellenőrzését.

-vv

Még több verbose output. Például további mezőket nyomtatnak ki az NFS válasz csomagokból, és az SMB csomagok teljesen dekódoltak.

-vvv

Még több verbose output. Például a telnet SB ... SE opciókat teljes egészében kinyomtatják. A -X telnet opciókat hexaként is nyomtatják.

-w

Írja be a nyers csomagokat a fájlba, ne pedig értelmezze és nyomtassa ki azokat. Később a -r opcióval kinyomtathatók. A szabványos kimenet akkor használható, ha a fájl `` - ''.

-x

Nyomtasson minden csomagot (mínusz a linkszintű fejléc) hexonként. A teljes csomag vagy a snaplen bájt közül a kisebb lesz kinyomtatva. Felhívjuk a figyelmet arra, hogy ez az egész link-layer csomag, ezért a párhuzamos rétegek (pl. Ethernet) esetében a padding byte-ok akkor is kinyomtatódnak, ha a magasabb réteg csomag rövidebb, mint a szükséges párnázás.

-X

Nyomtatáskor nyomtasson asciit is. Így ha a -x is van beállítva, a csomag hex / ascii-ban kerül kinyomtatásra. Ez nagyon hasznos az új protokollok elemzéséhez. Még ha a -x nem is van beállítva, egyes csomagok egyes részei hex / ascii-ban nyomtathatók.

kifejezés

kiválasztja, hogy mely csomagokat dobja ki. Ha nincs megadva kifejezés, akkor a hálózaton lévő összes csomagot ki kell dobni. Ellenkező esetben csak olyan csomagokat fognak ki, amelyekre a kifejezés "igaz".

A kifejezés egy vagy több primitívből áll. A primitívek általában egy azonosítót (név vagy szám) tartalmaznak, amelyet egy vagy több selejtező előz meg. Három különböző típusú selejtező van:

típus

a selejtezők azt mondják, hogy az id nevére vagy számára utal. Lehetséges típusok a fogadó , a net és a port . Pl .: "host foo", "net 128.3", "port 20". Ha nincs típusminősítő, a gazdagép feltételezhető.

dir

a selejtezők megadják az átirányítási irányt és / vagy az azonosítót . Lehetséges irányok: src , dst , src vagy dst és src és dst . Pl. `Src foo ',' dst net 128.3 ',` src vagy dst port ftp-data'. Ha nincs dir kvalifikátor, az src vagy a dst feltételezhető. A `null 'link rétegeknél (pl. Pont-pont protokollok, például csúszás esetén) a bejövő és a kimenő selejtezők használhatók a kívánt irány meghatározásához.

proto

a selejtezők korlátozzák a mérkőzést egy adott protokollra. Lehetséges prototípusok : éter , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp és udp . Pl .: "ether src foo", "arp net 128.3", "tcp port 21". Ha nincs proto qualifier, akkor a típusnak megfelelő összes protokollt feltételezzük. Például: "src foo": "(ip vagy arp vagy rarp) src foo" (kivéve az utóbbi nem jogi szintaxis), a "net bar" az "(ip vagy arp vagy rarp) net bar" és a "port 53" `(tcp vagy udp) 53 'port.

[`fddi 'valójában egy" éter "álnév; az elemző ugyanúgy kezeli őket a megadott hálózati felületen használt adatkapcsolati szintként. '' Az FDDI fejlécek Ethernet-szerű forrás- és célcímeket tartalmaznak, és gyakran Ethernet típusú csomagtípusokat tartalmaznak, így szűrhetők ezek az FDDI mezők mint az analóg Ethernet mezők esetében. Az FDDI fejlécek más mezőket is tartalmaznak, de kifejezetten nem nevezhetők el egy szűrőkifejezésben.

Hasonlóképpen, a `tr 'az` éter' álnév; az előző bekezdés az FDDI fejlécekkel kapcsolatos kijelentései a Token Ring fejlécekre is vonatkoznak.]

A fentiek mellett vannak olyan speciális "primitív" kulcsszavak is, amelyek nem követik a mintát: átjáró , sugárzott , kevésbé , nagyobb és aritmetikai kifejezések. Mindezeket az alábbiakban ismertetjük.

Bonyolultabb szűrési kifejezéseket építenek fel a szavak felhasználásával, és vagy, és nem kombinálják a primitíveket. Pl .: `host foo és nem port ftp és nem port ftp-data '. A gépelés mentéséhez az azonos minősítő listák elhagyhatók. Pl. A `tcp dst port ftp vagy ftp-adat vagy tartomány 'pontosan ugyanaz, mint` tcp dst port ftp vagy tcp dst port ftp-data vagy tcp dst port domain'.

A megengedhető primitívek:

dst gazdagép

Igaz, ha a csomag IPv4 / v6 célmezője a fogadó , amely lehet egy cím vagy egy név.

src fogadó host

Igaz, ha a csomag IPv4 / v6 forráskódja befogadó .

fogadó host

Igaz, ha a csomag IPv4 / v6 forrás vagy rendeltetése a fogadó . A fenti gazdaszövegek bármelyikét felveheti a kulcsszavakkal, az ip , az arp , a rarp vagy az ip6 kifejezéssel, mint például:

ip gazdagép

amely egyenértékű:

ether proto \ ip és a fogadó host

Ha a gazdagép több IP-címmel rendelkező név, minden egyes címet ellenőrizni fognak.

éter dst ehost

Igaz, ha az ethernet cél cím ehost . Az Ehost lehet egy / etc / ethers nevű név vagy egy szám (lásd az étereket (3N) numerikus formátumban).

éter src ehost

Igaz, ha az ethernet forrás címe ehost .

éter host ehost

Igaz, ha az ethernet forrás vagy célcím ehost .

átjáró állomás

Igaz, ha a csomag a gateway-t használja hostként. Vagyis az ethernet forrás vagy célcím volt a fogadó, de sem az IP-forrás, sem az IP cím nem volt a fogadó . A gépnek névnek kell lennie, és mind a gép gazdagép-név-IP-címének felbontási mechanizmusa (host név fájl, DNS, NIS, stb.), Mind a gép gazdagép-név-Ethernet címének felbontása mechanizmus (/ etc / ethers stb.). (Egyenértékű kifejezés

éter host ehost és nem host fogadó

amely a gazdagép / ehost nevekkel vagy számokkal használható.) Ez a szintaxis jelenleg nem működik az IPv6-alapú konfigurációban.

dst nettó nettó

Igaz, ha a csomag IPv4 / v6 célcímének hálózati száma van. A net lehet egy név az / etc / hálózatokból vagy egy hálózati számból (lásd a hálózatokat (4) a részletekért).

src net net

Igaz, ha a csomag IPv4 / v6 forráscíme hálózati számmal rendelkezik.

nettó nettó

Igaz, ha a csomag IPv4 / v6 forrás- vagy rendeltetési címe hálózati számmal rendelkezik.

net net mask netmaszk

Igaz, ha az IP-cím az adott hálómaszkhoz illeszkedik. Képes lehet src vagy dst minősítéssel. Ne feledje, hogy ez a szintaxis nem érvényes az IPv6-nál.

nettó nettó / len

Igaz, ha az IPv4 / v6 cím megegyezik a hálóval, és egy hálómaszk len . Képes lehet src vagy dst minősítéssel.

dst port port

Igaz, ha a csomag az ip / tcp, az ip / udp, az ip6 / tcp vagy az ip6 / udp, és a port cél port értéke. A port lehet egy szám vagy egy név, amelyet az / etc / services szolgáltatásban használnak (lásd: tcp (4P) és udp (4P)). Ha egy nevet használ, a portszám és a protokoll is be van jelölve. Ha egy számot vagy kétértelmű nevet használunk, csak a portszámot ellenőrzik (pl. A dst port 513 kinyomtatja mind a tcp / login forgalmat, mind a udp / forgalmat, és a port domén mind a tcp / domain, mind a udp / domain forgalmat nyomtatja).

src port port

Igaz, ha a csomagnak van egy port forrásportja.

port portot

Igaz, ha a csomag forrás vagy cél portja port . A fenti port kifejezés bármelyikét felveheti a kulcsszavakkal, tcp vagy udp , mint például:

tcp src port port

amely csak azoknak a TCP-csomagoknak felel meg, amelyek forrásportja port .

kevesebb hossza

Igaz, ha a csomag hosszának hossza kisebb vagy egyenlő. Ez megfelel:

len <= hossza .

nagyobb hosszúságú

Igaz, ha a csomag hosszúsága nagyobb vagy egyenlő a hosszúsággal . Ez megfelel:

len> = hossza .

ip proto protokoll

Igaz, ha a csomag egy IP-csomag (lásd ip (4P)) protokolltípus- protokollt . A protokoll lehet egy vagy több név: icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp vagy tcp . Vegyük észre, hogy a tcp , az udp és az icmp azonosítók is kulcsszavak, ezért el kell menekülniük a backslash (\) segítségével, amely \\ a C-shell-ban van. Ne feledje, hogy ez a primitív nem üldözi a protokoll fejlécet.

ip6 proto protokoll

Igaz, ha a csomag IPv6 protokoll típusú protokoll . Ne feledje, hogy ez a primitív nem üldözi a protokoll fejlécet.

ip6 protochain protokoll

Igaz, ha a csomag IPv6 csomag, és protokoll fejlécet tartalmaz a protokoll fejléc láncában. Például,

ip6 protochain 6

megegyezik az IPv6 csomagok TCP protokoll fejléccel a protokoll fejlécében. A csomag például tartalmazhat hitelesítési fejlécet, útválasztó fejlécet vagy hop-by-hop opció fejlécet az IPv6 fejléc és a TCP fejléc között. A primitív által kibocsátott BPF kód összetett, és a BPC optimizáló kódja nem optimalizálható a tcpdump-ban , így kissé lassú lehet.

ip protokoll protokollt

Az ip6 protochain protokollal egyenértékű, de ez IPv4-re vonatkozik.

éter sugárzás

Igaz, ha a csomag ethernet broadcast csomag. Az éter kulcsszó opcionális.

ip közvetítés

Igaz, ha a csomag egy IP-sugárzási csomag. Ellenőrzi mind az összes nullát, mind az összes broadcast konvenciót, és felnéz a helyi alhálózati maszkra.

éteres multicast

Igaz, ha a csomag ethernet multicast csomag. Az éter kulcsszó opcionális. Ez az " éter [0] & 1! = 0 " rövidítése.

ip multicast

Igaz, ha a csomag egy IP multicast csomag.

ip6 multicast

Igaz, ha a csomag egy IPv6 multicast csomag.

eter proto protokoll

Igaz, ha a csomag ether típusú protokoll . A protokoll lehet egy vagy több ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx vagy netbeui nevek . Ne feledje, hogy ezek az azonosítók is kulcsszavak, és el kell menekülni a backslash (\) segítségével.

[Az FDDI (pl. ` Fddi protocol arp ') és a Token Ring ( pl.` Tr protokoll arp ') esetében a protokollok többsége a 802.2 Logical Link Control (LLC) fejlécből származik. általában az FDDI vagy Token Ring fejléc tetejére rakódik.

Az FDDI vagy a Token Ring esetében a legtöbb protokollazonosítók szűrése során a tcpdump csak az SNAP formátumú LLC fejléc protokollazonosító mezőjét ellenőrzi egy 0x000000 szervezeti egység azonosítóval (OUI) a kapszulázott Ethernethez; nem ellenőrzi, hogy a csomag SNAP formátumban van-e 0x000000 OUI-val.

A kivételek az iso , amely ellenőrzi az LLC header, stp és netbeui DSAP (Destination Service Access Point) és SSAP (Source Service Access Point) mezőket, ahol ellenőrzi az LLC fejléc DSAP-jét és az atátot , ahol ellenőrzi a SNAP-formátumú csomagot 0x080007-es OUI-val és az Appletalk etype-rel.

Az Ethernet esetében a tcpdump ellenőrzi az Ethernet típusú mezőt a legtöbb protokollhoz; a kivételek az iso , a sap és a netbeui , amelyekhez egy 802.3 keret ellenőrzi, majd ellenőrzi az LLC fejlécet, mint az FDDI és Token Ring, atalk esetében , ahol az Appletalk etype egy Ethernet keretben és egy SNAP-formátumú csomagot, mint az FDDI és a Token Ring, aarp , ahol az Appletalk ARP etype-et ellenőrzi egy Ethernet keretben vagy egy 802.2 SNAP keretben 0x000000 és ipx OUI-val, ahol ellenőrzi az IPX etype-et egy Ethernet keret, az LLC fejlécben lévő IPX DSAP, az IPX címke nélküli 802.3 fejléc nélküli leképezés és az IPX etype egy SNAP keretben.]

decnet src host

Igaz, ha a DECNET forrás címe a gazdagép , amely lehet a "10.123" formátumú cím vagy a DECNET gazdagép neve. [A DECNET host név támogatás csak olyan Ultrix rendszereken érhető el, amelyek konfigurálva vannak a DECNET futtatásához.]

decnet dst host

Igaz, ha a DECNET célcím a gazda .

decnet fogadó host

Igaz, ha a DECNET forrás vagy rendeltetési cím a fogadó .

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

Rövidítések:

éter proto p

ahol p a fenti protokollok egyike.

lat , moprc , mopdl

Rövidítések:

éter proto p

ahol p a fenti protokollok egyike. Ne feledje, hogy a tcpdump jelenleg nem tudja, hogyan kell ezeket a protokollokat elemezni.

vlan [vlan_id]

Igaz, ha a csomag IEEE 802.1Q VLAN csomag. Ha a [vlan_id] meg van adva, csak a true a csomag a megadott vlan_id . Megjegyezzük, hogy az első vlan kulcsszó az expresszióban megváltoztatja a dekódolási eltolódásokat a fennmaradó kifejezésre azon a feltevésen, hogy a csomag VLAN csomag.

tcp , udp , icmp

Rövidítések:

ip proto p vagy ip6 proto p

ahol p a fenti protokollok egyike.

iso proto protokoll

Igaz, ha a csomag egy protokol típusú protokoll OSI-csomagja. A protokoll lehet egy vagy több név, például clnp , esis vagy isis .

clnp , esis , isis

Rövidítések:

iso proto p

ahol p a fenti protokollok egyike. Vegye figyelembe, hogy a tcpdump nem teljes munkát végez ezen protokollok értelmezésében.

expr relop expr

Igaz, ha a reláció tartja, ahol a relop az>, <,> =, <=, = ,! = És az expr egy számtani kifejezés, amely egész C-szintaxisban van kifejezve, a normál bináris operátorok [+ , -, *, /, &, |], egy hosszabb operátort és speciális csomagkapcsolt adatot. A csomagon belüli adatok eléréséhez használja a következő szintaxist:

proto [ expr : méret ]

A proto az éter, a fddi, a tr, a ppp, a slip, a link, az ip, az arp, a rarp, a tcp, az udp, az icmp vagy az ip6 egyike , és jelöli az index művelet protokollréteget. (az éter, a fddi, a tr, a ppp, a csúszka és a link mind a hivatkozási rétegre vonatkoznak.) A tcp, az udp és az egyéb felső szintű protokolltípusok csak az IPv4-re vonatkoznak, és nem az IPv6-ra (ez a jövőben rögzíthető). A jelzett protokollréteghez képest a byte offset értéke expr . A méret opcionális, és jelzi a bájtok számát a kívánt területen; lehet egy, kettő vagy négy, és az alapértelmezett egy. A hosszú operátor, amelyet a len címszó jelez, megadja a csomag hosszúságát.

Például az ' éter [0] & 1! = 0 ' elkapja az összes multicast forgalmat. Az ' ip [0] & 0xf! = 5 ' kifejezés elkap minden opciót tartalmazó IP-csomagot. Az ' ip [6: 2] & 0x1fff = 0 ' kifejezés csak a nem töredezett datagramokat és a töredezett datagramok fragmentumát ragadja meg. Ezt az ellenőrzést implicit módon alkalmazzák a tcp és udp index műveletekre. Például, tcp [0] mindig a TCP fejléc első bájtja, soha nem jelenti a beavatkozó töredék első bájtját.

Bizonyos eltolások és mezőértékek nevekként, nem pedig numerikus értékekként fejezhetők ki. A következő protokollfejléc-mezők eltolások állnak rendelkezésre: icmptype (ICMP típusú mező), icmpcode (ICMP kódmező ) és tcpflags (TCP flags mező).

A következő ICMP típusú mezőértékek állnak rendelkezésre: icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp-redirect , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp -nem olvasható , icmp-ireq , icmp-ireqreply , icmp-maszk , icmp-maszkolás .

A következő TCP jelző mező értékek állnak rendelkezésre: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-sürű .

A primitívek kombinálhatók:

A primitívek és az operátorok zárócsoportja (a zárójelek speciálisak a Shell-hez és meg kell szüntetni őket).

Negáció (` ! 'Vagy' nem ').

Összekötés (` && ' vagy` és ').

Alternatíva (` || 'vagy' vagy ').

A negáció legmagasabb előnyt élvez. Az alternáció és a kapcsolódás egyenlő előnyt élvez és balról jobbra kapcsolódik. Felhívjuk a figyelmet arra, hogy explicit és tokenek, nem egymás mellé helyezése szükséges a kötéshez.

Ha az azonosítót kulcsszó nélkül adják meg, akkor a legutóbbi kulcsszó feltételezhető. Például,

nem pedig host vs és ász

rövid

nem a host vs és a host ász

amelyet nem szabad összetéveszteni

nem (host vs vagy ász)

Az expressziós argumentumokat tcpdumpként adhatjuk át egyetlen argumentumként vagy többféle argumentumként, attól függően, hogy melyik a legegyszerűbb. Általában, ha a kifejezés Shell metakaraktereket tartalmaz, akkor egyszerűbb, mint egyetlen, idézett argumentum. Több érvet összefésülnek a terekkel, mielőtt elemeznék.

PÉLDÁK

A naplementével érkező vagy onnan távozó összes csomag kinyomtatása:

tcpdump fogadó napnyugta

Forgalom a hélium és a forró vagy az ász közötti forgalom kinyomtatásához:

tcpdump host helios és \ (forró vagy ász)

Az összes IP-csomag kinyomtatása az ász és bármely host között, kivéve a heliókat :

tcpdump ip host ász és nem hélium

A Berkeley helyi gazdagépek és házigazdák közötti összes forgalom kinyomtatása:

tcpdump net ucb-éter

Az összes ftp forgalom kinyomtatása az internetes gateway snup- on keresztül: (vegye figyelembe, hogy a kifejezés a zárójelek (helytelen) értelmezésének megakadályozására hivatkozik:

tcpdump 'gateway snup és (port ftp vagy ftp-data)'

Forgalom kinyomtatásához sem a helyi gazdagépektől származó, sem arra nem irányzott forgalom (ha egy másik hálóba átjársz, akkor ez a cucc soha ne tegye a helyi hálózatra).

tcpdump ip és nem net localnet

Az egyes TCP-beszélgetések kezdő és záró csomagjainak (a SYN és a FIN csomagok) kinyomtatása, amely nem helyi gazdagépet foglal magában.

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

A gateway snup- on keresztül küldött 576 bájtnál hosszabb IP-csomagok kinyomtatása:

tcpdump 'gateway snup és ip [2: 2]> 576'

IP-sugárzás vagy multicast csomagok nyomtatása, amelyeket nem ethernet broadcast vagy multicast küldött:

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

Az összes olyan ICMP csomag nyomtatása, amelyek nem echo kérések / válaszok (pl. Nem ping csomagok):

tcpdump 'icmp [icmptype]! = icmp-echo és icmp [icmptype]! = icmp-echoreply'

KIMENETI FORMÁTUM

A tcpdump kimenete protokollfüggő. Az alábbiakban rövid leírást és példákat adunk a legtöbb formátumra.

Link szintű fejlécek

Ha az '-e' opciót megadja, a hivatkozás szintű fejléc kinyomtatható. Az ethernetsen a forrás- és célcímek, a protokoll és a csomaghossz nyomtatódik.

Az FDDI hálózatokon az "-e" opció a tcpdump parancsot adja ki a "frame control" mező, a forrás és cél címek, valamint a csomaghossz nyomtatásához. (A `frame control 'mező a többi csomag értelmezését szabályozza, a normál csomagok (például az IP-datagramokat tartalmazóak)" async "csomagok, amelyek prioritási értéke 0 és 7 közé esik , például az async4 . a csomagok feltételezik, hogy tartalmaznak egy 802.2 Logical Link Control (LLC) csomagot, az LLC fejlécet kinyomtatják, ha nem egy ISO-adatgram vagy egy úgynevezett SNAP-csomag.

A Token Ring hálózatokon az "-e" opció a tcpdump parancsot adja ki a "hozzáférés-vezérlés" és "keretvezérlés" mező, a forrás- és célcímek és a csomaghossz nyomtatásához. Mint az FDDI hálózatok esetében, a csomagok feltételezik, hogy tartalmaznak egy LLC csomagot. Függetlenül attól, hogy a "-e" opció meg van-e adva vagy sem, a forrástervező információkat kinyomtatják a forrást tartalmazó csomagok számára.

(Megjegyzés: Az alábbi leírás feltételezi, hogy ismeri az RFC-1144-ben leírt SLIP tömörítési algoritmust.)

A SLIP kapcsolatokon kinyomtatható egy irányjelző ("I" a bejövő, "O" kimenő), csomagtípus és tömörítési információ. A csomag típusát először nyomtatja ki. A három típus az ip , a utcp és a ctcp . Az ip csomagokra további hivatkozási adatok nem kerülnek kinyomtatásra. TCP csomagok esetén a kapcsolatazonosító a típus után nyomtatódik. Ha a csomag tömörül, a kódolt fejléc kinyomtatható. A speciális eseteket * S + n és * SA + n kinyomtatja, ahol n az az összeg, amellyel a szekvencia száma (vagy a szekvencia száma és ack) megváltozott. Ha nem különleges eset, nulla vagy több változás nyomtatódik ki. A változást U (sürgős mutató), W (ablak), A (ack), S (sorszám) és I (csomagazonosító) jelzi, majd delta (+ n vagy -n) (= N). Végül kinyomtatják a csomagban található adatok mennyiségét és a tömörített fejléc hosszát.

Például a következő sor egy kimenő, tömörített TCP csomagot jelenít meg, amelynek implicit kapcsolódási azonosítója van; az ack 6-mal, a sorszám 49-szel és a csomag azonosítóval 6-ra változott; 3 bájt adat és 6 bájt tömörített fejléc van:

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

ARP / RARP csomagok

Az Arp / rarp kimenet mutatja a kérés típusát és annak érveit. A formátum öncélú. Itt van egy rövid minta, amelyet a rtsg- ről a host csam-ra a rlogin kezdetétől vettünk :

arp who-has csam mondja rtsg arp válasz csam is-a CSAM

Az első sor azt mondja, hogy az rtsg egy arp csomagot küldött, amely az internetes csatorna ethernet címét kérte. Csam válaszol az ethernet címével (ebben a példában az ethernet címek kisbetűkben és internetcímekben vannak feltüntetve).

Ez kevésbé lenne redundáns, ha tcpdump -n- t csináltunk:

arp who-has 128.3.254.6 say 128.3.254.68 arp válasz 128.3.254.6 is-at 02: 07: 01: 00: 01: c4

Ha tcpdump -e- t csináltunk, akkor látható lesz az a tény, hogy az első csomagot sugározzák, és a második a pont-pont,

RTSG Broadcast 0806 64: arp who-csam mondja rtsg CSAM RTSG 0806 64: arp válasz csam is-a CSAM

Az első csomag esetében ez azt mondja, hogy az ethernet forrás címe RTSG, a címzett az ethernet broadcast cím, a hex 0806 típusú típus (ETHER_ARP típus) és a teljes hossza 64 byte volt.

TCP csomagok

(Megjegyzés: Az alábbi leírás feltételezi, hogy ismeri az RFC-793-ban leírt TCP protokollt. Ha nem ismeri a protokollt, sem ez a leírás, sem pedig a tcpdump nem fog sok mindent használni.)

A TCP protokoll általános formátuma a következő:

src> dst: flags data-seqno ack ablak sürgős lehetőségek

Src és dst a forrás és cél IP címek és portok. A zászlók az S (SYN), az F (FIN), a P (PUSH) vagy az R (RST) vagy az egyetlen `. ' (nincs zászló). Az adat-seqno leírja a csomagban lévő adatok által lefedett szekvencia tér részét (lásd az alábbi példát). Az Ack a következő adatok sorozatszámát várták a másik irányban ezen a kapcsolaton. Az ablak a rendelkezésre álló fogadási pufferhely bájtjainak száma, amely a másik irányba rendelkezésre áll ezen a kapcsolaton. Az Urg azt jelzi, hogy a csomagban "sürgős" adatok vannak. Az opciók a tcp opciók, amelyek zárójelben vannak (pl. ).

Src, dst és zászlók mindig jelen vannak. A többi mező a csomag tcp protokolljának fejlécétől függ, és csak akkor adható ki, ha szükséges.

Itt van a rlogin megnyitó része a gazdagép rtsg- től a csam hostig .

rtsg.1023> csam.login: S 768512: 768512 (0) nyer 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 nyer 4096 rtsg.1023> csam. Belépés: . ack 1 nyer 4096 rtsg.1023> csam.login: P 1: 2 (1) ack 1 győzelem 4096 csam.login> rtsg.1023:. ack 2 nyer 4096 rtsg.1023> csam.login: P 2:21 (19) ack 1 nyer 4096 csam.login> rtsg.1023: P 1: 2 (1) ack 21 győzelem 4077 csam.login> rtsg.1023: P 2: 3 (1) ack 21 nyer 4077 sürgős 1 csam.login> rtsg.1023: P 3: 4 (1) ack 21 nyer 4077 sürgős 1

Az első sor azt mondja, hogy az rtsg 1023-as tcp portja küldött egy csomagra csatornak a bejelentkezéshez . Az S jelzi, hogy a SYN zászló be van állítva. A csomag sorszáma 768512 volt, és nem tartalmazott adatokat. (A jelölés az "első: utolsó (nbytes)", ami azt jelenti, hogy "a sorszámok első , de legutóbb nem az utolsó, amely a nbytes bytes felhasználói adatok".) Nem volt piggy-backed ack, a rendelkezésre álló vételi ablak 4096 bájt volt volt egy max. szegmens-méretű opció, amely 1024 bájtos msec-ot kér.

Csam egy hasonló csomaggal válaszol, kivéve, hogy tartalmaz egy malacka által támogatott ackot az rtsg SYN-jéhez. Az RTSG ezután a csam SYN-jét hallja. A `. ' azt jelenti, hogy nincsenek jelzők. A csomag nem tartalmaz adatokat, így nincs adatszekvencia-szám. Megjegyezzük, hogy az ack szekvenciaszám egy kicsi egész szám (1). Az első alkalommal, amikor a tcpdump egy tcp `conversationt 'lát, a sorozatszámot kinyomtatja a csomagról. A beszélgetés következő csomagjain az aktuális csomag sorszáma és a kezdeti sorszám közötti különbség kerül kinyomtatásra. Ez azt jelenti, hogy a szekvenciaszámok az első után értelmezhetők relatív bájtpozíciókként a beszélgetés adatfolyamában (az első adatbájt mindegyik iránya "1"). A `-S 'felülbírálja ezt a funkciót, ami az eredeti sorozatszámok kimenetét eredményezi.

A 6. sorban az rtsg 19 bájtos adatbájtot küld (bájt 2-től 20-ig a beszélgetés rtsg -> csam oldalán). A PUSH zászló a csomagban van beállítva. A 7. sorban a csam azt mondja, hogy az rtsg által küldött, de a 21. bájttól nem érkező adatokat érinti. A legtöbb ilyen adat láthatóan a socket pufferben van, mivel a csam vételi ablakának 19 bájtja kisebb. Csam egy adat bájtot is küld rtsg-nek ebben a csomagban. A 8. és a 9. sorban a csam két bájt sürgős, nyomott adatokat küld az rtsg-nek.

Ha a pillanatfelvétel elég kicsi volt ahhoz, hogy a tcpdump ne ragadja meg a teljes TCP fejlécet, akkor annyira értelmezi a fejlécet, amennyit csak tud, majd jelentést készít a `` [ tcp ] '' jelzi, hogy a maradék nem értelmezhető. Ha a fejléc egy hamis opciót tartalmaz (egy olyan hosszúságú, amely túl kicsi vagy a fejléc vége felett van), a tcpdump azt jelenti, hogy "[ rossz opt ]", és nem értelmez további opciókat (mivel lehetetlen megmondani ahol indulnak). Ha a fejléc hossza jelzi, hogy a beállítások jelen vannak, de az IP datagramhossz nem elég hosszú ahhoz, hogy a lehetőségek valóban ott legyenek, a tcpdump a `` [ bad hdr length ] '' értéket jelenti.

TCP csomagok rögzítése speciális zászló kombinációkkal (SYN-ACK, URG-ACK stb.)

A TCP fejléc vezérlő bitrészében 8 bit található:

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

Tegyük fel, hogy a TCP kapcsolat létrehozásához használt csomagokat szeretnénk megtekinteni. Emlékezzünk vissza, hogy a TCP egy 3-utas kézfogási protokollt használ, amikor inicializálja az új kapcsolatot; a TCP vezérlő bitekkel kapcsolatos kapcsolódási sorrend

1) A hívó elküldi a SYN-t

2) A címzett válaszol SYN, ACK

3) A hívó elküldi az ACK-t

Most olyan csomagok rögzítésére vagyunk kíváncsiak, amelyeknek csak a SYN bitkészlete van (1. lépés). Ne feledje, hogy a 2. lépéstől (SYN-ACK) nem csak csomagokat szeretnénk, hanem csak egy egyszerű SYN kódot. Amire szükségünk van, a tcpdump megfelelő szűrési kifejezése.

Emelje fel a TCP fejléc szerkezetét opciók nélkül:

0 15 31 ----------------------------------------------- ------------------ | forrás port | cél port | -------------------------------------------------- --------------- | sorszám | -------------------------------------------------- --------------- | nyugtázó szám | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | ablakméret | -------------------------------------------------- --------------- | TCP ellenőrzőösszeg | sürgős mutató | -------------------------------------------------- ---------------

A TCP fejléc általában 20 oktett adatot tartalmaz, hacsak nincsenek opciók. A grafikon első sorában 0 - 3 oktret tartalmaz, a második sor 4 - 7 okteteket mutat stb.

A 0-os számlálás megkezdéséhez a megfelelő TCP vezérlőbiteket a 13 oktett tartalmazza:

0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | ablakméret | ---------------- | --------------- | --------------- | - --------------- | | 13. oktáv | | |

Nézzük közelebbről a nyolc oktettet. 13:

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

Ezek a TCP vezérlõ bitek, amiket érdekel. A biteket ebben az oktatban 0-tól 7-ig, jobbra-balra számoljuk, így a PSH bit a bit száma 3, míg az URG bit az 5. szám.

Emlékezzünk arra, hogy csak SYN-készletű csomagokat akarunk elkülöníteni. Lássuk, mi történik a 13 oktettel, ha egy TCP datagram érkezik a fejlécében lévő SYN bithez:

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

A vezérlőbitek részében azt látjuk, hogy csak az 1. bitszám (SYN) van beállítva.

Feltételezve, hogy a 13. oktettszám egy 8 bites, nem előrejelzett egész szám a hálózati bájt sorrendben, akkor ennek az oktettnek a bináris értéke

00000010

és decimális ábrázolása

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

Már majdnem készen állunk, mert most már tudjuk, hogy ha csak SYN be van állítva, akkor a TCP fejlécben lévő 13. oktett értéke 8 bites unsigned integerként értelmezve a hálózati bájt sorrendben pontosan 2-nek kell lennie.

Ezt a kapcsolatot a következőképpen lehet kifejezni:

tcp [13] == 2

Ezt a kifejezést használhatjuk a tcpdump szűrőjeként annak érdekében, hogy olyan csomagokat lehessen nézni, amelyek csak SYN beállítást tartalmaznak:

tcpdump -i xl0 tcp [13] == 2

A kifejezés azt mondja, hogy "hagyja, hogy a TCP datagramma tizenharmadik oktettje a tizedes érték 2 legyen", ami pontosan azt akarja.

Tételezzük fel, hogy meg kell ragadnunk a SYN csomagokat, de nem törődünk vele, ha az ACK vagy bármely más TCP vezérlőbit egyszerre van beállítva. Lássuk, mi történik a 13. oktettel, amikor egy SYN-ACK készleten érkező TCP datagram érkezik:

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

Most az 1. és 4. bitek a 13. oktávban vannak beállítva. A 13 oktett bináris értéke

00010010

amely tizedesre változik

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

Most nem használhatjuk a tcpdump szűrő kifejezést a 'tcp [13] == 18' kifejezésre, mert csak azokat a csomagokat választanák, amelyeknek van SYN-ACK beállítása, de nem csak a SYN-készletűek. Ne felejtsük el, hogy az ACK vagy bármely más vezérlőbit beállításra kerül, amíg a SYN be van állítva.

A cél elérése érdekében logikusan ÉS a 13 oktett bináris értékét kell egy másik értékkel megőrizni a SYN bitet megőrizni. Tudjuk, hogy a SYN-t minden esetben meg akarjuk állítani, így logikusan és az értéket a 13. oktettben a SYN bináris értékével:

00010010 SYN-ACK 00000010 SYN ÉS 00000010 (SYN) és 00000010 (SYN-t akarunk) -------- -------- = 00000010 = 00000010

Látjuk, hogy ez az AND művelet ugyanazt az eredményt adja eredményre függetlenül attól, hogy az ACK vagy egy másik TCP vezérlőbit be van állítva. Az AND érték tizedes ábrázolása, valamint ennek a műveletnek a eredménye 2 (bináris 00000010), tehát tudjuk, hogy a SYN-vel rendelkező csomagok esetén a következő összefüggésnek igaznak kell lennie:

((oktett 13 értéke) ÉS (2)) == (2)

Ez a tcpdump szűrő kifejezésre mutat

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

Vegye figyelembe, hogy egy kifejezést vagy egy visszafordulót kell használni a kifejezésben, hogy elrejtse az AND ('&') különleges karaktert a shellből.

UDP Csomagok

Az UDP formátumot ez a rwho csomag mutatja:

actinide.who> broadcast.who: udp 84

Ez azt mondja, hogy a kikötő, aki a gazda- aktinidán udp-datagramot küldött a fogadó- közvetítéshez , az internetes közvetítési címhez. A csomag 84 bájtnyi felhasználói adatokat tartalmazott.

Néhány UDP szolgáltatás felismerésre kerül (a forrás vagy rendeltetési port száma) és a nyomtatott magasabb szintű protokollt. Különösen a Domain Name szolgáltatáskérelmek (RFC-1034/1035) és a Sun RPC hívások (RFC-1050) az NFS-re vonatkoznak.

UDP névkiszolgálói kérelmek

(Megjegyzés: Az alábbi leírás feltételezi, hogy ismeri az RFC-1035-ben ismertetett Domain Service protokollt. Ha nem ismeri a protokollt, az alábbi leírás görög nyelven íródott.)

A névkiszolgáló kérések formátuma a következő:

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

A h2opolo hosztoló megkérdezte a domino szervert a heliókon egy cím regisztráláshoz (qtype = A), amely az ucbvax.berkeley.edu névhez kapcsolódik. A lekérdezési azonosító "3" volt. A `+ 'jelzi a rekurzív kívánt zászló beállítását. A lekérdezés hossza 37 bájt volt, az UDP és IP protokoll fejlécek kivételével. A lekérdezés művelete normális volt, lekérdezés , így az op mező elmaradt. Ha az operáció bármi más volt, a "3" és a "+" között kinyomtatnák. Hasonlóképpen, a qclass a normális volt, C_IN és kihagyott. Minden más osztályt az "A" után azonnal kinyomtatnák.

Néhány anomáliát ellenőriztek, és több mezőt eredményezhetnek szögletes zárójelben: Ha egy lekérdezés tartalmaz egy választ, akkor a hatósági feljegyzések vagy további rekordok szekciója, ancount , nscount vagy arcount kinyomtatása "[ n a]", "[ n n ] "vagy" [ n au] ", ahol n a megfelelő szám. Ha a válasz bitek egyike (AA, RA vagy rcode), vagy bármelyik "must be zero" bit lesz beállítva két és három bájtban, akkor `[b2 & 3 = x ] 'nyomtatódik, ahol x a hex fejléc bájtok kettő és három.

UDP névszerver válaszok

A névkiszolgálói válaszok formátuma a következő:

src> dst: id op rcode zászlók a / n / au típusosztályadatok (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)

Az első példában a héliók a h2opolo 3-as lekérdezési rekordra, 3 névkiszolgáló rekordra és 7 további rekordra válaszolnak. Az első válaszrekord A (cím), és az adatai a 128.32.137.3 internetes cím. A válasz teljes mérete 273 bájt volt, az UDP és IP fejlécek kivételével. Az op (Query) és a válaszkód (NoError) kihagyásra került, mint az A rekord osztály (C_IN).

A második példában a heliók válaszolnak a 2. lekérdezésre a nem létező tartomány (NXDomain) válaszkódjával, válaszok nélkül, egy névszerver és nincs feljegyzés. A `* 'azt jelzi, hogy a hiteles válaszbit beállításra került. Mivel nem volt válasz, semmilyen típusú, osztály vagy adat nem lett kinyomtatva.

A megjelenő jelzők - `` (rekurzió elérhető, RA, nincs beállítva) és `| ' (csonkolt üzenet, TC, készlet). Ha a "kérdés" rész nem tartalmaz pontosan egy bejegyzést, akkor a "[ n q]" kerül kinyomtatásra.

Ne feledje, hogy a névkiszolgálói kérelmek és válaszok általában nagyok, és a 68 bájtos alapértelmezett snaplen nem elég a beolvasni kívánt csomagot. Használja a -s kapcsolót a snaplen növeléséhez, ha komolyan meg kell vizsgálnia a névszerver forgalmát. A ` -s 128 'jól működött számomra.

SMB / CIFS dekódolás

A tcpdump mostantól meglehetősen kiterjedt SMB / CIFS / NBT dekódolást tartalmaz az UDP / 137, UDP / 138 és TCP / 139 adatokhoz. Az IPX és a NetBEUI SMB adatok némelyik primitív dekódolása szintén megtörtént.

Alapértelmezés szerint viszonylag minimális dekódolást hajtunk végre, sokkal részletesebb dekódolást végzünk, ha -v használjuk. Figyelmeztetni kell, hogy -va egy SMB csomag akár egy vagy több oldalt is igénybe vehet, ezért csak a -v-t használja, ha valóban az összes komor részletet szeretné.

Ha dekódolja az unicode karakterláncokat tartalmazó SMB-munkameneteket, akkor az USE_UNICODE környezeti változót be kívánja állítani 1. Az unicode-ra való automatikus észlelésre szolgáló javítás üdvözlendő.

Az SMB csomagformátumokról és az összes te mezőről lásd: www.cifs.org vagy a pub / samba / specs / könyvtárat a kedvenc samba.org tüköroldalán. Az SMB javításokat Andrew Tridgell (tridge@samba.org) írta.

NFS kérések és válaszok

A Sun NFS (hálózati fájlrendszer) kérelmek és válaszok a következő formátumban kerülnek kinyomtatásra:

src.xid> dst.nfs: len op args src.nfs> dst.xid: válasz stat len ​​op találatok sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10,73165 wrl.nfs> sushi.6709: válasz ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 keresés fh 9,74 / 4096,6878 "xcolors" wrl.nfs> sushi.201b: válasz ok 128 keresés fh 9,74 / 4134,3150

Az első sorban a gazda sushi egy tranzakciót küldi az id 6709-hez a wrl-hez (megjegyzendő, hogy az src-állományt követő szám egy tranzakcióazonosító, nem pedig a forrásport). A kérelem 112 bájt volt, az UDP és IP fejlécek kivételével. A művelet egy readlink (olvasható szimbolikus link) a fájlkezelőben ( fh ) 21,24 / 10,731657119. (Ha valaki szerencsés, mint ebben az esetben, akkor a fájlkezelő fontos, kisebb eszközszámpárként értelmezhető, amelyet az inode szám és a generációs szám követ.) Wrl az "ok" -t a link tartalmával válaszolja meg.

A harmadik sorban a sushi arra kéri a wrl-t, hogy keresse meg a ` xcolors 'nevet a 9,74 / 4096,6878 könyvtárfájlban. Vegye figyelembe, hogy a nyomtatott adatok a művelettípustól függenek. A formátum az NFS protokoll specifikációjával együtt olvasva önmagától értendő.

Ha a -v (verbose) jelzés van megadva, további információk nyomtatódnak. Például:

sushi.1372a> wrl.nfs: 148 olvas fh 21,11 / 12.195 8192 bytes @ 24576 wrl.nfs> sushi.1372a: válasz ok 1472 olvasd el REG 100664 ids 417/0 sz 29388

(-v is kinyomtatja az IP fejléc TTL, ID, hosszúság és töredezettség mezőket, amelyeket elhagytak a példából.) Az első sorban a sushi arra kéri a wrl-et, hogy 8192 byte-ot olvasson a 21,11 / 12.195 fájlból a byte offset 24576. Wrl válaszok "ok"; a második sorban megjelenő csomag a válasz első töredéke, tehát csak 1472 bájt hosszú (a többi bájt a következő töredékekben következik be, de ezeknek a töredékeknek nincs NFS vagy akár UDP fejlécük, ezért nem nyomtathatók ki, a használt szűrő kifejezéstől függően). Mivel a -v jelzőt megadják, a fájl tulajdonságai közül néhányat (amelyeket a fájladatokon kívül visznek vissza) nyomtatnak ki: a fájl típusát ("REG", a rendszeres fájlhoz), a fájl módot (oktálisan) az uid és a gid, valamint a fájlméret.

Ha a -v jelzőt többször adják meg, akkor még több részletet nyomtatnak ki.

Ne feledje, hogy az NFS-kérelmek nagyon nagyok, és a részleteket nem fogják kinyomtatni, hacsak a snaplen nem nő. Próbálja meg használni a ` -s 192 'parancsot az NFS forgalom figyelése céljából.

Az NFS válasz csomagok nem határozzák meg kifejezetten az RPC műveletet. Ehelyett a tcpdump nyomon követi a `` legutóbbi '' kéréseket, és a tranzakciós azonosítót használva válaszol a válaszokra. Ha a válasz nem követi szorosan a megfelelő kérést, előfordulhat, hogy nem értelmezhető.

AFS kérelmek és válaszok

A Transarc AFS (Andrew File System) kérelmek és válaszok nyomtatása:

src.sport> dst.dport: rx csomagtípus src.sport> dst.dport: rx csomagtípusú szerviz hívás hívásnév args src.sport> dst.dport: rx csomagtípusú szolgáltatás válasz hívásnév args elvis. 7001> pike.afsfs: rx adat fs hívás átnevezése régi fid 536876964/1/1 ".newsrc.new" új fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx adat fs válasz átnevezés

Az első sorban az elvis fogadó RX csomagot küld a csukába. Ez egy RX adatcsomag az fs (fileserver) szolgáltatáshoz, és egy RPC hívás kezdete. Az RPC hívás átnevezés volt, az 536876964/1/1 régi könyvtárfájl azonosítója és a ".newsrc.new" régi fájlnév, valamint az 536876964/1/1 nevű új könyvtár azonosító és egy új fájlnév. newsrc”. A fogadó csuka egy RPC válaszral válaszol az átnevezésre (ami sikeres volt, mert adatcsomag volt, és nem abort csomag).

Általánosságban elmondható, hogy minden AFS RPC-t legalább az RPC hívás neve dekódol. A legtöbb AFS RPC-nek legalább néhány argumentuma van dekódolva (általában csak "érdekes" érvek, bizonyos érdekes definíciók esetén).

A formátum öncélú, de valószínűleg nem lesz hasznos azok számára, akik nem ismerik az AFS és az RX működését.

Ha a -v (verbose) jelzőt kétszer adják meg, akkor a visszaigazoló csomagok és további fejléc információk nyomtatódnak, például az RX hívás azonosítója, a hívószám, a sorozatszám, a sorozatszám és az RX csomagjelzők.

Ha a -v jelzőt kétszer adják meg, további információ nyomtatódik, például az RX hívás azonosítója, a sorozatszám és az RX csomagjelzők. Az MTU-tárgyalási információkat szintén RX ack csomagokból nyomtatják.

Ha a -v jelző háromszor van megadva, a biztonsági index és a szolgáltatásazonosító nyomtatódik.

A hibakódok nyomtatásra kerülnek az abort csomagok kivételével, az Ubik beacon csomagok kivételével (mert az abort csomagokat használják az Ubik protokollhoz való igen szavazásra).

Ne feledje, hogy az AFS-kérelmek nagyon nagyok, és sok argumentumot nem fog nyomtatni, hacsak a snaplen nem nő. Próbálja meg használni a ` -s 256 '-ot az AFS forgalom megtekintéséhez.

Az AFS válasz csomagok nem határozzák meg kifejezetten az RPC műveletet. Ehelyett a tcpdump nyomon követi a `` legutóbbi '' kéréseket, és megfelel a válaszoknak a hívószám és a szolgáltatás azonosító használatával. Ha a válasz nem követi szorosan a megfelelő kérést, előfordulhat, hogy nem értelmezhető.

KIP Appletalk (DDP UDP-ben)

Az UDP datagramba beágyazott Appletalk DDP csomagok de-encapsulated és DDP csomagokként dumped (azaz az összes UDP fejléc információ eldobható). A /etc/atalk.names fájl az appletalk net és a csomópontok nevek nevekhez való fordítására szolgál. A fájlban lévő sorok formája

szám név 1.254 éter 16.1 icsd-net 1.254.110 ace

Az első két sor ad appletalk hálózatok nevét. A harmadik sor egy adott gazdagép nevét adta meg (a gazdagép számmal a 3-os oktettől a hálótól megkülönböztetve - a nettó számnak két oktettnek kell lennie, és a gazdaszámnak három oktettje van.) A számot és a nevet külön kell választani a fehérek által (üres vagy lapos). Az /etc/atalk.names fájl üres sorokat vagy megjegyzéssort tartalmazhat (a sorok `# 'kezdődnek).

Az appletalk címek a következő formában kerülnek kinyomtatásra:

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

(Ha az /etc/atalk.names nem létezik, vagy nem tartalmaz bejegyzést néhány appletalk állomásnak / net számnak, akkor a címeket numerikus formában nyomtatja ki.) Az első példában az NBP (DDP port 2) a 144.1 a 209 csomó mindaddig küld, amit a 112 icsd 112 csomópont 220-as portján hallgat. A második vonal ugyanaz, kivéve, hogy a forrás csomópont teljes neve ismert ("office"). A harmadik vonal a 235-ös porton a jssmag 149 csomóponthoz küldött üzenet küldésére a icsd-net NBP porton (vegye figyelembe, hogy a broadcast címet (255) egy nettó név jelöli, amely nem tartalmaz gazdaszámot - ezért jó ötlet hogy megőrizze a csomópontneveket és a netneveket az /etc/atalk.names-ban).

Az NBP (névkötési protokoll) és az ATP (Appletalk tranzakciós protokoll) csomagok tartalmát értelmezik. Az egyéb protokollok csak a protokoll nevét (vagy a számot, ha nincs név a protokollban) és a csomag mérete.

Az NBP csomagok a következő példákhoz hasonlóan vannak formázva:

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-válasz 190: "techpit: LaserWriter @ *" 186

Az első sor a net icsd 112 fogadó által küldött lézerírók névkeresési kérelme és a net jssmag sugárzása. A keresési kifejezés nbp-idje 190. A második sor egy erre a kérésre adott választ (megjegyzi, hogy azonos azonosítója van) a jssmag.209 állomásról, mondván, hogy rendelkezik egy 250-es porton regisztrált "RM1140" nevű lézeríró-erőforrással. A harmadik line egy másik válasz ugyanarra a kérelemre, miszerint a gazdagép a 186-os porton regisztrált "techpit" lézernyomtatóval rendelkezik.

Az ATP csomag formázását az alábbi példában mutatjuk be:

jssmag.209.165> heliosz.132: atp-req 12266 <0-7> 0xae030001 heliosz.132> jssmag.209.165: atp-resp 12266: 0 (512) 0xae040000 heliosz.132> jssmag.209.165: atp-resp 12266: 1 (512) 0xae040000 heliosz.132> jssmag.209.165: atp-resp 12266: 2 (512) 0xae040000 heliosz.132> jssmag.209.165: atp-resp 12266: 3 (512) 0xae040000 heliosz.132> jssmag.209.165: atp- resp 12266: 4 (512) 0xae040000 heliosz.132> jssmag.209.165: atp-resp 12266: 5 (512) 0xae040000 heliosz.132> jssmag.209.165: atp-resp 12266: 6 (512) 0xae040000 heliosz.132> jssmag. 209.165: atp-resp * 12266: 7 (512) 0xae040000 jssmag.209.165> heliosz.132: atp-req 12266 <3,5> 0xae030001 heliosz.132> jssmag.209.165: atp-resp 12266: 3 (512) 0xae040000 heliosz .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

A Jssmag.209 12266 tranzakciós azonosítót kezdeményez a gazda héliumokkal, legfeljebb 8 csomag (a `<0-7> ') kérésével. A sor végén lévő hex szám a kérés "userdata" mező értéke.

A Helios 8 512 bájtos csomagokkal válaszol. A tranzakcióazonosítót követő `: digit 'adja meg a tranzakcióban a csomagszekvencia számát, és a parensben lévő szám az adatmennyiség a csomagban, az atp fejléc kivételével. A 7-es csomag "*" jelzi, hogy az EOM bit beállításra került.

A Jssmag.209 azt kéri, hogy a 3 és 5 csomagokat továbbítsák. A Helios újra elküldi őket, majd a jssmag.209 kiadja a tranzakciót. Végül a jssmag.209 kezdeményezi a következő kérést. A kérés "*" jelzi, hogy XO (`exactly once ') nincs beállítva.

IP töredezettség

A töredezett internetes datagramokat a következőképpen nyomtatják

(fragment id : méret @ offset +) (fragment id : méret @ offset )

(Az első forma azt jelzi, hogy több töredék van, a második azt jelzi, hogy ez az utolsó rész.)

Id a fragment id. A méret a fragmentum mérete (byte-ban) az IP fejléc kivételével. Az offset a fragmentum offsetje (byte-ban) az eredeti datagramban.

A töredékinformációkat minden egyes fragmenshez továbbítják. Az első rész a magasabb szintű protokoll-fejlécet tartalmazza, és a frag info a protokollinformáció után nyomtatódik. Az első frakciók nem tartalmaznak magasabb szintű protokoll-fejlécet, a frag info pedig a forrás- és célcímek után kerül kinyomtatásra. Például itt van egy ftp az arizona.edu-ról a lbl-rtsg.arpa-ra egy olyan CSNET kapcsolat felett, amely nem úgy tűnik, hogy 576 bájtos datagramokat kezel:

arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 win 4096 (frag 595a: 328 @ 0 +) arizona> rtsg: (frag 595a: 204 @ 328) rtsg.1170> arizona.ftp-adatok:. ack 1536 nyer 2560

Van itt néhány dolog: Először is, a 2. sorban szereplő címek nem tartalmazzák a portszámokat. Ez azért van, mert a TCP protokollinformációk mind az első töredékben vannak, és fogalmunk sincs, mi a port vagy a sorozatszám, amikor kinyomtuk a későbbi töredékeket. Másodszor, a tcp szekvenciainformáció az első sorban úgy van kinyomtatva, mintha 308 bájtnyi felhasználói adat lenne, amikor valójában 512 bájt (308 az első fragmentumban és 204 a másodikban). Ha lyukakat keres a szekvencia térben, vagy megpróbál összeilleszteni a csomagokat, ez csalhat.

Az IP-vel ellátott csomag nem töredezett zászlót jelöli hátulról (DF) .

Időbélyegek

Alapértelmezés szerint minden kimeneti sor előzi meg egy időbélyegzőt. Az időbélyeg az aktuális órajel a formában

hh: mm: ss.frac

és olyan pontos, mint a rendszermag óra. Az időbélyeg azt a időpontot tükrözi, amikor a rendszermag először látta a csomagot. Nem történt kísérlet arra, hogy figyelembe vegyük azt az időeltolódást, amikor az ethernet interfész eltávolította a csomagot a vezetékről, és amikor a rendszermag átadta az "új csomag" megszakítását.

LÁSD MÉG

közlekedés (1C), nit (4P), bpf (4), pcap (3)

Fontos: Az ember paranccsal ( % man ) tekintse meg, hogyan használják a parancsot az adott számítógépen.