One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the flow of our network traffic. This is a huge improvement over the traditional method of parsing row after row of big data in a structured table format. As the IoT becomes a reality and traffic volume continues to grow at a consistent rate, we need a way of visualizing this traffic. While we’re provided many graph types that help to convey information through colors, size or position, Plixer is excited to announce the inclusion of its latest graph type, the Sankey Flow Graph!
For those who aren’t familiar, Sankey diagrams are specifically designed to visualize both traffic flow and volume as represented by connected arrows. The width of the arrows is directly proportional to the quantity of flows. Sankey diagrams place a visual emphasis on significant data transfers or traffic flowing within a system. In our application of the diagram, we’ve found that this graph method can be used in wide variety of beneficial reports. Today I’d like to talk about a few use cases in which Sankey graphs can help you easily spot network issues while providing a better understanding of traffic flow though our networks.
Through personal knowledge of how Sankey diagrams have traditionally been used and an understanding of how they can now be leveraged, I wanted to share examples of some real-world and valuable use cases!
In this first example let’s look at a rather simple use case. Here I’ve built a report to monitor all flows being sent to Scrutinizer from a flow replicator:
I’ve isolated a core switch and created a filter for UDP port 2055. This very simple report is giving us terrific visualization of how traffic is being replicated on our network. On the left side of the report (source addresses) we can see the IP addresses for each of our flow exporters. Looking at the middle of the report, we see that all the exported traffic is UDP port 2055 (all NetFlow datagrams are UDP packets and port 2055 being the most widely used port for exporting flow data). Finally the right hand side of the report shows the destination addresses for the collectors receiving the replicated flow data. As you can see, we have a large number flow collectors in use for lab purposes. In an average production network, you would only have 1-3 collectors represented. This easy to create report provides the ability to visually verify flows are being sent to the correct collector.
In my second example, let’s take it up a notch and isolate a specific user on our network. In this example, I’ve been asked to investigate a specific user, and identify all of the hosts with whom they have communicated. Again I’ve built a very simple report. I have isolated the same core switch, because I know all of that user’s traffic would have passed through it. I’ve then added a filter to isolate the traffic sourced from the user in question:
With one simple report I have isolated the user in question and have shown all of the hosts with whom they have communicated. I can also provide a nice visualization of their traffic flow. Now to add more contextual detail to our analysis, I can take it a step further. In the next image, I’ve changed the report type from Host-to-Host to a more detailed Conversations Well Known Ports report:
Just by pivoting to a different report type, I’ve added much more context to our traffic analysis. Not only can I show all of the individual hosts this user has communicated with, but I can now display the types of communication based on the port and protocol in use, all while very cleanly displaying the flow of traffic.
So far I’m loving this new graph type! In our next example let’s look at a more specific use case. I want to know how much of our VoIP traffic is being tagged with a DiffServ code point (DSCP) value:
This specific example is taking advantage of Cisco NBAR2 exports. I’ve filtered on our Cisco exporter that provides NBAR2 data and additionally added filters for the applications in use with VoIP. Based on this report, we can see that a large amount of the traffic wasn’t being tagged by the host, but was being tagged by the PBX. Again the report I built was very simple to create, using only three filters to isolate our VoIP traffic. The information we gained back from this simple report however is very valuable to the admin/engineer.
For my final examples I want to show reports focused on security. For this first security related scenario, I was told a host on our network may have scanned a critical server for open ports. Again using our core switch as the data exporter, I’ve built a simple report using just two filters; 1 isolating the host in question as the source and 2 isolating our critical server as a destination:
As you can clearly see, we have confirmed that the user in question has indeed scanned our critical server for all open ports. Also, we have a very clean and detailed display of what that traffic looks like.
Let’s take a different approach on this last example. Instead of a scenario where a host was scanning one server, we want to investigate a host that has been reported to have been mapping our network. The indication is that they may have been scanning an entire subnet looking for port 22 to be open. Once again I’ve built a very simple report with our core switch as the metering point, added a filter to isolate the user as our source as well as an additional filter isolating port 22:
Clearly, it’s very easy to visualize that this single user was port scanning the entire subnet via port 22, an obvious security concern. This Sankey report provides undisputed visual proof that a security event has occurred and provides accountability to the user device.
These are just a few examples of how the new Sankey graph type can help to provide a very easy to interpret visual representation of your traffic flow. If you would ever like to get additional information about the Sankey graph, or find more real world use cases, don’t hesitate to reach out to us here!