To obtain the latest development copy go to 
GitHub. If you want a released version, go to the GitHub download page here
The firewall logs, and by default, syslog will put this on the screen. You can turn that off using dmesg(8). Specifically, you want to type dmesg -n 1. Or edit /etc/syslog.conf to put all the logging on another console. Firewalls shouldn't have monitors anyway. :)
If you wish to build a debian package for the firewall (one may already exist in a Hoiho repository someday) check out the debian directory from here into the copy you got above.
Use a prebuild debian (or ubuntu) package if you can !
If you can't, once you have got the latest development copy, just run
make install
This will put things in the following places. By default the configuration lives in /usr/local/etc/linuxserver-firewall, the executable in /usr/local/sbin and rulsets live in /usr/local/share/linuxserver-firewall/ruleset.d
Consider altering the default locations inside the Makefile before building if you want them to be in a different location.
The main engine is a script called "firewall". When you run it it sets up some chains, and runs each script in "hosts.d/</tt>", then each script in "<tt>interfaces.d/.if". The "ruleset.d/*" directory is used for customised rulesets, the standard scripts come with a whole heap. Theres also a support directory, but this is for internal use and shouldn't be needed.
This is like the interfaces.d directory, except it's not limited per interface. This is useful if you wish to provide rules for all packets on all interfaces (eg: TypeOfService munging) or if you want to have rules that effect a host no matter which interface packets arrive/leave by. This directory doesn't get used much, but the support is there should you want it :)
This has one file per interface, the file is named after the interface with ".if" appended to it, for instance "eth0.if". Each file specifies the rules for that interface. ${if} is an environmental variable which holds the current interface name. Several chains exist for each interface:
eg
or
apply_policy out ....
and it will correctly add the --append ${if}- for you and use the correct table too so you don't have to remember if it's the mangle, filter or nat table :)
Now, you often have a lot of rules that are common between interface, and are even common between firewall installations, for instance some rules that deny all incoming TCP connections but allow outgoing TCP connections. These are stored in the ruleset.d/ directory (discussed later). These firewall "fragments" can be loaded on the fly automatically and used as targets. There is a neat little wrapper around this that you will probably use for almost all your firewalling rules called "policy". policy takes two (or more) arguments, the first is the chain name as you would provide to "apply_policy" and the second is the target, the remaining arguments are passed directly to iptables and can be used for more filtering. some examples:
policy in tcp-strict
will load the "tcp-strict" ruleset from the ruleset.d directory, and then issue a iptables rule such as:
/sbin/iptables --table filter --append ${if}-in --jump tcp-strict
policy will not load a ruleset twice if it's used twice, and will not load rulesets that aren't used to save memory. policy is also smart enough to know about built in rules and some aliases that can be used to make things more clear.
| name | aliases |
|---|---|
| ACCEPT | ALLOW, PERMIT |
| DROP | DENY, BLACKHOLE |
| MASQUERADE | MASQ* |
since policy uses --append you just list the rules you want for an interface one after another. A ruleset for eth0 might look like:
policy in ACCEPT policy out ACCEPT policy forward-in ACCEPT policy forward-out ACCEPT
You should only need to use "policy" in the interfaces.d/ directory. In most firewalls I put in place policy is the only command in the interfaces.d directory (sometimes I have a for loop if I've got a range of ports I want to do something with for instance).
etc...
There are several example class files in CVS. There are several standard interface "types" (eg: "external", "internal", "dmz" etc) and then you symlink interfaces to these. eg:
ln -s external eth0.if ln -s internal eth1.if ln -s dmz eth2.if
There are two new commands now that should appear as the very first rule in a interface definition. on_startup: This means that this interface definition will be run always from the main firewall script "firewall" on_demand: This interface definition will only be run if the interface is already up
Also new main scripts were added:
ifup eth0 home
the environmental variable ${RULE} will be set to the rule name (basically the name of the file less the ".rule" extension, and the environmental variable ${IPTABLES} will be set to the path to the iptables executable. There are also "polite_reject" and "polite_drop" which will be discussed later.
Heres a list of the various included rulesets and what they do:
Most of these rules are configurable and rather obvious if you edit them.
There are also some misc commands that can be used from both interfaces.d/ and ruleset.d/
Currently (as of version 1.0) there is a restriction in the use of ruleset in the forward-in of an interface. If a ruleset ACCEPT's a packet on the fw-in of an interface, the packet will NOT be checked by the fw-out of the outgoing interface. If this confuses you, just never use any rulesets that ACCEPT packets in the fw-in path.
These are all wishlist features which may or may not get implemented :)
Renaming interfaces based on their category : "External0" "External1" "Internal1" "Internal2" etc - thusly when an interface comes up it is named by it's purpose. Useful for those machines that have 10+ interfaces and you can never remember which is which, also important when you have multiple ppp0, or VPN interfaces that may come up in any order (do you set the permissive rule on ppp0 or ppp1?)
