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.
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):
I may wait to do a capture until load is lower (so as to not impact back pressure, timing of events in a brittle system)
If there is redundancy in place I may decide to go ahead and capture immediately if it’s a high priority (hopefully we tested said redundancy!)
If we are actively failing stuff then I may just jump in and capture with out regard to safety (accepting even more failure in the face of failure)
If I’m in a non-production environment then I can accept failure conditions more readily (depends on your team)
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.
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.