firewalld is the default front-end controller for iptables on CentOS. The firewalld front-end has two main advantages over raw iptables −
Uses easy-to-configure and implement zones abstracting chains and rules.
Rulesets are dynamic, meaning stateful connections are uninterrupted when the settings are changed and/or modified.
Remember, firewalld is the wrapper for iptables - not a replacement. While custom iptables commands can be used with firewalld, it is recommended to use firewalld as to not break the firewall functionality.
First, let's make sure firewalld is both started and enabled.
[root@CentOS rdc]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2017-01-26 21:42:05 MST; 3h 46min ago Docs: man:firewalld(1) Main PID: 712 (firewalld) Memory: 34.7M CGroup: /system.slice/firewalld.service └─712 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
We can see, firewalld is both active (to start on boot) and currently running. If inactive or not started we can use −
systemctl start firewalld && systemctl enable firewalld
Now that we have our firewalld service configured, let's assure it is operational.
[root@CentOS]# firewall-cmd --state running [root@CentOS]#
We can see, the firewalld service is fully functional.
Firewalld works on the concept of zones. A zone is applied to network interfaces through the Network Manager. We will discuss this in configuring networking. But for now, by default, changing the default zone will change any network adapters left in the default state of "Default Zone".
Let's take a quick look at each zone that comes out-of-the-box with firewalld.
|Sr.No.||Zone & Description|
Low trust level. All incoming connections and packetsare dropped and only outgoing connections are possible via statefullness
Incoming connections are replied with an icmp message letting the initiator know the request is prohibited
All networks are restricted. However, selected incoming connections can be explicitly allowed
Configures firewalld for NAT. Internal network remains private but reachable
Only certain incoming connections are allowed. Used for systems in DMZ isolation
By default, trust more computers on the network assuming the system is in a secured work environment
By default, more services are unfiltered. Assuming a system is on a home network where services such as NFS, SAMBA and SSDP will be used
All machines on the network are trusted. Most incoming connections are allowed unfettered. This is not meant for interfaces exposed to the Internet
The most common zones to use are:public, drop, work, and home.
Some scenarios where each common zone would be used are −
public − It is the most common zone used by an administrator. It will let you apply the custom settings and abide by RFC specifications for operations on a LAN.
drop − A good example of when to use drop is at a security conference, on public WiFi, or on an interface connected directly to the Internet. drop assumes all unsolicited requests are malicious including ICMP probes. So any request out of state will not receive a reply. The downside of drop is that it can break the functionality of applications in certain situations requiring strict RFC compliance.
work − You are on a semi-secure corporate LAN. Where all traffic can be assumed moderately safe. This means it is not WiFi and we possibly have IDS, IPS, and physical security or 802.1x in place. We also should be familiar with the people using the LAN.
home − You are on a home LAN. You are personally accountable for every system and the user on the LAN. You know every machine on the LAN and that none have been compromised. Often new services are brought up for media sharing amongst trusted individuals and you don't need to take extra time for the sake of security.
Zones and network interfaces work on a one to many level. One network interface can only have a single zone applied to it at a time. While, a zone can be applied to many interfaces simultaneously.
Let's see what zones are available and what are the currently applied zone.
[root@CentOS]# firewall-cmd --get-zones work drop internal external trusted home dmz public block
[root@CentOS]# firewall-cmd --get-default-zone public [root@CentOS]#
Ready to add some customized rules in firewalld?
First, let's see what our box looks like, to a portscanner from outside.
bash-3.2# nmap -sS -p 1-1024 -T 5 10.211.55.1 Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-27 23:36 MST Nmap scan report for centos.shared (10.211.55.1) Host is up (0.00046s latency). Not shown: 1023 filtered ports PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 3.71 seconds bash-3.2#
Let's allow the incoming requests to port 80.
First, check to see what zone is applied as default.
[root@CentOs]# firewall-cmd --get-default-zone public [root@CentOS]#
Then, set the rule allowing port 80 to the current default zone.
[root@CentOS]# firewall-cmd --zone=public --add-port = 80/tcp success [root@CentOS]#
Now, let's check our box after allowing port 80 connections.
bash-3.2# nmap -sS -p 1-1024 -T 5 10.211.55.1 Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-27 23:42 MST Nmap scan report for centos.shared (10.211.55.1) Host is up (0.00053s latency). Not shown: 1022 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp closed http Nmap done: 1 IP address (1 host up) scanned in 3.67 seconds bash-3.2#
It now allows unsolicited traffic to 80.
Let's put the default zone to drop and see what happens to port scan.
[root@CentOS]# firewall-cmd --set-default-zone=drop success [root@CentOS]# firewall-cmd --get-default-zone drop [root@CentOs]#
Now let's scan the host with the network interface in a more secure zone.
bash-3.2# nmap -sS -p 1-1024 -T 5 10.211.55.1 Starting Nmap 7.30 ( https://nmap.org ) at 2017-01-27 23:50 MST Nmap scan report for centos.shared (10.211.55.1) Host is up (0.00094s latency). All 1024 scanned ports on centos.shared (10.211.55.1) are filtered Nmap done: 1 IP address (1 host up) scanned in 12.61 seconds bash-3.2#
Now, everything is filtered from outside.
As demonstrated below, the host will not even respond to ICMP ping requests when in drop.
bash-3.2# ping 10.211.55.1 PING 10.211.55.1 (10.211.55.1): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2
Let's set the default zone to public again.
[root@CentOs]# firewall-cmd --set-default-zone=public success [root@CentOS]# firewall-cmd --get-default-zone public [root@CentOS]#
Now let's check our current filtering ruleset in public.
[root@CentOS]# firewall-cmd --zone=public --list-all public (active) target: default icmp-block-inversion: no interfaces: enp0s5 sources: services: dhcpv6-client ssh ports: 80/tcp protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules: [root@CentOS rdc]#
As configured, our port 80 filter rule is only within the context of the running configuration. This means once the system is rebooted or the firewalld service is restarted, our rule will be discarded.
We will be configuring an httpd daemon soon, so let's make our changes persistent −
[root@CentOS]# firewall-cmd --zone=public --add-port=80/tcp --permanent success [root@CentOS]# systemctl restart firewalld [root@CentOS]#
Now our port 80 rule in the public zone is persistent across reboots and service restarts.
Following are the common firewalld commands applied with firewall-cmd.
|firewall-cmd --get-zones||Lists all zones that can be applied to an interface|
|firewall-cmd —status||Returns the currents status of the firewalld service|
|firewall-cmd --get-default-zone||Gets the current default zone|
|firewall-cmd --set-default-zone=<zone>||Sets the default zone into the current context|
|firewall-cmd --get-active-zone||Gets the current zones in context as applied to an interface|
|firewall-cmd --zone=<zone> --list-all||Lists the configuration of supplied zone|
|firewall-cmd --zone=<zone> --addport=<port/transport protocol>||Applies a port rule to the zone filter|
|--permanent||Makes changes to the zone persistent. Flag is used inline with modification commands|
These are the basic concepts of administrating and configuring firewalld.
Configuring host-based firewall services in CentOS can be a complex task in more sophisticated networking scenarios. Advanced usage and configuration of firewalld and iptables in CentOS can take an entire tutorial. However, we have presented the basics that should be enough to complete a majority of daily tasks.