In the past two years, we have seen two more vendors enter the market of exporting IPFIX from end systems.  For those of you who are new to IPFIX, it is the standard for NetFlow.

Ziften IPFIX Support

Back in the summer of 2015, Ziften released an IPFIX agent for end systems called ZFlow.  This export is impressive because it goes beyond what is currently defined in the IANA standard.  Details include:

  • Layer 7 application and version
  • application description and base file
  • Internal Name and File Name
  • Path of executable and CMD
  • MD5 Hash
  • The user name and IP address
  • Operating system and machine name
  • Process ID adn agent UUID
  • Many other details – to much to list

If the above looks like a lot of additional overhead, it is.  When we tested it, we learned that the flows are huge and as a result, only about 3-4 fit in each Ethernet datagram.  ZFlow is innovative but, its time in the IPFIX spot light was relatively short lived. Another vendor was already working on a similar technology but, hadn’t released yet.  Along came Cisco and nvzFlow.

Cisco nvzFlow Support

Much like ZFlow, nvzFlow is installed on end systems. Companies which utilize the Cisco ASA for VPN access have the option to upgrade to AnyConnect 4.2 which contains the nvzFlow support. The details being exported in nvzFlow include username, device operating system, domain being visited and much more.  Sophisticated details are also exported such as process and parent process names with a SHA256 hash which can be used to verify the signature of the executable.  These  details allow security teams to verify the authenticity of the files which generate flows on the local system.

Open Source Solution: IPFIXify

First released in 2012, IPFIXify is a free – open source system intended to empower vendors with the ability to export the unique details from their systems. Currently, IPFIXify exports basic NetFlow elements and can be configured to export the following examples:

Basic NetFlow v5Disk ReadsHandle CountPage File UsageProprietary Logs
BiFlow OctetsDisk SpaceMAC AddressParent ProcessSyslogs
Connection StateDisk Write TimeMemory UsageProcess CPUThread Count
CPU UtilizationEvent LogsNetstat DetailsProcess IDUsername
Destination FQDNExecutable PathOperating SystemProcess MemoryVirtual Size
Disk I/OFile Hash -SHA256OS VersionProcess NameWorking Set Size

 

The above is only a partial listing.

 

similar to Cisco nvzFlow and Ziften ZFlow

Above is an example of the reporting which resembles ZFlow and nvzFlow.

IPFIX from End System Uses

By deploying IPFIXify, nvzFlow or ZFlow, security and network professionals gain real-time insight into the status and performance of the mission critical systems their business depends on. They can be pushed down to VPN users to gather details on their connection experience or they can be used on a hosted cloud service to send back details regarding the performance of the service offering.  There is however, a potential problem with deploying this type of technology.

Problem Facing IPFIX from End Systems

Most commercial IPFIX, NetFlow, JFlow, sFlow, etc. collection systems have a licensing model.  Some vendors license by flow exporting device count and others by the number of interfaces sending flows.  Regardless, having 100 or several thousand devices sending IPFIX to the same collector could chew up a lot of licenses.  As a result, we added a feature to our UDP Forwarder called the Flow Replicator which addresses this issue.

UDP Forwarder | Flow Replicator

Normally, the Flow Replicator is used to multiply UDP packets and forward them onto multiple destinations without changing the source IP address.  Only the destination IP address is modified.  As a result, the collector believes it is receiving the packets directly from the original source. In other words, the Flow Replicator is completely transparent.

With Cisco nvzFlow, Plixer IPFIXify or Ziften ZFlow you probably want all of the flows coming from the same source to avoid chewing up licenses on the collector.

 

udp fanout

The above feature tells the Flow Replicator to forward all exporters in a defined profile with a source IP address of the Flow Replicator.  In other words, both the destination and source IP addresses are modified before the UDP frames are forwarded to the collectors.

You can learn more about the Flow Replicator’s UDP Forwarding capabilities on YouTube or by contacting our team.

Michael

Michael

Michael is the Co-Founder and the product manager for Scrutinizer Incident Response System. He can be reached most hours of the day between work and home. 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. Feel free to email him.

Related