NAME
tcpdump: elimine o tráfico nunha rede
SINOPSE
tcpdump [ -adeflnNOpqRStuvxX ] [ -c conta ]
[ -C file_size ] [ -F ficheiro ]
[ -i interface ] [ módulo- m ] [ -r ficheiro ]
[ -s snaplen ] [ -T tipo ] [ -U usuario ] [ -w ficheiro ]
[ -E algo: segredo ] [ expresión ]
DESCRICIÓN
Tcpdump imprime os encabezados de paquetes nunha interface de rede que coincide coa expresión booleana. Tamén pode executarse coa bandeira -w , o que fai que garde os datos de paquetes nun ficheiro para unha análise posterior e / ou coa marca -r , o que fai que lea desde un ficheiro de paquetes gardado en lugar de ler paquetes desde unha interface de rede. En todos os casos, tcpdump procesará só paquetes que coincidan coa expresión .
O Tcpdump fará que, se non se executa coa bandeira -c , continúa capturando os paquetes ata que se interrompa cun sinal SIGINT (xerado, por exemplo, escribindo o seu carácter de interrupción, normalmente o control de C) ou un sinal SIGTERM (normalmente xerado co matar (1) orde); Se se executa coa bandeira -c capturará os paquetes ata que se interrompa cun sinal SIGINT ou SIGTERM ou se procesou o número especificado de paquetes.
Cando tcpdump termine de capturar paquetes, reportará un reconto de:
Os paquetes `` recibidos por filtro '' (o seu significado depende do sistema operativo no que está executando tcpdump , e posiblemente na forma en que se configurou o sistema operativo) se se especificou un filtro na liña de comando, nalgúns SO que conteña paquetes independentemente de que fosen compatibles coa expresión de filtro e noutros sistemas operativos conta só con paquetes que coincidían coa expresión de filtro e foron procesados por tcpdump );
paquetes `` caeu por kernel '' (este é o número de paquetes que foron eliminados, debido a unha falta de espazo de buffer, polo mecanismo de captura de paquetes no sistema operativo no que tcpdump está a executarse, se o sistema informa esa información a aplicacións; se non, será informar como 0).
Nas plataformas que soportan o sinal de SIGINFO, como a maioría dos BSD, informará eses conteos cando recibe un sinal SIGINFO (xerado, por exemplo, escribindo o seu carácter `` estado '', normalmente controla -T) e continuará capturando paquetes .
Os paquetes de lectura dunha interface de rede poden requirir que teña privilexios especiais:
Baixo SunOS 3.x ou 4.x con NIT ou BPF:
Debe ter acceso de lectura a / dev / nit ou / dev / bpf * .
Baixo Solaris con DLPI:
Debe ter acceso de lectura / escritura ao pseudo dispositivo da rede, por exemplo / dev / le . Polo menos, nalgunhas versións de Solaris, non obstante, isto non é suficiente para permitir que tcpdump capture de forma promiscuo; nesas versións de Solaris, debes ser root ou tcpdump debe instalarse setuid a root, para capturalo de forma promiscuo. Teña en conta que, en moitas (quizais todas) interfaces, se non captura en modo promiscuo, non verá ningún paquete de saída, polo que non se pode usar unha captura non realizada de xeito promiscuo.
En HP-UX con DLPI:
Debe estar root ou tcpdump debe ser instalado setuid para root.
Baixo IRIX con snoop:
Debe estar root ou tcpdump debe ser instalado setuid para root.
En Linux:
Debe estar root ou tcpdump debe ser instalado setuid para root.
Con Ultrix e Digital UNIX / Tru64 UNIX:
Calquera usuario pode capturar o tráfico da rede con tcpdump . Non obstante, ningún usuario (nin sequera o superusuario) pode capturar en modo promiscuo nunha interface a menos que o superusuario permita o funcionamento do modo promiscuo nesa interface usando pfconfig (8) e ningún usuario (nin sequera o superusuario ) pode capturar o tráfico unicast recibido ou enviado pola máquina nunha interface a non ser que o superusuario permita o funcionamento de todo o modo en esa interface usando pfconfig , polo tanto, unha captura de paquetes útil nunha interface probablemente requira que o modo promiscuo ou a copia A operación de modo total, ou ambos os modos de operación, estean habilitados nesa interface.
En BSD:
Debe ter acceso de lectura a / dev / bpf * .
A lectura dun ficheiro de paquete gardado non require privilexios especiais.
OPCIÓNS
-a
Intento de converter enderezos de rede e de difusión a nomes.
-c
Sae despois de recibir paquetes de contador .
-C
Antes de escribir un paquete crúa nun ficheiro gardado, verifique se o ficheiro é actualmente maior que o arquivo_de tamaño e, en caso afirmativo, peche o ficheiro gardado actual e abra un novo. Os ficheiros gardados despois do primeiro ficheiro gardado terán o nome especificado coa bandeira -w , cun número despois del, comezando a 2 e continuando cara arriba. As unidades de tamaño de ficheiro son millóns de bytes (1.000.000 bytes, e non 1.048.576 bytes).
-d
Despexa o código compilado de paquetes compilado nunha forma lexible para a saída estándar e pare.
-dd
Despexa o código de paquetes como fragmento de programa C.
-ddd
Despexa o código de paquetes como números decimais (precedido cun reconto).
-e
Imprime o cabeceiro de nivel de ligazón en cada liña de descarga.
-E
Usar algo: segredo para descifrar paquetes IPsec ESP. Os algoritmos poden ser des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc ou ningún . O valor predeterminado é des-cbc . A capacidade de descifrar os paquetes só está presente se tcpdump foi compilado con criptografía activada. secreta o texto ascii para a clave secreta ESP. Non podemos tomar valor binario arbitrario neste momento. A opción asume RFC2406 ESP, non RFC1827 ESP. A opción só é para propósitos de depuración, e non se desanima o uso desta opción con unha chave verdadeiramente 'secreta'. Ao presentar a chave secreta de IPsec na liña de comandos faino visible para outros, a través de ps (1) e noutras ocasións.
-f
Imprime enderezos de Internet 'estranxeiros' numéricamente en lugar de simbólicamente (esta opción ten como obxectivo evitar o dano cerebral grave no servidor de Sun de YP --- normalmente colga por sempre traducir números de internet non locais).
-F
Use o ficheiro como entrada para a expresión do filtro. Non se ten en conta unha expresión adicional dada na liña de comandos.
-i
Escoita na interface . Se non está especificado, tcpdump busca a lista de interfaces do sistema para a interface máis baixa e configurada (excluíndo o loopback). Os lazos rompeuse escollendo a partida máis antiga.
Nos sistemas Linux con kernel 2.2 ou posterior, pode usarse un argumento de interface de `` calquera '' para capturar paquetes de todas as interfaces. Teña en conta que as capturas no dispositivo `` calquera '' non se farán en modo promiscuo.
-l
Facer a liña stdout buffered. Útil se quere ver os datos ao capturalo. Por exemplo,
`` tcpdump -l | tee dat '' ou `` tcpdump -l> dat & tail -f dat ''.
-m
Manteña as definicións do módulo SMI MIB do módulo de ficheiro. Esta opción pódese usar varias veces para cargar varios módulos MIB en tcpdump .
-n
Non converter enderezos de servidor a nomes. Isto pódese usar para evitar buscas DNS.
-nn
Non converter o protocolo nin os números de porto nin os nomes.
-N
Non imprima a cualificación do nome de dominio dos nomes do servidor. Por exemplo, se dan esta bandeira, tcpdump imprimirá `` nic '' no canto de `` nic.ddn.mil ''.
-O
Non execute o optimizador de código que coincida con paquetes. Isto só é útil se sospeita dun erro no optimizador.
-p
Non coloque a interface nun modo promiscuo. Teña en conta que a interface pode estar en modo promiscuo por algún outro motivo; polo tanto, `-p 'non pode ser usado como unha abreviatura para` ether host {local-hw-addr} ou broadcast de éter'.
-q
Saída rápida (tranquila?). Imprime menos información do protocolo para que as liñas de saída sexan máis curtas.
-R
Asume os paquetes ESP / AH para basearse na especificación antiga (RFC1825 a RFC1829). Se se especifica, tcpdump non imprimirá o campo de prevención de reprodución. Xa que non hai campo de versión de protocolo na especificación ESP / AH, tcpdump non pode deducir a versión do protocolo ESP / AH.
-r
Lea paquetes desde o ficheiro (que foi creado coa opción -w). A entrada estándar emprégase se o ficheiro é `` - ''.
-S
Imprimir os números de secuencia TCP absoluta, en vez de relativo.
-s
Snarf anula os bytes de datos de cada paquete en lugar do estándar de 68 (co NIT de SunOS, o mínimo é en realidade 96). Os 68 bytes son adecuados para IP, ICMP, TCP e UDP, pero poden truncar a información do protocolo do servidor de nomes e os paquetes NFS (ver a continuación). Os paquetes truncados debido a unha instantánea limitada indícanse na saída con `` [| proto ] '', onde proto é o nome do nivel de protocolo no que se produciu o truncado. Teña en conta que tomar instantáneas maiores aumenta tanto o tempo que leva para procesar os paquetes e, de feito, diminúe a cantidade de buffering de paquetes. Isto pode causar a perda dos paquetes. Debe limitar snaplen ao número máis pequeno que capturará a información do protocolo en que estea interesado. Configurar snaplen en 0 significa usar a lonxitude necesaria para capturar paquetes completos.
-T
Forzar os paquetes seleccionados por " expresión " para interpretar o tipo especificado. Tipos actualmente coñecidos son cnfp (protocolo Cisco NetFlow), rpc (Remote Procedure Call), rtp (protocolo de aplicacións en tempo real), rtcp (protocolo de control de aplicacións en tempo real), snmp (Protocolo de xestión de redes sinxelo), vat (Visual Audio Tool ) e wb (White Board distribuído).
-t
Non imprima unha marca de tempo en cada liña de descarga.
-tt
Imprimir unha marca de tempo non formateada en cada liña de descarga.
-U
Deixou os privilexios de root e cambia a ID de usuario a ID de usuario e grupo ao grupo principal de usuarios .
Nota! Red Hat Linux deixa caer automaticamente os privilexios ao usuario `` pcap '' se non se especifica máis nada.
-ttt
Imprimir un delta (en micro segundos) entre a liña actual e a anterior en cada liña de descarga.
-tttt
Imprimir unha marca de tempo no formato por defecto proseguiu por data en cada liña de descarga.
-u
Imprimir manetas NFS non decodificadas.
-v
(Pouca máis) Saída detallada. Por exemplo, o tempo de vida, a impresión, a lonxitude total e as opcións nun paquete IP están impresas. Tamén permite comprobacións de integridade de paquetes adicionais como verificar a suma de verificación de cabecera de IP e ICMP.
-vv
Saída aínda máis detallada. Por exemplo, os campos adicionais están impresos a partir de paquetes de resposta NFS e os paquetes SMB están completamente descodificados.
-vvv
Saída aínda máis detallada. Por exemplo, as opcións de telnet SB ... SE están impresas na súa totalidade. Con -X opcións de telnet tamén están impresas en hexadecimal.
-w
Escribe os paquetes crus para arquivar en vez de analizar e imprimilos. Posteriormente poden imprimirse coa opción -r. A saída estándar úsase se o ficheiro é `` - ''.
-x
Imprime cada paquete (menos o seu título de nivel de ligazón) en hexadecimal. O máis pequeno do paquete enteiro ou os bytes snaplen imprimiranse. Teña en conta que este é o paquete enteiro da capa de conexión, polo que para as capas de enlace que o pad (por exemplo, Ethernet), os bytes de relleno tamén se imprimirán cando o paquete de capa superior sexa máis curto que o relleno desexado.
-X
Ao imprimir hexadecimal, imprima ascii tamén. Así, se -x tamén está configurado, o paquete está impreso en hex / ascii. Isto é moi útil para analizar novos protocolos. Aínda que -x non está definido, algunhas partes de algúns paquetes poden ser impresas en hex / ascii.
expresión
selecciona os paquetes que se despacharán. Se non se fornece ningunha expresión , todos os paquetes da rede serán obxecto de dumping. Se non, só se borrarán os paquetes para os cales a expresión é 'verdadeira'.
A expresión consta dunha ou máis primitivas. Os primitivos normalmente consisten nunha id (nome ou número) precedida por un ou máis cualificadores. Existen tres tipos diferentes de cualificador:
tipo
Os cualificadores din que tipo de cousas refírese ao nome ou número de identificación. Os tipos posibles son anfitrión , rede e porto . Por exemplo, `host foo ',` net 128.3', `port 20 '. Se non hai un calificador de tipo, asumirase host .
dir
Os clasificadores especifican unha dirección de transferencia particular a e / ou desde a identificación . As direccións posibles son src , dst , src ou dst e src e dst . Por exemplo, `src foo ',` dst net 128.3', `src ou dst port ftp-data '. Se non hai cualificador dir, asúmese src ou dst . Para as capas de conexión "nulas" (ou sexa, protocolos de punto a punto como o slip) os calificadores de entrada e de saída poden usarse para especificar a dirección desexada.
proto
Os clasificadores restrinxen a correspondencia a un protocolo particular. Os posibles protos son: éter , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp e udp . Por exemplo, `ether src foo ',` arp net 128.3', `tcp port 21 '. Se non hai ningún calificador proto, presúmense todos os protocolos consistentes co tipo. Por exemplo, `src foo 'significa` (ip ou arp ou rarp) src foo' (excepto o último non é sintaxe legal), `barra neta 'significa` (ip ou arp ou rarp) barra neta' e 'porto 53' significa O porto `(tcp ou udp) 53 '.
[`fddi 'é realmente un alias para` ether'; o analizador trátanos de forma idéntica como "o nivel de conexión de datos empregado na interface de rede especificada". Os encabezados FDDI conteñen enderezos de destino e fonte similares a Ethernet, e moitas veces conteñen tipos de paquetes tipo Ethernet, polo que pode filtrar estes campos FDDI do mesmo xeito que cos campos Ethernet análogos. Os encabezados FDDI tamén conteñen outros campos, pero non os podes nomear de forma explícita nunha expresión de filtro.
Do mesmo xeito, `tr 'é un alias para` ether'; as declaracións do párrafo anterior sobre cabeceiras FDDI tamén se aplican aos cabeceis de Token Ring.]
Ademais do anterior, hai algunhas palabras clave especiais 'primitivas' que non seguen o patrón: pasarela , emisión , menos , maior e expresións aritméticas. Todos estes son descritos a continuación.
As expresións de filtros máis complexas fórmanse utilizando as palabras e , ou e non para combinar primitivas. Por exemplo, `host foo e non port ftp e non port ftp-data '. Para gardar a dixitación, pódense omitir as listas de cualificacións idénticas. Por exemplo, `tcp dst port ftp ou ftp-data ou domain 'é exactamente o mesmo que` tcp dst port ftp ou tcp dst port ftp-data ou tcp dst port domain'.
As primitivas admitidas son:
servidor anfitrión dst
Verdadeiro se o campo de destino IPv4 / v6 do paquete é servidor , que pode ser unha dirección ou un nome.
host host src
Verdadeiro se o campo de orixe fonte do IPv4 / v6 do paquete é anfitrión .
servidor anfitrión
Verdadeiro se a fonte ou destino de IPv4 / v6 do paquete é anfitrión . Calquera das expresións de host anteriores pódese prepender coas palabras clave, ip , arp , rarp ou ip6 como en:
servidor anfitrión ipo que equivale a:
ether proto \ ip e host hostSe o servidor é un nome con varias direccións IP, cada dirección verificarase por unha coincidencia.
eter dst ehost
Verdadeiro se o enderezo de destino de ethernet é ehost . Ehost pode ser un nome de / etc / éther ou un número (ver ethers (3N) para o formato numérico).
ether src ehost
Verdadeiro se o enderezo fonte ethernet é ehost .
ether host ehost
Verdadeiro se a fonte ou o enderezo de destino ethernet é ehost .
servidor de pasarela
Verdadeiro se o paquete usaba host como porta de entrada. É dicir, a fonte de Ethernet ou o enderezo de destino era anfitrión, pero nin a fonte de IP nin o destino de IP eran anfitrións . O servidor debe ser un nome e debe atoparse tanto polos mecanismos de resolución do enderezo de host-name-to-IP (arquivo de nome do servidor, DNS, NIS, etc.) e pola resolución do enderezo host-name-to-Ethernet mecanismo (/ etc / éteres, etc.). (Unha expresión equivalente é
ether host ehost e non host hostque pode usarse con nomes ou números para host / ehost ). Esta sintaxe non funciona na configuración con IPv6 neste momento.
net dst net
Verdadeiro se a dirección de destino IPv4 / v6 do paquete ten un número de rede de rede . A rede pode ser un nome de / etc / networks ou un número de rede (consulte redes (4) para máis detalles).
src net net
Verdadeiro se o enderezo fonte IPv4 / v6 do paquete ten un número de rede de rede .
neto neto
Verdadeiro se a dirección de orixe ou destino de IPv4 / v6 do paquete ten un número de rede de rede .
net mask mascara de rede
É certo se o enderezo IP coincide co net coa máscara de rede específica. Pode ser cualificado con src ou dst . Ten en conta que esta sintaxe non é válida para a rede IPv6.
net net / len
É verdadeiro se o enderezo IPv4 / v6 coincide coa rede cun ancho de banda de rede. Pode ser cualificado con src ou dst .
porto de porto dst
Verdadeiro se o paquete é ip / tcp, ip / udp, ip6 / tcp ou ip6 / udp e ten un valor de porto de destino de porto . O porto pode ser un número ou un nome usado en / etc / services (ver tcp (4P) e udp (4P)). Se se usa un nome, verifícanse tanto o número de porto como o protocolo. Se se usa un número ou nome ambiguo, só se controla o número de porto (por exemplo, o porto dst 513 imprimirá o tráfico tcp / login e udp / quen o tráfico e o dominio do porto imprimirán o tráfico tcp / dominio e udp / dominio).
porto porto src
Verdadeiro se o paquete ten un valor de porto de orixe do porto .
porto portuario
Verdadeiro se o porto fonte ou destino do paquete é o porto . Calquera das expresións do porto anterior pode prepender coas palabras clave, tcp ou udp , como en:
porto porto src tcpque só coincide con paquetes tcp cuxo porto fonte é porta .
menos lonxitude
Verdadeiro se o paquete ten unha lonxitude inferior ou igual á lonxitude . Isto equivale a:
len <= lonxitude .maior lonxitude
Verdadeiro se o paquete ten unha lonxitude superior ou igual á lonxitude . Isto equivale a:
len> = lonxitude .protocolo proto ip
Verdadeiro se o paquete é un paquete de IP (ver ip (4P)) do protocolo de tipo de protocolo . O protocolo pode ser un número ou un dos nomes icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp ou tcp . Teña en conta que os identificadores tcp , udp e icmp tamén son palabras clave e deben escapar a través de barra invertida (\), que é \\ no shell C. Teña en conta que esta primitiva non persegue a cadea de cabeceira do protocolo.
protocolo proto ip6
Verdadeiro se o paquete é un paquete IPv6 de protocolo de tipo de protocolo . Teña en conta que esta primitiva non persegue a cadea de cabeceira do protocolo.
protocolo protocolo ip6
Verdadeiro se o paquete é o paquete IPv6 e contén o encabezado do protocolo de protocolo na súa cabeceira de protocolo. Por exemplo,
ip6 protochain 6coincide con calquera paquete IPv6 con cabeceira de protocolo TCP na cadea de cabeceira do protocolo. O paquete pode conter, por exemplo, cabeceira de autenticación, cabeceira de enrutamento ou cabeceira de opción hop-by-hop, entre cabeceira IPv6 e cabeceira TCP. O código BPF emitido por esta primitiva é complexo e non pode ser optimizado polo código de optimizador de BPF en tcpdump , polo que isto pode ser algo lento.
protocolo protochain ip
É equivalente ao protocolo protocolo ip6 , pero isto é para IPv4.
emisión de éter
Verdadeiro se o paquete é un paquete de transmisión por ethernet. A palabra clave éter é opcional.
transmisión por ip
Verdadeiro se o paquete é un paquete de transmisión IP. Verifica as convencións de transmisión todos-ceros e todo-un e busca a máscara de subred local.
éter multicast
Verdadeiro se o paquete é un paquete de multidifusión ethernet. A palabra clave éter é opcional. Isto é abreviatura para ` ether [0] & 1! = 0 '.
multicast ip
Verdadeiro se o paquete é un paquete de IP multidifusión.
multicast ip6
Verdadeiro se o paquete é un paquete multidifusión IPv6.
protocolo protocolo éter
Verdadeiro se o paquete é de protocolo tipo éter. O protocolo pode ser un número ou un dos nomes ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx ou netbeui . Teña en conta que estes identificadores tamén son palabras clave e deben escapar a través de barra invertida (\).
[No caso de FDDI (por exemplo, ` fddi protocol arp ') e Token Ring (por exemplo,` tr protocol arp '), para a maioría destes protocolos, a identificación do protocolo provén do encabezado 802.2 Logical Link Control (LLC), que xeralmente está en capas enriba do cabeceiro FDDI ou Token Ring.
Ao filtrar para a maioría dos identificadores de protocolo en FDDI ou Token Ring, tcpdump comproba só o campo ID de protocolo dun encabezado LLC no chamado formato SNAP cun identificador de unidade organizativa (OUI) de 0x000000, para Ethernet encapsulado; non comproba se o paquete está en formato SNAP cun OUI de 0x000000.
As excepcións son iso , polo que comproba o campo de acceso DSAP (Punto de acceso de servizo de destino) e SSAP (Punto de acceso ao servizo de fontes) do encabezado LLC, stp e netbeui , onde comproba o DSAP do encabezado LLC e atalk , onde comproba un paquete con formato SNAP cun OUI de 0x080007 e o nome de Appletalk.
No caso de Ethernet, tcpdump verifica o campo de tipo Ethernet para a maioría destes protocolos; as excepcións son iso , sap e netbeui , para o cal comproba un marco 802.3 e logo comproba o encabezado LLC como o fai para FDDI e Token Ring, atalk , onde compara tanto o tipo de aplicación Appletalk nun marco Ethernet como un Paquete de formato SNAP como o fai para FDDI e Token Ring, aarp , onde comproba o etype ARP de Appletalk nun cadro Ethernet ou nun cadro SNAP 802.2 cun OUI de 0x000000 e ipx , onde comproba o tipo IPX en un cadro Ethernet, o IPAP DSAP no encabezado LLC, o 802.3 sen encapsulamento de encabezado LLC de IPX eo IPty etype nun marco SNAP.]
host decnet src
Verdadeiro se o enderezo fonte DECNET é anfitrión , que pode ser unha dirección do formulario `` 10.123 '', ou un nome de servidor DECNET. [Soporte de nome de servidor DECNET só está dispoñible en sistemas Ultrix que están configurados para executar DECNET.]
decnet dst host
Verdadeiro se o enderezo de destino DECNET é anfitrión .
servidor host decnet
Verdadeiro se a fonte ou a dirección de destino de DECNET son anfitrións .
ip , ip6 , arp , rarp , atalk , aarp , decnet , iso , stp , ipx , netbeui
Abreviaturas para:
éter proto ponde p é un dos protocolos anteriores.
lat , moprc , mopdl
Abreviaturas para:
éter proto ponde p é un dos protocolos anteriores. Teña en conta que tcpdump non sabe analizar estes protocolos.
vlan [vlan_id]
Verdadeiro se o paquete é un paquete VLAN IEEE 802.1Q. Se se especifica [vlan_id] , só o verdadeiro é que o paquete ten o vlan_id especificado. Teña en conta que a primeira palabra clave vlan atopada na expresión cambia os descontos de decodificación para o resto de expresións se supón que o paquete é un paquete VLAN.
tcp , udp , icmp
Abreviaturas para:
ip proto p ou ip6 proto ponde p é un dos protocolos anteriores.
protocolo proto iso
Verdadeiro se o paquete é un paquete OSI de protocolo de tipo de protocolo . O protocolo pode ser un número ou un dos nomes clnp , esis ou isis .
clnp , esis , isis
Abreviaturas para:
iso proto ponde p é un dos protocolos anteriores. Teña en conta que tcpdump fai un traballo incompleto de analizar estes protocolos.
expr relop expr
É certo se a relación mantense, onde relop é unha de>, <,> =, <=, =! = E expr é unha expresión aritmética composta de constantes enteiros (expresada na sintaxe estándar C), os operadores binarios normais [+ , -, *, /, &, |], un operador de lonxitude e os accesorios de paquetes de datos especiais. Para acceder aos datos dentro do paquete, use a seguinte sintaxe:
proto [ expr : tamaño ]Proto é un de éter, fddi, tr, ppp, slip, link, ip, arp, rarp, tcp, udp , icmp ou ip6 e indica a capa de protocolo para a operación de índice. ( ether, fddi, tr, ppp, slip and link todos refírense á capa de ligazón). Teña en conta que os tipos de protocolo tcp, udp e outros tipos de protocolo só se aplican a IPv4 e non a IPv6 (isto será arranxado no futuro). O desprazamento de bytes, en relación coa capa de protocolo indicado, vén dado por expr . O tamaño é opcional e indica o número de bytes no campo de interese; pode ser un, dous ou catro e por defecto. O operador de lonxitude, indicado pola palabra clave len , dá a lonxitude do paquete.
Por exemplo, ` ether [0] & 1! = 0 'captura todo o tráfico multicast. A expresión ` ip [0] & 0xf! = 5 'captura todos os paquetes IP con opcións. A expresión ` ip [6: 2] & 0x1fff = 0 'captura só datagramas non fragmentados e frag zero de datagramas fragmentados. Este control aplícase implícitamente ás operacións de índices tcp e udp . Por exemplo, tcp [0] sempre significa o primeiro byte do cabeceiro TCP e nunca significa o primeiro byte dun fragmento que intervén.
Algunhas compensacións e valores de campo poden expresarse como nomes e non como valores numéricos. Están dispoñibles os seguintes offsets de campo de cabeceira de protocolo: icmptype (campo de tipo ICMP), icmpcode (campo de código ICMP) e tcpflags (campo de bandeiras TCP).
Os seguintes valores de campo tipo ICMP están dispoñibles: icmp-echoreply , icmp-unreach , icmp -sourcequench , icmp -redirect , icmp-echo , icmp -routeradvert , icmp -routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp -supresamente , icmp -ireq , icmp -ireqreply , icmp-maskreq , icmp-maskreply .
Están dispoñibles os seguintes valores de campo de bandeiras TCP: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .
Os primitivos pódense combinar utilizando:
Un grupo paréntese de primitivas e operadores (paréntesis son especiais para o Shell e deben escapar).
Negación (` ! 'Ou' non ').
Concatenación (` && 'ou' e ').
Alternación (` || 'ou` ou ').
A negación ten maior precedencia. A alternancia ea concatenación teñen a mesma precedencia e asocian a esquerda a dereita. Teña en conta que agora son necesarios explicitamente e tokens, non xustaposición, para a concatenación.
Se se dá un identificador sen unha palabra clave, asúmese a palabra clave máis recente. Por exemplo,
non host versus aceé curto para
non host vs e host aceque non debe confundirse con
non (host vs ou ace)Os argumentos de expresión pódense pasar a tcpdump como un único argumento ou como múltiples argumentos, o que sexa máis conveniente. Xeralmente, se a expresión contén metacaracteres Shell, é máis fácil pasalo como un argumento único e citado. Múltiples argumentos concatenados con espazos antes de ser analizados.
EXEMPLOS
Para imprimir todos os paquetes que chegan ou parten do pór do sol :
tcpdump host sundownPara imprimir o tráfico entre helios e quente ou ace :
os helios do host tcpdump e \ (hot ou as \)Para imprimir todos os paquetes de IP entre ace e calquera servidor excepto os helios :
tcpdump ip host ace e non heliosPara imprimir todo o tráfico entre servidores e hosts locais en Berkeley:
tcpdump net ucb-etherPara imprimir todo o tráfico de ftp a través da pasarela de acceso a internet: (nota que se cita a expresión para evitar que a shell de (mis-) interprete os parénteses):
tcpdump 'gateway snup and (port ftp ou ftp-data)'Para imprimir tráfico non procedente nin destinado a hosts locais (se ten unha porta de entrada a outra rede, estas cousas nunca deberían facelo na súa rede local).
tcpdump ip e non net localnetPara imprimir os paquetes de inicio e fin (os paquetes SYN e FIN) de cada conversa TCP que implica un servidor non local.
tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0 e non src e dst net localnet 'Para imprimir paquetes de IP por máis de 576 bytes enviados a través de gateway snup :
tcpdump 'gateway snup e ip [2: 2]> 576'Para imprimir paquetes de transmisión IP ou multidifusión que non foron enviados a través de transmisión por ethernet ou multidifusión:
tcpdump 'ether [0] e 1 = 0 e ip [16]> = 224'Para imprimir todos os paquetes ICMP que non sexan solicitudes / respostas de eco (isto é, non paquetes de paquetes):
tcpdump 'icmp [icmptype]! = icmp-echo e icmp [icmptype]! = icmp-echoreply'FORMATO DE SALIDA
A saída de tcpdump depende do protocolo. A continuación amósase unha breve descrición e exemplos da maioría dos formatos.
Cabeceiras de nivel de ligazón
Se se dá a opción '-e', imprímese o cabeceiro do nivel da ligazón. En ethernets, as direccións de orixe e destino, protocolo e lonxitude do paquete están impresas.
Nas redes FDDI, a opción '-e' fai que tcpdump imprima o campo "control de cadros", os enderezos de orixe e destino e a lonxitude do paquete. (O campo 'control de cadro' regula a interpretación do resto do paquete. Os paquetes normais (como os que conteñen datagramas de IP) son paquetes 'asíncros', cun valor de prioridade entre 0 e 7; por exemplo, ' async4 '. Os paquetes supoñen que conteñen un paquete 802.2 Logical Link Control (LLC); o encabezado LLC está impreso se non é un datagrama ISO ou un paquete chamado SNAP.
Nas redes de Token Ring, a opción '-e' fai que tcpdump implemente os campos `control de acceso e control de cadros ', os enderezos de orixe e destino e lonxitude do paquete. Do mesmo xeito que nas redes FDDI, os paquetes supoñen que conteñen un paquete LLC. Independentemente de se a opción '-e' está especificada ou non, a información de enrutamento de orixe está impresa para os paquetes orientados á fonte.
(Nota: A seguinte descrición supón familiaridade co algoritmo de compresión SLIP descrito en RFC-1144.)
En enlaces SLIP, imprímense un indicador de dirección (`` I '' para entrada, `` O '' para saída), tipo de paquete e información de compresión. O tipo de paquete imprímese primeiro. Os tres tipos son ip , utcp e ctcp . Non se imprime máis información de ligazón para paquetes de IP . Para paquetes TCP, o identificador de conexión imprímese seguindo o tipo. Se o paquete está comprimido, imprímese o seu cabeceiro codificado. Os casos especiais son impresos como * S + n e * SA + n , onde n é a cantidade pola que o número de secuencia (ou número de secuencia e ack) cambiou. Se non é un caso especial, imprímense cero ou máis cambios. Un cambio está indicado por U (punteiro urxente), W (ventá), A (ack), S (número de secuencia) e I (ID de paquete), seguido dun delta (+ n ou -n) ou un novo valor (= n). Finalmente, imprímese a cantidade de datos no paquete e a lonxitude do cabeceiro comprimido.
Por exemplo, a seguinte liña mostra un paquete TCP de saída comprimida, cun identificador de conexión implícita; o ACK cambiou 6, o número de secuencias en 49, eo ID de paquete en 6; hai 3 bytes de datos e 6 bytes de cabeceira comprimida:
O ctcp * A + 6 S + 49 I + 6 3 (6)Paquetes ARP / RARP
A saída arp / rarp mostra o tipo de solicitude e os seus argumentos. O formato pretende ser auto explicativo. Aquí tes unha pequena mostra tomada desde o inicio dun `rlogin 'do host rtsg ao servidor csam :
arp que-csam dixo a resposta a artsg arp csam-en CSAMA primeira liña di que rtsg enviou un paquete arp pedindo o enderezo ethernet do host csam de internet. Csam responde coa súa dirección de ethernet (neste exemplo, os enderezos de ethernet están en casillas e enderezos de internet en minúsculas).
Isto parecería menos redundante se fixésemos tcpdump -n :
arp que - ten 128.3.254.6 din 128.3.254.68 resposta arp 128.3.254.6 é a-02: 07: 01: 00: 01: c4Se tivésemos feito tcpdump -e , o feito de que se transmitiu o primeiro paquete eo segundo é visible a cada punto:
RTSG Broadcast 0806 64: arp que ten csam tell rtsg CSAM RTSG 0806 64: arp response csam está-en CSAMPara o primeiro paquete, isto di que o enderezo da fonte Ethernet é RTSG, o destino é o enderezo de transmisión de ethernet, o campo de tipo contén hex 0806 (tipo ETHER_ARP) ea lonxitude total era de 64 bytes.
Paquetes TCP
(Nota: A seguinte descrición supón familiaridade co protocolo TCP descrito en RFC-793. Se non está familiarizado co protocolo, nin esta descrición nin o tcpdump serán moi útiles para vostede.)
O formato xeral dunha liña de protocolo tcp é:
src> dst: flags data-seqno ack ventá opcións urxentes Src e dst son as direccións e portos IP de fonte e destino. As bandeiras son unha combinación de S (SYN), F (FIN), P (PUSH) ou R (RST) ou un único `. ' (sen indicadores). Data-seqno describe a porción do espazo de secuencia cuberto polos datos deste paquete (vexa o seguinte exemplo). Ack é o número de secuencia dos próximos datos que se espera a outra dirección nesta conexión. A xanela é o número de bytes de espazo de buffer de recepción dispoñible na outra dirección nesta conexión. Urg indica que hai datos `urxentes 'no paquete. As opcións son opcións tcp entre parénteses angulares (por exemplo,
Src, dst e bandeiras están sempre presentes. Os outros campos dependen do contido do encabezado do protocolo tcp do paquete e só se saen se é o caso.
Aquí está a porción de apertura dun rlogin desde host rtsg para hospedar csam .
rtsg.1023> csam.login: S 768512: 768512 (0) gañou 4096A primeira liña di que o porto tcp 1023 en rtsg enviou un paquete ao inicio de sesión do porto en csam. O S indica que se estableceu a bandeira SYN . O número de secuencia de paquetes era 768512 e non contiña datos. (A notación é `first: last (nbytes) 'que significa` primeiros números de secuencia pero non incluíndo o último que é nbytes bytes de datos do usuario'). Non houbo ack respaldado por piggy, a xanela de recepción dispoñible era de 4096 bytes e houbo unha opción de tamaño máximo segmento que solicitou un ms de 1024 bytes.
Csam responde cun paquete similar, agás que inclúe un ack respaldado por piggy para SYN de RTSG. RTSG entón acks SYN de Csam. O `. ' significa que non se estableceron bandeiras. O paquete non contiña datos polo que non hai número de secuencia de datos. Teña en conta que o número de secuencia de ack é un enteiro pequeno (1). A primeira vez que tcpdump ve unha tcp 'conversa', imprime o número de secuencia do paquete. Nos seguintes paquetes da conversa, imprímese a diferenza entre o número de secuencia do paquete actual e este número de secuencia inicial. Isto significa que os números de secuencia despois do primeiro poden ser interpretados como posicións de bytes relativos na transmisión de datos da conversa (co primeiro byte de datos cada dirección sexa '1'). `-S 'substituirá esta función, facendo que os números de secuencia orixinal sexan saídos.
Na 6ª liña, rtsg envía csam 19 bytes de datos (bytes de 2 a 20 na rtsg -> csam lado da conversa). A marca PUSH está configurada no paquete. Na 7ª liña, csam di que recibiu datos enviados por rtsg ata pero non incluíu o byte 21. A maioría destes datos aparentemente está sentado no buffer de socket xa que a ventá de recepción de csam obtivo 19 bytes máis pequenos. Csam tamén envía un byte de datos a rtsg neste paquete. Nas liñas 8 e 9, csam envía dous bytes de datos urxentes e empuxados a rtsg.
Se a captura de pantalla era o suficientemente pequena que o tcpdump non capturou o cabeceiro TCP completo, interpreta a maior parte do encabezado como pode e despois informa `` [| tcp ] '' para indicar que o resto non podería ser interpretado. Se o encabezado contén unha opción falsa (unha cunha lonxitude que é demasiado pequena ou máis alá do final do encabezado), tcpdump informa como " malo " e non interpreta ningunha outra opción (xa que é imposible dicir onde comezan). Se a lonxitude do cabeceiro indica que as opcións están presentes, pero a lonxitude do datagrama IP non é suficiente para que as opcións estean aí mesmo, tcpdump informa como `` [ mala duración hdr ] ''.
Capturar paquetes TCP con combinacións de bandeiras específicas (SYN-ACK, URG-ACK, etc.)
Hai 8 bits na sección de bits de control do cabeceira TCP:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
Supoñamos que queremos ver paquetes utilizados para establecer unha conexión TCP. Lembre que o TCP usa un protocolo de axuste de man de 3 direccións cando inicializa unha nova conexión; a secuencia de conexión con respecto aos bits de control TCP é
1) A chamada envía SYN
2) O destinatario responde con SYN, ACK
3) A chamada envía ACK
Agora estamos interesados en capturar paquetes que só teñen o conxunto de bit SYN (Paso 1). Teña en conta que non queremos paquetes do paso 2 (SYN-ACK), só un SYN inicial sinxelo. O que necesitamos é unha expresión de filtro correcta para tcpdump .
Lembre a estrutura dun cabeceiro TCP sen opcións:
0 15 31 ----------------------------------------------- ------------------ | porto fonte | porto de destino | -------------------------------------------------- --------------- | número de secuencia | -------------------------------------------------- --------------- | número de confirmación | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | tamaño da fiestra | -------------------------------------------------- --------------- | Comprobación TCP | punteiro urxente | -------------------------------------------------- ---------------Un encabezado TCP xeralmente ten 20 octetos de datos, a menos que as opcións estean presentes. A primeira liña do gráfico contén octetos 0 - 3, a segunda liña mostra octetos 4 - 7, etc.
Comezando a contar con 0, os bits de control TCP relevantes están contidos no octeto 13:
0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | tamaño da fiestra | ---------------- | --------------- | --------------- | - --------------- | | 13 octeto | | |Tire unha ollada máis atenta ao octeto n. 13:
| | | --------------- | | C | E | U | A | P | R | S | F | | --------------- | 7 5 3 0 |Estes son os bits de control TCP nos que nos interesa. Numerábamos os bits deste octeto de 0 a 7, de xeito recto a esquerda, polo que o bit de PSH é o bit número 3, mentres que o bit de urg é o número 5.
Lembre que queremos capturar paquetes con só set SYN. Vexamos o que ocorre co octeto 13 se un datagrama TCP chega co bit SYN definido no seu cabeceiro:
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 0 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |Mirando a sección de bit de control vemos que só se define o número de bit 1 (SYN).
Supoñendo que o octeto número 13 é un enteiro sen signo de 8 bits en orde de bytes de rede, o valor binario deste octeto é
00000010
ea súa representación decimal é
7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2Xa estamos case terminados, porque agora sabemos que, se SYN só está configurado, o valor do 13 º byte no encabezado TCP, cando se interpreta como un enteiro de 8 bits non asinado en orde de bytes de rede, debe ser exactamente 2.
Esta relación pódese expresar como
tcp [13] == 2
Podemos usar esta expresión como filtro para tcpdump para ver paquetes que só teñen SYN definido:
tcpdump -i xl0 tcp [13] == 2
A expresión di "deixar que o octeto 13 dun datagrama TCP teña o valor decimal 2", que é exactamente o que queremos.
Agora, supoñamos que necesitamos capturar paquetes SYN, pero non nos importa se ACK ou calquera outro bit de control TCP está establecido ao mesmo tempo. Vexamos o que ocorre co octeto 13 cando chega un datagrama TCP co conxunto 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 |Agora os bits 1 e 4 establécense no octeto 13. O valor binario do octeto 13 é
00010010
que se traduce 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 = 18Agora non podemos simplemente usar 'tcp [13] == 18' na expresión de filtro tcpdump , porque só seleccionarían aqueles paquetes que teñen SYN-ACK definidos, pero non aqueles con só SYN. Lembre que non nos importa se ACK ou calquera outro bit de control estea definido sempre que se configure SYN.
Para acadar o noso obxectivo, necesitamos lóxica E o valor binario do octeto 13 con algún outro valor para preservar o bit SYN. Sabemos que queremos que se estableza SYN en calquera caso, polo que lógicamente E o valor no octeto 13 co valor binario dun SYN:
00010010 SYN-ACK 00000010 SYN E 00000010 (queremos SYN) E 00000010 (queremos SYN) -------- -------- = 00000010 = 00000010Vemos que esta operación AND ofrece o mesmo resultado sen importar se ACK ou outro bit de control TCP está configurado. A representación decimal do valor AND así como o resultado desta operación é 2 (binario 00000010), polo que sabemos que para os paquetes con SYN, a seguinte relación debe ser verdadeira:
((valor do octeto 13) E (2)) == (2)
Isto indícanos a expresión do filtro tcpdump
tcpdump -i xl0 'tcp [13] & 2 == 2'
Teña en conta que debe usar comiñas simples ou unha barra invertida na expresión para ocultar o carácter especial AND ('&') do shell.
Paquetes UDP
O formato UDP ilustra este paquete rwho:
actinide.who> broadcast.who: udp 84Isto di que o porto que no host actinide enviou un datagrama udp ao porto que na transmisión do servidor, o enderezo de transmisión de internet. O paquete contiña 84 bytes de datos do usuario.
Algúns servizos UDP son recoñecidos (desde o número de porto de orixe ou destino) e a información de protocolo de nivel superior impreso. En particular, as solicitudes de servizo de nome de dominio (RFC-1034/1035) e as chamadas de Sun RPC (RFC-1050) a NFS.
Solicitudes de servidor de nome UDP
(Nota: A seguinte descrición supón familiaridade co protocolo de servizo de dominio descrito no RFC-1035. Se non está familiarizado co protocolo, a seguinte descrición aparecerá en grego.)
As solicitudes de servidor de nomes están formateadas como
src> dst: id op? bandeiras tipo qclass nome (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)O servidor h2opolo preguntou ao servidor de dominio sobre helios para un rexistro de enderezo (qtype = A) asociado co nome ucbvax.berkeley.edu. O identificador de consulta foi "3". O `+ 'indica a marca de recurso desexada . A lonxitude da consulta era de 37 bytes, sen incluír os encabezados do protocolo UDP e IP. A operación de consulta era a normal, Query , polo que se omitía o campo op. Se o op fora outra cousa, imprimiríase entre o `3 'eo` +'. Do mesmo xeito, a clase QCLASS era normal, C_IN e omitida. Calquera outra clase sería impresa inmediatamente despois do `A '.
Observáronse algunhas anomalías e pode provocar campos adicionais entre parénteses: Se unha consulta contén unha resposta, os rexistros de autoridade ou a sección de rexistros adicionais, ancount , nscount ou arcount imprímense como '[ n a]', `[ n n ] 'ou `[ n au]' onde n é o reconto apropiado. Se algún dos bits de resposta están axustados (AA, RA ou rcode) ou calquera dos bits 'debe ser cero' están axustados en bytes dous e tres, `[b2 & 3 = x ] 'está impreso, onde x é o valor hexadecimal de bytes de cabeceira dous e tres.
Respostas do servidor de nome UDP
As respostas do servidor de nomes están formateadas como
src> dst: id op rcode flags a / n / au tipo de datos de tipo (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)No primeiro exemplo, os helios responden ao ID de consulta 3 de h2opolo con 3 rexistros de resposta, 3 rexistros de servidor de nomes e 7 rexistros adicionais. O primeiro rexistro de resposta é tipo A (enderezo) e os seus datos son o enderezo de internet 128.32.137.3. O tamaño total da resposta foi de 273 bytes, excluíndo cabeceiras UDP e IP. O código op (Query) e de resposta (NoError) omitíronse, así como a clase (C_IN) do rexistro A.
No segundo exemplo, os helios responden á consulta 2 cun código de resposta de dominio inexistente (NXDomain) sen respostas, un servidor de nome e ningún rexistro de autoridade. O `* 'indica que o bit de resposta autorizada foi definido. Xa que non houbo respostas, non se imprimiron ningún tipo, clase ou datos.
Outros caracteres de bandeira que poidan aparecer son `- '(recursión dispoñible, RA, non establecida) e` |' (mensaxe truncada, TC, conxunto). Se a sección `cuestión 'non contén exactamente unha entrada,` [ n q]' está impreso.
Teña en conta que as solicitudes e respostas de servidor de nomes tenden a ser grandes e que o byte predeterminado de 68 bytes pode non capturar o suficiente do paquete para imprimir. Utilice a bandeira -s para aumentar o snaplen se precisa investigar seriamente o tráfico do servidor de nomes. ` -s 128 'funcionou ben para min.
Descodificación SMB / CIFS
tcpdump agora inclúe unha decodificación SMB / CIFS / NBT bastante extensa para os datos de UDP / 137, UDP / 138 e TCP / 139. Tamén se realiza algunha descodificación primitiva dos datos de IPX e NetBEUI SMB.
De xeito predeterminado realízase unha descodificación bastante mínima, cunha decodificación moito máis detallada feita se -v é usado. Teña en conta que, con -que o único paquete SMB pode ocupar unha páxina ou máis, só use -v se realmente quere todos os detalles gory.
Se está decodificando as sesións de SMB que conteñen cadeas unicode entón é posible que desexe establecer a variábel de ambiente USE_UNICODE a 1. Sería benvido un parche para detectar automáticamente os sinais unicode.
Para obter información sobre os formatos de paquetes SMB e o que todos os campos significan, consulte www.cifs.org ou o directorio / samba / specs / do seu sitio favorito de miras samba.org. Os parches de SMB foron escritos por Andrew Tridgell (tridge@samba.org).
Solicitudes e respostas de NFS
As solicitudes e respostas de Sun NFS (Network File System) imprímense como:
src.xid> dst.nfs: len op args src.nfs> dst.xid: resposta stat len op resultados sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709: resposta ok 40 readlink "../var" sushi.201b> wrl.nfs: 144 busca fh 9,74 / 4096.6878 "xcolors" wrl.nfs> sushi.201b: resposta ok 128 busca fh 9,74 / 4134.3150Na primeira liña, o servidor sushi envía unha transacción con id 6709 para wrl (observe que o número seguinte ao servidor src é unha identificación de transacción e non o porto fonte). A solicitude foi de 112 bytes, excluíndo os encabezados UDP e IP. A operación foi unha ligazón de lectura (ligazón simbólica de lectura) no identificador de ficheiro ( fh ) 21,24 / 10.731657119. (Se ten sorte, como neste caso, o identificador de ficheiro pode interpretarse como un par de números de dispositivo maior e menor, seguido do número de inode e o número de xeración.) Wrl responde "ok" cos contidos da ligazón.
Na terceira liña, o sushi pide a wrl que busque o nome ` xcolors 'no ficheiro de directorio 9,74 / 4096.6878. Teña en conta que os datos impresos dependen do tipo de operación. O formato pretende ser auto-explicativo se se le en conxunto con unha especificación do protocolo NFS.
Se a bandeira -v (verbose) está dada, imprímese información adicional. Por exemplo:
sushi.1372a> wrl.nfs: 148 ler fh 21,11 / 12.195 8192 bytes @ 24576 wrl.nfs> sushi.1372a: resposta ok 1472 ler REG 100664 ids 417/0 sz 29388(-v tamén imprime os campos de encabezado de IP TTL, ID, lonxitude e fragmentación, que se omitiron deste exemplo.) Na primeira liña, o sushi pregunta a wrl para ler 8192 bytes do ficheiro 21,11 / 12.195, en offset 24576. Wrl responde 'ok'; o paquete que se mostra na segunda liña é o primeiro fragmento da resposta e, polo tanto, só ten 1472 bytes de lonxitude (os outros bytes seguirán nos fragmentos seguintes, pero estes fragmentos non teñen encabezados NFS nin UDP e polo tanto non se poden imprimir, dependendo da expresión de filtro usada). Porque a bandeira -v é dada, algúns dos atributos do ficheiro (que se devolven ademais dos datos do ficheiro) están impresos: o tipo de ficheiro (`` REG '', para o ficheiro normal), o modo de ficheiro (en octal), o uid e gid, eo tamaño do ficheiro.
Se a marca -v é dada máis dunha vez, aínda se imprimen máis detalles.
Teña en conta que as solicitudes NFS son moi grandes e gran parte dos detalles non se imprimirán a non ser que se incremente o snaplen . Tenta usar ` -s 192 'para ver o tráfico NFS.
Os paquetes de resposta NFS non identifican explícitamente a operación RPC. En cambio, tcpdump fai un seguimento das solicitudes `` recentes '' e corresponde ás respostas usando a ID de transacción. Se unha resposta non segue de preto a solicitude correspondente, pode non ser parsable.
Solicitudes e respostas AFS
As solicitudes e respostas de Transarc AFS (Andrew File System) están impresas como:
src.sport> dst.dport: rx paquete tipo src.sport> dst.dport: rx servizo de tipo de paquete chamado call-name args src.sport> dst.dport: rx nome de chamada de resposta de servizo de tipo de resposta args elvis. 7001> pike.afsfs: rx data fs chamada rename old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx data fs renomear respostaNa primeira liña, o anfitrión elvis envía un paquete RX a pica. Este foi un paquete de datos RX ao servizo fs (servidor de servidor de ficheiros) e é o inicio dunha chamada RPC. A chamada RPC foi renomeada, co antigo identificador de ficheiro de directorio de 536876964/1/1 e un antigo nome de ficheiro de `.newsrc.new 'e un novo identificador de ficheiro de directorio de 536876964/1/1 e un novo nome de ficheiro de`. newsrc '. O servidor responde cunha resposta RPC á chamada de nome (que foi exitosa, porque era un paquete de datos e non un paquete de abortos).
En xeral, todos os RPCs AFS son decodificados polo menos polo nome da RPC. A maioría dos RPC AFS teñen polo menos algúns dos argumentos descodificados (polo xeral só os argumentos 'interesantes', para algunha definición de interesante).
O formato pretende ser auto-descritivo, pero probablemente non será útil para persoas que non estean familiarizadas co funcionamento de AFS e RX.
Se a bandeira -v (verbose) é dada dúas veces, os paquetes de recoñecemento e a información adicional do cabeceiro están impresos, como a ID de chamada RX, o número de chamada, o número de secuencia, o número de serie e os paquetes de paquetes RX.
Se a bandeira -v é dada dúas veces, imprímese información adicional, como a ID de chamada RX, o número de serie e os paquetes de paquetes RX. A información de negociación de MTU tamén está impreso a partir de paquetes RX ack.
Se a marca -v é dada tres veces, imprímense o índice de seguridade e o servizo.
Os códigos de erro imprímense para paquetes de abortos, con excepción dos paquetes de farelo de Ubik (porque os paquetes de abortos son usados para indicar un voto si para o protocolo Ubik).
Teña en conta que as solicitudes AFS son moi grandes e moitos dos argumentos non se imprimirán a non ser que se incremente o snaplen . Tenta usar ` -s 256 'para ver o tráfico AFS.
Os paquetes de resposta AFS non identifican explícitamente a operación RPC. En cambio, tcpdump fai un seguimento das solicitudes `` recentes '' e corresponde ás respostas usando o número de chamada eo ID de servizo. Se unha resposta non segue de preto a solicitude correspondente, pode non ser parsable.
KIP Appletalk (DDP en UDP)
Os paquetes DDP de Appletalk encapsulados en datagramas UDP son desenxelados e descargados como paquetes DDP (é dicir, descartouse toda a información do cabeceiro UDP). O ficheiro /etc/atalk.names úsase para traducir os números de netlet e node de appletalk a nomes. As liñas deste ficheiro teñen o formulario
nome de número 1.254 éter 16.1 icsd-net 1.254.110 asAs dúas primeiras liñas dan os nomes das redes de appletalk. A terceira liña fornece o nome dun servidor específico (un servidor distínguese dunha rede polo 3º octeto no número; un número neto debe ter dous octetos e un número de servidor debe ter tres octetos). O número e o nome deben estar separados por espazo en branco (espazos en branco ou separadores). O ficheiro /etc/atalk.names pode conter liñas en branco ou liñas de comentario (liñas que comezan por un `# ').
As direccións de Appletalk imprímense no formulario:
net.host.port 144.1.209.2> icsd-net.112.220 office.2> icsd-net.112.220 jssmag.149.235> icsd-net.2(Se o /etc/atalk.names non existe ou non contén unha entrada para algún host / net de appletalk, os enderezos están impresos en forma numérica.) No primeiro exemplo, NBP (porto DDP 2) na rede 144.1 o nodo 209 está enviando ao que está a escoitar no porto 220 do nodo neto icsd 112. A segunda liña é a mesma, agás que se coñece o nome completo do nodo fonte (`office '). A terceira liña é un envío desde o porto 235 no nodo 14ss de rede para emitir no porto NBP de icsd-net (observe que o enderezo de emisión (255) está indicado por un nome de rede sen número de servidor; por esta razón, é unha boa idea para manter nomes de nodos e nomes netos distintos en /etc/atalk.names).
Os paquetes de NBP (protocolo de conexión de nomes) e ATP (protocolo de transacción Appletalk) teñen os seus contidos interpretados. Outros protocolos acaban de volcar o nome do protocolo (ou número se non se rexistra ningún nome para o protocolo) e o tamaño do paquete.
Os paquetes NBP están formateados como os seguintes exemplos:
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 @ *" 186A primeira liña é unha solicitude de busca de nomes para os lectores de láser enviados polo net icsd host 112 e emitidos por net jssmag. O nbp id para a busca é 190. A segunda liña mostra unha resposta a esta solicitude (ten en conta que ten o mesmo id) do servidor jssmag.209 dicindo que ten un recurso de laserwriter chamado "RM1140" rexistrado no porto 250. O terceiro A liña é outra resposta á mesma solicitude dicindo que o servidor techpit ten o "techpit" laserwriter rexistrado no porto 186.
O formato de paquete ATP demostrouse co seguinte exemplo:
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> 0xae030002Jssmag.209 inicia a identificación da transacción 12266 con helios host solicitando ata 8 paquetes (o `<0-7> '). O número hexadecimal ao final da liña é o valor do campo `userdata 'na solicitude.
Helios responde con 8 paquetes de 512 bytes. O `: díxito 'despois da identificación de transacción dá o número de secuencia de paquetes na transacción eo número en parís é a cantidade de datos no paquete, excluíndo o encabezado atp. O `* 'no paquete 7 indica que o bit de EOM foi configurado.
Jssmag.209 entón solicita que os paquetes 3 e 5 sexan retransmitidos. Helios reenvílas entón jssmag.209 publica a transacción. Finalmente, jssmag.209 inicia a seguinte solicitude. O `* 'na solicitude indica que XO (' exactamente unha vez ') non se axustou.
Fragmentación de IP
Os datagramas de Internet fragmentados imprímense como
( ID frag : tamaño @ offset +) ( ID frag : tamaño @ compensación )(O primeiro formulario indica que hai máis fragmentos. O segundo indica que este é o último fragmento).
A ID é o ID do fragmento. O tamaño é o tamaño do fragmento (en bytes), excluíndo o cabeceiro IP. O desprazamento é o desprazamento deste fragmento (en bytes) no datagrama orixinal.
A información do fragmento sae para cada fragmento. O primeiro fragmento contén o encabezado de protocolo de nivel superior e a información de frag está impreso despois da información do protocolo. Os fragmentos despois do primeiro conteñen ningún encabezado de protocolo de nivel superior e a información de frag se imprime despois dos enderezos de orixe e destino. Por exemplo, aquí está a parte dun ftp de arizona.edu a lbl-rtsg.arpa a través dunha conexión CSNET que non parece xestionar datagramas de 576 bytes:
arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 vitoria 4096 (frag 595a: 328 @ 0 +) arizona> rtsg: (frag 595a: 204 @ 328) rtsg.1170> arizona.ftp-data:. ack 1536 gaña 2560Hai algunhas cousas que hai que ter en conta aquí: En primeiro lugar, os enderezos da segunda liña non inclúen os números de porto. Isto ocorre porque a información do protocolo TCP está todo no primeiro fragmento e non temos nin idea do número de porto ou secuencia cando imprimimos os fragmentos posteriores. En segundo lugar, a información da secuencia tcp na primeira liña está impresa como se houbese 308 bytes de datos do usuario cando, de feito, hai 512 bytes (308 no primeiro frag e 204 no segundo). Se estás buscando buracos no espazo da secuencia ou estás a facer coincidir os acks con paquetes, isto pode enganalo.
Un paquete con IP non marca o fragmento está marcado cun final (DF) .
Timestamps
Por defecto, todas as liñas de saída están precedidas por unha marca de tempo. A marca de tempo é o tempo de reloxo actual no formulario
hh: mm: ss.frace é tan preciso como o reloxo do kernel. A marca de tempo reflicte o tempo que o kernel viu por primeira vez o paquete. Non se fai ningunha tentativa de explicar o tempo de retraso entre cando a interface ethernet eliminou o paquete do fío e cando o kernel serviu a interrupción do `paquete novo '.
VER TAMÉN
tráfico (1C), nit (4P), bpf (4), pcap (3)
Importante: use o comando man ( % home ) para ver como se usa un comando na súa computadora particular.