Homepage di Giacomo.
DOWNLOAD an IPFIREWALL pre-release (test).
Leggi un'introduzione al protocollo di rete TCP/IP e all'uso di IPFIRE-wall in italiano!
Download an installation and first utilization Guide (in italiano)!
Download an IPFIRE-wall presentation (in italiano!)


If anyone was interested in this work, or decided to download and try it, i would be very grateful if he [she] let me know.
Thanks a lot!
Have fun!


IPFIREwall is an IP packet filter also capable of doing Network Address Translation and IP Masquerading . It is written in C language and was born in a GNU/Linux environment.
In particular it was originally built inside the linux kernel (the latest available at that moment), although such version is now no more supported because of the lack of the RCU framework which is now required to run the packet filter.
It has been developed since June 2005.

Infrastructure and peculiarities.

IPFIRE-wall infrastructure is made up of two layers: the upper one runs in userspace and the lower inside the kernel. Filtering and translation actually happen in kernel context, while logging and user commands are handled in the userspace interface.
Communication between the two worlds takes place by means of the netlink socket communication. In this way, it is possible for users to watch detailed information about packet flowing and firewall filtering, at different levels of verbosity.
The framework is studied to allow the administrator to load his own filtering rules, which cannot be altered by unprivileged users, and to let also normal users personalize and make secure their own network activity. In the practise, the root user sets up a minimal network environment, with the most essential rules for filtering and address translation. In a second stage, having IPFIREwall been setup and configured by the administrator, each workstation's user adds his own rules to personalize his needs.
For instance, a tipical scenario would be represented by the parent (administrator), which applies some control denying the connections towards some specific addresses and protecting the computer against incoming connections.
In such an environment, the children can be left playing with IPFIREwall and the linux internetworking, and safely learn how them work.
Each user's rules are stored in three different configuration files: the first contains the denial rules, the second the permission ones, the third the translation rules.
The logical flow of the algorithm goes as follows:
the packet filter first reads the denial rules: if a match is found, the packet being observed is explicitly dropped, then IPFIREwall looks up among the permission rules: if a correspondence is found, the packet is explicitly allowed. If no match happens, then default policy is applied. To learn about setting and reading the default policy, see the kernel module loading chapter or the /proc interface chapter.
Continuing with our discussion, we have to say that just the root user is allowed to apply the network translation rules.
The administrator might want to load his rules at startup, and then leave users turn on their own firewall to add their rules or just to watch what is going on in network/transport layer, just as we told a few lines above. Every unprivileged user, when shutting down the firewall interface, flushes his rules from kernel lists, naturally leaving previously loaded administrator's ones. A normal user does not have the right to alter root's settings, nor has the capability of modifying some critical firewall variables, such as dynamic rules timers of translation tables timers, or again the maximum number of entries allowed inside the dynamic kernel lists storing each data structure. Settings as these are critical from both the security and the efficiency perspective and must be carefully tuned by the administrator. Global settings are stored in another configuration file, and memorize the names of the files listing the rules, the logging level, and some other options such as the port service resolution, the blacklisted sites, and so on...

A simple state machine.

IPFIRE is also able to keep the state of a connection (although the state machine implemented is very simple), creating a table for each connection which is looked up before consulting the static rule lists. Thanks to this option, reverse field match is possible and so it is not compulsory for the users to insert one rule and the corresponding one with inverted parameters. For instance, one can let a packet go out from the local machine and then the firewall recognizes it when a reply comes back from the remote node as an already allowed communication.

Blocking Internet addresses from their names.

As pointed out, IPFIRE can hold a list of Internet sites which must be blocked by the firewall. Userspace interface resolves periodically blacklisted Internet names and updates denial rules both locally (on configuration files) and in kernel lists. In this way, it is very easy to apply a simple form of parental control over Internet web sites. From the version 0.98.4 on, adding and removing the internet addresses to be blocked by their name has become very easy, since the IPFIREwall user interface has made a new interactive menu available to the aim.
While IPFIREwall is running and filtering, some statistics are made and in every moment are ready to be shown to the user.

A simple tool to analyze the logs.

A subsequent analysis can be done against log files by means of the utility called analyzer, which comes together with IPFIRE sowtware. This utility, which comes with no warranties, automatically performs the resolving of the IP addresses into the Internet names of the nodes involved and further statistics about the firewall decisions.

Valid XHTML 1.0!

Top of page
Back to index
Next page (Contents of the documentation).