nftables Integration

Netify DPI - nftables Integration

The nftables Integration is a part of the Netify Flow Actions Plugin - a premium add-on to the Netify Agent.

nftables can be used to implement bandwidth, firewall, and QoS solutions on routers, firewalls, and gateways. The Netify DPI nftables integration provides a way to create high-speed nftables sets based on any Netify deep packet inspection flow criteria. These sets can then be used to block, shape, mark, or perform other actions to network traffic.

In the example below, we will use Netify DPI's nftables integration to block network traffic using insecure encryption.

You can also review alternative options for taking actions on DPI flow data - see the IP sets and connection tracking (CT) labels integrations for details.

Prerequisites
- How It Works
- Installing Netifyd
- Network Interface Configuration
- Flow Actions Plugin

Netify Network Policy Engine

Blocking Traffic with Weak Encryption

In the example below, we will be using the nftables Sets feature to drop weak TLS 1.1 encrypted connections. However, we will make an exception for connections from a legacy printer device at 192.168.55.155. This solution uses two tools to implement the firewall blocking policy:

  • The Netify nftables integration to label all TLS 1.1 connections, except from 192.168.55.155
  • nftables rules to drop network traffic

Installation

Nftables integration is part of the Flow Actions Plugin which is installed as a separate package. Please see your Integrators Kit instructions for details.

Example Configuration

Introduction

The netify-proc-flow-actions.json JSON configuration file provides a starting point for implementing our solution. See sidebar for the configuration.

For this example, we use basic configurations to demonstrate a core feature. The Netify Integrators Kit provides more detailed reference documentation. Notably, the Flow Actions Plugin provides a very powerful expression language for pinpointing network traffic.

Actions

The actions block defines the traffic that needs to be identified. The criteria expressions are very powerful and flexible. In this case, TLS 1.1 (0x0302) encryption is our primary criteria, but we make an exception for our printer at 192.168.55.155. When network traffic triggers this action, the defined targets (nftset.weakssl and log.weakssl) are executed.

Targets

The targets block defines which engine to use for the flow action. In our example, there are two targets defined:

  • Logging
  • nftables Sets

You can see the effects of this configuration in the next section. 

# /etc/netifyd/netify-proc-flow-actions.json
{
  "version": 1,
  "actions": {
    "weakssl": {
      "criteria": "ip_nat == false && ssl_version == 0x0302;",
      "targets": [
        "nftset.weakssl",
        "log.weakssl"
      ],
      "exemptions": [
        "192.168.55.155"
      ]
    }
  },
  "targets": {
    "nftset.weakssl": {
      "target_type": "nftset",
      "set_name": "weakssl"
    },
    "log.weakssl": {
      "target_type": "log",
      "prefix": "weakssl",
      "interval": 10
    }
  },
  "target_defaults": {
    "nftset": {
      "table_name": "netify",
      "table_family": "inet",
      "set_family": "*",
      "type": [
        "local_addr",
        "ip_proto",
        "other_port",
        "other_addr"
      ],
      "ttl": 120,
      "managed": true,
      "flush_on_create": true,
      "flush_on_destroy": true
    }
  }
}

Example In Action

How do we test this setup? The badssl.com web site provides a handy way to test old SSL versions and ciphers. The site provides a link to a web server running TLS 1.1 and other insecure configurations. Keep in mind, modern web browsers and command line tools may block insecure connections, so it can be tricky to trigger a TLS 1.1 connection.

With the configuration in place and Netify restarted, the nft command can be used to see the "nftables sets" being populated by the Flow Actions Plugin: 

# nft -nn list table inet netify
table inet netify {
	set weakssl.v4 {
		type ipv4_addr . inet_proto . inet_service . ipv4_addr
		size 65536
		timeout 2m
		elements = { 192.168.1.100 . 6 . 1010 . 104.154.89.105 expires 1m47s500ms }
	}
    ...
}

Our 192.168.1.100 desktop was caught connecting to 104.154.89.105 (tls-v1-1.badssl.com) using TLS 1.1. Bonus: port 1010 is used instead of the usual HTTPS port 443 - not an issue with Netify DPI. With this "nftables set" in place, an nftables firewall rule can be created to block the traffic.

The log target was also specified in our Netify Flow Actions configuration. In the /tmp directory, a log of TLS 1.1 events is available. These logs can be ingested or integrated into other workflows. 

# jq . /tmp/weakssl-20221221-102846.json
{
  "entries": [
    {
      "app_id": "0.netify.badssl",
      "dst_addr": "104.154.89.105",
      "dst_port": 1011,
      "proto_id": "91",
      "src_addr": "192.168.1.100"
    }
  ],
  "time_end": 1671636526,
  "time_start": 1671636506
}

Further Reading

Processors

Outputs

Netify Agent


Inputs


Processor Plugins


Output Plugins


Output Formats


Other Links

Evaluate Netify DPI

Do you want to get started with evaluating Netify DPI? Request the Integrators Kit today.

Integrators Kit