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
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……