Fedora introduces Network Zones

Fedora is exploring a new security feature in the upcoming Fedora 17 release that is intended to make firewall configuration simpler for the average user. Based on features found in the new, D-Bus-enabled firewall tool, the Network Zones feature will automatically activate different sets of firewall rules based on the network location, and provide sensible defaults for different classes of network — from trusted connections at home to potentially dangerous open WiFi networks in public.

Background

At the heart of Network Zones is the notion that each network has an associated trust level — fully trusted, mostly trusted, mostly untrusted, or fully untrusted. To serve the needs of users that regularly move between network locations, the firewall should ratchet up the netfilter rules to a stricter level when in an untrusted location such as a restaurant or public park, but ratchet them back down when reconnecting to the home or office network. Exactly which rules are applied at each trust level is up to the user or administrator.

Existing firewall tools, however, fall short in two ways. First, they know only about network interfaces, not about the networks themselves (trust information in particular). Second, they require stopping and restarting the firewall in order to change any settings. Red Hat's Thomas Woerner developed a solution tackling both issues based on GNOME's NetworkManager, and a new firewall application named Firewalld.

NetworkManager, which was designed to keep track of WiFi networks and opportunistically switch between them when roaming, already implemented some of the required functionality. It maintains a history of networks visited, and allows users to associate preferences with each saved network connection. Adding a trust level to each network connection would allow NetworkManager to instruct the firewall to change to a different rule set.

Firewalld solves the restarting problem by running as a D-Bus enabled daemon, listening for state change commands, and emitting information on the current status of the firewall. NetworkManager also uses D-Bus, so it can simply send a message to Firewalld telling it to raise or lower specific firewall rules as the situation dictates. To keep the firewall state consistent, though, Firewalld must be the only application modifying the settings (thus requiring that other firewall management packages be disabled), and for security reasons, all rule change requests accepted by Firewalld must be authenticated with PolicyKit.

In order for Firewalld to expose a straightforward set of configuration options to users (and other applications) over D-Bus, the firewall rule set had to be refactored into a clean set of distinct chains that correspond to individual features and services. Thus, adding or removing a rule in one chain will not interfere with the others. Firewalld implements chains for feature sets like virtualization, masquerading (NAT), port forwarding, and open ports, plus predefined chains for individual services like Samba or FTP.

The Zones zone

The official Network Zones proposal on the Fedora wiki defines nine initial network trust levels: trusted (meaning fully trusted, with all incoming traffic permitted), home, work, and internal (all three of which are for mostly trusted networks), dmz, public, and external (which are mostly untrusted), and block and drop (which are both fully untrusted).

Firewalld provides an initial configuration for each zone in an XML file. By default, the mostly-trusted zones open only a select set of ports (SSH, mDNS, Samba, and Internet Printing Protocol (IPP) for the home and internal zones, and SSH and IPP for work). The mostly-untrusted zones are more restricted, with SSH being the only allowed protocol for public and dmz, but SSH allowed and IP Masquerading enabled for external — though it's not exactly clear what the benefit of the latter is. The block zone rejects all incoming connections, while the drop zone drops them silently.

Of course, the intent is for users or system administrators to customize each of the zones' configuration as desired, allowing some differentiation between the otherwise-identical offerings. There are GUI and command-line utilities (named firewall-config and firewall-cmd, respectively) for examining and altering the configuration options; however as of today not all of the Firewalld rules are supported in either tool.

There does not appear to be a DTD or XML Schema for the zone configuration or firewall rules yet, but the syntax is straightforward. Individual services are enabled with a <service name=servicename> element; the other available firewall options are enabled by adding an element specific to the feature, such as <masquerade enabled="True"/>.

Network Zone integration is available in the NetworkManager 0.9.4 release, which will be part of Fedora 17, allowing users to assign a trust level to each of their saved networks, as well as a default zone to apply to unknown network connections. A system tray applet will display the current firewall state in GNOME Shell. The project has discussed adding the same functionality to KDE's network manager as well.

Firewalld was first made available in Fedora 15, but with the completion of the Network Zones support, it is slated to become the default firewall configuration tool in Fedora 17 (scheduled for release in early May 2012). Network zone support is not the only benefit of the daemon-like firewall approach — D-Bus controls open the door for other dynamic features in the future, like triggering temporary firewall rules without manual intervention, and desktop notifications triggered by firewall events.

The Firewalld project is not resting on its laurels, however. The future plans include support for granting or limiting access to the configuration tools on a per-user basis, and more abstract firewall rules based on metadata — such as "allow external access to music sharing applications." Network Zones is of clear benefit to laptop users, who both expose their systems to the greatest risk while roaming, and have had the hardest time finding a balanced firewall policy. But the possibilities enabled by a dynamically controlled firewall extend further; only time will tell what roles it can fill that a static configuration hasn't.