Firewall settings unworkable
Thomas Woerner
twoerner at redhat.com
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
firewall:
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
completely.
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
updates.
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