Tcpdump: Eksempler, Valg og Mere

Tcpdump er en kommando, der bruges på forskellige Linux operativsystemer (OS'er), der samler TCP / IP-pakker, der passerer via en netværksadapter. Som et pakkesnifferværktøj kan tcpdump ikke kun analysere netværkstrafikken, men også gemme den til en fil.

I modsætning til nogle kommandoer, der leveres af operativsystemet som standard, kan du opleve, at du ikke kan bruge tcpdump, fordi den ikke er installeret. For at installere tcpdump, udfør apt-get install tcpdump eller yum installere tcpdump, afhængigt af dit operativsystem.

Sådan fungerer Tcpdump

Tcpdump udskriver overskrifterne af pakker på en netværksgrænseflade, der matcher den boolske ekspression . Det kan også køres med-w flag, hvilket gør det muligt at gemme pakkedataene til en fil til senere analyse og / eller med-r flag, hvilket får det til at læse fra en gemt pakkefil i stedet for at læse pakker fra en netværksgrænseflade. I alle tilfælde kun pakker, der matcher ekspression vil blive behandlet af tcpdump .

tcpdump vil, hvis ikke køre med-c flag, fortsæt med at fange pakker, indtil det afbrydes af et SIGINT-signal (genereret f.eks. ved at skrive dit afbrydelseskarakter typisk Ctrl + C) eller et SIGTERM signal (typisk genereret meddræbe(1) kommando); hvis køre med-c flag, vil det fange pakker, indtil det afbrydes af et SIGINT- eller SIGTERM-signal eller det specificerede antal pakker er blevet behandlet.

De ovennævnte omskiftere forklares detaljeret senere i denne artikel.

Hvornår tcpdump Afslutter fange pakker, vil det rapportere tæller af:

• Pakker "modtaget af filter."
  • Betydningen af ​​dette afhænger af det operativsystem, som du kører på tcpdump , og muligvis på den måde, operativsystemet blev konfigureret. Hvis et filter blev angivet på kommandolinjen, tæller det på nogle OS'er pakker, uanset om de blev matchet af filterudtrykket, og på andre tæller det kun pakker, der matches af filterudtrykket og blev behandlet af tcpdump.
• Pakker "faldt af kernen".
  • Dette er antallet af pakker, der blev tabt på grund af manglende bufferrum, ved pakkefangstmekanismen i operativsystemet, på hvilket tcpdump kører, hvis operativsystemet rapporterer disse oplysninger til applikationer. Hvis ikke, vil det blive rapporteret som 0.

På platforme, der understøtter SIGINFO-signalet, som de fleste BSD'er (Berkeley Software Distributions), vil det rapportere disse tæller, når det modtager et SIGINFO-signal (genereret f.eks. Ved at skrive dit "status" -karakter typisk Ctrl + T) og vil fortsætte med at fange pakker.

Tcpdump Kompatibilitet

Læsning af pakker fra en netværksgrænseflade med tcpdump-kommandoen kan kræve, at du har særlige rettigheder ( læsning en gemt pakkefil kræver ikke sådanne privilegier):

• SunOS 3.x eller 4.x med NIT eller BPF: Du skal have læseadgang til / Dev / nit eller dev / BPF * .
• Solaris med DLPI: Du skal have læse / skriveadgang til netværkspseudo-enheden, som / Dev / le . På mindst nogle versioner af Solaris er dette dog ikke tilstrækkeligt til at tillade tcpdump at fange i promiscuous mode; På disse versioner af Solaris skal du være root eller tcpdump skal installeres setuid til root, for at kunne optage i promiscuous mode. Bemærk at i mange (måske alle) grænseflader, hvis du ikke optager i promiskuøs tilstand, vil du ikke se nogen udgående pakker, så en optagelse, der ikke er gjort i promiskuøs tilstand, er muligvis ikke særlig nyttig.
• HP-UX med DLPI: Du skal være root eller tcpdump skal installeres setuid til root.
• IRIX med snoop: Du skal være root eller tcpdump skal installeres setuid til root.
• Linux: Du skal være root eller tcpdump skal installeres setuid til root.
• Ultrix og Digital UNIX / Tru64 UNIX: Enhver bruger kan fange netværkstrafik med tcpdump . Imidlertid kan ingen bruger (ikke engang superbrugeren) optage i promiskuøs tilstand på en grænseflade, medmindre superbrugeren har aktiveret promiskuus-tilstandsoperation på den grænseflade ved brug af pfconfig (8), og ingen bruger (ikke engang superbrugeren) kan fange unicast-trafik modtaget af eller sendt af maskinen på en grænseflade, medmindre superbrugeren har aktiveret kopi-all-mode-drift på den grænseflade ved brug af pfconfig , så nyttig Pakkeopsamling på en grænseflade kræver sandsynligvis, at enten promiscuous-mode eller copy-all-mode-drift eller begge driftsformer er aktiveret på den grænseflade.
• BSD: Du skal have læseadgang til / Dev / BPF * .

Tcpdump Command Syntax

Ligesom alle computerkommandoer fungerer tcpdump-kommandoen kun korrekt, hvis syntaksen er korrekt:

tcpdump -adeflnNOpqRStuvxX -c tælle

-C filstørrelse -F fil

-jeg grænseflade -m modul -r fil

-s snaplen -T type -U bruger -w fil

-E algo: hemmeligt ekspression

Tcpdump kommando indstillinger

Dette er alle de muligheder, du kan bruge med tcpdump-kommandoen:

• -en: Forsøg at konvertere netværks- og udsendelsesadresser til navne.
• -c: Afslut efter modtagelse tælle pakker.
• -C: Før du skriver en rå pakke til en savefile, skal du kontrollere om filen er større end filstørrelse og i bekræftende fald lukke den aktuelle gemfil og åben en ny.Savefiles efter den første gemfil vil have det navn, der er angivet med-w flag, med et nummer efter det, starter ved 2 og fortsætter opad. Enhederne i filstørrelse er millioner af bytes (1.000.000 bytes, ikke 1.048.576 bytes).
• -d: Dump den kompilerede pakke-matchende kode i en læsbar form til standard udgang og stop.
• -dd: Dump pakke-matchende kode som enC programfragment.
• DDD: Dump pakke-matchende kode som decimaltal (forud for et tal).
• -e: Udskriv koblingsniveauhovedet på hver dumpelinie.
• -E: Brug algo: hemmeligt til dekryptering af IPsec ESP-pakker. Algoritmer kan væredes-cbc, 3DES-cbc, blowfish-cbc, RC3-cbc, cast128-cbc, elleringen. Standard erdes-cbc. Evnen til at dekryptere pakker er kun til stede, hvis tcpdump blev kompileret med kryptografi aktiveret. hemmelighed Ascii-teksten til ESP-hemmelig nøgle. Vi kan ikke tage vilkårlig binær værdi for øjeblikket. Muligheden antager RFC2406 ESP, ikke RFC1827 ESP. Muligheden er kun til fejlfinding, og brugen af ​​denne mulighed med virkelig 'hemmelig' nøgle er modløs. Ved at præsentere IPsec hemmelig nøgle på kommandolinjen gør du den synlig for andre via ps (1) og andre lejligheder.
• -f: Udskriv 'udenlandske' internetadresser numerisk frem for symbolsk (denne mulighed er beregnet til at omgå alvorlige hjerneskade i Suns yp-server - normalt hænger det for evigt at oversætte nonlocal internetnumre).
• -F: Brug fil som input til filterudtrykket. Et ekstra udtryk angivet på kommandolinjen ignoreres.
• -jeg: Lyt videre grænseflade . Hvis uspecificeret, tcpdump søger i systemgrænsefladens liste for den laveste nummererede konfigurerede grænseflade (ekskl. loopback). Slips er brudt ved at vælge den tidligste kamp. På Linux-systemer med 2.2 eller nyere kerner, an grænseflade argumentet om "nogen" kan bruges til at indfange pakker fra alle grænseflader. Bemærk, at fange på "nogen" enheden ikke vil blive udført i promiskuøs tilstand.
• -l: Gør stdout line bufret. Nyttigt, hvis du vil se dataene, mens du fanger det. For eksempel "tcpdump -l | tee dat" eller "tcpdump -l> dat & tail -f dat".
• -m: Indlæs SMI MIB-moduldefinitioner fra fil modul . Denne mulighed kan bruges flere gange for at indlæse flere MIB moduler tcpdump .
• -n: Konverter ikke værtsadresser til navne. Dette kan bruges til at undgå DNS ​​opslag.
• -Nn: Konverter ikke protokoll- og portnumre mv. Til navne heller.
• N: Udskriv ikke domænenavnskvalifikation af værtsnavne. For eksempel, hvis du giver dette flag, så tcpdump vil udskrive "nic" i stedet for "nic.ddn.mil".
• -O: Kør ikke pakke-matching kode optimizer. Dette er kun nyttigt, hvis du har mistanke om en fejl i optimeringsprogrammet.
• -p: Må ikke sæt grænsefladen i promiskuøs tilstand. Bemærk, at grænsefladen måske er i promiskuøs tilstand af en anden årsag; Derfor kan '-p' ikke bruges som en forkortelse for 'etherhost {local-hw-addr} eller ether broadcast'.
• -q: Hurtig (stille) udgang. Udskriv mindre protokolloplysninger, så udgangslinjerne er kortere.
• -R: Antag, at ESP / AH-pakker skal baseres på den gamle specifikation: RFC1825 til RFC1829. Hvis angivet, tcpdump vil ikke udskrive replay forebyggelsesfelt. Da der ikke er nogen protokolversionsfelt i ESP / AH-specifikationen, tcpdump kan ikke udlede versionen af ​​ESP / AH-protokollen.
• -r: Læs pakker fra fil (som blev oprettet med -w indstillingen). Standardindgang bruges hvis fil er "- ''.
• -S: Udskriv absolut, snarere end relativ, TCP sekvensnumre.
• -s: Snarf snaplen bytes data fra hver pakke i stedet for standard på 68; med SunOS NIT er minimumet faktisk 96. Seksogogs bytes er tilstrækkelig til IP, ICMP, TCP og UDP, men kan afkorte protokolloplysninger fra navneserver og NFS-pakker (se nedenfor). Pakker afkortet på grund af et begrænset øjebliksbillede er angivet i udgangen med "| proto '', hvor proto er navnet på det protokolniveau, hvor afkortningen er sket. Bemærk, at når du tager større øjebliksbilleder, øges mængden af ​​tid, der kræves for at behandle pakker, og reducerer effektivt mængden af ​​pakkebuffering. Dette kan medføre, at pakker går tabt. Du bør begrænse snaplen til det mindste antal, der vil fange de protokoloplysninger, du er interesseret i. Indstilling snaplen til 0 betyder brug af den nødvendige længde for at fange hele pakker.
• -T: Force pakker udvalgt af " ekspression "fortolkes den angivne type . For øjeblikket kendte typer ercnfp (Cisco NetFlow-protokol)rpc (Remote Procedure Call),RTP (Protokollen i realtidsprogrammer)RTCP (Real-Time Applications kontrolprotokol),snmp (Simple Network Management Protocol),moms (Visual Audio Tool) ogwb (uddelt White Board).
• -t: Må ikke Udskriv en tidsstempel på hver dumpelinie.
• -tT: Udskriv en uformateret tidsstempel på hver dumpelinie.
• -U: Drops root privilegier og ændrer bruger ID til bruger og gruppe id til den primære gruppe af bruger .
• Bemærk: Red Hat Linux dropper automatisk privilegierne til brugeren "pcap", hvis intet andet er angivet.
• -ttt: Udskriv et delta (i mikrosekunder) mellem nuværende og forrige linje på hver dumpelinie.
• -tttt: Udskriv et tidsstempel i standardformat fremført med dato på hver dumpelinje.
• -u: Udskriv undecoded NFS håndtag.
• -v: (Lidt mere) verbose output. For eksempel udskrives tiden for at leve, identifikation, total længde og indstillinger i en IP-pakke. Tillader også yderligere pakkeintegritetskontroller, såsom verifikation af IP og ICMP header checksum.
• -vv: Endnu mere verbose output. F.eks. Udskrives yderligere felter fra NFS-svarpakker, og SMB-pakkerne er fuldt dekodet.
• -vvv: Endnu mere verbose output. For eksempel telnetSB … SE Indstillingerne udskrives fuldt ud. Med -X telnet muligheder er også trykt i hex.
• -w: Skriv de røde pakker til fil snarere end at analysere og udskrive dem. De kan senere udskrives med -r-indstillingen. Standard output bruges hvis fil er "- ''.
• -x: Udskriv hver pakke (minus dens linkniveau header) i hex. Den mindste af hele pakken eller snaplen bytes vil blive udskrevet. Bemærk, at dette er hele linklagspakken, så for linklag, der puden (f.eks. Ethernet), vil polstringsbytesne også blive udskrevet, når den højere lagspakke er kortere end den nødvendige polstring.
• -X: Når du udskriver hex, skal du også udskrive ascii. Således hvis-x er også indstillet, pakken er trykt i hex / ascii. Dette er meget praktisk til analyse af nye protokoller. Selvom-x er ikke også indstillet, nogle dele af nogle pakker kan udskrives i hex / ascii.
• ekspression : Vælger hvilke pakker der vil blive dumpet. Hvis nej ekspression er givet, vil alle pakker på nettet blive dumpet. Ellers kun pakker for hvilke ekspression er 'sande' vil blive dumpet. Det ekspression består af en eller flere primitiver. Primitiver består normalt af en id (navn eller nummer) forud for en eller flere kvalifikatorer. Der er tre forskellige slags kvalifikationer:
• type : Kvalifikatorer siger, hvad slags ting navnet eller nummeret refererer til. Mulige typer ervært, net, ogHavn-For eksempel 'vært foo', 'net 128,3', 'port 20'. Hvis der ikke er nogen type kvalifikation,vært antages.
• dir : Kvalifikatorer angiver en bestemt overførselsretning til og / eller fra id . Mulige anvisninger ersrc, DST, src eller dst ogsrc og DST (fx 'src foo', 'dst net 128,3', 'src eller dst port ftp-data'). Hvis der ikke er nogen dir-kvalifikation,src eller dst antages. For 'null'-linklag (dvs. punkt-til-punkt-protokoller såsom slip) indgående og udgående kvalifikatorer kan bruges til at angive en ønsket retning.
• proto : Kvalifikatorer begrænser kampen til en bestemt protokol. Mulige protos er: ether, FDDI, tr, ip, IP6, arp, RARP, DECnet, tcp, oguDPFor eksempel 'ether src foo', 'arp net 128,3', 'tcp port 21'. Hvis der ikke er nogen proto-kvalifikation, antages alle protokoller i overensstemmelse med typen. F.eks. Betyder 'src foo' 'ip eller arp eller rarp) src foo' (med undtagelse af sidstnævnte ikke en juridisk syntaks) betyder 'netlinje' '(ip eller arp eller rarp) netlinje' og 'port 53' betyder '(tcp eller udp) port 53'.
  • 'fddi' er faktisk et alias for 'ether'; parseren behandler dem identisk som "datalinkniveauet, der bruges på den angivne netværksgrænseflade." FDDI-overskrifter indeholder Ethernet-lignende kilde- og destinationsadresser og indeholder ofte Ethernet-lignende pakktyper, så du kan filtrere på disse FDDI-felter bare som med de analoge Ethernet-felter. FDDI-overskrifter indeholder også andre felter, men du kan ikke nævne dem eksplicit i et filterudtryk.
  • Tilsvarende er 'tr' et alias for 'ether'; de foregående afsnits erklæringer om FDDI-overskrifter gælder også for Token Ring-overskrifter.

Ud over ovenstående er der nogle specielle "primitive" søgeord, der ikke følger mønsteret:gateway, udsende, mindre, større, og aritmetik udtryk. Alle disse er beskrevet nedenfor.

Mere komplekse filter udtryk er opbygget ved at bruge ordeneog, eller, ogikke at kombinere primitiver-for eksempel "host foo og ikke port ftp og ikke port ftp-data". For at gemme skrivning kan identiske kvalifikationslister udelades (for eksempel "tcp dst port ftp eller ftp-data eller domæne" er nøjagtig det samme som "tcp dst port ftp eller tcp dst port ftp-data eller tcp dst port domain".)

Disse er primitiverne tilladt med tcpdump-kommandoen:

• dst vært vært
  • Sandt hvis IPv4 / v6 destinationsfeltet i pakken er vært , som kan være enten en adresse eller et navn.
• src vært vært
  • Sandt hvis IPv4 / v6-kildefeltet i pakken er vært .
• vært vært
  • Sandt, om enten IPv4 / v6-kilden eller destinationen for pakken er vært . Et hvilket som helst af de ovennævnte værtsudtryk kan udfyldes med søgeordene,ip, arp, RARP, ellerIP6, som i ip vært vært (hvilket svarer til etherproto ip og vært vært).
  • Hvis vært er et navn med flere IP-adresser, vil hver adresse blive tjekket for en kamp.
• ether dst ehost
  • Sandt hvis Ethernet-destinationsadressen er ehost . Ehost kan enten være et navn fra / etc / ethers eller et nummer (se ethere (3N) til numerisk format).
• ether src ehost
  • Sandt, hvis Ethernet-kildeadressen er ehost .
• ether vært ehost
  • Sandt, hvis enten Ethernet-kilden eller destinationsadressen er ehost .
• gateway vært
  • Sandt hvis pakken bruges vært som en gateway (dvs. Ethernet-kilden eller destinationsadressen var vært men hverken IP-kilden eller IP-destinationen var vært ).
  • Vært skal være et navn og skal findes både af maskinens værtsnavn-til-IP-adresse-opløsningsmekanismer (værtsnavnes fil, DNS, NIS osv.) og af maskinens værtsnavn-til-Ethernet-adresse opløsningsmekanisme (/ etc / ethers, etc.).
  • Et ækvivalent udtryk er ether vært ehost og nu vært vært , som kan bruges med enten navne eller tal til vært / ehost .) Denne syntaks fungerer ikke i IPv6-aktiveret konfiguration for øjeblikket.
• dst net net
  • Sandt, hvis pakken IPv4 / v6 har en netværksnummer på net . Net kan enten være et navn fra / etc / networks eller et netværksnummer (se net (4) for detaljer).
• src net net
  • Sandt hvis pakkens IPv4 / v6-kildeadresse har et netværksnummer på net .
• net net
  • Det er sandt, om enten IPv4 / v6-kilden eller destinationsadressen til pakken har et netværksnummer på net .
• net net maske netmaske
  • Sandt, hvis IP-adressen matcher net med det specifikke netmaske . Kan være kvalificeret tilsrc ellerDST. Bemærk, at denne syntaks ikke er gyldig for IPv6 net .
• net net / len
  • Sandt, hvis IPv4 / v6-adressen matcher net med en netmaske len bits bredt. Kan være kvalificeret tilsrc ellerDST.
• dst port Havn
  • Sandt hvis pakken er ip / tcp, ip / udp, ip6 / tcp eller ip6 / udp og har en destinationsportværdi af Havn . Det Havn kan være et tal eller et navn, der anvendes i / etc / services (se tcp (4P) og uDP (4P)). Hvis der bruges et navn, kontrolleres både portnummer og protokol. Hvis der anvendes et tal eller tvetydigt navn, kontrolleres kun portnummeret (f.eks.dst port 513 vil udskrive både tcp / login trafik og udp / hvem trafik, ogportdomæne vil udskrive både tcp / domæne og udp / domæne trafik).
• src port Havn
  • Sandt hvis pakken har en kildeportværdi på Havn .
• Havn Havn
  • Sandt, hvis enten kilden eller destinationsporten i pakken er Havn . Et hvilket som helst af de ovennævnte portudtryk kan forordnes med søgeordene,tcp elleruDP, som i tcp src port Havn , som kun matcher tcp-pakker, hvis kildeport er Havn .
• mindre længde
  • Sandt hvis pakken har en længde mindre end eller lig med længde . Dette svarer til len <= Længde .
• større længde
  • Sandt hvis pakken har en længde større end eller lig med længde . Dette svarer til len> = Længde .
• ip proto protokol
  • Sandt hvis pakken er en IP-pakke (se ip (4P)) af protokol type protokol . protokol kan være et nummer eller et af navnene ICMP , icmp6 , IGMP , igrp , pim , ah , esp , VRRP , uDP , eller tcp . Bemærk at identifikatorerne tcp , uDP , og ICMP er også nøgleord og skal undslippes via backslash (), som er i C-shell. Bemærk, at denne primitive ikke jager protokolhovedkæden.
• ip6 proto protokol
  • Sandt hvis pakken er en IPv6-pakke med protokoltype protokol . Bemærk, at denne primitive ikke jager protokolhovedkæden.
• ip6 protochain protokol
  • Sandt hvis pakken er IPv6-pakke, og indeholder protokoloverskrift med type protokol i sin protokol header kæde. For eksempel, ipv6 protochain 6 matcher enhver IPv6-pakke med TCP-protokoloverskrift i protokoloverskæringen. Pakken kan indeholde for eksempel autentifikationsoverskrift, rutefunktionsoverskrift eller hop-for-hop-opsætningsoverskrift mellem IPv6-header og TCP-header. BPF-koden, der udsendes af denne primitive, er kompleks og kan ikke optimeres af BPF optimizer kode i tcpdump , så det kan være lidt langsomt.
• ip protochain protokol
  • Svarende tilip6 protochain protokol , men det gælder IPv4.
• ether-udsendelse
  • Sandt hvis pakken er en Ethernet-udsendingspakke. Det ether Søgeord er valgfrit.
• ip-udsendelse
  • Sandt hvis pakken er en IP-udsendingspakke. Det kontrollerer både all-zeroes og all-one-broadcast konventioner, og ser op den lokale undernetmaske.
• ether multicast
  • Sandt hvis pakken er en Ethernet multicast-pakke. Det ether Søgeord er valgfrit. Dette er stenografi for 'ether 0 & 1! = 0'.
• ip multicast
  • Sandt hvis pakken er en IP multicast-pakke.
• ip6 multicast
  • Sandt hvis pakken er en IPv6 multicast-pakke.
• etherproto protokol
  • Sandt om pakken er af ether type protokol . protokol kan være et nummer eller et af navnene ip , IP6 , arp , RARP , atalk , AARP , DECnet , sca , lat , mopdl , moprc , iso , stp , ipx , eller NetBEUI . Bemærk, at disse identifikatorer også er nøgleord og skal undslippes via backslash ().
  • I tilfælde af FDDI (fx 'fddi protokol arp') og Token Ring (fx'tr protokol arp'), for de fleste af disse protokoller kommer protokollen identifikation fra 802.2 Logical Link Control (LLC) header, som normalt er lagdelt oven på FDDI eller Token Ring header.
  • Når du filtrerer efter de fleste protokollidentifikatorer på FDDI eller Token Ring, tcpdump kontrollerer kun protokollens ID-felt i en LLC-overskrift i såkaldt SNAP-format med en organisationsenhedsidentifikator (OUI) på 0x000000, for indkapslet Ethernet; det kontrollerer ikke, om pakken er i SNAP-format med en OUI på 0x000000.
  • Undtagelserne er iso , for hvilket det kontrollerer DSAP (Destination Service Access Point) og SSAP (Source Service Access Point) felter i LLC overskriften, stp og NetBEUI , hvor det kontrollerer DSAP af LLC overskriften, og atalk , hvor den kontrollerer en SNAP-formatpakke med en OUI på 0x080007 og Appletalk etype.
  • I tilfælde af Ethernet, tcpdump kontrollerer Ethernet-typen feltet for de fleste af disse protokoller; undtagelserne er iso , saft , og NetBEUI , for hvilket det kontrollerer en 802.3 ramme og derefter kontrollerer LLC overskriften som det gør for FDDI og Token Ring; atalk , hvor det kontrollerer både for Appletalk etype i en Ethernet-ramme og en SNAP-formatpakke som den gør for FDDI og Token Ring; AARP , hvor det kontrollerer Appletalk ARP etype i enten en Ethernet-ramme eller en 802.2 SNAP-ramme med en OUI på 0x000000; og ipx , hvor den kontrollerer IPX etype i en Ethernet-ramme, IPX DSAP i LLC-overskriften, 802.3 uden LLC-headerindkapsling af IPX og IPX-etikken i en SNAP-ramme.
• decnet src vært
  • Sandt hvis DECNET-kildeadressen er vært , som kan være en adresse på formularen "10.123" eller et DECNET-værtsnavn. DECNET-værtsnavnet er kun tilgængelig på Ultrix-systemer, der er konfigureret til at køre DECNET.
• decnet dst vært
  • Sandt hvis DECNET-destinationsadressen er vært .
• decnet vært vært
  • Sandt, hvis enten DECNET-kilden eller destinationsadressen er vært .
• ip, IP6, arp, RARP, atalk, AARP, DECnet, iso, stp, ipx, NetBEUI
  • Forkortelser for etherproto p hvor p er en af ​​de ovennævnte protokoller.
• lat, moprc, mopdl
  • Forkortelser for etherproto p hvor p er en af ​​de ovennævnte protokoller. Noter det tcpdump ved i øjeblikket ikke, hvordan man analyserer disse protokoller.
• VLAN Vlan_id
  • Sandt om pakken er en IEEE 802.1Q VLAN-pakke. Hvis Vlan_id er angivet, kun sandt, hvis pakken har den angivne vlan_id . Bemærk at den førsteVLAN Søgeord stødt på i ekspression ændrer afkodningsforskydninger for resten af ekspression på den antagelse, at pakken er en VLAN-pakke.
• tcp, uDP, ICMP
  • Forkortelser for ip proto p eller ip6 proto p hvor p er en af ​​de ovennævnte protokoller.
• iso proto protokol
  • Sandt hvis pakken er en OSI-pakke med protokoltype protokol . protokol kan være et nummer eller et af navnene CLNP , ESIS , eller isis .
• CLNP, ESIS, isis
  • Forkortelser for iso proto p hvor p er en af ​​de ovennævnte protokoller. Noter det tcpdump gør et ufuldstændigt job med at analysere disse protokoller.
• expr relop expr
  • Sandt hvis forholdet holder, hvor relop er en af>, <,> =, <=, =,! =, og expr er et aritmetisk udtryk sammensat af heltalskonstanter (udtrykt i standard C-syntaks), de normale binære operatører +, -, *, /, &, |, en længdeoperatør og specielle pakkedataadgangsmuligheder. For at få adgang til data inde i pakken skal du bruge følgende syntaks: proto expr: størrelse .

Proto er en afether, FDDI, tr, ppp, glide, link, ip, arp, RARP, tcp, uDP, ICMP, eller IP6, og angiver protokollaget til indeksoperationen (ether, FDDI, tr, ppp, glide, oglink alle henviser til linklaget). Noter det tcp, udp , og andre overlagsprotokoltyper gælder kun for IPv4, ikke IPv6 (dette vil blive rettet i fremtiden). Byteforskydningen, i forhold til det angivne protokollag, er givet af expr . Størrelse er valgfri og angiver antallet af byte inden for interesseområdet; det kan være enten en, to eller fire og standard til en. Længdeoperatøren, angivet med nøgleordetlen, giver længden af ​​pakken.

For eksempel, 'ether 0 & 1! = 0'fanger alle multicast trafik. Udtrykket 'ip 0 & 0xf! = 5'fanger alle IP-pakker med muligheder. Udtrykket 'ip 6: 2 & 0x1fff = 0'fanger kun ufragmenterede datagrammer og frag nul af fragmenterede datagrammer. Denne check er implicit anvendt tiltcp oguDP indeksoperationer. For eksempel, tcp 0 betyder altid den første byte af TCP header , og betyder aldrig den første byte af et mellemliggende fragment.

Nogle forskydninger og feltværdier kan udtrykkes som navne frem for som numeriske værdier. Følgende protokolhovedfeltforskydninger er tilgængelige: icmptype (ICMP type felt)icmpcode (ICMP kodefelt) ogtcpflags (TCP flagfelt).

Følgende ICMP-type feltværdier er tilgængelige:ICMP-echoreply, ICMP-unreach, ICMP-sourcequench, ICMP-redirect, ICMP-ekko, ICMP-routeradvert, ICMP-routersolicit, ICMP-timxceed, ICMP-paramprob, ICMP-tstamp, ICMP-tstampreply, ICMP-ireq, ICMP-ireqreply, ICMP-maskreq, ICMP-maskreply.

Følgende TCP-flagfeltværdier er tilgængelige:tcp-finne, tcp-syn, tcp-rst, tcp-skub, tcp-skub, tcp-ack, tcp-urg.

Primitiver kan kombineres ved hjælp af et af følgende:

• En parentesgruppe af primitiver og operatører (parenteser er specielle til Shell og skal undslippes)
• Negation ('!'eller `ikke')
• Sammenkædning ('&&'eller'og')
• Alternation ('||'eller'eller')

Negation har højeste prioritet. Alternation og sammenkædning har samme prioritet og forbinder venstre mod højre. Bemærk at eksplicitog tokens, ikke sidestilling, er nødvendige for sammenkædning.

Hvis en identifikator er givet uden et søgeord, antages det nyeste søgeord. For eksempel, ikke vært vs og ess er for kort ikke vært vs og vært ess. Dette bør dog ikke forveksles med ikke (vært vs eller ess).

Ekspressionsargumenter kan sendes til tcpdump som enten et enkelt argument eller som flere argumenter, hvilket er mere praktisk. Generelt, hvis udtrykket indeholder Shell-metategn, er det lettere at overføre det som et enkelt citeret argument. Flere argumenter er sammenkædet med mellemrum, inden de analyseres.

Tcpdump Eksempler

tcpdump vært søndag

Ovenstående tcpdump-kommando bruges til at udskrive alle pakker, der ankommer til eller afgår fra solnedgang.

tcpdump vært helios og (hot or ace )

Dette eksempel på tcpdump udskriver trafik mellem helios og heller ikke hed eller es.

tcpdump ip host ess og ikke helios

Du kan bruge denne tcpdump-kommando til at udskrive alle IP-pakker mellem es og enhver vært undtagen helios.

tcpdump net ucb-ether

I ovenstående eksempel udskriver tcpdump al trafik mellem lokale værter og værter på Berkeley.

tcpdump 'gateway snup og (port ftp eller ftp-data)'

Dette næste tcpdump kommandoeksempel bruges til at udskrive all FTP-trafik via internetgateway snup . Bemærk, at udtrykket er citeret for at forhindre, at skalen fortolker parenteserne.

tcpdump ip og ikke net LOCALNET

I ovenstående tcpdump-eksempel udskriver kommandoen trafik, der hverken er hentet fra eller bestemt til lokale værter.

tcpdump 'tcp tcpflags & (tcp-syn | tcp-fin)! = 0 og ikke src og dst net LOCALNET '

I ovenstående eksempel på tcpdump bruges kommandoen til at udskrive start- og slutpakkerne (SYN- og FIN-pakkerne) for hver TCP-samtale, der involverer en ikke-lokal vært.

tcpdump 'gateway snup og ip 2: 2> 576'

Ovenstående kommando udskriver IP-pakker længere end 576 byte sendt via gateway snup.

tcpdump 'ether 0 & 1 = 0 og ip 16> = 224'

Tcpdump-kommandoen vist ovenfor udskriver IP-udsendelser eller multicast-pakker, der var ikke sendt via Ethernet-udsendelse eller multicast.

tcpdump 'icmp icmptype! = icmp-echo og icmp icmptype! = icmp-echoreply'

I dette sidste eksempel på tcpdump udskriver kommandoen alle ICMP-pakker, der ikke er ekkoforespørgsler eller svar (dvs. ikke pingpakker).

Tcpdump Output Format

Udgangen af tcpdump er afhængig af protokollen. Følgende giver en kort beskrivelse og eksempler på de fleste af formaterne.

Link Niveau Headers. Hvis '-e'-indstillingen er angivet, udskrives koblingsniveauhovedet. På Ethernet-netværk udskrives kilde- og destinationsadresserne, protokollen og pakkelængden.

På FDDI-netværk forårsager '-e'-indstillingen tcpdump at udskrive feltet 'frame control', kilden og destinationsadresserne og pakkelængden. ("Ramme kontrol" -feltet styrer tolkningen af ​​resten af ​​pakken. Normale pakker (som dem, der indeholder IP-datagrammer) er async-pakker med en prioritetsværdi mellem 0 og 7: for eksempel `async4'. Sådanne pakker antages at indeholde en 802.2 Logical Link Control (LLC) pakke; LLC-overskriften udskrives, hvis den er ikke et ISO datagram eller en såkaldt SNAP-pakke.

På Token Ring-netværk forårsager alternativet '-e' tcpdump at udskrive 'adgangskontrol' og 'ramme kontrol' felter, kilden og destinationsadresserne og pakkelængden. Som på FDDI-netværk antages pakker at indeholde en LLC-pakke. Uanset om '-e'-indstillingen er angivet eller ej, udskrives kildedirektionsoplysningerne for kildedrevne pakker.

(NB: Den følgende beskrivelse forudsætter fortrolighed med SLIP-komprimeringsalgoritmen beskrevet i RFC-1144.)

På SLIP-links udskrives en retningsindikator ("I" for indgående, "O" for udgående), pakketype og komprimeringsoplysninger. Pakketypen udskrives først. De tre typer er ip , utcp , og ctcp . Ingen yderligere linkoplysninger er trykt på ip pakker. For TCP-pakker udskrives forbindelsesidentifikatoren efter typen. Hvis pakken komprimeres, udskrives den kodede overskrift. De særlige tilfælde udskrives som* S + n og* SA + n , hvor n er den mængde, hvormed sekvensnummeret (eller sekvensnummer og akk) er ændret. Hvis det ikke er en særlig sag, udskrives nul eller flere ændringer. En ændring er angivet med U (hastighedspeger), W (vindue), A (ack), S (sekvensnummer) og I (pakke ID), efterfulgt af et delta (+ n eller -n) eller en ny værdi (= n). Endelig udskrives mængden af ​​data i pakken og den komprimerede headerlængde.

For eksempel viser følgende linje en udgående komprimeret TCP-pakke med en implicit forbindelsesidentifikator; Akk'en er ændret med 6, sekvensnummeret med 49 og pakkens ID med 6; der er 3 byte af data og 6 bytes komprimeret overskrift:

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

Arp / rarp pakker. Arp / rarp output viser typen af ​​anmodning og dens argumenter. Formatet skal være selvforklarende. Her er en kort prøve taget fra starten af ​​en 'rlogin' fra værten rtsg at være vært CSAM :

arp hvem har csam fortælle rtsgarp svar csam er-ved CSAM

Den første linje siger, at rtsg sendte en arp-pakke og beder om Ethernet-adressen til internethost csam. Csam svarer med sin Ethernet-adresse (i dette eksempel er Ethernet-adresser i hætter og internetadresser i små og mellemstore tilfælde).

Dette ville se mindre overflødigt ud, hvis vi havde gjort det tcpdump -n :

arp som har 128.3.254.6 fortælle 128.3.254.68arp svar 128.3.254.6 er-kl 02: 07: 01: 00: 01: c4

Hvis vi havde gjort tcpdump -e , at den første pakke udsendes og den anden er punkt-til-punkt ville være synlig:

RTSG Broadcast 0806 64: arp som har csam fortælle rtsgCSAM RTSG 0806 64: Arp svar csam er-ved CSAM

For den første pakke siger dette, at Ethernet-kildeadressen er RTSG, destinationen er Ethernet-udsendelsesadressen, typefeltet indeholdt hex 0806 (type ETHER_ARP), og den totale længde var 64 bytes.

TCP pakker (NB: Den følgende beskrivelse forudsætter fortrolighed med TCP protokollen beskrevet i RFC-793. Hvis du ikke er bekendt med protokollen, vil hverken denne beskrivelse eller tcpdump være til stor nytte for dig) . Det generelle format for en tcp-protokollinje er:

src> dst: flags data-seqno ack vindue hastende indstillinger

src og DST er kilde- og destinations-IP-adresser og -porte. Flag er en kombination af S (SYN), F (FIN), P (PUSH) eller R (RST) eller en enkelt '.' (ingen flag). Data-seqno beskriver den del af sekvensrummet, der er dækket af dataene i denne pakke (se eksempel nedenfor). Ack er sekvensnummeret for de næste data forventet den anden retning på denne forbindelse. Vindue er antallet af byte af modtage bufferrum til rådighed den anden retning på denne forbindelse. Urg indikerer, at der er "haste" data i pakken. Muligheder er tcp indstillinger indeholdt i vinkelbeslag (f.eks. ).

Src, dst, og flag er altid til stede. De andre felter er afhængige af indholdet i pakkenes tcp-protokollhoved og kun output, hvis det er relevant.

Her er åbningsdelen af ​​en rlogin fra værten rtsg at være vært CSAM .

rtsg.1023> csam.login: S 768512: 768512 (0) vinde 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 vinde 4096 rtsg.1023> csam.login:. akk 1 vinde 4096rtsg.1023> csam.login: P 1: 2 (1) akk 1 vinde 4096csam.login> rtsg.1023:. akk 2 vinde 4096rtsg.1023> csam.login: P 2:21 (19) akk 1 vinde 4096csam.login> rtsg.1023: P 1: 2 (1) ack 21 vinde 4077csam.login> rtsg.1023: P 2: 3 (1) ack 21 vinde 4077 presse 1csam.login> rtsg.1023: P 3: 4 (1) ack 21 vinde 4077 presse 1

Den første linje siger, at tcp port 1023 på rtsg sendte en pakke til port Log på på csam. DetS indikerer at SYN flag blev sat. Paketsekvensnummeret var 768512 og indeholdt ingen data. (Notationen er 'første: sidste (nbytes)', hvilket betyder 'sekvensnumre' først op til men ikke inklusive sidst som er nbytes bytes af brugerdata '.) Der var ingen piggy-backed ack, det tilgængelige modtagelsesvindue var 4096 bytes, og der var en maks-segmentstørrelse mulighed, der anmoder om en mss på 1024 byte.

Csam svarer med en lignende pakke, medmindre den indeholder en piggybacked ack for rtsgs SYN. Rtsg acks derefter csam's SYN. Det '.' betyder ingen flag er sat. Pakken indeholdt ingen data, så der er ikke noget datasekvensnummer. Bemærk at ack sekvensnummeret er et lille heltal (1). Den første gang tcpdump ser en tcp 'samtale', den udskriver sekvensnummeret fra pakken. På efterfølgende pakker af samtalen udskrives forskellen mellem den nuværende pakets sekvensnummer og dette indledende sekvensnummer. Dette betyder, at sekvensnumre efter den første kan fortolkes som relative bytepositioner i samtaleens datastrøm (med den første databyte hver retning er '1'). '-S' vil tilsidesætte denne funktion, hvilket får de originale sekvensnumre til at blive udgivet.

På den sjette linje sender rtsg csam 19 bytes data (bytes 2 til 20 i rtsg -> csam side af samtalen). PUSH-flag er sat i pakken. På den syvende linje siger csam, at det er modtaget data sendt af rtsg op til, men ikke med byte 21. De fleste af disse data er tilsyneladende sidder i stikket buffer siden csams modtagelsesvindue har fået 19 bytes mindre. Csam sender også en byte af data til rtsg i denne pakke. På den ottende og niende linje sender csam to byte med presserende data til rtsg.

Hvis øjebliksbillede var lille nok det tcpdump fangede ikke hele TCP header, det fortolker så meget af overskriften som det kan og derefter rapporterer "| tcp '' for at angive resten, kunne ikke fortolkes. Hvis overskriften indeholder en falsk valgmulighed (en med en længde, der enten er for lille eller ud over enden af ​​overskriften) tcpdump rapporterer det som " dårlig opt '' og fortolker ikke yderligere muligheder (da det er umuligt at fortælle, hvor de starter). Hvis overskriftslængden angiver mulighederne er til stede, men IP-datagramlængden er ikke lang nok til at mulighederne rent faktisk er der, tcpdump rapporterer det som " dårlig hdr længde ''.

Capture pakker med bestemte flag kombinationer. Der er otte bits i styrebitsafsnittet i TCP-overskriften:

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

Lad os antage, at vi ønsker at se pakker, der bruges til oprettelse af en TCP-forbindelse. Husk, at TCP bruger en trevejs håndskriftsprotokol, når den initialiserer en ny forbindelse; forbindelsessekvensen med hensyn til TCP-styrebitene er:

1. Indringer sender SYN.
2. Modtageren reagerer med SYN, ACK.
3. Opkalder sender ACK.

Nu er vi interesserede i at fange pakker, der kun har SYN-bitsæt (Trin 1). Bemærk, at vi ikke ønsker pakker fra trin 2 (SYN-ACK), bare en simpel indledende SYN. Hvad vi har brug for er et korrekt filter udtryk for tcpdump .

Husk strukturen af ​​en TCP header uden valgmuligheder:

0 15 31-----------------------------------------------------------------| source port | destinationshavn |-----------------------------------------------------------------| sekvensnummer |-----------------------------------------------------------------| kvitteringsnummer |-----------------------------------------------------------------| HL | rsvd | C | E | U | A | P | R | S | F | vinduestørrelse |-----------------------------------------------------------------| TCP checksum | hastende peger |-----------------------------------------------------------------

En TCP header indeholder normalt 20 oketter med data, medmindre der er muligheder. Den første linje i grafen indeholder oktetter 0-3, den anden linje viser oktetter 4-7 osv.

Begyndende med at tælle med 0 er de relevante TCP kontrolbiter indeholdt i oktet 13:

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

Lad os se nærmere på octet nr. 13:

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

Dette er de TCP kontrol bits, som vi er interesserede i. Vi har nummereret bitene i denne oktet fra 0 til 7, højre mod venstre, så PSH-bit er bit nummer 3, mens URG-bit er nummer 5.

Husk at vi ønsker at fange pakker med kun SYN-sæt. Lad os se, hvad der sker med oktet 13, hvis et TCP datagram ankommer med SYN-bitsættet i dets overskrift:

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

Når vi ser på kontrolbitsafsnittet, ser vi, at kun bitnummer 1 (SYN) er indstillet.

Forudsat at oktet nummer 13 er et 8-bit usigneret heltal i netværksbyte rækkefølge, er denne oktets binære værdi:

00000010

Dens decimal repræsentation er:

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

Vi er næsten færdige, for nu ved vi, at hvis kun SYN er indstillet, skal værdien af ​​den 13. oktet i TCP-overskriften, når den tolkes som et 8-bit usigneret heltal i netværksbyteordre, være nøjagtigt 2.

Dette forhold kan udtrykkes som

tcp 13 == 2

Vi kan bruge dette udtryk som filteret til tcpdump for at se pakker, der kun har SYN-sæt:

tcpdump -i xl0 tcp 13 == 2

Udtrykket siger "lad den 13. oktet af et TCP datagram have decimalværdien 2", hvilket er præcis det, vi ønsker.

Lad os nu antage, at vi skal indfange SYN-pakker, men det er ligeglad, om ACK eller nogen anden TCP-kontrolbit er indstillet på samme tid. Se hvad der sker med oktet 13, når et TCP datagram med SYN-ACK sæt ankommer:

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

Bits 1 og 4 er nu indstillet i den 13. oktet. Den binære værdi af oktet 13 er:

00010010

som oversætter til decimal:

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

Vi kan ikke bare bruge 'tcp 13 == 18' i tcpdump filter udtryk, fordi det ville kun vælge de pakker, der har SYN-ACK sæt, men ikke dem med kun SYN sæt. Husk, at vi er ligeglade med, om ACK eller en anden kontrolbit er indstillet, så længe SYN er indstillet.

For at opnå vores mål skal vi logisk OG den binære værdi af oktet 13 med en anden værdi for at bevare SYN-bit. Vi ved, at vi vil have SYN i hvert fald, så vi logisk OG værdien i den 13. oktet med binærværdien af ​​en SYN:

00010010 SYN-ACK 00000010 SYN OG 00000010 (vi ønsker SYN) OG 00000010 (vi ønsker SYN) -------- -------- = 00000010 = 00000010

Vi ser at denne AND-funktion leverer det samme resultat, uanset om ACK eller en anden TCP-kontrolbit er indstillet. Den decimale repræsentation af AND-værdien samt resultatet af denne operation er 2 (binær 00000010), så vi ved, at for pakker med SYN-sæt skal følgende forhold være sandt:

((værdi af oktet 13) OG (2)) == (2)

Dette peger os til tcpdump filter ekspression

tcpdump -i x10 'tcp 13 & 2 == 2'

Bemærk at du skal bruge enkle citater eller et tilbageslag i udtrykket for at skjule AND ('&') specialtegnet fra skallen.

UDP pakker. UDP-format er illustreret af denne rwho-pakke:

actinide.who> broadcast.who: udp 84

Dette siger, at havnen hvem på vært actinide sendte et udp datagram til port hvem på vært udsende , internet-udsendelsesadressen. Pakken indeholdt 84 bytes brugerdata.

Nogle UDP-tjenester genkendes (fra kilde- eller destinationsportnummeret) og de højere protokolloplysninger, der udskrives - især Domain Name-serviceanmodninger (RFC-1034/1035) og Sun RPC-opkald (RFC-1050) til NFS.

UDP navn server anmodninger (NB: Den følgende beskrivelse forudsætter kendskab til Domain Service-protokollen beskrevet i RFC-1035. Hvis du ikke er bekendt med protokollen, vil den følgende beskrivelse ikke give mening.)

Navn server anmodninger er formateret som:

src> dst: id op? flag q qtype qclass navn (len) h2opolo.1538> helios.domæne: 3+ A? ucbvax.berkeley.edu. (37)

Vært h2opolo spurgte domæneserveren på helios for en adressepost (qtype = A) tilknyttet navnet ucbvax.berkeley.edu. Forespørgsels-id'et var '3'. '+' Indikerer ønsket rekursion flag blev sat. Forespørgslængden var 37 bytes, uden UDP- og IP-protokoloverskrifter. Forespørgselsoperationen var den normale, Forespørgsel , så op feltet blev udeladt. Hvis open havde været noget andet, ville det have været trykt mellem '3' og '+'. På samme måde var qclassen den normale, C_IN , og udelades. Enhver anden qclass ville have været udskrevet umiddelbart efter 'A''en.

Nogle få anomalier kontrolleres og kan resultere i ekstra felter indesluttet i firkantede parenteser: Hvis en forespørgsel indeholder et svar, autoritetsoptegnelser eller yderligere registreringsafsnit, ancount , nscount , eller arcount er trykt som ' n a ',' n heller ikke ' n au 'hvor n er den passende tæller. Hvis nogen af ​​reaktionsbiterne er indstillet (AA, RA eller Rcode) eller en af ​​'skal være nul', sættes bitene i to og tre, `b2 & 3 = x 'udskrives, hvor x er hex-værdien af ​​header bytes to og tre.

UDP navneserver svar. Navneserversvar er formateret som:

src> dst: id op rcode flag a / n / au type klassedata (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)

I det første eksempel, helios svarer til forespørgsel id 3 fra h2opolo med tre svar records, tre navneserver records og syv ekstra poster. Den første svarplade er type A (adresse), og dens data er internetadresse 128.32.137.3. Den samlede størrelse af svaret var 273 bytes, eksklusive UDP og IP headers. Op (Query) og Response Code (NoError) blev udeladt, ligesom klassen (C_IN) af A-posten.

I det andet eksempel, helios svarer til forespørgsel 2 med en svarkode for ikke-eksisterende domæne (NXDomain) uden svar, en navneserver og ingen autoritetsoptegnelser. '*' Indikerer at autoritativt svar bit blev indstillet. Da der ikke var svar, blev der ikke skrevet nogen type, klasse eller data.

Andre flagfigurer, der kan vises, er '-' (rekursion tilgængelig, RA, ikke sæt) og '|' (afkortet besked, TC, indstillet). Hvis afsnittet 'spørgsmål' ikke indeholder nøjagtigt en post, ' n q 'udskrives.

Bemærk, at navneserverforespørgsler og svar tendens til at være store og standard snaplen af 68 bytes må ikke fange nok af pakken til at udskrive. Brug-s flag for at øge snaplen, hvis du har brug for seriøst at undersøge navneservertrafik. '-s 128"har fungeret godt for mig.

SMB / CIFS-dekodning. tcpdump indeholder temmelig omfattende SMB / CIFS / NBT-afkodning for data på UDP / 137, UDP / 138 og TCP / 139. Nogle primitive afkodning af IPX og NetBEUI SMB data er også gjort.

Som standard gøres en forholdsvis minimal afkodning, med en langt mere detaljeret dekodering udført, hvis -v anvendes. Vær advaret om, at med -v en enkelt SMB-pakke kan tage en side eller mere, så brug kun -v hvis du virkelig vil have alle de gory detaljer.

Hvis du afkodning SMB-sessioner indeholdende unicode-strenge, kan du muligvis indstille miljøvariablen USE_UNICODE til 1. En patch til automatisk detektion af unicode-strenge ville være velkommen.

For information om SMB-pakkeformater og hvad alle felter betyder, se www.cifs.org eller pub / samba / specs / mappen på dit foretrukne samba.org spejlsted. SMB-patchesne blev skrevet af Andrew Tridgell ([email protected]).

NFS anmodninger og svar. Sun NFS (Network File System) anmodninger og svar udskrives som:

src.xid> dst.nfs: len op args src.nfs> dst.xid: Svar statlen op resultater sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10,73165wrl.nfs> sushi.6709: svar ok 40 læselink "../var"sushi.201b> wrl.nfs: 144 opslag fh 9,74 / 4096,6878 "xcolors"wrl.nfs> sushi.201b: svar ok 128 opslag fh 9,74 / 4134.3150

I den første linje, vært sushi sender en transaktion med id 6709 til WRL (bemærk at tallet efter src-vært er et transaktions-id, ikke kildeporten). Forespørgslen var 112 bytes, eksklusive UDP- og IP-overskrifterne. Operationen var a readlink (læs symbolsk link) på filhåndtag ( fh ) 21,24 / 10,731657119. (Hvis man er heldig, som i dette tilfælde kan filhåndtaget fortolkes som et større, mindre enhedsnummerpar efterfulgt af inodenummeret og generationsnummeret.) WRL svar 'ok' med indholdet af linket.

I den tredje linje, sushi spørger WRL at finde navnet " xcolors 'i mappefil 9,74 / 4096,6878. Bemærk, at de udskrevne data afhænger af operationstypen. Formatet er beregnet til at være selvforklarende, hvis det læses sammen med en NFS-protokolspec.

Hvis -v (verbose) flag er givet, udskrives yderligere oplysninger. For eksempel:

sushi.1372a> wrl.nfs: 148 læse fh 21,11 / 12,195 8192 bytes @ 24576wrl.nfs> sushi.1372a: svar ok 1472 læs REG 100664 ids 417/0 sz 29388

(-v udskriver også IP-header TTL-, ID-, længde- og fragmenteringsfelterne, som er udeladt fra dette eksempel.) I den første linje, sushi spørger WRL at læse 8192 bytes fra fil 21,11 / 12,195, ved byte offset 24576. WRL svar 'ok'; pakken vist på den anden linje er det første fragment af svaret og er derfor kun 1472 byte lang (de andre byte vil følge i efterfølgende fragmenter, men disse fragmenter har ikke NFS eller endda UDP-overskrifter og kan derfor ikke udskrives, afhængigt af det anvendte filter udtryk). Da -v-flag er givet, udskrives nogle af filattributterne (som returneres ud over fildataene): filtypen ("REG", for almindelig fil), filtilstanden (i oktal), den uid og gid, og filstørrelsen.

Hvis -v-flag er givet mere end en gang, bliver der udskrevet endnu flere detaljer.

Bemærk, at NFS-anmodninger er meget store, og meget af detaljerne vil ikke blive udskrevet, medmindre snaplen er øget. Prøv at bruge '-s 192'for at se NFS-trafik.

NFS-svarpakker identificerer ikke RPC-operationen eksplicit. I stedet, tcpdump holder styr på "seneste" anmodninger og matcher dem med svarene ved hjælp af transaktions-id'et. Hvis et svar ikke følger nøje den tilsvarende anmodning, kan det ikke være parserbart.

Transarc AFS (Andrew File System) anmodninger og svar.

src.sport> dst.dport: rx pakke-type src.sport> dst.dport: rx pakke-type serviceopkald call-name args src.sport> dst.dport: rx pakke-type service svar call-name args elvis.7001> pike.afsfs: rx data fs call omdøbe gamle fid 536876964/1/1 ".newsrc.new" ny fid 536876964/1/1 ".newsrc"pike.afsfs> elvis.7001: rx data fs svar omdøbe

I første linje sender vært Elvis en RX-pakke til gedde. Dette var en RX datapakke til fs (fileserver) service, og er starten på et RPC-opkald.RPC-opkaldet blev et omdøb, med den gamle katalogfil-id på 536876964/1/1 og et gammelt filnavn af '.newsrc.new' og et nyt katalogfil-id på 536876964/1/1 og et nyt filnavn af '. newsrc'. Værtsdukken reagerer med et RPC-svar på omdøbsopkaldet (hvilket lykkedes, fordi det var en datapakke og ikke en abortpakke).

Generelt afkodes alle AFS RPC'er i det mindste ved RPC-opkaldsnavn. De fleste AFS RPC'er har i det mindste nogle af argumenterne afkodet (generelt kun de "interessante" argumenter, for en vis definition af interessant).

Formatet skal være selvbeskrivende, men det vil nok ikke være nyttigt for folk, der ikke er bekendt med AFS og RX's arbejde.

Hvis -v (verbose) -flagget gives to gange, udskrives bekræftelsespakker og yderligere headeroplysninger, såsom RX-opkalds-id, opkaldsnummer, sekvensnummer, serienummer og RX-pakkeflaggene.

Hvis -v-flag er givet to gange, udskrives yderligere oplysninger, såsom RX-opkalds-id, serienummer og RX-pakkeflaggerne. MTU-forhandlingsoplysningerne er også trykt fra RX ack pakker.

Hvis -v-flag er givet tre gange, udskrives sikkerhedsindeks og service-id.

Fejlkoder udskrives for abortpakker med undtagelse af Ubik-beaconpakker (fordi abortpakker bruges til at betegne en ja-stemme for Ubik-protokollen).

Bemærk, at AFS-anmodninger er meget store, og mange af argumenterne vil ikke blive udskrevet, medmindre snaplen er øget. Prøv at bruge `-s 256'for at se AFS-trafik.

AFS-svarpakker identificerer ikke RPC-operationen eksplicit. I stedet, tcpdump holder styr på "seneste" anmodninger og matcher dem med svarene ved hjælp af opkaldsnummer og service-id. Hvis et svar ikke følger nøje den tilsvarende anmodning, kan det ikke være parsable.

KIP Appletalk (DDP i UDP). Appletalk DDP pakker indkapslet i UDP datagrammer er de-indkapslet og dumpet