It is very simple to extend FireHOL for simple single socket services. There are two different ways to do it.

The service definition syntax

The first needs a small service definition somewhere at the beginning of the FireHOL configuration file.

For example the following:

	server_myservice_ports="proto/sports"
	client_myservice_ports="cports"
Where: Just the above two lines will allow you to use (for example):
	interface eth0 internet
		server myservice accept
		client myservice reject
	
	router myrouter
		route myservice drop
later in the configuration file.

As an example, assuming that the IMAP4 service was not defined in FireHOL you would have to write:

	version 5
	
	server_imap_ports="tcp/143"
	client_imap_ports="default"
	
	interface eth0 lan0
		server imap accept
	
	interface eth1 lan1
		client imap reject
	
	router lan2lan inface eth0 outface eth1
		route imap accept

The inline service definition syntax

The second way is to use the inline service definition syntax:

		server custom myservice proto/sports cports accept
All the parameters are the same with the one presented above, in the previous section.

The IMAP4 service example above, now becomes:

	version 5
	
	interface eth0 lan0
		server custom imap tcp/143 default accept
	
	interface eth1 lan1
		client custom imap tcp/143 default reject
	
	router lan2lan inface eth0 outface eth1
		route custom imap tcp/143 default accept
So, if you are only going to need a service just once in your firewall, it might be convenient to use the inline syntax, while if you are going to need it many times, it would be easier to use the service definition syntax.
Personally, I always prefer to use the service definition syntax and to avoid the inline one (I always forget that the inline one requires a service name too...).

Multi-socket, but simple servers

Both of the expressions, given above for defining more services, accept multiple arguments.

Fox example, assume there is a service named serveme that listens at two ports, port 1234 TCP and 1234 UDP. The expected client ports are the default random ports a system may choose, plus the same port numbers the server is listening at.

To define this service you will have to write:

	version 5
	
	server_serveme_ports="tcp/1234 udp/1234"
	client_serveme_ports="default 1234"
		
	interface eth0 lan0
		server serveme accept
	
	interface eth1 lan1
		client serveme reject
	
	router lan2lan inface eth0 outface eth1
		route serveme accept
In this situation, FireHOL simply produces all the combinations between client and server ports and generates multiple iptables statements to accomplish them.

This is also the reason why the protocol cannot be defined in client ports.

Requiring kernel modules

Each service can be configured to require two sets of kernel modules depending whether NAT is enabled or not. This is done on a per service basis, so that if a service is not used in a configuration, FireHOL will not load the module.

The general format is:

	require_service_modules="some_module"
	require_service_nat_modules="some_module_for_nat"
As an example you can see the complete IRC definition within FireHOL:
	server_irc_ports="tcp/ircd"
	client_irc_ports="default"
	
	require_irc_modules="ip_conntrack_irc"
	require_irc_nat_modules="ip_nat_irc"
	
	ALL_SHOULD_ALSO_RUN="${ALL_SHOULD_ALSO_RUN} irc"
The last statement in the above example says to FireHOL, that if the configuration is using the all service, FireHOL should indirectly also setup the irc service with all the optional rule parameters of the all service.

Complex services

Complex services are those that use multiple sockets initiated on both directions (where the client becomes a server and vice versa) of the communication, and possibly involving protocols beyond TCP and UDP.

Currently you will have also to consider as complex all the services that you would prefer not to implement using the connection tracker of iptables (i.e. stateless). In the future, and if there is enough demand, I might expand simple services to handle stateless services too.

To write a complex service you will have to write a BASH function. It is not hard, but it is not two lines of code too, and most probably I am going to change the interface to those functions in the future, as FireHOL evolves. So, if you write one, please sumbit a patch so that I will be able to change your function if and when I change the interface to those functions.

Note however that there are a few types of currently complex services that I'll try to avoid. These are all those services that in order to be implemented in a stateful way there must exist a kernel module for them. If I support these services now, FireHOL will loose its beauty since it will have to have ranges of ports completely open to everyone just in case your service wants them. There are plenty of such kernel modules in an experimental state, which you can use if you decide to patch and recompile your kernel. If you do this, I'll be glad to support your stateful rules about them. If you try to allow such services in a stateless maner by, for example, allowing uncodintionally all traffic at high numbered ports... you are on your own.

If you decide to write a complex service, open FireHOL in your favorite editor and find all the functions that start with rules_. All these functions define rules for the complex services currently supported. If you know the basics of BASH programming, the existing functions will give you a clear idea of what you have to do to write your own.

Distribution of services with third party packages

FireHOL v1.213 and above includes a feature that allows third parties to install new service definitions in the directory /etc/firehol/services. The purpose of this feature is to allow the distributors of third party packages (like proxy servers, dns servers, etc) automatically install their service definitions in your system when their applications are installed.

To install a service definition, just create a file with any name, but with extension .conf in the directory /etc/firehol/services. The file itself must be a BASH script with any logic in it. The only requirements are:


SourceForge Logo $Id: adding.html,v 1.10 2004/10/31 23:43:25 ktsaou Exp $

FireHOL, a firewall for humans...
© Copyright 2004 Costa Tsaousis <costa@tsaousis.gr>