Usando o tcpdump para extrair o conteúdo RPC do NFS

3

Questão bem simples ... Estou rodando o tcpdump e tentando analisar o conteúdo dos pacotes TCP entre servidor / cliente. Eu vejo o RPC "GETATTR" sendo recebido, o que é ótimo! No entanto, eu quero saber o arquivo para o qual o RPC está sendo feito. Estou assumindo que isso está no conteúdo do pacote. Quando imprimo o tcpdump como ASCII.

From server:
tcpdump -vvv -s 200 port 2049 
14:45:38.408949 IP (tos 0x0, ttl 64, id 58408, offset 0, flags [DF], proto TCP (6), length 296)
myserver.nfs > myclient.2469839164: reply ok 240 getattr NON 3 ids 0/3 sz 0

Aqui e outros sites mostram que é possível mapear para nomes de arquivos. Talvez seja dependente da plataforma? Eu só quero ter certeza de que não há uma opção óbvia para o tcpdump que estou perdendo.

Estou executando o RH5 - Kernel 2.6.32-279.el6.x86_64

    
por Jmoney38 12.09.2013 / 17:00

3 respostas

2

Ok, acho que consegui encontrar uma "solução alternativa". Você não será capaz de obter o nome do arquivo usando o NFSv3, mas poderá ge o inode.

Usando o Wireshark,

Go to Edit -> Preferences -> Protocols -> NFS -> check all boxes and set "Decode nfs handles as: KNFSD_LE.

Salve. Agora capture e filtre pelo protocolo NFS.

Pesquise o pacote GETATTR Reply (Call in #) Regular file mode: ???.

Abra este pacote e expanda o seguinte:

Network File System -> obj_attributes 

verifique o valor fileid , esse será o número do inode do arquivo.

no servidor, vá para o compartilhamento nfs e

find . -inum inode

Com o NFSv4, você vê uma chamada com o nome do arquivo diretamente.

    
por 12.09.2013 / 21:04
2

Você pode dar uma olhada na ferramenta nfstrace no github: ( link ). Ele rastreia todos os procedimentos NFSv3 / NFSv4 capturados.

    
por 23.01.2015 / 17:09
0

A impureza do RedHat (e qualquer outro) do NFS v3 usará um identificador de arquivo na maioria das operações, em vez de um nome. Se você não vir a alça com o wireshark, continue expandindo partes do pacote até encontrá-lo. Alguns pacotes conterão um identificador para o objeto de destino e para seu diretório pai, portanto, examine-o com atenção. Em NFS CALLs, a linha "Info" de resumo da wireshark geralmente mostra um hash que é uma versão reduzida da alça. O problema é que sem "outras informações" ou acesso à máquina em questão (por exemplo, se você estiver analisando os pacotes de outra pessoa), o identificador de arquivo não é uma informação muito útil.

Você pode pesquisar os pacotes que vieram antes para o identificador ou seu hash e esperar encontrar um local onde o mesmo identificador de arquivo esteja presente de uma maneira que o associe a um nome de arquivo. Por exemplo, uma pesquisa resultará em uma resposta que contém o identificador do arquivo. Ou a resposta de uma operação de criação mostrará o identificador do objeto que acabou de ser criado. Ou se uma sequência "readdirplus" estiver presente e os pacotes não estiverem truncados, é provável que você possa obter as informações de lá.

É claro que, em muitos casos, o nfs mount está em uso há algum tempo, e a chamada original que fez com que o cliente "aprenda" o identificador que acompanha o nome pode ter desaparecido há muito tempo. Portanto, se você for capaz de controlar e planejar as etapas de reprodução do problema e coleta de pacotes, pode ser útil começar sem a montagem do nfs presente. Então inicie o tcpdump. Em seguida, execute a montagem. Então reproduza o problema do nfs. Dessa forma, você tem certeza de capturar pacotes que conectarão todos os identificadores de arquivos com nomes de arquivos.

    
por 23.05.2018 / 22:59