Firewall¶

Introduction to the Firewall System¶

Zentyal uses the Linux kernel subsystem called Netfilter [2] for providing its firewall module, it has filtering, package marking and connection redirection capabilities.

Firewall configuration with Zentyal¶

Zentyal’s security model is based on delivering the maximum possible security on the default configuration, trying at the same time to minimize the efforts of adding a new service.

When Zentyal is configured as a firewall, it’s normally installed between the internal network and the router connected to the internet. The network interface which connects the host with the router has to be marked as External in Network -> Network interfaces, this way the firewall can stablish more strict policies for the connections initiated outside our network.

External interface

The default policy for external interfaces is to deny any attempt of establishing a new connection to Zentyal, on the other hand, for internal interfaces, Zentyal denies all the connection attempts, except the ones that are targeted to services defined by the installed modules. The modules add rules to the firewall to allow this connections, anyway, this rules can be modified later by the system administrator. A exception to this norm are the connections to the LDAP server, which add the rule but configured to deny the connection for security reasons. The default configuration for the connections to hosts outside the network and connections from the server itself is allow all.

Packet filtering

Definition of firewall politics can be made from: Firewall ‣ Packet filtering.

It’s possible to define 5 different sections of rules depending on the work flow of the traffic we are addressing:

• Traffic from internal networks to Zentyal (example: allow access to the file server from the local network).
• Traffic between internal networks and from internal networks to the Internet (example: restrict access to Internet or to specific addresses to some internal clients and restrict communication between internal networks)
• Traffic from Zentyal to external networks (example: allow to download files using HTTP from the server itself).
• Traffic from external networks to Zentyal (example: Allow the mail server to receive messages from the internet).
• Traffic from external networks to internal networks (example: allow access to a internal server from the Internet).

We have to take into account that the last two typos of rules could create a compromise in the security of Zentyal and the network, so we must be very careful modifying them.

Schema illustrating the different traffic flows in the firewall

Zentyal provides a simple way to define the rules that will form the firewall’s policy. The definition of this rules uses the high-level concepts defined before: the Network services to specify to which protocols and ports we want to apply the rules and Network objects to specify to which IP addresses (source or destination) we want to apply.

List of package filtering rules from internal networks to Zentyal

Normally, each rule has a Source and a Destination which can be Any, a IP address or a Object in case we want to specify more than one IP address or MAC address. In some sections the Source or Destination are omitted because their value is already known, for example Zentyal will always be the Destination in the section Traffic from internal networks to Zentyal and always the Source in Traffic from Zentyal to external networks

Additionally each rule is always associated with a Service`in order to specify the protocol and the ports (or range of ports). The services with source ports are used for rules related to outgoing traffic of internal services, for example an internal HTTP server, while the services with destination ports are used for rules related to incoming traffic to internal services or from outgoing traffic to external services. Is important to note that there is a set of generic labels that are very useful for the firewall like :guilabel:`Any to select any protocol or port, or Any TCP, Any UDP to select any TCP or UDP protocol respectively.

The more relevant parameter is Decision to take on new connection. Zentyal allows to take three different decisions.

• Accept the connection.
• Deny the connection, ignoring incoming packets and telling the source that the connection cannot be stablish.
• Register the connection event and continue evaluating the rest of the rules. This way, using Logs -> Log query -> Firewall we can check which connections were performed.

The rules are inserted in a table where they are evaluated from the beginning to the end, once a rule accepts a connections, we stop evaluating the rest. A generic rule at the beginning of the chain can have the effect of ignoring a more specific one that is located after in the list, this is why the ordering of the rules is very important. There is the option of applying a logical not to the rule evaluation using Inverse in order to define more advanced politics.

Creating a new rule in the firewall

For example, if we want to register the connections to a service, first we have the rule that will register the connection and then the rule that will accept it. If this two rules are in inverse order, we won’t register anything, because the first rule already accepts the connection. Following the same logic if we want to restrict the access to the Internet, we will first restrict the desired sites or clients and then we will allow access to the rest, swapping the location of the rules will give total access to every client.

By default, the decision is always to deny connections and we have to add explicit rules to allow them. There are a series of rules which are automatically added during installation to define a first version of firewall policies: We allow all the outgoing connections to external networks, Internet, from the Zentyal server (in Traffic from Zentyal to external networks) and we also allow all the connections from internal to external networks (in guilabel:Traffic between internal networks and from internal networks to Internet). Additionally each installed module adds a series of rules in sections Traffic from internal networks to Zentyal and Traffic from external networks to Zentyal, normally allowing traffic from internal networks and denying from the external networks. This is made implicitly, but it simplifies the firewall management, because this way to allow the service we only need to change the parameter Decision and we don’t need to create a new rule. Note that this rules are added only during the installation process of a module, and they are not automatically modified during future changes.

Finally, there is an additional field Description to comment the objective of this rule inside the global policy of the firewall.

Port redirection with Zentyal¶

Destination port redirections can be configured in Firewall ‣ Port redirection.

To configure a redirection we have to stablish the Interface where we are going to receive the traffic that needs translation, the Original source (which can be the Zentyal server, a source IP or an object), the:guilabel:Original source port (which can be Any, a Default port or Port range), The Protocol and the Source (which can be also Any, a IP address or a Object). We will also specify the IP address of the Destination and finally the Port where the destination host will receive the requests, which can be same as the original or not. There is also an optional field of Description to clarify the purpose of the rule.

Port redirection