Tcpdump - Comando de Linux - Comando Unix

NOM

tcpdump: aboca el trànsit a la xarxa

SINOPSI

tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]

[ -C mida de fitxer ] [ -F fitxer ]

[ -i interfície ] [ -m mòdul ] [ -r fitxer ]

[ -s snaplen ] [ -T tipus ] [ -U usuari ] [ -w fitxer ]

[ -E alguna cosa: secret ] [ expressió ]

DESCRIPCIÓ

Tcpdump imprimeix les capçaleres de paquets en una interfície de xarxa que coincideix amb l' expressió booleana. També es pot executar amb l'indicador -w , que li permet guardar les dades del paquet en un fitxer per a una anàlisi posterior i / o amb l'indicador -r , que fa que es llegeixi des d'un fitxer de paquets guardat en comptes de llegir paquets des d'una interfície de xarxa. En tots els casos, tcpdump processarà només paquets que coincideixin amb l' expressió .

Tcpdump , si no s'executa amb l'indicador -c , continuarà capturant els paquets fins que s'interrompi amb un senyal SIGINT (generat, per exemple, escrivint el vostre caràcter d'interrupció, generalment el control-C) o un senyal SIGTERM (generalment generat amb la matança (1) ordre); si s'executa amb l'indicador -c , es capturaran els paquets fins que s'interrompi un senyal SIGINT o SIGTERM o s'hagi processat el nombre especificat de paquets.

Quan tcpdump finalitzi la captura de paquets, reportarà un recompte de:

paquets `` rebuts per filtre '' (el significat d'això depèn del sistema operatiu on està executant tcpdump , i possiblement en la forma en què es va configurar el sistema operatiu), si es va especificar un filtre a la línia d'ordres, en alguns SO es compta els paquets, independentment de si van coincidir amb l'expressió de filtre, i en altres SO, només compta amb paquets que coincidien amb l'expressió de filtre i que van ser processats per tcpdump );

paquets `` eliminats per kernel '' (aquest és el nombre de paquets que es van deixar caure, degut a la manca d'espai de memòria intermèdia, pel mecanisme de captura de paquets del sistema operatiu en el que s'executa el tcpdump , si el SO informa aquesta informació a les aplicacions; si no, es comunicarà com a 0).

A les plataformes que admeten el senyal de SIGINFO, com la majoria de BSD, informarà aquests comptes quan rep un senyal de SIGINFO (generat, per exemple, escrivint el vostre caràcter `` status '', generalment controla -T) i continuarà capturant paquets .

Els paquets de lectura d'una interfície de xarxa poden requerir que tingueu privilegis especials:

Sota SunOS 3.x o 4.x amb NIT o BPF:

Heu de tenir accés de lectura a / dev / nit o / dev / bpf * .

Sota Solaris amb DLPI:

Heu de tenir accés de lectura / escriptura al pseudo dispositiu de la xarxa, per exemple / dev / le . Tanmateix, almenys en algunes versions de Solaris, això no és suficient per permetre que tcpdump capture de manera promiscuada; en aquestes versions de Solaris, heu de ser root o tcpdump s'ha d'instal·lar setuid a root, per tal de capturar de manera promiscu. Tingueu en compte que, en moltes (potser totes) interfícies, si no captures de manera promiscua, no veurà paquets sortints, de manera que una captura no realitzada de manera promiscuada pot ser que no sigui molt útil.

A HP-UX amb DLPI:

Heu de ser root o tcpdump s'ha d'instal·lar setuid a root.

Sota IRIX amb snoop:

Heu de ser root o tcpdump s'ha d'instal·lar setuid a root.

Sota Linux:

Heu de ser root o tcpdump s'ha d'instal·lar setuid a root.

Sota Ultrix i Digital UNIX / Tru64 UNIX:

Qualsevol usuari pot capturar trànsit de xarxa amb tcpdump . Tanmateix, cap usuari (ni tan sols el superusuari) pot capturar de manera promiscuada en una interfície, tret que el superusuari hagi habilitat l'operació en mode promiscuo en aquesta interfície utilitzant pfconfig (8), i cap usuari (ni tan sols el superusuari ) pot capturar el trànsit unicast rebut o enviat per la màquina en una interfície, tret que el súper usuari hagi habilitat l'operació de còpia en mode en aquesta interfície utilitzant pfconfig , de manera que la captura de paquets útil en una interfície probablement requereix que sigui mode promiscu o còpia -aquesta manera, o ambdós modes de funcionament, s'habilitarà en aquesta interfície.

Sota BSD:

Heu de tenir accés de lectura a / dev / bpf * .

Llegir un fitxer de paquets guardats no requereix privilegis especials.

OPCIONS

-a

Intenta convertir les adreces de xarxa i de difusió als noms.

-c

Sortiu després de rebre paquets de recompte .

-C

Abans d'escriure un paquet cru a un fitxer d'emmagatzematge, comproveu si el fitxer és actualment més gran que el fitxer_imatge i, en aquest cas, tanqueu el fitxer d' emmagatzematge actual i obriu-ne un de nou. Els fitxers guardats després del primer fitxer d'emmagatzematge tindran el nom especificat amb l'indicador -w , amb un número després d'això, començant per 2 i continuant cap amunt. Les unitats de file_size són milions de bytes (1.000.000 de bytes, no 1.048.576 bytes).

-d

Envieu el codi de compilació de paquets compilat en una forma llegible per humans a la sortida estàndard i atureu-lo.

-dd

Esborreu el codi de paquet com a fragment de programa C.

-ddd

Desplaça el codi de paquetatge com a números decimals (precedit d'un recompte).

-e

Imprimiu el encapçalament de nivell d'enllaç a cada línia de bolcat.

-E

Utilitza alguna cosa: secret per desxifrar paquets IPsec ESP. Algorismes poden ser des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc o cap . El valor predeterminat és des-cbc . La capacitat de desxifrar paquets només està present si tcpdump s'ha compilat amb la criptografia activada. segrega el text ascii per a la clau secreta d'ESP. No podem acceptar un valor binari arbitrari en aquest moment. L'opció assumeix RFC2406 ESP, no RFC1827 ESP. L'opció només és per a propòsits de depuració, i l'ús d'aquesta opció amb una clau veritablement 'secreta' es desanima. En presentar la clau secreta d'IPsec a la línia d'ordres, es fa visible per a d'altres, a través de ps (1) i en altres ocasions.

-f

Imprimiu les adreces d'Internet 'estrangeres' en forma numèrica més que no simbòlicament (aquesta opció està pensada per evitar un dany cerebral greu en el servidor del servidor de Sun: normalment es bloqueja per sempre traduint números d'Internet no locals).

-F

Utilitzeu el fitxer com a entrada per a l'expressió del filtre. S'ignora una expressió addicional a la línia d'ordres.

-i

Escolta a la interfície . Si no s'especifica, tcpdump cerca la llista d'interfície del sistema per a la interfície més baixa, configurada i configurada (excloent loopback). Els enllaços es trenquen triant la coincidència més primerenca.

En sistemes Linux amb kernels 2.2 o posterior, es pot utilitzar un argument d' interfície de `` qualsevol '' per capturar paquets de totes les interfícies. Tingueu en compte que les captures del `` qualsevol '' dispositiu no es faran de manera promiscu.

-l

Configureu la línia de stdout en búfer. Útil si voleu veure les dades mentre la captura. Per exemple,
`` tcpdump -l | tee dat '' o `` tcpdump -l> dat & tail -f dat ''.

-m

Carregueu definicions del mòdul SMI MIB des del mòdul d' arxius. Aquesta opció es pot utilitzar diverses vegades per carregar diversos mòduls MIB en tcpdump .

-n

No convertiu les adreces d'amfitrió als noms. Això es pot utilitzar per evitar cerques DNS.

-nn

No converteu tampoc els noms de protocol, port, etc.

-N

No imprimiu la qualificació del nom de domini dels noms d'amfitrió. Per exemple, si dóna aquesta bandera, tcpdump imprimirà `` nic '' en lloc de `` nic.ddn.mil ''.

-O

No executeu l'optimitzador de codi coincident amb paquets. Això només és útil si sospiteu d'un error en l'optimitzador.

-p

No col·loqueu la interfície en mode promiscu. Tingueu en compte que la interfície pot ser de manera promiscuada per algun altre motiu; per tant, `-p 'no es pot utilitzar com a abreviació de` ether host {local-hw-addr} o emissió d'èter'.

-q

Sortida ràpida (silenciosa?). Imprimiu menys informació del protocol perquè les línies de sortida siguin més curtes.

-R

Assumiu que els paquets ESP / AH es basen en especificacions anteriors (RFC1825 a RFC1829). Si s'especifica, tcpdump no imprimirà camp de prevenció de reproducció. Com que no hi ha cap camp de versió de protocol a l'especificació ESP / AH, tcpdump no pot deduir la versió del protocol ESP / AH.

-r

Llegir els paquets del fitxer (que es va crear amb l'opció -w). S'utilitza l'entrada estàndard si el fitxer és `` - ''.

-S

Impressió de nombres absoluts, més que relatius, de seqüència de TCP.

-s

Snarf snaplen bytes de dades de cada paquet en lloc de la predeterminada de 68 (amb NIT de SunOS, el mínim és de fet 96). 68 bytes és adequat per a IP, ICMP, TCP i UDP, però pot truncar la informació del protocol del servidor de noms i els paquets NFS (vegeu a continuació). Els paquets truncats a causa d'una instantània limitada estan indicats a la sortida amb `` [| proto ] '', on proto és el nom del nivell de protocol en què s'ha produït el truncament. Tingueu en compte que prendre instantànies més grans augmenta la quantitat de temps que triga a processar paquets i, de manera efectiva, disminueix la quantitat de buffer de paquets. Això pot fer que es perdin els paquets. Heu de limitar el snaplen al número més petit que capturi la informació del protocol que us interessa. Configurar snaplen a 0 significa utilitzar la longitud necessària per capturar paquets complets.

-T

Forçar els paquets seleccionats per " expressió " per interpretar el tipus especificat. Els tipus coneguts actualment són cnfp (protocol de Cisco NetFlow), rpc (Remote Procedure Call), rtp (protocol d'aplicacions en temps real), rtcp (protocol de control d'aplicacions en temps real), snmp (Protocol d'administració de xarxes simples), dipòsit (Visual Audio Tool ) i wb (White Board distribuït).

-t

No imprimiu una marca de temps a cada línia d'abocament.

-tut

Imprimiu una marca de temps no formateada a cada línia d'abocament.

-U

Retorna els privilegis de root i canvia l'identificador d' usuari a l' usuari i l'identificador de grup al grup principal d' usuaris .

Nota! Red Hat Linux deixa caure automàticament els privilegis de l'usuari `` pcap '' si no s'especifica res més.

-ttt

Imprimiu un delta (en microsegons) entre la línia actual i la anterior a cada línia d'abocament.

-tttt

Imprimiu una marca de temps en el format per defecte seguida per data en cada línia d'abocament.

-u

Impressió d'identificadors sense nifes NFS.

-v

(Lleugerament més) de sortida detallada. Per exemple, el temps de vida, la identificació, la longitud total i les opcions d'un paquet IP estan impreses. També permet comprovacions addicionals de la integritat del paquet, com verificar la suma de verificació de capçalera IP i ICMP.

-vv

Fins i tot més resultats verbosos. Per exemple, els camps addicionals s'imprimeixen a partir de paquets de resposta NFS, i els paquets SMB estan totalment descodificats.

-vvv

Fins i tot més resultats verbosos. Per exemple, les opcions de telnet SB ... SE estan impreses íntegrament. Amb les opcions de X Telnet també s'imprimeixen en hexadecimal.

-w

Escriviu els paquets bruts per a fitxar en comptes d'analitzar-los i imprimir-los. Posteriorment es podran imprimir amb l'opció -r. S'utilitza la sortida estàndard si el fitxer és `` - ''.

-x

Imprimiu cada paquet (menys el seu encapçalament de nivell d'enllaç) a hexadecimal. Es mostrarà el més petit de tot el paquet o els bytes snaplen . Tingueu en compte que aquest és el paquet complet de la capa d'enllaç, de manera que per a les capes d'enllaç que el coixinet (per exemple, Ethernet), els bytes de farciment també s'imprimiran quan el paquet de capa superior sigui més curt que el farcit requerit.

-X

Quan imprimiu hexadecimal, imprimiu ascii també. D'aquesta manera, si -x també està establert, el paquet està imprès en hexadecimal / ascii. Això és molt útil per analitzar nous protocols. Encara que -x no estigui també configurat, algunes parts d'alguns paquets es poden imprimir en hex / ascii.

expressió

selecciona quins paquets es rebutjaran. Si no s'indica cap expressió , tots els paquets de la xarxa seran objecte de dumping. En cas contrari, només s'emetran paquets per als quals l' expressió "veritable" sigui.

L' expressió consisteix en una o més primitives. Els primitius normalment consisteixen en un identificador (nom o número) precedit per un o més classificadors. Hi ha tres tipus diferents de classificadors:

escriu

Els classificadors diuen quin tipus de cosa es refereix al nom de l'id o al número. Els tipus possibles són host , net i port . Per exemple, `host foo ',` net 128.3', `port 20 '. Si no hi ha qualificador de tipus, s'assumeix l' amfitrió .

dir

Els classificadors especifiquen una adreça de transferència particular a i / o de l' id . Les adreces possibles són src , dst , src o dst i src i dst . Per exemple, `src foo ',` dst net 128.3', `src o dst port ftp-data '. Si no hi ha qualificador dir, s'assumeix src o dst . Per a les capes d'enllaç "nuls" (és a dir, protocols de punt a punt com el lliscament) es poden utilitzar els qualificadors d' entrada i sortida per especificar la direcció desitjada.

proto

Els classificadors restringeixen la coincidència a un protocol concret. Els possibles protos són: ether , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp i udp . Per exemple, `ether src foo ',` arp net 128.3', `tcp port 21 '. Si no hi ha proto qualifier, s'assumeixen tots els protocols coherents amb el tipus. Per exemple, `src foo 'significa` (ip o arp o rarp) src foo' (excepte aquest últim no és una sintaxi legal), `barra neta 'significa` (ip o arp o rarp) barra neta' i 'port 53' significa "port (tcp o udp) 53 '.

[`fddi 'és en realitat un àlies per` èter'; l'analitzador els tracta de forma idèntica com el `` el nivell de l'enllaç de dades que s'utilitza a la interfície de xarxa especificada. '' Les capçaleres FDDI contenen adreces de font i destinació com Ethernet, i sovint contenen tipus de paquets tipus Ethernet, de manera que es pot filtrar en aquests camps FDDI igual que amb els camps Ethernet anàlegs. Les capçaleres FDDI també contenen altres camps, però no es poden nomenar explícitament en una expressió de filtre.

De la mateixa manera, `tr 'és un àlies per` èter'; les instruccions del paràgraf anterior sobre capçaleres FDDI també s'apliquen als encapçalaments de Token Ring.]

A més de l'anterior, hi ha algunes paraules clau especials `primitives 'que no segueixen el patró: passarel·la , emissió , menys , major i expressions aritmètiques. Tot això es descriu a continuació.

Les expressions de filtre més complexes es construeixen utilitzant les paraules i , o i no per combinar primitives. Per exemple, `host foo i no port ftp i no port ftp-data '. Per desar l'escriptura, es poden ometre llistes de qualificacions idèntiques. Per exemple, `tcp dst port ftp o ftp-data o domain 'és exactament el mateix que` tcp dst port ftp o tcp dst port ftp-data o tcp dst port domain'.

Les primitives permeses són:

host dst host

És veritat si el camp de destinació IPv4 / v6 del paquet és l' amfitrió , que pot ser una adreça o un nom.

host host de src

És cert si el camp d'origen IPv4 / v6 del paquet és amfitrió .

host host

És veritat si l'origen o la destinació del paquet IPv4 / v6 és host . Qualsevol de les expressions de l'amfitrió anteriors es pot predisponer amb les paraules clau, ip , arp , rarp o ip6 com a:

ip host host

que és equivalent a:

ether proto \ ip i host host

Si l' amfitrió és un nom amb diverses adreces IP, es verificarà cada adreça per a una coincidència.

ether dst ehost

És cert si l'adreça de destinació d'ethernet és ehost . Ehost pot ser un nom de / etc / ethers o un número (vegeu ethers (3N) per al format numèric).

ether src ehost

És cert si l'adreça d'origen ethernet és ehost .

ether host ehost

És veritat si l'adreça ethernet o la destinació són ehost .

amfitrió de passarel·la

És cert si el paquet utilitza host com a porta d'entrada. És a dir, l'adreça ethernet o la destinació era host, però ni la font IP ni la destinació IP eren host . L'amfitrió ha de ser un nom i ha de trobar-se tant pels mecanismes de resolució de l'adreça host-name-to-IP (nom del servidor, DNS, NIS, etc.) com per la resolució de l'adreça del host-name-to-Ethernet mecanisme (/ etc / éteres, etc.). (Una expressió equivalent és

ether host ehost i no host host

que es pot utilitzar amb noms o números per host / ehost ). Aquesta sintaxi no funciona en la configuració habilitada per IPv6 en aquest moment.

dst net net

És cert si l'adreça de destinació IPv4 / v6 del paquet té un número de xarxa de xarxa . La xarxa pot ser un nom de / etc / networks o un número de xarxa (veure xarxes (4) per obtenir més informació).

src net net

És cert si l'adreça d'origen IPv4 / v6 del paquet té un número de xarxa de xarxa .

xarxa neta

És cert si l'adreça d'origen o destinació IPv4 / v6 del paquet té un número de xarxa de xarxa .

net mask màscara de xarxa

És cert si l'adreça IP coincideix amb la màscara de xarxa específica. Pot ser qualificat amb src o dst . Tingueu en compte que aquesta sintaxi no és vàlida per a la xarxa IPv6.

xarxa net / len

És cert si l'adreça IPv4 / v6 coincideix amb la xarxa amb una xarxa de màscares de memòria ampla. Pot ser qualificat amb src o dst .

port port dst

Cert si el paquet és ip / tcp, ip / udp, ip6 / tcp o ip6 / udp i té un valor de port de destinació del port . El port pot ser un número o un nom usat a / etc / services (vegeu tcp (4P) i udp (4P)). Si s'utilitza un nom, es verifica tant el número de port com el protocol. Si s'utilitza un nombre o nom ambigu, només es verifica el número de port (p. Ex., El port dst 513 imprimirà tant el trcp / login com el udp / quin trànsit i el domini del port imprimiran tant trcp / domini com udp / domini del trànsit).

port de port src

Cert si el paquet té un valor de port de origen del port .

port del port

És veritat si el port origen o destinació del paquet és el port . Qualsevol de les expressions de port anteriors es pot prepender amb les paraules clau, tcp o udp , com a:

port de port src TCP

que només coincideix amb els paquets tcp el port d'origen és el port .

menys durada

Cert si el paquet té una longitud inferior o igual a la longitud . Això equival a:

len <= longitud .

major durada

És veritat si el paquet té una longitud superior o igual a la longitud . Això equival a:

len> = longitud .

protocol proto ip

És veritat si el paquet és un paquet d'IP (vegeu ip (4P)) del protocol de tipus de protocol . El protocol pot ser un número o un dels noms icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp o tcp . Tingueu en compte que els identificadors tcp , udp i icmp també són paraules clau i s'han d'escapar mitjançant una barra invertida (\), que és \\ al shell C. Tingueu en compte que aquesta primitiva no persegueix la cadena de capçalera del protocol.

protocol proto ip6

És veritat si el paquet és un paquet IPv6 del protocol de tipus de protocol . Tingueu en compte que aquesta primitiva no persegueix la cadena de capçalera del protocol.

protocol protocolo ip6

És veritat si el paquet és paquet IPv6 i conté encapçalament de protocol amb protocol de tipus en la cadena de capçalera del protocol. Per exemple,

ip6 protochain 6

coincideix amb qualsevol paquet d'IPv6 amb encapçalament de protocol TCP en la cadena de capçalera del protocol. El paquet pot contenir, per exemple, l'encapçalament d'autenticació, el encapçalament d'encaminament o l'encapçalament d'opció hop-by-hop, entre encapçalament IPv6 i encapçalament TCP. El codi BPF emès per aquesta primitiva és complex i no pot ser optimitzat pel codi d'optimitzador de BPF a tcpdump , de manera que això pot ser una mica lent.

protocol protocolo IP

Equivalent al protocol IP6 protocols , però això és per a IPv4.

transmissió d'èter

És veritat si el paquet és un paquet d'emissió d'ethernet. La paraula clau ether és opcional.

ip broadcast

Cert si el paquet és un paquet d'emissió IP. Comprova tant les convencions de transmissió de tots els zeros com tots, i mira la màscara de subxarxa local.

ether multicast

Cert si el paquet és un paquet multicast ethernet. La paraula clau ether és opcional. Aquesta és la abreviatura de ` ether [0] i 1! = 0 '.

ip multicast

Cert si el paquet és un paquet multicast d'IP.

ip6 multicast

Cert si el paquet és un paquet de multidifusió IPv6.

protocol d' èter protector

Cert si el paquet és de protocol tipus ether. El protocol pot ser un número o un dels noms ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx o netbeui . Tingueu en compte que aquests identificadors també són paraules clau i s'han d'escapar mitjançant una barra invertida (\).

[En el cas de FDDI (per exemple, ` fddi protocol arp ') i Token Ring (per exemple,` tr protocol arp '), per a la majoria d'aquests protocols, la identificació del protocol prové del encapçalament 802.2 Logical Link Control (LLC), que Normalment es troba en capes a la part superior de l'encapçalament FDDI o Token Ring.

Quan es filtra per a la majoria d'identificadors de protocol en FDDI o Token Ring, tcpdump només comprova el camp ID d'un encapçalament LLC en un format anomenat SNAP amb un identificador d'unitat organitzativa (OUI) de 0x000000, per Ethernet encapsulat; no comprova si el paquet està en format SNAP amb un OUI de 0x000000.

Les excepcions són iso , per a això es comprova el camp DSAP (punt d'accés de servei de destinació) i SSAP (punt d'accés del servei d'origen) del encapçalament LLC, stp i netbeui , on verifica el capítol DSAP del LLC i atalk , on comprova si hi ha un paquet de format SNAP amb un OUI de 0x080007 i l'etype de Appletalk.

En el cas d'Ethernet, tcpdump comprova el camp del tipus Ethernet per a la majoria d'aquests protocols; les excepcions són iso , sap i netbeui , per les quals es verifica un marc 802.3 i, a continuació, comprova el encapçalament LLC com ho fa per FDDI i Token Ring, atalk , on comprova tant l'etype Appletalk en un marc Ethernet com un Paquet de format SNAP com ho fa per FDDI i Token Ring, aarp , on comprova el tipus etyp ARP d'Appletalk en un marc Ethernet o en un marc SNAP 802.2 amb un OUI de 0x000000 i ipx , on comprova el tipus IPX en un marc Ethernet, el IPAP DSAP al encapçalament LLC, el 802.3 sense cap encapsulament de capçalera LLC de IPX, i el tipus IPX en un marc SNAP.]

host de decnet src

És veritat si l'adreça d'origen de DECNET és l' amfitrió , que pot ser una adreça del formulari `` 10.123 '', o un nom de host DECNET. [El suport del nom del servidor DECNET només està disponible en sistemes Ultrix que estan configurats per executar DECNET.]

decnet dst host

És veritat si l'adreça de destinació DECNET és amfitrió .

host host de decnet

És veritat si l'adreça origen o la destinació de DECNET és l' amfitrió .

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

Abreujades per a:

èter proto p

on p és un dels protocols anteriors.

lat , moprc , mopdl

Abreujades per a:

èter proto p

on p és un dels protocols anteriors. Tingueu en compte que actualment tcpdump no sap com analitzar aquests protocols.

vlan [vlan_id]

Cert si el paquet és un paquet VLAN IEEE 802.1Q. Si s'especifica [vlan_id] , només el veritable és el paquet que té el vlan_id especificat. Tingueu en compte que la primera paraula clau vlan que es troba en l' expressió canvia els descomptes de descodificació de la resta de l' expressió si suposem que el paquet és un paquet VLAN.

tcp , udp , icmp

Abreujades per a:

ip proto p o ip6 proto p

on p és un dels protocols anteriors.

protocolo proto iso

Cert si el paquet és un paquet OSI del protocol de tipus de protocol . El protocol pot ser un nombre o un dels noms clnp , esis o isis .

clnp , esis , isis

Abreujades per a:

iso proto p

on p és un dels protocols anteriors. Tingueu en compte que tcpdump fa un treball incomplet d'anàlisi d'aquests protocols.

expr relop expr

És cert si la relació es manté, on relop és una de>, <,> =, <=, =! =, I expr és una expressió aritmètica composta de constants enters (expressada en la sintaxi C estàndard), els operadors binaris normals [+ , -, *, /, &, |], un operador de longitud i accessoris especials de dades de paquets. Per accedir a les dades dins del paquet, utilitzeu la sintaxi següent:

proto [ expr : size ]

Proto és un d' èter, fddi, tr, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp o ip6 , i indica la capa de protocol per a l'operació d'índex. ( ether, fddi, tr, ppp, slip and link) fan referència a la capa d'enllaç.) Tingueu en compte que tcp, udp i altres tipus de protocol de la capa superior només s'apliquen a IPv4, no a IPv6 (això es solucionarà en el futur). El desplaçament de bytes, relatiu a la capa de protocol indicat, ve donat per expr . La mida és opcional i indica el nombre de bytes en el camp d'interès; Pot ser un, dos o quatre, i es fa per defecte. L'operador de longitud, indicat per la paraula clau len , dóna la longitud del paquet.

Per exemple, ` ether [0] i 1! = 0 'capturen tot el trànsit multidifusió. L'expressió ' ip [0] i 0xf! = 5 ' captura tots els paquets IP amb opcions. L'expressió ' ip [6: 2] & 0x1fff = 0 ' només captura datagrames no frag fragments i frag zero de datagrames fragmentats. Aquest xec s'aplica implícitament a les operacions d'índex TCP i UDP . Per exemple, tcp [0] sempre significa el primer byte del encapçalament TCP, i mai no significa el primer byte d'un fragment intervingut.

Alguns desplaçaments i valors de camp poden expressar-se com a noms en comptes de com a valors numèrics. Hi ha disponibles els desplaçaments de camp de capçaleres de protocol següents: icmptype (camp de tipus ICMP), icmpcode (camp de codi ICMP) i tcpflags (camp de fitxes TCP).

Els següents valors de camp tipus ICMP estan disponibles: icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp-redirect , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp -sempre , icmp-ireq , icmp-ireqreply , icmp-maskreq , icmp-maskreply .

Els següents valors de camp de banderes TCP estan disponibles: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .

Els primitius es poden combinar usant:

Un grup entre primitives i operadors entre parèntesis (entre parèntesis són especials per al Shell i han de ser escapats).

Negació (` ! 'O` no ').

Concatenació (` && 'o` and ').

Alternança (` || 'o` o ').

La negació té una prioritat més alta. L'alternança i la concatenació tenen la mateixa prioritat i associen d'esquerra a dreta. Tingueu en compte que els testimonis explícits i de tokens, no juxtaposició, ara són necessaris per a la concatenació.

Si s'ofereix un identificador sense una paraula clau, s'assumeix la paraula clau més recent. Per exemple,

no host versus ace

és curta per a

no host vs i host ace

que no s'ha de confondre amb

no (host vs o as)

Els arguments d'expressió es poden passar a tcpdump com un únic argument o com a múltiples arguments, el que sigui més convenient. En general, si l'expressió conté caràcters metacarel·lar Shell, és més fàcil passar-ho com un argument únic citat. Diversos arguments es concatenen amb espais abans d'analitzar-los.

EXEMPLES

Per imprimir tots els paquets que arriben o surten de la posta de sol :

presentació de l'amfitrió de tcpdump

Imprimir el trànsit entre heli i calent o as :

helios de host tcpdump i \ (hot o as \)

Per imprimir tots els paquets IP entre as i qualsevol host, excepte els heli :

tcpdump ip host ace i no helios

Per imprimir tot el trànsit entre hosts i hosts locals a Berkeley:

tcpdump net ucb-ether

Per imprimir tot el trànsit de ftp a través de la passarel · la d' accés a Internet: (tingueu en compte que s'expressa l'expressió per evitar que l'intèrpret d'ordres (incorreu) interpreti els parèntesis):

tcpdump 'gateway snup i (port ftp o ftp-data)'

Per imprimir el trànsit no procedent ni destinat als hosts locals (si trobeu una porta d'entrada a una altra xarxa, aquest no hauria de fer-lo mai a la vostra xarxa local).

tcpdump ip i no xarxa local local

Per imprimir els paquets d'inici i final (els paquets SYN i FIN) de cada conversió TCP que implica un amfitrió no local.

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

Per imprimir paquets d'IP de més de 576 bytes enviats a través de la captura de passarel:

tcpdump 'gateway snup i ip [2: 2]> 576'

Per imprimir paquets d'emissió IP o multidifusió que no s'han enviat a través d'emissora d'ethernet o multidifusió:

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

Per imprimir tots els paquets ICMP que no són peticions / respostes de ressò (és a dir, no paquets de paquets):

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

FORMAT DE SORTIDA

La sortida de tcpdump depèn del protocol. A continuació es proporciona una breu descripció i exemples de la majoria dels formats.

Encapçalaments de nivell d'enllaç

Si s'ofereix l'opció '-e', s'imprimeix l'encapçalament del nivell de l'enllaç. A ethernets s'imprimeixen les adreces d'origen i destinació, protocol i longitud del paquet.

A les xarxes FDDI, l'opció '-e' fa que tcpdump imprimeixi el camp 'control de marc', les adreces de destinació i origen i la longitud del paquet. (El camp `control de marcs 'regeix la interpretació de la resta del paquet. Els paquets normals (com aquells que contenen datagrames d'IP) són paquets` async', amb un valor de prioritat entre 0 i 7, per exemple, ` async4 '. s'assumeix que els paquets contenen un paquet de control d'enllaç lògic (LLC) 802.2: el encapçalament LLC s'imprimeix si no és un datagrama ISO o un paquet anomenat SNAP.

A les xarxes de Token Ring, l'opció '-e' fa que tcpdump imprimeixi els camps `control d'accés 'i` control de marc', les adreces de font i destinació, i la longitud del paquet. Com en les xarxes FDDI, s'assumeix que els paquets contenen un paquet LLC. Independentment de si l'opció '-e' s'especifica o no, la informació d'enrutament d'origen s'imprimeix als paquets de codi font.

(Nota: La descripció següent assumeix la familiaritat amb l'algorisme de compressió SLIP descrit en RFC-1144.)

En enllaços SLIP, s'imprimeix un indicador de direcció (`` I '' per a entrades, `` O '' per a sortir), tipus de paquet i informació de compressió. El tipus de paquet s'imprimeix primer. Els tres tipus són ip , utcp i ctcp . No s'imprimeix cap altra informació d'enllaç per a paquets d' IP . Per a paquets TCP, l'identificador de connexió s'imprimeix seguint el tipus. Si el paquet està comprimit, s'imprimeix el encapçalament codificat. Els casos especials s'imprimeixen com * S + n i * SA + n , on n és la quantitat per la qual ha canviat el nombre de seqüència (o nombre de seqüència i ack). Si no és un cas especial, s'imprimeixen zero o més canvis. Un canvi és indicat per U (punter urgent), W (finestra), A (ack), S (número de seqüència) i I (ID del paquet), seguit d'un delta (+ n o -n) o un nou valor (= n). Finalment, s'imprimeix la quantitat de dades del paquet i la longitud del capçal comprimit.

Per exemple, la següent línia mostra un paquet TCP comprimit de sortida, amb un identificador de connexió implícit; l'ack ha canviat un 6, el nombre de seqüència de 49 i el de paquet de 6; hi ha 3 bytes de dades i 6 bytes de capçalera comprimida:

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

Paquets ARP / RARP

La sortida arp / rarp mostra el tipus de sol·licitud i els seus arguments. El format té la intenció de ser explicatiu. Aquí teniu una petita mostra extreta des de l'inici d'un `rlogin 'de host rtsg a host csam :

arp qui-ha trucat tell rtsg arp answer csam is-a CSAM

La primera línia diu que rtsg va enviar un paquet arp preguntant per l'adreça ethernet de l'amfitrió d'Internet csam. Csam contesta amb la seva adreça ethernet (en aquest exemple, les adreces d'ethernet es troben en caps i adreces d'Internet en minúscules).

Això semblaria menys redundant si haguéssim fet tcpdump -n :

arp que-té 128.3.254.6 dir 128.3.254.68 resposta arp 128.3.254.6 és-a les 02: 07: 01: 00: 01: c4

Si haguéssim fet tcpdump -e , el fet que es emet el primer paquet i el segon sigui punt a punt seria visible:

RTSG Broadcast 0806 64: arp que ha informat CSS RTSG 0806 64: arp answer csam és-a CSAM

Per al primer paquet, es diu que l'adreça d'origen ethernet és RTSG, la destinació és l'adreça de difusió d'ethernet, el camp de tipus conté hexadecimal 0806 (tipus ETHER_ARP) i la longitud total era de 64 bytes.

Paquets TCP

(Nota: La descripció següent assumeix la familiaritat amb el protocol TCP descrit a RFC-793. Si no esteu familiaritzat amb el protocol, ni aquesta descripció ni el vostre tcpdump us seran molt útils.)

El format general d'una línia de protocol TCP és:

src> dst: flags data-seqno ack finestra opcions urgents

Src i dst són les adreces i ports d'origen i destinació. Els flags són una combinació de S (SYN), F (FIN), P (PUSH) o R (RST) o un sol "." (sense banderes). Data-seqno descriu la part de l'espai de seqüència cobert per les dades d'aquest paquet (vegeu l'exemple següent). Ack és el número de seqüència de les dades següents que s'esperava l'altra direcció d'aquesta connexió. La finestra és el nombre de bytes de l'espai de memòria intermèdia de recepció disponible en l'altra direcció d'aquesta connexió. Urg indica que hi ha dades 'urgents' al paquet. Les opcions són opcions tcp incloses entre claudàtors angulars (per exemple, ).

Src, dst i les banderes estan sempre presents. Els altres camps depenen del contingut de l'encapçalament del protocol tcp del paquet i només es generen si escau.

Aquí hi ha la part d'obertura d'un rlogin de host rtsg per allotjar csam .

rtsg.1023> csam.login: S 768512: 768512 (0) guanyar 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 win 4096 rtsg.1023> csam. iniciar Sessió: . 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

La primera línia diu que el port tcp 1023 a rtsg va enviar un paquet a l' inici de sessió del port a csam. El S indica que s'ha establert l'indicador SYN . El número de seqüència de paquets era de 768512 i no contenia dades. (La notació és `first: last (nbytes) ', que significa` nombres de seqüència primers fins a però no incloent l' últim que és nbytes bytes de dades de l'usuari'.) No hi va haver ack respaldada per piggy, la finestra de recepció disponible era de 4096 bytes i hi ha una opció de mida de segment màx. que sol·licita un ms de 1024 bytes.

Csam contesta amb un paquet similar, excepte que inclou un ack respaldat per piggy per a SYN de RTSG. Rtsg llavors acks SYN de Csam. El `. ' significa que no s'han configurat banderes. El paquet no contenia dades, de manera que no hi ha cap número de seqüència de dades. Tingueu en compte que el número de seqüència de ack és un enter petit (1). La primera vegada que tcpdump veu una conversa Tcp, imprimeix el número de seqüència del paquet. En paquets posteriors de la conversa, s'imprimeix la diferència entre el número de seqüència del paquet actual i aquest número de seqüència inicial. Això significa que els nombres de seqüència després de la primera poden interpretar-se com a posicions de bytes relatives en la seqüència de dades de la conversa (amb el primer byte de dades cada direcció és «1»). `-S 'anul·larà aquesta característica, fent que es generin els nombres de seqüència originals.

A la sisena línia, RTSG envia csam 19 bytes de dades (bytes de 2 a 20 en el costat rtsg -> csam de la conversa). L'indicador PUSH s'estableix al paquet. A la 7a línia, csam diu que les dades rebudes són enviades per rtsg fins però no s'inclou el byte 21. La majoria d'aquestes dades aparentment estan assegudes al buffer de sockets ja que la finestra de recepció de csam ha obtingut 19 bytes més petits. Csam també envia un byte de dades a rtsg en aquest paquet. A les línies 8 i 9, csam envia dos bytes de dades urgents, empantats a rtsg.

Si la captura de pantalla era prou petita que tcpdump no va capturar l'encapçalament TCP complet, interpreta la major part del encapçalament que pot i després informa `` [| tcp ] '' per indicar que la resta no es pot interpretar. Si l'encapçalament conté una opció falsa (una amb una longitud massa petita o més enllà del final de l'encapçalament), tcpdump la informa com " mal opt " i no interpreta cap altra opció (ja que no es pot dir on comencen). Si la longitud de la capçalera indica que les opcions estan presents, però la longitud del datagrama d'IP no és prou llarg perquè les opcions estiguin actualment, tcpdump la informa com a `` [ mala longitud hdr ] ''.

Capturar paquets TCP amb combinacions de bandera particulars (SYN-ACK, URG-ACK, etc.)

Hi ha 8 bits a la secció de bits de control del encapçalament TCP:

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

Suposem que volem veure els paquets utilitzats per establir una connexió TCP. Recordeu que TCP utilitza un protocol de presa de mans de 3 maneres quan s'inicialitza una nova connexió; la seqüència de connexió respecte als bits de control de TCP és

1) El visitant envia SYN

2) El destinatari respon amb SYN, ACK

3) El visitant envia ACK

Ara estem interessats a capturar paquets que només tenen el conjunt de bit SYN (pas 1). Tingueu en compte que no volem paquets del pas 2 (SYN-ACK), només un SYN inicial senzill. El que necessitem és una expressió de filtre correcta per a tcpdump .

Recordeu l'estructura d'un encapçalament TCP sense opcions:

0 15 31 ----------------------------------------------- ------------------ | port d'origen | port de destinació | -------------------------------------------------- --------------- | número de seqüència | -------------------------------------------------- --------------- | número de confirmació | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | mida de finestra | -------------------------------------------------- --------------- | TCP checksum | punter urgent | -------------------------------------------------- ---------------

Un encapçalament TCP normalment té 20 octets de dades, tret que hi hagi opcions. La primera línia del gràfic conté els octets 0 - 3, la segona línia mostra octets 4 - 7, etc.

Començant a comptar amb 0, els bits de control TCP rellevants estan continguts en l'octeto 13:

0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | mida de finestra | ---------------- | --------------- | --------------- | - --------------- | | 13 º octet | | |

Anem a veure l'octet núm. 13:

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

Aquests són els bits de control TCP que ens interessen. Hem numerat els bits d'aquest octet de 0 a 7, de dreta a esquerra, de manera que el bit de PSH és el bit número 3, mentre que el bit URG és el número 5.

Recordem que volem capturar paquets amb només SYN. Anem a veure què passa amb l'octet 13 si arriba un datagrama TCP amb el bit de SYN establert en el seu encapçalament:

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

En veure la secció de bits de control, veiem que només s'estableix el número de bits 1 (SYN).

Suposant que octet número 13 és un enter de 8 bits sense signe en ordre de bytes de xarxa, el valor binari d'aquest octet és

00000010

i la seva representació decimal és

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

Ja hem acabat, perquè ara sabem que si només s'estableix SYN, el valor del 13 º octet en el encapçalament TCP, quan s'interpreta com un enter de 8 bits sense signe en l'ordre de bytes de xarxa, ha de ser exactament 2.

Aquesta relació es pot expressar com

tcp [13] == 2

Podem utilitzar aquesta expressió com a filtre per a tcpdump per veure paquets que només tenen SYN:

tcpdump -i xl0 tcp [13] == 2

L'expressió diu que "deixeu que el 13 º octet d'un datagrama TCP tingui el valor decimal 2", que és exactament el que volem.

Ara, suposem que hem de capturar els paquets SYN, però no ens importa que ACK o qualsevol altre bit de control TCP estigui configurat al mateix temps. Anem a veure què passa amb l'octet 13 quan arriba un datagrama TCP amb el conjunt SYN-ACK:

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

Ara els bits 1 i 4 s'estableixen al 13è octet. El valor binari de l'octet 13 és

00010010

que es tradueix en decimal

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

Ara no podem utilitzar 'tcp [13] == 18' en l'expressió del filtre tcpdump , ja que només seleccionarien aquells paquets que tenen SYN-ACK establerts, però no aquells que només tenen el SYN. Recordeu que no ens importa que ACK o qualsevol altre bit de control estigui configurat sempre que s'estableixi SYN.

Per aconseguir el nostre objectiu, necessitem lògicament I el valor binari de l'octet 13 amb algun altre valor per preservar el bit de SYN. Sabem que volem que SYN s'estableixi, en qualsevol cas, de manera que LOGICAMENT i el valor en el 13 º octet amb el valor binari d'un SYN:

00010010 SYN-ACK 00000010 SYN I 00000010 (volem SYN) I 00000010 (volem SYN) -------- -------- = 00000010 = 00000010

Veiem que aquesta operació AND ofereix el mateix resultat independentment de si s'estableix ACK o un altre bit de control TCP. La representació decimal del valor AND, així com el resultat d'aquesta operació, és 2 (binari 00000010), de manera que sabem que per a paquets amb SYN, la relació següent ha de ser veritable:

((valor del octet 13) I (2)) == (2)

Això ens indica l'expressió del filtre tcpdump

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

Tingueu en compte que haureu d'usar cometes simples o una barra invertida a l'expressió per ocultar el caràcter especial AND ('&') del shell.

Paquets UDP

El format UDP s'il·lustra amb aquest paquet rwho:

actinide.who> broadcast.who: udp 84

Això diu que el port que a l' actínida de l' amfitrió va enviar un datagrama udp al port que en la transmissió de l' emissora , l'adreça de difusió a Internet. El paquet contenia 84 bytes de dades d'usuari.

Alguns serveis UDP es reconeixen (des del número de port d'origen o de destinació) i la informació del protocol de nivell superior s'imprimeix. En concret, les sol·licituds de servei de noms de domini (RFC-1034/1035) i les trucades de Sun RPC (RFC-1050) a NFS.

Sol·licituds de servidor de noms UDP

(Nota: La descripció següent assumeix la familiaritat amb el protocol de servei de domini descrit en RFC-1035. Si no esteu familiaritzat amb el protocol, la següent descripció apareixerà en grec.)

Les sol·licituds del servidor de noms estan formatejades com a

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

L'amfitrió h2opolo va demanar al servidor de domini en helios un registre d'adreça (qtype = A) associat al nom ucbvax.berkeley.edu. L'identificador de consulta era "3". El `+ 'indica que es va establir l'indicador de recursió desitjat . La longitud de la consulta era de 37 bytes, sense incloure els encapçalaments de protocol UDP i IP. L'operació de consulta era la normal, Query , de manera que el camp op estava omès. Si l'op havia estat una altra cosa, s'hauria imprès entre el `3 'i el` +'. De la mateixa manera, la classclatura era la normal, C_IN , i s'ometia . Qualsevol altra classe s'hauria imprès immediatament després de la 'A'.

Es comproven algunes anomalies i poden provocar camps addicionals entre claudàtors: si una consulta conté una resposta, els registres d'autoritat o la secció de registres addicionals, ancount , nscount o arcount s'imprimeixen com '[ n a]', `[ n n ] 'o' [ n au] 'on n és el recompte adequat. Si algun dels bits de resposta s'estableixen (AA, RA o rcode) o qualsevol dels bits `must be zero 'estan establerts en bytes dos i tres,` [b2 & 3 = x ]' s'imprimeix, on x és el valor hexadecimal de bytes de capçalera dos i tres.

Respostes del servidor de noms UDP

Les respostes del servidor de noms estan formatejades com a

src> dst: id rcode flags a / n / au class class data (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)

En el primer exemple, els helios responen a la consulta 3 de l' h2opolo amb 3 registres de resposta, 3 registres del servidor de noms i 7 registres addicionals. El primer registre de resposta és tipus A (adreça) i les seves dades són l'adreça d'Internet 128.32.137.3. La mida total de la resposta va ser de 273 bytes, excepte els encapçalaments UDP i IP. S'ha omès el codi op (Query) i de resposta (NoError), igual que la classe (C_IN) del registre A.

En el segon exemple, els helios responen a la consulta 2 amb un codi de resposta de domini inexistent (NXDomain) sense respostes, un servidor de noms i cap registre d'autoritat. El `* 'indica que el bit de resposta autoritzada s'ha definit. Atès que no hi havia respostes, no es va imprimir cap tipus, classe ni dades.

Altres caràcters d'indicació que poden aparèixer són `- '(recursió disponible, RA, no establerta) i` |' (missatge truncat, TC, establert). Si la secció `question 'no conté exactament una entrada, s'imprimeix` [ n q]'.

Tingueu en compte que les sol · licituds i respostes del servidor de noms tendeixen a ser grans i la captura predeterminada de 68 bytes pot no capturar prou del paquet que voleu imprimir. Utilitzeu la marca -s per augmentar el complement si necessiteu investigar seriosament el trànsit del servidor de noms. ` -s 128 'ha funcionat bé per a mi.

Descodificació de SMB / CIFS

tcpdump ara inclou una decodificació SMB / CIFS / NBT bastant extensa per a les dades de UDP / 137, UDP / 138 i TCP / 139. També es fa una descodificació primitiva de dades IPX i NetBEUI SMB.

Per defecte, es fa una descodificació bastant mínima, amb una decodificació molt més detallada si s'utilitza -v. Tingueu en compte que amb -que un sol paquet SMB pot ocupar una pàgina o més, només cal fer servir -v si realment voleu tots els detalls gory.

Si descodifica sessions de SMB que contenen cadenes unicode, és possible que vulgueu establir la variable d'entorn USE_UNICODE a 1. S'hauria d'acceptar un pegat per detectar automàticament els codis unicode.

Per obtenir informació sobre els formats de paquets SMB i el significat de tots els camps, visiteu www.cifs.org o el directori pub / samba / specs / del vostre lloc de mirall favorit de samba.org. Els pegats SMB van ser escrits per Andrew Tridgell (tridge@samba.org).

Sol·licituds i respostes de NFS

Les sol · licituds i respostes de Sun NFS (Network File System) s'imprimeixen com:

src.xid> dst.nfs: len op args src.nfs> dst.xid: answer stat len ​​op results sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709: reply ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 consultes fh 9,74 / 4096.6878 "xcolors" wrl.nfs> sushi.201b: resposta ok 128 cerques fh 9,74 / 4134.3150

A la primera línia, l'host sushi envia una transacció amb id 6709 a wrl (tingueu en compte que el número que segueix el servidor src és un identificador de transacció, no el port d'origen). La sol·licitud era de 112 bytes, sense incloure els encapçalaments UDP i IP. L'operació era un enllaç llegit (enllaç simbòlic llegit) a l'identificador del fitxer ( fh ) 21,24 / 10.731657119. (Si teniu sort, com en aquest cas, l'identificador del fitxer es pot interpretar com un parell de número de dispositiu major i menor, seguit del número d'inode i del número de generació.) Wrl respon 'ok' amb el contingut de l'enllaç.

A la tercera línia, el sushi demana a wrl que cerqui el nom ' xcolors ' al fitxer de directori 9,74 / 4096.6878. Tingueu en compte que les dades impreses depenen del tipus de funcionament. El format té com a objectiu ser automàtic si es llegeix juntament amb una especificació del protocol NFS.

Si s'ofereix la bandera -v (verbosa), s'imprimeix informació addicional. Per exemple:

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

(-v també imprimeix els camps de la capçalera IP TTL, ID, longitud i fragmentació, que s'han omès d'aquest exemple.) En la primera línia, el sushi demana a wrl que llegeixi 8192 bytes del fitxer 21,11 / 12,195, en offset 24576. Wrl respon 'ok'; el paquet que es mostra a la segona línia és el primer fragment de la resposta i, per tant, només té 1472 bytes de llarg (els altres bytes es seguiran en fragments posteriors, però aquests fragments no tenen encapçalaments NFS o fins i tot UDP i, per tant, no es poden imprimir, depenent de l'expressió de filtre usada). Com que es dóna la bandera -v, alguns dels atributs del fitxer (que es retornen a més de les dades del fitxer) s'imprimeixen: el tipus de fitxer (`` REG '', per a fitxers regulars), el mode d'arxiu (en octal), el uid i gid, i la mida del fitxer.

Si la bandera -v s'ofereix més d'una vegada, s'imprimiran encara més detalls.

Tingueu en compte que les sol · licituds de NFS són molt grans i gran part dels detalls no s'imprimiran a menys que snaplen s'incrementi. Intenta utilitzar ` -s 192 'per veure el trànsit NFS.

Els paquets de resposta NFS no identifiquen explícitament l'operació RPC. En canvi, tcpdump fa un seguiment de les peticions "recents" i les coincideix amb les respostes utilitzant l'identificador de la transacció. Si una resposta no segueix de prop la sol·licitud corresponent, és possible que no sigui comparable.

Sol·licituds i respostes de AFS

Les sol·licituds i respostes de Transarc AFS (Andrew File System) s'imprimeixen com a:

src.sport> dst.dport: rx tipus de paquet src.sport> dst.dport: rx servei de tipus de paquet anomenat nom de trucada args src.sport> dst.dport: rx servei de tipus de paquet de resposta nom de trucada args elvis. 7001> pike.afsfs: rx data fs truqueu al nom antic fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx data fs reanombre el nom

A la primera línia, l'host elvis envia un paquet RX a la pica. Aquest va ser un paquet de dades RX al servei fs (servidor de servidor de fitxers), i és l'inici d'una trucada RPC. La trucada RPC era un canvi de nom, amb l'identificador de fitxer de directori antic de 536876964/1/1 i un antic nom de fitxer de `.newsrc.new ', i un nou identificador de fitxer de directori de 536876964/1/1 i un nou nom de fitxer de`. newsrc '. El host pike respon amb una resposta RPC a la trucada de canvi de nom (que va tenir èxit, perquè era un paquet de dades i no un paquet d'avort).

En general, tots els RPC d'AFS són decodificats almenys pel nom de la trucada RPC. La majoria dels RPC d'AFS tenen almenys alguns dels arguments descodificats (generalment només els arguments 'interessants', per a algunes definicions d'interessants).

El format té com a finalitat la seva auto-descripció, però probablement no serà útil per a persones que no estiguin familiaritzades amb el funcionament d'AFS i RX.

Si s'ofereix el pavelló -v (verbós) dues vegades, s'imprimeixen paquets de reconeixement i informació addicional de capçalera, com ara l'identificador de trucada RX, el número de trucada, el número de seqüència, el número de sèrie i els paquets de paquets RX.

Si s'ofereix la bandera -v dues vegades, s'imprimeix informació addicional, com ara l'identificador de trucada RX, el número de sèrie i els paquets de paquets RX. La informació de negociació de MTU també s'imprimeix a partir de paquets RX ack.

Si el símbol -v s'ofereix tres vegades, s'indica l'índex de seguretat i l'identificador de servei.

Els codis d'error s'imprimeixen per a paquets d'abortació, a excepció dels paquets de baliza d'Ubik (perquè els paquets d'abort s'utilitzen per significar un sí de vot per al protocol Ubik).

Tingueu en compte que les sol·licituds d'AFS són molt grans i molts dels arguments no s'imprimiran a menys que s'incrementi el snaplen . Intenta utilitzar ` -s 256 'per veure el trànsit AFS.

Els paquets de resposta AFS no identifiquen explícitament l'operació RPC. En canvi, tcpdump fa un seguiment de les peticions "recents" i les correspon a les respostes utilitzant el número de trucada i l'ID del servei. Si una resposta no segueix de prop la sol·licitud corresponent, és possible que no sigui comparable.

KIP Appletalk (DDP en UDP)

Els paquets DDP d'Appletalk encapsulats en datagrames UDP es desxifren i es baixen com a paquets DDP (és a dir, es descarta tota la informació de capçalera UDP). El fitxer /etc/atalk.names s'utilitza per traduir nombres de nets i nombres d'appletalk a noms. Les línies d'aquest fitxer tenen el formulari

nom del número 1.254 èter 16.1 icsd-net 1.254.110 as

Les dues primeres línies donen els noms de les xarxes de miniaplicacions. La tercera línia dóna el nom d'un host en particular (un host es distingeix d'una xarxa pel tercer octet en el número; un número net ha de tenir dos octets i un número d'amfitrió ha de tenir tres octets). El nombre i el nom s'han de separar per espais en blanc (blanks o pestanyes). El fitxer /etc/atalk.names pot contenir línies en blanc o línies de comentari (línies que comencen amb '#').

Les adreces de Appletalk s'imprimeixen en el formulari:

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

(Si el /etc/atalk.names no existeix o no conté una entrada per a un número d'amfitrió / número net de l'aplicació, les adreces s'imprimeixen en forma numèrica.) En el primer exemple, NBP (DDP port 2) a la xarxa 144.1 el node 209 està enviant a qualsevol que estigui escoltant al port 220 del node 112 de xarxa icsd. La segona línia és la mateixa, tret que es conegui el nom complet del node font (`office '). La tercera línia és un enviament des del port 235 al node 149 de xarxa per emetre al port NBP icsd-net (tingueu en compte que l'adreça de difusió (255) està indicada per un nom de xarxa sense número d'amfitrió; per aquest motiu, és una bona idea per mantenir noms de nodes i noms de xarxa diferents en /etc/atalk.names).

Els paquets de protocol NBP (protocol d'enllaç de noms) i ATP (protocol de transacció Appletalk) han interpretat els seus continguts. Altres protocols acomiaden el nom del protocol (o el número si no hi ha cap nom registrat per al protocol) i la mida del paquet.

Els paquets NBP tenen un format com els següents exemples:

icsd-net.112.220> jssmag.2: nbp-lkup 190: "=: LaserWriter @ *" jssmag.209.2> icsd-net.112.220: nbp-reply 190: "RM1140: LaserWriter @ *" 250 techpit.2> icsd -net.112.220: nbp-reply 190: "techpit: LaserWriter @ *" 186

La primera línia és una sol·licitud de cerca de noms per a lectors de làser enviats per l'amfitrió de xarxa icsd 112 i transmesa per net jssmag. L'identificador nbp per a la cerca és 190. La segona línia mostra una resposta a aquesta sol·licitud (tingueu en compte que té el mateix id) de l'amfitrió jssmag.209 que diu que té un recurs de laserwriter anomenat "RM1140" registrat al port 250. El tercer La línia és una altra resposta a la mateixa sol · licitud que diu que el techpit host té el "techpit" de gravadora làser registrat al port 186.

El format del paquet ATP es demostra en el següent exemple:

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

Jssmag.209 inicia la identificació de la transacció 12266 amb helios amfitrió sol·licitant fins a 8 paquets (el `<0-7> '). El número hexadecimal al final de la línia és el valor del camp `userdata 'a la sol·licitud.

Helios respon amb 8 paquets de 512 bytes. El `: dígit 'després de l'identificador de la transacció dóna el número de seqüència de paquets en la transacció i el número en parens és la quantitat de dades del paquet, excloent el encapçalament de l'atp. El `* 'del paquet 7 indica que el bit d'EOM s'ha definit.

Jssmag.209 llavors demana que els paquets 3 i 5 es tornin a transmetre. Helios els reenvia llavors jssmag.209 publica la transacció. Finalment, jssmag.209 inicia la propera sol·licitud. El `* 'a la sol · licitud indica que XO (' exactament una vegada ') no s'ha establert.

Fragmentació IP

Els datagrames d'Internet fragmentats s'imprimeixen com a

( ID frag : mida @ offset +) ( ID frag : mida @ compensació )

(El primer formulari indica que hi ha més fragments. El segon indica que aquest és l'últim fragment).

Id és l'id de fragment. La mida és la mida del fragment (en bytes), excepte el encapçalament IP. El desplaçament és el desplaçament d'aquest fragment (en bytes) en el datagrama original.

La informació del fragment es produeix per a cada fragment. El primer fragment conté el encapçalament de protocol de nivell més alt i la informació del frag s'imprimeix després de la informació del protocol. Els fragments després de la primera no contenen cap encapçalament del protocol de nivell superior i la informació del frag s'imprimeix després de les adreces de font i destinació. Per exemple, aquí forma part d'un ftp d'arizona.edu a lbl-rtsg.arpa a través d'una connexió CSNET que no sembla manejar datagrames de 576 bytes:

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

Hi ha algunes coses a tenir en compte aquí: en primer lloc, les adreces de la 2a línia no inclouen els números de port. Això és degut a que la informació del protocol TCP es troba en el primer fragment i no tenim ni idea del nombre de port o seqüència quan imprimim els fragments posteriors. En segon lloc, la informació de la seqüència de TCP a la primera línia s'imprimeix com si hi hagués 308 bytes de dades d'usuari quan, de fet, hi ha 512 bytes (308 en el primer frag i 204 en el segon). Si busqueu forats a l'espai de la seqüència o intenteu fer coincidir els acks amb paquets, això us pot enganyar.

Un paquet amb la marca IP no fragmentària està marcat amb un final (DF) .

Timestamps

Per defecte, totes les línies de sortida són precedides per una marca de temps. La marca de temps és el temps actual del rellotge en el formulari

hh: mm: ss.frac

i és tan precís com el rellotge del kernel. La marca de temps reflecteix el temps que el nucli va veure el paquet per primera vegada. No es pretén donar compte del retard de temps entre quan la interfície ethernet va treure el paquet del cable i quan el nucli va atendre el paquet `new packet '.

VEGEU TAMBÉ

trànsit (1C), nit (4P), bpf (4), pcap (3)

Important: utilitzeu l'ordre man ( % home ) per veure com s'utilitza una comanda a l'ordinador en particular.