Firewalld

Set up a Firewall using FirewallD
Introduction
Firewalld is a firewall management solution available for many Linux distributions which acts
as a frontend for the iptables packet filtering system provided by the Linux kernel. In this
guide, we will cover how to set up a firewall for your server and show you the basics of
managing the firewall with the firewall-cmd administrative tool.
Basic Concepts of FirewallD
Let’s get familiar with a few basic concepts that the tool (firewall-cmd) introduces.
Zones:
The firewalld daemon manages groups of rules using entities called "zones".
In order from least trusted to most trusted, the predefined zones within firewalld are:
 drop: The lowest level of trust. All incoming connections are dropped without reply and
only outgoing connections are possible.
 block: Similar to the above, but instead of simply dropping connections, incoming
requests are rejected with an icmp-host-prohibited or icmp6-adm-prohibited message.
 public: Represents public, untrusted networks. You don't trust other computers but
may allow selected incoming connections on a case-by-case basis.
 external: External networks in the event that you are using the firewall as your
gateway. It is configured for NAT masquerading so that your internal network remains
private but reachable.
 internal: The other side of the external zone, used for the internal portion of a gateway.
The computers are fairly trustworthy and some additional services are available.
 dmz: Used for computers located in a DMZ (isolated computers that will not have
access to the rest of your network). Only certain incoming connections are allowed.
 work: Used for work machines. Trust most of the computers in the network. A few
more services might be allowed.
 home: A home environment. It generally implies that you trust most of the other
computers and that a few more services will be accepted.
 trusted: Trust all of the machines in the network. The most open of the available
options and should be used sparingly.
To use the firewall, we can create rules and alter the properties of our zones and then assign
our network interfaces to whichever zones are most appropriate.
SagarG
or

Rule Permanence
In firewalld, rules can be designated as either permanent or immediate. If a rule is added or
modified, by default, the behavior of the currently running firewall is modified. At the next boot,
the old rules will be reverted.
Most firewall-cmd operations can take the --permanent flag to indicate that the non-
ephemeral firewall should be targeted. This will affect the rule set that is reloaded upon boot.
This separation means that you can test rules in your active firewall instance and then reload
if there are problems. You can also use the --permanent flag to build out an entire set of rules
over time that will all be applied at once when the reload command is issued.
Install and Enable Your Firewall to Start at Boot
firewalld is installed by default on some Linux distributions, including many images of
CentOS 7. However, it may be necessary for you to install firewalld yourself:
[root@localhost ~]# yum install firewalld
[root@localhost ~]# systemctl enable firewalld
[root@localhost ~]# systemctl reboot Or reboot Or init 6
We can verify that the service is running and reachable by typing:
Getting Familiar with the Current Firewall Rules
Exploring the Defaults
We can see which zone is currently selected as the default by typing:
Since we haven't given firewalld any commands to deviate from the default zone, and none of
our interfaces are configured to bind to another zone, that zone will also be the only "active"
zone (the zone that is controlling the traffic for our interfaces). We can verify that by typing:
SagarG
or

How do we know what rules are associated with the home zone though? We can print out the
default zone's configuration by typing:
Exploring Alternative Zones
To get a list of the available zones, type:
We can see the specific configuration associated with a zone by including the --
zone= parameter in our --list-all command:
You can output all of the zone definitions by using the --list-all-zones option. You will
probably want to pipe the output into a pager for easier viewing:
[root@localhost ~]# firewall-cmd --list-all-zones | less
SagarG
or

Selecting Zones for your Interfaces
Changing the Zone of an Interface
You can transition an interface between zones during a session by using the --
zone= parameter in combination with the --change-interface= parameter. As with all
commands that modify the firewall.
Note: Whenever you are transitioning an interface to a new zone, be aware that you are
probably modifying the services that will be operational. For instance, here we are
moving to the "public" zone, which has SSH available. This means that our connection
shouldn't drop. Some other zones do not have SSH enabled by default and if your
connection is dropped while using one of these zones, you could find yourself unable to
log back in.
We can verify that this was successful by asking for the active zones again:
Adjusting the Default Zone
If all of your interfaces can best be handled by a single zone, it's probably easier to just select
the best default zone and then use that for your configuration.
You can change the default zone with the --set-default-zone= parameter. This will immediately
change any interface that had fallen back on the default to the new zone:
SagarG
or

Setting Rules for your Applications
The basic way of defining firewall exceptions for the services you wish to make available is
easy. We'll run through the basic idea here.
Adding a Service to your Zones
The easiest method is to add the services or ports you need to the zones you are using. Again,
you can get a list of the available services with the --get-services option:
Note: You can get more details about each of these services by looking at their
associated .xml file within the /usr/lib/firewalld/services directory. For
instance, the SSH service is defined like this:
For instance, if we are running a web server serving conventional HTTP traffic, we can allow
this traffic for interfaces in our "home" zone for this session by typing:
You can leave out the --zone= if you wish to modify the default zone. We can verify the
operation was successful by using the --list-all or --list-services operations:
Once you have tested that everything is working as it should, you will probably want to modify
the permanent firewall rules so that your service will still be available after a reboot. We can
make our "home" zone change permanent by typing:
SagarG
or

You can verify that this was successful by adding the --permanent flag to the --list-
services operation.
What If No Appropriate Service Is Available?
The firewall services that are included with the firewalld installation represent many of the
most common requirements for applications that you may wish to allow access to. However,
there will likely be scenarios where these services do not fit your requirements.
In this situation, you have two options.
Opening a Port for your Zones
The easiest way to add support for your specific application is to open up the ports that it uses
in the appropriate zone(s). This is as easy as specifying the port or port range, and the
associated protocol for the ports you need to open.
For instance, if our application runs on port 5000 and uses TCP, we could add this to the
"public" zone for this session using the --add-port= parameter. Protocols can be
either tcp or udp:
We can verify that this was successful using the --list-ports operation:
It is also possible to specify a sequential range of ports by separating the beginning and ending
port in the range with a dash. For instance, if our application uses UDP ports 5555 to 5565,
we could open these up on "home" by typing:
After testing, we would likely want to add these to the permanent firewall. You can do that by
typing:
SagarG
or

Defining a Service
Opening ports for your zones is easy, but it can be difficult to keep track of what each one is
for. If you ever decommission a service on your server, you may have a hard time
remembering which ports that have been opened are still required. To avoid this situation, it
is possible to define a service.
Services are simply collections of ports with an associated name and description. Using
services is easier to administer than ports, but requires a bit of upfront work. The easiest way
to start is to copy an existing script (found in /usr/lib/firewalld/services) to
the /etc/firewalld/services directory where the firewall looks for non-standard
definitions.
For instance, we could copy the SSH service definition to use for our "example" service
definition like this. The filename minus the .xml suffix will dictate the name of the service within
the firewall services list:
[root@localhost ~]#cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/example.xml
Now, you can adjust the definition found in the file you copied:
[root@localhost ~]# nano /etc/firewalld/services/example.xml
Reload your firewall to get access to your new service:
SagarG
or

You can see that it is now among the list of available services:
Creating Your Own Zones
For Instance,
For Web Server: Publicweb
DNS Server: privatedns
You can verify,
As stated before, these won't be available in the current instance of the firewall yet:
SagarG
or

Now, you can begin assigning the appropriate services and ports to your zones. It's usually a
good idea to adjust the active instance and then transfer those changes to the permanent
configuration after testing. For instance, for the "publicweb" zone, you might want to add the
SSH, HTTP, and HTTPS services:
Likewise, we can add the DNS service to our "privateDNS" zone:
Now, set –permanent flag and reload the firewallD & Network to work efficiently.
[root@localhost ~]# firewall-cmd --set-default-zone=publicweb
SagarG
or

Firewalld

More Related Content

What's hot (20)

Similar to Firewalld (20)

More from Sagar Gor (6)

Recently uploaded (20)

Firewalld