Le décapage de la charge utile à partir d'un tcpdump?

Est-il un moyen automatisé (soit dans tcpdump ou par l'intermédiaire d'une aide de l'app Là-bas) pour générer un fichier pcap qui contient uniquement Ethernet, IP et la Couche 4 (TCP dans mon cas) des en-têtes, de sorte qu'il n'y a pas de charge/de données d'application dans le résultat de l'évaluation du ppce? J'ai constaté que depuis l'en-tête de tailles varient souvent, il est impossible d'en choisir une taille de capture qui ne prends pas toutes les données de la charge utile.

InformationsquelleAutor caw | 2011-12-09
  1. 9

    Vous pouvez dépouiller le TCP charge utile très facilement avec Python scapy module

    AVANT

    [mpenning@hotcoffee tshark_wd]$ tcpdump -n -r sample.pcap 
reading from file sample.pcap, link-type EN10MB (Ethernet)
00:25:42.443559 IP 192.168.12.237.1052 > 192.168.12.236.22: Flags [P.], 
    seq 2445372969:2445373021, ack 1889447842, win 63432, length 52
00:25:42.443607 IP 192.168.12.236.22 > 192.168.12.237.1052: Flags [.], 
    ack 52, win 65535, length 0
00:25:42.443980 IP 192.168.12.236.22 > 192.168.12.237.1052: Flags [P.], 
    seq 1:389, ack 52, win 65535, length 388

    CHARGE UTILE DE DÉCAPAGE

    L'exécution de ce en tant que root sous linux...

    #!/usr/bin/env python
from scapy.all import *
INFILE = 'sample.pcap'
OUTFILE = 'stripped.pcap'
paks = rdpcap(INFILE)
for pak in paks:
    pak[TCP].remove_payload()
wrpcap(OUTFILE, paks)

    APRÈS

    [mpenning@hotcoffee tshark_wd]$ tcpdump -n -r stripped.pcap 
reading from file sample.pcap, link-type EN10MB (Ethernet)
00:25:42.443559 IP truncated-ip - 52 bytes missing! 192.168.12.237.1052 
    > 192.168.12.236.22: Flags [P.], seq 2445372969:2445373021, 
    ack 1889447842, win 63432, length 52
00:25:42.443607 IP 192.168.12.236.22 > 192.168.12.237.1052: Flags [.], 
    ack 52, win 65535, length 0
00:25:42.443980 IP truncated-ip - 388 bytes missing! 192.168.12.236.22 
    > 192.168.12.237.1052: Flags [P.], seq 1:389, 
    ack 52, win 65535, length 388

    Dans le tcpdump ci-dessus, notez le "XX octets manquants!" des messages. C'est parce que nous avons supprimé le TCP charge utile.

    InformationsquelleAutor Mike Pennington
  2. 0

    Si le simple fait de tronquer serait travailler pour vous, vous pouvez utiliser:

    tcpdump -i eth0 -s 96 -w test1.pcap

    Plus tard, vous pouvez l'analyser avec wireshark.

    • Malheureusement, l'OP est correct, il n'existe aucun moyen de prédire de façon fiable la longueur des en-têtes TCP, en raison de la TCP Options de champ. Pour la plupart, c'est la seule partie de l'adresse IP / TCP en-têtes qui a une grande chance de différentes longueur. Fixe snaplen valeur ne garantit pas que vous avez toujours tronquer le TCP de la charge utile au bon endroit.
    InformationsquelleAutor ILYA Khlopotov
  3. -2

    Ma solution a été comme suit. J'aimerais entendre comment les autres le font sans bibliothèques externes ou de troncature. J'aimerais entendre comment les autres réalisé cela, parce que j'ai été incapable de trouver le remove_payload() fonction dans le Scapy de la documentation, en faisant cette réponse inutilisable.

    #read pcap file 
pkts = rdpcap("packet-capture.pcap")

#write packet with payload "XXXXXXXXXX"
for pkt in pkts:
     pkt.load = "XXXXXXXXXX"

#write new pcap
wrpcap("new.pcap", pkts)

    Le problème avec ceci est que, lors de la lecture à l'aide de tcpdump, il laisse un octets manquants! pour la src IP. Je peux vérifier l'infromation est toujours là à l'aide de scapy via

    pkts[_packet_num].load

    Est-il un moyen de régénérer l'ensemble de la capture de sorte qu'il semble comme si elle a été altérée?

    • Ceci ressemble plus à une autre question que de réponse. Peut-être envisager de demander une autre.
    InformationsquelleAutor user2938818