Firewall¶

Introduction to the Firewall System¶

Zentyal uses the Linux kernel subsystem called Netfilter [2] in the firewall module. Functionality includes filtering, package marking and connection redirection capabilities.

Firewall configuration with Zentyal¶

Zentyal’s security model is based on delivering the maximum possible security with the default configuration, trying at the same time to minimise the effort when adding a new service.

When Zentyal is configured as a firewall, it is 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, therefore the firewall can establish stricter policies for connections initiated outside your network.

External interface

The default policy for external interfaces is to deny any new connections. 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 these connections. These rules can be modified later by the system administrator. An exception to this are the connections to the LDAP server, which add a rule but it is configured to deny the connection for security reasons. The default configuration for connections to hosts outside the network and connections from the server itself is allow all.

Packet filtering

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

Five different sections are available for configuration depending on the work flow of the traffic you 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).

You have to take into account that the last two types of rules could compromise in security of Zentyal and the network, so you must be very careful when 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 policy. The definition of these rules uses the high-level concepts as defined in Network services section to specify which protocols and ports to apply rules and in Network objects section to specify to which IP addresses (source or destination) are included in rule definitions.

List of package filtering rules from internal networks to Zentyal

Normally, each rule has a Source and a Destination which can be Any, an IP address or an Object in case more than one IP address or MAC address needs to be specified. In some sections the Source or Destination are omitted because their values are already known, for example Zentyal will always be the Destination in the Traffic from internal networks to Zentyal section 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 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 the Decision to take on new connection. Zentyal allows this parameter to use three different decisions types.

• Accept the connection.
• Deny the connection, ignoring incoming packets and telling the source that the connection can not be established.
• Register the connection event and continue evaluating the rest of the rules. This way, using Maintenance ‣ Logs -> Log query -> Firewall you can check which connections were attempted.

The rules are inserted into a table where they are evaluated from the beginning to the end. Once a rule accepts a connection, the rest are ignored. A generic rule at the beginning of the chain can have the effect of ignoring a more specific one that is located later in the list, this is why ordering of 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 policies.

Creating a new rule in the firewall

For example, if you want to register the connections to a service, first you use the rule that will register the connection and then the rule that will accept it. If these two rules are in inverse order, nothing will be registered, because the first rule has already accepts the connection. Following the same logic if you want to restrict the access to the Internet, first restrict the desired sites or clients and then allow access to the rest, swapping the location of the rules will give complete access to every client.

By default, the decision is always to deny connections and you have to add explicit rules to allow them. There are a series of rules which are automatically added during installation to define an initial version of firewall policies: allow all the outgoing connections to external networks to the Internet, from the Zentyal server (in Traffic from Zentyal to external networks) and also allow all the connections from internal to external networks (in 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 implicit, but it simplifies the firewall management by allowing the service. Only the parameter Decision needs to be changed and you do not need to create a new rule. Note that these rules are added during the installation process of a module only, and they are not automatically modified during future changes.

Finally, there is an additional field Description used to add a descriptive comment about the rule policy within the global policy of the firewall.

Port redirection with Zentyal¶

Destination port redirection can be configured using Firewall ‣ Port redirection.

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

Additionally you can also Log the connections that go through this redirection and Replace source address. If you check this last option the internal host will see Zentyal as the original source of the connection, which is useful if Zentyal is not the gateway for the internal machine.

Port redirection