nProbe IPS: How To setup an Inline Layer-7 Traffic Policer in 5 Minutes

Posted · Add Comment

Introduction

Recently, we have added Intrusion Prevention System (IPS) capabilities to our nProbe. Those capabilities are available starting from the latest 9.5 version, both for Linux and FreeBSD – including OPNsense and pfSense, and are available with all nProbe versions and licenses (see the product page for additional details).

On Linux, nProbe leverages the netfilter framework. In essence, the kernel send packets to nProbe via NF_QUEUE which, in turn, gives each packet a pass/drop verdict so that it can be dropped or let it continue its journey through the network. In addition, nProbe has the ability to mark packets to create policies that go beyond the simple pass/drop but can include, shaping, routing, and so on. Using markers it is also possible to offload traffic packets. In essence, once a flow packet has been marked, the kernel can be told to bridge additional flow packets directly, without sending them to nProbe. This is beneficial and allows to reach very good bridging performances. On FreeBSD, the NetFilter framework is not available and nProbe leverages netmap. For this reason, all packets need to be sent to userspace to nProbe. Hence, measured performances are reduced if compared to Linux. The nProbe product page reports typical performance figures for both Linux and FreeBSD.

For those of you who prefer a video resource, here’s the step-by-step tutorial

otherwise you can read the rest of this article for details.

Creating a Layer-7 Traffic Policer

In this post, we create a Layer-7 traffic policer on a Linux machine, put as a bump-in-the-wire between the clients we want to policy and the router that handles their traffic. A commodity 4x1Gb Intel 82580 network card installed on the machine is used to bridge the traffic between the clients and the router. nProbe IPS will operate on top of this bridge, that is created with 2 of the 4 interfaces of the network card:

  • enp2s0f0 is connected to a WiFi access point where clients are connected.
  • enp2s0f1 is connected to the Router that in charge of handling clients’ traffic.

Packets reaching one of the two bridged interfaces, before being bridged, are sent to nProbe via NFQUEUE that emits a verdict. If the packet verdict is drop, then the packet is dropped and not bridged. Otherwise, the packet is allowed to reach the other interface.

Let’s now see how to – quickly and easily – configure the bridge, NFQUEUE and nProbe to implement the Layer-7 traffic policer.

Configuring the Bridge and NFQUEUE

This part of the configuration prepares the system to:

  • Bridge clients’ traffic
  • Send clients’ traffic to nProbe for policy enforcement

To facilitate the configuration, we have prepared a shell script that takes care of the above. This script, distributed along with any packaged version of nProbe, becomes automatically available at the following path once nProbe is installed:

 /usr/share/nprobe/netfilter/scripts/policy_and_bridge_simple.sh

The script begins with a brief configuration section that allows interface names to be configured. Interface names are pretty much everything that needs to be specified. After the necessary configuration changes have been applied, the script can be run as ./policy_and_bridge_simple.sh to set up the system.

In short, the script carries out the following tasks. First, it creates a bridge using Linux bridging capabilities. Then, it instructs the kernel to send packets to nProbe, rather than bridging them automatically. This is done with a couple of iptables rules, indicating that packets entering the system from bridged interfaces must go through a NFQUEUE.

For the sake of example, iptables can be used to send packets entering the system from enp2s0f0 and enp2s0f1 to the NFQUEUE queue identified with id 0 as follows:

iptables -t mangle -A FORWARD -j NFQUEUE --queue-num 0 --queue-bypass -m physdev --physdev-in enp2s0f0
iptables -t mangle -A FORWARD -j NFQUEUE --queue-num 0 --queue-bypass -m physdev --physdev-in enp2s0f1

Configuring nProbe IPS

nProbe, to operate in IPS mode, needs a rules file. Policy rules are applied to groups of hosts (identified with IP or MAC Addresses) and give the ability to pass/drop/mark packets on the basis of their Layer-7 application protocol, Layer-7 application category, country, flow risk, and so on.

A very simple configuration file can be the following

# Pool definition
{"pool":{"id":1,"name":"Local Networks","ip": [ "172.16.12.0/24", "172.16.4.0/24", "192.168.2.0/24"], "mac": []},"policy": {"id": 0} }

# Policy definition
{"policy":{"id":0,"name":"root policy rule", "default_marker": "pass", "markers": { "categories": { }, "protocols": {"Facebook": "drop" }, "countries": { }, "asn" : { }, "continents" : { } } } }

The file basically tells nProbe to drop Facebook traffic ("protocols": {"Facebook": "drop" }) for all hosts belonging to networks "172.16.12.0/24", "172.16.4.0/24", "192.168.2.0/24". A pass verdict is emitted for all non-Facebook traffic ("default_marker": "pass").

Now that the file is ready, assuming it is saved as nprobe-ips.config, nProbe can be started as follows

$ /usr/bin/nprobe --ips-mode nprobe-ips.config -i nf:0 -n none

Relevant options have the following meaning:

  • --ips-mode nprobe-ips.config tells to operate in IPS mode and specifies the rules file
  • nf:0 indicates the NFQUEUE queue used by the kernel to send packets to nProbe. Note that this id 0 MUST match with the id indicated in the configuration of policy_and_bridge_simple.sh. In general, it is safe to use 0.

From this point on, traffic policies are enforced for all clients. For example, this is what happens to one of the client that tries to reach Facebook before and after Layer-7 policer activation.

Conclusion

In this post, we have seen how to quickly create a Layer-7 traffic policer on Linux using nProbe IPS. A very simple "protocols": {"Facebook": "drop" } policy has been created just for the sake of example. In practice, nProbe IPS is flexible enough to create complex policies using also Layer-7 categories, countries, autonomous systems and so on.

Moreover, by leveraging packet marks, effective kernel traffic offload and traffic shaping can be implemented. There are scripts distributed with any packaged version of nProbe available under /usr/share/nprobe/netfilter/ that can be used for reference when implementing offload and shaping.