IPFIRE Startup and command line options
Homepage di Giacomo.

IPFIRE "options" file.

IPFIREwall at startup reads a configuration file located in each user's home IPFIRE directory and named options . At the moment, this file is not personalizable by means of the user interface, so people who want to customize the firewall behaviour must get familiar with its sintax. Lines beginning with # are comments and thus they ignored by firewall. The directives recognized are the following, divided into those allowed to everyone and those allowed only to administrator:

Unprivileged user options.

Sets kernel log level on the system log to N. N must be between 0 and 7. At the moment this option can be ignored.

Enables blacksite rules. Each user can add a line to the file named blacksites and located in IPFIRE directory indicating the name of an Internet site, and firewall will block any connection towards that node. It is necessary for this to work that output UDP connections towards the dns service (port 53) are enabled. See rule fields explanation or rule adding for further information. From version 0.98.4 on, it is possible to manage the blocked sites by an interactive menu called by pressing Control+B on the main menu. This option should be followed by a directive DNS_REFRESH=N , wher N is an integer in seconds indicating the refresh time of name resolving. Every N seconds, resolver wakes up and reloads the blacklist rules in the kernel, rewriting also the configuration file called blacklist. A reasonable interval is represented by some hours. Default value is 4 hours if none is indicated. Sites changing rapidly their mapping IP-name will require a lower value for the refresh interval. Try this function out and discover the optimal setting for your environment. Remember also that you can overwrite the refresh value acting on the command line, id est specifying the option -dns N.
A tipical line in blacksites file might be:
www.badsite.com .
Site addresses are resolved every N seconds.
Indicates the logging level of the user interface. N can be in the rank between 0 and 7. If the loglevel is less than 6, the translation operations are not shown in the user interface. Else if loglevel is less than 5, only implicit responses and denial verdicts are logged. Else if INTEGER is less than 3, only implicit responses are logged. Rather than acting on this parameter, administrator should act on loguser parameter, which sets kernel - user communication, affecting the efficiency of the system.

Specify an alternative file for permission rules database. Permission rules will be read/written from/to this file.

Specify an alternate file for denial rules database.

Specify an alternate file to look for the list of blocked Internet sites.

Specify an alternate file to look for the list of translation rules. Only root can apply translation rules.

Port numbers are resolved in the name of the corresponding service. Services are read by getservbyname() from the system file /etc/hosts , and dynamically loaded into memory. In this way, all calls to resolving function lookup in memory allocated vector, not in file, assuring high performance in resolving process. As a result, you will read in console the name of the service, e.g. www instead of the port number.

IPFIREwall supports multilanguage. It is important that the translation file be located inside the IPFIRE subdirectory in each user's home, in the folder languages.
The current translation available is the italian one. One can have a look at the file it in IPFIRE/languages directory to see how it is written and how easy it is to write a language file. The first part of each line contains the exact english phrase. The translation follows, separated by a single = character.
If you want to write a translation for IPFIREwall in your language, make sure not to change the english part preceding the =, and write the language specific part as you like. Then contact the author to have the language officially included in the distribution.

Administrative options.

This option enables the Network Address Translation globally. If there is some translation rule in your set, it won't be applied unless this directive is explicitly enabled. Destination network address translation is available through IPFIREwall, as well source NAT, but the latter has not been tested very well yet! IP masquerading must be explicitly enabled with the following:

Enables IP masquerading. When a host acts as a gateway, connected to Internet with for instance a dialup modem and procided with a dynamic IP address, this option is useful because IPFIREwall automatically does a source network address translation for all packets leaving the gateway's network interface (in our example, the modem). Masquerading rules must be set up properly too with the help of the user interface.

Rules will not be removed from firewall if this line is present. Only a command line directive as -flush will override this setting.

This is an important issue: sets the logging level of the messages going from kernel to userspace. If all packets were logged, atomic kernel context would send up to userspace a lot of packets in a short time, overloading IPFIRE interface. The best setting is 1: it's called smart logging and only packets which are not already been sent to userspace reach interface. Anyway,
N = 0 means no packet will be sent to user (no logging, fast).
N = 1 means smartlog: only new packets are sent.
N>= 6: all packets and information is sent to user.
N >= 4: negative verdicts are sent.
N >= 5: positive and negative responses are sent
N >= 2: implicit responses are sent.
Remember that only options 1 and 6 have been tested.
See here for further implications about logging.

Log to file name.

All rules in firewall will be treated as stateful, independently of the fact they have the field state set or not. Following option must be set for this to work.

Stateful firewall enabled. Rules marked as stateful will be tracked and matched by means of direct and reverse field inspection.

This option allows unprivileged users to insert their own rules into kernel firewall. It is usally combined with load command line flag.

Log information tables will remain allocated for N seconds in kernel firewall. (This applies to sessions started with loglevel set to 1).

Kernel will allocate at most N entries for log tables (loglevel = 1).

Kernel will allocate at most N entries for the source nat tables and destination nat tables (note: N for source + N for destination).

Kernel will allocate at most N entries for state tables.

Note that the settings concerning dynamic tables are critical since they use system memory. Wrong or too permissive settings can facilitate DOS attacks! See table variables section for details.

Valid XHTML 1.0!

Top of page
Back to index
Next page (Main menu - rule managing).
Previous page (Command line arguments).