Firewall settings unworkable

Thomas Woerner twoerner at
Wed Oct 6 15:26:58 UTC 2010

I am currently working on a proof of concept implementation of a 
firewall daemon, that will support dynamic firewall management with a 
D-BUS interface.

This implementation should be usable in some days and will feature the 
transition of the current firewall model to the dynamic version. It will 
provide the majority of features system-config-firewall has at the 
moment (services, ports, trusted, forward, icmp and masquerading), but 
will be limited to a command line client with D-BUS interface.

Here is more information on planned and proposed features:

Firewall Concepts - PROPOSAL

1) Firewall daemon

The current firewall services are static and can not handle dynamic 
firewall changes. Also system, user and administrator preferences can 
not be incorporated easily. The separation of IPv4 and IPv6 firewall 
services makes all this even worse.

The solution is to create a firewall service with a daemon, which is 
taking care of the firewall similar to NetworkManager that does this for 
network connections. The firewall daemon provides information about the 
current active firewall settings via D-BUS and also accepts firewall 
changes via D-BUS by using policykit authentication methods.

The firewall daemon is acting as a single authority for firewall 
creation and management. Controlling and maintaining the firewall if 
there are several applications or daemons changing firewall rules and 
behavior independently will most likely make it impossible to have a 
sane firewall state.

Support for additional firewall features like ebtables is needed to be 
able to support desktop and virtualizsation requirements.

2) Dynamic firewall

The current static model does not allow to add or remove rules and to 
load or unload netfilter firewall helpers easily. Restarting the 
firewall completely is required. Also the order of rules is very 
important and the usage of the predefined INPUT and FORWARD rules chains 
only is not helping to solve this.

The chains need to be separated. For example chains for services and 
ports, masquerading, port forwarding, icmp filtering and virtualization 
and custom rules. This makes it much more flexible, safe and robust. 
Adding a rule with the firewall daemon to one of these chains will most 
likely not interefere with rules of other chains. The order of the 
chains and how they are used is fixed and will not change.

For the netfilter firewall helpers it is not that easy. Helpers are for 
example used for amanda, ftp, samba and tftp services. If one of these 
services gets disabled, then the helper has to get unloaded from the 
kernel. For some of the helpers this is only possible after all 
connections that are handled by the module are closed. Therefore 
connection tracking information is important here and needs to get into 
account. Adding support for conntrack connection handling is therefore 
needed here.

It is possible to specify a timeout for a firewall service and also the 
other features. The service will be opened immediately and closed again 
after the defined period is over. This allows to accept new connections 
from unknown sources in the specified time frame. This will be very 
useful for UPNP, SNMP or NetBIOS for example to find printers or to 
share data with others. This mechanism is similar to the bluetooth 
handler in cell phones.

3) Network zones: Network security model

The network security model specifies the default trust level of all 
connections and can be selected initially at installation time, 
firstboot or when the first network connection gets established. The 
model describes the trust level of the whole network environment, the 
host is connected to and also defines what to do with new connections.

There are different initial models:

   - Home / Work
   - Public
   - Connection specific

The home or work zone has the highest trust level. All incoming 
connections are allowed. The public zone on the other hand is fully 
untrusted. No incoming connection is allowed. The connection specific 
model requires that the user tunes the trust level of a connection 
according to the needs. The default is untrusted.

The user or administrator is able to define new zones or adapt initial 
zones to change the behaviour according to their needs. Network 
connections can be bound to zones. The network security model makes it 
possible to have one trust level for all connections or to have several 
connections with different trust levels. The firewall has support for 
these zones and makes it possible that the user or admin can enable 
firewall features for zones.

If a new or undefined network connection is enabled in NetworkManager, 
the firewall daemon gets informed about this via D-BUS and can set 
firewall rules accordingly. There are chains for all supported network zones

4) Port metadata information (proposed by Lennart Poettering)

To have a port independent metadata information would be good to have. 
The current model with a static assignment of ports and protocols from 
/etc/services is not a good solution and is not reflecting current use 
cases. Ports in applications or services are dynamic and therefore the 
port itself does not describe the use case.

This metadata information could be used to form simple rules for the 
firewall. Here are some examples:

   allow external access to file sharing applications or services
   allow external access to music sharing applications or services
   allow external access to all sharing applications or services
   allow external access to torrent file sharing applications or services
   allow external access to http web services

The metadata information here could not only be application specific, 
but also a group of use cases. For example the "all sharing" group or 
the "file sharing" group could match all sharing or file sharing 
applications, for example torrent file sharing. These are examples, 
therefore it might be that they are not useful.

There are two possible solutions to get metadata information in the 

The first is to add it to netfilter (kernel space). This has the 
advantage, that it can be used by everyone, but also limits the use. To 
get user or system specific information into account, all these need to 
be implemented in kernel space also.

The other one would be to add this to a firewall daemon. These abtract 
rules could be used together with informations like the trust level of 
the network connections, the user decision to share with as specific 
person/host or the hard rule of the administrator to forbid sharing 

The second solution would have the advantage that new metadata groups or 
changes in incorporation of trust levels, user preferences or 
administrator rules would not require to push a new kernel. Adding these 
kind of abtract rules to a firewall daemon would make it much more 
flexible. Even new security levels woule be easy to add without kernel 

5) User interaction mode

This is a special mode of in the firewall the user or admin can enable. 
All requests of applications to alter the firewall are directed to the 
user to get notified and granted or denied. It is possible to set a time 
limit for the acceptance of a connection and to limit it to hosts, 
networks or connections. It can be saved to behave the same in the 
future without notification.

An additional feature of this mode is direct external connection 
attempts on preselected services or ports to the user with the same 
features as the application initiated requests. The limitation on 
services and ports will also limit the amount of requests sent to the user.

6) Compatibility Mode

The current static firewall model will still be available for 
compatibility for users or administrators creating their own firewall. 
This deactivates the firewall service and also the D-BUS daemon.


Comments and additional information is highly welcome.

More information about the devel mailing list