Alff is a plugin based, unitised, command line orientated framework for managaing your linux firewall rules.
Alff does "know" about networks, services (as in webserver, dnsserver, ...) or DHCP servers and provides a simple and intuitive configuration interfaces for this.
The Alff configuration file contains some elemental configuration options regarding your firewall type, network environment and your firewall machines.
At the moment Alff only supports a routing firewall; the bridging mode is not up-to-date, but will be included later on. (patches welcome)
The network configuration contains information about your network segments (called vlans) including information about IP network(s), the firewall interface which is connected to this vlan and a (list of) security class(es) for each vlan.
The term vlan is just a name for a network segment with one or more ip networks. It does not need to be a 802.1q vlan.
"Vlan" was chosen because the initial purpose of alff was to filter between a number of 802.1q vlans which include one ip network each.
Alff does know two security classes by default:
- filtered: This class marks a vlan as 'behind the firewall'. This information is used when creating a vlan to vlan matrix or can be used as an access level for services.
- trusted: This class marks a vlan as network of trusted machines. It does not include 'filtered' as one might want to set a vlan to 'trusted' which is outside your own network. This information can be used as another access level for services.
It is possible to include multiple vlans in one security class and to put one vlan into different security classes.
Let´s have an exmple:
<alff_config> <options> <fw_type> router </fw_type> <allow_icmp> all </allow_icmp> <default_chain_policy> REJECT </default_chain_policy> <dhcp_server> 192.168.42.23 </dhcp_server> </options> <vlan> <id> 42 </id> <network> 192.168.42.0/24 </network> <desc> my admin network </desc> <interface> eth0 </interface> <filtered> yes </filtered> <trusted> yes </trusted> <security_class> admin </security_class> </vlan> <vlan> <id> 23 </id> <network> 192.168.23.0/23 </network> <desc> my hacking lab network </desc> <filtered> yes </filtered> </vlan> <vlan> <id> WORLD </id> <network> ! 192.168.23.0/23 </network> <network> ! 192.168.42.0/24 </network> <interface> ppp0 </interface> <desc> The bad bad WORLD </desc> </vlan> </alff_config>
The alff framework "as is" is a simple tool. All real magic was pushed into the plugins or available modules - the perl modules for example.
The main thing alff itself does, is to take care about the execution of the plugins you´ve chosen and to generate a ruleset based on the output of the plugins.
Alff will have a look into /etc/alff/plugin.d - a runlevel like organized directory with executable files -
and will execute each plugin found there in the order of their filenames.
There exists a policy about the intende>
Plugin for network traversals
The classifyInterVlanTraffic plugin is used to generate a vlan to vlan matrix of all defined networks
in alff.conf which are configured as 'filtered', meaning that these network are behind your firewall.
When using this plugin you will get around (in most cases less than) n² chains called like 'vlan1_to_vlan2' where n
is the number of all vlans in alff.conf.
The plugin will skip a network traversal if both vlan are not marked as filtered, as there is nothing your firewall could do for them if none of the networks are behind your firewall.
Besides creating those chains and creating rules in FORWARD for branching the traffic fitting to a network traversal into
the right chain this plugin will have a look into the rules.d/ configuration directory and search for rules fitting to this network traversal.
These rules are just stored as a set of iptables command you would enter in a shell.
This is done as follows:
- At first the plugin will look for a '<src_vlan>_to_default' file like '42_to_default'.
This could be used to specify rules which should be loaded into all network traversal chains which handle traffic from vlan '42' to any destination.
Imagine vlan '42' being the network of your network administrators who should be able to access everything in the network. This would be an easy way of configurating this.
- At second classifyInterVlanTraffic will have a look for a 'default_to_<dst_vlan>' file like 'default_to_23'.
This is just the other way around as above.
- Now the plugin checks if there is a rules file for exactly this network traversal named like '<src_vlan>_to_<dst_vlan>'.
- If none of the above named files exists, classifyInterVlanTraffic will put the 'default_chain_policy' - configured in the alff.conf file - into this chain.
Plugin for service handling
As promised, alff does know about services :)
The generateServiceChains and hookInServiceChains plugins take care of the creation and loading of the services rules.
The generateServiceChains plugin will read the service configuration files in the services.d/ configuration directory and create a chain called 'allowSrv<ServiceConfigFileName>' for each service, filled with rules which allow all traffic to the configured ports of the given servers.
This mechanism will allow you to use this chains as nice targets when allowing access to your services.
Further on this plugin checks the configuration file for information about the network classes (securityClasses) from which this services is configured to be available by default. This provides an easy way to manage the access to your services.
The hookInServiceChains plugin just hooks the service access chains into the FORWARD chain.
See the plugin.d policy why this is splitted.
There are an increasing number of other plugins available. Just check them out...