Em ferramentas como o TCPDUMP, quando exatamente os pacotes de rede são capturados?

Question

Uma das ferramentas que estou usando usa a criptografia/descriptografia para enviar dados pela rede. Estou modificando a ferramenta e preciso ter certeza de que os dados estão realmente sendo enviados de forma criptografada.

São Wireshark e tcpdump as ferramentas certas para esse fim? Em que ponto durante a transferência eles capturam os pacotes de rede?

Answer 1

Ambas as ferramentas capturam os dados exatamente como se apagam sobre o fio. (Pense nisso como uma espécie de equivalente a "tee" para a saída que será exibida e também para arquivar; aqui também, os mesmos dados vão para o soquete e para o tcpdump ou qualquer outra coisa.)

Então, sim, se sua ferramenta estiver configurada corretamente para criptografar os dados antes de enviá -los, o TCPDUMP ou o Wireshark devem refletir isso nas capturas de pacotes.

Answer 2

Resposta curta: Os pacotes são tocados no final da pilha de rede de software (por exemplo, no Linux).

Resposta longa com a escavação de código no kernel tcpdump, libpcap e linux 3.12:

Tanto o Wireshark quanto o TCPDUMP usa libpcap, por exemplo,

http://sources.debian.net/src/tcpdump/4.5.1-2/tcpdump.c#l1472

    if (pcap_setfilter(pd, &fcode) < 0)

que, por sua vez, instalam um filtro de pacote via setFilter_op e ActiveRate_OP. Existem muitas implementações dessas operações, e acho que no Linux recente PF_PACKET será usado com pcap_activate_linux libpcap-1.5.3-2/pcap-linux.c#L1287:

/*
 * Current Linux kernels use the protocol family PF_PACKET to
 * allow direct access to all packets on the network while
 * older kernels had a special socket type SOCK_PACKET to
 * implement this feature.
 * While this old implementation is kind of obsolete we need
 * to be compatible with older kernels for a while so we are
 * trying both methods with the newer method preferred.
 */
status = activate_new(handle);

    ...
    activate_new(pcap_t *handle)
     ...
    /*
 * Open a socket with protocol family packet. If the
 * "any" device was specified, we open a SOCK_DGRAM
 * socket for the cooked interface, otherwise we first
 * try a SOCK_RAW socket for the raw interface.
 */
sock_fd = is_any_device ?
    socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
    socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

Pf_packet é implementado no kernel, no arquivo net/packet/af_packet.c. A inicialização de PF_Socket é feita em packet_do_bind com register_prot_hook(sk) função (se o dispositivo estiver no estado da UP), que chama dev_add_pack a partir de net/núcleo/dev.c Para registrar o gancho:

 370 /**
 371 *      dev_add_pack - add packet handler
 372 *      @pt: packet type declaration
 373 *
 374 *      Add a protocol handler to the networking stack. The passed &packet_type
 375 *      is linked into kernel lists and may not be freed until it has been
 376 *      removed from the kernel lists.
 377 *
 378 *      This call does not sleep therefore it can not
 379 *      guarantee all CPU's that are in middle of receiving packets
 380 *      will see the new packet type (until the next received packet).
 381 */
 382
 383 void dev_add_pack(struct packet_type *pt)
 384 {
 385        struct list_head *head = ptype_head(pt);
 386
 387        spin_lock(&ptype_lock);
 388        list_add_rcu(&pt->list, head);
 389        spin_unlock(&ptype_lock);
 390 }

Eu acho, pf_packet manipulador - o tpacket_rcv(...) função - será registrado em ptype_all.

Ganchos, registrados em ptype_all são chamados para pacotes de saída de dev_queue_xmit_nit ("Rotina de suporte. Envia quadros de saída para qualquer torneira de rede atualmente em uso.") Com com a list_for_each_entry_rcu(ptype, &ptype_all, list) { ... deliver_skb ...} .. func, entregra_skb chama o func que é tpacket_rcv para libpcap.

dev_queue_xmit_nit é chamado de dev_hard_start_xmit (Linha 2539 na rede/núcleo/dev.c) que é AFAIK o último estágio (para pacotes de saída) de manuseio de pacotes independentes de dispositivos na pilha de rede Linux.

A mesma história é para pacotes de entrada, ptype_all-Ganchos registrados são chamados de __netif_receive_skb_core com o mesmo list_for_each_entry_rcu(ptype, &ptype_all, list) {.. deliver_skb..}. __netif_receive_skb_core é chamado de __netif_receive_skb No início do manuseio de pacotes de entrada

Linux Foundation tem boa descrição da pilha de redes (http://www.linuxfoundation.org/collaborate/workgroups/networking/kernel_flow), você pode ver dev_hard_start_xmit na imagem http://www.linuxfoundation.org/images/1/1c/network_data_flow_through_kernel.png (Aviso, é enorme) no lado esquerdo logo abaixo da lenda. E netif_receive_skb está dentro do quadrado mais baixo à direita ("net/núcleo/dev.c"), que é alimentado do IRQ, então NAPI Poll ou Netif_RX e a única saída daqui é netif_receive_skb.

A imagem mostra até um dos dois ganchos PF_Packet - o quadrado mais à esquerda sob legenda ("Net/packet/af_packet.c") - para pacotes de saída.

Qual é a sua ferramenta? Como se conecta à pilha de rede? Se você pode localizar a ferramenta no Imagem de Network_data_flow, você receberá a resposta. Por exemplo, o Netfilter é fisgado (NF_HOOK) somente em ip_rcv (entrada) ip_output (saída local) e ip_forward (extrovertido do roteamento) - logo depois netif_receive_skb e pouco antes dev_queue_xmit.

Answer 3

Sim, essas são as ferramentas certas. O Wireshark identificará pacotes TLS e SSL, se é isso que você está usando para criptografia. Você pode fornecer à Wireshark a chave privada do servidor e descriptografar o tráfego, se necessário (exceto para modos efêmeros como DHE e ECDHE).