Block Insecure Traffic with nftables

This example shows an end-to-end policy using the Flow Actions Plugin and nftables to block traffic that uses weak encryption.

We detect TLS v1.1 traffic with the Netify DPI engine, place matching flows into an nftables set, and then apply a firewall rule to drop those flows. To add a real-world use case, a legacy printer at 192.168.55.155 is exempted.

Prerequisites

Netify Agent v5 with the Flow Actions Plugin
A Linux system with nftables installed and active
Privileges to restart netifyd and manage nftables rules

nftables can implement firewall, bandwidth, and QoS policies on Linux routers and gateways. The Netify nftables integration creates high-speed sets from DPI flow matches, which can then be used to block, shape, mark, or otherwise control traffic.

In this example, the policy decision is defined in the action criteria expression. For supported properties, operators, and syntax details, see the Expression Engine integration documentation.

Goal: Blocking Traffic with Weak Encryption

The configuration below uses two targets: one to update the nftables set and one to emit logs. Traffic is matched on TLS 1.1 and exempted for 192.168.55.155.

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

Example Configuration

Actions

An action defines when to do it.

The actions block specifies the logic for identifying specific network traffic. In this example, the weakssl action that we have defined uses a criteria expression to isolate TLS 1.1 traffic (identified by the hex code 0x0302) that is not subject to Network Address Translation (ip_nat == false).

To prevent connectivity issues with legacy hardware, an exemptions rule is applied to a specific printer at 192.168.55.155. When network traffic meets these defined conditions, the system triggers the specified targets : nftset.weakssl. We'll define this target next.

Targets

A target defines what to do when an action matches.

In this example, we are creating a nftset.weakssl target to write an entry to an nftset. You can see the effects of this configuration in the next section.

The target_defaults section allows us to create some default settings for the nftset . You can find details about those properties in the Flow Actions reference document.

Config: /etc/netifyd/netify-proc-flow-actions.json

{
  "version": 1,
  "actions": {
    "weakssl": {
      "criteria": "ip_nat == false && ssl_version == 0x0302;",
      "targets": [
        "nftset.weakssl"
      ],
      "exemptions": [
        "192.168.55.155"
      ]
    }
  },
  "targets": {
    "nftset.weakssl": {
      "target_type": "nftset",
      "set_name": "weakssl"
    }
  },
  "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 website 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:

Terminal - Netify

$ 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.

Terminal - Netify

$ nft add chain inet netify forward { type filter hook forward priority 0 \; policy accept \; }
$ nft add rule inet netify forward ip saddr . meta l4proto . th dport . ip daddr @weakssl.v4 drop

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": 1010,
      "proto_id": "91",
      "src_addr": "192.168.1.100"
    }
  ],
  "time_end": 1671636526,
  "time_start": 1671636506
}