11/29/2017

Rich rules for Firewalld

Rich rules for Firewalld

Why Firewalld Rich Rules?


  1. You need more power than what's available with simply adding or removing services
  2. You want to make exceptions for certain hosts.
  3. You want to make exceptions for certain networks.
  4. You don't have experience with the iptables command needed for direct rules.

Basic Documentation

The man page for firewall-cmd does not cover rich rules. To get the man page about them use:

   man firewalld.richlanguage to view the details like... 

       A rule is part of a zone. One zone can contain several rules. If some rules
       interact/contradict, the first rule that matches "wins".

       Rich rule structure


           rule
             [source]
             [destination]
             service|port|protocol|icmp-block|icmp-type|masquerade|forward-port|source-port
             [log]
             [audit]
             [accept|reject|drop|mark]


Summary Firewalld Rich Rules common options:

rule [family="ipv4|ipv6"] 
source [not] address="address[/mask]"|mac="mac-address"|ipset="ipset"
destination [not] address="address[/mask]"
port port="port value" protocol="tcp|udp"
log [prefix="prefix text"] [level="log level"] [limit value="rate/duration"]
accept [limit value="rate/duration"]
reject [type="reject type"] [limit value="rate/duration"]
drop [limit value="rate/duration"]
mark set="mark[/mask]" [limit value="rate/duration"]


Working with reject action

Actually, I think for the reject action above, the type argument is mandatory. For the reject action, the type must use one of: 

icmp-host-prohibited, host-prohib, icmp-net-unreachable, net-unreach, icmp-host-unreachable, host-unreach, icmp-port-unreachable, port-unreach, icmp-proto-unreachable, proto-unreach, icmp-net-prohibited, net-prohib, tcp-reset, tcp-rst, icmp-admin-prohibited, admin-prohib 

In the whitelist used below you can notice a reject action:

reject type="icmp-host-prohibited"

Two simple firewall scenarios

Let's take two services running on a host, a web server and a dns server. The web server service should accept one host and reject all others, a simple whitelist using a reject action. The dns server service should accept all hosts except one, and drop all others, a simple blacklist using a drop action.

Whitelist one host for one service

In this scenario, the host 10.0.0.107 would be allowed access to the http service, but any other host (the 0.0.0.0/0 network) would be rejected. Beware, any reject or drop rules are evaluated before accept rules.

firewall-cmd --add-rich-rule='
rule family=ipv4 
source address="10.0.0.107" 
service name="http" 
log prefix="RICH HTTP ACCEPTED" 
accept' 

firewall-cmd --add-rich-rule='
rule family=ipv4 
source NOT address="10.0.0.107" 
service name="http" 
log prefix="RICH HTTP REJECTED " 
reject type="icmp-host-prohibited"

Monitoring the RICH HTTP firewall log

To see attempts to connect either be accepted or rejected, try to access the web server from the host 10.0.0.107 and 10.0.0.108, respectively after executing the following on a host like 10.0.0.5 with the httpd service running:

tail -f /var/log/messages | grep 'RICH HTTP '

Blacklist one host for one service

In this scenario, the host 10.0.0.107 would be blacklisted from accessing the DNS service, and its attempts to connect will be dropped. All other hosts will be accepted for access:

firewall-cmd --add-rich-rule='
rule family=ipv4 
source address="10.0.0.107" 
service name="dns" 
log prefix="RICH DNS DROPPED " 
drop'

firewall-cmd --add-rich-rule='
rule family=ipv4 
source address="0.0.0.0/0" 
service name="dns" 
log prefix="RICH DNS ACCEPTED " 
accept' 

Monitoring the RICH DNS firewall log

To see attempts to connect to the DNS server either be accepted or rejected, try to access the dns server from the host 10.0.0.107 and 10.0.0.108, respectively after executing the following on a host like 10.0.0.5 with the httpd service running:

tail -f /var/log/messages | grep 'RICH DNS '

Rich Rule Persistence

For the rules entered above to be maintained across restarting firewalld or the system, they need to be either added again with the --permanent option, or you can use the --runtime-to-permanent option to preserve the rules in the default zone (You can also create rich rules in other zones using the --zone option).


firewall-cmd --runtime-to-permanent

After the above command is executed the rules are saved to a file like /etc/firewalld/zones/public.xml based upon the default active zone. Although you can use the firewall-cmd --remove-rich-rules option to delete rich rules that you no longer want, you can also edit the zone xml file directly, and then use:

firewall-cmd --reload

Other Useful firewall-cmd commands:

firewall-cmd --get-active-zones
firewall-cmd --list-all
firewall-cmd --list-all-zones
firewall-cmd --list-rich-rules
firewall-cmd --help


No comments:

About Me - WrightRocket

My photo

I've worked with computers for over 30 years, programming, administering, using and building them from scratch.

I'm an instructor for technical computer courses, an editor and developer of training manuals, and an Android developer.