5.15. Configuring Complex Firewall Rules with the "Rich Language" Syntax
With the “rich language” syntax, complex firewall rules can be created in a way that is easier to understand than the direct-interface method. In addition, the settings can be made permanent. The language uses keywords with values and is an abstract representation of iptables rules. Zones can be configured using this language; the current configuration method will still be supported.
5.15.1. Formatting of the Rich Language Commands
All the commands in this section need to be run as
root. The format of the command to add a rule is as follows:
firewall-cmd [--zone=zone] --add-rich-rule='rule' [--timeout=timeval]
This will add a rich language rule rule for zone zone. This option can be specified multiple times. If the zone is omitted, the default zone is used. If a timeout is supplied, the rule or rules only stay active for the amount of time specified and will be removed automatically afterwards. The time value can be followed by
h(hours) to specify the unit of time. The default is seconds.
To remove a rule:
firewall-cmd [--zone=zone] --remove-rich-rule='rule'
This will remove a rich language rule rule for zone zone. This option can be specified multiple times. If the zone is omitted, the default zone is used.
To check if a rule is present:
firewall-cmd [--zone=zone] --query-rich-rule='rule'
This will return whether a rich language rule rule has been added for the zone zone. The command prints
yeswith exit status
0if enabled. It prints
nowith exit status
1otherwise. If the zone is omitted, the default zone is used.
For information about the rich language representation used in the zone configuration files, see the firewalld.zone(5) man page.
5.15.2. Understanding the Rich Rule Structure
The format or structure of the rich rule commands is as follows:
rule [family="rule family"] [ source [NOT] [address="address"] [mac="mac-address"] [ipset="ipset"] ] [ destination [NOT] address="address" ] [ element ] [ log [prefix="prefix text"] [level="log level"] [limit value="rate/duration"] ] [ audit ] [ action ]
The structure of the rich rule in the file uses the
NOTkeyword to invert the sense of the source and destination address commands, but the command line uses the
A rule is associated with a particular zone. A zone can have several rules. If some rules interact or contradict, the first rule that matches the packet applies.
5.15.3. Understanding the Rich Rule Command Options
- If the rule family is provided, either
ipv6, it limits the rule to
IPv6, respectively. If the rule family is not provided, the rule is added for both
IPv6. If source or destination addresses are used in a rule, then the rule family needs to be provided. This is also the case for port forwarding.
Source and Destination Addresses
- By specifying the source address, the origin of a connection attempt can be limited to the source address. A source address or address range is either an IP address or a network IP address with a mask for
IPv4, the mask can be a network mask or a plain number. For
IPv6, the mask is a plain number. The use of host names is not supported. It is possible to invert the sense of the source address command by adding the
NOTkeyword; all but the supplied address matches.A MAC address and also an IP set with type hash:mac can be added for
familyis specified for the rule. Other IP sets need to match the
familysetting of the rule.
- By specifying the destination address, the target can be limited to the destination address. The destination address uses the same syntax as the source address for IP address or address ranges. The use of source and destination addresses is optional, and the use of a destination addresses is not possible with all elements. This depends on the use of destination addresses, for example, in service entries. You can combine
The element can be only one of the following element types:
serviceelement is one of the firewalld provided services. To get a list of the predefined services, enter the following command:
~]$If a service provides a destination address, it will conflict with a destination address in the rule and will result in an error. The services using destination addresses internally are mostly services using multicast. The command takes the following form:
portelement can either be a single port number or a port range, for example,
5060-5062, followed by the protocol, either as
udp. The command takes the following form:
port port=number_or_range protocol=protocol
protocolvalue can be either a protocol ID number or a protocol name. For allowed
/etc/protocols. The command takes the following form:
- Use this command to block one or more
ICMPtype is one of the
ICMPtypes firewalld supports. To get a listing of supported
ICMPtypes, enter the following command:
~]$Specifying an action is not allowed here.
icmp-blockuses the action
rejectinternally. The command takes the following form:
- Turns on IP masquerading in the rule. A source address can be provided to limit masquerading to this area, but not a destination address. Specifying an action is not allowed here.
- Forward packets from a local port with protocol specified as
udpto either another port locally, to another machine, or to another port on another machine. The
to-portcan either be a single port number or a port range. The destination address is a simple IP address. Specifying an action is not allowed here. The
forward-portcommand uses the action
acceptinternally. The command takes the following form:
forward-port port=number_or_range protocol=protocol /
- Matches the source port of the packet - the port that is used on the origin of a connection attempt. To match a port on current machine, use the
source-portelement can either be a single port number or a port range (for example, 5060-5062) followed by the protocol as
udp. The command takes the following form:
source-port port=number_or_range protocol=protocol
- Log new connection attempts to the rule with kernel logging, for example, in syslog. You can define a prefix text that will be added to the log message as a prefix. Log level can be one of
debug. The use of log is optional. It is possible to limit logging as follows:
The rate is a natural positive number [1, ..], with the duration of
log [prefix=prefix text] [level=log level] limit value=rate/duration
hmeans hours, and
ddays. The maximum limit value is
1/d, which means at maximum one log entry per day.
- Audit provides an alternative way for logging using audit records sent to the service
auditd. The audit type can be one of
DROP, but it is not specified after the command
auditas the audit type will be automatically gathered from the rule action. Audit does not have its own parameters, but limit can be added optionally. The use of audit is optional.
- An action can be one of
mark. The rule can only contain an element or a source. If the rule contains an element, then new connections matching the element will be handled with the action. If the rule contains a source, then everything from the source address will be handled with the action specified.
accept | reject [type=reject type] | drop | mark set="mark[/mask]"With
accept, all new connection attempts will be granted. With
reject, they will be rejected and their source will get a reject message. The reject type can be set to use another value. With
drop, all packets will be dropped immediately and no information is sent to the source. With
markall packets will be marked with the given mark and the optional mask.
5.15.4. Using the Rich Rule Log Command
Logging can be done with the Netfilter log target and also with the audit target. A new chain is added to all zones with a name in the format “zone_log”, where zone is the zone name. This is processed before the
denychain to have the proper ordering. The rules or parts of them are placed in separate chains, according to the action of the rule, as follows:
zone_log zone_deny zone_allow
All logging rules will be placed in the “zone_log” chain, which will be parsed first. All
droprules will be placed in the “zone_deny” chain, which will be parsed after the log chain. All
acceptrules will be placed in the “zone_allow” chain, which will be parsed after the
denychain. If a rule contains
allowactions, the parts of the rule that specify these actions are placed in the matching chains.
220.127.116.11. Using the Rich Rule Log Command Example 1
IPv6connections for authentication header protocol
rule protocol value="ah" accept
18.104.22.168. Using the Rich Rule Log Command Example 2
IPv6connections for protocol
FTPand log 1 per minute using audit:
rule service name="ftp" log limit value="1/m" audit accept
22.214.171.124. Using the Rich Rule Log Command Example 3
IPv4connections from address
TFTPand log 1 per minute using syslog:
rule family="ipv4" source address="192.168.0.0/24" service name="tftp" log prefix="tftp" level="info" limit value="1/m" accept
126.96.36.199. Using the Rich Rule Log Command Example 4
RADIUSare all rejected and logged at a rate of 3 per minute. New
IPv6connections from other sources are accepted:
rule family="ipv6" source address="1:2:3:4:6::" service name="radius" log prefix="dns" level="info" limit value="3/m" reject rule family="ipv6" service name="radius" accept
188.8.131.52. Using the Rich Rule Log Command Example 5
IPv6packets received from
1:2:3:4:6::on port 4011 with protocol
1::2:3:4:7on port 4012.
rule family="ipv6" source address="1:2:3:4:6::" forward-port to-addr="1::2:3:4:7" to-port="4012" protocol="tcp" port="4011"
184.108.40.206. Using the Rich Rule Log Command Example 6
Whitelist a source address to allow all connections from this source.
rule family="ipv4" source address="192.168.2.2" accept
firewalld.richlanguage(5)man page for more examples.