Packet Sensor¶

In switched networks, only the packets for a specific device reach the device’s network card. If the server running the Packet Sensor is not deployed in-line in the main data path, a network TAP, or a switch/router that offers a “monitoring port” or “mirroring port” must be used. In this case, the network device sends copies of data packets traveling through selected ports or VLANs to the monitoring port. Packet Sensor inspects every packet it receives and conducts packet-based traffic analysis. The advantages and disadvantages of packet-based traffic monitoring are listed in the "Choosing a Method of Traffic Monitoring and DDoS Detection" section.

For instructions on how to configure switches or routers for port mirroring, consult their documentation.

To add a Packet Sensor, click the [+] button from the title bar of the Configuration » Components panel. To modify an existing Packet Sensor, go to Configuration » Components and click its name.

● Sensor Name – A short name to help you identify the Packet Sensor

● Sensor Color – The color used in graphs for the Packet Sensor. The default color is a random one, which can be changed by clicking the drop-down menu

● Sensor Visibility – Toggles the listing inside Reports » Devices

● Device Group – Optional parameter used for grouping up components (e.g. by location or role). It can be used to restrict the access of Guest accounts

● Sensor Server – The server that runs the Packet Sensor. The configuration of servers is described in the Configuration » Servers section. If this is not the Console server, follow NFS configuration for remote servers to make the raw packet data visible in the UI

● Capture Engine – Select the preferred packet capturing engine. LibPcap requires no additional setup but it is too slow for multi-gigabit sniffing and it does not run on multiple threads. Netmap and PF_RING are much faster but both require the installation of additional kernel modules. DPDK provides the fastest packet capturing engine and allows packet forwarding but it is very complicated to configure.

○ Embedded LibPcap – Select to use the built-in LibPcap 1.8.1 library

○ System LibPcap – Select to use the LibPcap library installed by the Linux distribution

○ Netmap – Select to use the Netmap framework to speed up packet processing

○ PF_RING – Select to use the PF_RING framework to speed up packet processing. Click the button on the right for PF_RING-specific settings, but don’t activate the PF_RING ZC option if you don’t have a purchased ZC license

○ DPDK – Select to use the DPDK framework, then click the button on the right of the Capture Engine field to configure DPDK-specific parameters as described in Appendix 1

● Sniffing Interface – The network interface(s) listened by the Packet Sensor. If the server running the Packet Sensor is deployed in-line, then this field must contain the network interface that receives the traffic entering your network. The PF_RING framework allows listening to multiple physical interfaces simultaneously when the interfaces are entered separated by semicolon “;”

● CPU Threads – Packet Sensor can run multi-threaded on a given set of CPU cores. Each thread increases the RAM usage. On most systems, activating more than 6 CPU threads hurts performance

● Link Speed IN / OUT – Enter the speed (bandwidth, capacity) of the monitored link. The values are used for percentage-based reports and percentage-based bits/s thresholds

● Sensor License – The license used by the Packet Sensor. Wanguard provides all features; Wansight does not provide traffic anomaly detection and reaction

● Stats Engine – Collects traffic tops and AS graphs:

○ Basic – Enables tops for Internal IPs, IP protocols, versions and TCP/UDP ports. It is the recommended value because it adds a very small performance penalty

○ Extended – Enables all tops from Basic as well as tops for external IPs (IPs not included in the IP Zone). It adds performance penalty of over 20%, especially during spoofed attacks. Permits the detection of threshold violations for external IPs

○ Full – Enables all tops from Extended as well as tops and graphs for autonomous systems. It adds a performance penalty of over 20%, especially during spoofed attacks. Permits the detection of threshold violations for external IPs

● Stats Engine Options – When Stats Engine is set to Full you can click the button next to it. To enable Transit AS tops and graphs, enter the path to an existing BGP Dump File exported by BGPd in MTR format, and the IPv4 and optionally IPv6 address of the BGP router

● IP Zone – Packet Sensor needs an IP Zone from which to learn about your network’s boundaries and to extract per-subnet settings

● BPF Expression – You can filter the type of traffic the Packet Sensor receives using a tcpdump-style syntax

● IP Validation – This option is the most frequently-used way to distinguish the direction of the packets:

○ Off – Packet Sensor analyzes all traffic and uses MAC Validation to identify the direction of traffic

○ On – Packet Sensor analyzes the traffic that has the source and/or the destination IP in the selected IPZone

○ Strict – Packet Sensor analyzes the traffic that has either the source or the destination IP in the selected IP Zone

○ Exclusive – Packet Sensor analyzes the traffic that has the destination IP in the selected IP Zone, but not the source IP

● MAC Validation/Options – This option can be used to distinguish the direction of the packets or to ignore unwanted OSI Layer 2 traffic:

○ None – Packet Sensor analyzes all traffic and uses IP Validation to identify the direction of traffic

○ Upstream MAC – MAC validation is active and the MAC Address belongs to the upstream router

○ Downstream MAC – MAC validation is active and the MAC Address belongs to the downstream router

The MAC Address must be written using the Linux convention – six groups of two hexadecimal values separated by colons (:)

● Granularity – Interval between successive updates for traffic parameters and anomalies. A granularity of 1 second ensures detection of anomalies in under one second at the expense of the SQL server’s load

● Sampling (1/N) – Contains the packet sampling rate. On most systems, the correct value is 1

● Comments – Comments about the Packet Sensor can be saved here. They are not visible elsewhere

To start the Packet Sensor, click the small button displayed next to its name in Configuration » Components. Ensure that the Packet Sensor starts correctly by watching the event log (details in the Configuration » Schedulers » Event Reporting section).

If the Packet Sensor starts without errors, but you can’t see any data collected by it in Reports » Devices » Overview, follow the troubleshooting steps listed below.

10.1. Packet Sensor Troubleshooting¶

✔ Look for warnings or errors produced by the Packet Sensor in the event log (details in the Configuration » Schedulers » Event Reporting section)
✔ Ensure that you have correctly configured the Packet Sensor. Each configuration field is described in this chapter
✔ The event log error “License key not compatible with the existing server” can be fixed by sending the string from  Configuration » Servers » [Packet Sensor server] » Hardware Key to sales@andrisoft.com
✔ Make sure that the sniffing interface is up:

[root@localhost ~]# ip link show <interface>

✔ Ensure that you have correctly configured the switch/TAP to send packets to the server on the configured interface

✔ Verify whether the server is receiving packets via the configured interface:

[root@localhost ~]# tcpdump -i <interface_usually_eth1_or_p1p2> -n -c 100

✔ When IP Validation is not disabled, make sure that the selected IP Zone contains all your subnets
✔ If the CPU usage of the Packet Sensor is too high, set the Stats Engine parameter to “Basic”, install PF_RING, Netmap or DPDK to enable multi-threading, or use a network adapter that allows distributing Packet Sensors over multiple CPU cores
✔ To troubleshoot Sensor graph or IP graph issues, follow the Graphs Troubleshooting guide
✔ For PF_RING-related issues, contact ntop.org. To increase the maximum number of PF_RING programs from 64 to 256, increase the MAX_NUM_RING_SOCKETS defined in kernel/linux/pf_ring.h and recompile the pf_ring kernel module
✔ The system process responsible for capturing packets is called WANtrafficlogger. There will be as many processes active as the number of packet dumps active in Reports » Tools » Packets
✔ Make sure you are running the latest version of the software by checking Help » Software Updates

10.2. Packet Sensor Optimization Steps for Intel 82599¶

To distribute the packet-processing tasks of the Packet Sensor over multiple CPU cores when using an adapter with the Intel 82599 chipset (Intel X520, Intel X540, HP X560, etc.):

✔ Follow the documentation and optimization guides provided by the network adapter vendor

✔ Install PF_RING and switch to the PF_RING-aware ixgbe driver

✔ See the number of RSS queues allocated by the ixgbe driver by executing dmesg, or by listing /var/log/messages or /var/log/syslog. By default, the number of RSS queues is equal to the number of CPU cores when hyper-threading is off, or double the number of CPU cores when hyper-threading is on. You can set the number of RSS queues manually, by loading ixgbe.ko with the RSS=<number> option

✔ Enable multithreading in the Packet Sensor configuration or define multiple Packet Sensors, each listening to ethX@queue_id or ethX@queue_range and add them to a Sensor Cluster to have a unified reporting and anomaly detection domain. No additional licensing is needed because all Packet Sensors defined to listen to a single interface use a single Sensor license

On a quad-core CPU with multithreading, the ixgbe driver allocates 8 RSS queues. In this case, if you define a Packet Sensor for ethX@0-3 and another one for ethX@4-7, the packet-processing task will be distributed over 2 CPU cores. PF_RING exposes up to 32 RSS queues.