Ask Your Question
0

capture only destination IPs

asked 2019-09-19 11:00:57 +0000

We're preparing a mass migration of servers to a completely new network. To build an overview of the interactions between all our servers, we're thinking on leveraging Wireshark to capture all IPs our Windows servers are connecting to. Our Linux team already did something similar with native tool tcpdump. They used capture filter ''''tcp[13]=18' or proto ICMP or proto UDP" to look at TCP SYN packages or ICMP/UDP traffic, which (if I googled properly) translates to filter "tcp[0xd]&18=2 or proto ICMP or proto UDP" in Wireshark.

Is there a more efficient way, cause the pcap file can still grow quite big on busy servers?

edit retag flag offensive close merge delete

Comments

You can set a snaplen to only capture up to and including the IP header without saving the payload.

cmaynard gravatar imagecmaynard ( 2019-09-19 14:16:14 +0000 )edit

ok, thanks, that's indeed a good option. I'll test if our tool to analyze the pcaps still works when I added '-s 64' in the cmdline.

NicoWeytens gravatar imageNicoWeytens ( 2019-09-20 07:13:34 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2019-09-21 18:25:41 +0000

cmaynard gravatar image

Maybe a better, simpler solution is to just run tshark, making use of its statistics options? For example:

tshark -i some_interface -s 64 -q -z conv,ip,"ip.addr==1.2.3.4"

... where 1.2.3.4 is the IP address of a particular server you're interested in. If you have multiple servers, you can just or the filters together, e.g., "ip.addr==1.2.3.4 or ip.addr==2.3.4.5". If you want all conversations, you can omit the filter altogether and post-process if you need to.

edit flag offensive delete link more

Comments

Interesting point. However, I can't deviate from our Linux team's way of working too much if we want to re-use their post-processing tooling. The result should still be a pcap file per server, which is then handed over to them to merge with their data.

NicoWeytens gravatar imageNicoWeytens ( 2019-09-23 07:54:45 +0000 )edit
0

answered 2019-09-21 07:59:01 +0000

SYN-bit gravatar image

If you need to create an overview of connections and are not interested in the amount of the traffic, then you can iteratively remove traffic from the capture once you've added it to the list of interactions. As there are probably a few top conversations, removing those from the capture process might significantly reduce the capture sizes.

So basically:

  1. Capture traffic for a short while
  2. Analyze the traffic and and the top interactions to your list
  3. Add these interactions to the filter in a not clause
  4. Go back to step one, rinse and repeat :-)

The filter will become something like:

(tcp[13]=18 or proto icmp or proto udp) and not (host 10.0.0.1 and udp port 53) and not (host 10.0.2.10 and tcp port 80) and not ... etc

Some small notes on your capture filter:

  • Both tcpdump and wireshark use the same filtering language (BPF), no need to convert
  • protocol names in a BPF filters are case sensitive, so you need to use "udp" instead of "UDP" and "icmp" instead of "UDP"
  • tcp[13]=18 means: look at offset 13 in the packet and only capture the packet when its value is 18. This means the SYN-bit (2) and the ACK-bit (16) both needs to be set, but all other TCP flags must be unset
  • tcp[0xd]&18 = 2 means: look at offset 0xd (13 in decimal) and then take it's value and then only look at the bits for SYN (2) and ACK (16) by doing a logical AND. If the result is exactly 2, then capture the packet. This means, the SYN-bit (2) needs to be set, the ACK-bit (16) needs to be unset and all other bits in the TCP flags can be set or unset (as they were masked by the AND (&) operator.
edit flag offensive delete link more

Comments

Based on your notes I'm reviewing my filter. I've now reverted back to using tcp[13]=18 (same syntax as our Linux guys used), but I thought that gave a syntax error during previous tests. Apparently I did something else wrong then, cause now it's perfectly accepted. Tnx for your explanation! Btw, when I use udp/icmp in lowercase, dumpcap does throw a syntax error. It does accept them in uppercase, and I see udp/icmp traffic in my test captures.

NicoWeytens gravatar imageNicoWeytens ( 2019-09-23 08:31:57 +0000 )edit

Ah... I overlooked it a bit. You can either use "icmp or udp" (lowercase) or "proto ICMP or proto UDP" (uppercase, as now ICMP and UDP are just defined values instead of ip protocols). Sorry for the noise :-)

SYN-bit gravatar imageSYN-bit ( 2019-09-23 09:37:11 +0000 )edit

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: 2019-09-19 11:00:57 +0000

Seen: 109 times

Last updated: Sep 21