My Introduction to firewallD

WARNING:

1. When I say My Introduction, I do not mean I am trying to introduce you to firewallD. I really mean this is the first time I had to properly deal with it. I wish this story would involve robots, but it is not that exciting

2. You should not follow this blindly as a guide. I screwed it up and documented it here. Read it first and see what I did wrong and why.

So I am building an apache webserver on a Linux box (Red Hat Enterprise Server 7.2 if you are curious, but there is nothing stopping the gist of my story working on any Linux distro using systemd and, more specifically, firewallD) and want to limit the number of hosts that can access it to one, which happens to have 192.168.79.13 as its IP.

In the golden days...

If we were to use dear ol' pedestrian iptables, one way to create the rules would be

iptables -I INPUT -s '192.168.79.13/32' -m state --state NEW \
   -m tcp -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -s '192.168.79.13/32' -m state --state NEW \
   -m tcp -p tcp --dport 443 -j ACCEPT

and then check if it has been loaded using

iptables -L -n

At this point we might have decided we really should have also told it to apply the rule to only a specific interface or IP (we might be listening to many IPs on the same interface). So we would adjust it as needed until we are satisfied. And, once satisfied it works, save it using

service iptables save

Modern Times

So far so good. But in Red Hat 7 and CentOS 7 as a result, iptables save is no longer an available command. firewallD should be used instead, which is amusing since it is but a front end to iptables. I guess the point is that if iptables is replaced you would still be able to use firewallD to control whatever comes next; in other words, it is an abstraction layer.

But, I digress. Bottom line is we need to figure out how to use firewallD. First thing is that we will be using firewall-cmd to talk to it. Next is that it allows to create separate firewall zones (same idea as the Windows firewall zones for the Microsoft crowd amongst you) which define the interface and possibly IPs it is associated with and which services and rules are supposed to do what there. And, yes, that last sentence was a mouthful, so we shall begin by seeing which zone we are using.

[user@webtest httpd]$ sudo firewall-cmd --get-default-zone
public
[user@webtest httpd]$

I guess that makes sense since this is a pretty much out-of-the-box install; we are still customizing it. But, which zones are in use?

[user@webtest httpd]$ sudo firewall-cmd --get-active-zones
public
  interfaces: eth0
[user@webtest httpd]$

So, the only active zone is the default one, which is being applied to eth0. What can you tell me about the public zone?

[user@webtest httpd]$ sudo firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

[user@webtest httpd]$

I knew about ssh service (sshd) -- that is how I am connected to it -- but I did not realize it actually has a dhcpv6 client. How about ports in use?

[user@webtest httpd]$ sudo firewall-cmd --zone=public --list-ports
[user@webtest httpd]$

Hmmm, nothing? But sshd uses port 22 by default (which is how it is set right now); shouldn't it show up? Well, like Windows' firewall you can specify a service or just a port. If you do the former, its port is not listed. I wonder if it is just satisfied the ssh service is on and relies on it to know which port it is using; this sounds like something worthwhile to test later. Talking about services, which ones firewallD knows of, be them running or not?

[user@webtest httpd]$ sudo firewall-cmd --get-services
RH-Satellite-6 amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client 
dns freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability http 
https imaps ipp ipp-client ipsec iscsi-target 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 rsyncd samba 
samba-client smtp ssh telnet tftp tftp-client transmission-client vdsm 
vnc-server wbem-https
[user@webtest httpd]$

It even knows about telnet! Not that it is even installed here, which means firewallD has some kind of configuration file somewhere listing all the services it should be aware of. Which means you can add/subtract services to this list... or it ends up overwritten during an upgrade. One of the two, right?

So we created the firewall zone. How does it look like? It is actually a xml file; here's the one for the public zone as it stands right now in this conversation:

[user@webtest httpd]$ sudo cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other 
computers on networks to not harm your computer. Only selected incoming 
connections are accepted.</description>
  <service name="dhcpv6-client"/>
  <service name="ssh"/>
</zone>
[user@webtest httpd]$

I think we have an idea of the beast.

Houston, we have a problem

So, let's say we want to allow access to our webserver on port 80. We can do something like

firewall-cmd --zone=public --add-port=80/tcp --permanent

or

firewall-cmd --zone=public --add-service=http --permanent

right? Er, not quite. Let me show what I mean: after we run one of those commands (I picked the service one) we should always check if the zone was updated.

[user@webtest httpd]$ sudo firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

[user@webtest httpd]$

But yet, it is in the file!

[user@webtest httpd]$ sudo cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other 
computers on networks to not harm your computer. Only selected incoming 
connections are accepted.</description>
  <service name="dhcpv6-client"/>
  <service name="ssh"/>
  <service name="http"/>
</zone>
[user@webtest httpd]$

What is going on? Short version: user error. Long version: --permanent means save to file only. It does not affect the running version. If you want to turn it on, you need to restart firewalld.

[user@webtest httpd]$ sudo systemctl restart firewalld
[user@webtest httpd]$

Another alternative is not to use --permanent, as in

firewall-cmd --zone=public --add-service=http

That will commit the change immediately. If you reboot it is lost, so it is a good way to test it. And then once you are ready to commit, you can then do

firewall-cmd --runtime-to-permanent

which as the name implies saves the running firewall to the appropriate zone files. In any case, here is the outcome:

[user@webtest httpd]$ sudo firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eth0
  sources:
  services: dhcpv6-client httpd ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

[user@webtest httpd]$

If you want to remove that very rule, you can do it by

firewall-cmd --zone=public --remove-service=httpd

Back to the iptables example

Do you remember it? No? Let me put it here

iptables -I INPUT -s '192.168.79.13/32' -m state --state NEW \
   -m tcp -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -s '192.168.79.13/32' -m state --state NEW \
   -m tcp -p tcp --dport 443 -j ACCEPT

The key here is not we are specifying the ports, but that we want to specify the IP traffic is coming from. In the firewalld universe that requires a rich rule. Here is what I am using:

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
    source address="192.168.79.13/32" service name="http" accept"
firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
    source address="192.168.79.13/32" service name="https" accept"

it should behave the very same way as the iptables entries. But, let's see how it looks like in runtime

[user@webtest httpd]$ sudo firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" source address="192.168.79.13/32" service 
name="https" accept
        rule family="ipv4" source address="192.168.79.13/32" service 
name="http" accept
[user@webtest httpd]$

And, after we are satisfied and committed it, in the zone file

[user@webtest httpd]$ sudo cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other 
computers on networks to not harm your computer. Only selected incoming 
connections are accepted.</description>
  <service name="dhcpv6-client"/>
  <service name="ssh"/>
  <rule family="ipv4">
    <source address="192.168.79.13/32"/>
    <service name="https"/>
    <accept/>
  </rule>
  <rule family="ipv4">
    <source address="192.168.79.13/32"/>
    <service name="http"/>
    <accept/>
  </rule>
</zone>
[user@webtest httpd]$

References

• firewall-cmd man page
  
• 4.5. Using Firewalls
  
• FirewallD Fedora docs
  
• FirewallD rich language Fedora docs
  
• Linux Firewall (firewalld, firewall-cmd, firewall-config)
  
• Firewalld configuration and usage