Documenting a Problem

I remember talking to a group about the ‘superman syndrome’ where the analyst wants to swoop in and save the day. I explained that like most forensic tasks, protocol analysis can be tedious, confusing and downright boring at times. Alright who wants to capture some packets now!?

If you can’t see it, you can’t fix it. That is why I like to use protocol analysis to minimally document the problem that I’m experiencing. Even if the packets don’t show any anomalies, it is worth knowing. If you do see an anomaly, you might not have the solution but at least you know what it looks like when its broken.

Ideally protocol analysis is most helpful when you have two traces to compare; the good and bad trace. In most realistic scenarios, the client will not have a good trace and just the current bad trace. I’m our classes I review how to make use of what you have.

In this example the customer had a DSL line with an issue and another DSL line what worked fine. The customer mentioned that whenever the DSL circuit ‘acted up’, they simply rebooted the modem. Both DSL circuits went to the same carrier, ordered at the same time, provisioned the same way and even use the same hardware. Perfect, example of something I can compare. I also noticed that these are not just modems, but they route, dhcp, firewall and NAT.

What I found, is that the problem circuit was having issues passing larger frames, while the other had no issues. After the reboot the problem circuit now behaves like the good one. Upon further investigation I noticed the problem modem had older firmware and suggested they get that firmware updated.

So, even though I couldn’t ‘fix’ the problem, we know exactly what the problem is and what to look for if the problem returns.

Enjoy