This page should be revised or reconstructed to be more helpful. Problems may include being out of step with current team or project status or process.
system-config-firewall
What is system-config-firewall?
system-config-firewall is a graphical user interface for setting basic firewall rules.
Current firewall model
The current firewall model is static. The standard firewall configuration for IPv4 and IPv6 are created by lokkit. The initial firewall configuration is created at install time by anaconda and can be altered later on by the user with system-config-firewall, system-config-firewall-tui or the command line tool lokkit.
The configuration files are:
/etc/sysconfig/iptables /etc/sysconfig/iptables-config /etc/sysconfig/ip6tables /etc/sysconfig/ip6tables-config
/etc/sysconfig/iptables is the iptables configuration file and contains the rules in iptables-save format for IPv4. Analog for /etc/sysconfig/ip6tables and ip6tables for IPv6.
The -config files contain the service configuration for the services iptables and ip6tables.
system-config-firewall and lokkit are creating the /etc/sysconfig/ip*tables files. The files contain the full firewall configuration. These files are applied with the iptables and ip6tables services. system-config-firewall is handling these services to apply new firewalls or firewall changes.
Advantages / Disadvantages
+ One source for the rules.
+ A user can easily see which rules are applied and which rules should be applied by comparing /etc/sysconfig/ip*tables with the output of ip*tables-save.
- The model is static, the firewall has to be restarted to apply changes.
- The /etc/sysconfig/ip*tables files are recreated for all changes.
- Active connections could be terminated because of restarting the firewall even for small changes.
Planned features
- Dynamic firewall (v1)
- Full DBus interface (v1)
- User interaction mode (v1 and v2)
- Network zone support (v1, requires to add the ability to classify network connections in NetworkManager)
- User policy support (v2+)
The old firewall behaviour will still be usable if the firewall is set to static mode. This makes it backward compatible.
Dynamic firewall
The new firewall model will be dynamic. This means that /etc/sysconfig/ip*tables are not used for firewall configuration and will not be written for firewall changes. Also a lot of (most) firewall changes can be done without restarting the firewall. The firewall will be created and managed by lokkit. If /etc/sysconfig/ip*tables files are available, these will be used and the firewall is configured to be in static mode.
There will be new chains for services, ports, trusted interfaces, masquerading, port forwarding, icmp filtering and also services like libvirt. This will make custonmisation easier than before. Because of adding and removing rules to and from fixed chains in the firewall structure, these actions could not result in unexpected behaviour.
What the dynamic model can not do is to limit access for already active connections, because these are already established or related. Also it is not possible to unload netfilter kernel helpers at any time. If these helpers are in use, the unload of the module is not working. These are the cases where the old model has an advantage. Netfilter helpers are for example used for ftp, samba, tftp and amanda for services defined in system-config-firewall.
DBus interface
system-config-firewall will provide an enhanced dbus interface to easily configure the firewall. This will provide the ability to enable and disable services and to open or close ports, to mark and unmark interfaces as trusted or for masquerading, to add and remove port forwarding. Also adding or removing custom rules; but this will most likely require a firewall restart.
User interaction mode
The user will be asked if an application requests to change the firewall for example to grant access for a service. This is necessary, because the user has to be made aware of what is going on. This is only needed for network interfaces, which are not trusted. Marking a home network as trusted will be easy with a zone model (see #Network zone support).
Hiding changes to the firewall for the user will make the firewall insecure and the user will not know what is going on and what he is sharing with the world.
A dialog to ask the user could look like this:
Application X has requested to grant external access
for service Y. This will make it possible for Z to
browse this share.
Do you want to grant external access?
[ ] Remember this decision
[V] More options
[ ] Limit for [ 1 |V] [ minute(s) |V].
[ ] Limit to [ host 000.000.000.000 |V].
[YES] [NO] [HELP]
There will a also be a mode to make is possible for the user to allow connections on incoming requests for defined services. An incoming connection to one of these services will result in a question to the user as above, but the initiator is an incoming connection and not a local application requesting to change the firewall. This feature will make it possible to share data only on request for a connection and not the whole zone. This feature is planned for version 2.
Network zone support
Network zones define the level of trust for network interfaces. The access grants and limits can be set in a zone which can be used for a special type of network connections or trust level. A public WIFI network interface for example should be untrusted, a wired home network interface should be fairly trusted. But it might be needed to grant or limit access to services even for these two.
Useful network zones:
- UNTRUSTED_ZONE
This zone should be used for untrusted network connections. The zone does not allow to add access grants. All requests to modify this zone will be rejected.
- STANDARD_ZONE
This is the default zone for all network connections that are not classified by the user or administrator. It contains all grants or limits from the ALL_ZONE as a base and can be altered further.
- HOME_ZONE
- WORK_ZONE
These zones can be altered by the user or administrator and contain all grants or limits from the ALL_ZONE as a base and can be altered further.
- TRUSTED_ZONE
All accesses are granted.
- ALL_ZONE
This is an abstract zone, which can not be set for a connection. It can be used to configure access grants or limits for all zones except UNTRUSTED_ZONE.
- ACTIVE_ZONE
The active zone can not be set for a connection, it is only available to alter the current active zone. If there are more than one zone active, the user has to select the one he wants to alter.
The user or administrator classifies the network connections in NetworkManager, because it is managing the network interfaces. The zone selection depends on connection settings. For example access point data for WIFI connections or MAC addresses.
The default zone of a network connection could depend on the network type. WIFI connections for exmaple should be untrusted by default, but wired connections could belong to the standard zone.
The administrator could define if the STANDARD_ZONE or UNTRUSTED_ZONE should be used for unclassified connections. For security reasons, the UNTRUSTED_ZONE should be default, but for usablility reasons the STANDARD_ZONE might be good to use.
It could also be possible to add user or administrator defined zones.
User policy support
The administrator will have the ability to define which users can use the user interaction mode to alter the firewall and/or to react on incoming requests.
Other firewall configuration options
Another way to configure the firewall it either by hand or with other firewall configuration tools in the repo. It is important to disable the firewall of system-config-firewall here.
Download
https://fedorahosted.org/released/system-config-firewall/
Grab the latest source from GIT
You can get the current source using the following commands:
$ git clone git://git.fedorahosted.org/git/system-config-firewall