And, yes, look at this, our first demonstration,
and with every demonstration, remember, it is a practical test for yourself.
We can demonstrate it, but you're going to learn when you follow through.
So we're going to begin our firewall configuration by taking a look
at where our configuration files are and by examining some of the
basic usage of our firewall‑cmd command.
Come on,
let's find that command line. And here we are, look at
this, the glorious AlmaLinux command line.
So we're working on our Red Hat 8 clone.
Now this could be AlmaLinux, it could be Rocky Linux,
it could be CentOS Linux. You can see we've already elevated our
privilege. We're going to be working with the root account for a lot of
what we're doing, so we've gained a root shell.
Our main command is firewall‑cmd, and we can go through and check the
state of our firewall, and look, it's not running.
We could also try and list our rules if we use list‑all. Again, we're
getting this FirewallD is not running. Now it should be running by default,
but remember, we cloned this virtual machine. We're using Vagrant, Vagrant
downloads boxes, we never created this, so we cloned it, and it just
highlights that we should always check the current configuration rather than
just making assumptions.
We need to now enable our firewall, and we can go ahead and do that with a
straightforward systemctl command. Of course, if I go through and take a
look at the status, and the service is firewalld. Now we get some good
information coming back from this.
We can see, yes,
it's disabled and not running, but if we look at the vendor preset,
it would normally come enabled. But as I say, we don't
need to argue about the situation,
we can see that it's not currently running. We want it to be
running, so let's just get our firewall up and running and protect
our system. So we can go ahead then and use the systemctl enable,
so that then enables firewalld to auto‑start, ‑‑now is just making
sure that it starts now.
In this way, I can run it with the one command rather than two separate commands.
We can always go back now and check the status, and we can see the
status is up and running and enabled, and this is good.
But take a look,
we are getting a warning about zone drifting, so we'll fix this later.
But as well as being able to check using systemctl,
we can go back to our firewall‑cmd command and ‑‑state. Now we see a happier
figure of running. And if I go back now and run ‑‑list‑all, we're going to start
listing our firewall rules that we have in place. Now there's more information
that we're going to learn about as we go through, but we've got a zone name,
public. This is just our default zone that we're working with. It's active, and
that means it has then either IP addresses associated with it or interfaces
associated with it.
And we can see we've got both of our interfaces,
enp0s8 and enp0s3, associated with it.
Take a look at the services, though. These are inbound. They are
allowed to connect into the cockpit service,
the web management interface,
the DHCP version 6 client, and SSH. Well, probably at this
stage we only need SSH allowed inbound.
So, again, never accept that the default rules are going to be secure enough.
We're also looking at the runtime configuration.
The runtime configuration is showing what is loaded in memory,
but we also have our permanent configuration.
These are then settings that persist. Now when we look at them, because we
haven't made any changes to the runtime configuration,
the runtime configuration represents our permanent
configuration that is loaded in memory. But, again,
never assume your permanent and runtime configurations are going to be the same.
We make changes to our runtime configuration, and we need to save
them through to the permanent configuration.
That permanent or persisted configuration begins by templates that are
created as XML files in usr, lib, and firewalld, so these directories will
contain the different XML files that represents our services and our zones.
More on this as we go through later.
But any changes to the default will then be in our customization
directory, which is underneath the etc and firewalld.
So when I look underneath here, I can see a similar set of directories.
When I go through and say dig into the zones directory,
we know we must have changed the zone to public, because we've added our
interfaces to this. So we can see then that we've got the public XML, but
only the public zone has been changed, none of our other zones, so the
defaults for the other zones are still in place, untouched, underneath the
/usr/lib/firewalld. But remember,
we never want to just accept what's been delivered to us.
We need to tune this so it works for our needs,
not just the out‑of‑the‑box needs, and that's what we're
going to be taking a look at is configuring our firewall, as we run through this section.