Improved nProbe Configuration File

nprobe.conf

# This configuration for nProbe exposes many more options than is available in the file provided
# when downloading nProbe.
# 
# Most likely you will only need to change the -n and -i options for your environment. However, a
# number of other options are documented in case you need them.
#
# The provided template works very well with ElastiFlow - A solution to collect and analyze network
# flow data using the Elastic Stack. ElastiFlow is available from:
# https://github.com/robcowart/elastiflow

# -V: flow export version
# It is used to specify the flow version for exported flows. Supported versions are 5 (v5), 9 (v9)
# and 10 (IPFIX).
-V=9

# -T: flow template definition
# Contrary to NetFlow v5 where the flow format is fixed, NetFlow V9 and IPFIX flows have a custom
# format that can be specified at runtime using this option.
-T="%SAMPLING_INTERVAL %IN_BYTES %IN_PKTS %IPV4_SRC_ADDR %IPV4_DST_ADDR %IPV4_NEXT_HOP %IPV6_SRC_ADDR %IPV6_DST_ADDR %IPV6_NEXT_HOP %L4_SRC_PORT %L4_DST_PORT %SRC_VLAN %DOT1Q_SRC_VLAN %SRC_TOS %TCP_FLAGS %PROTOCOL %IP_PROTOCOL_VERSION %DIRECTION %FLOW_START_MILLISECONDS %FLOW_END_MILLISECONDS %INPUT_SNMP %OUTPUT_SNMP %IN_SRC_MAC %OUT_DST_MAC %ICMP_TYPE %BIFLOW_DIRECTION %L7_PROTO_NAME"

# -U: flow template id
# NetFlow v9 and IPFIX flows format is specified in a template whose definition is sent by nProbe
# before to start sending flows. The flow format is defined by --T, where --U is used to set the
# template identifier. This option should not be used unless the default template value (257) needs
# to be changed. As based on -T nProbe can define several templates, this value is the one used for
# the first defined template.
-U=888

# -n|--collector: collector addresses
# This specifies the NetFlow collectors addresses to which nProbe will send the flows. If more than
# one is specified, they need to be separated with a comma or the --n flag can be repeated several
# times (e.g. -n 172.22.3.4:33,172.22.3.4:34 and -n 172.22.3.4:33 --n 172.22.3.4:34 are
# equivalent). When multiple collectors are defined, you can control the way flows are exported
# using the --a option (see below); if on a collector address the destination port is omitted,
# flows are sent to 2055 port and whereas if all the option is not specified, by default, flows are
# sent to the loop back interface (127.0.0.1) on port 2055. If this parameter is used, nProbe
# exports flows towards collector running at 127.0.0.1:2055. By default the UDP protocol is used
# but also TCP and SCTP (Linux only when nProbe is compiled with SCTP support and the kernel
# supports it). In this case you can specify the collector address as udp://<host>:<port>,
# tcp:// <host>:<port>, and sctp://<host>:<port>,
-n=192.0.2.1:2055

# -3|--collector-port: specifies the NetFlow collector port
# It is now possible to use the nProbe as NetFlow proxy. With --collector-port we can se the
# incoming NetFlow port on which flows are received instead of sniffing packets. nProbe is able to
# convert flows from various versions. For instance “nprobe --collector-port 2055 --i
# 192.168.0.1:2056 --V 10” converts each flow received on port 2055 to IPFIX and sends them to
# 192.168.0.1:2056.

# -i|--interface: interface name
# It specifies the interface from which packets are captured. If -i is not used, nProbe will use
# the default interface (if any). In case a user needs to activate nProbe on two different
# interfaces, then he/she needs to activate multiple nProbe instances once per interface. For
# debugging purposes it is possible to pass nProbe a .pcap file from which packets will be read. If
# nProbe is compiled and activated with PF_RING support, you can specify multiple interfaces from
# which packets are captured. For example, “-i eth0,eth1”, will merge packets received on eth0 and
# eth1 into a single traffic stream. This configuration is particularly useful when merging the two
# directions (TX and RX) of a network TAP.
-i=eth0

# -t: maximum flow lifetime
# Regardless of the flow duration, a flow that has been active for more that the specified maximum
# lifetime is considered expired and it will be emitted. Further packets belonging to the same
# flow will be accounted on a new flow.
-t=60

# -d: maximum flow idle lifetime
# A flow is over when the last packet received is older that the maximum flow idle lifetime. This
# means that whenever applicable, (e.g. SNMP walk) UDP flows will not be accounted on 1 packet/1
# flow basis, but on one global flow that accounts all the traffic. This has a benefit on the total
# number of generated flows and on the overall collector performance.
-d=15

# -l: maximum queue timeout
# It specifies the maximum amount of time that a flow can be queued waiting to be exported. Use
# this option in order to try to pack several flows into fewer packets, but at the same time have
# an upper bound timeout for queuing flows into the probe.
-l=60

# -s: snaplen
# This flag specifies the portion of the packet (also called snaplen) that will be captured by
# nProbe. By default nprobe sets the snaplen automatically according to its configuration, but you
# can override its value using thia flag.

# -p: flow aggregation
# Flows can be aggregated both at collector and probe side. However probe allocation is much more
# effective as it reduces significantly the number of emitted flows hence the work that the
# collector has to carry on. nProbe supports various aggregation levels that can be selected
# specifying with the --p flag. The aggregation format is <vlanid>/<proto>/<IP>/<port>/<TOS>/<AS>
# where each option can be set to 0 (ignore) or 1 (take care). Ignored fields are set to a null
# value. For instance the value 0/0/1/0/0/0 is useful for creating a map of who’s talking to who
# (network conversation matrix).

# -a: select flow export policy
# When multiple collectors are defined (see --n option), nProbe sends them flows in round robin.
# However it is possible to send the same flow to all collectors as a flow redirector does if the
# --a option is used.

# -O: set the number of threads that fetch packets out of the network interface.
# In general: the more threads are available, the better is the performance. However it is not
# suggested to have too many threads as in some platforms this can slow down the probe. Start with
# 1 and increase it if necessary. We suggest to run nprobe as single threaded application and
# distribute the traffic across multiple probes using PF_RING (e.g. PF_RING cluster or libzero). In
# fact adding threads you will end up spending a lot of time on synchronization without improving
# the performance. Please refer to this post
# http://www.ntop.org/nprobe/10-gbit-line-rate-netflow-traffic-analysis-using-nprobe-and-dna/ for
# more information.

# -u: input device index
# The NetFlow specification contains a numeric index in order to identify flows coming from
# different interfaces of the same probe. As multiple nProbe instances can be started on the same
# host but on different devices, the collector can use this flag to divide flows according to the
# interface number. If --u is not used, then nprobe will use 0 as interface index. Alternatively,
# if -1 is used then the last two bytes of the mac address of the flow sender are used as index.

# -Q: output device index
# Similar to --u but for the output interface.

# --vlanid-as-iface-idx <mode: inner | outer | single | double>
# nProbe can use the VLAN tag as interface identifier. Using this flag you enable this feature. As
# VLAN tags can be stacked you need to specify if the inner or outer tag will be used for the
# interface identifier. Since VLAN fields are included in the template, this is option is likely
# not necessary.

# --discard-unknown-flows <mode:0 | 1 | 2>
# nProbe includes nDPI support for analyzing packet contents in order to detect application
# protocol. The mode value can be used to:
# • 0: Export all known (i.e. those whose application protocol has been detected) and unknown (i.e.
#      the application protocol is unknown)
# • 1: Export only known flows, discarding unknown flows.
# • 2: Export only unknown flows, discarding known flows.
--discard-unknown-flows=mode:0

# -w: size of the hash that stores the flows
# The default size is 131072 and it should be enough for most of networks. In case flows are not
# emitted often and with strong traffic conditions it would be necessary to increase the hash. See
# later in this manual for knowing more about nProbe tuning.

# -W: Discard IPv6 traffic
# Use this flag if you want nProbe not to account IPv6 traffic.

# -e: flow export delay
# Some collectors cannot keep up with nProbe export speed. This flag allows flows to be slow down
# by adding a short delay (specified in ms) between two consecutive exports. The maximum allowed
# delay is 1000 ms.

# -B: packet count delay
# It specified how many flow packets need to be sent before --e is applied,

# -z: minimum TCP flow size
# Peer-to-peer applications, attacks or misconfigured applications often generate a lot of tiny TCP
# flows that can cause significant load on the collector side. As most collector setups often
# discarded those flows, it is possible to instrument nProbe via the --z flag not to emit such
# flows. Note that the --z flag affects only the TCP protocol (i.e. UDP, ICMP and other protocols
# are not affected).

# -M: maximum number of active flows
# It is used to limit the maximum number of concurrent flows that the probe can sustain. This is
# useful for preventing the probe from creating as many flows as needed and hence to take over all
# the available resources.

# -E: netflow engine
# Specify the netflow engineType:engineId into the generated flows.

# -m: minimum number of flows per packet
# In order to minimize the number of emitted packets containing flows, it is possible to specify
# the minimum number of flows that necessarily need to be contained in a packet. This means that
# the packet is not emitted until the specified number of flows is reached.
# -m=2

# -q: <host>:[<port>] flow sender address and port
# This option is used to specify the address -- and, optionally, the port -- that will be used by
# nProbe to emit the flows towards the destination indicated with -n. In practice, nProbe will
# create a socket and bind it to <host>:[port], thus allowing the user to choose the interface
# taken by the emitted flows when leaving the host. It is not possible to specify an arbitrary IP
# address. Only local interface addresses are allowed. An error is raised when trying to specify a
# non-allowed address.

# -S: sample rate <packet rate>:<flow rate>
# nProbe uses all the captured packets for calculating flows. In some situations (e.g. strong
# traffic conditions) it is necessary to reduce the number of packets that need to be handled by
# nProbe. This option specifies the sampling rate, i.e. the number of packets that are discarded
# between two packets used to produce flows. You can also specify the flow sample rate that reduce
# the egress flow rate thus lowering the load on collectors. The default value is 1:1 (no packet
# sample, no flow sample).

# -g|--pid-file:
# It specifies the path where nProbe will save the process PID.

# -o: intra templates packet export.
# It specifies the number of flow packets that are exported between two templates export.
# -o=50

# --aggregate-gtp-tunnels
# Aggregates traffic flowing in each GTP tunnel based in tunnel id.

# [--collector-sample-rate] <value>
# Specifies the sample rate of the collector (either in bytes of packets).

# --tunnel:
# Let the probe decode tunneled traffic (e.g. GTP or GRE traffic) and thus extract traffic
# information from such traffic rather than from the external envelope.

# --no-promisc:
# With this option nProbe does not use promiscuous mode to capture packets.

# --smart-udp-frags:
# Ignore UDP fragmented packets with fragment offset greater than zero, and compute the fragmented
# packet length on the initial fragment header. This flag might lead to inaccuracy in measurement
# but it speeds us operations with fragmented traffic.

# --ipsec-auth-data-len
# Length of the authentication data of IPSec in tunnel mode. If not set, IPSec will not be decoded
# but just accounted.

# --black-list
# With this option you can specify a list of networks or hosts from which all the incoming packets
# will be discarded by the probe. The accepted notation can be CIDR format or the classical
# network/netmask format.

# --biflows-export-policy <policy>
# Bi-directional flows are such when there is traffic in both direction of the flow (i.e.
# source->dest and dest->source). As mono-directional flows might indicate suspicious activities,
# this flag is used to determine the export policy:
# • 0: Export all known (i.e. mono and bi-directional flows)
# • 1: Export only bi-directional flows, discarding mono-directional flows.
# • 2: Export only mono-directional flows, discarding bi-directional flows.
--biflows-export-policy=0

# --dont-drop-privileges
# Do not drop root privileges to user ‘nobody’ when this option is specified.

# --unprivileged-user <name>
# When nprobe drops privileges (unless --dont-drop-privileges is used) the user nobody is used. It
# is possible to use another user by using this option.

# --account-l2
# NetFlow accounts IP traffic only, not counting layer 2 headers. Using this option the layer 2
# headers are also accounted in flow traffic statistics.

# --tcp <server:port>
# Delivers flows in JSON format via TCP to the specified pair server:port.

# --ndpi-proto-ports <file>
# Read the nDPI custom protocol and ports configuration from the specified file. Please refer to
# the nDPI manual for further information about the format of this file.

# --disable-l7-protocol-guess
# When nDPI is unable to detect a protocol, nProbe uses the port information to guess the protocol.
# This flag prevents nProbe from doing that, so protocols are detected only by nDPI without relying
# on default ports.

# --disable-cache
# nProbe implements a flow cache for merging packets belonging to the same flow. In proxy/collector
# mode, nProbe can disable this feature so that incoming flows are not put in cache but immediately
# exported.