In Tools wie tcpdump, wann genau werden die Netzwerkpakete erfasst?

Question

Eines der Tools, die ich verwende, verwendet die Verschlüsselung/Entschlüsselung, um Daten über das Netzwerk zu senden. Ich modifiziere das Tool und ich muss sicher sein, dass die Daten tatsächlich in einer verschlüsselten Form gesendet werden.

Sind Wireshark und tcpdump die richtigen Werkzeuge für den Zweck? Zu welchem ​​Zeitpunkt erfassen sie während der Übertragung die Netzwerkpakete?

Answer 1

Beide Tools erfassen die Daten genau, wenn sie über die Leitung ausgegeben werden. (Stellen Sie es sich als eine Art Äquivalent von "tee" für die Ausgabe, die sowohl auf dem Bildschirm als auch in der Datei angezeigt wird; auch hier gehen die gleichen Daten an den Socket sowie an tcpdump oder was auch immer.)

Also ja Wenn Ihr Tool korrekt konfiguriert ist, um die Daten vor dem Senden zu verschlüsseln, sollten tcpdump oder Wireshark das in ihren Paketerfassungen widerspiegeln.

Answer 2

Ja, das sind die richtigen Werkzeuge. Wireshark wird TLS- und SSL-Pakete identifizieren, wenn Sie das zur Verschlüsselung verwenden. Sie können Wireshark den privaten Schlüssel des Servers zur Verfügung stellen und den Datenverkehr bei Bedarf entschlüsseln (außer für kurzlebige Modi wie DHE und ECDHE).

Answer 3

Kurze Antwort: Pakete werden am Ende des Software-Netzwerk-Stacks (z. B. unter Linux) abgegriffen.

Lange Antwort mit Code Graben in tcpdump, libpcap und Linux-Kernel 3.12:

Sowohl Wireshark und tcpdump verwendet libpcap zum Beispiel

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

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

die wiederum ein Paket installieren Filter über setfilter_op und activate_op. Es gibt viele Implementierungen dieser Operationen, und ich denke, dass auf den letzten Linux PF_PACKET mit pcap_activate_linuxlibpcap-1.5.3-2/pcap-linux.c#L1287 verwendet werden:

/* 
* 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 im Kernel implementiert, in der Datei net/packet/af_packet.c. Initialisierung von PF_SOCKET wird in packet_do_bind mit register_prot_hook(sk) Funktion erfolgen (wenn das Gerät in UP-Zustand ist), which callsdev_add_pack von net/core/dev.c den Haken registrieren:

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 } 

Ich denke, pf_packet Handler - die tpacket_rcv(...) function - wird in ptype_all registriert werden .

Hooks, in ptype_all registriert sind für ausgehende Pakete von dev_queue_xmit_nit („Unterstützungsroutine. Sendet ausgehenden Rahmen zu einem Netzwerk aktuell verwendeten Hähne.“) Genannt wird mit list_for_each_entry_rcu(ptype, &ptype_all, list) { ... deliver_skb ...} .. func ruft deliver_skb die FUNC, die für tpacket_rcv Libpcap ist.

dev_queue_xmit_nit aus dev_hard_start_xmit (Line 2539 in net/core/dev.c) genannt, welche AFAIK die letzte Stufe in Linux Handhabung (für ausgehende Pakete) von geräteunabhängigen Paketstapel ist die Vernetzung.

Die gleiche Geschichte ist für eingehende Pakete, ptype_all-registrierte Hooks werden von __netif_receive_skb_core mit demselben list_for_each_entry_rcu(ptype, &ptype_all, list) {.. deliver_skb..} aufgerufen.__netif_receive_skb_core aus __netif_receive_skb in den Anfängen der Umgang mit eingehenden Pakete

genannt

Linux Foundation hat eine gute Beschreibung Stapel Vernetzung (http://www.linuxfoundation.org/collaborate/workgroups/networking/kernel_flow) Sie dev_hard_start_xmit auf das Bild http://www.linuxfoundation.org/images/1/1c/Network_data_flow_through_kernel.png sehen (Warnung, es ist riesig) auf der linken Seite nur unter der Legende. Und netif_receive_skb ist innerhalb der rechten unteren Quadrat ("net/core/dev.c"), die von IRQ, dann NAPI Poll oder netif_rx gespeist wird und der einzige Ausgang von hier ist netif_receive_skb.

Das Bild zeigt sogar einen von zwei pf_packet Hooks - das linke Quadrat unter der Legende ("net/packet/af_packet.c") - für ausgehende Pakete.

Was ist Ihr Werkzeug? Wie verbindet er sich mit dem Netzwerk-Stack? Wenn Sie das Werkzeug in Network_data_flow picture finden können, erhalten Sie die Antwort. Zum Beispiel ist Netfilter süchtig (NF_HOOK) nur in ip_rcv (eingehende) ip_output (lokale ausgehend) und ip_forward (ausgehend von Routing) - kurz nach netif_receive_skb und kurz vor dev_queue_xmit.