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 -> Interfaces, therefore the firewall can establish stricter policies for connections initiated outside your network.
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. The default configuration for connections to hosts outside the network and connections from the server itself is allow all.
Definition of firewall policies can be made from: Firewall ‣ Packet filtering.
Each one of the sections above is in charge of controlling different traffic flows depending on their source and destination:
- Filtering rules from internal networks to Zentyal (example: allow access to
Zentyal's file server from the local network).
- Filtering rules for internal networks
(example: restrict access to Internet from a set of hosts, forbid the DMZ to access other LAN segments)
- Filtering rules from external networks to Zentyal
(example: allow any host in the Internet to access a webpage served by Zentyal).
- Filtering rules for traffic coming out from Zentyal
(example: server outgoing connections through an internal/external interface).
You have to take into account that allowing Internet connections to Zentyal services could be potentially dangerous, study the security implications before modifying the third set of rules.
Studying the image above, you can determine which section you will need depending on the type of traffic you want to control in the firewall. The arrows only signal the source and destination, naturally, all the traffic must go though Zentyal's firewall in order to be processed. For example, the arrow Internal Networks which goes from LAN 2 to Internet, means that one of the LAN hosts is the source and the host in the Internet is the destination, but the connection will be processed by Zentyal, which is the gateway for that host.
Zentyal provides a simple way to define the rules that will compose 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 the rules and in Network objects section to specify to which IP addresses (source or destination) are included in rule definitions.
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 Filtering rules from internal networks to Zentyal section and always the Source in Filtering rules from traffic coming out from Zentyal
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 top to bottom. Once a (DENY/ACCEPT) rule matches a connection, the decision is taken and filtering stops, so the rules below it are not considered. Logging rules produce the log and continue evaluating rules.
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 the order of rules is important. You can also apply a logical not to the rule evaluation using Inverse match in order to define more advanced policies.
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 accepted 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 Filtering rules for traffic coming out of Zentyal) and also allow all the connections from internal to external networks (in Filtering rule for internal networks). Additionally, each installed module adds a series of rules in sections Filtering rules from internal networks to Zentyal and Filtering rules from external networks to Zentyal, normally allowing traffic from internal networks and denying from the external networks. 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.