Penguin

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.


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

 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.


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/</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.

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 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:

${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
${if}-postrouting-out
Used by packets that are leaving this interface after routing has taken place.
${if}-prerouting-in
Used by packets that have entered this interface before routing has taken place.

eg

  • Dropping port 80 on forward-in on ppp0 will disallow people on the internet to connect to port 80 internally
  • Dropping port 80 on forward-out on ppp0 will disallow people internally from connecting out to the internet on port 80
You could use "${IPTABLES} --append ${if}-in ..." to add the rules for this interface, but because this is so common there is a function to do it for you called apply_policy. you use it like
apply_policy in ....

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).

There are also interface features which you can specify in these files. These are /proc entries in /proc/sys/net/ipv4/conf/${if}/*. there is an alias to manage these for you "if_feature". For instance
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

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:

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

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.

Heres a list of the various included rulesets and what they do:

classify
This sets the various TypeOfService bits in the IP header based on the port (protocol) of the packet.
icmp-strict
Ignore ICMP not due to an already established connection. This means that ping, and PathMaximumTransferUnitDiscovery? works, but someone pinging us will fail. Kinda a bit of overkill, but it's here for those that are scared of this kind of thing.
icmp-trust
Allow all ICMP
martians
drop any packets that are from or to an internal IP range as specified in rfc1918. useful for external interfaces.
multicast-strict
Drops pretty much all multicast
multicast-trust
Allows some multicast through.
tcp-strict
Allows only outgoing TCP connections, rejects the rest, except for port 80 where it drops all packets (slowing down the still numerous codered hits).
tcp-trust
Allows all TCP except to some well known ports that it shouldn't have access to (eg: linuxconf, nfs and portmap etc). Useful for an interface that is connecting to another department that you trust and want traffic to flow to and from, but they don't need any of your sensitive services, so if they get compromised hopefully the attacker won't get the opertunity to compromise you too.
udp-strict
Disallows incoming UDP that isn't part of an already established "connection" (ie: a reply from a packet that was originated here)
udp-trust
Disallows incoming UDP to potentially dangerous ports (NFS, Portmap, tftp etc)

Most of these rules are configurable and rather obvious if you edit them.

Misc commands

There are also some misc commands that can be used from both interfaces.d/ and ruleset.d/

polite_reject
requires at least one argument, the first is the rule to append to, the rest is any other iptables options that may be used (eg: limiting it by port). polite_reject then rejects the packets ratelimited to 5/s and logs them at a rate of 2/s, rendering floods less effective. All packets that aren't rejected are dropped.
polite_drop
same as polite_reject but only logs at 2/s and doesn't send back reject messages. This is useful for rules where you know that the rejects aren't going to be used (for example if the source address is a martian) or it could be downright harmful (eg: the packet was directed towards a multicast or broadcast address).

Restrictions on the use of rulesets in forwarding

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.

FAQ

Q
Why do I get lots of messages saying "End of something" on my screen/in my syslog
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 : done