Love this article! I’m embarrassed to admit I’ve never thought about collecting the data with tcpdump (which I’ve been using for decades at this point :) and viewing it in Wireshark.
Probably safer to capture it in tcpdump than Wireshark - and then you can view the capture file off line as well.
I think that was the main thing I realised reading this; at first I thought “why wouldn’t I just collect with wireshark as well?”, but duh, I need to capture on my servers too!
I didn’t follow, what’s wrong with using tshark on servers?
I fully admit that I only use tshark more commonly than tcpdump because I find tshark a little easier to get what I’m looking for. I’m trying to decide if I should look into tcpdump more for safety considerations in production environments.
Some of the things I consider when capturing on servers (using tcpdump or tshark):
tshark is totally fine! I just didn’t know it existed, nor did I know exporting tcpdump output into Wireshark was a thing (etc. etc.), so it was always “do I install Wireshark (and as a result, X and half of the world) onto this server?”, and the answer was usually “heck no, keep X away from that”.
Using tshark directly I have no problems with :) I just am super familiar with Wireshark’s GUI, so being able to use that even with data collected from servers is a big positive.
Ah, ha. I understand, and you’re totally right to stay away from installing unnecessary X packages on a server. I know for sure that tshark installs with limited dependencies (no X) on Debian.
Tcpdump and rotating capture files helped me sniff out a switch with a bad port. It’s a wonderful tool to know.