The traffic represented by NetFlow data is not directly analysed. Instead, the exported NetFlow records are converted into
connection logs and host and application protocol data.
As a result, there are several differences between converted NetFlow data and the discovery and connection data gathered directly
by your managed devices. You should keep these differences in mind when performing analysis that requires:
-
Statistics on the number of detected connections
-
Operating system and other host-related information (including vulnerabilities)
-
Application data, including client information, web application information, and vendor and version server information
-
Knowing which host in a connection is the initiator and which is the responder
Network Discovery Policy versus Access Control Policy
You configure NetFlow data collection, including connection logging, using rules in the network discovery policy. Contrast
this with connection logging for connections detected by managed devices, which you configure per access control rule.
Types of Connection Events
Because NetFlow data collection is linked to networks rather than access control rules, you do not have granular control over
which NetFlow connections the system logs.
NetFlow data cannot generate Security Intelligence events.
NetFlow-based connection events can be stored in the connection event database only; you cannot send them to the system log
or an SNMP trap server.
Number of Connection Events Generated Per Monitored Session
For connections detected directly by managed devices, you can configure the access control rule to log a bidirectional connection
event at the beginning or end of a connection, or both.
In contrast, because exported NetFlow records contain unidirectional connection data, the system generates at least two connection
events for each NetFlow record it processes. This also means that a summary's connection count is incremented by two for every
connection based on NetFlow data, providing an inflated count of the number of connections that are actually occurring on
your network.
Because the NetFlow exporter outputs records at a fixed interval even if a connection is still ongoing, long-running sessions
can result in multiple exported records, each of which generates a connection event. For example, if the NetFlow exporter
exports every five minutes, and a particular connection lasts twelve minutes, the system generates six connection events for
that session:
-
One pair of events for the first five minutes
-
One pair for the second five minutes
-
A final pair when the connection is terminated
Host and Operating System Data
Hosts added to the network map from NetFlow data do not have operating system, NetBIOS, or host type (host vs network device)
information. You can, however, manually set a host’s operating system identity using the host input feature.
Application Data
For connections detected directly by managed devices, the system can identify application protocols, clients, and web applications
by examining the packets in the connection.
When the NetFlow records are processesed, the system uses a port correlation in /etc/sf/services
to extrapolate application protocol identity. However, there is no vendor or version information for those application protocols,
nor do connection logs contain information on client or web applications used in the session. You can, however, manually provide
this information using the host input feature.
Note that a simple port correlation means that application protocols running on non-standard ports may be unidentified or
misidentified. Additionally, if no correlation exists, the system marks the application protocol as unknown
in connection logs.
Vulnerability Mappings
The system cannot map vulnerabilities to hosts monitored by NetFlow exporters, unless you use the host input feature to manually
set either a host’s operating system identity or an application protocol identity. Note that because there is no client information
in NetFlow connections, you cannot associate client vulnerabilities with hosts created from NetFlow data.
Initiator and Responder Information in Connections
For connections detected directly by managed devices, the system can identify which host is the initiator, or source, and
which is the responder, or destination. However, NetFlow data does not contain initiator or responder information.
When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host
is using, and whether those ports are well-known:
-
If both or neither port being used is a well-known port, the system considers the host using the lower-number port to be the
responder.
-
If only one of the hosts is using a well-known port, the system considers that host to be the responder.
For this purpose, a well-known port is any port that is either numbered from 1 to 1023, or that contains application protocol
information in /etc/sf/services
on the managed device.
In addition, for connections detected directly by managed devices, the system records two byte counts in the corresponding
connection event:
Connection events based on unidirectional NetFlow records contain only one byte count, which the system assigns to either
Initiator Bytes or Responder Bytes, depending on the port-based algorithm. The system sets the other field to 0. Note that if you are viewing connection summaries
(aggregated connection data) of NetFlow records, both fields may be populated.