The problem with baselining is that very few people do it. In some cases, the analyst has “paralysis due to analysis.” In other words, they over think what is involved in producing a baseline and never do one.
I will give you the best tip I know regarding baselining: “just capture and start something.” Don’t worry about ‘getting everything’ or expecting to ‘understand every packet you see.’ Decide on a goal for your baseline and meet that goal. Heck, just capturing some packets, giving the trace file a meaningful name, and filing it away is incredibly helpful.
One of my favorite baselines is a ‘boot-up’ baseline since it contains so much valuable information. Examples of what I like to generally record is:
- Client MAC/IP address
- Network captured from (i.e VLAN, subnet, etc)
- Boot time
- Total Bytes or packets transferred
- Protocol used and not used
- List of servers client converses with
- Dhcp options and any relay ip helper address information
- Commands not responded to
With Wireshark, all this information can be entered into its File Comments (the little pencil on the bottom left corner of the application).
Of course, every device or application will have additional items to document but the goal here is to document how the data was captured, tool used, and the immediate goal you identified. The same trace file can be used for other future reviews or as a comparison if something goes awry.
In this example, we received our first Cisco 8832 and I thought this would be a great opportunity to capture the device bootup and investigate any anomalies. I need a way to capture the bootup traffic and using a span port was not an option in this specific environment. So, I needed a tap that passed POE (power over Ethernet) and, in this case, a regular tap where I used my Ethernet port would trip the switch port security settings. The other thing about using my Ethernet port to capture packets is that due to Microsoft filtering, possible firewall interference, and the inability to see errored packets made this option less desirable.
The trace was pretty clean with the exception of the phone sending ntp commands to an old decommissioned ntp server. Everybody’s immediate reaction was that was due to a misconfigured DHCP option. When we checked that’s was not the case.
I showed them that the ntp ip address file was provided within one of the many files that the phone downloads from their Cisco Unified Communications Manager. I documented the file and the voice admin made the change. This is a great example of simply ‘tuning and cleaning up’ the many settings in the typical corporate environment.
It’s worth noting that I use Jaspers tracewrangler to clean up the trace file for my video.
View the baselining here: