Nathan Overall edited this page Apr 5, 2015 · 6 revisions


Please see our homepage for more details:

How to build and install the package

Use a prebuild debian (or ubuntu) package if you can! (see

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 bearwall. 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. There's also a support directory, but this is for internal use and shouldn't be needed.

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:

Chain Description
${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.

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. For example 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

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

There are two new commands now that should appear as the very first rule in a interface definition.


This means that this interface definition will be run always from the main firewall script "firewall"


This interface definition will only be run if the interface is already up.


Here you create 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

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. Configuration files are named with .host appended to it, for example This directory doesn't get used much, but the support is there should you want it :)

The hosts.d directory is intended for advanced users who want to override the way bearwall generates interface policies. Configuration files added in this directory are run in the bearwall environment which allows you to use all the usual bearwall syntax. Bearwall won't hold your hand and expects host.d configuration files to setup their own chains and insert them into the iptables firewall chain used by bearwall.

A simple host.d config for enable ssh on all interfaces would look like this:

new_chain host-in
iptables_with_table --append fw-in --jump host-in
policy host-in ACCEPT --protocol tcp --destination-port ssh

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 files must end in .rule (e.g. ssh.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.

Here's a list of the various included rulesets and what they do:

ruleset description
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/


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.


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.


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

    • Superceded by a udev where the file /etc/udev/rules.d/70-persistent-net.rules maps MAC addresses to interface names. With ppp interfaces, bring them up with 'unit N' in the command line, and they will take on that number. The other option is making a stanze in /etc/network/interfaces specifying a name, such as:

      auto internet
      iface internet inet ppp
      provider dsl-provider

  • 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

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.