Monitoring DNS can help you use Netflow data more efficiently and effectively, saving both time and money.
If you want to have any chance to successfully secure your infrastructure, visibility into network traffic is crucial. Afterall, unusual traffic patterns can tip you off to all manner of potential problems, like malware that has slipped by your outer layers of security, devices hogging bandwidth, etc.
To fulfill this role, many administrators rely on NetFlow — introduced by Cisco back in 1996 — which is traditionally considered the go-to tool for keeping track of data traveling within your on-premise network. Operating at the router level, NetFlow records IP transactions as well as other protocols like TCP and UDP. While NetFlow is still the most recognizable name in the segment, many popular alternative tools are also available that collect the same sort of information. For the purposes of this article, we will refer to all data of this type simply as “flow data.”
However, as useful as it is, trying to actually glean actionable information from flow data can expose some of its major drawbacks and blindspots. Even with a solution in place to capture flow data, the sheer volume of information generated at larger organizations can quickly become overwhelming — counterproductively reducing the very visibility you were trying to obtain in the first place. And once you add cloud infrastructure into the mix, these same big data-related problems — including costs related to storage and processing — become even harder to grapple with.
Furthermore, the organizations that have traditionally utilized NetFlow on-premise tended to be highly connected companies — often with network peering agreements that direct traffic along contracted routes — who used the technology in a larger capacity to engineer their traffic loads. However, once companies began moving their operations to the cloud en masse, this primary use case has become less relevant.
Despite these drawbacks, flow data is still important, as is pursuing the goal of having complete visibility across your infrastructure, especially from a security and operational perspective. If you were able to more efficiently utilize the flow data you’re collecting, you could potentially sidestep many of the issues related to big data management.
DNS telemetry offers a great way to baseline and monitor your production environment, giving you insight into who your devices are communicating with both within your network and outside of it — but that is only half the conversation. When you use DNS to identify a potentially suspicious conversation, reviewing flow data can validate whether the conversation actually occurred, greatly enhancing your overall visibility, and therefore, resiliency.
For example, let’s imagine that your company’s production environment is entirely hosted in the ubiquitous “cloud.” Being the dutiful administrator you are, you happen to be ahead of the curve and are already logging all of your recursive DNS queries as well as the netflow records for your environment. How do you go about using that data in a complimentary manner that solves the big data problem? Well, instead of trying to look for the proverbial needle in the haystack by analyzing flow data in isolation, you can utilize your DNS telemetry to highlight exactly where you should be searching. In this hypothetical scenario, you happen to notice that one of your development databases made an anomalous DNS query to foo.bar.xyz — but did the machine actually have a conversation with that remote endpoint? By querying your flow data for just this specific source and destination pair, you can quickly answer that question and react appropriately.
When it comes to visibility, more telemetry isn’t necessarily better, especially if its volume becomes a burden. However, by uniting disparate but complimentary telemetry, you can cut through the noise and get a much clearer picture of what’s going on within your environment.
