In this section, we will continue our work on the Apache2 Web Server we started in the last section, so as to make it accessible for other computers in our subnetwork. Also, we will give you a brief introduction to Linux firewalls in CentOS 7.
As briefly mentioned in the first section of this chapter, a network connection is always made through a combination of an IP address and the port, which together is called a socket address. Now, every Linux network service, such as a mail or web server, must be connected to an IP address and the port so that we can establish a connection to it at all from a different computer in the network or from the same local one:
When we are talking about network communication, we often refer to this as "a service is listening to IP address a port b". For example, our web server is listening on port 80 of the IP address 10.0.2.15, the mail service is listening on port 24, the web service is listening on port 80 of the IP address 10.0.2.15, and the FTP service is listening on port 21 of IP address 10.0.2.15.
But maybe you are wondering which IP address does a service use for communication if we have configured multiple network interfaces on our system, all with a different IP address? The answer to this is simple. Most networking services on any Linux system listen to all available network interfaces for network connections by default after installation. For almost all standard services, you can also change this to listen only to a specific network interface, or network connection, or subnetwork, or even ranges of networks:
Some even only listen to a localhost by default after installation, as these often are very critical services where system administrators need to change the listening address intentionally as a measurement of responsibility to make them aware of the risks.
So let's say you have a Linux server that is running several networking services and each is listening on a different port. A firewall is a tool for managing connections to your computer. In Linux, the standard firewall is called firewalld. This firewall can protect your system against unwanted network connections from outside your system, for example, if some intruder is trying to break into your system and steal data. It does so by managing your incoming network ports for communication. By default, firewalld closes all incoming network ports except the port 22 for SSH connections. Otherwise, you would not be able to remotely connect to your machine:
So if you want to have some kind of network communication, you have to explicitly tell the firewall to do so. You can open or close individual ports or ranges of ports, and so on. This helps a lot in managing security on your server, but it's important to note that, by default, firewalld does not restrict any local network communication within a system, so the localhost network connection is always working and is not blocked by the firewall. Also, it's very important to know that firewalld, by default, is an incoming firewall only, which means it does not block any outgoing connections at all:
In order to fix this problem, we need to know how we can troubleshoot a system service. So, first go back to our master server where this web server is running. To find out if something is wrong with your service, there are always at least three places where to look. The first thing we should do is to check the systemctl status output, as we have done before. As you can see, the service is currently running and the final current lines of output of the service also look OK:
Sometimes, here in this output, you will find error messages or warnings if a service is not functioning normally.
Sometimes, the last two lines of the log output for a service are not enough, so the second place to look for if you need to troubleshoot your service, is the journalctl command. If you use the journalctl command with the -u flag, you can filter log messages for your service of choice; in our example, the httpd service:
Here, in our example, no suspicious log output can be found in journald, which is the service that writes all the log messages of all the services running into a centralized database. The journal log for the Apache HTTP Server looks normal.
So, the third place where we can have a look for troubleshooting services is the rsyslog log file, which is located at /var/log/messages. Open this file and go to the end of it, pressing capital G:
Here also, nothing really suspicious has been logged to the rsyslog file.
Some services, such as our Apache HTTP Web Server, provide their own log files for troubleshooting or getting info about the service.
Please note that there is no standardized directory where a service outputs its own log files, but some services write their log files into a subdirectory under the /var/log file directory. Here, you can find two log files. One is the access_log, which logs user access to our web server (for example, the files on the server that have been downloaded). The other is the error_log file, which logs all kinds of errors that this service may encounter. So, first have a look at the access_log file:
This looks very normal. Now, also open the error_log file. Jump to the end using capital G:
Here, no special error messages can be found.
The solution to the problem of why nobody outside of our server can access the Apache HTTP Web Server instead of CentOS 7 is that a very restrictive firewall is active that blocks almost any incoming network connection.
You can view the currently allowed firewall rules by typing firewall-cmd --list-all. On CentOS 7, the standard firewall is called firewalld:
As you can see here, only the SSH service is allowed by default to communicate with our server. Firewalld is mainly protecting all incoming network connections. Outgoing connections from our server to other servers are not restricted or limited; that's the reason why we can access our web server from the localhost, but not from any other host.
To fix this problem, we can open the HTTP service, also known as opening port 80, in our firewall. So that we can do that permanently, use the following two commands: firewall-cmd --permanent --add-service, and then http. So that the changes can be applied, next reload the firewall rules. Finally, let's see if the HTTP service is now enabled in the firewall:
As you can see, it works.
Finally, let's test if we can make remote connections to our Apache Web Server from another server. Go to client1 and repeat the wget command:
Yes, it works! You are now able to access your web server in your network.
Until now, we haven't talked about how to remove a service from the firewall. To remove the HTTP service or port from the firewall configuration, use the following firewall command syntax, firewall-cmd --permanent --remove-service.
Then the service of choice; in our example, the http service. Similar to adding a service, you also have to reload the firewall here. Let's recheck our firewall settings:
As you can see, HTTP port has been closed.
Finally, a very useful feature of the firewalld service is to open individual port numbers without providing a service name. This is very useful if you need to open a port where no service file, such as the HTTP, is available. For example, to open port 12345, use the TCP protocol. Let's show the new firewall configuration after we have reloaded the firewall:
As you can see, the port 12345 is now open using the TCP protocol. Instead of TCP, you can also use the UDP protocol. Now, to close the port 12345 using the TCP protocol, use the following command. Here, also reload the firewall configuration. Let's perform a recheck:
Let's summarize what we have learned so far:
- If it is a service-related problem, first have a look at the systemctl output for the service.
- If the problem persists, next look at the journalctl output for the service.
- If it is a general system problem, or you cannot fix your service problems with the systemctl and journalctl outputs, next have a look at the /var/log-messages rsyslog output file.
- Also, some services provide special log file locations outside of journald or the rsyslog file, so also have a look there. But you must be aware that not every service or program has such a special log file directory or output.
- Finally, we gave you a brief introduction to the firewalld service using predefined service files, such as the HTTP, and also we showed you how to work with individual ports that are not defined by service files. In the next chapter, we will show you advanced file permissions.