Managing Rich Rules in Firewalld

Apart from the regular zones and services syntax that firewalld offers, administrators have two other options for adding firewall rules: direct rules and rich rules.

 

Direct rules

Direct rules allow an administrator to insert hand-coded { ip, ip6,eb} tables rules into the zones managed by firewalld. While powerful, and exposing features of the kernel netfilter subsystem not exposed through other means, these rules can be hard to manage. Direct rules also offer less flexibility than standard rules and rich rules. Unless explicitly inserted into a zone managed by firewalld, direct rules will be parsed before any firewalld rules are.

A short example of adding some direct rules to blacklist an IP range is given below:

$ firewall-cmd  – – direct   – -permanent   – – add-chain  ipv4  raw  blacklist

$ firewall-cmd  – – direct   – -permanent   – – add-rule  ipv4  raw  PREROUTING  0  -s  192.168.0.0/24  -j  blacklist

$ firewall-cmd  – – direct   – -permanent   – – add-rule  ipv4  raw  blacklist       0  -m  limit  – -limit  1/min  -j  LOG  – -log-prefix  “blacklisted”

$ firewall-cmd  – – direct   – -permanent   – – add-rule  ipv4  raw  blacklist  1  -j  DROP

 

Rich rules

Firewalld rich rules give administrators an expressive language in which to express custom firewall rules that are not covered by the basic firewalld syntax. For example, to only allow connections to a service from a single IP address, instead of all IP addresses routed through a zone. Rich rule can be used to express basic allow/deny rules, but can also be used to configure logging, both to syslog and auditd, as well as port forwards, masquerading, and rate limiting. The basic syntax of a rich rule can be expressed by the following block.

rule

[source]

[destination]

Service |port|protocol|icmp-block|masquerade|forward port

[log]

[audit]

[accept|reject|drop]

Almost every single element of a rule can take additional arguments in the form of option=value

 

Rule ordering

Once multiple rules have been added to a zone or the firewall, the ordering of rules can have a big effect on how the firewall behaves.

The basic ordering of rules inside a zone is the same for all zones

1) Any port forwarding and masquerading rules set for that zone.

2) Any logging rules set for that zone.

3) Any deny rules set for that zone.

4) Any allow rules set for that zone.

In all cases, the first match will win. If a packet has not been matched by any rule in a zone, it will typically be denied, but zones might have a different default. For example, the trusted zone will accept any unmatched packet. Also, after matching a logging rule, a packet will continue to be processed as normal. Direct rules are the exception. Most direct rules will be parsed before any other processing is done by firewalld, but the direct rule syntax allows an administrator to insert any rule they want anywhere in any zone.

 

Testing and debugging

To make testing and debugging easier, almost all rules can be added to the runtime configuration with timeout. The moment the rule with timeout is added to the firewall, the timer starts counting down for that rule. Once the timer for a rule has reached zero seconds, that rule is removed from the runtime configuration. Using timeout can be an incredibly useful tool while working on a remote firewall, especially when testing more complicated rule sets. If a rule works, the administrator can add it again, but with the – -permanent option. If the rule does not work as intended, maybe even locking the administrator out of the system, it will be removed automatically, allowing the administrator to continue his or her work. A timeout is added to a runtime rule by adding the option – -timeout=<TIMEINSECONDS> to the end of the firewall-cmd that enables the rule.

 

If you need any further assistance please contact our support department.