Differences between version 22 and predecessor to the previous major change of PerrysFirewallingScript.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 22 | Last edited on Tuesday, April 4, 2006 2:47:36 pm | by JamieCurtis | Revert |
| Older page: | version 18 | Last edited on Friday, February 25, 2005 4:00:41 pm | by AlastairPorter | Revert |
@@ -1,20 +1,40 @@
- cvs -d
:pserver:anonymous@cvs.sf.net:/cvsroot/wand checkout iptables
+To obtain the latest development copy get the following
:
-Or get the Debian packages from CraigBox (when Hoiho's repository is up, you'll know)
+<verbatim>
+svn co http://source.meta.net.nz/svn/linuxserver-firewall/trunk linuxserver-firewall
+</verbatim>
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) do the following once you've checked it out as above:
+
+<verbatim>
+ cd linuxserver-firewall
+ svn co http://source.meta.net.nz/svn/linuxserver-firewall/debian/trunk debian
+</verbatim>
+
+----
+!!!How to build and install the package
+
+Use a prebuild debian (or ubuntu) package if you can !
+
+If you can't, once you have got the latest development copy, just run
+<verbatim>
+ make install
+</verbatim>
+This will put things in the following places. By default the configuration lives in <tt>/usr/local/etc/linuxserver-firewall</tt>, the executable in <tt>/usr/local/sbin</tt> and rulsets live in <tt>/usr/local/share/linuxserver-firewall/ruleset.d</tt>
----
!!!How it works
-The main engine is a script called "firewall". When you run it it sets up some chains, and runs each script in "hosts.d/*", then each script in "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.
+The main engine is a script called "<tt>
firewall</tt>
". When you run it it sets up some chains, and runs each script in "<tt>
hosts.d/*</tt>
", then each script in "<tt>
interfaces.d/*.if</tt>
". The "<tt>
ruleset.d/*</tt>
" 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.
-!!The hosts.d directory
-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 :)
+!!The <tt>
hosts.d</tt>
directory
+This is like the <tt>
interfaces.d</tt>
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 :)
-!!The interfaces.d directory
-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:
+!!The <tt>
interfaces.d</tt>
directory
+This has one file per interface, the file is named after the interface with "<tt>
.if</tt>
" appended to it, for instance "<tt>
eth0.if</tt>
". 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:
;${if}-in: Used by all packets entering by this interface for this host only.
;${if}-out: Used by all packets leaving by this interface for this host only.
;${if}-forward-in: Used by packets coming IN this interface that aren't destined for this host itself.
;${if}-forward-out: Used by packets going OUT an interface that aren't originated by this host itself
@@ -54,9 +74,9 @@
if_feature rp_filter 1 # enable reverse path filtering for this interface
if_feature accept_redirects # accept ICMP redirects on this interface
etc...
-!!classes.d
+!!<tt>
classes.d</tt>
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
@@ -69,9 +89,9 @@
;fw-ipup: This brings up only one interface and presumes that the main "firewall" script has been run to set everything up. It takes one or two parameters. The first parameter is the interface name (such as eth0, eth1) and the second is an optional name for the name of the interface definition to read. For instance a wireless interface might use "home" or "work", so you could type:
ifup eth0 home
;fw-ipdown: This removes all the firewalling rules to do with an interface. Dynamic rulesets that are loaded by that interface are __not__ removed, however won't be executed by packets so only a very slight memory overhead is kept.
-!!the ruleset.d directory
+!!the <tt>
ruleset.d</tt>
directory
This is used to store fragments of a firewall, each fragment does something simple and can be used by interface.d files. rulesets have the form of "''name''.rule". rulesets don't have much in the way of helper functions. The first line of them should be:
. support/ruleset.functions
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.
@@ -101,9 +121,11 @@
;__A__:You don't have a catch all rule for something in one of your class files. Look at the syslog messages carefully and see what interface they are dealing with and which rule you are missing.
!!Wishlist features
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?) %%%
1. Superceded by a program whose name I forget which has a file of MAC->interfacenames and when run renames interfaces as required. Rather nifty. %%%
2. With ppp interfaces, bring them up with 'unit N' in the command line, and they will take on that number. Solves the problem nicely. You might need pppd 2.4.2.
-;
Some saner defaults : A simple default so if you run the script straight out of CVS it probably does what you want. Go get the deb if you need this.
-;
Use iptables-save and restore to speed shutdown/startup of script? : Not really worth the effort...
-;
Transparent support of ipv6 : Needs investigating
-;
Automatically load ip_nat_* modules :
+*
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?)
+**
1. Superceded by a program whose name I forget which has a file of MAC->interfacenames and when run renames interfaces as required. Rather nifty.
+**
2. With ppp interfaces, bring them up with 'unit N' in the command line, and they will take on that number. Solves the problem nicely. You might need pppd 2.4.2.
+*
Some saner defaults : A simple default so if you run the script straight out of CVS it probably does what you want. Go get the deb if you need this.
+*
Use iptables-save and restore to speed shutdown/startup of script? : Not really worth the effort...
+*
Transparent support of ipv6 : Needs investigating
+*
Automatically load ip_nat_* modules : done
