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.
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=seconds]
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 will be used. If a timeout is supplied, the rule or rules will be active for the amount of seconds specified and will be removed automatically afterwards.
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 will be 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. Prints yes with exit status 0, if enabled, prints no with exit status 1 otherwise. If the zone is omitted, the default zone will be used.
For information about the rich language representation used in the zone configuration files, see the
firewalld.zone(5) man page.
The format or structure of the rich rule commands is as follows:
rule [family="<rule family>"]
[ source address="<address>" [invert="True"] ]
[ destination address="<address>" [invert="True"] ]
[ <element> ]
[ log [prefix="<prefix text>"] [level="<log level>"] [limit value="rate/duration"] ]
[ audit ]
[ accept|reject|drop ]
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. If the rule family is provided, it can be either
ipv4 or ipv6, it limits the rule to IPv4 or IPv6. If the rule family is not provided, the rule will be added for both IPv4 and 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- 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
IPv4orIPv6. The network family (IPv4orIPv6) will be automatically discovered. ForIPv4, the mask can be a network mask or a plain number. ForIPv6the 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 addinginvert="true" orinvert="yes"; all but the supplied address will match. destination- 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. 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. The element can be exactly one of the element types:
service,port,protocol,masquerade,icmp-blockandforward-port. service- The service name is one of the firewalld provided services. To get a list of the supported services, issue the following command:
firewall-cmd --get-services. 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:service name=service_name port- The port can either be a single port number or a port range, for example, 5060-5062. The protocol can either be specified as
tcporudp. The command takes the following form:port port=number_or_range protocol=protocol protocol- The protocol value can be either a protocol ID number or a protocol name. For allowed protocol entries, see
/etc/protocols. The command takes the following form:protocol value=protocol_name_or_ID icmp-block- Use this command to block one or more
ICMPtypes. TheICMPtype is one of theICMPtypesfirewalld supports. To get a listing of supportedICMPtypes, issue the following command:~]$
Specifying an action is not allowed here.firewall-cmd --get-icmptypesicmp-blockuses the actionrejectinternally. The command takes the following form:icmp-block name=icmptype_name masquerade- 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-port- Forward packets from a local port with protocol specified as
tcporudpto either another port locally, to another machine, or to another port on another machine. Theportandto-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. Theforward-portcommand uses the actionacceptinternally. The command takes the following form:forward-port port=number_or_range protocol=protocol /to-port=number_or_range to-addr=address log- 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
emerg,alert,crit,error,warning,notice,infoordebug. The use of log is optional. It is possible to limit logging as follows:
The rate is a natural positive number [1, ..], the duration oflog [prefix=prefix text] [level=log level] limit value=rate/durations,m,h,d.smeans seconds,mminutes,hhours andddays. The maximum limit value is1/dwhich means at maximum one log entry per day. audit- Audit provides an alternative way for logging using audit records sent to the service
auditd. The audit type can be one ofACCEPT,REJECTorDROPbut it is not specified after the commandauditas 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. accept|reject|drop- An action can be one of
accept,rejectordrop. 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
Withacceptall new connection attempts will be granted. Withrejectthey will be rejected and their source will get a reject message. The reject type can be set to use another value. Withdropall packets will be dropped immediately and no information is sent to the source.
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
deny chain in order to have 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
reject and droprules will be placed in the “zone_deny” chain, which will be parsed after the log chain. All accept rules will be placed in the “zone_allow” chain, which will be parsed after the deny chain. If a rule contains log and also deny or allow actions, the parts are placed in the matching chains.
Enable new
IPv4 and IPv6 connections for authentication header protocol AH:rule protocol value="ah" accept
Allow new
IPv4 and IPv6 connections for protocol FTP and log 1 per minute using audit:rule service name="ftp" log limit value="1/m" audit accept
Allow new
IPv4 connections from address 192.168.0.0/24 for protocol TFTP and 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
New
IPv6 connections from 1:2:3:4:6:: for protocol RADIUS are all rejected and logged at a rate of 3 per minute. New IPv6 connections 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
Forward
IPv6 packets received from 1:2:3:4:6:: on port 4011 with protocol TCP to 1::2:3:4:7 on 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"
Local applications or services are able to change the firewall configuration if they are running as
root(for example, libvirt). With this feature, the administrator can lock the firewall configuration so that either no applications, or only applications that are added to the lockdown whitelist, are able to request firewall changes. The lockdown settings default to disabled. If enabled, the user can be sure that there are no unwanted configuration changes made to the firewall by local applications or services.
Using an editor running as
root, add the following line to the /etc/firewalld/firewalld.conf file as follows:Lockdown=yesReload the firewall using the following command as
root:~]# firewall-cmd --reload
Try to enable the service imaps in the default zone using the following command as an administrative user, that is to say, a user in group wheel (usually the first user on system). You will be prompted for the user password:~]$ firewall-cmd --add-service=imaps
Error: ACCESS_DENIED: lockdown is enabled
To enable the use of firewall-cmd, issue the following command as
root:~]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/firewall-cmd*'
Add the --permanent option if you want to make it persistent.
Reload the firewall as
root:~]# firewall-cmd --reload
Try to enable the imaps service again in the default zone by entering the following command as an administrative user. You will be prompted for the user password:~]$ firewall-cmd --add-service=imaps
This time the command succeeds.
To query whether lockdown is enabled, enter the following command as
root:~]# firewall-cmd --query-lockdown
Prints yes with exit status 0, if lockdown is enabled, prints no with exit status 1 otherwise.
To enable lockdown, enter the following command as
root:~]# firewall-cmd --lockdown-on
To disable lockdown, enter the following command as
root:~]# firewall-cmd --lockdown-off
The lockdown whitelist can contain commands, security contexts, users and user IDs. If a command entry on the whitelist ends with an asterisk “*”, then all command lines starting with that command will match. If the “*” is not there then the absolute command including arguments must match.
The context is the security (SELinux) context of a running application or service. To get the context of a running application use the following command:
~]$ ps -e --context
That command returns all running applications. Pipe the output through the grep tool to get the application of interest. For example:~]$ ps -e --context | grep example_program
To list all command lines that are on the whitelist, enter the following command as
root:~]# firewall-cmd --list-lockdown-whitelist-commands
To add a command command to the whitelist, enter the following command as
root:~]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'
To remove a command command from the whitelist, enter the following command as
root:~]# firewall-cmd --remove-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'
To query whether the command command is on the whitelist, enter the following command as
root:~]# firewall-cmd --query-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'
Prints yes with exit status 0, if true, prints no with exit status 1 otherwise.
To list all security contexts that are on the whitelist, enter the following command as
root:~]# firewall-cmd --list-lockdown-whitelist-contexts
To add a context context to the whitelist, enter the following command as
root:~]# firewall-cmd --add-lockdown-whitelist-context=context
Add the --permanent option to make it persistent.
To remove a context context from the whitelist, enter the following command as
root:~]# firewall-cmd --remove-lockdown-whitelist-context=context
Add the --permanent option to make it persistent.
To query whether the context context is on the whitelist, enter the following command
root:~]# firewall-cmd --query-lockdown-whitelist-context=context
Prints yes with exit status 0, if true, prints no with exit status 1 otherwise.
To list all user IDs that are on the whitelist, enter the following command as
root:~]# firewall-cmd --list-lockdown-whitelist-uids
To add a user ID uid to the whitelist, enter the following command as
root:~]# firewall-cmd --add-lockdown-whitelist-uid=uid
Add the --permanent option to make it persistent.
To remove a user ID uid from the whitelist, enter the following command as
root:~]# firewall-cmd --remove-lockdown-whitelist-uid=uid
Add the --permanent option to make it persistent.
To query whether the user ID uid is on the whitelist, enter the following command:
~]$ firewall-cmd --query-lockdown-whitelist-uid=uid
Prints yes with exit status 0, if true, prints no with exit status 1 otherwise.
To list all user names that are on the whitelist, enter the following command as
root:~]# firewall-cmd --list-lockdown-whitelist-users
To add a user name user to the whitelist, enter the following command as
root:~]# firewall-cmd --add-lockdown-whitelist-user=user
Add the --permanent option to make it persistent.
To remove a user name user from the whitelist, enter the following command as
root:~]# firewall-cmd --remove-lockdown-whitelist-user=user
Add the --permanent option to make it persistent.
To query whether the user name user is on the whitelist, enter the following command:
~]$ firewall-cmd --query-lockdown-whitelist-user=user
Prints yes with exit status 0, if true, prints no with exit status 1 otherwise.
The default whitelist configuration file contains the NetworkManager context and the default context oflibvirt. Also the user ID 0 is in the list.
<?xml version="1.0" encoding="utf-8"?> <whitelist> <selinux context="system_u:system_r:NetworkManager_t:s0"/> <selinux context="system_u:system_r:virtd_t:s0-s0:c0.c1023"/> <user id="0"/> </whitelist>
Here follows an example whitelist configuration file enabling all commands for the
firewall-cmdutility, for a user called user whose user ID is 815:<?xml version="1.0" encoding="utf-8"?> <whitelist> <command name="/usr/bin/python -Es /bin/firewall-cmd*"/> <selinux context="system_u:system_r:NetworkManager_t:s0"/> <user id="815"/> <user name="user"/> </whitelist>In this example we have shown both
user id and user name but only one is required. Python is the interpreter and therefore prepended to the command line. You can also use a very specific command, for example:/usr/bin/python /bin/firewall-cmd --lockdown-on
In that example only the --lockdown-on command will be allowed.
NOTE
In Red Hat Enterprise Linux 7, all utilities are now placed in
/usr/bin/ and the /bin/directory is sym-linked to the /usr/bin/ directory. In other words, although the path for firewall-cmd when run as root might resolve to /bin/firewall-cmd, /usr/bin/firewall-cmd can now be used. All new scripts should use the new location but be aware that if scripts that run as root have been written to use the /bin/firewall-cmdpath then that command path must be whitelisted in addition to the /usr/bin/firewall-cmd path traditionally used only for non-root users.
The “*” at the end of the name attribute of a command means that all commands that start with this string will match. If the “*” is not there then the absolute command including arguments must match.
Comentarios
Publicar un comentario