The packet analysts “self check”

One thing all members of our packet analysis team do every once in a while is to check what their own laptop/PC is doing on the network – meaning, that we just close all programs and run Wireshark to see what packets are still going in and out. If we’re in paranoid mode for some reason, we even grab a network TAP and an additional “known good” PC to capture the packets, just to make sure that no malware is hiding packets from us. Sometimes we also let some program run to see what it does while the user doesn’t do anything. And as my buddy and “trace connoisseur” Eddi (also, one of the most paranoid IT people I know ;)) always says: “You need to be able to explain each and every packet that goes in and out of your PC.”

Capturing packets of VMware machines, part 2

In the first post I described how to capture packets in VMware vSphere environments when dealing with standard vSwitches. While that works fine, some larger installations have an even better way of doing network captures of virtual machine traffic, provided by the so-called Distributed vSwitches. Unfortunately, those special vSwitches require a Enterprise Plus license, so all installations that run on Enterprise or less do not get these and have to stick with standard vSwitches.

Firewall trouble

A few days ago my connection(s) to the computing center suddenly degraded, meaning that I suddenly could not contact some of my servers anymore or only after waiting for sometimes minutes, while others worked fine. I checked the Icinga monitoring system and saw that everything was fine, except the firewall, which seemed to have a lot more latency than usual when forwarding packets. Then, my provider sent me and email that his own monitoring system was seeing problems with my firewall, too, and shortly after that a SMS arrived telling me that it seemed to have gone belly up. Uh oh.