, confirming that 147.28.145.159 is our streaming video server. The output from this includes these same lines: The filter we’ll use comes from column 4 (bolded above): pcap_stats.py -r sensor1.pcap -m 100 -b 'udp port 3478' We’ll re-analyze the pcap file, but this time restrict our view to just port 3478 using the “-b” parameter to use a BPF. Since IP address 147.28.145.159 (“”) has exactly the same number of packets and bytes we might guess that that’s the target IP for all this streaming traffic, but instead of guessing, let’s follow the process. We were taking part in a streaming webcast, so this seems likely. The hint for this says it may be WebRTC streaming audio and video. Right away we see high volume traffic: both “udp port 3478” and “host 147.28.145.159” have 1,790,872 packets and 985MB of traffic.įiltering Process and Common Types to Discard High Volume Port The columns are: 1) Number of packets of this type, 2) Total number of bytes in these packets, 3) description, 4) filter to use for this specific traffic, and 5) hint about what this traffic might be. Use pcap_stats.py -hĭuring this process we’ll be re-analyzing the packets multiple times, so it’s a good idea to work from a pcap file instead of directly from an interface.
This will report on any traffic types that show up in at least 100 packets. Here’s an example of pcap_stats reading packets from a pcap file: pcap_stats.py -r sensor1.pcap -m 100 This open source tool reads packets from a network interface or pcap file and reports back on both the number of packets and the total number of bytes they contain. I’m going to recommend our pcap_stats ( ). Locating these flows isn’t too difficult if you have the right tool. This is exactly what we’re aiming to do identify high volume traffic that we no longer want to capture and analyze, discard it, helping our capture and analysis tool to keep up. If I want to see everything except that replication traffic, I invert it with “not” (a “discard” filter): tcpdump -i eth0 -qtnp 'not (host 7.8.9.10 and host 14.15.16.17 and tcp port 3306)' , which will just show me that replication traffic. I can use that BPF in almost any application that captures packets to only show me this replication traffic, like: tcpdump -i eth0 -qtnp '(host 7.8.9.10 and host 14.15.16.17 and tcp port 3306)' If I have two mysql database servers, a primary (7.8.9.10) and a secondary (14.15.16.17) and have a lot of replication traffic going from the primary to the secondary, I can use this BPF to describe this traffic: '(host 7.8.9.10 and host 14.15.16.17 and tcp port 3306)' This may end up discarding between approximately 10% and 80% of the raw packets, leaving our capture and analysis tools able to keep up with the remaining 90% to 20% of the incoming stream. Once we’ve found these, we put together a BPF (a “Berkeley Packet Filter”) an expression that specifically describes this traffic so that we can tell the capture library to discard it. The goal is to find one or more traffic types that 1) have lots of packets and/or lots of combined bytes in those packets, 2) are limited to a small number of ports and IP addresses, and 3) are trusted very unlikely to have anything malicious inside.
#WIRESHARK CAPTURE PACKETS BETWEEN TWO HOSTS HOW TO#
In that blog I mentioned discarding high volume flows as a way to avoid those problems, but never explained how to find them. We’ve talked about the general process of speeding that up (see “ Improving Packet Capture Performance“). It’s easy to have a system where the network interface, processor, or disk can limit how many packets can be processed in a second, leading to packet capture loss. One of the most common problems in capturing and analyzing packets is making sure that the capture system can keep up with the flood of traffic.
0 kommentar(er)
