Comando Tcpdump Linux

Ejemplos, descripción, opciones y otros detalles de Tcpdump Tcpdump es un comando utilizado en varios sistemas operativos (SO) de Linux que reúne paquetes TCP/IP que pasan a través de un adaptador de red.

Ejemplos, descripción, opciones y otros detalles de Tcpdump

Tcpdump es un comando utilizado en varios sistemas operativos (SO) de Linux que reúne paquetes TCP/IP que pasan a través de un adaptador de red. Al igual que una herramienta sniffer de paquetes, tcpdump no solo puede analizar el tráfico de red sino también guardarlo en un archivo.

A diferencia de algunos comandos que proporciona el sistema operativo de forma predeterminada, es posible que no pueda usar tcpdump porque no está instalado. Para instalar tcpdump, ejecute apt-get install tcpdump o yum install tcpdump , dependiendo de su sistema operativo.

Cómo funciona Tcpdump

Tcpdump imprime los encabezados de los paquetes en una interfaz de red que coinciden con la expresión booleana. También se puede ejecutar con el indicador -w , lo que hace que guarde los datos del paquete en un archivo para su posterior análisis, y/o con el indicador -r , que hace que lea desde un archivo de paquete guardado en lugar de leer paquetes desde una interfaz de red. En todos los casos, tcpdump solo procesará los paquetes que coincidan con expresión .

Tcpdump , si no se ejecuta con el indicador -c , continuará capturando paquetes hasta que sea interrumpido por una señal SIGINT (generada, por ejemplo, escribiendo su carácter de interrupción, generalmente Ctrl + C ) o una señal SIGTERM (generalmente generada con el comando kill (1)); si se ejecuta con el indicador -c , capturará paquetes hasta que sea interrumpido por una señal SIGINT o SIGTERM o se haya procesado el número especificado de paquetes.

Los interruptores mencionados anteriormente se explican en detalle más adelante en este artículo.

Cuando tcpdump termine de capturar paquetes, informará recuentos de:

  • Paquetes «recibidos por filtro».
    • El significado de esto depende del sistema operativo en el que esté ejecutando tcpdump , y posiblemente de la forma en que se configuró el sistema operativo. Si se especificó un filtro en la línea de comando, en algunos sistemas operativos cuenta los paquetes, independientemente de si la expresión del filtro los hizo coincidir, y en otros solo cuenta los paquetes que coincidieron con la expresión del filtro y fueron procesados ​​por tcpdump.
  • Paquetes «descartados por el núcleo».
    • Este es el número de paquetes que fueron descartados, debido a la falta de espacio en el búfer, por el mecanismo de captura de paquetes en el sistema operativo en el que se ejecuta tcpdump , si el sistema operativo informa esa información a las aplicaciones. Si no, se informará como 0.

En las plataformas que admiten la señal SIGINFO, como la mayoría de los BSD (Distribuciones de software de Berkeley), informará esos recuentos cuando reciba una señal SIGINFO (generada, por ejemplo, escribiendo su carácter de «estado», generalmente Ctrl + T ) y continuará capturando paquetes.

Compatibilidad con Tcpdump

La lectura de paquetes desde una interfaz de red con el comando tcpdump puede requerir que tenga privilegios especiales ( lectura un archivo de paquete guardado no requiere tales privilegios):

  • SunOS 3.xo 4.x con NIT o BPF : debe tener acceso de lectura a /dev/nit o dev/bpf * .
  • Solaris con DLPI : debe tener acceso de lectura/escritura al pseudo dispositivo de red, como /dev/le . Sin embargo, en al menos algunas versiones de Solaris, esto no es suficiente para permitir que tcpdump capture en modo promiscuo; en esas versiones de Solaris, debe ser root, o tcpdump debe estar instalado setuid en root, para poder capturar en modo promiscuo. Tenga en cuenta que, en muchas (tal vez todas) las interfaces, si no captura en modo promiscuo, no verá ningún paquete saliente, por lo que una captura que no se realice en modo promiscuo puede no ser muy útil.
  • HP-UX con DLPI : debe ser root o tcpdump debe estar instalado setuid en root.
  • IRIX con snoop : debe ser root o tcpdump debe estar instalado setuid en root.
  • Linux : debe ser root o tcpdump debe estar instalado setuid en root.
  • Ultrix y UNIX Digital/Tru64 UNIX : cualquier usuario puede capturar el tráfico de red con tcpdump . Sin embargo, ningún usuario (ni siquiera el superusuario) puede capturar en modo promiscuo en una interfaz a menos que el superusuario haya habilitado la operación en modo promiscuo en esa interfaz utilizando pfconfig (8), y ningún usuario (ni siquiera el superusuario) puede capturar el tráfico de unidifusión recibido o enviado por la máquina en una interfaz a menos que el superusuario haya habilitado la operación de copiar todo el modo en esa interfaz usando pfconfig , entonces < La captura de paquetes em> útil en una interfaz probablemente requiera que el modo promiscuo o la operación de copiar todo el modo, o ambos modos de operación, estén habilitados en esa interfaz.
  • BSD : debe tener acceso de lectura a /dev/bpf * .

Sintaxis del comando Tcpdump

Como todos los comandos de la computadora, el comando tcpdump funciona correctamente solo si la sintaxis es correcta:

tcpdump [ -adeflnNOpqRStuvxX ] [ -c cuenta ]

[ -C tamaño_archivo ] [ -F archivo ]

[ -i interfaz ] [ -m módulo ] [ -r archivo ]

[ -s snaplen ] [ -T tipo ] [ -U usuario ] [ -w archivo ]

[ -E algo: secreto ] [ expresión ]

Opciones de comando Tcpdump

Estas son todas las opciones que puede usar con el comando tcpdump:

  • -a : intente convertir la red y difundir direcciones a nombres.
  • -c : salga después de recibir los paquetes count .
  • -C : antes de escribir un paquete sin procesar en un archivo guardado, verifique si el archivo es actualmente mayor que file_size y, de ser así, cierre el archivo guardado actual y abra uno nuevo. Los archivos guardados después del primer archivo guardado tendrán el nombre especificado con la bandera -w , con un número después, comenzando en 2 y continuando hacia arriba. Las unidades de file_size son millones de bytes (1,000,000 bytes, no 1,048,576 bytes).
  • -d : volcar el código compilado de coincidencia de paquetes en una forma legible para humanos a la salida estándar y detener.
  • -dd : volcar el código de coincidencia de paquetes como un fragmento de programa C .
  • -ddd : volcar el código de coincidencia de paquetes como números decimales (precedido de un recuento).
  • -e : imprima el encabezado de nivel de enlace en cada línea de volcado.
  • -E : use algo: secret para descifrar los paquetes ESP IPsec. Los algoritmos pueden ser des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc o ninguno . El valor predeterminado es des-cbc . La capacidad de descifrar paquetes solo está presente si tcpdump se compiló con la criptografía habilitada. «secreto» es el texto ASCII para la clave «secreta» ESP. La opción supone RFC2406 ESP, no RFC1827 ESP. La opción es solo para fines de depuración, y se desaconseja el uso de esta opción con una verdadera clave «secreta». Al presentar la clave «secreta» de IPsec en la línea de comandos, la hace visible para otros, a través de ps (1) y otras ocasiones.
  • -f : Imprima direcciones de Internet «extranjeras» numéricamente en lugar de simbólicamente (esta opción está diseñada para evitar fallas en el servidor yp de Sun, por lo general se cuelga mientras se traducen números de internet no locales).
  • -F : utilice archivo como entrada para la expresión de filtro. Se ignora una expresión adicional dada en la línea de comando.
  • -i : escuche en la interfaz . Si no se especifica, tcpdump busca en la lista de la interfaz del sistema la interfaz configurada con el número más bajo (excluyendo el bucle invertido). Los empates se rompen al elegir el primer partido. En sistemas Linux con núcleos 2.2 o posteriores, se puede utilizar un argumento de interfaz de «any» para capturar paquetes de todas las interfaces. Tenga en cuenta que las capturas en el dispositivo «any» no se realizarán de manera promiscua modo.
  • -l : crea una línea estándar almacenada en búfer. Útil si desea ver los datos mientras los captura. Por ejemplo, «tcpdump -l | tee dat » o» tcpdump -l> dat & tail -f dat ».
  • -m : cargue las definiciones del módulo SMI MIB del archivo module . Esta opción se puede usar varias veces para cargar varios módulos MIB en tcpdump .
  • -n : no convierta las direcciones de host en nombres. Esto se puede usar para evitar búsquedas de DNS.
  • -nn : tampoco convierta los números de protocolo y puerto, etc. a nombres.
  • -N : no imprima la calificación del nombre de dominio de los nombres de host. Por ejemplo, si le da esta bandera, entonces tcpdump imprimirá «nic» en lugar de «nic.ddn.mil».
  • -O : no ejecute el optimizador de código de coincidencia de paquetes. Esto es útil solo si sospecha que hay un error en el optimizador.
  • -p : No pone la interfaz en modo promiscuo. Tenga en cuenta que la interfaz puede estar en modo promiscuo por alguna otra razón; por lo tanto, «-p» no puede usarse como una abreviatura para «ether host {local-hw-addr} o ether broadcast».
  • -q : Salida rápida (silenciosa). Imprima menos información de protocolo para que las líneas de salida sean más cortas.
  • -R : suponga que los paquetes ESP/AH se basan en la especificación anterior: RFC1825 a RFC1829.Si se especifica, tcpdump no imprimirá el campo de prevención de reproducción. Como no hay un campo de versión de protocolo en la especificación ESP/AH, tcpdump no puede deducir la versión del protocolo ESP/AH.
  • -r : lea los paquetes del archivo (que se creó con la opción -w). La entrada estándar se usa si archivo es «-«.
  • -S : imprime números de secuencia TCP absolutos, en lugar de relativos.
  • -s : Snarf snaplen bytes de datos de cada paquete en lugar del valor predeterminado de 68; con el NIT de SunOS, el mínimo es en realidad 96. Sesenta y ocho bytes son adecuados para IP, ICMP, TCP y UDP, pero pueden truncar la información del protocolo del servidor de nombres y los paquetes NFS (ver más abajo). Los paquetes truncados debido a una instantánea limitada se indican en la salida con «[| proto ] », donde proto es el nombre del nivel de protocolo en el que se ha producido el truncamiento Tenga en cuenta que tomar instantáneas más grandes aumenta la cantidad de tiempo que lleva procesar los paquetes y, efectivamente, disminuye la cantidad de almacenamiento en búfer de paquetes. Esto puede hacer que los paquetes se pierdan. Debe limitar snaplen al más pequeño número que capturará la información del protocolo que le interesa. Establecer snaplen en 0 significa usar la longitud requerida para capturar paquetes completos.
  • -T : obliga a los paquetes seleccionados por « expresión » a interpretarse en el tipo especificado. Los tipos conocidos actualmente son cnfp (protocolo Cisco NetFlow), rpc (llamada a procedimiento remoto), rtp (protocolo de aplicaciones en tiempo real), rtcp (Protocolo de control de aplicaciones en tiempo real), snmp (Protocolo simple de administración de red), iva (Herramienta de audio visual) y wb (tablero blanco distribuido).
  • -t : No imprime una marca de tiempo en cada línea de volcado.
  • -tt : imprime una marca de tiempo sin formato en cada línea de volcado.
  • -U : quita los privilegios de root y cambia la ID de usuario a user y la ID de grupo al grupo primario de user .
  • Nota : Red Hat Linux elimina automáticamente los privilegios del usuario «pcap» si no se especifica nada más.
  • -ttt : imprime un delta (en microsegundos) entre la línea actual y la anterior en cada línea de volcado.
  • -tttt : imprime una marca de tiempo en el formato predeterminado, seguido de la fecha en cada línea de volcado.
  • -u : imprime identificadores NFS sin codificar.
  • -v : (Ligeramente más) salida detallada. Por ejemplo, se imprimen el tiempo de vida, la identificación, la longitud total y las opciones en un paquete IP. También permite verificaciones adicionales de integridad de paquetes, como verificar la suma de comprobación del encabezado IP e ICMP.
  • -vv : salida aún más detallada. Por ejemplo, se imprimen campos adicionales a partir de paquetes de respuesta NFS y los paquetes SMB están completamente decodificados.
  • -vvv : salida aún más detallada. Por ejemplo, las opciones SB SE de telnet se imprimen en su totalidad. Con -X las opciones de telnet también se imprimen en hexadecimal.
  • -w : escriba los paquetes sin formato en el archivo en lugar de analizarlos e imprimirlos. Posteriormente se pueden imprimir con la opción -r. La salida estándar se usa si el archivo es «-«.
  • -x : imprime cada paquete (menos su encabezado de nivel de enlace) en hexadecimal. Se imprimirá el más pequeño de todo el paquete o snaplen bytes. Tenga en cuenta que este es el paquete completo de capa de enlace, por lo que para las capas de enlace que rellenan (por ejemplo, Ethernet), los bytes de relleno también se imprimirán cuando el paquete de capa superior sea más corto que el relleno requerido.
  • -X : al imprimir en hexadecimal, imprima también ASCII. Por lo tanto, si también se establece -x , el paquete se imprime en hexadecimal/ASCII. Esto es muy útil para analizar nuevos protocolos. Incluso si -x no está configurado también, algunas partes de algunos paquetes pueden imprimirse en hexadecimal/ASCII.
  • expresión : selecciona qué paquetes se volcarán. Si no se da ninguna expresión , todos los paquetes en la red serán volcados. De lo contrario, solo se volcarán los paquetes para los que expresión sea ‘verdadero’. La expresión consiste en una o más primitivas . Las primitivas generalmente consisten en un id (nombre o número) precedido por uno o más calificadores. Hay tres tipos diferentes de calificador:
  • tipo : los calificadores dicen a qué tipo de cosas se refiere el nombre o número de identificación. Los tipos posibles son host , net y port , por ejemplo, ‘host foo’, ‘net 128.3’, ‘port 20’. Si no hay calificador de tipo, se supone host .
  • dir : los calificadores especifican una dirección de transferencia particular hacia y/o desde id .Las direcciones posibles son src , dst , src o dst y src y dst ( por ejemplo, ‘src foo’, ‘dst net 128.3’, ‘src or dst port ftp-data’). Si no hay un calificador dir, se supone src o dst . Para las capas de enlace ‘nulo’ (es decir, protocolos punto a punto como deslizamiento), los calificadores entrantes y salientes se pueden usar para especificar la dirección deseada.
  • proto : los calificadores restringen la coincidencia a un protocolo particular. Los protos posibles son: éter , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp y udp , por ejemplo, ‘ether src foo ‘,’ arp net 128.3 ‘,’ tcp port 21 ‘. Si no hay un protocalificador, se suponen todos los protocolos consistentes con el tipo. Por ejemplo, ‘src foo’ significa ‘(ip o arp o rarp) src foo’ (excepto que este último no es una sintaxis legal), ‘net bar’ significa ‘(ip o arp o rarp) net bar’ y ‘port 53’ significa ‘(tcp o udp) puerto 53’.
    • [‘fddi’ es en realidad un alias para ‘ether’; el analizador los trata de forma idéntica como «el nivel de enlace de datos utilizado en la interfaz de red especificada». Los encabezados FDDI contienen direcciones de origen y destino similares a Ethernet, y a menudo contienen tipos de paquetes similares a Ethernet, por lo que puede filtrar en estos campos FDDI solo Al igual que con los campos de Ethernet análogos, los encabezados FDDI también contienen otros campos, pero no puede nombrarlos explícitamente en una expresión de filtro.
    • Del mismo modo, ‘tr’ es un alias para ‘éter’; las declaraciones del párrafo anterior sobre los encabezados FDDI también se aplican a los encabezados Token Ring.]

Además de lo anterior, hay algunas palabras clave «primitivas» especiales que no siguen el patrón: gateway , broadcast , less , < fuertes> mayor y aritmética expresiones. Todos estos se describen a continuación.

Las expresiones de filtro más complejas se crean utilizando las palabras y , o y no para combinar primitivas, por ejemplo, «host foo y no puerto ftp y no puerto ftp-data «. Para guardar la escritura, se pueden omitir listas de calificadores idénticos (por ejemplo, «tcp dst port ftp o ftp-data or domain» es exactamente lo mismo que «tcp dst port ftp o tcp dst port ftp-data o tcp dst port domain»).

Estas son las primitivas permitidas con el comando tcpdump:

  • host dst host
    • Verdadero si el campo de destino IPv4/v6 del paquete es host , que puede ser una dirección o un nombre.
  • host src host
    • Verdadero si el campo de origen IPv4/v6 del paquete es host .
  • host host
    • Verdadero si el origen o el destino de IPv4/v6 del paquete es host . Cualquiera de las expresiones de host anteriores se puede anteponer con las palabras clave, ip , arp , rarp o ip6 , como en ip host host (que es equivalente a ether proto \ ip y host host).
    • Si host es un nombre con varias direcciones IP, se verificará que cada dirección coincida.
  • ether dst ehost
    • Verdadero si la dirección de destino de Ethernet es ehost . Ehost puede ser un nombre de/etc/ethers o un número (consulte ethers (3N) para ver el formato numérico).
  • ether src ehost
    • Verdadero si la dirección de origen de Ethernet es ehost .
  • host de éter ehost
    • Verdadero si la dirección de origen o destino de Ethernet es ehost .
  • puerta de enlace host
    • Verdadero si el paquete usaba host como puerta de enlace (es decir, la dirección de origen o destino de Ethernet era host pero ni la fuente de IP ni el destino de IP eran host ).
    • Host debe ser un nombre y debe encontrarse tanto en los mecanismos de resolución de nombre de host a dirección IP de la máquina (archivo de nombre de host, DNS, NIS, etc.) como en el nombre de host de la máquina -mecanismo de resolución de dirección Ethernet (/ etc/ethers, etc.).
    • Una expresión equivalente es host host ehost y ahora host host , que puede usarse con nombres o números para host/ehost .) Esta sintaxis no funciona en la configuración habilitada para IPv6 en este momento.
  • dst net net
    • Verdadero si la dirección de destino IPv4/v6 del paquete tiene un número de red de net . Net puede ser un nombre de/etc/networks o un número de red (consulte redes (4) para más detalles).
  • src net net
    • Verdadero si la dirección de origen IPv4/v6 del paquete tiene un número de red de net .
  • net net
    • Verdadero si la dirección de origen o destino IPv4/v6 del paquete tiene un número de red de net .
  • net net mask netmask
    • Verdadero si la dirección IP coincide con net con la netmask específica. Puede estar calificado con src o dst . Tenga en cuenta que esta sintaxis no es válida para IPv6 net .
  • net net/len
    • Verdadero si la dirección IPv4/v6 coincide con net con una máscara de red len bits de ancho. Puede estar calificado con src o dst .
  • puerto dst port
    • Verdadero si el paquete es ip/tcp, ip/udp, ip6/tcp o ip6/udp y tiene un valor de puerto de destino de puerto . El puerto puede ser un número o un nombre utilizado en/etc/services (consulte tcp (4P) y udp (4P)). Si se usa un nombre, se verifican tanto el número de puerto como el protocolo. Si se utiliza un número o un nombre ambiguo, solo se verifica el número de puerto (por ejemplo, dst port 513 imprimirá tcp/login traffic y udp/who traffic, y port domain Imprimirá tcp/domain y udp/domain traffic).
  • puerto src port
    • Verdadero si el paquete tiene un valor de puerto de origen de puerto .
  • puerto port
    • Verdadero si el puerto de origen o de destino del paquete es port . Cualquiera de las expresiones de puerto anteriores se puede anteponer con las palabras clave, tcp o udp , como en tcp src port port , que solo coincide con los paquetes tcp cuyo puerto de origen es port .
  • menos longitud
    • Verdadero si el paquete tiene una longitud menor o igual a longitud . Esto es equivalente a len <= Longitud .
  • mayor longitud
    • Verdadero si el paquete tiene una longitud mayor o igual a longitud . Esto es equivalente a len> = Longitud .
  • ip proto protocol
    • Verdadero si el paquete es un paquete IP (consulte ip (4P)) del tipo de protocolo protocolo . Protocolo puede ser un número o uno de los nombres icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp o tcp . Tenga en cuenta que los identificadores tcp , udp y icmp también son palabras clave y deben escaparse mediante la barra invertida (\), que está \\ en el C-shell. Tenga en cuenta que esta primitiva no persigue la cadena de encabezado del protocolo.
  • ip6 proto protocol
    • Verdadero si el paquete es un paquete IPv6 del tipo de protocolo protocolo . Tenga en cuenta que esta primitiva no persigue la cadena de encabezado del protocolo.
  • ip6 protochain protocol
    • Verdadero si el paquete es un paquete IPv6 y contiene un encabezado de protocolo con el tipo protocol en su cadena de encabezado de protocolo. Por ejemplo, ipv6 protochain 6 coincide con cualquier paquete IPv6 con el encabezado del protocolo TCP en la cadena del encabezado del protocolo. El paquete puede contener, por ejemplo, encabezado de autenticación, encabezado de enrutamiento o encabezado de opción salto por salto, entre el encabezado IPv6 y el encabezado TCP. El código BPF emitido por esta primitiva es complejo y no puede ser optimizado por el código optimizador BPF en tcpdump , por lo que esto puede ser algo lento.
  • protochain de ip protocol
    • Equivalente a ip6 protochain protocolo , pero esto es para IPv4.
  • transmisión de éter
    • Verdadero si el paquete es un paquete de difusión de Ethernet. La palabra clave ether es opcional.
  • transmisión ip
    • Verdadero si el paquete es un paquete de difusión IP. Comprueba las convenciones de difusión de todos ceros y todos y busca la máscara de subred local.
  • multidifusión de éter
    • Verdadero si el paquete es un paquete de multidifusión Ethernet. La palabra clave ether es opcional. Esta es la abreviatura de ‘ ether [0] & 1! = 0 ‘.
  • IP multicast
    • Verdadero si el paquete es un paquete de multidifusión IP.
  • multidifusión ip6
    • Verdadero si el paquete es un paquete de multidifusión IPv6.
  • éter proto protocol
    • Verdadero si el paquete es de tipo ethernet protocolo . Protocolo puede ser un número o uno de los nombres ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx o netbeui . Tenga en cuenta que estos identificadores también son palabras clave y deben escaparse mediante una barra diagonal inversa (\).
    • [En el caso de FDDI (por ejemplo, ‘ fddi protocol arp ‘) y Token Ring (por ejemplo, ‘ tr protocol arp ‘), para la mayoría de esos protocolos, el protocolo la identificación proviene del encabezado 802.2 Logical Link Control (LLC), que generalmente está en capas sobre el encabezado FDDI o Token Ring.
    • Al filtrar la mayoría de los identificadores de protocolo en FDDI o Token Ring, tcpdump verifica solo el campo de ID de protocolo de un encabezado LLC en el denominado formato SNAP con un Identificador de unidad organizativa (OUI) de 0x000000, para Ethernet encapsulado ; no comprueba si el paquete está en formato SNAP con una OUI de 0x000000.
    • Las excepciones son iso , para lo cual verifica los campos DSAP (Punto de acceso al servicio de destino) y SSAP (Punto de acceso al servicio de origen) del encabezado LLC, stp y netbeui , donde comprueba el DSAP del encabezado LLC, y atalk , donde comprueba un paquete de formato SNAP con un OUI de 0x080007 y el tipo Appletalk.
    • En el caso de Ethernet, tcpdump comprueba el campo de tipo de Ethernet para la mayoría de esos protocolos; las excepciones son iso , sap y netbeui , para las cuales verifica si hay un marco 802.3 y luego verifica el encabezado LLC como lo hace para FDDI y Token Ring; atalk , donde verifica tanto el tipo Appletalk en una trama Ethernet como un paquete de formato SNAP como lo hace para FDDI y Token Ring; aarp , donde comprueba el tipo ARP de Appletalk en una trama Ethernet o una trama SNAP 802.2 con un OUI de 0x000000; e ipx , donde verifica el tipo de IPX en un marco Ethernet, el IPX DSAP en el encabezado LLC, el 802.3 sin encapsulación de encabezado LLC de IPX y el tipo IPX en un marco SNAP.]
  • decnet src host
    • Verdadero si la dirección de origen de DECNET es host , que puede ser una dirección con el formato «10.123 » o un nombre de host de DECNET. [El soporte de nombre de host de DECNET solo está disponible en sistemas Ultrix que están configurados para ejecutar DECNET.]
  • decnet dst host
    • Verdadero si la dirección de destino de DECNET es host .
  • host de decnet host
    • Verdadero si la dirección de origen o destino de DECNET es host .
  • ip , ip6 , arp , rarp , atalk , aarp , decnet , iso , stp , ipx , netbeui
    • Abreviaturas de ether proto p donde p es uno de los protocolos anteriores.
  • lat , moprc , mopdl
    • Abreviaturas de ether proto p donde p es uno de los protocolos anteriores. Tenga en cuenta que tcpdump actualmente no sabe cómo analizar estos protocolos.
  • vlan [vlan_idfont>
    • Verdadero si el paquete es un paquete VLAN IEEE 802.1Q. Si se especifica [vlan_id] , solo es verdadero si el paquete tiene el vlan_id especificado. Tenga en cuenta que la primera palabra clave vlan encontrada en expresión cambia las compensaciones de decodificación para el resto de expresión en el supuesto de que el paquete es un paquete VLAN.
  • tcp , udp , icmp
    • Abreviaturas de ip proto p o ip6 proto p donde p es uno de los protocolos anteriores.
  • iso proto protocol
    • Verdadero si el paquete es un paquete OSI de tipo de protocolo protocolo . Protocolo puede ser un número o uno de los nombres clnp , esis o isis .
  • clnp , esis , isis
    • Abreviaturas de iso proto p donde p es uno de los protocolos anteriores. Tenga en cuenta que tcpdump realiza un trabajo incompleto al analizar estos protocolos.
  • expr relop expr
    • Verdadero si la relación se mantiene, donde relop es uno de>, =, <=, =,! = Y expr es una expresión aritmética compuesta de constantes enteras (expresada en sintaxis estándar C), los operadores binarios normales [+, -, *, /, &, |], un operador de longitud y accesores especiales de datos por paquetes.Para acceder a los datos dentro del paquete, use la siguiente sintaxis: proto [expr: size] .

Proto es uno de éter , fddi , tr , ppp , deslizamiento , enlace , ip , arp , rarp , tcp , udp , icmp o ip6 , e indica la capa de protocolo para la operación de índice ( ether , fddi , tr , ppp , slip y link se refieren a la capa de enlace) . Tenga en cuenta que tcp, udp y otros tipos de protocolos de capa superior solo se aplican a IPv4, no a IPv6. El desplazamiento de bytes, en relación con la capa de protocolo indicada, viene dado por expr . Tamaño es opcional e indica el número de bytes en el campo de interés; puede ser uno, dos o cuatro, y el valor predeterminado es uno. El operador de longitud, indicado por la palabra clave len , proporciona la longitud del paquete.

Por ejemplo, ‘ ether [0] & 1! = 0 ‘ captura todo el tráfico de multidifusión. La expresión ‘ ip [0] & 0xf! = 5 ‘ captura todos los paquetes IP con opciones. La expresión ‘ ip [6: 2] & 0x1fff = 0 ‘ solo captura datagramas no fragmentados y frag zero de datagramas fragmentados. Esta verificación se aplica implícitamente a las operaciones de índice tcp y udp . Por ejemplo, tcp [0] siempre significa el primer byte del encabezado TCP , y nunca significa el primer byte de un fragmento intermedio.

Algunos desplazamientos y valores de campo pueden expresarse como nombres en lugar de como valores numéricos. Los siguientes desplazamientos de campo de encabezado de protocolo están disponibles: icmptype (campo de tipo ICMP), icmpcode (campo de código ICMP) y tcpflags (campo de banderas TCP )

Los siguientes valores de campo de tipo ICMP están disponibles: icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp-redirect , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp-tstampreply , icmp-ireq , icmp-ireqreply , icmp-maskreq , icmp-maskreply .

Los siguientes valores de campo de indicadores TCP están disponibles: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .

Las primitivas se pueden combinar usando cualquiera de los siguientes:

  • Un grupo entre paréntesis de primitivas y operadores (los paréntesis son especiales para el Shell y deben escaparse)
  • Negación (‘! ‘ o ` no ‘)
  • Concatenación (‘ && ‘ o ‘ y ‘)
  • Alternancia (‘ || ‘ o ‘ o ‘)

La negación tiene mayor precedencia. La alternancia y la concatenación tienen la misma precedencia y se asocian de izquierda a derecha. Tenga en cuenta que se requieren tokens explícitos y , no yuxtaposición, para la concatenación.

Si se proporciona un identificador sin una palabra clave, se supone la palabra clave más reciente. Por ejemplo, no host vs y as es la abreviatura de no host vs y host as . Sin embargo, esto no debe confundirse con no (host vs o as) .

Los argumentos de expresión se pueden pasar a tcpdump como un argumento único o como argumentos múltiples, lo que sea más conveniente. En general, si la expresión contiene metacaracteres de Shell, es más fácil pasarla como un argumento único entre comillas. Múltiples argumentos se concatenan con espacios antes de ser analizados.

Ejemplos de Tcpdump

  tcpdump host sundown  

El comando tcpdump anterior se utiliza para imprimir todos los paquetes que llegan o salen de ocaso.

  tcpdump host helios y \ (hot or as \)  

Este ejemplo de tcpdump imprime el tráfico entre helios y hot o ace.

  tcpdump ip host as y no helios  

Puede usar este comando tcpdump para imprimir todos los paquetes IP entre ace y cualquier host, excepto helios.

  tcpdump net ucb-ether  

En el ejemplo anterior, tcpdump imprime todo el tráfico entre hosts locales y hosts en Berkeley.

  tcpdump 'gateway snup y (puerto ftp o ftp-data)'  

El siguiente ejemplo de comando tcpdump se usa para imprimir todo el tráfico FTP a través de la puerta de enlace de Internet snup .Tenga en cuenta que la expresión se cita para evitar que el shell malinterprete los paréntesis.

  tcpdump ip y no net   localnet  

En el ejemplo tcpdump anterior, el comando imprime el tráfico que no proviene ni está destinado a hosts locales.

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

Para el ejemplo anterior de tcpdump, el comando se usa para imprimir los paquetes de inicio y fin (los paquetes SYN y FIN) de cada conversación TCP que involucra un host no local.

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

El comando anterior imprimirá paquetes IP de más de 576 bytes enviados a través de la puerta de enlace snup.

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

El comando tcpdump que se muestra arriba imprime paquetes de difusión IP o multidifusión que no se enviaron a través de difusión Ethernet o multidifusión.

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

En este último ejemplo de tcpdump, el comando imprime todos los paquetes ICMP que no son solicitudes o respuestas de eco (es decir, no paquetes de ping).

Formato de salida Tcpdump

La salida de tcpdump depende del protocolo. A continuación se ofrece una breve descripción y ejemplos de la mayoría de los formatos.

Encabezados de nivel de enlace . Si se da la opción ‘-e’, se imprime el encabezado de nivel de enlace. En las redes Ethernet, se imprimen las direcciones de origen y destino, el protocolo y la longitud del paquete.

En las redes FDDI, la opción ‘-e’ hace que tcpdump imprima el campo ‘control de trama’, las direcciones de origen y destino y la longitud del paquete. (El campo ‘control de trama’ regula la interpretación del resto del paquete. Los paquetes normales (como los que contienen datagramas IP) son paquetes ‘asíncronos’, con un valor de prioridad entre 0 y 7: por ejemplo, ` async4 «. Se supone que dichos paquetes contienen un paquete de control de enlace lógico (LLC) 802.2; el encabezado LLC se imprime si es no un datagrama ISO o un paquete denominado SNAP.

En las redes Token Ring, la opción ‘-e’ hace que tcpdump imprima los campos ‘control de acceso’ y ‘control de trama’, las direcciones de origen y destino, y la longitud del paquete. Al igual que en las redes FDDI, se supone que los paquetes contienen un paquete LLC. Independientemente de si la opción ‘-e’ está especificada o no, la información de enrutamiento de origen se imprime para los paquetes enrutados de origen.

(N.B .: La siguiente descripción supone familiaridad con el algoritmo de compresión SLIP descrito en RFC-1144.)

En los enlaces SLIP, se imprime un indicador de dirección («I» para entrada, «O» para salida), tipo de paquete e información de compresión. El tipo de paquete se imprime primero. Los tres tipos son ip , utcp y ctcp . No se imprime más información de enlace para los paquetes ip . Para los paquetes TCP, el identificador de conexión se imprime siguiendo el tipo. Si el paquete está comprimido, se imprime su encabezado codificado. Los casos especiales se imprimen como *S+ n y *SA+ n , donde n es la cantidad por la cual el número de secuencia (o número de secuencia y reconocimiento) ha cambiado. Si no es un caso especial, se imprimen cero o más cambios. Un cambio se indica con U (puntero urgente), W (ventana), A (ack), S (número de secuencia) e I (ID de paquete), seguido de un delta (+ no -n), o un nuevo valor (= n) Finalmente, se imprime la cantidad de datos en el paquete y la longitud del encabezado comprimido.

Por ejemplo, la siguiente línea muestra un paquete TCP comprimido saliente, con un identificador de conexión implícito; el ack ha cambiado en 6, el número de secuencia en 49 y la ID del paquete en 6; Hay 3 bytes de datos y 6 bytes de encabezado comprimido:

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

Paquetes Arp/rarp . La salida de Arp/rarp muestra el tipo de solicitud y sus argumentos. El formato está destinado a explicarse por sí mismo. Aquí hay una pequeña muestra tomada desde el inicio de un ‘rlogin’ desde el host rtsg al host csam :

 arp who-has csam tell rtsg 
arp reply csam is-at CSAM

La primera línea dice que rtsg envió un paquete arp pidiendo la dirección Ethernet del host de Internet csam. Csam responde con su dirección Ethernet (en este ejemplo, las direcciones Ethernet están en mayúsculas y las direcciones de Internet en minúsculas).

Esto se vería menos redundante si hubiéramos hecho tcpdump -n :

 arp quien-tiene 128.3.254.6 decir 128.3.254.68 
respuesta arp 128.3.254.6 es a las 02: 07: 01: 00: 01: c4

Si hubiéramos hecho tcpdump -e , el hecho de que el primer paquete se transmite y el segundo es punto a punto sería visible:

 RTSG Broadcast 0806 64: arp who-has csam tell rtsg 
CSAM RTSG 0806 64: arp reply csam is-at CSAM

Para el primer paquete, esto dice que la dirección de origen de Ethernet es RTSG, el destino es la dirección de difusión de Ethernet, el campo de tipo contenía hexadecimal 0806 (tipo ETHER_ARP) y la longitud total fue de 64 bytes.

Paquetes TCP (NB: la siguiente descripción supone estar familiarizado con el protocolo TCP descrito en RFC-793. Si no está familiarizado con el protocolo, ni esta descripción ni tcpdump serán de mucha utilidad para usted) . El formato general de una línea de protocolo tcp es:

 src> dst: marca opciones urgentes de ventana de confirmación de datos seqno 

Src y dst son las direcciones IP y los puertos de origen y destino. Las banderas son una combinación de S (SYN), F (FIN), P (PUSH) o R (RST) o un solo ‘.’ (sin banderas) Data-seqno describe la porción del espacio de secuencia cubierto por los datos en este paquete (vea el ejemplo a continuación). Ackno es el número de secuencia de los siguientes datos esperados en la otra dirección en esta conexión. Ventana es el número de bytes de espacio de búfer de recepción disponible en la otra dirección en esta conexión. Urg indica que hay datos «urgentes» en el paquete. Las Opciones son opciones tcp encerradas entre corchetes angulares (por ejemplo,).

Src, dst, y flags siempre están presentes. Los otros campos dependen del contenido del encabezado del protocolo tcp del paquete y solo se envían si es apropiado.

Aquí está la parte de apertura de un registro desde el host rtsg al host csam .

 rtsg.1023> csam.login: S 768512: 768512 (0) win 4096 
csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 win 4096
rtsg.1023 > csam.login:. ack 1 gana 4096
rtsg.1023> csam.login: P 1: 2 (1) ack 1 gana 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 gana 4077 urg 1
csam.login> rtsg.1023: P 3: 4 (1) ack 21 gana 4077 urg 1

La primera línea dice que el puerto tcp 1023 en rtsg envió un paquete al puerto login en csam. La S indica que se configuró el indicador SYN . El número de secuencia del paquete era 768512 y no contenía datos. (La notación es ‘first: last (nbytes)’, que significa ‘números de secuencia first hasta pero sin incluir last que son nbytes bytes de datos de usuario ‘). No hubo un reconocimiento de respaldo, la ventana de recepción disponible era de 4096 bytes y había una opción de tamaño de segmento máximo que solicitaba un mss de 1024 bytes.

Csam responde con un paquete similar, excepto que incluye un reconocimiento a cuestas para SYN de rtsg. Rtsg luego confirma SYN de csam. Los ‘.’ significa que no se establecieron banderas. El paquete no contenía datos, por lo que no hay un número de secuencia de datos. Tenga en cuenta que el número de secuencia ack es un entero pequeño (1). La primera vez que tcpdump ve una ‘conversación’ tcp, imprime el número de secuencia del paquete. En los paquetes posteriores de la conversación, se imprime la diferencia entre el número de secuencia del paquete actual y este número de secuencia inicial. Esto significa que los números de secuencia después del primero pueden interpretarse como posiciones relativas de bytes en el flujo de datos de la conversación (con el primer byte de datos en cada dirección ‘1’). ‘-S’ anulará esta característica, causando la salida de los números de secuencia originales.

En la sexta línea, rtsg envía csam 19 bytes de datos (bytes 2 a 20 en el lado rtsg -> csam de la conversación). El indicador PUSH se establece en el paquete. En la séptima línea, csam dice que recibió datos enviados por rtsg hasta el byte 21, pero sin incluirlos. La mayoría de estos datos aparentemente se encuentran en el búfer de socket ya que la ventana de recepción de csam se ha reducido 19 bytes. Csam también envía un byte de datos a rtsg en este paquete. En las líneas octava y novena, csam envía dos bytes de datos urgentes y enviados a rtsg.

Si la instantánea era lo suficientemente pequeña como para que tcpdump no capturara el encabezado TCP completo, interpreta la mayor parte del encabezado posible y luego informa «[| tcp ] ‘ ‘para indicar que el resto no se pudo interpretar. Si el encabezado contiene una opción falsa (una con una longitud que es demasiado pequeña o más allá del final del encabezado), tcpdump lo informa como «[ bad opt ] » y no interpreta más opciones (ya que es imposible saber por dónde comienzan). Si la longitud del encabezado indica que las opciones están presentes pero la longitud del datagrama IP no es lo suficientemente larga como para que las opciones estén realmente allí, tcpdump lo informa como «[ longitud incorrecta de hdr ] ‘ ‘.

Capture paquetes con combinaciones de banderas particulares .Hay ocho bits en la sección de bits de control del encabezado TCP:

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

Supongamos que queremos ver los paquetes utilizados para establecer una conexión TCP. Recuerde que TCP utiliza un protocolo de enlace de tres vías cuando inicializa una nueva conexión; La secuencia de conexión con respecto a los bits de control TCP es:

  1. La persona que llama envía SYN.
  2. El destinatario responde con SYN, ACK.
  3. La persona que llama envía ACK.

Ahora estamos interesados ​​en capturar paquetes que solo tienen el conjunto de bits SYN (Paso 1). Tenga en cuenta que no queremos paquetes del paso 2 (SYN-ACK), solo un SYN inicial simple. Lo que necesitamos es una expresión de filtro correcta para tcpdump .

Recuerde la estructura de un encabezado TCP sin opciones:

 0 15 31 
---------------------------------------- -------------------------
| puerto fuente | puerto de destino |
------------------------------------------- ----------------------
| número de secuencia |
------------------------------------------- ----------------------
| número de reconocimiento |
------------------------------------------- ----------------------
| HL | rsvd | C | E | U | A | P | R | S | F | tamaño de ventana |
------------------------------------------- ----------------------
| Suma de comprobación TCP | puntero urgente |
------------------------------------------- ----------------------

Un encabezado TCP generalmente contiene 20 octetos de datos, a menos que haya opciones disponibles. La primera línea del gráfico contiene octetos 0–3, la segunda línea muestra los octetos 4–7, etc.

Comenzando a contar con 0, los bits de control TCP relevantes están contenidos en el octeto 13:

 0 7 | 15 | 23 | 31 
---------------- | --------------- | ------------ --- | ----------------
| HL | rsvd | C | E | U | A | P | R | S | F | tamaño de ventana |
---------------- | --------------- | ---------- ----- | ----------------
| El | 13o octeto | El | |

Echemos un vistazo más de cerca al octeto no. 13:

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

Estos son los bits de control TCP en los que estamos interesados. Hemos numerado los bits en este octeto de 0 a 7, de derecha a izquierda, por lo que el bit PSH es el bit número 3, mientras que el bit URG es el número 5.

Recuerde que queremos capturar paquetes con solo SYN configurado. Veamos qué sucede con el octeto 13 si llega un datagrama TCP con el bit SYN establecido en su encabezado:

 | 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 la sección de bits de control, vemos que solo se establece el bit número 1 (SYN).

Suponiendo que el octeto número 13 es un entero sin signo de 8 bits en orden de bytes de red, el valor binario de este octeto es:

00000010

Su representación decimal es:

 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

Ya casi hemos terminado, porque ahora sabemos que si solo se establece SYN, el valor del decimotercer octeto en el encabezado TCP, cuando se interpreta como un entero sin signo de 8 bits en el orden de bytes de la red, debe ser exactamente 2.

Esta relación se puede expresar como

tcp [13] == 2

Podemos usar esta expresión como filtro para tcpdump para ver paquetes que solo tienen SYN configurado:

tcpdump -i xl0 tcp [13] == 2

La expresión dice «deje que el decimotercer octeto de un datagrama TCP tenga el valor decimal 2», que es exactamente lo que queremos.

Ahora, supongamos que necesitamos capturar paquetes SYN, pero no nos importa si ACK o cualquier otro bit de control TCP está configurado al mismo tiempo. Mire lo que le sucede al octeto 13 cuando llega un datagrama TCP con SYN-ACK configurado:

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

Los bits 1 y 4 ahora están configurados en el 13er octeto. El valor binario del octeto 13 es:

00010010

que se traduce a 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

No podemos simplemente usar ‘tcp [13] == 18’ en la expresión del filtro tcpdump , porque eso seleccionaría solo aquellos paquetes que tienen establecido SYN-ACK, pero no aquellos con solo SYN establecido. Recuerde que no nos importa si ACK o cualquier otro bit de control está configurado mientras SYN esté configurado.

Para lograr nuestro objetivo, necesitamos lógicamente Y el valor binario del octeto 13 con algún otro valor para preservar el bit SYN. Sabemos que queremos que SYN se establezca en cualquier caso, por lo que lógicamente Y el valor en el 13er octeto con el valor binario de un SYN:

 00010010 SYN-ACK 00000010 SYN 
Y 00000010 (queremos SYN) Y 00000010 (queremos SYN)
-------- --------
= 00000010 = 00000010

Vemos que esta operación AND ofrece el mismo resultado independientemente de si se establece ACK u otro bit de control TCP.La representación decimal del valor AND así como el resultado de esta operación es 2 (binario 00000010), por lo que sabemos que para los paquetes con SYN establecido, la siguiente relación debe ser verdadera:

((valor del octeto 13) Y (2)) == (2)

Esto nos lleva a la expresión de filtro tcpdump

tcpdump -i xl0 ‘tcp [13] & 2 == 2’

Tenga en cuenta que debe usar comillas simples o una barra diagonal inversa en la expresión para ocultar el carácter especial AND (‘&’) del shell.

paquetes UDP. este formato rwho ilustra el formato UDP:

 actinide.who> broadcast.who: udp 84 

Esto dice que el puerto who en el host actinide envió un datagrama udp al puerto who en el host broadcast , la transmisión por Internet habla a. El paquete contenía 84 bytes de datos del usuario.

Se reconocen algunos servicios UDP (desde el número de puerto de origen o de destino) y se imprime la información del protocolo de nivel superior, en particular, las solicitudes de servicio de nombres de dominio (RFC-1034/1035) y las llamadas Sun RPC (RFC-1050) a NFS.

Solicitudes del servidor de nombres UDP (Nota: la siguiente descripción asume que está familiarizado con el protocolo del Servicio de dominio descrito en RFC-1035. Si no está familiarizado con el protocolo, la siguiente descripción tendrá poco sentido. )

Las solicitudes del servidor de nombres están formateadas como:

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

El host h2opolo solicitó al servidor de dominio en helios un registro de dirección (qtype = A) asociado con el nombre ucbvax.berkeley.edu. La consulta id era ‘3’. El ‘+’ indica que se configuró el indicador recursividad deseada . La longitud de la consulta fue de 37 bytes, sin incluir los encabezados de protocolo UDP e IP. La operación de consulta era la normal, Consulta , por lo que se omitió el campo op. Si la operación hubiera sido otra cosa, se habría impreso entre el ‘3’ y el ‘+’. Del mismo modo, la clase q era la normal, C_IN , y se omitió. Cualquier otra clase q se hubiera impreso inmediatamente después de la ‘A’.

Se verifican algunas anomalías y pueden resultar en campos adicionales encerrados entre corchetes: si una consulta contiene una respuesta, registros de autoridad o una sección de registros adicionales, ancount , nscount o arcount se imprimen como ‘[ n a]’, ‘[ n n]’ o ‘[ n au ] ‘donde n es el recuento apropiado. Si se establece alguno de los bits de respuesta (AA, RA o rcode) o cualquiera de los bits `debe ser cero ‘se establece en los bytes dos y tres, se imprime` [b2 & 3 = x ]’ , donde x es el valor hexadecimal de los bytes de encabezado dos y tres.

Respuestas del servidor de nombres UDP. Las respuestas del servidor de nombres están formateadas como:

  src> dst: id op rcode marca a/n/au tipo datos de clase (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 ejemplo, helios responde al ID de consulta 3 de h2opolo con tres registros de respuesta, tres registros de servidor de nombres y siete registros adicionales. El primer registro de respuestas es de tipo A (dirección), y sus datos son la dirección de internet 128.32.137.3. El tamaño total de la respuesta fue de 273 bytes, excluyendo los encabezados UDP e IP. Se omitieron el código op (Consulta) y el código de respuesta (NoError), al igual que la clase (C_IN) del registro A.

En el segundo ejemplo, helios responde a la consulta 2 con un código de respuesta de dominio inexistente (NXDomain) sin respuestas, un servidor de nombres y ningún registro de autoridad. El ‘*’ indica que se estableció el bit respuesta autorizada . Como no hubo respuestas, no se imprimió ningún tipo, clase o datos.

Otros caracteres de marca que pueden aparecer son ‘-‘ (recursividad disponible, RA, no establecido) y ‘|’ (mensaje truncado, TC, conjunto). Si la sección ‘pregunta’ no contiene exactamente una entrada, se imprime ‘[ n q]’.

Tenga en cuenta que las solicitudes y respuestas del servidor de nombres tienden a ser grandes, y el snaplen predeterminado de 68 bytes puede no capturar suficiente paquete para imprimir. Use el indicador -s para aumentar la respuesta si necesita investigar seriamente el tráfico del servidor de nombres. ‘ -s 128 ‘ me ha funcionado bien.

Decodificación SMB/CIFS. tcpdump incluye una decodificación SMB/CIFS/NBT bastante extensa para datos en UDP/137, UDP/138 y TCP/139. También se realizan algunas decodificaciones primitivas de datos IPX y NetBEUI SMB.

Por defecto, se realiza una decodificación bastante mínima, con una decodificación mucho más detallada si se usa -v. Tenga en cuenta que con -v un solo paquete SMB puede ocupar una página o más, por lo que solo use -v si realmente desea todos los detalles sangrientos.

Si está decodificando sesiones SMB que contienen cadenas unicode, puede establecer la variable de entorno USE_UNICODE en 1.Sería bienvenido un parche para detectar automáticamente cadenas Unicode.

Para obtener información sobre los formatos de paquetes SMB y el significado de todos los campos, visite www.cifs.org o el directorio pub/samba/specs/en su sitio espejo samba.org favorito. Los parches SMB fueron escritos por Andrew Tridgell (tridge@samba.org).

Solicitudes y respuestas de NFS. Las solicitudes y respuestas de Sun NFS (Sistema de archivos de red) se imprimen como:

  src.xid> dst.nfs: len op args  
src.nfs> dst.xid: respuesta stat len ​​op resultados
sushi .6709> wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs> sushi.6709: responda ok 40 readlink "../var"
sushi.201b> wrl.nfs: < br /> 144 búsquedas fh 9,74/4096.6878 "xcolors"
wrl.nfs> sushi.201b:
responder ok 128 búsquedas fh 9,74/4134.3150

En la primera línea, el host sushi envía una transacción con id 6709 a wrl (tenga en cuenta que el número que sigue al host src es un id de transacción, no el puerto de origen). La solicitud era de 112 bytes, excluyendo los encabezados UDP e IP. La operación fue un readlink (leer enlace simbólico) en el identificador de archivo ( fh ) 21,24/10.731657119. (Si tiene suerte, como en este caso, el identificador de archivo se puede interpretar como un par de números de dispositivo mayor y menor, seguido del número de inodo y el número de generación.) Wrl responde ‘ok’ con el contenido del enlace.

En la tercera línea, sushi le pide a wrl que busque el nombre ‘ xcolors ‘ en el archivo de directorio 9,74/4096.6878. Tenga en cuenta que los datos impresos dependen del tipo de operación. El formato se explica por sí mismo si se lee junto con una especificación de protocolo NFS.

Si se da el indicador -v (detallado), se imprime información adicional. Por ejemplo:

 sushi.1372a> wrl.nfs: 
148 leer fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs> sushi.1372a:
responder bien 1472 leer REG 100664 ids 417/0 sz 29388

(-v también imprime los campos TTL, ID, longitud y fragmentación del encabezado IP, que se han omitido en este ejemplo). En la primera línea, sushi pide wrl lea 8192 bytes del archivo 21,11/12.195, en el desplazamiento de bytes 24576. Wrl responde ‘ok’; el paquete que se muestra en la segunda línea es el primer fragmento de la respuesta y, por lo tanto, solo tiene una longitud de 1472 bytes (los otros bytes seguirán en fragmentos posteriores, pero estos fragmentos no tienen encabezados NFS o UDP, por lo que podrían no imprimirse) dependiendo de la expresión de filtro utilizada). Debido a que se proporciona el indicador -v, se imprimen algunos de los atributos del archivo (que se devuelven además de los datos del archivo): el tipo de archivo («REG», para el archivo normal), el modo de archivo (en octal), el uid y gid, y el tamaño del archivo.

Si el indicador -v se da más de una vez, se imprimen aún más detalles.

Tenga en cuenta que las solicitudes NFS son muy grandes y gran parte de los detalles no se imprimirán a menos que se aumente snaplen . Intente usar ‘ -s 192 ‘ para ver el tráfico NFS.

Los paquetes de respuesta NFS no identifican explícitamente la operación RPC. En cambio, tcpdump realiza un seguimiento de las solicitudes «recientes» y las compara con las respuestas utilizando el ID de la transacción. Si una respuesta no sigue de cerca la solicitud correspondiente, es posible que no se pueda analizar.

Solicitudes y respuestas de Transarc AFS (Andrew File System).

  src.sport> dst.dport: rx paquete-tipo  
src.sport> dst.dport: servicio de paquete-rx llamada call-name args
src.sport> dst.dport: servicio de tipo de paquete de respuesta respuesta args de nombre de llamada
elvis.7001> pike.afsfs:
llamada de datos de fs cambiar el nombre del viejo fid 536876964/1/1 ".newsrc.new"
nuevo fid 536876964/1/1 ".newsrc"
pike.afsfs> elvis.7001: datos de rx fs responder cambiar nombre

En la primera línea, el host elvis envía un paquete RX a Pike. Este era un paquete de datos RX para el servicio fs (servidor de archivos) y es el comienzo de una llamada RPC. La llamada RPC era un cambio de nombre, con el antiguo ID del archivo de directorio de 536876964/1/1 y un nombre de archivo antiguo de ‘.newsrc.new’, y un nuevo ID de archivo de directorio de 536876964/1/1 y un nuevo nombre de archivo de ‘. newsrc ‘. El host Pike responde con una respuesta RPC a la llamada de cambio de nombre (que fue exitosa, porque era un paquete de datos y no un paquete de cancelación).

En general, todos los RPC de AFS se decodifican al menos por el nombre de la llamada RPC. La mayoría de los RPC de AFS tienen al menos algunos de los argumentos decodificados (generalmente solo los argumentos ‘interesantes’, para alguna definición de interesante).

El formato está destinado a autodescribirse, pero probablemente no será útil para las personas que no están familiarizadas con el funcionamiento de AFS y RX.

Si el indicador -v (detallado) se da dos veces, se imprimen los paquetes de confirmación y la información adicional del encabezado, como el ID de la llamada RX, el número de llamada, el número de secuencia, el número de serie y los indicadores del paquete RX.

Si el indicador -v se proporciona dos veces, se imprime información adicional, como el ID de la llamada RX, el número de serie y los indicadores del paquete RX.La información de negociación de MTU también se imprime desde paquetes RX ack.

Si el indicador -v se da tres veces, se imprimen el índice de seguridad y la identificación del servicio.

Los códigos de error se imprimen para los paquetes de cancelación, con la excepción de los paquetes de baliza Ubik (porque los paquetes de cancelación se utilizan para indicar un voto de sí por el protocolo Ubik).

Tenga en cuenta que las solicitudes de AFS son muy grandes, y muchos de los argumentos no se imprimirán a menos que se aumente snaplen . Intente usar -s 256 para ver el tráfico de AFS.

Los paquetes de respuesta AFS no identifican explícitamente la operación RPC. En cambio, tcpdump realiza un seguimiento de las solicitudes «recientes» y las compara con las respuestas utilizando el número de llamada y el ID de servicio. Si una respuesta no sigue de cerca la solicitud correspondiente, es posible que no se pueda analizar.

KIP Appletalk (DDP en UDP) . Los paquetes DDP de Appletalk encapsulados en datagramas UDP se desencapsulan y se descargan como paquetes DDP (es decir, se descarta toda la información del encabezado UDP). El archivo /etc/atalk.names se usa para traducir appletalk net y números de nodo a nombres.

Las líneas en este archivo tienen esta forma:

  nombre del número  
1.254 éter
16.1 icsd-net
1.254.110 as

Las primeras dos líneas dan los nombres de las redes appletalk. La tercera línea da el nombre de un host particular (un host se distingue de una red por el tercer octeto en el número: un número de red debe tener dos octetos y un número de host debe tiene tres octetos). El número y el nombre deben estar separados por espacios en blanco (espacios en blanco o tabuladores). El archivo /etc/atalk.names puede contener líneas en blanco o líneas de comentarios (líneas que comienzan con un `# ‘).

Las direcciones de Appletalk se imprimen en el formulario:

  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 existe o no contiene una entrada para algún número de host/red de appletalk, las direcciones se imprimen en forma numérica). En el primer ejemplo, NBP ( El puerto DDP 2) en la red 144.1, el nodo 209 está enviando a lo que esté escuchando en el puerto 220 del nodo de red icsd 112. La segunda línea es la misma, excepto que se conoce el nombre completo del nodo de origen (‘oficina’). La tercera línea es un envío desde el puerto 235 en el nodo 149 jssmag de red para transmitir en el puerto icsd-net NBP (tenga en cuenta que la dirección de transmisión (255) se indica mediante un nombre de red sin número de host; por esta razón, es un buen idea de mantener nombres de nodo y nombres de red distintos en /etc/atalk.names).

Los paquetes NBP (protocolo de enlace de nombre) y ATP (protocolo de transacción de Appletalk) tienen su contenido interpretado. Otros protocolos simplemente vuelcan el nombre del protocolo (o el número si no hay un nombre registrado para el protocolo) y el tamaño del paquete.

Los paquetes NBP tienen el formato de los siguientes ejemplos:

 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ínea es una solicitud de búsqueda de nombres para grabadoras láser enviadas por net icsd host 112 y transmitidas en net jssmag. La identificación de nbp para la búsqueda es 190. La segunda línea muestra una respuesta a esta solicitud (tenga en cuenta que tiene la misma identificación) del host jssmag.209 y dice que tiene un recurso de grabador láser llamado «RM1140» registrado en el puerto 250. La tercera La línea es otra respuesta a la misma solicitud que dice que el techpit del host tiene una grabadora láser «techpit» registrada en el puerto 186.

El formato del paquete ATP se muestra en el siguiente ejemplo:

 jssmag.209.165> helios.132: atp-req 12266 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 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 0xae030001
jssmag.209.133> helios.132: atp-req * 12267 0xae030002

Jssmag.209 inicia la identificación de transacción 12266 con helios de host solicitando hasta ocho paquetes (el »). El número hexadecimal al final de la línea es el valor del campo ‘userdata’ en la solicitud.

Helios responde con ocho paquetes de 512 bytes.El ‘: dígito’ que sigue a la identificación de la transacción proporciona el número de secuencia del paquete en la transacción y el número en parens es la cantidad de datos en el paquete, excluyendo el encabezado atp. El ‘*’ en el paquete 7 indica que se estableció el bit EOM.

Jssmag.209 luego solicita que los paquetes 3 y 5 sean retransmitidos. Helios los reenvía, luego jssmag.209 lanza la transacción. Finalmente, jssmag.209 inicia la siguiente solicitud. El ‘*’ en la solicitud indica que XO (‘exactamente una vez’) fue no establecido.

Fragmentación de IP . Los datagramas fragmentados de Internet se imprimen así:

  (frag id:size@  offset   +)  
(frag id: tamaño @ desplazamiento )

(La primera forma indica que hay más fragmentos. La segunda indica que este es el último fragmento).

Id es la identificación del fragmento. Tamaño es el tamaño del fragmento (en bytes) excluyendo el encabezado IP. Offset es el desplazamiento de este fragmento (en bytes) en el datagrama original.

La información del fragmento se emite para cada fragmento. El primer fragmento contiene el encabezado del protocolo de nivel superior, y la información del fragmento se imprime después de la información del protocolo. Los fragmentos después del primero no contienen encabezado de protocolo de nivel superior, y la información del fragmento se imprime después de las direcciones de origen y destino. Por ejemplo, aquí es parte de un ftp de arizona.edu a lbl-rtsg.arpa a través de una conexión CSNET que no parece manejar datagramas 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 gana 2560

Hay un par de cosas a tener en cuenta aquí: Primero, las direcciones en la segunda línea no incluyen números de puerto. Esto se debe a que la información del protocolo TCP está en el primer fragmento y no tenemos idea de cuáles son los números de puerto o secuencia cuando imprimimos los fragmentos posteriores. En segundo lugar, la información de secuencia tcp en la primera línea se imprime como si hubiera 308 bytes de datos de usuario cuando, de hecho, hay 512 bytes (308 en el primer fragmento y 204 en el segundo). Si está buscando agujeros en el espacio de secuencia o tratando de hacer coincidir los acks con los paquetes, esto puede engañarlo.

Un paquete con el indicador IP no fragmentar se marca con un (DF) al final.

Marcas de tiempo. Por defecto, todas las líneas de salida están precedidas por una marca de tiempo.

  hh: mm: ss.frac  

La marca de tiempo es la hora actual del reloj en la forma anterior y es tan precisa como el reloj del núcleo. La marca de tiempo refleja la hora en que el núcleo vio por primera vez el paquete. No se intenta dar cuenta del lapso de tiempo entre el momento en que la interfaz Ethernet retiró el paquete del cable y el momento en que el núcleo atendió la interrupción del «paquete nuevo».

Rate article
labsfabs.com
Add a comment