Ask Your Question
0

how to identify the VMs of traffic capture

asked 2020-12-08 12:42:17 +0000

bianmingkai gravatar image

I have two VMs and network configuration below :

VM1(192.168.1.10,client) -------------------- VM2 ( 192.168.1.20,also a web server ,listening on tcp port 80)

running the command of traffic capture from VM1:

VM1: tcpdump -i eth0 host 192.168.1.20 -w /tmp/traffic.pcap

then, VM1: curl 192.168.1.20

then we stop the traffic capture from both VMs , Since we know that this traffic capture from VM1, but what if we just share this file with someone who doesn't know where does the traffic capture from , is there any way for someone who has no idea about where the traffic capture from to identify where the traffic capture from ? thanks

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-12-08 18:27:56 +0000

Jim Aragon gravatar image

updated 2020-12-08 22:37:36 +0000

grahamb gravatar image

Possibly. There are a couple of ways you can try to determine if a trace file was captured on one of the endpoints in the trace:

  1. Look for frames smaller than 60 bytes. The minimum Ethernet frame size is 60 bytes, plus a four-byte frame check sequence, for a total of 64 bytes. If a frame is smaller than 60 bytes, then padding bytes will be added to bring it up to 60 bytes then the four-byte frame check sequence will be appended. When Wireshark sees an outgoing frame, the four-byte frame check sequence hasn't been added yet, and when Wireshark sees an incoming frame, the frame check sequence has already been stripped off, (at least on the Windows systems that I'm familiar with; some systems do pass the frame check sequence to Wireshark). So the smallest Ethernet frame that Wireshark should see is 60 bytes (or 64 bytes if the checksum is present). If you see a frame smaller than 60 bytes, then it was below the minimum Ethernet frame size and the padding had not yet been added when Wireshark saw the frame, so the system that transmitted that frame is where the packets were captured. In this case, all the undersized frames will be from one host. This can easily be done with a quick display filter:

    frame.len < 60

    Or, for a more sophisticated filter that accounts for whether the frame check sequence is present or not:

    (eth.fcs && frame.len < 64) || (!eth.fcs && frame.len < 60)

  2. Turn on IP, TCP, UDP, and Ethernet checksum validation and look for packets with bad checksums. Almost all modern NICs do checksum offloading, which means that the checksum is calculated and applied by the NIC after Wireshark sees an outgoing frame. If you see bad checksums only on packets transmitted by one host, then that is probably the host where the data was captured. The checksums are good when the frames are transmitted on the wire. If the checksums were actually bad, then the packets with bad checksums would have been retransmitted or the communication would fail. So if you see bad checksums from one host only with checksum validation on, the packets were probably captured on that host.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-12-08 12:42:17 +0000

Seen: 1,205 times

Last updated: Dec 08 '20