Note: This is an RHCSA 7 exam objective and an RHCE 7 exam objective.
Presentation
Firewalld is the new userland interface in RHEL 7. It replaces the iptables interface and connects to the netfilter kernel code. It mainly improves the security rules management by allowing configuration changes without stopping the current connections.
To know if Firewalld is running, type:
# systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled) Active: active (running) since Tue 2014-06-17 11:14:49 CEST; 5 days ago ...
or alternatively:
# firewall-cmd --state running
Note: If Firewalld is not running, the command displays not running.
If you’ve got several network interfaces in IPv4, you will have to activate ip forwarding.
To do that, paste the following line into the /etc/sysctl.conf file:
net.ipv4.ip_forward=1
Then, activate the configuration:
# sysctl -p
Note: If you interested in kernel parameter configuration, there is a tutorial about the sysctl command.
Although Firewalld is the RHEL 7 way to deal with firewalls and provides many improvements, iptables can still be used (but both shouldn’t run at the same time).
You can also look at the iptables rules created by Firewalld with the iptables-save command.
Zone Management
Also, a new concept of zone appears: all network interfaces can be located in the same default zone or divided into different ones according to the levels of trust defined. In the latter case, this allows to restrict traffic based on origin zone (read this article from lwn.net for more details).
Note: Without any configuration, everything is done by default in the public zone. If you’ve got more than one network interface or use sources (see Source management section below), you will be able to restrict traffic between zones.
To get the default zone, type:
# firewall-cmd --get-default-zone public
To get the list of zones where you’ve got network interfaces or sources assigned to, type:
# firewall-cmd --get-active-zones public interfaces: eth0
Note: You can have more than one active zone at a time.
To get the list of all the available zones, type:
# firewall-cmd --get-zones block dmz drop external home internal public trusted work
To change the default zone to home permanently, type:
# firewall-cmd --set-default-zone=home success
Note: This information is stored in the /etc/firewalld/firewalld.conf file.
Network interfaces can be assigned to a zone in a permanent way.
To permanently assign the eth0 network interface to the internal zone (a file called internal.xml is created in the /etc/firewalld/zones directory), type:
# firewall-cmd --permanent --zone=internal --change-interface=eth0 success # nmcli con show | grep eth0 System eth0 4de55c95-2368-429b-be65-8f7b1a357e3f 802-3-ethernet eth0 # nmcli con mod "System eth0" connection.zone internal # nmcli con up "System eth0" Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)
Note1: This operation can also be done by editing the /etc/sysconfig/network-scripts/ifcfg-eth0 file and add ZONE=internal followed by # nmcli con reload . It seems that with RHEL 7.5, the use of ZONE in ifcfg-* files no longer works (source).
Note2: More information about the nmcli command is available at the page dedicated to nmcli or at the IPV4 configuration page.
Note3: The RHEL 7.3 release improves the way Firewalld handles zones (v0.3.9 -> v0.4.3.2: BZ#1302802).
To know which zone is associated with the eth0 interface, type:
# firewall-cmd --get-zone-of-interface=eth0 internal
To get the permanent configuration of the public zone, type:
# firewall-cmd --permanent --zone=public --list-all public (default, active) interfaces: eth0 sources: services: dhcpv6-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules:
It is also possible to create new zones. To create a new zone (here test), type:
# firewall-cmd --permanent --new-zone=test success # firewall-cmd --reload success
Note: Only permanent zones can be created.
Source Management
A zone can be bound to a network interface (see above) and/or to a network addressing (called here a source).
Any network packet entering in the network stack is associated with a zone.
The association is done according to the following pattern:
– is the packet coming from a source already bound to a zone? (if yes, it is associated with this zone),
– if not, is the packet coming from a network interface already bound to a zone? (if yes, it is associated with this zone),
– if not, the packet is associated with the default zone.
This way, multiple zones can be defined even on a server with only one network interface!
Caution: To get this feature, Firewalld relies on NetworkManager (see reference). This means that if you plan to stop NetworkManager for any reason (for example when building a KVM host), you will have to stop Firewalld and use Iptables instead!
Note: With the RHEL 7.3 release, Firewalld robustness has been improved in regard to NetworkManager (see details here).
To add a source (here 192.168.2.0/24) to a zone (here trusted) permanently, type:
# firewall-cmd --permanent --zone=trusted --add-source=192.168.2.0/24 success # firewall-cmd --reload success
Note1: Use the –remove-source option to delete a previous assigned source.
Note2: Use the –change-source option to move the source to the new specified zone.
Note3: If you want to temporarily add a source to a zone, don’t use the –permanent option and don’t reload the firewall configuration. If you reload the firewall configuration, this will cancel all the operation.
Note4: You can also make some changes and when you like your new configuration, have it become your permanent configuration with the firewall-cmd –runtime-to-permanent command.
With the RHEL 7.3 release, you can add a source based on a MAC address (here 00:11:22:33:44:55) to a zone (here trusted) permanently:
# firewall-cmd --permanent --zone=trusted --add-source=00:11:22:33:44:55 success # firewall-cmd --reload success
With the RHEL 7.3 release, you can create an ipset (a set of IP addresses or networks, see below) and add a source based on it:
# firewall-cmd --permanent --new-ipset=iplist --type=hash:ip success # firewall-cmd --reload success # firewall-cmd --ipset=iplist --add-entry=192.168.1.11 success # firewall-cmd --ipset=iplist --add-entry=192.168.1.12 success # firewall-cmd --permanent--zone=trusted --add-source=ipset:iplist success # firewall-cmd --reload success
To get the list of the sources currently bound to a zone (here trusted), type:
# firewall-cmd --permanent --zone=trusted --list-sources 192.168.2.0/24 00:11:22:33:44:55 ipset:iplist
Note: Remove the –permanent option if you only want to display temporary settings.
To keep track of your configuration (active zones are zones that have a binding to an interface or source), type:
# firewall-cmd --get-active-zones public interfaces: eth0 trusted sources: 192.168.2.0/24
As an exemple of source management, let’s assume you want to only allow connections to your server from a specific IP address (here 1.2.3.4/32).
# firewall-cmd --zone=internal --add-service=ssh --permanent success # firewall-cmd --zone=internal --add-source=1.2.3.4/32 --permanent success # firewall-cmd --zone=public --remove-service=ssh --permanent success # firewall-cmd --reload success
Source: Serverfault website.
With RHEL 7.3, a new option called –info-zone is available.
To get the detail of a zone called public, type:
# firewall-cmd --info-zone=public public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
Note: You can also add the –permanent option.
Service Management
After assigning each network interface to a zone, it is now possible to add services to each zone.
To allow the http service permanently in the internal zone, type:
# firewall-cmd --permanent --zone=internal --add-service=http success # firewall-cmd --reload success
Note1: Type –remove-service=http to deny the http service.
Note2: The firewall-cmd –reload command is necessary to activate the change. Contrary to the –complete-reload option, current connections are not stopped.
Note3: If you only want to temporarily add a service, don’t use the –permanent option and don’t reload the firewall configuration. If you reload the firewall configuration, you cancel all the operation.
If you want to temporary add several services (here http, https, and dns) at the same time in the internal zone, type:
# firewall-cmd --zone=internal --add-service={http,https,dns}
success
To get the list of services in the default zone, type:
# firewall-cmd --list-services dhcpv6-client ssh
Note: To get the list of the services in a particular zone, add the –zone= option.
With RHEL 7.3, a new option called –info-service is available.
To get some information about the ftp service, type:
# firewall-cmd --info-service=ftp ftp ports: 21/tcp protocols: source-ports: modules: nf_conntrack_ftp destination:
Note: You can also add the –permanent option.
Firewall Services Configuration
With the Firewalld package, the firewall configuration of the main services (ftp, httpd, etc) comes in the /usr/lib/firewalld/services directory. But it is still possible to add new ones in the /etc/firewalld/services directory. Also, if files exist at both locations for the same service, the file in the /etc/firewalld/services directory takes precedence.
For example, it is the case of the HAProxy service. There is no firewall configuration associated.
Create the /etc/firewalld/services/haproxy.xml and paste the following lines:
<?xml version="1.0" encoding="utf-8"?> <service> <short>HAProxy</short> <description>HAProxy load-balancer</description> <port protocol="tcp" port="80"/> </service>
Note: You can use the firewall-cmd –permanent –new-service=haproxy command to quickly create a configuration file skeleton.
Assign the correct SELinux context and file permissions to the haproxy.xml file:
# cd /etc/firewalld/services # restorecon haproxy.xml # chmod 640 haproxy.xml
Add the HAProxy service to the default zone permanently and reload the firewall configuration:
# firewall-cmd --permanent --add-service=haproxy success # firewall-cmd --reload success
Note: According to Bert Van Vreckem, it is possible to go quicker by using the command history (see details here):
# firewall-cmd --add-service=haproxy success # firewall-cmd --add-service=haproxy --permanent success
In RHEL 7.0 (Firewalld v0.3.9.7), there were 47 firewall services configured: amanda-client, bacula, bacula-client, dhcp, dhcpv6, dhcpv6-client, dns, ftp, high-availability, http, https, imaps, ipp, ipp-client, ipsec, kerberos, kpasswd, ldap, ldaps, libvirt, libvirt-tls, mdns, mountd, ms-wbt, mysql, nfs, ntp, openvpn, pmcd, pmproxy, pmwebapi, pmwebapis, pop3s, postgresql, proxy-dhcp, radius, rpc-bind, samba, samba-client, smtp, ssh, telnet, tftp, tftp-client, transmission-client, vnc-server, wbem-https.
In RHEL 7.1 (Firewalld v0.3.9.11), the RH-Satellite-6 service was added.
In RHEL 7.2 (Firewalld v0.3.9.14), the freeipa-ldaps, freeipa-ldap, freeipa-replication, iscsi-target, rsyncd and vdsm services were added.
In RHEL 7.3 (Firewalld v0.4.3.2), the amanda-k5-client, ceph, ceph-mon, docker-registry, dropbox-lansync, imap, kadmin, mosh, pop3, privoxy, ptp, pulseaudio, puppetmaster, sane, smtps, snmp, snmptrap, squid, synergy, syslog, syslog-tls, tinc, tor-socks, xmpp-bosh, xmpp-client, xmpp-local and xmpp-server services have been added for a total of 81 services.
Port Management
Port management follows the same model as service management.
To allow the 443/tcp port temporarily in the internal zone, type:
# firewall-cmd --zone=internal --add-port=443/tcp success
Note1: To make the configuration permanent, add the –permanent option and reload the firewall configuration.
Note2: Type –remove-port=443/tcp to deny the port.
To get the list of ports currently open in the internal zone, type:
# firewall-cmd --zone=internal --list-ports 443/tcp
Note: To only get the list of ports permanently open, add the –permanent option. Here, you will not get anything.
Rich Rules
As the syntax used by the rich rules are somehow difficult to remember, keep in mind the man firewalld.richlanguage command and the Example section at the end.
Here is the format of a rich rule:
# firewall-cmd --add-rich-rule 'rule ...'
To allow all connections from 192.168.2.2, type:
# firewall-cmd --add-rich-rule 'rule family="ipv4" source address="192.168.2.2" log accept'
Note1: The log option writes coming packets into the /var/log/messages file.
Note2: Use the –remove-rich-rule option instead of the –add-rich-rule option if you want to delete an already existing rule.
To list the rich rules set in the default zone, type:
# firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.2.2" log accept
Direct Rules
It is still possible to set specific rules by using the direct mode (here to open the tcp port 9000) that by-passes the Firewalld interface:
# firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 9000 -j ACCEPT success
Note1: This example has been borrowed from Khosro Taraghi’s blog.
Note2: Use the same command with the –remove-rule instead of –add-rule to delete the rule.
Note3: The configuration is temporary except if you add the –permanent option just after the –direct option.
Note4: It is not necessary to reload the firewall configuration, all commands are directly activated.
To display all the direct rules added, type:
# firewall-cmd --direct --get-all-rules
Note1: For information, the configuration is written into the /etc/firewalld/direct.xml file.
Note2: Direct rules are not part of the RHCSA/RHCE exam objectives.
IP Set Management
With the RHEL 7.3 comes the ability to create ipsets. An ipset is a set of IP addresses or networks. The different categories belong to hash:ip or hash:net.
To create a permanent IPv4 ipset containing two IP addresses and drop packets coming from these addresses, type:
# firewall-cmd --permanent --new-ipset=blacklist --type=hash:ip success # firewall-cmd --reload success # firewall-cmd --ipset=blacklist --add-entry=192.168.1.11 success # firewall-cmd --ipset=blacklist --add-entry=192.168.1.12 success # firewall-cmd --add-rich-rule='rule source ipset=blacklist drop' success
Note: Add –option=family=inet6 to create an IPv6 ipset.
To get the content of the blacklist ipset, type:
# firewall-cmd --info-ipset=blacklist blacklist type: hash:ip options: entries: 192.168.1.11 192.168.1.12
To remove the 192.168.1.12 entry from the blacklist ipset, type:
# firewall-cmd --ipset=blacklist --remove-entry=192.168.1.12 success # firewall-cmd --ipset=blacklist --get-entries 192.168.1.11
To create a permanent IPv4 ipset containing two networks, type:
# firewall-cmd --permanent --new-ipset=netlist success # firewall-cmd --reload success # firewall-cmd --ipset=netlist --add-entry=192.168.1.0/24 success # firewall-cmd --ipset=netlist --add-entry=192.168.2.0/24 success # firewall-cmd --info-ipset=netlist netlist type: hash:net options: entries: 192.168.1.0/24 192.168.2.0/24 To remove the netlist ipset, type: # firewall-cmd --permanent --delete-ipset=netlist success # firewall-cmd --reload success # firewall-cmd --get-ipsets blacklist It is also possible to download the content of an ipset from a file (--add-entries-from-file=file option) or store it with the name ipset in the /etc/firewalld/ipsets/ipset.xml or /usr/lib/firewalld/ipsets/ipset.xml files according to the following format:
<?xml version="1.0" encoding="utf-8"?> <ipset type="hash:ip"> <short>My Ipset</short> <description>description</description> <entry>192.168.1.11</entry> <entry>192.168.1.12</entry> </ipset>
To load this ipset, type:
# firewall-cmd --reload
Masquerading
If your firewall is your network gateway and you don’t want everybody to know your internal addresses, you can set up two zones, one called internal, the other external, and configure masquerading on the external zone. This way, all packets will get your firewall ip address as source address.
To set up masquerading on the external zone in a temporary way, type:
# firewall-cmd --zone=external --add-masquerade success
Note1: To remove masquerading, use the –remove-masquerade option.
Note2: To know if masquerading is active in a zone, use the –query-masquerade option.
Note3: To get the configuration permanent, add the –permanent option and reload the firewall configuration.
Port Forwarding
Port forwarding is a way to forward inbound network traffic for a specific port to another internal address or an alternative port.
Caution: Port forwarding requires masquerading (source). This point is a classical mistake made during the RHCE exam.
So, you need to enable masquerading before anything else:
# firewall-cmd --zone=external --add-masquerade success
If you want all packets intended for port 22 to be now forwarded to port tcp 3753 temporarily, type:
# firewall-cmd --zone=external --add-forward-port=port=22:proto=tcp:toport=3753 success
Note1: To remove port forwarding, use the –remove-forward-port option.
Note2: To know if port forwarding is active in a zone, use the –query-forward-port option.
Note3: If you want to make the configuration permanent, add the –permanent option and reload the firewall configuration.
Also, if you want to define the destination ip address, this time in a permanent way, type:
# firewall-cmd --permanent --zone=external --add-forward-port=port=22:proto=tcp:toport=3753:toaddr=10.0.0.1 success # firewall-cmd --reload success
Special Modules
Sometimes it is required to download specific modules. Instead of using a rc.local file, it is better to notify Firewalld through the /etc/modules-load.d directory.
In this example we want to add the ip_nat_ftp and ip_conntrack_ftp modules to follow ftp connections.
We only need to choose a filename (here firewall_ftp.conf) and type these instructions:
# echo ip_nat_ftp > /etc/modules-load.d/firewall_ftp.conf # echo ip_conntrack_ftp >> /etc/modules-load.d/firewall_ftp.conf
Source: StackExchange website.
Offline Configuration
In some cases (installations through Anaconda or Kickstart for example), you need to set up firewall rules when Firewalld is not running. The firewall-offline-cmd command has just been created for this purpose.
For instance, to open the tcp port 22, you would type in the /etc/sysconfig/iptables file:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
Instead, you can now execute the following command:
# firewall-offline-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
Configuration Backup
To store the current configuration into files, type:
# iptables -S > firewalld_rules_ipv4 # ip6tables -S > firewalld_rules_ipv6
Debugging Tips
To better understand how Firewalld works, assign the ‘–debug’ value to the FIREWALLD_ARGS variable in the /etc/sysconfig/firewalld file:
# firewalld command line args # possile values: --debug FIREWALLD_ARGS='--debug'
Restart the Firewalld daemon:
# systemctl restart firewalld
Note: Messages will be written into the /var/log/firewalld file.
Also, with the RHEL 7.3 release comes the LogDenied directive in the /etc/firewalld/firewalld.conf file.
This directive adds logging rules right before reject and drop rules in the INPUT, FORWARD and OUTPUT chains for the default rules and also final reject and drop rules in zones.
Possible values are: all, unicast, broadcast, multicast and off (value by default).
Reload the Firewalld configuration:
# firewall-cmd --reload
Note: Messages will be written into the /var/log/messages file. If you also want messages to be written in a file called /var/log/custom.log, edit the /etc/rsyslog.conf file, add the line kern.warning /var/log/custom.log and restart the rsyslog configuration with # systemctl restart rsyslog
Additional Resources
In addition, you can:
- read this article about Firewalld by Sander van Vugt,
- watch Thomas Woerner‘s video about Firewalld, present and future (48min/2015),
- read this FedoraProject page about Fail2ban with Firewalld,
- read the CIS RHEL 7 Server Hardening Guide,
- watch Venkat Nagappan‘s video about Firewalld Concepts and Examples (34min/2015),
- watch Sander van Vugt‘s video about port forwarding using firewall-cmd (8min/2015),
- watch Ralph Nyberg‘s video about Firewalld and Iptables (26min/2016),
- read Thomas Woerner‘s blog, the blog of the author of Firewalld,
- read this presentation from the 11th Netfilter Workshop (2015),
- read the changelog of the Firewalld versions,
- have a look at ‘s blog about Configuring zones bound by source IPs in Firewalld or Comparing and contrasting Uncomplicated Firewall and Firewalld,
- read Alexander Molochko‘s blog about Creating a new zone in Firewalld.
Sources: RHEL7 Security Guide, wiki Fedora project.
Test yourself!
I started studying with RHEL 6 in April and switched over to 7 – As a result, I spent a lot of time honing iptables skills only to have firewalld take over (similar to sysvinit and systemd).
I honestly prefer iptables as I am much more comfortable with it on the fly and the exam requirement states that you can still use iptables to fulfill any firewall requirements. Therefore, I think it might be helpful to some to show how to disable firewalld in favor of iptables.
> systemctl disable firewalld
> systemctl stop firewalld
> yum -y install iptables-services
> touch /etc/sysconfig/iptables
> touch /etc/sysconfig/iptables6
> systemctl start iptables
> systemctl start ip6tables
> systemctl enable iptables
> systemctl enable ip6tables
This will make it so that iptables is the preferred firewall service. You can then add firewall rules to /etc/sysconfig/iptables manually or use iptables -a [RULE YOU WANT] to append a rule to the chain you specify.
Also, in learning firewall-cmd, it helped me to visualize the concepts of zoning better by first using the gui tool firewall-config (Applications | Sundry | Firewall) and then going back and learning the command line equivalents.
Okay I have a few questions. They are as follows:
1: Has red Hat cancelled RHCE 6 and only has RHCE7 or can on still take RHCE6 for now?
2: I also prefer iptables but funny enough the manually configured iptables information did not persist reboot but I guess I may have to use system-config-firewall to make my modifications.
I look forward to your response.
Thanks in advance.
Concerning RHCE6, according to Red Hat training department (see the comment associated with my last post “RHCSA & RHCE 6 last call”), you could take the exam in its kiosk version until Feb 28, 2016 if you purchase the vouncher before Feb 28, 2015.
Concerning the iptables information, you should be able to persist your modifications whatever the way (manual/automatic, gui/cli).
I don’t understand the relationship between iptables and firewalld. They seem to reference each other, but are two different firewalls, each with their own config files. Can you explain how the two are related, and how to remove iptables completely and work solely with firewalld?
The iptables and firewalld services use the iptables userland component that talks to the netfilter kernel component.
The iptables and firewalld services are mutually exclusive, they can’t run at the same time.
The iptables service is a pseudo service: it relies on the /etc/sysconfig/iptables file to set up the firewall configuration but doesn’t run permanently.
To remove the iptables service, you can use the instructions given for disabling the firewalld service (http://www.certdepot.net/rhel7-disable-firewalld-use-iptables/) and apply opposite commands (enable -> disable, disable -> enable, start -> stop, stop -> start).
Personally i think firewalld is overally complicated for most server environments, it is probably more useful for graphical users. Setting up a chain for a device (or assigning a zone to an interface in firewalld) is fairly simple in iptables directly, most servers have a single interface(or bonded single) so really the usercase is small. The addition of rich rules appears more complex then one directly in iptables. Not really sure what other Administrators do but I always insert iptables and save, this does not require a reload of iptables like they make you think is an advantage with firewalld (but then again I have never used graphical ui to do iptables). Do people really run servers in graphical?
I don’t think unfortunately you can disable firewalld for RHEL7 RHCE as it is listed specifically in the objectives. So I guess learn to love it and don’t take RHCE until you are comfortable with it.
The RHCSA objective about firewalling is pretty clear: Configure firewall settings using firewall-config, firewall-cmd, or iptables. If you don’t like Firewalld, Red Hat allows you to use Iptables and you can perfectly disable Firewalld.
For the RHCE exam it is however specifically listed as an objective.
“Use firewalld and associated mechanisms such as rich rules, zones and custom rules, to implement packet filtering and configure network address translation (NAT)”
You may very well be able to disable it in RHCSA exam but then they probably want you to do something far simpler with it so probably not much point.
There is something which really confuses me, when doing a port forward like the command below you mentioned:
# firewall-cmd –zone=external –add-forward-port=port=22:proto=tcp:toport=3753
I know that I have to use the –add-masquerade, but do I need also to do the sysctl.conf and add the net.ipv4.ip_forward=1 or in which case I do this?
From what I understand (I didn’t test it), if you don’t specify the toaddr=10.0.0.1 part, you are doing a port forwarding to the localhost, so you don’t need to set up ip_forwarding=1.
ip_forwarding=1 is needed when you allow a packet coming from one network interface to go through another network interface, not when it’s a local port redirection.
On the other hand, when you add the toaddr=10.0.0.1 part, it’s clear that you need to set up ip_forwarding=1.
thanks so much for the detailed answer !
Under “Port management” you ran “–add-port” temporarily. You should remove the “–reload”, otherwise “–remove-port” fails.
You are perfectly right, the firewall-cmd –reload command should be removed. Thanks.
Can direct rules be added and seen on the firewall GUI?
I haven’t tried.
I am trying to use a spare router as a gateway for the internal zone.No internet access just to create an intranet of all my servers so as to practice then port forwarding between the internal zone and the public zone..Would you please post a link on how to do that..
Also for some unexplained reason firewalld keeps assigning all my interfaces to the default zone.I assign them to other zones (–remove-interface and then –add-interface permanent etc and –reload)and although it is ok after a reboot they are all again stacked together in the default zone..I am furious beyond words….:)
Thanks a lot…
Your site is like nectar from Heaven 🙂
Depending on the RHEL/CentOS 7 version that you used, there are several known bugs about zones in Firewalld (1239326, 1273888, etc). Don’t give up!
Hi!
Interfaces will always revert to the default zone if they do not have an alternative zone defined within their configuration. Just add in
/etc/sysconfig/network-scripts/ifcfg-eth0 “zone=internal”
after that:
systemctl restart network.service
systemctl restart firewalld.service
and zone internal will be active with interface eth0
Zone management is still a work in progress in Firewalld. Thanks.
I would say that the RedHat way should be to both place the interface in the given zone using firewall-cmd AND set the zone in the connection by using nmcli connection.zone.
ifup scripts reset the if zone no matter what you set in the firewall config. Ugly state of affairs.
BTW, I was bitten by the default ACCEPT target of the trusted zone. You don’t need to add services to trusted (no brainer) but some port forwarding does not work either there. Case in point, I had httpd listening on both 80 and 82, and added a port forward from port 80 to 82 in trusted. Expecting to go to 82 when client requested 80… no, it went to 80. On other zones this works.
Maybe it’s right under my nose and I just don’t see it. What are the equivalent firewalld CLI commands to list the firewall rules?
Something like iptables -L.
For a given zone, I would say: firewall-cmd –zone=zone –list-all
Can somebody help in case they know ? I’m unable to implement 1) and 3) rules using rich-rules and zones. Think you need to use direct rules
Create a permanent rich rule configuration in the DMZ that matches the following requirements:
1) All packets coming in from the 10.0.1.0/24 network should be blocked.
2) All packets that are addressed to the SSH services should be logged with a maximum of two packets per minute. The messages should be logged with the “debug” log level, and the prefix “SSH:“.
3) If packets are coming from the host with IP address 10.0.1.1 and are addressed to port 80 or 22, they should be accepted.
I’m configuring firewalld for a project, where NetworkManager is disabled for our standard RHEL7/CentOS7 build, and nearly followed your advice to disable firewalld and migrate to iptables:
“Caution: To get this feature, Firewalld relies on NetworkManager (see reference). This means that if you plan to stop NetworkManager for any reason (for example when building a KVM host), you will have to stop Firewalld and use Iptables instead!”
The RHEL7 reference actually advises to use the –permanent –add-interface option:
“IMPORTANT
The –permanent –add-interface option is supposed to be used only for interfaces that are not managed by the NetworkManager utility. This is because NetworkManager, or the legacy network service, adds interfaces into zones automatically according to the ZONE= directive in the ifcfg interface configuration file. See the Red Hat Enterprise Linux 7 Networking Guide for information on NetworkManager and working with ifcfg files.”
Otherwise, this is a great reference, thanks!
I was not aware of this. Red Hat documentation regularly receives updates and the NetworkManager component evolves too. It is difficult to follow everything.
I personally find the writing not very clear. After reading it several times, which shouldn’t normally be necessary, I understand a specific role of the –add-interface option. But there is currently nothing about this supposed link between the –add-interface option and the NetworkManager component in the firewall-cmd man page.
Concerning the ZONE directive, it is one of the weakest features of Firewalld. Zones are supposed to be central to Firewalld and I haven’t found any firewall-cmd command to set them! You have to execute a NetworkManager command or write it directly into an ifcfg file.
Let me know if what you try to do, using Firewalld without NetworkManager, works as you expect because this combination seems weird. Also, it is almost official that deactivate NetworkManager won’t be possible in the next main RHEL release.
Hi CertDepot,
Do we need to be expert in firewall configuration on the exam? Since I’m new to RHEL I only know the basics config like add services, port, zone, etc. But with regards to port forwarding and masquerading as of this writing I’m still trying to get the concept.
Port forwarding and masquerading are not very complicated concepts.
Port forwarding consists in listening on a port and redirecting on another one.
Masquerading involves a server used as a gateway with NAT (Network Address Translation).
Thanks CertDepot, Is there a way I cannot be concerned about this “net.ipv4.ip_forward=1”?
I might forget this one. I don’t see any examples of this on the sysctl manual page. Do you have any idea where I can find examples? Thanks
This is pretty simple. Each time you want to take packets from one interface and put them on another interface (act like a router), you need to set up IP Forwarding with net.ipv4.ip_forward=1 in the /etc/sysctl.conf file.
Thanks CertDepot.
Hi CertDepot,
I’ve tried to concatenate this file
# cat /proc/sys/net/ipv4/ip_forward
Is it related to net.ipv4.ip_forward=1? Can I use this also instead of adding net.ipv4.ip_forward=1 on /etc/sysctl.conf file?
The answer is there.
Thanks CertDepot!
command ‘sysctl -a |grep forward’ can give you information if ip forwarding is enabled or not. 🙂
Yes, absolutely.
I’ve got a question about routing with firewalld. I managed to get routing working between two network interfaces, eth0 and eth1, by using direct (–direct)rules.
However, I read that direct options should be used only as a last resort when it’s not possible to use for example –add-rich-rule=’rule’.
Does anyone know a way of configuring routing between eth0 and eth1 interfaces with rich rules?
For example, the direct rule I have to allow VMs on a dmz (eth1) to access public network (eth0) on SSH port:
# firewall-cmd –direct -add-rule ipv4 filter FORWARD 0 -i eth1 -o eth0 -p tcp –dport 22 -j ACCEPT
How would one do this with rich rules? I read the man pages for richlanguage, not much of a help.
It turns out that I only need to enable masquerading on the public interface, and enable ip_forward. No other config is required to make routing work basically.
Hello CertDepot, How do I query default FORWARD policy using firewall-cmd?
With the firewall-cmd command, I don’t know. Otherwise, you can use iptables -L FORWARD
There is perhaps a solution based on a direct rule.
The below will list any FORWARD chain direct rules that exists:
# firewall-cmd –direct –get-all-rules
I am not familiar yet with firewalld, and now I know why, because it is completely not intuitive.
In my opinion, when you have got the router, based on the linux system, you should still choose iptables.
Firewalld still looks like a beta version, and you still write the direct rules if you want to do something more complicated 🙁
I do not completely understand the idea of preconfig 9 zones (why not 7 maybe 11), the better way is to give the option to create the new zones by admin, how many he need.
1. Is it possible to create completely new zone?
2. you write that the order of processing packets is:
a) zone with source definition
b) zone with interface definition
c) zone default
What if I have 2 zones with similar source which are different by mask, which zone will be first to process?
I agree with you, Firewalld is not very intuitive.
1. Yes, it is possible to create new zones: # firewall-cmd –permanent –new-zone=test
I’m sure you then need to edit a xml file to complete the configuration.
2. Your example is a corner case not supposed to happen in normal life. I don’t know the answer.
Editing the xml file does not seem to be necessary. I have tested by creating a new zone. corresponding xml file gets auto generated and any permanent settings to this zone gets automatically written to the xml file in the /etc/firewalld/zones/ directory.
Interesting. Thanks.
I’ve tried to backup and restore the firewalld configuration via “iptables -S” and “iptables-save” and restoring via “iptables-restore” , but it didn’t work.
The only solution I have found to do the trick is to backup via “cp -a /etc/firewalld /some_location/” and later restore via “cp -a /some_location/firewalld/ /etc” and reloading via “firewall-cmd –reload”
And if you want to test something you can always prevent locking yourself via:
1.Set atd to reload the firewall in some time in advance
2.”firewall-cmd ” without permanent
3.And if you like it “firewall-cmd –runtime-to-permanent”
Interesting. Thanks.
When asked to configure a firewall in exam which allows so and so service.. are we supposed to create a new zone or editing any of the preconfigured zones will be ok?
Thanks.
In the RHCSA exam, from my knowledge, there was never a question about setting up a new zone or modifying the content of an existing zone. This is not part of the exam objectives.
I am confused …so what does “Configure firewall settings using firewall-config, firewall-cmd, or iptables.” means? I mean when they ask for any setting change regarding firewall like allow http service or allow these host… don’t we have to do them in a zone.
Thanks.
To my knowledge, zones are not used in the exams.
When they ask any firewalld configuration, everything is done in the default zone.
Agreed. If not explicitly asked, all firewall configuration should be done in the default zone independently of what zone is set as the default on a server (public, dmz etc) during the exam.
I’d only change the default zone to something else if there is a task to do so.
Thanks for the clarification.
An important, albeit missing, component, is how to get the firewalld logs, in RHEL7/CentOS7 to the central rsyslog host.
Greetings mr certdepot & thanks again for being the best rh exam website.
About block/reject, lets say that we’ve been given a domain and not an IP that must be blocked – is there any option to block/reject a specific domain name (to ensure it will be blocked even if it gets a different ip) or just dig @ its ip and block it?
Sorry, I’m not aware of any option for rejecting a specific domain name at the firewall level. Yuo will have to specify its IP address.
Hostnames will be resolved once only, before the rule is submitted to the kernel.
Renewing my RHCE to 7 on Friday and wondered what releases folks seeing in the US? Not too worried, between this site and Jang’s book, topics are well covered (and practiced). Would just be nice to do a last round of practice labs on the (potentially) current exam release. 7.0, 7.1, …?
Thanks Man Great Work
Thanks.
Hi Certdepot,
regarding the need to enable the ip forwarding that requires masquerading in my lab (using rhel7.0) it’s seem already enable by default when I’m running the command it’s display
Warning: ALREADY_ENABLED
maybe in the exam we must check it first before configuring port forwarding. Nice info for me considering already failed 2 times on my exam 🙁
This point requires some verifications: enabling ip forwarding may be needed depending on versions of Firewalld or RHEL, or even of level of patches.
It seems to be a good idea to check as you propose.
Good luck for your next attempt.
hi Certdepot
so, masquerading we need to enable it in the external zone or in the zone we are currently working (default)
You need to enable masquerading in the external zone.
If for example you want to forward from 192.168.1.12:2020 to [someIP]:443 then there are two options:
1.if you don’t provide someIP (firewalld will forward it to 127.0.0.1) or someIP belongs to the same machine then you do not need enable masquerade.
2.if someIP belongs to some other machine then you must enable masquerade (and of course IP_forwarding via sysctl) in the zone which applies to 192.168.1.12 (zone with source address binding or zone with NIC binding).
I hope it will help to understand masquerading (aka NAT).
That sounds about right. You don’t need masquerading if you don’t do NAT, which is the case if you want to forward to 127.0.0.1 (no NAT involved).
# firewall-cmd –zone=internal –add-service=ssh –permanent
success
# firewall-cmd –zone=internal –add-source=1.2.3.4/32 –permanent
success
# firewall-cmd –zone=public –remove-service=ssh –permanent
success
# firewall-cmd –reload
success
I have tried this example. it does not work.
I have tried with –zone=public …
firewall-cmd –add-source=192.168.1.241/32 –perm
firewall-cmd –reload
It does not block access from other IPs. (ssh is already added to this zone)
Can you post the output of “sudo iptables -nL”?
The netmask 192.168.1.241/32 does seem correct. I suspect the solution is using 192.168.1.241/30, This will limit the subnet to 2 nodes. ../32 may be causing an error. check the log files. For more info look up an IP Calculator.
30 in binary 01 1110
32 in binary 10 0000
How to Test this scenarios ??
# firewall-cmd –permanent –zone=external –add-forward-port=port=22:proto=tcp:toport=3753:toaddr=10.0.0.1
success
# firewall-cmd –reload
success
can you please explain ??
I have set it up on server1 and from server1 try to ssh on port 22.
server1 and server2 both are in same ip range/subnet
Firewalld does not allow port forwarding on localhost, see the bug report here: https://bugs.centos.org/view.php?id=13181
You can still test the scenario by trying to SSH on port 22 from the server2 (not server1). You will then get forwarded from server1:22 to 10.0.0.1:3753. I hope this makes sense to you.
thanks,
I have tested it from other server2 and it works fine.
” Firewalld does not allow port forwarding on localhost, see the bug report here: https://bugs.centos.org/view.php?id=13181 ”
I was able to test port forwarding on local host as well.
But i will recheck it.
Hi CertDepot
I really appreciate your effort here
I want to clarify on masquerading, because a) I’ve found a bunch of sources that seem to make it more complicated than you, and b) I’m not convinced that I’ve been able to create the correct behaviour on my VMs.
From your explanation, and Michael Jang’s, I’ve deduced that if I am asked to configure masquarading on a specific zone, it should be essentially as simple as “–permanent –zone=($zone) –add-masquarade , where $zone is most likely to be dmz or external or whatever zone you don’t want to be able to directly address hosts in the internal networks. Furthermore, with a rich rule you can enable this behaviour to be only when the request is coming from a specified IP or IP range, with anything else following whatever routing logic is configured?
And, after as simple a command as above (plus –reload), I should be able to verify this as working by showing that I can only ping, or ssh, in one direction between hosts in different zones, e.g. my internal server can ping or ssh my external server, but my external server cannot ping my internal server (unless the port-forward is configured specifically). That’s the part where I’ve had issues- I keep feeling this is configured correctly, but then I keep being able to ping in either directions.
I keep running into other sources which specify a direct rule to be added as well, can you confirm this should not be necessary? e.g. https://www.server-world.info/en/note?os=CentOS_7&p=firewalld&f=2
The essential source of my angst is that my lab isn’t behaving the way I think it should, so if you reassure me…it’s time for me to rebuild my lab, I think!
Cheers
Sounds like this is set up correctly. I suspect what you are looking for is a deeper understanding and control of the masquarade (NAT). Take a closer look at the rich rules and try and implement a few.
Hi,
I am studying for the EX300 exam, but I have doubts about Rich Rules and Port Forwarding
The Port Forwarding I understood
to redirect ssh to port 6000
$ firewall-cmd –add-forward-port=port=6000:proto=tcp:toport=22:toaddr=192.168.122.197
# ssh -p 6000 192.168.122.197 – it’s ok
Now to do the same using the rich rules I’m not getting
$ firewall-cmd –add-rich-rule ‘rule family=ipv4 source address=192.168.122.197 forward-port port=80 protocol=tcp to-port=8080’
$ elinks http://192.168.122.197:8080
The “connection refused” error occurs
# firewall-cmd –list-all
public (default, active)
interfaces: eth0 eth1 team0
sources:
services: dhcpv6-client http https ssh
ports: 3260/tcp
masquerade: yes
forward-ports:
icmp-blocks:
rich rules:
rule family=”ipv4″ source address=”192.168.122.197″ forward-port port=”80″ protocol=”tcp” to-port=”8080″
What am I doing wrong?
Thank you
In the second example you seem to use IP 192.168.122.197 as the source address, however, in the first example the same IP address is used as the destination address.
Hi,
I am unable to understand how add-sources attributes works. My Firewalld version is 0.4.3.2. Public is my default zone and zone red have source 192.168.0.107/24. By the below configuration if any one comes from (192.168.0.107) the request would succeed because the source zone (red) is applied first, and it allows ssh access. If someone attempts to ssh from somewhere else, say 192.168.0.112, there wouldn’t be a source zone, because no zones match that source. Therefore, the request would pass directly to the interface zone (public), which does not explicitly handle ssh. Since public’s target is default, the request passes to the firewalld default action, which is to reject it.
Now the problem is 192.168.0.112 ip can also access the server.So what is the benefit of add-source in firewalld.
[root@sanserver services]# firewall-cmd –version
0.4.3.2
———————————————————
[root@sanserver services]# firewall-cmd –list-all –zone=public ; firewall-cmd –list-all –zone=red;
public (active)
target: default
icmp-block-inversion: no
interfaces: ens33
sources:
services: dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
sourceports:
icmp-blocks:
rich rules:
red (active)
target: default
icmp-block-inversion: no
interfaces:
sources: 192.168.0.107/24
services: dns smtp ssh
ports: 2223/tcp
protocols:
masquerade: no
forward-ports:
sourceports:
icmp-blocks:
rich rules:
——————————————————
[root@node11 ~]# ifconfig
ens33: flags=4163 mtu 1500
inet 192.168.0.112 netmask 255.255.255.0 broadcast 192.168.0.255
[root@node11 ~]# ssh 192.168.0.110
root@192.168.0.110‘s password:
Last login: Sun Nov 11 09:18:25 2018 from 192.168.0.112
[root@sanserver ~]#
The Ip address 192.168.0.112 is within the range of 192.168.0.107/24, and hence will be accepted through your firewall. There may be other issues with the firewall I didn’t look too closely at it.
To calculate a proper net mask look up IP calculator.
I got these results from a random IP calculator.
Address: 192.168.0.107
Netmask: 255.255.255.0 = 24
Wildcard: 0.0.0.255
Network: 192.168.0.0/24 (Class C)
Broadcast: 192.168.0.255
HostMin: 192.168.0.1
HostMax: 192.168.0.254
Hosts/Net: 254
Use 192.168.0.107/32 to restrict access to a specific IP rather than the whole subnet.
Hi Lisenet,
Can you please elaborate. I can block the specific ip/24 by using rich rule (source not address) but not with sources attribute.