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:

  1. 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”.
  2. 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.

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