When the security team identifies a suspicious activity, they often turn to NetFlow or IPFIX first to gain insight into how the bad actor gained access to the internal network. Should a network incident response system used for tracking down malicious communication activities place emphasis on flow directionality?

Before I get started, the phrase “Flow Direction” can mean at least two things in the world of NetFlow and IPFIX. To the engineer who is developing software to export IPFIX, flow direction tells us where the flow was metered. I wrote a post titled ingress or egress on this already. I did it again here and here. The 2nd meaning has to do with security professionals, who want to know “who started it”. This post is about the later and geared toward malware incident response.

Flow Audit Trail

The traffic pattern of an infiltration needs to be investigated not only to identify initial access but, also to understand how the contagion moved about. Who, what, when, where and how are the crucial details needed to respond timely to an advanced cyber threat. Warehousing flows is the most viable solution for comprehensive traffic auditing.

Although the routers, switches, firewalls, probes and even IDS appliances may generate the flows, it is the collector that fills the DVR or storage responsibility. Beyond warehousing the data for long periods of time, the collector must:

  • Scale the collection into the millions of flows per second in order to meet the needs of the business
  • Support a distributed architecture that collects locally as flow volumes generated can crush WAN connections.
  • Provide the deep flow reporting and filtering needs of the investigators who have to thoroughly analyze the traffic patterns

About Flow Direction

But, what about determining flow direction? Does the security admin need to know if the source IP address was the client or the server in the connection?

Until recently, NetFlow and IPFIX provided little insight into which IP address in a connection was the client and which was the server. Vendors like Cisco however, now provide the option of exporting client/server IP addresses rather than source/destination IP addresses. The question is: does this connection relationship help when investigating a security breach? The answer is ‘maybe’.

flow directionality

Flow Directionality

The value of the above report which shows the client on one side and the server on the other is identified by observing the TCP flags in the initial connection handshake:

  • Client > Server (SYN)
  • Server > Client (SYN,ACK)

The client sends the SYN to initiate the TCP connection and therefore it is assumed to have started the data transfer. This determination of flow directionality by relying on TCP flags works okay until UDP is introduced by the malware. In the report above, I added a filter to include only UDP traffic and the report came back with “no data” because TCP flags are obviously not exported in UDP flows. My point is that determining which IP address is the client or the server really doesn’t matter because malware uses UDP nearly as much as TCP (i.e. we need to pay attention to UDP just as much as TCP). You might want to read my post on Security Vendors Teaching Bad Actors How to Get Past Firewalls.

Flow Deduplication

Beyond the hardware figuring it out for us, there is no reliable way to ascertain flow direction when pouring through traditional flow exports. Security vendors claiming to determine flow directionality after performing deduplication or by some other means that they are not willing to disclose the details of are probably also selling ocean front property in Arizona. Consider reading this post on Deduplication and Stitching.

Stay tuned for Part 2 on NetFlow Directionality in July of 2015……

Mike Patterson author pic

Michael

Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.

Related