yum
upgrades for production use, this is the repository for you.
Active subscription is required.
FirewallD has a very nice concept of zones and it has some predefined ones.
When you need to whitelist a particular IP and label it as “trusted” on the system, then the trusted FirewallD is the thing you will play with.
Another modern thing is ipsets, which FirewallD supports well. The ipsets are useful to efficiently store and lookup many IP addresses.
So combining all the features together, we can whitelist many IP addresses in a clean and efficient way:
First, create 2 ipsets: one for IPv4 and the other for IPv6:
firewall-cmd --permanent --new-ipset=whitelist4 --type=hash:net --option=maxelem=256 --option=family=inet --option=hashsize=4096
firewall-cmd --permanent --new-ipset=whitelist6 --type=hash:net --option=maxelem=256 --option=family=inet6 --option=hashsize=4096
Next, tell FirewallD that clients from those IP addresses belong to trusted zone:
firewall-cmd --permanent --zone=trusted --add-source=ipset:whitelist4
firewall-cmd --permanent --zone=trusted --add-source=ipset:whitelist6
Whitelist an IP, and apply your changes:
firewall-cmd --ipset=whitelist4 --add-entry=1.2.3.4 --permanent
firewall-cmd --reload
Priority of trusted vs drop zones
Suppose that you are in a situation where you want to block an entire network, but whitelist a single IP address from it.
This may happen in a situation, e.g. when a server administrator works with an E-Commerce website that has malicious visitors from his own country.
In this case, you have two source zones: one for whitelisting and the other for the block.
It is important to understand that FirewallD matches zones in alphabetical order.
So if you put the admin’s whitelisted IP to the trusted
zone, and place admin’s Internet provider network to the block
zone – the admin will still be unable to access.
Because FirewallD will first match the block
zone when he connects, simply because both block
comes before trusted
, alphabetically.
So you may want to create an additional trusted zone that follows the same behavior: accept connections from it.
firewall-cmd --permanent --new-zone=000-trusted
firewall-cmd --set-target=ACCEPT --zone=000-trusted --permanent
firewall-cmd --reload
firewall-cmd --zone=000-trusted --list-all
Now you can add IP addresses/sets to this zone and their connections will be accepted *even if they fall within networks blocked in the drop
zone.
E.g. let’s say you want to network block Amazon’s network range
firewall-cmd --permanent --ipset=networkblock --add-entry=52.0.0.0/11
But you still want individual IP addresses allowed, e.g. Nextopia search (listing of nextopia.txt
):
23.21.156.120
23.21.156.122
34.204.137.83
34.234.31.124
50.18.255.116
50.18.255.118
50.18.255.120
52.54.23.140
52.5.202.218
52.5.14.151
52.3.132.184
52.3.116.112
52.23.91.52
52.7.55.35
52.45.183.192
54.243.143.63
54.243.142.22
54.243.142.6
54.243.143.167
54.243.143.190
96.45.201.230
174.129.210.5
184.73.252.38
184.73.226.72
52.3.25.253
52.44.89.1
18.204.185.69
As you can see, quite a bunch of those IP addresses is from the blocked network. So we can create an IP set, and add it as a source to the 000-trusted
zone:
# Creating "nextopia" IP set:
firewall-cmd --permanent --new-ipset=nextopia --type=hash:ip --option=maxelem=100 --option=family=inet --option=hashsize=4096
# Populating the IP set with addresses:
firewall-cmd --permanent --ipset=nextopia --add-entries-from-file=/tmp/nextopia.txt
# Adding the IP set to 000-trusted zone
firewall-cmd --permanent --zone=000-trusted --add-source=ipset:nextopia
# Applying configuration at runtime:
firewall-cmd --reload
000-trusted
vs trusted
zone?
Making use of both 000-trusted
and trusted
zones around at the same time is a valid use case: e.g. imagine you also trust an entire network but want to block selected IP from it.
In that case, you will use trusted
and block
zones.
P.S. you can also create 000-trusted
using XML configuration files:
cp /usr/lib/firewalld/zones/trusted.xml /etc/firewalld/zones/000-trusted.xml
Then ensure contents like this:
<?xml version="1.0" encoding="utf-8"?>
<zone target="ACCEPT">
<short>Trusted Priority</short>
<description>All network connections are accepted, priority over block zone.</description>
</zone>
Apply the addition of the new zone with:
firewall-cmd --reload
Managing IP sets
It is a good practice to maintain an IP set if it is subject to change.
Simply editing a text file isn’t the right thing to do here.
It is best to have each IP set available via packages. This makes whitelisting and updates consistently.
We have some IP sets available via the RPM repository.
Check them all out at the trusted-lists
GitHub project.
Example. Whitelisting Braintree payment gateway
sudo yum -y install firewalld-ipset-braintree
Now, FirewallD knows about the new IP set named braintree
. It will appear in the list of known IP sets provided by firewall-cmd --get-ipsets
output.
All we have to do is add it up as desired, onto the whitelist.
# Adding the IP set to 000-trusted zone
firewall-cmd --permanent --zone=000-trusted --add-source=ipset:braintree
# Applying configuration at runtime:
firewall-cmd --reload
Ensure that the package is automatically updated in order to always whitelist the gateway’s IPs and networks.