Now so far, we've been working just with our public zone.
The public zone was the default zone and had the interfaces added to it,
but we can also make other zones active by adding
source addresses through to them.
If we go through and remove HTTP from our public zone,
we, of course, then won't be able to connect to it from our remote Ubuntu system.
But if we add then the service to another zone,
such as the internal zone, we still won't be able to access it.
The internal zone won't be active.
If we go through and take a look, though,
we'll be able to see that the service is enabled in our internal zone.
If we add a source to that internal zone,
so here we're adding in the complete 192.168.33 network,
and we're adding it through to our internal zone,
that's going to make the zone active,
but it's only going to be accessible to those services if you are
accessing from the source network 192.168.33.0.
Now these are the networks that I'm working with,
your own systems may be different.
Make sure you're adding in the network that your systems are located on.
We're then going to be able from my remote system,
which is 192.168.33.13, I'm going to be able to access the IP address 11,
which is my Alma Linux system.
So let's dive out to our command line for a little bit of practice,
and we're going to look at modifying our rules so we can take a look
at the different zones and take a look at adding‑in rules to a
different zone based on a source address.
And look,
we're back for that golden opportunity of learning again with hands‑on practice.
So let's go through now, having added in our HTTP rule,
where we're going to remove it.
If I go through now and use the remove‑service=http,
that's removed it from my runtime.
We can flush it through to our persistent connection.
Now, of course,
we've lost then connection from our Ubuntu system to our web server because
the connection before was related to the inbound connection coming in on one
of the interfaces associated with our public zone.
But we need to look at our zones in more detail now and also
understand the difference between our active zones and
non‑active zones and how zones become active.
So if I go through and using the firewall‑cmd command,
we can easily go through and run ‑‑get this time and ‑active zones.
And the only active zone that we have is the public zone,
and it's active because it has the two interfaces associated with it.
When we look at the default zone,
we haven't needed to specify the zone name because the
default zone we've been working with is public.
If we look at, let's say, our internal zone,
so we can explicitly mention the zone that we want with ‑‑zone and list all,
we can see that we've got a lot of services associated with this.
But this zone is inactive,
it is not associated with any source address or any interface,
and it's this that we want to investigate.
We're going to now say that the web server should only be accessible to
devices that are located on the 192.168.33 network,
irrespective of the interface that it's coming in on.
So we can start looking at source IP addresses and
setting up our rules based on that.
The first thing, though,
we must do is tidy up this excess of services that we have.
So I'm going to go through and use a firewall‑cmd ‑‑zone=internal,
and we can go through then and remove our service.
And we can begin by the cockpit service, so let's just move this
to the top of the screen so it's easier to see.
We can then start going through our other services that
were listed in the internal zone, so multicast DNS.
We've also then got the DHCP version 6 client.
Now you can get the idea where more services were enabled in the internal zone,
but it still doesn't match what we need.
The last service we want to do is our Samba service,
but also, remember we're saying that we want access to our web server,
so we can then go through and put our add‑service=http.
And just think, all that we've done is modify the service list.
If I go through and search Ctrl+R for get,
okay, that gave me get‑default‑zones,
but I can easily change that to get‑active‑zones.
Of course,
it hasn't then associated a source address or an
interface with the internal zone, so we can then go through and add a source.
This could be a single IP address or a range of addresses.
I'm going to add in then the subnet 192.168.33, which matches my network.
You obviously add in your own network address.
Now when we go through and take a look at the active zones now,
we can see then that we have both the internal,
based on a source, and then our original public zone,
based on the interfaces.
Now because my Ubuntu system is on that network,
were able then to still carry on accessing our website.
We can check the IP address of my Ubuntu system using the ip command,
and we can see then the 192.168.33.13 address,
so we're on the correct source network.
Now remember,
we have made runtime configurations, and it's great making the runtime
configurations because if we then have any errors,
we've not stored that configuration.
But once we're happy then that it's working,
we can go through and flush the configuration through to our files,
so ‑‑runtime‑to‑permanent, then persist that connection.
So next time our firewall daemon starts up, we're going to load the rules that are tried and tested.