Introduction
In the previous labs, you opened and closed "doors" (ports) for everyone. But what if you want to open the door only for your friend, or lock it specifically for a known troublemaker?
This is where rich rules come in. Instead of only opening or closing a service broadly, rich rules let you express more detailed policy such as matching source addresses, logging, or rejecting specific traffic.
They matter because real firewall policy is often conditional. Security decisions are rarely only "port open" or "port closed."
Note on Lab Environment: To ensure you don't accidentally lock yourself out of the web terminal, we will use the trusted zone by default. This means all traffic is allowed unless we explicitly block it. In a real production environment, you would use a more restrictive zone like public or drop.
In this lab, you will learn how to:
- Block specific people: Reject connections from a specific IP address.
- Keep records: Log attempts so you can see who tried to get in.
- Restrict access: Configure a rule to allow remote control (SSH) only from a specific network.
- Audit: Save your rules to a file for review.
Block a Specific IP
In this step, first, let's learn how to block a specific bad actor. Suppose you notice that the computer at 192.168.1.100 is trying to hack you. You want to block it completely.
We will use a "Rich Rule" to do this. Even though our default zone is trusted (allow all), a specific Reject rule will take precedence for this IP.
Rich rules matter because real firewall policy is often conditional. You may want different behavior based on source address, service, logging needs, or other criteria that simple open-or-close commands cannot express well.
The syntax looks like constructing a sentence: rule family="ipv4" source address="192.168.1.100" reject
Run the following command to add this rule permanently.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" reject'
Let's break down this "sentence":
rule family="ipv4": We are talking about standard IP addresses.source address="...": This is the bad guy's address.reject: This is the action.
Reject vs. Drop:
- Reject is polite: It tells the sender "Go away, you are not allowed."
- Drop is rude: It ignores the sender completely, as if your computer doesn't exist.
Choosing between them is not just style. reject gives faster feedback to legitimate clients and easier troubleshooting, while drop can reveal less information to an attacker but may cause longer timeouts.
Since we used --permanent, the rule is saved but not active yet. Reload the firewall to apply it.
sudo firewall-cmd --reload
Now, verify the rule exists.
sudo firewall-cmd --list-rich-rules
You should see your new rule listed.
Log Dropped Packets
In this step, simply blocking someone is good, but sometimes you want proof. You can add "logging" to a rule, which is like installing a security camera that records every time the rule is triggered.
That combination of filtering and logging is common in security operations. Blocking traffic protects the system, while logging creates evidence you can investigate later.
Let's block another IP, 10.0.0.5, but this time we will log the attempt before rejecting it.
Run this command:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.5" log prefix="BLOCKED_IP: " level="info" reject'
What's new here?
log: Turn on the camera.prefix="BLOCKED_IP: ": When writing to the system logs, start the line with this text. This makes it very easy to find these specific events later using search tools.
Apply the changes.
sudo firewall-cmd --reload
Check your work.
sudo firewall-cmd --list-rich-rules
You should now see two rules: the first one (simple reject) and the second one (log and reject).
Restrict Service Access
In this step, in a hardened environment, you would block SSH from everywhere and only allow it from a trusted network (like your VPN).
Educational Note: Because we are using the trusted zone to keep your connection alive, this step is partially symbolic. Adding an "Allow" rule when everything is already allowed doesn't change behavior. However, learning this syntax is critical for when you work with restrictive zones like public or drop.
The goal is to create a rule that says "Allow SSH if the source is 192.168.0.0/24".
This is a good example of least privilege in network policy. Instead of exposing administrative access to the whole world, you narrow it to the network that should legitimately manage the server.
First, remove the general SSH service.
sudo firewall-cmd --permanent --remove-service=ssh
Note: You might see a warning like Warning: NOT_ENABLED: ssh. This is normal and expected. Since our default zone is trusted (which allows everything by default but has no specific services enabled), trying to remove a service that isn't explicitly listed triggers this harmless warning.
Second, add the specific Rich Rule for the subnet.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" service name="ssh" accept'
Reload to make these changes active.
sudo firewall-cmd --reload
Now, verify. First, check the services list.
sudo firewall-cmd --list-services
You should NOT see ssh here anymore (it was removed from the general services).
Next, check the Rich Rules.
sudo firewall-cmd --list-rich-rules
You should see a rule that accepts service name="ssh" from the specified source.
Audit Your Rules
In this step, in a production environment, it is best practice to perform a final audit of your firewall rules and back them up before closing your session. This ensures that the rules are applied in the correct order and that you have a recovery file.
In this step, you will export your Rich Rules to a text file for auditing.
First, list all Rich Rules and redirect the output to a file named rules_list.txt in your project folder.
sudo firewall-cmd --list-rich-rules > ~/project/rules_list.txt
Now, read the file to confirm the content is correct.
cat ~/project/rules_list.txt
You should see the list of rules you created in this lab. This file now serves as a simple backup of your rich rule configuration.
Summary
In this lab, you leveled up your firewall skills using Rich Rules. You learned how to:
- Block specific IPs (the "Reject" rule).
- Log security events (the "Camera" rule).
- Restrict sensitive services like SSH to trusted networks only.
- Audit your configuration by exporting rules to a file.
These advanced techniques give you the precision needed to secure complex environments.
