Table of Contents

How to use

Startup

There are two ways you can start up ipfixprobe.

Configuring the service

Ipfixprobe can be set up to be used as a daemon to continuously process incoming packets.

All you need to do is create NAME.conf (e.g. instance.conf) file in /etc/ipfixprobe/

ℹ️ To see how to write your .conf, check out our example file or for plugins specific option see plugins guide

Starting the service

⚠️ Exchange NAME for name of your .conf file

Start manually
       sudo systemctl start ipfixprobe@NAME.service
       

       sudo systemctl stop ipfixprobe@NAME.service
Enable at system startup 
       sudo systemctl enable ipfixprobe@NAME.service
       

       sudo systemctl disable ipfixprobe@NAME.service

⚠️ If you are having trouble setting up ipfixprobe as systemd service make sure that:

  • .conf file is in /etc/ipfixprobe/
  • You are using the right .conf file
  • You are launching the service with administrative privileges
  • Try running systemctl status ipfixprobe@NAME.service
  • Check for errors with sudo journalctl -xeu ipfixprobe@NAME.service
  • Make sure ipfixprobe is installed in /usr/bin/ipfixprobe/
  • Check out ipfixprobed in the init directory and make sure the config2args.py and scheme.json are installed in IPFIXPROBE_LIB_DIR (recompile after change)
Check running processes

Once ipfixprobe is running, you can check out the process by 

       pgrep -af ipfixprobe

Or kill the process by 

 
       kill PROCESS_NUMBER

You can have more than one ipfixprobe instance running at the same time

⚠️ Some command line parameters for ipfixprobe and its plugins are NOT supported as systemd parameters. (most are) See example file above for all available options, or run ipfixprobe as a daemon from the command line (without the need for a .conf file) by adding -d flag.

Ipfixprobe supports manual launching from a terminal by specifying parameters.

⚠️ Remember: Ipfixprobe MUST be run with: 1 input - 1 storage - 0-N process - 0-1 output plugins at the same time

Arguments
  • -i or –input set input plugin (-h input for help)
  • -s or –storage (default:cache) set storage plugin (-h storage for help)
  • -p or –process set process plugin/s (-h process for help)
  • -o or –output (default:ipfix) set output plugin(-h output for help)
Example usage

Lunch ipfixprobe from the terminal with raw socket, cache, and text output. 

        ipfixprobe -i 'raw;i=eth0' -s cache -o text

ℹ️ For more information about plugins check out our plugin guide.

Other arguments
  • -t or –telemetry (default:none) Path where to mount the telemetry directory to AppFs (Application File system). This exposes telemetry data to userspace and other applications.
  • -q or –iqueue (default:64) The size of the queue (in records) between input and storage
  • -Q or –oqueue (default:16536) The size of the queue (in records) between storage and output
  • -f or –fps (default:unlimited) Limit the number of exported flows to N per second or 0 for unlimited
  • -c or –count (default:unlimited) Quit after N number of packets processed on each interface
  • -P or –pid(default:false) Create .pid file (text file with process number)
  • -L or –plugins-path(default:CMAKE_INSTALL_FULL_LIBDIR/ipfixprobe/ e.g. /usr/local/lib64/ipfixprobe) Define the new path to the plugins directory
  • -d or –daemon(default:false) Run as a standalone process
  • -V or –version Show ipfixprobe version
  • -C or –cpus Specifies what CPU cores should be used by IPFIXPROBE. Cores are specified as numbers (e.g. 0,2,3)

Data storage

Get data from packet files or probes output stored in different formats for later usage.

You can use ipfixprobe with a combination of other tools from NEMEA to convert .pcap files to .csv (Comma Separated Values) format. To do this, you can choose from two options. Install ipfixprobe and dependencies locally or use a Docker image.

ℹ️ You can easily adjust this procedure to convert any Ipfixprobe input to CVS files.


1️⃣ Using ipfixprobe manually from the command line

1️⃣Install ipfixprobe (Check installation guide)

2️⃣Insatll ipfixprobe plugins

 
          sudo dnf copr -y enable @CESNET/ipfixprobe 
          sudo dnf install ipfixprobe-nemea ipfixprobe-input-pcap ipfixprobe-nemea-process-experimental ipfixprobe-nemea-output-unirec

3️⃣Install Nemea 

 
         sudo dnf copr -y enable @CESNET/NEMEA 
         sudo dnf install nemea

4️⃣Install Extra Packages for Enterprise Linux 

 
          dnf install -y epel-release

1️⃣Install ipfixprobe (Check installation guide)

2️⃣Insatll ipfixprobe plugins 

 
      cd build
      cmake -DENABLE_INPUT_PCAP=ON -DENABLE_OUTPUT_UNIREC=ON -DENABLE_PROCESS_EXPERIMENTAL=ON -DENABLE_NEMEA=ON ..
      cd ..
      make -j
      make install

3️⃣Install Nemea

4️⃣Install Extra Packages for Enterprise Linux 

 
          dnf install -y epel-release


1️⃣ Create a .trapcap file with ipfixprobe out of your .pcap file. (replace NAME with path to pcap file)

      ipfixprobe -i "pcap;file=NAME.pcap" -p "pstats" -p "nettisa" -o "unirec;i=f:tmpTrap.trapcap:timeout=WAIT;p=(pstats,nettisa)"

2️⃣ Conver .trapcap file to .csv file with NEMEA module logger. (replace NAME with path to csv file) 

      /usr/bin/nemea/logger -t -i "f:tmpTrap.trapcap"  -w "NAME.csv"

There could be more tools named logger on your system. Use NEMEA module.

3️⃣ Remove the temporary .trapcap file. 

      rm tmpTrap.trapcap


2️⃣ Using Docker image

Use the provided Docker image to convert files from .pcap to .csv.

Ipfixprobe must be installed from source to use Docker image

Requirements
  • Docker or Podman
  • bash
  • which
  • mktemp
Usage

Use the provided script in the build files (in the docker folder) for ipfixprobe to convert PCAP to CSV with a Docker image.

Provided script builds Docker image automatically. Make sure to be in the same directory as Dockerfile. 

      bash ./ipfixprobe_wrapper.sh <process_script.sh> <input_file.pcap> <output_file.csv>
  • process_script.sh : Script for processing the pcap file inside the container. (Script available in docker folder)
  • input_file.pcap : Path to the input pcap file.
  • output_file.csv : Path to the output CSV file.

➡️ Example usage 

      bash ./ipfixprobe_wrapper.sh ./process_script.sh ../pcaps/mixed.pcap ./output.csv
Build a Docker image by hand.
      docker build -t docker_ipfixprobe .

This is possible with Ipfixcol2 collector.

1️⃣ Install Ipfixprobe, see here.

2️⃣ Enable necessary ipfixprobe output plugins (IPFIX), see the plugins guide.

3️⃣ Install Ipfixcol2 from here

4️⃣ Create Ipfixcol2 config file. For input, use UDP or TCP plugin. For output use JSON, IPFIX File, or FSD File. See Ipfixcol2 documentation for information on how to do this.

5️⃣ Lunch Ipfixprobe (lunch with u ipfix plugin parameter for UDP). 

ipfixprobe -i "pcap;i=eth0" -o "ipfix;host=127.0.0.1;port=4739"

6️⃣ Lunch collector (start after probe). 

ipfixcol2 -c ipfixcol2-confign.xml

ℹ️ Use verbose parameters available both for Ipfixprobe and Ipfixcol2 for troubleshooting.

General usage

When monitoring network traffic with ipfixprobe, it is important to consider where and how to place the probe. Correct placement affects data visibility, performance, and the ability to detect security events.

On the monitored device (localhost)
  • Simple deployment without the need for additional hardware.
  • Ability to detect encripted data before encription (e.g. in the application layer).
  • The overhead of running the probe affects the monitored device.
In front of the network
  • Good for monitoring NETWORK ↔ INTERNET traffic.
  • Difficult to attribute traffic to a specific internal host.
  • Cannot see communication within the internal network.
Inside network
  • Good for monitoring lateral movement (device ↔ device traffic).
  • Possible need for more probes to cover the whole network.

  • Seeing both directions is generally more accurate (TCP handshake, responses, and lack of them, DoS attacks…).
  • Some plugins cannot work correctly without a response.
  • However, one-way monitoring may be sufficient for some use cases (e.g., outbound-only detection, flow volume statistic) and consumes fewer resources.

TAP (Test Access Point)
  • Dedicated hardware for network analysis.
  • Provides complete, reliable visibility.
  • Good for long-term network monitoring.
  • More expensive, but provides consistent results.
SPAN (Switched Port Analyzer)
  • Software solution for monitoring the network.
  • In high packet counts, packets can be dropped → may miss events.
  • Cheaper and easier to deploy.
  • Less reliable than TAP.

One port monitoring
  • Less demanding
  • Unable to see both sides of communication
Two or more port monitoring
  • Needs aggregation of data
  • Able to see both sides of communication