Comando Linux tcpdump
Nos sistemas operacionais do tipo Unix, o tcpdump coleta um despejo bruto do tráfego de rede.
Este documento cobre a versão Linux do tcpdump .
Descrição
Tcpdump imprime uma descrição do conteúdo de pacotes em uma interface de rede que corresponde à expressão booleana especificada na linha de comando . Também pode ser executado com o sinalizador -w , que faz com que ele salve os dados do pacote em um arquivo para análise posterior, ou com o sinalizador -r , que faz com que ele leia de um arquivo de pacote salvo em vez de ler pacotes de um arquivo. interface de rede.
Se não for executado com o sinalizador -c , o tcpdump continuará capturando pacotes até que seja interrompido por um sinal SIGINT (por exemplo, quando o usuário digitar o caractere de interrupção , normalmente control-C ) ou um sinal SIGTERM (normalmente gerado com o kill comando); se executado com o sinalizador -c , ele capturará pacotes até que seja interrompido por um sinal SIGINT ou SIGTERM ou o número especificado de pacotes tenha sido processado.
Quando o tcpdump terminar de capturar pacotes, ele relatará contagens do seguinte:
- pacotes “capturados” (o número de pacotes que o tcpdump recebeu e processou);
- pacotes “recebidos pelo filtro” (o significado disso depende do sistema operacional no qual você está executando o tcpdump e, possivelmente, da maneira como o sistema operacional foi configurado; se um filtro foi especificado na linha de comando , em alguns sistemas operacionais ele conta pacotes independentemente se foram correspondidos pela expressão de filtro e, mesmo se correspondidos pela expressão de filtro, independentemente de o tcpdump já os tenha lido e processado; em outros sistemas operacionais, ele conta apenas pacotes que foram correspondidos pela expressão de filtro, independentemente de o tcpdump já os leu e processou e, em outros sistemas operacionais, conta apenas pacotes que foram correspondidos pela expressão de filtro e processados pelo tcpdump );
- pacotes “descartados pelo kernel ” (este é o número de pacotes que foram descartados, devido à falta de espaço no buffer) pelo mecanismo de captura de pacotes no sistema operacional no qual o tcpdump está sendo executado, se o sistema operacional relatar essas informações para aplicativos; caso contrário, , será relatado como 0 ).
Em plataformas que suportam o sinal SIGINFO , como a maioria dos sistemas operacionais BSD (incluindo o macOS X ) e o Digital / Tru64 UNIX , ele reportará essas contagens quando receber um sinal SIGINFO (gerado (por exemplo) digitando o caractere “status”, normalmente control-T ; embora em algumas plataformas, como o macOS X, o caractere “status” não seja definido por padrão, portanto, você deve configurá-lo com stty para usá-lo) e continuará capturando pacotes.
A leitura de pacotes de uma interface de rede pode exigir que você tenha privilégios especiais ; consulte o manual do pcap (3PCAP) para obter detalhes. A leitura de um arquivo de pacote salvo não requer privilégios especiais.
Sintaxe
tcpdump [-AbdDefhHIJKlLnNOpqRStuUvxX] [-B buffer_size ] [-c count ]
[-C file_size ] [-G rotate_seconds ] [-F file ] [-i interface ]
[-j tstamp_type ] [-m module ] [-M secret ] [-r file ]
[ -snaplen ] [-T type ] [-w file ] [-W filecount ]
[-E spi @ ipaddr algo : segredo , ...] [-y datalinktype ]
[-z postrotate-command ] [-Z user ] [ expressão ]Opções
| -UMA | Imprima cada pacote (menos seu cabeçalho no nível do link ) em ASCII . Útil para capturar páginas da web . |
| -b | Imprima o número AS nos pacotes BGP na notação ASDOT em vez da notação ASPLAIN . |
| -B buffer_size | Defina o tamanho do buffer de captura do sistema operacional como buffer_size , em unidades de KiB (1024 bytes ). |
| -c count | Saia depois de receber pacotes de contagem . |
| -C file_size | Antes de gravar um pacote bruto em um arquivo de salvamento , verifique se o arquivo atualmente é maior que file_size e, se houver, feche o arquivo de salvamento atual e abra um novo. Os arquivos de salvamento após o primeiro arquivo de salvamento têm o nome especificado com o sinalizador -w , com um número após ele, iniciando em 1 e continuando para cima. As unidades de file_size são milhões de bytes (1.000.000 bytes, não 1.048.576 bytes). |
| -d | Despejar o código compilado de correspondência de pacotes em um formato legível por humanos para saída padrão e parar. |
| -dd | Despejar código de correspondência de pacotes como um fragmento de programa C. |
| -ddd | Despejar o código de correspondência de pacotes como números decimais (precedido por uma contagem). |
| -D | Imprima a lista das interfaces de rede disponíveis no sistema e nas quais o tcpdump pode capturar pacotes. Para cada interface de rede, um número e um nome de interface, possivelmente seguidos por uma descrição de texto da interface, são impressos. O nome ou o número da interface pode ser fornecido ao sinalizador -i para especificar uma interface na qual capturar. Essa opção pode ser útil em sistemas que não possuem um comando para listá-los (por exemplo, sistemas Windows ou sistemas UNIX sem ifconfig -a ); o número pode ser útil nos sistemas Windows 2000 e posteriores, nos quais o nome da interface é uma sequência um pouco complexa . O sinalizador -D não será suportado seO tcpdump foi criado com uma versão mais antiga do libpcap que não possui a função pcap_findalldevs (). |
| -e | Imprima o cabeçalho no nível do link em cada linha de despejo. |
| -E | Use spi @ ipaddr algo: secret para descriptografar pacotes IPsec ESP endereçados a addr e que contenham o valor spi do Security Parameter Index . Essa combinação pode ser repetida com vírgula ou separação de nova linha . Observe que a configuração do segredo para pacotes IPv4 ESP é suportada no momento. Os algoritmos podem ser des -cbc , 3DES-CBC , blowfish-CBC , RC3-CBC , CAST128-CBC , ou nenhum . O padrão é des-cbc. A capacidade de descriptografar pacotes só está presente se o tcpdump foi compilado com a criptografia ativada. secret é o texto ASCII da chave secreta do ESP . Se precedido por 0x , um valor hexadecimal será lido. A opção assume o RFC 2406 ESP , não o RFC 1827 ESP . A opção é apenas para fins de depuração , e o uso dessa opção com uma verdadeira chave ‘secreta’ é desencorajado. Ao apresentar a chave secreta do IPsec na linha de comando, você a torna visível para outras pessoas, via ps (1) e outras ocasiões. Além da sintaxe acima , o nome do arquivo de sintaxe pode ser usado para que o tcpdump use os dados no arquivo. O arquivo é aberto após o recebimento do primeiro pacote ESP , portanto, quaisquer permissões especiais que o tcpdump possa ter sido concedido já deveriam ter sido concedidas. |
| -f | Imprima endereços IPv4 ‘estrangeiros’ numericamente em vez de simbolicamente (esta opção visa solucionar um problema com o servidor NIS da Sun – geralmente fica travado para sempre traduzir números de Internet não locais). O teste para endereços IPv4 ‘estrangeiros’ é feito usando o endereço IPv4 e a máscara de rede da interface na qual a captura está sendo feita. Se esse endereço ou máscara de rede não estiver disponível, porque a interface na qual a captura está sendo feita não possui endereço ou máscara de rede ou porque a captura está sendo feita na interface ” qualquer ” do Linux , que pode capturar em mais de uma interface, esta opção não funcionará corretamente. |
| Arquivo -F | Use o arquivo como entrada para a expressão de filtro. Uma expressão adicional dada na linha de comando é ignorada. |
| -G rotate_seconds | Se especificado, gira o arquivo de despejo especificado com a opção -w a cada rotate_seconds segundos. Os arquivos de salvamento têm o nome especificado por -w, que deve incluir um formato de hora, conforme definido por strftime . Se nenhum formato de hora for especificado, cada novo arquivo substituirá o anterior. Se usado em conjunto com a opção -C , os nomes de arquivos assumem a forma de ‘ arquivo <contagem> ‘. |
| -h | Imprima as seqüências de versão tcpdump e libpcap , imprima uma mensagem de uso e saia. |
| -H | Tente detectar os cabeçalhos de malha de rascunho do 802.11s. |
| interface -i | Ouça na interface . Se não especificado, o tcpdump pesquisará na lista de interface do sistema a interface configurada com o menor número (excluindo o loopback). Os laços são quebrados escolhendo a primeira correspondência. Nos sistemas Linux com kernels da versão 2.2 ou posterior, um argumento de interface ” any ” pode ser usado para capturar pacotes de todas as interfaces. Observe que as capturas no dispositivo ” any ” não serão feitas no modo promíscuo. Se o sinalizador -D for suportado, um número de interface impresso por esse sinalizador poderá ser usado como argumento da interface. |
| -EU | Coloque a interface no “modo monitor”; isso é suportado apenas nas interfaces Wi-Fi IEEE 802.11 e suportado apenas em alguns sistemas operacionais. Observe que, no modo monitor, o adaptador pode se desassociar da rede à qual está associado, para que você não possa usar nenhuma rede sem fio com esse adaptador. Isso pode impedir o acesso a arquivos em um servidor de rede ou a resolução de nomes de host ou endereços de rede, se você estiver capturando no modo monitor e não estiver conectado a outra rede com outro adaptador. Esse sinalizador afetará a saída do sinalizador -L . Se -I não for especificado, apenas os tipos de camada de link disponíveis quando não estiverem no modo monitor serão mostrados; se -I for especificado, apenas os tipos de camada de link disponíveis no modo monitor serão mostrados. |
| -j tstamp_type | Defina o tipo de carimbo de data e hora para a captura como tstamp_type . Os nomes a serem usados para os tipos de registro de data e hora são dados em pcap-tstamp-type (7); nem todos os tipos listados necessariamente serão válidos para qualquer interface. |
| -J | Liste os tipos de carimbo de data e hora suportados para a interface e saia. Se o tipo de registro de data e hora não puder ser definido para a interface, nenhum tipo de registro de data e hora será listado. |
| -K | Liste os tipos de carimbo de data e hora suportados para a interface e saia. Se o tipo de registro de data e hora não puder ser definido para a interface, nenhum tipo de registro de data e hora será listado. |
| -eu | Tornar a linha stdout armazenada em buffer. Útil se você quiser ver os dados enquanto os captura. Por exemplo,tcpdump -l | tee dat ou tcpdump -l> dat e tail -f dat Observe que no Windows “linha em buffer” significa “sem buffer”, para que o WinDump escreva cada caractere individualmente se -l for especificado. -U é semelhante a -l em seu comportamento, mas fará com que a saída seja “compactada em buffer de pacote”, de modo que a saída seja gravada em stdout no final de cada pacote e não no final de cada linha; isso é armazenado em buffer em todas as plataformas, incluindo Windows. |
| -EU | Liste os tipos de links de dados conhecidos para a interface, no modo especificado, e saia. A lista de tipos de links de dados conhecidos pode depender do modo especificado; por exemplo, em algumas plataformas, uma interface Wi-Fi pode suportar um conjunto de tipos de links de dados quando não está no modo monitor (por exemplo, pode suportar apenas cabeçalhos Ethernet falsos ou pode suportar cabeçalhos 802.11, mas não suporta cabeçalhos 802.11, mas não suporta cabeçalhos 802.11 com informações de rádio ) e outro conjunto de tipos de links de dados no modo monitor (por exemplo, ele pode suportar cabeçalhos 802.11 ou cabeçalhos 802.11 com informações de rádio, apenas no modo monitor). |
| -m module | Carregue as definições do módulo SMI MIB do módulo de arquivo . Esta opção pode ser usada várias vezes para carregar vários módulos MIB no tcpdump . |
| -M segredo | Use o segredo como um segredo compartilhado para validar os resumos encontrados nos segmentos TCP com a opção TCP- MD5 (RFC 2385), se presente. |
| -n | Não converta endereços (por exemplo, endereços de host, números de porta etc.) em nomes. |
| -N | Não imprima a qualificação de nomes de domínio de nomes de host. Por exemplo, se você der esse sinalizador, o tcpdump exibirá “nic” em vez de “nic.ddn.mil”. |
| -O | Não execute o otimizador de código de correspondência de pacote. Essa opção é útil apenas se você suspeitar de um erro no otimizador. |
| -p | Não coloque a interface no modo promíscuo. Observe que a interface pode estar no modo promíscuo por algum outro motivo; portanto, ‘ -p ‘ não pode ser usado como uma abreviação de ‘ ether host {local-hw-addr} ou ether broad-cast ‘. |
| -q | Saída rápida / silenciosa. Imprima menos informações de protocolo para que as linhas de saída sejam mais curtas. |
| -R | Suponha que os pacotes ESP / AH sejam baseados em especificações antigas (RFC1825 a RFC1829). Se especificado, o tcpdump não imprimirá o campo de prevenção de reprodução. Como não há campo de versão do protocolo na especificação ESP / AH , o tcpdump não pode deduzir a versão do protocolo ESP / AH . |
| arquivo -r | Leia pacotes do arquivo (que foi criado com a opção -w ). A entrada padrão é usada se o arquivo for ” – “. |
| -S | Imprima números de sequência TCP absolutos, e não relativos. |
| -s snaplen | Snarf snaplen bytes de dados de cada pacote, em vez do padrão de 65535 bytes. Pacotes truncados devido a um instantâneo limitado são indicados na saída com ” [| proto] “, em que proto é o nome do nível de protocolo no qual o truncamento ocorreu. Observe que tirar instantâneos maiores aumenta a quantidade de tempo necessária para processar pacotes e, efetivamente, diminui a quantidade de buffer de pacote. Isso pode causar a perda de pacotes. Você deve limitar snaplen ao menor número que capturar as informações de protocolo que lhe interessam. Definir snaplen como 0 define o padrão de 65535 , paracompatibilidade com versões anteriores do tcpdump . |
| -T tipo | Força os pacotes selecionados por “expressão” a serem interpretados no tipo especificado . Atualmente, os tipos conhecidos são aodv ( protocolo Ad-hoc de vetor de distância sob demanda), cnfp (protocolo Cisco NetFlow), rpc (chamada de procedimento remoto), rtp (protocolo de aplicativos em tempo real), rtcp (protocolo de controle de aplicativos em tempo real), snmp (Protocolo Simples de Gerenciamento de Rede), tftp (Protocolo de Transferência de Arquivos Trivial), vat (Visual Audio Tool) e wb (Quadro Branco distribuído). |
| -t | Não imprima um carimbo de data / hora em cada linha de despejo. |
| -tt | Imprima um carimbo de data / hora não formatado em cada linha de despejo. |
| -ttt | Imprima um delta (resolução de microssegundos) entre a linha atual e a anterior em cada linha de despejo. |
| -tttt | Imprima um carimbo de data / hora no formato padrão prosseguido por data em cada linha de despejo. |
| -ttttt | Imprima um delta (resolução de microssegundo) entre a linha atual e a primeira em cada linha de despejo. |
| -você | Imprimir identificadores NFS não codificados . |
| -VOCÊ | Se a opção -w não for especificada, efetue a saída do pacote impresso “buffer de pacote”; isto é, à medida que a descrição do conteúdo de cada pacote for impressa, ela será gravada na saída padrão, e não quando não estiver gravando em um terminal, sendo gravada somente quando o buffer de saída for preenchido. Se a opção -w for especificada, faça com que a saída do pacote bruto salva “seja armazenada em buffer”; isto é, à medida que cada pacote é salvo, ele será gravado no arquivo de saída, em vez de ser gravado somente quando o buffer de saída for preenchido. O sinalizador -U não será suportado se o tcpdump tiver sido construído com uma versão mais antiga da libpcap que não possui a função pcap_dump_flush (). |
| -v | Ao analisar e imprimir, produza (um pouco mais) saída detalhada. Por exemplo, o tempo de vida, a identificação, o comprimento total e as opções em um pacote IP são impressos. Além disso, permite verificações adicionais de integridade de pacotes, como a soma de verificação de cabeçalho IP e ICMP. Ao gravar em um arquivo com a opção -w , relate, a cada 10 segundos, o número de pacotes capturados. |
| -vv | Saída ainda mais detalhada. Por exemplo, campos adicionais são impressos a partir de pacotes de resposta NFS e pacotes SMB são totalmente decodificados. |
| -vvv | Saída ainda mais detalhada. Por exemplo, as opções de telnet SB … SE são impressas na íntegra. Com as opções -X Telnet , também são impressas em hexadecimal. |
| -W | Escreva os pacotes brutos no arquivo, em vez de analisá-los e imprimi-los. Posteriormente, eles podem ser impressos com a opção -r . A saída padrão é usada se o arquivo for ” – “. Essa saída será armazenada em buffer se gravada em um arquivo ou canal, portanto, um programa que esteja lendo o arquivo ou canal pode não ver pacotes por um período arbitrário de tempo após o recebimento. Use o sinalizador -U para fazer com que os pacotes sejam gravados assim que são recebidos. Veja pcap-savefile (5) para uma descrição do formato do arquivo. |
| -W | Utilizado em conjunto com a opção -C , isso limita o número de arquivos criados para o número especificado e começa a sobrescrever arquivos desde o início, criando assim um buffer ‘rotativo’. Além disso, ele irá nomear os arquivos com suficientes principais 0 s para suportar o número máximo de arquivos, permitindo-lhes para classificar corretamente. Utilizado em conjunto com a opção -G , isso limitará o número de arquivos de despejo girados criados, saindo com o status 0 ao atingir o limite. Se usado com -C também, o comportamento resultará em arquivos cíclicos por fatia de tempo. |
| -x | Ao analisar e imprimir, além de imprimir os cabeçalhos de cada pacote, imprima os dados de cada pacote (menos o cabeçalho no nível do link) em hexadecimal. O menor do pacote inteiro ou bytes snaplen serão impressos. Observe que este é o pacote inteiro da camada de link, portanto, para as camadas de link que atendem (por exemplo, Ethernet), os bytes de preenchimento também serão impressos quando o pacote de camada superior for menor que o preenchimento necessário. |
| -xx | Ao analisar e imprimir, além de imprimir os cabeçalhos de cada pacote, imprima os dados de cada pacote, incluindo seu cabeçalho no nível do link, em hexadecimal. |
| -X | Ao analisar e imprimir, além de imprimir os cabeçalhos de cada pacote, imprima os dados de cada pacote (menos o cabeçalho no nível do link) em hexadecimal e ASCII . Esta opção é muito útil para analisar novos protocolos. |
| -XX | Ao analisar e imprimir, além de imprimir os cabeçalhos de cada pacote, imprima os dados de cada pacote, incluindo seu cabeçalho no nível do link, em hexadecimal e ASCII. |
| -y datalinktype | Defina o tipo de link de dados a ser usado ao capturar pacotes para datalinktype . |
| -z postrotate-command | Utilizado em conjunto com as opções -C ou -G , isso fará com que o tcpdump execute ” arquivo de comando “, em que arquivo é o arquivo salvo sendo fechado após cada rotação. Por exemplo, especificar -z gzip ou -z bzip2 comprimirá cada arquivo de salvamento usando gzip ou bzip2 . Observe que o tcpdump executará o comando paralelamente à captura, usando a prioridade mais baixa para que isso não perturbe o processo de captura. E caso você queira usar um comando que aceite bandeiras ou argumentos diferentes, você sempre pode escrever um shell script que use o nome do arquivo de salvamento como o único argumento, faça as bandeiras &argumentos e execute o comando que você deseja. |
| Usuário -Z | Se o tcpdump estiver em execução como raiz , após abrir o dispositivo de captura ou inserir o arquivo de salvamento, mas antes de abrir qualquer arquivo de salvamento para saída, altere o ID do usuário para usuário e o ID do grupo para o grupo principal de usuários. Esse comportamento também pode ser ativado por padrão no momento da compilação. |
| expressão | Seleciona quais pacotes serão despejados. Se nenhuma expressão for dada, todos os pacotes na rede serão descartados. Caso contrário, apenas os pacotes cuja expressão for ‘ verdadeira ‘ serão despejados. Para a sintaxe da expressão, consulte pcap-filter (7). Os argumentos de expressão podem ser passados para o tcpdump como um único argumento ou como vários argumentos, o que for mais conveniente. Geralmente, se a expressão contiver metacaracteres do Shell, é mais fácil passá-la como um argumento único e citado. Vários argumentos são concatenados com espaços antes de serem analisados. |
Formato de saída
A saída do tcpdump depende do protocolo. A seguir, é apresentada uma breve descrição e exemplos da maioria dos formatos.
Cabeçalhos de nível de link
Se a opção ‘ -e ‘ for fornecida, o cabeçalho no nível do link será impresso. Em Ethernets, os endereços de origem e destino, protocolo e tamanho do pacote são impressos.
Nas redes FDDI , a opção ‘ -e ‘ faz com que o tcpdump imprima o campo ‘ frame control ‘, os endereços de origem e destino e o tamanho do pacote. (O campo ‘frame control’ controla a interpretação do restante do pacote. Pacotes normais (como aqueles que contêm datagramas IP) são pacotes ‘ assíncronos ‘, com um valor de prioridade entre 0 e 7 ; por exemplo, ‘ async4 ‘. presume-se que os pacotes contenham um pacote 802.2 Logical Link Control ( LLC ); o cabeçalho LLC será impresso se não for um datagrama ISO ou o chamado pacote SNAP .
Nas redes Token Ring , a opção ‘ -e ‘ faz com que o tcpdump imprima os campos ‘ controle de acesso ‘ e ‘ controle de quadro ‘, os endereços de origem e destino e o tamanho do pacote. Como nas redes FDDI, supõe-se que os pacotes contenham um pacote LLC. Independentemente de a opção ‘ -e ‘ ser especificada ou não, as informações de roteamento de origem são impressas para pacotes roteados de origem.
Nas redes 802.11, a opção ‘ -e ‘ faz com que o tcpdump imprima os campos ‘ frame control ‘, todos os endereços no cabeçalho 802.11 e o tamanho do pacote. Como nas redes FDDI, supõe-se que os pacotes contenham um pacote LLC.
Nota: A descrição a seguir pressupõe familiaridade com o algoritmo de compactação SLIP descrito no RFC-1144.
Nos links SLIP, um indicador de direção (” I ” para entrada, ” O ” para saída), tipo de pacote e informações de compactação são impressos. O tipo de pacote é impresso primeiro. Os três tipos são ip , utcp e ctcp . Nenhuma outra informação de link é impressa para pacotes IP. Para pacotes TCP, o identificador de conexão é impresso seguindo o tipo. Se o pacote estiver compactado, seu cabeçalho codificado será impresso. Os casos especiais são impressos como * S + n e * SA + n , em que n é a quantidade pela qual o número de sequência (ou número de sequência e confirma) mudou. Se não for um caso especial, zero ou mais alterações serão impressas. Uma alteração é indicada por U (ponteiro urgente), W (janela), A (confirmação), S (número de sequência) e I (ID do pacote), seguido por um delta ( + n ou -n ) ou um novo valor ( = n ). Finalmente, a quantidade de dados no pacote e o comprimento do cabeçalho compactado são impressos.
Por exemplo, a linha a seguir mostra um pacote TCP compactado de saída, com um identificador de conexão implícito; o ack mudou em 6 , o número de sequência em 49 e o ID do pacote em 6 ; existem 3 bytes de dados e 6 bytes de cabeçalho compactado:
O ctcp * A + 6 S + 49 I + 6 3 (6)
Pacotes ARP / RARP
A saída Arp / Rarp mostra o tipo de solicitação e seus argumentos. O formato pretende ser auto-explicativo. Aqui está uma pequena amostra retirada do início de um ‘ rlogin ‘ do host rtsg para o host csam :
arp quem-tem csam diga rtsg resposta arp csam é-em CSAM
A primeira linha diz que o rtsg enviou um pacote arp solicitando o endereço Ethernet do host da Internet csam . O Csam responde com seu endereço Ethernet (neste exemplo, os endereços Ethernet estão em maiúsculas e os endereços da Internet em minúsculas).
Isso pareceria menos redundante se tivéssemos feito tcpdump -n :
arp who-have 128.3.254.6 tell 128.3.254.68 A resposta arp 128.3.254.6 é às 02: 07: 01: 00: 01: c4
Se tivéssemos feito tcpdump -e , o fato de o primeiro pacote ser transmitido e o segundo ser ponto a ponto seria visível:
RTSG Broadcast 0806 64: arp quem-tem csam tell rtsg CSAM RTSG 0806 64: a resposta arp csam está em CSAM
Para o primeiro pacote, o endereço de origem Ethernet é RTSG , o destino é o endereço de transmissão Ethernet, o campo de tipo continha hex 0806 (tipo ETHER_ARP) e o comprimento total era de 64 bytes.
Pacotes TCP
Nota: A descrição a seguir pressupõe familiaridade com o protocolo TCP descrito no RFC-793. Se você não estiver familiarizado com o protocolo, nem essa descrição nem o tcpdump serão muito úteis para você.
O formato geral de uma linha de protocolo tcp é:
src> dst: sinaliza opções urgentes da janela data-seqno ack
Src e dst são os endereços IP e as portas de origem e destino. Os sinalizadores são uma combinação de S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Eco) ou ‘ . ‘(ACK) ou’ none ‘se nenhum sinalizador estiver definido. data-seqno descreve a parte do espaço de sequência coberto pelos dados neste pacote (veja o exemplo abaixo). ack é o número de sequência dos próximos dados esperados na outra direção nesta conexão. janelaé o número de bytes de espaço no buffer de recebimento disponível na outra direção nesta conexão. urg indica que há dados ‘urgentes’ no pacote. As opções são opções tcp entre colchetes angulares (por exemplo, <mss 1024> ).
Src , dst e flags estão sempre presentes. Os outros campos dependem do conteúdo do cabeçalho do protocolo tcp do pacote e são gerados apenas se apropriado.
Aqui está a parte de abertura de um rlogin do host rtsg para o host csam .
rtsg.1023> csam.login: S 768512: 768512 (0) vitória 4096 <mss 1024> csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 vitória 4096 <mss 1024> rtsg.1023> csam.login:. ack 1 vitória 4096 rtsg.1023> csam.login: P 1: 2 (1) ack 1 vitória 4096 csam.login> rtsg.1023:. ack 2 vitória 4096 rtsg.1023> csam.login: P 2:21 (19) ack 1 vitória 4096 csam.login> rtsg.1023: P 1: 2 (1) ack 21 vitória 4077 csam.login> rtsg.1023: P 2: 3 (1) ack 21 vitória 4077 urg 1 csam.login> rtsg.1023: P 3: 4 (1) ack 21 vitória 4077 urg 1
A primeira linha diz que a porta TCP 1023 no rtsg enviou um pacote para o login da porta no csam . O S indica que a bandeira SYN foi definido. O número de sequência do pacote era 768512 e não continha dados. A notação é ‘ first: last (nbytes) ‘, que significa ‘números de sequência primeiro, mas não incluindo o último, que é nbytes bytes de dados do usuário’. Não houve confirmação confirmada por piggy , a janela de recebimento disponível era de 4096 bytes e havia uma opção de tamanho de segmento máximo solicitando um mss de 1024 bytes.
CSAM responde com um pacote semelhante exceto que inclui um piggy-apoiada ACK para rtsg SYN ‘s. Rtsg então obtém o SYN do csam . O ‘ . ‘significa que o sinalizador ACK foi definido. O pacote não continha dados, portanto, não há número de sequência de dados. Observe que o número de sequência ack é um número inteiro pequeno . A primeira vez que tcpdumpvê uma ‘conversa’ tcp, imprime o número de sequência do pacote. Nos pacotes subsequentes da conversa, a diferença entre o número de sequência do pacote atual e esse número de sequência inicial é impressa. Isso significa que os números de sequência após o primeiro podem ser interpretados como posições de bytes relativas no fluxo de dados da conversa (com o primeiro byte de dados em cada direção sendo ‘ 1 ‘). O ‘ -S ‘ substituirá esse recurso, causando a saída dos números de sequência originais.
Na 6ª linha, o rtsg envia ao csam 19 bytes de dados (bytes 2 a 20 no lado rtsg → csam da conversa). O sinalizador PUSH é definido no pacote. Na 7ª linha, o csam diz que recebeu dados enviados por rtsg até, mas não inclui o byte 21. A maioria desses dados está aparentemente no buffer de soquete, pois a janela de recebimento do csam ficou 19 bytes menor. O CSAM também envia um byte de dados para rtsg neste pacote. Nas linhas 8 e 9, o csam envia dois bytes de dados urgentes e enviados para rtsg .
Se o instantâneo for pequeno o suficiente para que o tcpdump não capture o cabeçalho TCP completo, ele interpreta o máximo possível do cabeçalho e então reporta ” [| tcp] ” para indicar que o restante não pôde ser interpretado. Se o cabeçalho contiver uma opção falsa (uma com um tamanho muito pequeno ou além do final do cabeçalho), o tcpdump o reportará como ” [má opção] ” e não interpretará nenhuma outra opção (já que é impossível dizer onde eles começar). Se o comprimento do cabeçalho indicar que existem opções, mas o comprimento do datagrama IP não for longo o suficiente para que as opções realmente existam, o tcpdump o reportará como ” [comprimento ruim de hdr] “.
Captura de pacotes TCP com combinações de sinalizadores específicas ( SYN-ACK , URG-ACK , etc.)
Existem 8 bits na seção de bits de controle do cabeçalho TCP:
CWR ECE URG ACK PSH RST SYN FIN
Vamos supor que queremos assistir aos pacotes usados no estabelecimento de uma conexão TCP. Lembre-se de que o TCP usa um protocolo de handshake de três vias ao inicializar uma nova conexão; a seqüência de conexão em relação aos bits de controle TCP é
- O chamador envia SYN
- O destinatário responde com SYN, ACK
- O chamador envia ACK
Agora, estamos interessados em capturar pacotes que possuem apenas o bit SYN definido (Etapa 1). Observe que não queremos pacotes da etapa 2 (SYN-ACK), um SYN inicial simples. O que precisamos é de uma expressão de filtro correta para o tcpdump.
Lembre-se da estrutura de um cabeçalho TCP sem opções:
0 15 31
-------------------------------------------------- ---------------
| porta de origem | porta de destino |
-------------------------------------------------- ---------------
| número de sequência |
-------------------------------------------------- ---------------
| número de confirmação |
-------------------------------------------------- ---------------
| HL rsvd | C | E | U | A | P | R | S | F | tamanho da janela |
-------------------------------------------------- ---------------
| Soma de verificação TCP | ponteiro urgente |
-------------------------------------------------- ---------------
Um cabeçalho TCP geralmente contém 20 octetos de dados, a menos que existam opções. A primeira linha do gráfico contém os octetos de 0 a 3, a segunda linha mostra os octetos de 4 a 7, etc.
Começando a contar com 0, os bits de controle TCP relevantes estão contidos no octeto 13:
0 7 15 23 31
---------------- | --------------- | --------------- | - ---------------
| HL rsvd | C | E | U | A | P | R | S | F | tamanho da janela |
---------------- | --------------- | --------------- | - ---------------
| | 13 de outubro | | |
Vamos dar uma olhada no octeto não. 13:
| |
| --------------- |
| C | E | U | A | P | R | S | F |
| --------------- |
7 5 3 0 |
Estes são os bits de controle TCP que são de interesse. Nós numeramos os bits neste octeto de 0 a 7 , da direita para a esquerda, então o bit PSH é o número 3 , enquanto o bit URG é o número 5 .
Lembre-se de que queremos capturar pacotes com apenas o conjunto SYN. Vamos ver o que acontece com o octeto 13 se um datagrama TCP chegar com o bit SYN definido em seu cabeçalho:
| C | E | U | A | P | R | S | F |
| --------------- |
0 0 0 0 0 0 0 1 0 |
| --------------- |
| 7 6 5 4 3 2 1 0 |
Observando a seção de bits de controle, vemos que apenas o número de bit 1 (SYN) está definido.
Supondo que o octeto número 13 seja um número inteiro não assinado de 8 bits na ordem de bytes da rede, o valor binário desse octeto é
00000010
e sua representação 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 = 2
Estamos quase terminando, porque agora sabemos que, se apenas SYN estiver definido, o valor do 13º octeto no cabeçalho TCP, quando interpretado como um número inteiro não assinado de 8 bits na ordem de bytes da rede, deverá ser exatamente 2.
Esse relacionamento pode ser expresso como:
tcp [13] == 2
Podemos usar essa expressão como o filtro para o tcpdump assistir pacotes que possuem apenas SYN definido:
tcpdump -i xl0 tcp [13] == 2
A expressão diz “deixe o 13º octeto de um datagrama TCP ter o valor decimal 2”, que é exatamente o que queremos.
Agora, vamos supor que precisamos capturar pacotes SYN, mas não nos importamos se ACK ou qualquer outro bit de controle TCP está definido ao mesmo tempo. Vamos ver o que acontece com o octeto 13 quando um datagrama TCP com o conjunto SYN-ACK chega:
| 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 são definidos no 13º octeto. O valor binário do octeto 13 é
00010010
que se traduz no decimal 18 :
^ 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
Agora não podemos usar ‘ tcp [13] == 18 ‘ na expressão de filtro tcpdump , porque isso selecionaria apenas os pacotes que têm o SYN-ACK configurado, mas não aqueles com apenas o SYN definido. Lembre-se de que não nos importamos se ACK ou qualquer outro bit de controle estiver definido enquanto SYN estiver definido.
Para atingir nosso objetivo, precisamos logicamente AND do valor binário do octeto 13 com algum outro valor para preservar o bit SYN. Sabemos que queremos que SYN seja definido em qualquer caso, portanto, logicamente AND o valor no 13º octeto com o valor binário de um SYN:
00010010 SYN-ACK 00000010 SYN
AND 00000010 (queremos SYN) AND 00000010 (queremos SYN)
-------- --------
= 00000010 = 00000010
Vemos que essa operação AND fornece o mesmo resultado, independentemente de ACK ou outro bit de controle TCP estar definido. A representação decimal do valor AND, bem como o resultado dessa operação, é 2 (binário 00000010), portanto sabemos que para pacotes com SYN configurados a seguinte relação deve ser verdadeira:
(( valor do octeto 13 ) AND ( 2 )) == ( 2 )
Isso nos indica a expressão de filtro tcpdump
tcpdump -i xl0 'tcp & 2 == 2'
Alguns deslocamentos e valores de campo podem ser expressos como nomes e não como valores numéricos. Por exemplo, tcp] pode ser substituído por tcp [tcpflags]. Os seguintes valores de campo de sinalizador TCP também estão disponíveis: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-act , tcp-urg .
Isso pode ser demonstrado como:
tcpdump -i xl0 'tcp [tcpflags] & tcp-push! = 0'
Observe que você deve usar aspas simples ou uma barra invertida na expressão para proteger o caractere especial AND (‘ & ‘) do shell.
Pacotes UDP
O formato UDP é ilustrado por este pacote rwho :
actinide.who> broadcast.who: udp 84
Isso diz que a porta que no host actinide enviou um datagrama udp para a porta que na transmissão do host , o endereço de transmissão da Internet. O pacote continha 84 bytes de dados do usuário.
Alguns serviços UDP são reconhecidos (a partir do número da porta de origem ou de destino) e as informações do protocolo de nível superior são impressas. Em particular, solicitações de serviço de Nome de Domínio (RFC-1034/1035) e Sun RPC chama (RFC-1050) para NFS.
Solicitações do servidor de nomes UDP
Nota: A descrição a seguir pressupõe familiaridade com o protocolo do Serviço de Domínio descrito no RFC-1035. Se você não estiver familiarizado com o protocolo, a descrição a seguir parecerá escrita em um idioma estrangeiro estranho que não é musical nem encantador.
As solicitações do servidor de nomes são formatadas como
src> dst: id op? sinalizadores qtype qclass name (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
O host h2opolo solicitou ao servidor de domínio na helios um registro de endereço ( qtype = A ) associado ao nome ucbvax.berkeley.edu . O ID da consulta era ‘ 3 ‘. O ‘ + ‘ indica que o sinalizador de recursão desejado foi definido. O comprimento da consulta era de 37 bytes, sem incluir os cabeçalhos de protocolo UDP e IP. A operação de consulta era a consulta normal, portanto, o campo op foi omitido. Se o op tivesse sido qualquer outra coisa, teria sido impresso entre o ‘ 3 ‘ e o ‘ + ‘. Da mesma forma, a qclass era a normal, C_IN , e omitida. Qualquer outra qclassteria sido impresso imediatamente após o ‘ A ‘.
Algumas anomalias são verificadas e podem resultar em campos extras entre colchetes: se uma consulta contiver uma resposta, a seção registros de autoridade ou registros adicionais , ancount , nscount ou arcount serão impressos como ‘ [na] ‘, ‘ [nn] ‘ ou ‘ [nau] ‘ onde n é a contagem apropriada. Se algum dos bits de resposta estiver definido ( AA , RA ou rcode ) ou qualquer um dos bits ‘deve ser zero’, nos bytes dois e três, ‘ [b2 & 3 = x] ‘ será impresso, onde x é o valor hexadecimal de bytes de cabeçalho dois e três.
Respostas do servidor de nomes UDP
As respostas do servidor de nomes são formatadas como
src> dst: id op rcode sinaliza dados de classe do tipo n / au (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, o helios responde à consulta id 3 do h2opolo com 3 registros de resposta, 3 registros do servidor de nomes e 7 registros adicionais. O primeiro registro de resposta é do tipo A (endereço) e seus dados são o endereço da Internet 128.32.137.3 . O tamanho total da resposta foi de 273 bytes, excluindo os cabeçalhos UDP e IP. O op (consulta) e o código de resposta (NoError) foram omitidos, assim como a classe (C_IN) do registro A.
No segundo exemplo, o helios responde à consulta 2 com um código de resposta de domínio inexistente ( NXDomain ) sem respostas, um servidor de nomes e nenhum registro de autoridade. O ‘ * ‘ indica que o bit de resposta oficial foi definido. Como não houve respostas, nenhum tipo, classe ou dados foram impressos.
Outros caracteres de sinalização que podem aparecer são ‘ – ‘ (recursão disponível, RA , não definida) e ‘ | ‘(mensagem truncada, TC , conjunto). Se a seção ‘pergunta’ não contiver exatamente uma entrada, ‘ [nq] ‘ será impresso.
Decodificação SMB / CIFS
O tcpdump agora inclui decodificação SMB / CIFS / NBT bastante extensa para dados em UDP / 137, UDP / 138 e TCP / 139. Também é feita uma decodificação primitiva dos dados IPX e NetBEUI SMB .
Por padrão, é feita uma decodificação bastante mínima, com uma decodificação muito mais detalhada se -v for usado. Esteja avisado de que, com -v, um único pacote SMB pode ocupar uma página ou mais; portanto, use -v se você realmente deseja todos os detalhes sangrentos.
Solicitações e respostas NFS
As solicitações e respostas do Sun NFS (Sistema de Arquivos de Rede) são impressas como:
src.xid> dst.nfs: len op args src.nfs> dst.xid: estatuto da resposta, resultados opcionais 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 pesquisa fh 9,74 / 4096.6878 "xcolors" wrl.nfs> sushi.201b: resposta ok 128 pesquisa fh 9,74 / 4134.3150
Na primeira linha, o host sushi envia uma transação com o ID 6709 para wrl (observe que o número após o host src é um ID de transação, não a porta de origem). A solicitação era de 112 bytes, excluindo os cabeçalhos UDP e IP. A operação foi um link de leitura (link simbólico de leitura) no identificador de arquivo ( fh ) 21,24 / 10.73165 . Se alguém tiver sorte, como neste caso, o identificador de arquivo pode ser interpretado como um par maior e menor de número de dispositivo, seguido pelo número do inode e pelo número de geração. Wrl responde ‘ ok ‘ com o conteúdo do link.
Na terceira linha, o sushi pede ao wrl para procurar o nome ‘ xcolors ‘ no arquivo de diretório 9,74 / 4096.6878 . Observe que os dados impressos dependem do tipo de operação. O formato deve ser auto-explicativo se lido em conjunto com uma especificação de protocolo NFS .
Se o sinalizador -v (detalhado) for fornecido, informações adicionais serão impressas. Por exemplo:
sushi.1372a> wrl.nfs: 148 leitura fh 21,11 / 12.195 8192 bytes @ 24576 wrl.nfs> sushi.1372a: resposta ok 1472 ler REG 100664 ids 417/0 sz 29388
-v também imprime os campos TTL , ID , comprimento e fragmentação do cabeçalho IP , que foram omitidos neste exemplo. Na primeira linha, o sushi pede ao wrl para ler 8192 bytes do arquivo 21,11 / 12.195 , no deslocamento de bytes 24576 . Wrl responde ‘ ok ‘; o pacote mostrado na segunda linha é o primeiro fragmento da resposta e, portanto, possui apenas 1472 bytes (os outros bytes seguirão nos fragmentos subsequentes, mas esses fragmentos não têm cabeçalhos NFS ou UDP e, portanto, podem não ser impressos, dependendo da expressão de filtro usada). Porque o -vComo sinalizador é fornecido, alguns dos atributos do arquivo (que são retornados além dos dados do arquivo) são impressos: o tipo de arquivo (” REG “, para arquivo normal), o modo de arquivo (em octal ), o uid e gid e o tamanho do arquivo . Se o sinalizador -v for exibido mais de uma vez, mais detalhes serão impressos.
Observe que as solicitações de NFS são muito grandes e muitos detalhes não serão impressos, a menos que a ampliação seja aumentada. Tente usar ‘ -s 192 ‘ para assistir ao tráfego NFS.
Pacotes de resposta NFS não identificam explicitamente a operação RPC. Em vez disso, o tcpdump acompanha as solicitações “recentes” e as corresponde às respostas usando o ID da transação. Se uma resposta não seguir atentamente a solicitação correspondente, ela poderá não ser analisável.
Solicitações e respostas do AFS
As solicitações e respostas do Transarc AFS (Andrew File System) são impressas como:
src.sport> dst.dport: tipo de pacote rx src.sport> dst.dport: chamada de serviço do tipo de pacote rx nome-da-chamada args src.sport> dst.dport: resposta de serviço do tipo de pacote rx args de nome de chamada elvis.7001> pike.afsfs: chamada fs de dados rx renomear fid antigo 536876964/1/1 ".newsrc.new" novo fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: renomear a resposta fs de dados rx
Na primeira linha, o host elvis envia um pacote RX para o pico. Este era um pacote de dados RX para o serviço fs (servidor de arquivos) e é o início de uma chamada RPC. A chamada RPC foi renomeada, com o ID do arquivo de diretório antigo 536876964/1/1 e um nome de arquivo antigo ‘.newsrc.new’ e um novo ID de arquivo do diretório 536876964/1/1 e um novo nome de arquivo ‘.newsrc’. O pique do host responde com uma resposta RPC à chamada de renomeação (que foi bem-sucedida, porque era um pacote de dados e não um pacote de cancelamento).
Em geral, todos os RPCs do AFS são decodificados pelo menos pelo nome da chamada do RPC. A maioria dos RPCs do AFS possui pelo menos alguns dos argumentos decodificados (geralmente apenas os argumentos ‘interessantes’, para alguma definição de interessante).
O formato pretende ser auto-descritivo, mas provavelmente não será útil para pessoas que não estão familiarizadas com o funcionamento do AFS e RX.
Se o sinalizador -v (detalhado) for fornecido duas vezes, os pacotes de confirmação e informações adicionais do cabeçalho serão impressos, como o ID da chamada RX, o número da chamada, o número da sequência, o número de série e os sinalizadores do pacote RX.
Se o sinalizador -v for fornecido duas vezes, informações adicionais serão impressas, como o ID da chamada RX, o número de série e os sinalizadores de pacotes RX. As informações de negociação da MTU também são impressas a partir de pacotes de confirmação RX.
Se o sinalizador -v for fornecido três vezes, o índice de segurança e a identificação do serviço serão impressos.
Os códigos de erro são impressos para pacotes de interrupção, com exceção dos pacotes de beacon da Ubik (porque os pacotes de interrupção são usados para significar um voto sim para o protocolo da Ubik).
Observe que as solicitações do AFS são muito grandes e muitos dos argumentos não serão impressos, a menos que a ampliação seja aumentada. Tente usar ‘ -s 256 ‘ para assistir ao tráfego do AFS.
Pacotes de resposta do AFS não identificam explicitamente a operação RPC. Em vez disso, o tcpdump rastreia solicitações “recentes” e as corresponde às respostas usando o número de chamada e o ID do serviço. Se uma resposta não seguir atentamente a solicitação correspondente, ela poderá não ser analisável.
KIP AppleTalk (DDP em UDP)
Os pacotes AppleTalk DDP encapsulados em datagramas UDP são desencapsulados e despejados como pacotes DDP (ou seja, todas as informações do cabeçalho UDP são descartadas). O arquivo /etc/atalk.names é usado para converter os números de rede e nó AppleTalk em nomes. As linhas neste arquivo têm o formato
nome do número 1,254 éter 16.1 icsd-net 1.254.110 ace
As duas primeiras linhas dão os nomes das redes AppleTalk. A terceira linha indica o nome de um host em particular que um host é diferenciado de uma rede pelo terceiro octeto no número, um número de rede deve ter dois octetos e um número de host deve ter três octetos. O número e o nome devem ser separados por espaços em branco (espaços em branco ou tabulações). O arquivo /etc/atalk.names pode conter linhas em branco ou linhas de comentário (linhas começando com um ‘ # ‘).
Os endereços AppleTalk são impressos no formato:
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 não existir ou não contiver uma entrada para algum número de host / rede AppleTalk, os endereços serão impressos em formato numérico. No primeiro exemplo, PNI (DDP porta 2 ) no líquido 144,1 nó 209 está a enviar para o que está ouvindo na porta 220 do nó ICSD líquido 112 . A segunda linha é a mesma, exceto que o nome completo do nó de origem é conhecido (‘ escritório ‘). A terceira linha é um envio da porta 235 no nó net jssmag 149 para transmitir na icsd-netPorta NBP (observe que o endereço de broadcast (255) é indicado por um nome de rede sem número de host – por esse motivo, é uma boa idéia manter nomes de nó e nomes de rede distintos em /etc/atalk.names ).
Os pacotes NBP (protocolo de ligação de nomes) e ATP (protocolo de transação AppleTalk) têm seu conteúdo interpretado. Outros protocolos despejam o nome do protocolo (ou número, se nenhum nome estiver registrado para o protocolo) e o tamanho do pacote.
Pacotes NBP são formatados 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 @ *" 186
A primeira linha é uma solicitação de pesquisa de nome para gravadores a laser enviados pelo host icsd net 112 e transmitidos no net jssmag. O ID do nbp para a pesquisa é 190. A segunda linha mostra uma resposta para essa solicitação (observe que ele tem o mesmo ID) do host jssmag.209, dizendo que ele possui um recurso de gravação a laser chamado ” RM1140 ” registrado na porta 250 . A terceira linha é outra resposta à mesma solicitação, dizendo que o host techpit tem o laserwriter ” techpit ” registrado na porta 186 .
A formatação do pacote ATP é demonstrada pelo seguinte exemplo:
jssmag.209.165> helios.132: atp-req 12266 <0-7> 0xae030001 O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação do Windows 10 jssmag.209.165> helios.132: atp-req 12266 <3,5> 0xae030001 O que você precisa saber antes de iniciar o processo de instalação. O que você precisa saber antes de iniciar o processo de instalação. jssmag.209.165> helios.132: atp-rel 12266 <0-7> 0xae030001 jssmag.209.133> helios.132: atp-req * 12267 <0-7> 0xae030002
Jssmag.209 inicia ID de transação 12266 com acolhimento Helios , solicitando até 8 pacotes (o ‘ <0-7> ‘). O número hexadecimal no final da linha é o valor do campo ‘userdata’ na solicitação. O Helios responde com 8 pacotes de 512 bytes. O ‘ : [dígito]’ após a identificação da transação fornece o número de sequência do pacote na transação e o número em parens é a quantidade de dados no pacote, excluindo o cabeçalho atp. O ‘ * ‘ no pacote 7 indica que o bit EOM foi definido.
O jssmag.209 solicita que os pacotes 3 e 5 sejam retransmitidos. Helios os reenvia e o jssmag.209 libera a transação. Finalmente, o jssmag.209 inicia a próxima solicitação. O ‘ * ‘ na solicitação indica que XO (‘exatamente uma vez’) não foi definido.
Fragmentação de IP
Os datagramas da Internet fragmentados são impressos como:
(ID da frag: size @ offset +) (ID da frag: tamanho @ deslocamento )
A primeira forma indica que existem mais fragmentos. O segundo indica que este é o último fragmento.
Id é o ID do fragmento. Tamanho é o tamanho do fragmento (em bytes), excluindo o cabeçalho IP. Deslocamento é o deslocamento deste fragmento (em bytes) no datagrama original.
A informação do fragmento é emitida para cada fragmento. O primeiro fragmento contém o cabeçalho do protocolo de nível superior e as informações do frag são impressas após as informações do protocolo. Os fragmentos após o primeiro não contêm cabeçalho de protocolo de nível superior e as informações sobre fragmentos são impressas após os endereços de origem e destino. Por exemplo, aqui está parte de um ftp do arizona.edu para o lbl-rtsg.arpa em uma conexão CSNET que não parece lidar com datagramas de 576 bytes:
arizona.ftp-data> rtsg.1170:. 1024: 1332 (308) ack 1 vitória 4096 (frag 595a: 328 @ 0 +) arizona> rtsg: (frag 595a: 204 @ 328 ) rtsg.1170> arizona.ftp-data:. ack 1536 vitória 2560
Há algumas coisas a serem observadas aqui: Primeiro, os endereços na 2ª linha não incluem números de porta. Como as informações do protocolo TCP estão todas no primeiro fragmento e não temos idéia de quais são os números de porta ou sequência quando imprimimos os fragmentos posteriores. Segundo, as informações da sequência tcp na primeira linha são impressas como se houvesse 308 bytes de dados do usuário quando, de fato, existem 512 bytes (308 na primeira frag e 204 na segunda). Se você estiver procurando por buracos no espaço de sequência ou tentando combinar acks com pacotes, isso pode te enganar.
Um pacote com o sinalizador IP não fragmentar é marcado com um final (DF).
Timestamps
Por padrão, todas as linhas de saída são precedidas por um carimbo de data / hora . O registro de data e hora é a hora atual do relógio no formato hh: mm: ss.frac e é tão precisa quanto o relógio do kernel. O registro de data e hora reflete o horário em que o kernel viu o pacote pela primeira vez. Nenhuma tentativa é feita para explicar o intervalo de tempo entre o momento em que a interface Ethernet removeu o pacote do fio e quando o kernel atendeu à interrupção do ‘novo pacote’.
Exemplos
pôr do sol do host tcpdump
Imprime todos os pacotes que chegam ou partem do pôr do sol do host .
hélices do host tcpdump e \ (quente ou ace \)
Imprime o tráfego entre hélices do host e quente ou ás .
ace do host do tcpdump ip e não helios
Imprime todos os pacotes IP entre o ás e qualquer host, exceto helios .
tcpdump 'snup do gateway e (porta ftp ou ftp-dados)'
Imprime todo o tráfego ftp através do snup do gateway da Internet . Observe que a expressão é citada para impedir que o shell interprete os parênteses.
ip tcpdump e não net localnet
Imprime o tráfego nem originado nem destinado a hosts locais. Se você faz o gateway para outra rede, esse material nunca deve chegar à sua rede local.
tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0 e não src e dst net localnet'
Imprime os pacotes inicial e final (os pacotes SYN e FIN ) de cada conversa TCP que envolve um host não local.
tcpdump 'porta 80 do tcp e (((ip [2: 2] - ((ip [0] e 0xf) << 2)) - ((tcp [12] & 0xf0) >> 2))! = 0)'
Imprime todos os pacotes HTTP IPv4 para e da porta 80. O tcpdump imprime apenas pacotes que contêm dados; não, por exemplo, pacotes SYN e FIN e pacotes ACK- only.
tcpdump 'snup do gateway e ip [2: 2]> 576'
Imprime pacotes IP com mais de 576 bytes enviados pelo snup do gateway .
tcpdump 'éter [0] & 1 = 0 e ip [16]> = 224'
Imprime pacotes de difusão IP ou multicast que não foram enviados via difusão Ethernet ou multicast.
tcpdump 'icmp [icmptype]! = icmp-eco e icmp [icmptype]! = icmp-echoreply'
Imprime todos os pacotes ICMP que não são solicitações / respostas de eco (ou seja, não pacotes de ping ).
Comandos relacionados
ip – Exiba e manipule informações sobre roteamento, dispositivos, roteamento de políticas e túneis.
stty – Defina opções para o visor do seu terminal.
