Å utføre pakkefangst ved hjelp av en sniffer kan være en ekstremt kraftig metode for å diagnostisere komplekse problemer. Når alt annet mislykkes, er det ofte nyttig å se rådataene som sendes over ledningen. Pakkene lyver ikke, og å analysere applikasjonstrafikken din på et lavt nivå kan avsløre dypere symptomer på et problem (eller avsløre et problem som du ikke engang visste eksisterte).
I denne artikkelen, vi Vi vil dekke noen grunnleggende grunnlag for å bruke det CLI-baserte tcpdump verktøyet.
Grunnleggende om sniffer
Så først ting først: Hva mener vi når vi sier «pakke sniffer?» En pakke sniffer er ganske enkelt et program som lar deg fange pakker på nettverket ditt. Tcpdump og Wireshark er eksempler på pakkesniffere. Tcpdump gir en CLI-pakkesniffer, og Wireshark gir et funksjonsrikt GUI for å snuse og analysere pakker.
Som standard fungerer tcpdump i promiskuøs modus. Dette betyr ganske enkelt at alle pakker som når en vert vil bli sendt til tcpdump for inspeksjon. Denne innstillingen inkluderer til og med trafikk som ikke var bestemt for den spesifikke verten du tar, for eksempel kringkasting og multicast-trafikk. Selvfølgelig er tcpdump ikke noe magisk programvare: Det kan bare fange de pakkene som på en eller annen måte når en av de fysiske grensesnittene på maskinen din.
Installere tcpdump er enkelt. Den er tilgjengelig i standard pakkelager på Red Hat-systemet, og du kan installere det ved navn:
Vanlige pakkesnusingsscenarier
Å fange opp all trafikken som kommer inn i maskinen din, kan høres konseptuelt kult ut, men det høres også ganske lavt ut for mange av aktivitetene vi utfører i vårt daglige arbeid som sysadminer. Så når vil du bruke et pakkepappverktøy? Jeg henvender meg vanligvis til en pakkesniffer når jeg feilsøker et nettverksapplikasjonsproblem og jeg har brukt opp alle andre alternativer. Ofte har jeg allerede utført grunnleggende feilsøking for nettverk og gjennomgå eventuelle applikasjonsloggfiler, men jeg kan fortsatt ikke komme til bunns i et problem. På dette tidspunktet kan det være lærerikt å bryte ut en pakkesniffer for å observere de faktiske dataene som sendes på ledningen.
En annen god brukstilfelle for en pakkesniffer er pedagogisk. Å se på pakkene som er involvert i en applikasjonsutveksling kan gå langt for å forbedre forståelsen av de underliggende protokollene. For eksempel kan det være uvurderlig å observere hele pakkestrømmen til et rekursivt DNS-spørsmål når du prøver å forstå hvordan DNS fungerer.
Utføre grunnleggende pakkefangst
Den beste måten å lære på er ved å bare dykke inn, så la oss komme i gang med noen grunnleggende pakkeopptak. La oss først prøve tcpdump uten noen spesielle alternativer. Merk at du må være superbruker for å utføre pakkefangst (teknisk sett kan du kjøre den fra en vanlig konto med spesielle muligheter, men det er vanligvis lettere å kjøre den som root). Bruk Ctrl + C, eller send en SIGTERM til tcpdump prosess-ID (PID) for å stoppe opptaket.
Standard tcpdump
Til se standardutgangen til tcpdump, skriv bare kommandoen:
Merk: I stedet for å ha mye utdata før du trykker Ctrl + C, kan du spesifisere hvor mange pakker du vil se med -c flagget. Kommandoen ovenfor kan i stedet være tcpdump -c 6 for å få de samme resultatene (seks pakker fanget).
Utgangen fra tcpdump kan være litt skremmende i begynnelsen, men du blir vant til å se på det etter at du har brukt dette verktøyet noen ganger. La oss bryte ned feltene, fra venstre til høyre:
Snuse et bestemt grensesnitt
Legg merke til at toppen av utgangen av forrige eksempel viser deg grensesnittet som tcpdump begynner å fange på (eth0), og bunnen av fangsten inkluderer sammendragsstatistikk om de fangede pakkene.
Det første du sannsynligvis vil gjøre når du bruker tcpdump er å spesifisere et bestemt grensesnitt for utføring av opptak. Som standard vil tcpdump velge det laveste nummererte grensesnittet som er «opp». Mange servere har flere grensesnitt, og du vil være klar over grensesnittet du bruker til å fange. I tillegg kan noen «spesielle» grensesnitttyper, for eksempel et netfilter -grensesnitt, flyte til toppen av listen. Denne oppførselen kan forårsake forvirring, så det er best å spesifisere grensesnittet du er interessert i.
La oss starte med å se grensesnittene som er tilgjengelige for å fange:
Med en liste over grensesnitt vi har til rådighet, kan vi nå spesifisere grensesnittet vi skal lytte til med -i flagget.Vær oppmerksom på at enten grensesnittnavnet eller nummeret fra --list-interfaces -kommandoen kan brukes:
Ser vi på ovennevnte bilder, får vi grunnleggende informasjon om pakkene som krysser våre Nettverk. Det ser ut til at disse pakkene inneholder Spanning Tree Protocol (STP) -utgang, kanskje fra en oppstrømsbryter. Teknisk sett er dette ikke pakker, de er lag to rammer. Du vil imidlertid høre begrepene som brukes om hverandre når du diskuterer pakkefangst.
Få mer informasjon
Det forrige eksemplets enkle feilsøkingsresultat kan være bra for å identifisere åpenbare problemer, men noen ganger trenger vi mer informasjon for å virkelig grave i et komplekst problem. Det er viktig å vite hvordan du justerer detaljnivået til opptaket ditt, da det lar deg grave dypere inn i de faktiske dataene i pakkene.
Nøyaktighetsnivået på tcpdump styres ved å legge til mellom ett og tre -v flagg til kommandoen:
Merk at ved å spesifisere det maksimale nivået av ordlighetsgrad, kan jeg se langt mer informasjon om pakkehuset. Ovenfor kan vi se tilleggsinformasjon om dataene i STP-pakken, for eksempel root bridge ID og root path cost. Hvis du ikke er kjent med STP, ikke bekymre deg for det. Det viktige å merke seg her er at ved å øke ordlighetsgraden, kan vi få tilleggsinformasjon om nettverkstrafikken vår.
Å se en pakkes eksakte byte
Å øke ordlighetsgraden er nyttig, men vi ser fremdeles ikke kjøttet fra pakkenes innhold. Hvis du virkelig vil se de eksakte bytene som er i pakkene, kan du bruke flaggene -x og -X. -x flagget skriver ut dataene i hver pakke i heks, mens -X flagget også skriver ut dataene i ASCII. Her er utdataene ved hjelp av -x:
Og her er utgangen med -X:
Legg merke til hex- og ASCII-dataene i eksemplene ovenfor. I dette tilfellet utførte jeg et DNS A-postspørsmål for . Vær også oppmerksom på at jeg brukte -c -flagget til å spesifisere antall pakker som skulle fanges, og jeg ga et fangstfilter på port 53. Vi vil diskutere filtre i neste artikkel.
Holde seg med tallene
Når du jobber med tcpdump, vil du kanskje legge merke til at standardatferden er å automatisk løse IP-adresser til fullt kvalifiserte domenenavn (FQDNs). Tcpdump vil også oversette portnumre (for eksempel 22) til vennlige navn (for eksempel SSH). Selv om denne oppførselen er fin, vil vi ofte se de numeriske dataene slik at vi ikke tilslører feilsøking på noen måte. Denne standardoppførselen kan endres ved å sende enten -n for å deaktivere IP-adressesøk, eller -nn for å deaktivere både IP-adresse og portoppslag.
Her er resultatet når du bruker -nn:
Lagring av dumping
På et tidspunkt vil du kanskje for å lagre pakkeopptakene dine for senere analyse, eller for dypere analyse med et grafisk verktøy som Wireshark. Denne oppgaven kan enkelt utføres med -w -flagget, som lar deg skrive en pakkefangstfil:
Merk: Du kan lese den lagrede filen ved hjelp av tcpdump med -r -flagget, eller med et annet program som støtter pcap-filformatet.
Som vi kan se ovenfor , -w -flagget produserte en praktisk pcap-fil som vi kan ta med oss.
Innpakning
Å utføre pakkefangst er en kraftig teknikk i nettverkets feilsøkingsoppgaver, spesielt når du sitter fast i et problem og resten av nettverket ser OK ut. Å forstå hvordan du bruker tcpdump på kommandolinjen, kan spare deg for timer med frustrasjon når du prøver å løse problemer med nettverksapplikasjoner, og syntaksen er ganske intuitiv når du er vant til det.