After taking a closer look on how to achieve better DNS settings in terms of privacy, this post elaborates necessary steps for a secure configuration of IPFire's firewall engine.

Depending on how volatile and predictable your network is, the following steps might cause interruptions or break some clients altogether - if they are using hard-coded DNS resolvers, for example -, so it might be a good idea to apply them within a maintenance window. Make sure you can access the wiki at any time in order to know what to do if something was misconfigured by accident.

Change the default behaviour to drop all packets

By default, IPFire permits all outgoing connections initiated by internal networks or the system itself. While this is certainly not optimal in terms of security, it is necessary for some use cases such as fixed changeover dates, and makes using IPFire less troublesome for beginners and drop-in replacement scenarios, as its firewall engine behaves like an ordinary ISP router.

To make things as secure as possible, however, it is necessary to drop any connection by default. In order to do so, change "forward firewall" and "outgoing firewall" policies to "blocked" on the firewall options CGI. Afterwards, a reboot is required to apply these settings.

After rebooting, nothing will work.

Allow essential connections for IPFire itself

Some networks services must be reachable for any IPFire machine, which is why the following outgoing firewall rules are needed as a second step:

• DNS traffic to configured DNS servers
  Unless DNS over TLS is enabled, this includes connections to port 53 to the group of DNS resolvers configured. (We will come to firewall groups in a moment.) Apart from UDP, TCP is needed as well for support receiving larger responses that do not fit into a single UDP packet. With DNS over TLS, the destination port becomes 853 (TCP only).
• NTP traffic to configured NTP servers
  Validating DNSSEC, establishing TLS sessions and using similar cryptography systems requires clock synchronisation, which is the goal of the Network Time Protocol (NTP). Unless a custom NTP server has been configured in IPFire - usually required for enterprise environments -, this requires connections to members of the public internet pool of NTP servers to port 123 (UDP). Since they are distributed across the world, restricting access to certain countries does not make sense and creates a considerable amount of noise in the firewall logs.
• ICMP traffic for flow control and debugging/administrative purposes
  Although it is possible to run an IPv4 machine without permitting any ICMP traffic in theory¹, some ICMP messages types are almost indispensable, especially when it comes to flow control, signaling fragmentation needs or handling broken connections. Thanks to connection tracking, IPFire will permit those ICMP messages by default if they belong to a previously established connection.
  However, since IPFire measures the latency to its gateway, manually permitting outgoing ICMP type 8 messages is required. Depending on your uplink setup, this can or cannot be limited to certain IP networks or countries.
• HTTPS traffic for fetching updates
  To search for and install updates, accessing port 443 (TCP) of the IPFire mirror servers is required. Depending on your needs and threat level, you might want to limit this to their IP addresses or countries. Both will likely change over time, which we will discuss below for forwarding firewall rules.
• WHOIS traffic for administrative purposes
  IPFire's web interface provides additional information to certain IP addresses at various places, consisting of their Pointer Record, the country assigned to it, and the WHOIS result from the corresponding RIR. The latter is fetched by querying public WHOIS on port 43 (TCP), which is why such traffic needs to be allowed as well, but can safely be limited to your administration time spans or even to certain occasions.

Taking care for all of these services usually requires about five firewall rules, and since they often depend on the network environment, we unfortunately cannot ship a default ruleset suitable for all (or even the majority of the) IPFire users.

Keep in mind additional firewall rules are required for establishing IPsec or OpenVPN connections and using dynamic DNS services or downloading IPS rules, if you have not allowed HTTPS traffic to the respective countries.

Best Practices for creating and maintaining firewall rules

Since further firewall rules depend on your network, we can only provide you with some common Best Practices for creating and maintaining them - by following the firewall documentation, it should not be too difficult to set up the appropriate rules -:

• Use groups
  As soon as you need the same services, IP addresses, or networks twice, set up a firewall group for them. This pays off quickly since they can be reused, make changes more simple and less error-prone.
• Provide meaningful comments
  Both firewall rules and groups may have comments. Make sure you write down something meaningful there, so the purpose of that rule or group can be understood quickly and inconsistent configuration stands out. If a firewall rule is only needed temporarily, add some notes when it was set up, who requested it and when it is due for removal. Using patterns such as TEMP makes searching for such rules easier.
• Restrict the rules - but do not overdo it
  A firewall rule should be as precise as possible, allowing the most necessary network traffic only. If source and destination can be restricted, restrict them. If connections are legitimate only within certain time frames, adjust the rule accordingly. For administrative services such as SSH access, the number of required concurrent connections might be deterministic - enable rate limiting in the firewall rules for those cases.
  At some point, however, it makes sense not to restrict things too much so your firewall ruleset does not go beyond the acceptable amount. Combining groups or using entire networks instead of single IP addresses might help to find a trade-off between a secure (but unmanageable) firewall ruleset and a comprehensible but too permissive one.
• Regularly review your firewall configuration
  IPFire should not be set up and then be forgotten about. Any network changes sooner or later, and so does the firewall ruleset appropriate for it.
  From time to time, it should be reviewed whether rules are still necessary, need to be changed or made more precise, or can be grouped in a simpler way. Take such reviews serious, and undergo them on a regular basis (quarterly might a good interval for most home users, but your mileage might vary).
  Remember: The firewall configuration is the most powerful part of your IPFire machine, but does not spoil anything if neglected.

Take advantage of the web proxy

Based on Squid, IPFire comes with an easily configurable, albeit powerful and secure web proxy. Contrary to popular opinion, the author considers web proxies to be an important security mechanism which is not legacy at all.

The more traffic one can handle through proxies, the better, as they make a direct TCP connection between client and server redundant while introducing additional possibilities for authenticating clients and limiting access. Unfortunately, support for web proxies is diminishing if implemented at all in modern devices such as multimedia equipment or IoT.

As mentioned in the information security post, the amount of connected devices actually needed is pretty low. At some point, one might be able to limit internet access to those devices supporting web proxies, introducing a "use proxy or die" policy (as referred to by the author).

Since off-the-shelf malware usually does not come with proxy support - a surprisingly high amount of more sophisticated threats seem to lack it as well -, enforcing proxies for internet access represents a considerable gain in terms of security, particularly in combination with proxy authentication.

Configure your clients to retrieve NTP information locally

For distributing accurate time information, IPFire can be configured to serve as a NTP source for local networks. If enabled and used by your clients, there is no reason for permitting direct NTP traffic to the internet, eventually closing the last loophole.

Ultimately, all of your clients retrieve DNS and NTP information from the IPFire machine and access web-based resources through its web proxy, if permitted. Such a network is hard to infiltrate, but also hard to set up - depending on your users, it might be a good idea to start with a relaxed firewall ruleset, restricting it step by step.

In the next post, we will take a stroll into operations security.