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.
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.
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.
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.
I am seeing the same on Rocky 9 fresh install, using firewalld with blocklist added with ipset.
@iwalker
Adding blocklists as single source IPs is not really feasible - as with big blocklists it tends to take a lot of time (seen mentions about half of an hour on startup :)) - with ipset it’s very fast.
@Darmach I don’t add single IP’s, mine adds for example Cloudflare subnet’s. Also, using the --permanent parameter, means the subnets are added, and reloaded later, no issues with speed whatsoever, or even restricting access when I delete potentially old unexisting subnets, before adding the new ones again. Maybe not 100% ideal, but it does the job.
But yeah, ipset I’ve used with iptables, I just prefer to do it the firewalld way now and use what is by default available with EL8/EL9 it’s quick and simple, and I don’t have to learn to deeply with nftables.
But of course, everyone is free to choose how they want
Let’s not get sidetracked by the discussion of which way is better, I’m glad blocking subnets works great for you, the lists I use have about 30k of entries (mostly subnets - www.ipdeny.com).
From @jlehtone messages it looks like I might not be impacted - as with firewalld might not be using deprecated ipsets. This, however, brings the same concerns that @BillT had - why we see the warnings?
In my case the output looks like follows - so it looks the same as @BillT nftables named set, right?
On RedHat ipset deprecated warning - Red Hat Customer Portal solution is in progress (for now).
From the description it looks like they’re actually calling ipset. To deploy the rules above I actually had to install ipset. @jlehtone are you sure I am not using it?
The only place, where I have (sets of any kind in use) is still a CentOS 7.
On el9_2 system:
nft add set filter ssh_flood '{ type ipv4_addr; flags dynamic; }'
adds a named set without fuss:
# nft list table filter | head -6
table ip filter {
set ssh_flood {
type ipv4_addr
flags dynamic
}
# ipset list
# dmesg | grep -i ipset
#
The ipset create black hash:ip does invoke the warning:
# ipset list
Name: black
Type: hash:ip
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xb475fd8f
Size in memory: 216
References: 0
Number of entries: 0
Members:
# dmesg | grep -i ipset
[86107.645424] Warning: Deprecated Driver is detected: ipset will not be maintained in a future major release and may be disabled
and ‘nft’ does not see it:
# nft list ruleset | grep black
#
In other words, the ‘ipset’ is not a wrapper/translator to nftables like the ‘iptables’ is in el8 and el9.
Overall, Ipset - nftables wiki does that show how to translate ipset sets into nftables constructs. If nft does not see the ipset set, then how could it use it?
Does the firewalld create (and populate) both ipset and nftables sets in your config?
PS. The “ipset create” did load the ip_set kernel module. That is the most likely source of the warning.
The lsmod | grep ip_set should show something. The question remains, why that load is triggered?
Yes, it does. I cleaned up ipset/nft, cleaned up firewalld. Recreated entries with firewalld, ipset was created, nft ruleset created, same addresses. So it looks like the warning is legit - I am using actual ipset when doing
In other words, the issue is that FirewallD does produce both ipset and nftables set with its --new-ipset action, while one expects it to create only one set that matches the chosen backend. None of the generated (nftables) rules do actually use the ipset set (when backend is nftables).
One probably should:
Get a CentOS Stream system
Verify that firewall in it still has this behaviour
Report a CentOS Stream bug to Red Hat
That, after all, is the touted purpose of CentOS Stream, isn’t it?
it’s quick and simple, and I don’t have to learn to deeply with nftables.