Note.
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!
Introduction.
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 2.6.12.3 (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.