|
Einführung Einfach ausgedrückt ist tcpdump ein Paketanalysetool, das den Datenverkehr in einem Netzwerk ausgibt und Datenpakete im Netzwerk entsprechend der Definition des Benutzers abfängt. Tcpdump kann den „Header“ der im Netzwerk übertragenen Datenpakete vollständig abfangen und analysieren. Es unterstützt das Filtern nach Netzwerkschicht, Protokoll, Host, Netzwerk oder Port und bietet logische Anweisungen wie „und“, „oder“, „nicht“, um Ihnen dabei zu helfen, unnütze Informationen zu entfernen. Praktische Befehlsbeispiele Standard-Start Normalerweise werden durch den direkten Start von tcpdump alle Pakete überwacht, die durch die erste Netzwerkschnittstelle fließen. Überwachen Sie Pakete auf einer angegebenen Netzwerkschnittstelle Wenn Sie keine Netzwerkkarte angeben, überwacht tcpdump standardmäßig nur die erste Netzwerkschnittstelle, normalerweise eth0. In den folgenden Beispielen wird keine Netzwerkschnittstelle angegeben. Pakete von einem bestimmten Host überwachen Drucken Sie alle Pakete aus, die in den Sonnenuntergang hinein- oder hinausgehen.
TCPdump-Host Sonnenuntergang Sie können auch eine IP-Adresse angeben, um beispielsweise alle vom Host unter 210.27.48.1 empfangenen und gesendeten Pakete zu erfassen Drucken Sie die Datenpakete zwischen Helios und Hot oder Ace
tcpdump host helios und \( hot oder ace \) Abfangen der Kommunikation zwischen Host 210.27.48.1 und Host 210.27.48.2 oder 210.27.48.3
tcpdump Host 210.27.48.1 und \ (210.27.48.2 oder 210.27.48.3 \) Druckt IP-Pakete zwischen Ace und anderen Hosts, aber nicht Helios.
tcpdump ip host ace und nicht helios Wenn Sie die IP-Pakete aller Hosts außer dem Host 210.27.48.2 abrufen möchten, verwenden Sie den Befehl:
tcpdump IP-Host 210.27.48.1 und ! 210.27.48.2 Alle vom Host Hostname gesendeten Daten abfangen
tcpdump -i eth0 src host Hostname
Überwachen Sie alle an den Host Hostname gesendeten Pakete
tcpdump -i eth0 Zielhost Hostname
Überwachen Sie Pakete von einem angegebenen Host und Port Wenn Sie die vom Host 210.27.48.1 empfangenen oder gesendeten Telnet-Pakete abrufen möchten, verwenden Sie den folgenden Befehl
tcpdump TCP-Port 23 und Host 210.27.48.1
Überwachen Sie den lokalen UDP-Port 123. 123 ist der Service-Port von NTP Überwachen Sie Pakete in einem bestimmten Netzwerk Drucken Sie alle Kommunikationspakete zwischen dem lokalen Host und dem Host im Berkeley-Netzwerk (nt: ucb-ether, hier kann es als Netzwerkadresse des „Berkeley-Netzwerks“ verstanden werden. Die ursprünglichste Bedeutung dieses Ausdrucks kann wie folgt ausgedrückt werden: Drucken Sie alle Pakete mit der Netzwerkadresse ucb-ether.) Drucken Sie alle FTP-Pakete, die durch das Gateway snup gehen (beachten Sie, dass der Ausdruck in einfache Anführungszeichen eingeschlossen ist, um zu verhindern, dass die Shell die Klammern falsch interpretiert).
tcpdump 'Gateway-Snup und (Port-FTP oder FTP-Daten)'
Drucken Sie alle IP-Pakete, deren Quell- oder Zieladresse der lokale Host ist (Wenn das lokale Netzwerk über ein Gateway mit einem anderen Netzwerk verbunden ist, kann das andere Netzwerk nicht als lokales Netzwerk gezählt werden. (nt: Dieser Satz ist ungenau und muss ergänzt werden.) Wenn tatsächlich „localnet“ verwendet wird, sollte es durch den Namen des lokalen Netzwerks ersetzt werden.)
tcpdump ip und nicht net localnet
Pakete des angegebenen Protokolls überwachen Drucken Sie die Start- und Endpakete einer TCP-Sitzung, deren Quelle oder Ziel kein Host im lokalen Netzwerk ist.
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 und nicht src und dst net localnet'
Drucken Sie alle Pakete, deren Quell- oder Zielport 80 ist, deren Netzwerkschichtprotokoll IPv4 ist und die Daten enthalten, statt SYN, FIN, nur ACK usw. (Die IPv6-Version des Ausdrucks kann als Übung verwendet werden.)
tcpdump 'TCP-Port 80 und (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(nt: Es ist klar, dass ip[2:2] die Länge des gesamten IP-Datenpakets darstellt, (ip[0]&0xf)<<2) die Länge des IP-Datenpaketheaders darstellt (ip[0]&0xf stellt das IHL-Feld im Paket dar und die Einheit dieses Feldes beträgt 32 Bit. Um die Anzahl der Bytes zu erhalten, multiplizieren Sie mit 4, d. h. verschieben Sie um 2 nach links. (tcp[12]&0xf0)>>4 gibt die Länge des TCP-Headers an. Die Einheit dieses Felds ist ebenfalls 32 Bit. Die Anzahl der konvertierten Bits ist ((tcp[12]&0xf0) >> 4) << 2,
Das heißt, ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 bedeutet: die Länge des gesamten IP-Pakets minus der Länge des IP-Headers, minus
Die Länge des TCP-Headers ist ungleich 0, was bedeutet, dass das IP-Paket tatsächlich Daten enthält. Bei der IPv6-Version muss lediglich der Unterschied zwischen der 'Payload Length' im IPv6-Header und der 'Length of the TCP Header' beachtet werden und der Ausdruck 'ip[]' muss durch 'ip6[]' ersetzt werden.) Drucken Sie IP-Pakete mit einer Länge von mehr als 576 Bytes und einer Gateway-Adresse von snup
tcpdump 'Gateway-Snup und IP[2:2] > 576'
Drucken Sie alle IP-Layer-Broadcast- oder Multicast-Pakete, aber keine physischen Ethernet-Layer-Broadcast- oder Multicast-Datagramme.
tcpdump 'ether[0] & 1 = 0 und ip[16] >= 224'
Drucken Sie andere ICMP-Pakete als „Echoanforderungs-“ oder „Echoantwort“-Pakete (dieser Ausdruck kann beispielsweise verwendet werden, um alle Pakete zu drucken, die nicht vom Ping-Programm generiert wurden).
(nt: „Echoanforderung“ und „Echoantwort“ sind zwei Arten von ICMP-Paketen, die normalerweise vom Ping-Programm generiert werden))
tcpdump 'icmp[icmptyp] != icmp-echo und icmp[icmptyp] != icmp-echoreply'
tcpdump und wireshark Wireshark (früher Ethereal) ist ein sehr einfaches und benutzerfreundliches Tool zur Paketerfassung unter Windows. Es ist jedoch schwierig, unter Linux ein gutes grafisches Tool zur Paketerfassung zu finden.
Glücklicherweise gibt es Tcpdump. Um dies zu erreichen, können wir die perfekte Kombination aus Tcpdump + Wireshark verwenden: Erfassen Sie Pakete in Linux und analysieren Sie die Pakete dann in Windows.
tcpdump tcp -i eth1 -t -s 0 -c 100 und dst-Port ! 22 und src net 192.168.1.0/24 -w ./target.cap
(1)tcp: ip icmp arp rarp und tcp, udp, icmp und andere Optionen sollten an der ersten Parameterposition platziert werden, um den Datagrammtyp zu filtern
(2)-i eth1: Erfasst nur Pakete, die durch die Schnittstelle eth1 laufen.
(3)-t: Zeitstempel nicht anzeigen
(4) -s 0: Die Standard-Erfassungslänge beim Erfassen von Datenpaketen beträgt 68 Bytes. Fügen Sie -S 0 hinzu, um das komplette Datenpaket zu erfassen
(5) -c 100 : nur 100 Pakete erfassen
(6)dst port ! 22: Pakete mit Zielport 22 werden nicht erfasst
(7)src net 192.168.1.0/24: Die Quellnetzwerkadresse des Pakets ist 192.168.1.0/24
(8)-w ./target.cap: Als CAP-Datei speichern, praktisch für die Analyse mit Ethereal (Wireshark) Erfassen Sie HTTP-Pakete mit tcpdump
tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 oder tcp[20:2]=0x4854
0x4745 sind die ersten beiden Buchstaben „GE“ von „GET“ und 0x4854 sind die ersten beiden Buchstaben „HT“ von „HTTP“. tcpdump dekodiert die abgefangenen Daten nicht vollständig und der Großteil des Inhalts des Datenpakets wird direkt im Hexadezimalformat ausgedruckt. Dies ist offensichtlich nicht förderlich für die Analyse von Netzwerkfehlern. Die übliche Lösung besteht darin, zuerst tcpdump mit dem Parameter -w zu verwenden, um Daten abzufangen und in einer Datei zu speichern, und sie dann mit anderen Programmen (z. B. Wireshark) zu dekodieren und zu analysieren. Natürlich sollten auch Filterregeln definiert werden, um zu verhindern, dass die abgefangenen Datenpakete die gesamte Festplatte füllen. Bedeutung der Ausgabeinformationen Beachten wir zunächst, dass das allgemeine Ausgabeformat von tcpdump lautet: Systemzeit Quellhost.Port > Zielhost.Port Datenpaketparameter Das Ausgabeformat von tcpdump ist protokollabhängig. Nachfolgend finden Sie eine kurze Beschreibung der am häufigsten verwendeten Formate und zugehörige Beispiele. Link-Layer-Header Bei FDDI-Netzwerken bewirkt „-e“, dass tcpdump das Feld „Frame Control“, die Quell- und Zieladressen sowie die Länge des angegebenen Pakets druckt. (Das Feld „Frame Control“ steuert die Interpretation der anderen Felder im Paket.) Normale Pakete (wie die von IP-Datagrammen) sind Pakete mit gesetztem Flag „async“ und haben einen Prioritätswert von 0 bis 7;
Beispielsweise bedeutet „async4“, dass dieses Paket ein asynchrones Datenpaket mit einer Priorität von 4 ist. Es wird allgemein angenommen, dass diese Pakete ein LLC-Paket (Logical Link Control-Paket) enthalten. Wenn dieses Paket zu diesem Zeitpunkt kein ISO-Datagramm oder ein sogenanntes SNAP-Paket ist, wird sein LLC-Header gedruckt (Hinweis: er sollte sich auf den in diesem Paket enthaltenen LLC-Paketheader beziehen). Bei Token-Ring-Netzwerken bewirkt „-e“, dass tcpdump die Felder „Frame Control“ und „Access Control“ des angegebenen Pakets sowie die Quell- und Zieladressen ausgibt.
plus die Länge des Pakets. Ähnlich wie bei FDDI-Netzwerken enthält dieses Paket normalerweise LLC-Pakete. Unabhängig davon, ob die Option „-e“ verwendet wird. Für Pakete vom Typ „source-routed“ in diesem Netzwerk (nt:
Die Quelladresse des Datenpakets wird verfolgt, die spezifische Bedeutung ist unbekannt und muss ergänzt werden), und die Quellroutinginformationen des Pakets werden immer gedruckt. Bei 802.11-Netzwerken (WLAN, Wireless Local Area Network) bewirkt „-e“, dass tcpdump das Frame-Control-Feld des angegebenen Pakets druckt.
Der Paketheader enthält alle Adressen und die Länge des Pakets. Ähnlich wie bei FDDI-Netzwerken enthält dieses Paket normalerweise ein LLC-Paket. (Hinweis: Die folgende Beschreibung setzt voraus, dass Sie mit dem SLIP-Kompressionsalgorithmus vertraut sind (nt: SLIP steht für Serial Line Internet Protocol.), der zu finden ist in
Entsprechende Hinweise finden sich im RFC-1144.) Für SLIP-Netzwerke (nt: SLIP-Verbindungen, die als Netzwerk verstanden werden können, d. h. eine über eine serielle Leitung hergestellte Verbindung, und eine einfache Verbindung kann auch als Netzwerk betrachtet werden),
Es werden die „Richtungsanzeige“ des Pakets („I“ für „in“, „O“ für „out“), der Typ und die Komprimierungsinformationen gedruckt. Der Pakettyp wird zuerst gedruckt. Typen sind IP, UTCP und CTCP (nt: unbekannt, muss hinzugefügt werden). Bei IP-Paketen werden keine Verbindungsinformationen gedruckt (nt: bei SLIP-Verbindungen können die Verbindungsinformationen von IP-Paketen nutzlos oder undefiniert sein.
erneut bestätigen). Bei TCP-Paketen wird die Verbindungskennung gefolgt vom Typ gedruckt. Wenn das Paket komprimiert ist, wird der codierte Header gedruckt.
Zu diesem Zeitpunkt wird es für ein spezielles komprimiertes Paket wie folgt angezeigt:
*S+n oder *SA+n, wobei n die Anzahl der Pakete (Sequenznummer oder (Sequenznummer und Bestätigungsnummer)) darstellt, die erhöht oder verringert werden (nt | rt: S, SA ist schwer auszusprechen und muss übersetzt werden).
Bei nicht speziellen Archiven werden 0 oder mehr „Änderungen“ ausgedruckt. „Änderungen“ werden im folgenden Format ausgedruckt:
‚Flags‘ +/-/=n Paketdatenlänge. Komprimierte Headerlänge.
Dabei kann „flag“ folgende Werte annehmen:
U (dringender Zeiger), W (Pufferfenster), A (Bestätigung), S (Sequenznummer), I (Paket-ID) und der inkrementelle Ausdruck „= n“ gibt an, dass ein neuer Wert zugewiesen wird, und +/- zeigt eine Erhöhung oder Verringerung an. Das Folgende zeigt beispielsweise den Ausdruck eines ausgehenden komprimierten TCP-Pakets, das eine implizite Verbindungskennung enthält; die Bestätigungsnummer wird um 6 erhöht,
Die Sequenznummer erhöht sich um 49, die Paket-ID erhöht sich um 6, die Paketdatenlänge beträgt 3 Byte (Oktekt) und der komprimierte Header beträgt 6 Byte. (nt: Dies sollte also anscheinend kein speziell komprimiertes Datenpaket sein). ARP/RARP-Pakete Die Ausgabeinformationen von tcpdump für Arp/rarp-Pakete umfassen den Anforderungstyp und die der Anforderung entsprechenden Parameter. Das Anzeigeformat ist präzise und klar. Das Folgende ist ein „rlogin“ vom Host rtsg zum Host csam
Ein Beispielpaket zu Beginn des (Remote-Login-)Prozesses:
arp wer-hat csam sag rtsg
arp Antwort csam ist-bei CSAM
Die erste Zeile gibt an, dass rtsg ein ARP-Paket gesendet hat (nt: an das gesamte Netzwerksegment gesendet, ARP-Paket), um die Ethernet-Adresse von csam abzufragen
Csam antwortete mit ihrer eigenen Ethernet-Adresse (in diesem Fall werden Ethernet-Adressen durch Großbuchstaben identifiziert, während Internet
Die Adresse (d. h. IP-Adresse) wird durch die Namen in Kleinbuchstaben identifiziert. Wenn Sie tcpdump -n verwenden, können Sie anstelle der Namenskennungen deutlich die Ethernet- und IP-Adressen sehen:
arp wer-hat 128.3.254.6 sagen 128.3.254.68
ARP-Antwort 128.3.254.6 ist bei 02:07:01:00:01:c4 Wenn wir tcpdump -e verwenden, können wir deutlich sehen, dass das erste Paket an das gesamte Netzwerk gesendet wird, während das zweite Paket Punkt-zu-Punkt ist:
RTSG-Sendung 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: ARP-Antwort CSAM ist bei CSAM
Das erste Datenpaket zeigt, dass die Quell-Ethernet-Adresse des ARP-Pakets RTSG ist, die Zieladresse das gesamte Ethernet-Segment ist und der Wert des Typfelds hexadezimal 0806 ist (was auf ETHER_ARP (nt: ARP-Pakettypkennung) hinweist).
Die Gesamtlänge des Pakets beträgt 64 Bytes. TCP-Pakete (Hinweis: Im Folgenden wird davon ausgegangen, dass Sie mit TCP, wie in RFC-793 beschrieben, vertraut sind. Andernfalls sind die folgende Beschreibung und das tcpdump-Programm möglicherweise nicht sehr hilfreich für Sie. (nt: Warnungen können ignoriert werden,
Schauen Sie einfach weiter zu und kommen Sie zurück, um sich die Teile anzusehen, die Sie nicht kennen.). Normalerweise zeigt tcpdump TCP-Pakete im folgenden Format an:
src > dst: Flags Datensequenznummer Bestätigung Fenster dringend Optionen src und dst sind die Quell- und Ziel-IP-Adressen und die entsprechenden Ports. Flags bestehen aus S(SYN), F(FIN), P(PUSH, R(RST),
W(ECN CWT(nt | rep: unbekannt, muss ergänzt werden)) oder E(ECN-Echo(nt | rep: unbekannt, muss ergänzt werden)),
Ein einzelner '.' zeigt an, dass es keinen Flag-Identifikator gibt. Die Datensegment-Sequenznummer (Data-seqno) beschreibt eine Position im Sequenznummernraum, die den Daten in diesem Paket entspricht (nt: die gesamten Daten sind segmentiert,
Jedes Segment hat eine Sequenznummer und alle Sequenznummern bilden einen Sequenznummernraum (siehe folgendes Beispiel). Ack beschreibt das nächste Segment, das das lokale Ende in derselben Verbindung und Richtung empfangen soll.
Die Sequenznummer des Datenfragments (das die andere Partei senden soll). Fenster ist die Größe des an diesem Ende verfügbaren Datenempfangspuffers (und die Daten sollten entsprechend dieser Größe organisiert werden, wenn die andere Partei Daten sendet).
Urg (dringend) gibt an, dass das Datenpaket dringende Daten enthält. options beschreibt einige TCP-Optionen, die in spitzen Klammern ausgedrückt werden (z. B. <mss 1024>). Die Felder src, dst und flags werden immer angezeigt. Die anderen Felder werden je nach den Informationen im TCP-Protokollheader möglicherweise angezeigt oder nicht. Dies ist der Beginn einer Rlogin-Anwendungsanmeldung von TRSG bei CSAM.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 Win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: .ack 2 win 4096
rtsg.1023>csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
Die erste Zeile zeigt an, dass ein Datenpaket vom TCP-Port 1023 des RTSG-Hosts an den TCP-Login-Port des CSA-Hosts gesendet wurde (nt: der UDP-Protokoll-Port und der TCP-Protokoll-Port sind zwei verschiedene Bereiche, obwohl der Wertebereich derselbe ist). S zeigt an, dass das SYN-Flag gesetzt ist. Die Sequenznummer des Pakets ist 768512, und es enthält keine Daten. (Das Format ist: „first:last(nbytes)“, was bedeutet, „die Sequenznummer der Daten in diesem Paket beginnt bei first und endet bei last, letzte ausgenommen. Und es enthält insgesamt nbytes an Benutzerdaten.“) Es gibt keine Piggyback-Antwort (nt: aus dem folgenden Text geht hervor, dass die zweite Zeile das Datenpaket mit einer Piggyback-Antwort ist), die verfügbare Empfangsfenstergröße beträgt 4096 Bytes, und das anfordernde Ende (rtsg)
Die maximal zulässige Datensegmentgröße beträgt 1024 Bytes (nt: Diese Information wird an das antwortende CSAM-Ende als Anfrage für weitere Verhandlungen zwischen den beiden Parteien gesendet). Csam antwortet auf rtsg mit einem ähnlichen SYN-Paket, abgesehen von einer Huckepack-Bestätigung. rtsg antwortete auch auf das SYN-Paket von csam mit einem ACK-Paket als Antwort. „.“ bedeutet, dass in diesem Paket kein Flag gesetzt ist. Da dieses Antwortpaket keine Daten enthält, gibt es im Paket keine Datensegment-Sequenznummer. Erinnerung! Die Sequenznummer dieses ACK-Pakets ist nur eine kleine Ganzzahl 1. Es gibt folgende Erklärung: Für eine Sitzung auf einer TCP-Verbindung druckt tcpdump nur die Sequenznummer des anfänglichen Datenpakets an beiden Enden der Sitzung, und die nachfolgenden entsprechenden Datenpakete drucken nur die Differenz zur anfänglichen Paketsequenznummer. Das heißt, die Sequenznummer nach der anfänglichen Sequenznummer kann als die „relative Byte“-Position des aktuell in dieser Sitzung übertragenen Datensegments in den gesamten zu übertragenden Daten betrachtet werden (nt: die erste Position beider Seiten ist 1, d. h. die Startnummer des „relativen Bytes“). „-S“ überschreibt diese Funktion,
Bewirkt, dass die ursprünglichen Sequenznummern der Pakete ausgedruckt werden. Die Bedeutung der sechsten Zeile ist: rtsg hat 19 Bytes Daten an csam gesendet (die Bytes sind von 2 bis 20 nummeriert und die Übertragungsrichtung ist rtsg an csam). Das PUSH-Flag ist im Paket gesetzt. In Zeile 7
csam meldet, dass sie Bytes von rtsg bis zu Byte Nummer 21 empfangen hat, diese jedoch nicht einschließt. Diese Bytes werden im Empfangspuffer des Sockets von csam gespeichert. Dementsprechend
Die Empfangspufferfenstergröße von csam wird um 19 Bytes reduziert (nt: erkennbar an der Änderung des Win-Attributwerts in den Zeilen 5 und 7). csam sendet in diesem Paket in Zeile 7 auch ein Byte an rtsg. In den Zeilen 8 und 9 sendet csam weiterhin zwei Datenpakete mit nur einem Byte an rtsg, und dieses Datenpaket hat das PUSH-Flag. Wenn das erfasste TCP-Paket (nt: hier Snapshot) zu klein ist, sodass tcpdump seine Header-Daten nicht vollständig abrufen kann, versucht tcpdump, den unvollständigen Header zu analysieren.
Der verbleibende, nicht analysierte Teil wird als „[|tcp]“ angezeigt. Wenn der Header falsche Attributinformationen enthält (zum Beispiel ist sein Längenattribut tatsächlich länger oder kürzer als die tatsächliche Länge des Headers), zeigt tcpdump für den Header „[bad opt]“ an. Wenn die Länge des Headers uns verrät, dass einige Optionen (nt | rt: aus dem folgenden Text geht hervor, dass es sich um einige Optionen im Header des TCP-Pakets für das IP-Paket handelt, die später übersetzt werden) in diesem Paket enthalten sind,
Die Länge des echten IP-Pakets reicht nicht aus, um diese Optionen unterzubringen, und tcpdump zeigt „[bad hdr length]“ an. Erfassen Sie TCP-Pakete mit speziellen Flags (wie z. B. SYN-ACK-Flag, URG-ACK-Flag usw.). Im TCP-Header gibt es 8 Bits, die als Steuerbitbereich verwendet werden, und ihr Wert ist:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt: Aus dem Ausdruck können wir schließen, dass diese 8 Bits in einer ODER-Verknüpfung vorliegen, die später rückgängig gemacht werden kann) Nehmen wir nun an, wir möchten die Datenpakete überwachen, die während des gesamten Prozesses zum Herstellen einer TCP-Verbindung generiert werden. Denken Sie daran, dass TCP das Drei-Wege-Handshake-Protokoll verwendet, um eine neue Verbindung herzustellen. Die Datenpakete, die dieser Drei-Wege-Handshake-Verbindungssequenz entsprechen und die entsprechenden TCP-Steuerflags aufweisen, lauten wie folgt:
1) Der Verbindungsinitiator (nt:Caller) sendet ein Paket mit dem SYN-Flag
2) Der Empfänger (nt: Recipient) antwortet mit einem Paket mit SYN- und ACK-Flags
3) Nach Erhalt der Antwort vom Empfänger sendet der Initiator als Antwort ein Datenpaket mit einem ACK-Flag
0 15 31
-----------------------------------------------------------------
| Quellport | Zielport |
-----------------------------------------------------------------
|Sequenznummer |
-----------------------------------------------------------------
| Bestätigungsnummer |
-----------------------------------------------------------------
| HL | rsvd |C|E|U|A|P|R|S|F| Fenstergröße |
-----------------------------------------------------------------
| TCP-Prüfsumme | dringender Zeiger |
-----------------------------------------------------------------
Ein TCP-Header ohne Optionsdaten umfasst normalerweise 20 Bytes (nt | rt:options wird als Optionsdaten verstanden und muss zurückübersetzt werden). Die erste Zeile enthält die Bytes 0 bis 3,
Die zweite Zeile enthält die Bytes mit den Nummern 4-7. Beginnt die Nummerierung bei 0, steht das TCP-Steuerflag im Byte 13 (nt: linke Hälfte der vierten Zeile). 0 7| 15| 23| 31
----------------|------------------|------------------|----------------
| HL | rsvd |C|E|U|A|P|R|S|F| Fenstergröße |
----------------|------------------|------------------|----------------
| | 13. Oktett | | |
Schauen wir uns Byte Nummer 13 genauer an: | |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
Hier sind die Steuerflags, die uns interessieren. Von rechts nach links sind die Bits von 0 bis 7 nummeriert, also ist PSH Nummer 3 und URG Nummer 5.
Denken Sie daran, dass wir nur Pakete wollen, bei denen das SYN-Flag gesetzt ist. Schauen wir uns an, was in Byte 13 eines Paketheaders passiert, wenn das SYN-Bit gesetzt ist: |C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
In den Daten des Steuersegments ist nur Bit 1 (Bitnummer 1) gesetzt. Unter der Annahme, dass Byte Nummer 13 ein 8-Bit-unsigned-char-Typ ist und nach der Netzwerk-Bytenummer sortiert ist (nt: für ein Byte ist die Netzwerk-Bytereihenfolge gleichbedeutend mit der Host-Bytereihenfolge), lautet sein Binärwert wie folgt:
00000010 Und sein Dezimalwert ist: 0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2 (nt: 1 * 2^6 bedeutet 1 mal 2 hoch sechs, vielleicht ist es so klarer, d. h. die Exponenten 7 6 ... 0 im ursprünglichen Ausdruck werden nach unten verschoben, um es auszudrücken) Damit kommen wir unserem Ziel immer näher, denn wir wissen ja bereits, dass, wenn das SYN-Bit im Paketheader gesetzt ist, der Wert des 13. Bytes im Header 2 ist (nt: in der Netzwerkreihenfolge, also im Big-Endian-Modus, steht das wichtigste Byte vorne (vorne, d. h. die eigentliche Speicheradresse des Bytes ist relativ klein, das wichtigste Byte bezeichnet das höchste Bit der Zahl in der mathematischen Darstellung, also z. B. 3 in 356)). Die als Formel ausgedrückte Beziehung, die tcpdump verstehen kann, lautet:
tcp[13] 2 Daher können wir diese Beziehung als Filterbedingung für tcpdump verwenden. Das Ziel besteht darin, nur Pakete zu überwachen, die das SYN-Flag enthalten:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 bezieht sich auf die Netzwerkschnittstelle, beispielsweise eth0) Dieser Ausdruck besagt: „Lass Byte 13 des TCP-Pakets den Wert 2 haben“, und das ist, was wir wollen.
Nehmen wir nun an, wir müssen Pakete mit dem SYN-Flag erfassen, unabhängig davon, ob es andere Flags enthält. (nt: solange es SYN enthält, wollen wir es). Sehen wir uns an, was passiert, wenn ein Paket Folgendes enthält:
Was passiert, wenn ein SYN-ACK-Paket (nt: sowohl SYN- als auch ACK-Flags) eintrifft:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
Die Bits 1 und 4 von Byte 13 sind gesetzt und ihre Binärwerte sind:
00010010 In Dezimalzahlen umgerechnet: 0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18 (nt: 1 * 2^6 bedeutet 1 mal 2 hoch sechs, vielleicht ist es so klarer, d. h. die Exponenten 7 6 ... 0 im ursprünglichen Ausdruck werden nach unten verschoben, um es auszudrücken) Jetzt können wir nicht nur 'tcp[13] 18' als Filterausdruck für tcpdump verwenden, da dies dazu führen würde, dass nur Pakete mit dem SYN-ACK-Flag ausgewählt werden und alle anderen verworfen werden.
Erinnern Sie sich daran, dass unser Ziel darin besteht, nur das SYN-Flag für das Paket zu setzen und alle anderen Flags zu ignorieren. Um unser Ziel zu erreichen, müssen wir den Binärwert von Byte 13 mit einer anderen Zahl UND-verknüpfen, um den Wert des SYN-Bits zu erhalten. Das Ziel ist: Solange SYN gesetzt ist, verknüpfen wir es mit dem SYN-Wert von Byte 13 (nt: 00000010). 00010010 SYN-ACK 00000010 SYN
UND 00000010 (wir wollen SYN) UND 00000010 (wir wollen SYN)
-------- --------
= 00000010 = 00000010
Wir können sehen, dass die obige UND-Operation uns unabhängig davon, ob das ACK oder andere Flags des Pakets gesetzt sind, denselben Wert liefert, nämlich 2 im Dezimalsystem (00000010 im Binärsystem).
Wir wissen also, dass für Pakete mit dem SYN-Flag der folgende Ausdruck immer als wahr ausgewertet wird: ( ( Wert von Oktett 13 ) UND ( 2 ) ) ( 2 ) (nt: Wert von Oktett 13, d.h. der Wert von Byte 13) Die Inspiration folgte und wir erhielten den folgenden TCPDump-Filterausdruck
tcpdump -i xl0 'tcp[13] & 2 2' Beachten Sie, dass die einfachen Anführungszeichen oder Backslashes (nt: hier werden einfache Anführungszeichen verwendet) nicht weggelassen werden können, da die Shell sonst & nicht interpretieren oder ersetzen kann. UDP-Pakete Das Anzeigeformat von UDP-Datenpaketen kann anhand der von der jeweiligen Anwendung rwho generierten Datenpakete veranschaulicht werden:
actinide.wer > broadcast.wer:udp 84 Dies bedeutet: Port Who auf dem Actinide-Host hat ein UDP-Paket an Port Who auf dem Broadcast-Host gesendet (nt: Actinide und Broadcast beziehen sich beide auf Internetadressen).
Dieses Paket enthält 84 Byte Benutzerdaten. Einige UDP-Dienste können anhand des Quell- oder Zielports des Pakets oder anhand der angezeigten Protokollinformationen auf höherer Ebene identifiziert werden. Beispielsweise können Domain Name Service-Anfragen (DNS-Anfragen,
in RFC-1034/1035) und Sun RPC-Aufrufe an NFS (die vom NFS-Server initiierten Remote-Aufrufe (nt: Sun RPC), die in RFC-1050 beschrieben sind). UDP-Namensdienstanforderung (Hinweis: Die folgende Beschreibung setzt voraus, dass Sie mit dem in RFC-103 beschriebenen Domänendienstprotokoll vertraut sind. Andernfalls ist die folgende Beschreibung für Sie möglicherweise unverständlich.
Achten Sie nicht darauf, es soll Ihnen nur Angst machen, schauen Sie einfach weiter zu)) Namensdienstanforderungen haben das folgende Format:
src > dst: ID op? Flags qtype qclass Name (Länge)
(nt: Aus dem folgenden Text sollte das Format src > dst: id op flags qtype qclass? name (len) lauten)
Beispielsweise gibt es eine tatsächliche Anzeige von:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) Der Host h2opolo fragt den auf Helios laufenden Nameserver nach dem Adressdatensatz von ucbvax.berkeley.edu ab (nt: qtype entspricht A). Die Abfrage selbst hat die ID '3'. Symbol
„+“ bedeutet, dass das Flag für rekursive Abfragen gesetzt ist (nt: der DNS-Server kann den übergeordneten DNS-Server nach Adressdatensätzen abfragen, die der Server nicht enthält). Die über das IP-Paket gesendeten Abfrageanforderungsdaten sind 37 Byte lang, ohne die Header-Daten der UDP- und IP-Protokolle. Da diese Abfrageoperation der Standardwert ist (nt | rt: normal), wird das Feld op weggelassen.
Wenn das Feld op nicht ausgelassen wird, wird es zwischen „3“ und „+“ angezeigt. Ebenso ist qclass der Standardwert C_IN und wird ebenfalls nicht angezeigt. Wenn es nicht ausgelassen wird, wird es nach „A“ angezeigt. Bei der Ausnahmeprüfung werden zusätzliche Felder in eckigen Klammern angezeigt: Wenn eine Abfrage auch eine Antwort enthält (nt: kann als Antwort auf eine vorherige Anfrage verstanden werden) und diese Antwort autoritative oder zusätzliche Datensatzsegmente enthält,
ancount, nscout, arcount (nt: spezifische Feldbedeutung, die ergänzt werden soll) werden als „[na]“, „[nn]“, „[nau]“ angezeigt, wobei n die entsprechende Anzahl darstellt. Wenn die folgenden Antwortbits im Paket (wie AA-Bit, RA-Bit, rcode-Bit) oder ein beliebiges „muss 0 sein“-Bit in Byte 2 oder 3 gesetzt ist (nt: auf 1 gesetzt), wird „[b2&3]=x“ angezeigt, wobei x den Wert darstellt, nachdem Header-Byte 2 und Byte 3 mit „UND“ verknüpft wurden. UDP-Namensdienstantwort Für Name Service-Antwortpakete hat tcpdump das folgende Anzeigeformat
src > dst: ID Op Rcode Flags a/n/au Typ Klasse Daten (Länge)
Die konkrete Anzeige sieht beispielsweise so aus:
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97) Die erste Zeile zeigt an, dass helios auf die Anfrage Nr. 3 von h2opolo mit 3 Antwortdatensätzen (nt | rt: Antwortdatensätze), 3 Nameserverdatensätzen,
und 7 weitere Datensätze. Der erste Antwortdatensatz (nt: der erste von 3 Antwortdatensätzen) ist vom Typ A (nt: steht für Adresse) und seine Daten sind die Internetadresse 128.32.137.3.
Dieses UDP-Antwortpaket enthält 273 Byte Daten (ohne UDP- und IP-Headerdaten). Die Felder op und rcode werden ignoriert (nt: der tatsächliche Wert von op ist Query, rcode, d. h.
Der tatsächliche Wert des Antwortcodes ist NoError. Das Klassenfeld wird ebenfalls ignoriert (nt | rt: sein Wert ist C_IN, was auch der Standardwert des Datensatztyps A ist). Die zweite Zeile gibt an, dass Helios auf die von h2opolo gesendete Abfrageanforderung Nr. 2 geantwortet hat. In der Antwort lautet der Rcode NXDomain (nt: zeigt eine nicht vorhandene Domäne an) und es gibt keinen Antwortdatensatz.
Es enthält jedoch einen Nameserver-Eintrag, aber keinen Authority-Server-Eintrag (nt | ck: Aus dem oben Gesagten sind die Authority-Einträge hier die entsprechenden zusätzlichen
Datensätze). „*“ zeigt an, dass das Flag für autoritative Server-Antworten gesetzt ist (nt: sodass zusätzliche Datensätze Autoritätsdatensätze anzeigen).
Da kein Antwortdatensatz vorhanden ist, werden die Felder „Typ“, „Klasse“ und „Daten“ ignoriert. Das Flag-Feld kann andere Zeichen enthalten, wie etwa „-“ (nt: zeigt rekursive Abfrage an, d. h. RA-Flag ist nicht gesetzt), „|“ (nt: zeigt verkürzte Nachricht an, d. h. TC-Flag ist gesetzt). Wenn das „Frage“-Segment der Antwort keine Einträge enthält (nt: die Bedeutung jedes Eintrags muss ergänzt werden), wird „[nq]“ gedruckt. Beachten Sie, dass die Anfragen und Antworten des Nameservers groß sind und die standardmäßige Snaplen-Größe von 68 Bytes möglicherweise nicht ausreicht, um das gesamte Paket zu erfassen. Wenn Sie die Auslastung des Nameservers wirklich sehen müssen, erhöhen Sie den Snaplen-Wert mit der Option -s für tcpdump. SMB/CIFS-Dekodierung tcpdump kann jetzt den Inhalt von Paketen für SMB/CIFS/NBT-bezogene Anwendungen dekodieren (nt: „Server Message Block Common“, „Internet File System“)
„Abkürzung für NETBIOS, ein Netzwerkprotokoll, das auf TCP/IP implementiert ist“. Diese Dienste verwenden normalerweise die UDP-Ports 137/138 und den TCP-Port 139). Die ursprünglichen Dekodierungsfunktionen für IPX- und NetBEUI-SMB-Pakete können weiterhin verwendet werden (nt: NetBEUI ist eine erweiterte Version von NETBIOS). Standardmäßig dekodiert tcpdump die entsprechenden Datenpakete nur im prägnantesten Modus. Wenn wir detaillierte Dekodierungsinformationen wünschen, können wir die Startoption -v verwenden. Es ist zu beachten, dass -v sehr detaillierte Informationen erzeugt.
Beispielsweise generiert ein einzelnes SMB-Paket einen Bildschirm oder mehr an Informationen. Daher sollte diese Option nur bei Bedarf verwendet werden. Informationen zum SMB-Paketformat und zur Bedeutung der einzelnen Felder finden Sie unter www.cifs.org oder im Verzeichnis pub/samba/specs/ einer samba.org-Mirror-Site. SMB-Patches für Linux
(nt | rt: Patch) Beigetragen von Andrew Tridgell ([email protected]). NFS-Anfragen und -Antworten tcpdump druckt das folgende Format für Sun NFS (Network File System)-Anforderungs- und Antwort-UDP-Pakete aus:
src.xid > dst.nfs:Länge der Argumente
src.nfs > dst.xid: Antwort stat len op Ergebnisse Nachfolgend finden Sie eine Reihe spezifischer Ausgabedaten
sushi.6709 > wrl.nfs: 112 Leselink fh 21,24/10.73165
wrl.nfs > sushi.6709: Antwort ok 40 Readlink "../var"
sushi.201b > wrl.nfs:
144 Suche fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
Antwort ok 128 Suche fh 9,74/4134.3150 Die erste Ausgabezeile zeigt, dass der Host Sushi eine „Transaktionsanforderung“ (nt: Transaktion) an den Host Wrl gesendet hat. Die ID dieser Anforderung ist 6709 (beachten Sie, dass auf den Hostnamen die Transaktions-ID-Nummer folgt, nicht die Quellportnummer). Die Anforderungsdaten sind 112 Bytes lang, ohne die Länge der UDP- und IP-Header. Der Operationstyp ist Readlink (nt: Diese Operation ist eine symbolische Link-Leseoperation).
Die Betriebsparameter sind fh 21,24/10.73165 (nt: kann je nach tatsächlicher Betriebsumgebung wie folgt interpretiert werden, fd bedeutet, dass der Datei-Handle beschrieben wird, 21,24 bedeutet das Master/Slave-Gerätenummernpaar des Geräts, das diesem Handle entspricht, 10 bedeutet die i-Node-Nummer, die diesem Handle entspricht (nt: jede Datei entspricht einem i-Node im Betriebssystem, beschränkt auf Unix-ähnliche Systeme),
73165 ist eine Zahl (nt: kann als Zufallszahl zur Identifizierung dieser Anfrage verstanden werden, die konkrete Bedeutung muss ergänzt werden)). In der zweiten Zeile reagiert WRL mit "OK" und gibt das tatsächliche Verzeichnis des symbolischen Links zurück, den Sushi im Feld der Ergebnisse lesen möchte. Die dritte Zeile zeigt, dass Sushi WRL erneut auffordert, nach der von 'FH 9,74/4096.6878' beschriebenen "Xcolors" -Datei zu suchen. Wenn die Option -v (Option für ausführliche Drucke) von TCPDump festgelegt wird, werden zusätzliche Informationen angezeigt.
Sushi.1372a> wrl.nfs:
148 Lesen Sie FH 21,11/12.195 8192 Bytes @ 24576
wrl.nfs> Sushi.1372a:
Antwort OK 1472 Lesen Sie Reg 100664 IDS 417/0 SZ 29388 (Die Option -V würde normalerweise auch die Felder TTL, ID, Länge und Fragmentierung des IP -Headers drucken, aber sie werden in diesem Beispiel weggelassen.)
In der ersten Zeile fordert Sushi WRL auf, 8192 Bytes von Daten aus Datei 21,11/12.195 (oben beschrieben) zu lesen, beginnend bei Offset 24576 -Bytes.
WRL antwortet auf erfolgreiches Lesen;
頭, 甚至UDP頭信息也為空(nt: 源和目的應該要有), 這將導致這些片段不能滿足過濾條件, 從而沒有被打印). -v 選項除了顯示文件數據信息, 還會顯示附加顯示文件屬性信息: file type(文件類型, ''REG'' 表示普通文件), file mode(文件存取模式, 8進制表示的), uid 和gid(nt: 文件屬主和組屬主), file size (文件大小). Wenn das -v -Flag mehrmals angegeben wird (z. B. -VV), zeigt TCPDump detailliertere Informationen an. Es muss angemerkt werden, dass NFS -Anforderungspakete viele Daten enthalten
'-s 192', um Snaplen zu erhöhen, mit der die Netzwerkbelastung (NT: Verkehr) von NFS-Anwendungen überwacht werden kann. NFS -Antwortpakete folgen nicht ausschließlich den entsprechenden Anforderungspaketen (NT: RPC -Operation).
Das Antwortpaket kann nicht analysiert werden. AFS -Anfragen und Antworten AFS (NT: Andrew -Dateisystem, Transarc, unbekannt, ergänzt) Anforderungen und Antworten haben die folgenden Versprechen src.sport> dst.dport: rx packet-Typ
src.sport> dst.dport: rx packet-service call-name args
src.sport> dst.dport: rx paket-type service Antwort Anrufname args Elvis.7001> Pike.AFSFS:
RX Data FS CALL ALOTE FID 536876964/1/1 ".Newsrc.new"
Neue FID 536876964/1/1 ".Newsrc"
Pike.AFSFS> Elvis.7001: RX -Daten fs Antwort umbenennen In der ersten Zeile sendet der Host Elvis ein RX -Paket an Pike.
Hier
Der Beginn eines Anrufs (NT: RPC, Remote -Prozeduranruf).
Der ursprüngliche Verzeichnis -Deskriptor ist 536876964/1/1, der Original -Dateiname ".Newsrc.New", der neue Verzeichnisdeskriptor ist 536876964/1/1 und der neue Dateiname ".Newsrc".
Der Host Pike reagiert auf die RPC -Anforderung für den Umbenennenbetrieb (die Antwort zeigt an, dass der Umbenennungsbetrieb erfolgreich ist, da die Antwort ein Paket ist, das den Dateninhalt und nicht ein abnormales Paket enthält). Im Allgemeinen erhalten alle Anforderungen von AFS RPC einen Namen (NT: Decodes), wenn sie angezeigt werden.
Darüber hinaus werden einige Parameter dieser RPC -Anfragen bei der Anzeige ein Name angegeben (nt | rt: decodieren, decodieren, im Allgemeinen ist die Benennung beispielsweise auch sehr direkt.
Ein interessanter Parameter wird als "interessant" angezeigt, was schwer auszusprechen ist und übersetzt werden muss). Dieses Display -Format ist so konzipiert, dass es "leicht zu verstehen auf einen Blick" ist, aber es ist möglicherweise nicht sehr nützlich für Menschen, die nicht mit der Funktionsweise von AFS und RX vertraut sind (NT: Ignorieren Sie es einfach, es ist nur um Sie zu erschrecken, lesen Sie einfach weiter). Wenn das Flag -v (ausführlich) wiederholt angegeben wird (NT: wie -VV), druckt TCPDump die Bestätigungspakete aus (NT: kann als Pakete verstanden werden, die sich von den Antwortpaketen unterscheiden) und zusätzliche Header -Informationen.
(NT: Kann als alle Pakete verstanden werden, nicht nur als zusätzliche Header -Informationen des Bestätigungspakets), beispielsweise die RX -Anruf -ID (die ID des Anfrageanforderungsaufrufs im Anforderungspaket).
Anrufnummer ('Call Request' -Nummer), Sequenznummer (NT: Paketsequenznummer),
Seriennummer (NT | RT: Kann als ein weiteres serielles Signal im Zusammenhang mit den Daten im Paket verstanden werden, muss die spezifische Bedeutung ergänzt werden), die Kennung des Anforderungspakets.
Daher wird es weggelassen), und die MTU -Verhandlungsinformationen im Bestätigungspaket werden ebenfalls ausgedruckt (NT: Das Bestätigungspaket ist das Bestätigungspaket relativ zum Anforderungspaket, maximale Übertragungseinheit). Wenn die Option -V dreimal wiederholt wird (NT: wie -vvv), wird der 'Sicherheitsindex' und 'Service -ID' des AFS -Anwendungstyppakets gedruckt. Für Pakete, die eine Ausnahme angeben (NT: Abort -Paket, das als Paket verstanden werden kann, mit dem der Empfänger über eine Ausnahme aufgetreten ist), druckt TCPDump Fehlercodes aus.
Für Ubik Beacon -Pakete (NT: Ubik Beacon Indication -Paket kann Ubik als spezielles Kommunikationsprotokoll verstanden werden, kann als Special Communication Protocol, Beacon -Pakete, Beacon -Datenpakete verstanden werden, als einige Datenpakete verstanden werden, die auf Schlüsselinformationen in der Kommunikation hinweisen. AFS-Anfragen sind groß und haben viele Parameter, sodass ein größerer Snaplen für TCPDUMP benötigt wird. AFS -Antwortpakete geben nicht an, zu welchem Remote -RPC das RPC gehört.
(Service Index), um das empfangene Antwortpaket zu entsprechen. Kip AppleTalk Protocol (NT | RT: DDP in UDP kann als DDP verstanden werden, das Appletalk -Datenablieferungsprotokoll,
Es entspricht dem Netzwerkschichtprotokoll, das den Kip Appletalk -Protokollstapel unterstützt, und DDP selbst wird über UDP übertragen.
Das auf UDP für andere Netzwerke implementierte Netzwerkschicht ist Kip AppleTalk ein vollständiger Netzwerkprotokollstack, der von Apple entwickelt wurde). AppleTalk -DDP -Pakete sind in UDP -Paketen eingekapselt, und deren Dekapulation (NT: entsprechend der Dekodierung) und das Ableiten entsprechender Informationen folgen auch den DDP -Paketregeln.
(NT: Einkapseln, einkapseln, äquivalent zu Codierung, Entkapsel, dekapulieren, entspricht dem Dekodieren, Dump, Dump, normalerweise auf das Drucken seiner Informationen). Die Datei /etc/atalk.names enthält die Zuordnung der numerischen Kennungen von Appletalk -Netzwerken und Knoten zu ihren Namen.
Nummername 1,254 Äther
16.1 ICSD-NET
1.254.110 ACE Die ersten beiden Zeilen geben an, dass es zwei AppleTalk -Netzwerke gibt.
Die Kennung eines Netzwerks beträgt normalerweise nur zwei Bytes, was der Hauptunterschied zwischen den beiden Identifikatoren ist) (NT: 1.254.110 kann als ACE -Host im Ether -Netzwerk verstanden werden).
Der Kennung und sein entsprechender Name müssen durch einen Raum getrennt werden. Die vollständige AppleTalk -Netzwerkadresse wird im folgenden Format angezeigt:
net.host.port Das Folgende ist eine bestimmte Anzeige:
144.1.209.2> ICSD-NET.112.220
Office.2> ICSD-NET.112.220
JSSMAG.149.235> ICSD-NET.2
(Wenn die Datei /etc/atalk.names nicht vorhanden ist oder keine Eingabe für das entsprechende AppleTalK -Host/ -Netzwerk hat, wird die Netzwerkadresse des Pakets numerisch angezeigt.) In der ersten Zeile sendet der Knoten 209 im Netzwerk 144.1 ein NBP-Anwendungspaket über Port 2 an den Knoten 112 Hören auf Port 220 im Netzwerk ICSD-NET.
(NT | RT: NBP, Name Bindungsprotokoll, von den Daten stellt der NBP -Server diesen Dienst auf Port 2 an.
'DDP -Port 2' kann als "DDP, das der Transportschicht Port 2 entspricht, verstanden werden. Die zweite Zeile ähnelt der ersten Zeile, außer dass die gesamte Adresse der Quelle durch 'Office' identifiziert wird.
Die dritte Zeile gibt an, dass der Knoten 149 im JSSMAG-Netzwerk ein Datenpaket an Port 2 (NBP-Port) aller Knoten im ICSD-NET-Netzwerk über Port 235 gesendet hat (Beachten Sie, dass
In AppleTalk -Netzwerken handelt es sich bei einer Adresse nicht um einen Knoten, sodass sie eine Broadcast -Adresse sind, sodass Knotenkennungen und Netzwerkkennungen am besten in /etc/atalk.names unterschieden werden.
NT: Andernfalls kann ein Flag X.port nicht bestimmen, ob X auf den Port aller Hosts in einem Netzwerk oder den Port eines bestimmten Hosts X bezieht). TCPDUMP kann NBP (Name Bindungsprotokoll) und ATP (Appletalk -Transportprotokoll) für andere Anwendungsschichtprotokolle analysieren.
Wenn das Protokoll nicht mit einem gebräuchlichen Namen registriert wurde, werden nur die Protokollnummer und die Paketgröße gedruckt. NBP -Pakete werden im folgenden Format angezeigt:
ICSD-NET.112.220> JSSMAG.2: NBP-LKUP 190: "=: Laserwriter@*"
JSSMAG.209.2> ICSD-NET.112.220: NBP-Repry 190: "RM1140: Laserwriter@*" 250
TechPit.2> ICSD-NET.112.220: NBP-Repry 190: "TechPit: Laserwriter@*" 186
Die erste Zeile gibt an, dass der Knoten 112 im ICSD-NET-Netzwerk eine Name-Abfrageanforderung für 'Laserwriter' über Port 220 an Port 2 aller Knoten im JSSMAG-Netzwerk (NT:
Hier kann der Name als Name einer Ressource verstanden werden, z. B. ein Drucker). Die zweite Zeile zeigt, dass der Knoten 209 im Netzwerk JSSMAG auf Port 220 des ICSD-Net.112-Knotens über Port 2 reagierte: Ich habe einen 'Laserwriter' -Ressource, dessen Ressourcenname 'RM1140' ist, und ich stelle diesen Ressourcendienst in Port 250 an. Die Sequenznummer dieser Antwort ist 190, was der Sequenznummer der Sequenznummer entspricht, die die Sequenznummer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Quer-Nummer-Quer-Nr. Die dritte Zeile ist auch eine Antwort auf die erste Zeilenanforderung: Der Knoten TechPit antwortete auf Port 220 des ICSD-NET.112 Knoten über Port 2: Ich habe eine 'Laserwriter' -Ressource, deren Ressourcenname 'TechPit' ist und in Port 186 angegeben ist. Das Anzeigeformat von ATP -Datenpaketen lautet wie folgt JSSMAG.209.165> Helios.132: ATP-REQ 12266 <0-7> 0xAE030001
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 0 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 1 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 2 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 3 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 5 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 6 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp*12266: 7 (512) 0xAE040000
JSSMAG.209.165> Helios.132: ATP-REQ 12266 <3,5> 0xAE030001
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 3 (512) 0xAE040000
Helios.132> JSSMAG.209.165: ATP-Resp 12266: 5 (512) 0xAE040000
JSSMAG.209.165> Helios.132: ATP-Rel 12266 <0-7> 0xAE030001
JSSMAG.209.133> Helios.132: ATP-REQ* 12267 <0-7> 0xAE030002
Die erste Zeile zeigt an, dass der Knoten JSSMAG.209 ein Anforderungspaket mit Sitzungsnummer 12266 an den Knoten Helios gesendet hat, um Helios zu fordern
Antwort 8 Pakete (Die Sequenznummern dieser 8 Pakete sind 0-7 (NT: Die Sequenznummer unterscheidet sich von der Sitzungsnummer, der Anzahl einer vollständigen Übertragung.
Ersteres ist die Anzahl jedes Datenpakets im Übertragung. Helios antwortet mit acht 512-Byte-Paketen.
Die Anzahl in Klammern zeigt die Größe der Daten im Paket an, die den ATP -Header nicht mit Sequenznummer 7 (Zeile 8) enthalten, gibt es draußen ein '*' Zeichen.
Zeigt an, dass das EOM -Flag des Datenpakets festgelegt ist (NT: EOM, Ende der Medien, kann so verstanden werden, dass die Datenantwort einer Sitzung abgeschlossen ist). Die nächste Zeile 9 gibt an, dass JSSMAG.209 eine weitere Anfrage an Helios gestellt hat: Bitte geben Sie die Pakete mit den Sequenznummern 3 und 5 weiter. Nachdem Helios die beiden Pakete erhalten hatten, endet JSSMAG.209 aktiv (veröffentlicht). In der letzten Zeile sendet JSSMAG.209 ein Anforderungspaket an Helios, um die nächste Sitzung zu starten.
(NT: XO, genau einmal, kann als in dieser Sitzung verstanden werden. Das Datenpaket wird genau einmal am empfangenden Ende verarbeitet, auch wenn die andere Partei das Datenpaket wiederholt.
Der Empfänger verarbeitet es nur einmal, was einen speziell entwickelten Paketempfänger- und Verarbeitungsmechanismus erfordert). IP -Paket -Fragmentierung (NT: Bezieht sich auf die Aufteilung eines IP -Datenpakets in mehrere IP -Datenpakete.) Fragmentierte IP -Pakete (NT: Kleine IP -Pakete, die nach einem großen IP -Paket generiert wurden, haben die folgenden zwei Anzeigformate.
(Frag ID: Größe@offset+)
(Frag ID: Größe@offset)
(Das erste Format zeigt an, dass nach diesem Fragment nachfolgende Fragmente vorhanden sind. Das zweite Format zeigt an, dass dieses Fragment das letzte Fragment ist.) ID repräsentiert die Fragmentierungsnummer (NT: Aus dem folgenden Text wird jedem zu fragmentierten großen IP -Paket eine Fragmentierungsnummer zugewiesen, um zu unterscheiden, ob jedes kleine Fragment aus demselben Datenpaket fragmentiert ist).
Die Größe zeigt die Größe dieses Fragments an, ohne die Fragment -Header -Daten anzuzeigen.
Ein IP -Paket ist insgesamt fragmentiert, einschließlich Header und Daten, nicht nur der Daten). Jedes Fragment erzeugt die entsprechende Ausgabe.
Der IP-Header ist in das erste Fragment platziert), sodass TCPDump diese Informationen für das erste Fragment angezeigt wird, gefolgt von dem Fragment selbst.
Das FTP -Anwendungskommunikationsfragment über das CSNET -Netzwerk (NT: CSNET -Verbindung kann als eine im CSNET -Netzwerk festgelegte Verbindung verstanden werden):
Arizona.ftp-DATA> RTSG.1170: 1024: 1332 (308) ACK 1 Gewinn 4096 (Frag 595A: 328@0+)
Arizona> RTSG: (Frag 595A: 204@328)
RTSG.1170> Arizona.ftp-Data: ACK 1536 Gewinn 2560 Ein paar Punkte erwähnenswert:
Im ersten und zweiten Druckzeilen gibt es nach der Adresse keine Portnummer.
Dies liegt daran, dass die TCP -Protokollinformationen im ersten Fragment platziert sind. Zweitens können wir aus der ersten Zeile sehen, dass Arizona 308 Bytes von Benutzerdaten an RTSG senden muss, aber die Tatsache ist, dass das entsprechende IP -Paket insgesamt 512 Bytes von Daten nach der Fragmentierung erzeugt (das erste Fragment enthält 308 Bytes von Daten, und das zweite Fragment enthält 204, in denen sich die Daten in der Daten, wie Sie mit einer Sequenz sind, in der Folge, in der Sie in den Daten sind, in der Sie in der HABE -ZEITS -ZEITS -HABE -HALTE -HILDE -NIME -NIMME sind). 12 reicht aus, um Sie für eine Weile zu verwirren (tatsächlich konzentrieren Sie sich nur auf 308,
Machen Sie sich keine Sorgen über die Gesamtmenge der Daten nach der Fragmentierung). Wenn ein Datenpaket (nt | rt: auf ein IP-Datenpaket) über ein Nicht-IP-Fragmentierungsflag verfügt, wird es am Ende mit '(df)' angezeigt. Zeitstempel Standardmäßig enthalten alle TCPDUMP -Ausgabestellungen Zeitstempelinformationen.
Das Anzeigeformat von Zeitstempelinformationen lautet wie folgt
HH: MM: ss.Frac (NT: Stunde: Minute: Second. (NT: FRAC Unbekannt, muss ergänzt werden))
Die Präzision dieses Zeitstempels steht im Einklang mit der Kernelzeitgenauigkeit und spiegelt die Zeit wider, in der der Kernel das entsprechende Datenpaket zum ersten Mal sah (NT: SAW, was bedeutet, dass das Datenpaket betrieben werden kann).
Die Zeit, die das Datenpaket benötigt, um von der physischen Linie in den Kernel zu übertragen, und die Zeit, die der Kernel mit Interrupts für dieses Paket ausgibt, wird nicht berücksichtigt. Befehlsnutzung TCPDump verwendet die Befehlszeilenmethode, und sein Befehlsformat lautet:
tcpdump [-AddeFllnnopqrstuuvxx] [-c count] [-c File_Size] [-f -Datei] [-I -Schnittstelle] [-m -Modul] [-m Secret] [-r -Datei] [-s Snaplen] [-t -Typ] [-W -Datei] [-W FileCount] [-E -spi@ipadDr algo: Heimung] [-Y -Datal] [-E -spi@ipaddr algo: ... Eine kurze Einführung in TCPDump -Optionen
: : : : : : : : : : : : : : : TCPDump -bedingte Ausdrücke Dieser Ausdruck wird verwendet, um zu bestimmen, welche Pakete gedruckt werden. Ein Ausdruck besteht aus einem oder mehreren Primitiven.
: : : : : : : : : : : : : : : Zusätzlich zu den oben beschriebenen Primitiven gibt es andere Formen von Primitiven und unterscheiden sich von den obigen Expressionsformaten. Expressionselemente können auch durch die Schlüsselwörter verbunden und nicht mit komplexeren bedingten Ausdrücken "Host Foo und nicht Port-FTP und nicht Port-FTP-DATA" (NT: Die Filterbedingung kann als Host des Datenpakets FOOs und den Ports, das in der FOTP-Datei, in der das FOOD) und die nach dem FTP-Dato, und das usw.-usw.-ted-tex-tex-tex-tex-tex-usw.- und ted-usw. (port 20) verstanden wird, und die nach dem HOST. . Aus Gründen der Bequemlichkeit kann der gleiche Modifikator weggelassen werden, wie z. (Port 53)). Mit Hilfe von Klammern und entsprechenden Operatoren können Ausdrücke miteinander kombiniert und verwendet werden (da Klammern Sonderzeichen der Shell sind, müssen sie entkommen, wenn sie in Shell -Skripten oder Terminals verwendet werden, dh '(' und ')' als '\ (' und '\)'). Gültige Operatoren sind:
Negation ("!" Oder "nicht")
Und Operator ("&&" oder "und")
Oder Operation ("||" oder "oder") Der Negationsbetreiber hat die höchste Vorrang. Der 'und' Operator muss explizit geschrieben werden, anstatt nur die vorhergehenden und folgenden Ausdrücke nebeneinander zu platzieren (NT: Der 'und' Operator zwischen den beiden kann nicht weggelassen werden). Wenn vor einem Kennung kein Schlüsselwort vorhanden ist, wird beispielsweise das zuletzt verwendete Schlüsselwort während der Analyse des Ausdrucks (normalerweise das Kennzeichen der Kennung von links nach rechts).
Nicht Gastgeber VS und ACE
ist eine Vereinfachung des folgenden Ausdrucks:
Nicht Host VS und Host Ace
Anstelle von nicht (Host vs oder Ace). Der gesamte bedingte Expression kann als einzelner String -Parameter oder als mehrere Parameter verwendet werden, die durch Räume in TCPDump unterteilt sind, was im Allgemeinen bequemer ist. nach Spitzen und als Schnur analysiert. Anhang: Expressionselemente von TCPDump (NT: TRISE Mittel in der folgenden Beschreibung: Der entsprechende bedingte Ausdruck enthält nur einen spezifischen Ausdruck, der unten aufgeführt ist. Zu diesem Zeitpunkt ist der Ausdruck wahr, dh der Zustand ist erfüllt) DST Host Host
Wenn die Zieldomäne des IPv4/V6 -Pakets Host ist, kann der entsprechende bedingte Ausdruck wahr sein.
SRC Host Host
Wenn die Quelldomäne des IPv4/V6 -Pakets Host ist, ist der entsprechende bedingte Ausdruck wahr.
Host kann eine IP -Adresse oder ein Hostname sein.
Host Host
Wenn die Quelle oder die Zieladresse des IPv4/V6 -Pakets Host ist, ist der entsprechende bedingte Ausdruck wahr.
IP Host Host
Es kann auch ausgedrückt werden als:
Ether Proto \ IP und Host Host (NT: Dieser Ausdruck wird unten erläutert, wobei IP vor der IP entkommen muss, da IP bereits ein Schlüsselwort für TCPDump ist.)
Wenn Host ein Host mit mehreren IPs ist, wird jede Adresse für die Paketabteilung verwendet (NT: Das heißt, die Zieladresse des an den Host gesendeten Pakets kann eines dieser IPs sein, und die Quelladresse des vom Host empfangenen Pakets kann auch eines dieser IPs sein).
Äther dst ehost
Wenn die Ethernet -Zieladresse des Datenpakets (NT: auf ein Paket bezieht, das durch TCPDump, einschließlich IP -Pakete und TCP -Pakete, gekrabbeln kann), ist der entsprechende bedingte Ausdruck wahr.
Ether Src Ehost
Wenn die Ethernet -Quelladresse des Pakets eHost ist, ist der entsprechende bedingte Ausdruck wahr.
Äther Host ehost
Wenn die Ethernet -Quelle oder die Zieladresse des Pakets eHost ist, ist der entsprechende bedingte Ausdruck wahr.
Gateway Host
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::3s::::::333:33333333333333333333ag33333333333333333333333333333 es333333333333333333333333333333 es33 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann dann dann dann aber33333333333333333333 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 dann3 dann3 aber3 dann3 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann nichtie dasen aber aber abersossoss aberstens aberstensss aberten aber abers :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::3s::::::333:33333333333333333333ag33333333333333333333333333333 es333333333333333333333333333333 es33 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann dann dann dann aber33333333333333333333 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 dann3 dann3 aber3 dann3 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann nichtie dasen aber aber abersossoss aberstens aberstensss aberten aber abers :::::::::::
Derzeit funktioniert diese Option nicht in einer Konfigurationsumgebung, die das IPv6 -Adressformat unterstützt (NT: Konfiguration, Konfigurationsumgebung, kann als Netzwerkkonfiguration beider Kommunikationsparteien verstanden werden).
DST -Netz
Wenn das Feld Netzwerknummer der Zieladresse des Pakets (IPv4 oder IPv6 -Format) NET ist, ist der entsprechende bedingte Ausdruck wahr.
Net kann ein Name aus der Netzwerkdatenbankdatei /etc /networks sein oder eine Netzwerknummer in digitaler Form sein.
Eine digitale IPv4-Netzwerknummer wird als DOT-Part-Vierfach (z. B. 192.168.1.0) oder Dot-Teil-Triple (z. B. 192.168.1) oder DOT-Teil-Binärdateien (z. B. 172,16) oder Gruppeneinheit (z. B. 10);
對應于這四種情況的網絡掩碼分別是:四元組:255.255.255.255(這也意味著對net 的匹配如同對主機地址(host)的匹配:地址的四個部分都用到了),三元組:255.255.255.0, 二元組: 255.255.0.0, 一元組:255.0.0.0.
Für das IPv6 -Adressformat muss die Netzwerknummer ausgeschrieben werden (8 Teile müssen ausgeschrieben werden).
ff: ff: ff: ff: ff: ff: ff: ff: ff: ff, so ipv6 -Netzwerk -Matching ist ein echter Weg (Nt | Rt | IFID durch die folgenden Netze/Len)
SRC NET NET
Wenn das Feld Netzwerknummer der Quelladresse des Pakets (IPv4- oder IPv6 -Format) NET ist, ist der entsprechende bedingte Ausdruck wahr.
Netznetz
Wenn das Feld Netzwerknummer der Quelle oder Zieladresse des Pakets (IPv4- oder IPv6 -Format) NET ist, ist der entsprechende bedingte Ausdruck wahr.
Netto -Netto -Masken -Netzmaske
Wenn die Netzwerkmaske der Quelle oder des Zieladresses des Pakets (IPv4- oder IPv6 -Format) mit NetMask übereinstimmt, kann der entsprechende bedingte Ausdruck trugen.
Net Net/Len
Wenn die Anzahl der Bits im Feld Netzwerknummer der Quell- oder Zieladresse des Pakets (IPv4- oder IPv6-Format) mit Len übereinstimmt, kann diese Option auch mit SRC verwendet werden.
DST -Port
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::3s::::::333:33333333333333333333ag33333333333333333333333333333 es333333333333333333333333333333 es33 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann dann dann dann aber33333333333333333333 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 dann3 dann3 aber3 dann3 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann nichtie dasen aber aber abersossoss aberstens aberstensss aberten aber abers :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::3s::::::333:33333333333333333333ag33333333333333333333333333333 es333333333333333333333333333333 es33 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann dann dann dann aber33333333333333333333 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 nicht3 dann3 dann3 aber3 dann3 nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht nicht dann nichtie dasen aber aber abersossoss aberstens aberstensss aberten aber abers :::::::::::
SRC -Port Port
Wenn der Quellport des Pakets Port ist, ist der entsprechende bedingte Ausdruck wahr.
Port Port
Wenn der Quell- oder Zielport des Pakets Port ist, ist der entsprechende bedingte Ausdruck wahr.
DST PORTELANGE PORT1-PORT2
Wenn der Zielport des Datenpakets (einschließlich IP/TCP, IP/UDP, IP6/TCP oder IP6/UDP -Protokoll) zum Port -Bereich von Port1 bis Port2 gehört, einschließlich Port1, Port2), ist die entsprechende bedingte Expression der TCPDUMPS -PARSIGE und der PORT -POLT -POLT -POLT -POLT -POLT -POLT -AT -POLT -OPT -OBTE -POLT -POLT -POLT (NT -Port1).
SRC PORTELANGE PORT1-PORT2
Wenn der Quellport des Datenpakets zum Portbereich von Port1 nach Port2 (einschließlich Port1, Port2) gehört, ist der entsprechende bedingte Ausdruck wahr.
Port1-port2
Wenn der Quell- oder Zielport des Pakets zum Portbereich von Port1 nach Port2 (einschließlich Port1, Port2) gehört, ist der entsprechende bedingte Ausdruck wahr.
Den oben genannten Optionen für den Port können beispielsweise: TCP oder UDP vorangegangen werden:
TCP SRC -Port -Port
Dadurch wird TCPDump -Crawl nur TCP -Pakete, deren Quellport einen Port ist.
Weniger Länge
Wenn die Länge des Pakets kleiner als Länge oder gleich Länge ist, ist der entsprechende bedingte Ausdruck wahr.
größere Länge
Wenn die Länge des Pakets größer als Länge oder gleich Länge ist, ist der entsprechende bedingte Ausdruck wahr.
IP -Protokollprotokoll
Wenn das Paket ein IPv4 -Paket ist und sein Protokolltyp Protokoll ist, ist die entsprechende bedingte Expression wahr.
: : : : : : : : : : : : : : :
IP6 -Protokoll
Wenn das Paket ein IPv6 -Paket ist und sein Protokolltyp Protokoll ist, ist die entsprechende bedingte Expression wahr.
Beachten Sie, dass dieser Ausdruck nicht den gesamten Protokoll -Header -Inhalt in der Protokoll -Header -Kette im Datenpaket ausdruiert.
IP6 -Protokollprotokoll
Wenn das Paket ein IPv6 -Paket ist und seine Protokollkette einen Protokollkopf von Typ -Protokoll enthält, ist die entsprechende bedingte Expression beispielsweise wahr. IP6 -Protochain 6
Es wird mit den IPv6-Paketen mit dem TCP-Protokoll-Header in seiner Protokoll-Header-Kette übereinstimmt.
Der entsprechende BPF, der durch diese ausgelöst wird
Der BPF -Optimierungscode kümmert sich auch nicht um diesen Teil, sodass das durch diese Option ausgelöste Paketanpassung möglicherweise langsamer ist.
IP -Protochänenprotokoll
Die Bedeutung ist die gleiche wie das IP6 -Protochain -Protokoll, dies wird jedoch in IPv4 -Paketen verwendet.
die Sendung
Wenn das Paket ein Ethernet -Broadcast -Paket ist, ist der entsprechende bedingte Ausdruck wahr.
IP -Sendung
Wenn das Paket ein IPv4 -Broadcast -Paket ist, wird der entsprechende bedingte Ausdruck wahr sein.
Wenn die Netzwerkmaske der Netzwerkschnittstelle, in der das Paket erfasst wird, illegal ist oder die Schnittstelle die entsprechende Netzwerkadresse und das entsprechende Netzwerk überhaupt nicht setzt oder Pakete auf der "beliebigen" Netzwerkschnittstelle unter Linux fängt (diese "jede" jede "jede" Schnittstelle kann Datenpakete von mehr als einer Schnittstelle im System empfangen (nt: Tatsächlich können Sie die verfügbaren Schnittstellen im System im System aus dem System unterhalten).
Ether Multicast
Wenn das Paket ein Ethernet -Multicast -Paket ist (NT: Multicast, kann es gleichzeitig als Übergabe von Nachrichten an eine Reihe von Zieladressen verstanden werden, die als Sendung bezeichnet werden können), ist der entsprechende bedingte Ausdruck zutreffend. Das Byte in einem Ethernet -Paket ist 1, was bedeutet, dass dies ein Multicast -Paket ist).
IP Multicast
Wenn das Paket ein IPv4 -Multicast -Paket ist, ist der entsprechende bedingte Ausdruck wahr.
IP6 Multicast
Wenn das Paket ein IPv6 -Multicast -Paket ist, ist der entsprechende bedingte Ausdruck wahr.
Ether -Protokollprotokoll
Wenn das Paket zum folgenden Ethernet -Protokolltyp gehört, ist die entsprechende bedingte Expression wahr.
Protokollfeld, das eine Nummer oder die unten aufgeführten Namen sein kann: IP, IP6, ARP, RARP, Atalk (AppleTalk -Netzwerkprotokoll),
aarp(nt: AppleTalk Address Resolution Protocol, AppleTalk網絡的地址解析協議),
decnet(nt: 一個由DEC公司所提供的網絡協議棧), sca(nt: 未知, 需補充),
lat(Local Area Transport, 區域傳輸協議, 由DEC公司開發的以太網主機互聯協議),
mopdl, moprc, iso(nt: 未知, 需補充), stp(Spanning tree protocol, 生成樹協議, 可用于防止網絡中產生鏈接循環),
ipx（nt: Internetwork Packet Exchange, Novell 網絡中使用的網絡層協議）, 或者
netbeui(nt: NetBIOS Extended User Interface，可理解為, 網絡基本輸入輸出系統接口擴展).
protocol字段可以是一個數字或以下協議名之一:ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat,
mopdl, moprc, iso, stp, ipx, 或者netbeui.
必須要注意的是標識符也是關鍵字, 從而必須通過'\'來進行轉義.
SNAP：子網接入協議（SubNetwork Access Protocol）)
在光纖分布式數據網絡接口(其表達元形式可以是'fddi protocol arp'), 令牌環網(其表達元形式可以是'tr protocol arp'),
以及IEEE 802.11 無線局域網(其表達元形式可以是'wlan protocol arp')中, protocol
標識符來自802.2 邏輯鏈路控制層頭,
在FDDI, Token Ring 或802.1頭中會包含此邏輯鏈路控制層頭.
當以這些網絡上的相應的協議標識為過濾條件時, tcpdump只是檢查LLC頭部中以0x000000為組成單元標識符(OUI, 0x000000
標識一個內部以太網)的一段'SNAP格式結構'中的protocol ID 域, 而不會管包中是否有一段OUI為0x000000的'SNAP格式結構'(nt: SNAP, SubNetwork Access Protocol,子網接入協議). 以下例外:
iso tcpdump 會檢查LLC頭部中的DSAP域(Destination service Access Point, 目標服務接入點)和
SSAP域(源服務接入點).(nt: iso 協議未知, 需補充)
stp 以及netbeui
tcpdump 將會檢查LLC 頭部中的目標服務接入點(Destination service Access Point);
atalk
tcpdump 將會檢查LLC 頭部中以0x080007 為OUI標識的'SNAP格式結構', 并會檢查AppleTalk etype域.
(nt: AppleTalk etype 是否位于SNAP格式結構中, 未知, 需補充).
此外, 在以太網中, 對于ether proto protocol 選項, tcpdump 會為protocol 所指定的協議檢查以太網類型域(the Ethernet type field), 但以下這些協議除外:
iso, stp, and netbeui
tcpdump 將會檢查802.3 物理幀以及LLC 頭(這兩種檢查與FDDI, TR, 802.11網絡中的相應檢查一致);
(nt: 802.3, 理解為IEEE 802.3, 其為一系列IEEE 標準的集合. 此集合定義了有線以太網絡中的物理層以及數據鏈路層的媒體接入控制子層. stp 在上文已有描述)
atalk
tcpdump 將會檢查以太網物理幀中的AppleTalk etype 域, 同時也會檢查數據包中LLC頭部中的'SNAP格式結構'
(這兩種檢查與FDDI, TR, 802.11網絡中的相應檢查一致)
aarp tcpdump 將會檢查AppleTalk ARP etype 域, 此域或存在于以太網物理幀中, 或存在于LLC(由802.2 所定義)的
'SNAP格式結構'中, 當為后者時, 該'SNAP格式結構'的OUI標識為0x000000;
(nt: 802.2, 可理解為, IEEE802.2, 其中定義了邏輯鏈路控制層(LLC), 該層對應于OSI 網絡模型中數據鏈路層的上層部分.
LLC 層為使用數據鏈路層的用戶提供了一個統一的接口(通常用戶是網絡層). LLC層以下是媒體接入控制層(nt: MAC層,
對應于數據鏈路層的下層部分).該層的實現以及工作方式會根據不同物理傳輸媒介的不同而有所區別(比如, 以太網, 令牌環網,
光纖分布數據接口(nt: 實際可理解為一種光纖網絡), 無線局域網(802.11), 等等.)
ipx tcpdump 將會檢查物理以太幀中的IPX etype域, LLC頭中的IPX DSAP域，無LLC頭并對IPX進行了封裝的802.3幀,
以及LLC 頭部'SNAP格式結構'中的IPX etype 域(nt | rt: SNAP frame, 可理解為, LLC 頭中的'SNAP格式結構'.
該含義屬初步理解階段, 需補充).
decnet src host
如果數據包中DECNET源地址為host, 則與此對應的條件表達式為真.
(nt:decnet, 由Digital Equipment Corporation 開發, 最早用于PDP-11 機器互聯的網絡協議)
decnet dst host
如果數據包中DECNET目的地址為host, 則與此對應的條件表達式為真.
(nt: decnet 在上文已有說明)
decnet host host
如果數據包中DECNET目的地址或DECNET源地址為host, 則與此對應的條件表達式為真.
(nt: decnet 在上文已有說明)
ifname interface
如果數據包已被標記為從指定的網絡接口中接收的, 則與此對應的條件表達式為真.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
on interface
與ifname interface 含義一致.
rnr num
如果數據包已被標記為匹配PF的規則, 則與此對應的條件表達式為真.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
rulenum num
與rulenum num 含義一致.
reason code
如果數據包已被標記為包含PF的匹配結果代碼, 則與此對應的條件表達式為真.有效的結果代碼有: match, bad-offset,
fragment, short, normalize, 以及memory.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
rset name
如果數據包已被標記為匹配指定的規則集, 則與此對應的條件表達式為真.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
ruleset name
與rset name 含義一致.
srnr num
如果數據包已被標記為匹配指定的規則集中的特定規則(nt: specified PF rule number, 特定規則編號, 即特定規則),
則與此對應的條件表達式為真.(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為
OpenBSD中的防火墻程序))
subrulenum num
與srnr 含義一致.
action act
如果包被記錄時PF會執行act指定的動作, 則與此對應的條件表達式為真. 有效的動作有: pass, block.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
與以下表達元含義一致:
ether proto p
p是以上協議中的一個.
lat, moprc, mopdl
與以下表達元含義一致:
ether proto p
p是以上協議中的一個. 必須要注意的是tcpdump目前還不能分析這些協議.
vlan [vlan_id]
如果數據包為IEEE802.1Q VLAN 數據包, 則與此對應的條件表達式為真.
(nt: IEEE802.1Q VLAN, 即IEEE802.1Q 虛擬網絡協議, 此協議用于不同網絡的之間的互聯).
如果[vlan_id] 被指定, 則只有數據包含有指定的虛擬網絡id(vlan_id), 則與此對應的條件表達式為真.
要注意的是, 對于VLAN數據包, 在表達式中遇到的第一個vlan關鍵字會改變表達式中接下來關鍵字所對應數據包中數據的開始位置(即解碼偏移). 在VLAN網絡體系中過濾數據包時, vlan [vlan_id]表達式可以被多次使用. 關鍵字vlan每出現一次都會增加
4字節過濾偏移(nt: 過濾偏移, 可理解為上面的解碼偏移).
Zum Beispiel:
vlan 100 && vlan 200
表示: 過濾封裝在VLAN100中的VLAN200網絡上的數據包再例如:
vlan && vlan 300 && ip
表示: 過濾封裝在VLAN300 網絡中的IPv4數據包, 而VLAN300網絡又被更外層的VLAN封裝
mpls [label_num]
如果數據包為MPLS數據包, 則與此對應的條件表達式為真.
(nt: MPLS, Multi-Protocol Label Switch, 多協議標簽交換, 一種在開放的通信網上利用標簽引導數據傳輸的技術).
如果[label_num] 被指定, 則只有數據包含有指定的標簽id(label_num), 則與此對應的條件表達式為真.
要注意的是, 對于內含MPLS信息的IP數據包(即MPLS數據包), 在表達式中遇到的第一個MPLS關鍵字會改變表達式中接下來關鍵字所對應數據包中數據的開始位置(即解碼偏移). 在MPLS網絡體系中過濾數據包時, mpls [label_num]表達式可以被多次使用. 關鍵字mpls每出現一次都會增加
4字節過濾偏移(nt: 過濾偏移, 可理解為上面的解碼偏移).
Zum Beispiel:
mpls 100000 && mpls 1024
表示: 過濾外層標簽為100000 而層標簽為1024的數據包再如:
mpls && mpls 1024 && host 192.9.200.1
表示: 過濾發往或來自192.9.200.1的數據包, 該數據包的內層標簽為1024, 且擁有一個外層標簽.
pppoed
如果數據包為PPP-over-Ethernet的服務器探尋數據包(nt: Discovery packet,
其ethernet type 為0x8863),則與此對應的條件表達式為真.
(nt: PPP-over-Ethernet, 點對點以太網承載協議, 其點對點的連接建立分為Discovery階段(地址發現) 和
PPPoE 會話建立階段, discovery 數據包就是第一階段發出來的包. ethernet type
是以太幀里的一個字段，用來指明應用于幀數據字段的協議)
pppoes
如果數據包為PPP-over-Ethernet會話數據包(nt: ethernet type 為0x8864, PPP-over-Ethernet在上文已有說明, 可搜索關鍵字'PPP-over-Ethernet'找到其描述), 則與此對應的條件表達式為真.
要注意的是, 對于PPP-over-Ethernet會話數據包, 在表達式中遇到的第一個pppoes關鍵字會改變表達式中接下來關鍵字所對應數據包中數據的開始位置(即解碼偏移).
Zum Beispiel:
pppoes && ip
表示: 過濾嵌入在PPPoE數據包中的ipv4數據包
tcp, udp, icmp
與以下表達元含義一致:
ip proto p or ip6 proto p
其中p 是以上協議之一(含義分別為: 如果數據包為ipv4或ipv6數據包并且其協議類型為tcp,udp, 或icmp則與此對應的條件表達式為真)
iso proto protocol
如果數據包的協議類型為iso-osi協議棧中protocol協議, 則與此對應的條件表達式為真.(nt: [初解]iso-osi 網絡模型中每層的具體協議與tcp/ip相應層采用的協議不同. iso-osi各層中的具體協議另需補充)
protocol 可以是一個數字編號, 或以下名字中之一:
clnp, esis, or isis.
(nt: clnp, Connectionless Network Protocol, 這是OSI網絡模型中網絡層協議, esis, isis 未知, 需補充)
clnp, esis, isis
是以下表達的縮寫
iso proto p
其中p 是以上協議之一
l1, l2, iih, lsp, snp, csnp, psnp
為IS-IS PDU 類型的縮寫.
(nt: IS-IS PDU, Intermediate system to intermediate system Protocol Data Unit, 中間系統到中間系統的協議數據單元. OSI(Open Systems Interconnection)網絡由終端系統, 中間系統構成.
終端系統指路由器, 而終端系統指用戶設備. 路由器形成的本地組稱之為'區域'（Area）和多個區域組成一個'域'（Domain）.
IS-IS 提供域內或區域內的路由. l1, l2, iih, lsp, snp, csnp, psnp 表示PDU的類型, 具體含義另需補充)
vpi n
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備,
如果數據包為ATM數據包, 并且其虛擬路徑標識為n, 則與此對應的條件表達式為真.
(nt: ATM, Asychronous Transfer Mode, 實際上可理解為由ITU-T(國際電信聯盟電信標準化部門)提出的一個與
TCP/IP中IP層功能等同的一系列協議, 具體協議層次另需補充)
vci n
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備,
如果數據包為ATM數據包, 并且其虛擬通道標識為n, 則與此對應的條件表達式為真.
(nt: ATM, 在上文已有描述)
Fahrbahn
如果數據包為ATM LANE 數據包, 則與此對應的條件表達式為真. 要注意的是, 如果是模擬以太網的LANE數據包或者
LANE邏輯單元控制包, 表達式中第一個lane關鍵字會改變表達式中隨后條件的測試. 如果沒有指定lane關鍵字, 條件測試將按照數據包中內含LLC(邏輯鏈路層)的ATM包來進行.
llc
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備,
如果數據包為ATM數據包, 并且內含LLC則與此對應的條件表達式為真
oamf4s
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是Segment OAM F4 信元(VPI=0 并且VCI=3), 則與此對應的條件表達式為真.
(nt: OAM, Operation Administration and Maintenance, 操作管理和維護,可理解為:ATM網絡中用于網絡管理所產生的ATM信元的分類方式.
ATM網絡中傳輸單位為信元, 要傳輸的數據終究會被分割成固定長度(53字節)的信元,
(初理解: 一條物理線路可被復用, 形成虛擬路徑(virtual path). 而一條虛擬路徑再次被復用, 形成虛擬信道(virtual channel)).
通信雙方的編址方式為:虛擬路徑編號(VPI)/虛擬信道編號(VCI)).
OAM F4 flow 信元又可分為segment 類和end-to-end 類, 其區別未知, 需補充.)
oamf4e
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是end-to-end OAM F4 信元(VPI=0 并且VCI=4), 則與此對應的條件表達式為真.
(nt: OAM 與end-to-end OAM F4 在上文已有描述, 可搜索'oamf4s'來定位)
oamf4
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是end-to-end 或segment OAM F4 信元(VPI=0 并且VCI=3 或者VCI=4), 則與此對應的條件表達式為真.
(nt: OAM 與end-to-end OAM F4 在上文已有描述, 可搜索'oamf4s'來定位)
oam
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是end-to-end 或segment OAM F4 信元(VPI=0 并且VCI=3 或者VCI=4), 則與此對應的條件表達式為真.
(nt: 此選項與oamf4重復, 需確認)
metac
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'元信令線路'(nt: VPI=0 并且VCI=1, '元信令線路', meta signaling circuit, 具體含義未知, 需補充),
則與此對應的條件表達式為真.
bcc
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'廣播信令線路'(nt: VPI=0 并且VCI=2, '廣播信令線路', broadcast signaling circuit, 具體含義未知, 需補充),
則與此對應的條件表達式為真.
sc
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'信令線路'(nt: VPI=0 并且VCI=5, '信令線路', signaling circuit, 具體含義未知, 需補充),
則與此對應的條件表達式為真.
ilmic
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'ILMI線路'(nt: VPI=0 并且VCI=16, 'ILMI', Interim Local Management Interface , 可理解為基于SNMP(簡易網絡管理協議)的用于網絡管理的接口)則與此對應的條件表達式為真.
connectmsg
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'信令線路'并且是Q.2931協議中規定的以下幾種消息: Setup, Calling Proceeding, Connect,
Connect Ack, Release, 或者Release Done. 則與此對應的條件表達式為真.
(nt: Q.2931 為ITU(國際電信聯盟)制定的信令協議. 其中規定了在寬帶綜合業務數字網絡的用戶接口層建立, 維護, 取消網絡連接的相關步驟.) metaconnect
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'元信令線路'并且是Q.2931協議中規定的以下幾種消息: Setup, Calling Proceeding, Connect,
Connect Ack, Release, 或者Release Done. 則與此對應的條件表達式為真. expr relop expr
如果relop 兩側的操作數(expr)滿足relop 指定的關系, 則與此對應的條件表達式為真.
relop 可以是以下關系操作符之一: >, <, <=, =, !=.
expr 是一個算術表達式. 此表達式中可使用整型常量(表示方式與標準C中一致), 二進制操作符(+, -, *, /, &, |,
<<, >>), 長度操作符, 以及對特定數據包中數據的引用操作符. 要注意的是, 所有的比較操作都默認操作數是無符號的,
例如, 0x80000000 和0xffffffff 都是大于0的(nt: 對于有符號的比較, 按照補碼規則, 0xffffffff
會小于0). 如果要引用數據包中的數據, 可采用以下表達方式:
proto [expr : size]
proto 的取值可以是以下取值之一:ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp,
tcp, udp, icmp, ip6 或者radio. 這指明了該引用操作所對應的協議層.(ether, fddi, wlan,
tr, ppp, slip and link 對應于數據鏈路層, radio 對應于802.11(wlan,無線局域網)某些數據包中的附帶的
"radio"頭(nt: 其中描述了波特率, 數據加密等信息)).
要注意的是, tcp, udp 等上層協議目前只能應用于網絡層采用為IPv4或IPv6協議的網絡(此限制會在tcpdump未來版本中進行修改). 對于指定協議的所需數據, 其在包數據中的偏移字節由expr 來指定.
以上表達中size 是可選的, 用來指明我們關注那部分數據段的長度(nt:通常這段數據是數據包的一個域)， 其長度可以是1, 2, 或4個字節. 如果不給定size, 默認是1個字節. 長度操作符的關鍵字為len,
這代碼整個數據包的長度.
例如, 'ether[0] & 1 != 0' 將會使tcpdump 抓取所有多點廣播數據包.(nt: ether[0]字節的最低位為1表示數據包目的地址是多點廣播地址). 'ip[0] & 0xf != 5' 對應抓取所有帶有選項的
IPv4數據包. 'ip[6:2] & 0x1fff = 0'對應抓取沒被破碎的IPv4數據包或者其片段編號為0的已破碎的IPv4數據包. 這種數據檢查方式也適用于tcp和udp數據的引用,
即, tcp[0]對應于TCP 頭中第一個字節, 而不是對應任何一個中間的字節.
一些偏移以及域的取值除了可以用數字也可用名字來表達. 以下為可用的一些域(協議頭中的域)的名字: icmptype (指ICMP 協議頭中type域), icmpcode (指ICMP 協議頭code 域), 以及tcpflags(指TCP協議頭的flags 域)
以下為ICMP 協議頭中type 域的可用取值:
icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert,
icmp-routersolicit, icmp-timx-ceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply,
icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply.
以下為TCP 協議頭中flags 域的可用取值:tcp-fin, tcp-syn, tcp-rst, tcp-push,
tcp-ack, tcp-urg. 到此這篇關于Linux下tcpdump命令解析及使用詳解的文章就介紹到這了,更多相關Linux tcpdump命令內容請搜索123WORDPRESS.COM以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持123WORDPRESS.COM！ Das könnte Sie auch interessieren:- Linux通過sar命令查看網卡流量
- 詳談linux中sar的使用方法
- Detaillierte Erklärung der Linux-Befehle sort, uniq, tr tools
- Detaillierte Erklärung zur Verwendung der Stat-Funktion und des Stat-Befehls in Linux
- Linux-Befehl „cut“ erklärt
- Linux常用命令之grep命令用法詳解
- Linux 常用命令操作大全(推薦收藏)
- Verwendung des Linux-Befehls „sar“ und Analyse von Codebeispielen
| 
