This is a continuation of Flow Directionality Support : Part 1 which should be read first.
My guess is that a flow collector vendor claiming to determine flow or NetFlow direction makes an educated guess from NetFlow v5 traffic on who initiated the connection using flow start times (using a single exporter so timestamps are relative), packet counts, and port numbers. The trouble is, finding the true relationship between two hosts is very difficult when you connect through an intermediate node or nodes where traffic is encrypted. For example, take the use of today’s peering applications such as Skype, Bittorrent, and the use of tunnels like VPN or Tor. The handshake(s) that happen after the initial connection is established is far more important. Even if a flow collection vendor could accurately determine flow directionality (which they can’t), there are really two cases to look at:
- Internal Host A and Internal Host B: In this case, two hosts you control are talking, and it’s really a matter of whether or not the communications are authorized. You have both systems to look at, so determining which one is offering the service is relatively trivial and need not involve flow “best-guesswork”.
- Internal Host A and External Host B: Host A almost certainly initiates the communications, but to what? A web site? A C&C server via Tor, P2P, or VPN? If it’s a web site or other common web service, then it’s an apparent client/server relationship. However, with “HTTPS everywhere”, it’s now very difficult to say because it could be connecting to a VPN and then on to somewhere bad. Directionality as defined by a flow collection vendor doesn’t work nearly as well today as it did 10 years ago.
Okay, I took off on a bit of a rant there. Now I’ll reel it in a little and start wrapping up this post.
Determining NetFlow Directionality
If the value behind determining NetFlow directionality is to figure out “whether a host uploaded or downloaded information”, I’m not sure the best strategy is to look at the volume of packets or bytes in either direction. Bad actors could easily upload more data in one direction (i.e. A -> B) when the actual download was in the lower traffic direction (i.e. B -> A). Do you think a bad actor would do this to try and mislead security professionals? If you want to monitor for electronic data theft, we have setup the following for several customers:
- Monitor all internal traffic headed to the internet
- Trigger 1: Set a threshold that watches for data transfers above a certain amount (e.g. 20 MB in 5 minute intervals).
- Trigger 2: Set a second threshold that counts the number of Trigger 1 events in a 24 hour period. If greater than n, increase the threat index for the host or send notification.
- Exclude traffic that will cause false positives
The above strategy isn’t fool proof but, it can be very effective and if desired, it can ignore whether the amount of traffic being uploaded to the Internet is less than the amount of data being downloaded. Malware is clever and uncovering data exfiltration requires that we monitor for more than one traffic pattern.
Flowpro Defender
I’m not sure that paying attention to flow direction was ever an effective means to identifying the most stealthy threats. At our company, we are watching connections to social media and suspicious DNS flows. This is where there is far more to be worried about as not all serious electronic data thefts involve massive byte transfers. Contact us to evaluate FlowPro Defender and learn what is hiding in your DNS traffic. Read part 3 to learn about an entirely different type of Flow Direction.