Ipset being deprecated?

General
1

I noticed the following warning on startup with rocky 9.

Warning: Deprecated Driver is detected: ipset will not be maintained in a future major release and may be disabled

I use an ipset list with all the published cloudflare address blocks to allow web server access only from cloudflare sources using

firewall-cmd --permanent --new-ipset=cloudflare --type=hash:net
firewall-cmd --permanent --ipset=cloudflare --add-entries-from-file=cloudflare.ips

and then apply it to a “rich rule”.

Does anyone know what to use instead of ipset to carry out this function that will continue working when rocky 10 comes out?

2

I do it differently. I create a zone called cloudflare. To this zone I add the services http and https. I then use curl to get the IPv4 and IPv6 listing from Cloudflare and parse the results to then use these with the firewall-cmd --add-source command for the cloudflare zone.

Obviously then remove http and https from public zone to force everything via cloudflare with no direct connections coming to your VPS. My script that does this:

#!/bin/bash
#
# Script to get Cloudflare IP's and add to firewalld zone

# Variables
CF_IPLIST=`curl -s "https://api.cloudflare.com/client/v4/ips"`
IPV4=`echo ${CF_IPLIST} | jq .result.ipv4_cidrs[] | sed 's/"//g'`
IPV6=`echo ${CF_IPLIST} | jq .result.ipv6_cidrs[] | sed 's/"//g'`
ZONE_NAME=cloudflare

# Update firewalld to allow inbound http/https
#
# Clear all source IP's CLOUDFLARE zone
for IP in `firewall-cmd --zone=${ZONE_NAME} --list-sources`
do
  firewall-cmd --zone=${ZONE_NAME} --remove-source=${IP} --permanent > /dev/null
done

# Create IPV4 rules
for IP in $IPV4
do
  firewall-cmd --zone=${ZONE_NAME} --add-source=${IP} --permanent > /dev/null
done

# Create IPV6 rules
for IP in $IPV6
do
  firewall-cmd --zone=${ZONE_NAME} --add-source=${IP} --permanent > /dev/null
done

# Reload firewall config
firewall-cmd --reload

obviously before running the script you need to ensure the cloudflare zone has been created. I could theoretically have coded the script to deal with that and create it automatically if it didn’t exist.

The script will remove all existing source IP’s from the cloudflare zone, before adding the new ones. I run it via cron once per week so as to not get blocked pulling the IP list from cloudflare.

2 Likes
3

Thanks for this. I will try it out.

1 Like
4

The ‘ipset’ and ‘iptables’ tools of old did talk to netfilter in the the kernel.
In el8 and el9 (and also backported in el7) there is nftables in the kernel.
At least the ‘iptables’ in el8 and el9 is a wrapper that translates rules to nftables syntax.
See Chapter 2. Getting started with nftables Red Hat Enterprise Linux 9 | Red Hat Customer Portal

The nftables has sets and verdict maps. Chapter 2. Getting started with nftables Red Hat Enterprise Linux 9 | Red Hat Customer Portal

The real question is, does the FirewallD’s “ipset” actually call ‘ipset’, or does it use nftables’ sets?

You have that ipset=cloudflare. Run sudo nft list ruleset to see what FirewallD has actually told to the kernel.

5

This is what it shows (I’m only running IPV4 on the server at present):

# nft list ruleset
table inet firewalld {
	set cloudflare {
		type ipv4_addr
		flags interval
		elements = { 103.21.244.0/22, 103.22.200.0/22,
			     103.31.4.0/22, 104.16.0.0/13,
			     104.24.0.0/14, 108.162.192.0/18,
			     131.0.72.0/22, 141.101.64.0/18,
			     162.158.0.0/15, 172.64.0.0/13,
			     173.245.48.0/20, 188.114.96.0/20,
			     190.93.240.0/20, 197.234.240.0/22,
			     198.41.128.0/17 }
	}
6

That is a nftables named set. Therefore, you (firewalld) are not using the deprecated ipset and should be able to continue to do so in the future too.

2 Likes
7

I’m still on Rocky 8 but will be filing this away for future reference. I’ve been using this resource with some scripts to massage the download into ipset XML files, but it sounds like I should be invoking firewall-cmd to manage the sets.

8

OK thanks. I’m wondering why the warning? Maybe something to do with the in place upgrade from Rocky 8.

9

Quite possible. Rocky does not support in-place upgrades. (Neither did CentOS.)

IMHO, if you can do a fresh, clean (re)install, then life is more secure; there are no in-place options if, for example a server burns to crisp – a clean reinstall will be required.

10

Both el8 and el9 do have two mutually exclusive services: firewalld.service and nftables.service. (Well, iptables.service too, but it is clearly deprecated.)

Both services can create the sets.
If you have rather static environment (as production servers usually are) and you know how to write a proper ruleset, then nftables.service is a great choice.
If you don’t master filtering or there is a need for dynamics, then FirewallD is more convenient.