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 v5||Disk Reads||Handle Count||Page File Usage||Proprietary Logs|
|BiFlow Octets||Disk Space||MAC Address||Parent Process||Syslogs|
|Connection State||Disk Write Time||Memory Usage||Process CPU||Thread Count|
|CPU Utilization||Event Logs||Netstat Details||Process ID||Username|
|Destination FQDN||Executable Path||Operating System||Process Memory||Virtual Size|
|Disk I/O||File Hash -SHA256||OS Version||Process Name||Working Set Size|
The above is only a partial listing.
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.
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.