Firewall overview

OpenWrt uses the firewall3 (fw3) netfilter/iptable rule builder application. It runs in user-space to parse a configuration file into a set of iptables rules, sending each to the kernel netfilter modules.

The netfilter rule set can be very complex for a typical router. This is by necessity; each rule is tailored to a discrete capability provided by the router to protect its supported networks, provide NAT to conserve scarce IPv4 addresses, even mangle the packets during routing. A typical router has over 100 rules designed to support packet routing.

The fw3 application is used by OpenWRT to “safely” construct a rule set while hiding much of the details.

On inspecting the netfilter rule set using fw3 print, you will see a number of netfilter/iptables rules either not explicitly defined in the fw3 configuration files, or more difficult to understand (thank goodness for the –comment match!) The netfilter rules include:

  • A number of chains (mis-termed _rule) for each special target and zone
  • INPUT and OUTPUT for the often forgotten loopback interface
  • The option syn_flood 1 or option mtu_fix 1 each translate to complex iptable rules
  • The option masq 1 translates to the '-j MASQUERADE' target for NAT
  • mangle rules that match bits in the packets TCP header and then modify the packet

The fw3 configuration is fairly straight forward and automatically provides the router with a base rule set of rules and an understandable configuration file for additional rules.

The rules consumed by netfilter are, at best, difficult to comprehend due to the exacting nature of netfilter. However, every rule provides desired capability or blocks malicious capability, and therefore necessary.

fw3 is a user-space application similar in nature to the iptables application.

Both use the libiptc library to communication with the netfilter kernel modules, and follow the same basic pattern:

  • iptc_init to establish a socket and, using a getsockopt call, read the netfilter table into the application. This is on a per-table (filter by default) basis.
  • Modify the chains, rules, etc. in the table. All parsing and error checking is done in user-space by libiptc.
  • iptc_commit to replace the table in the kernel.

fw3 is typically managed by invoking the shell script /etc/init.d/firewall. The shell script accepts the following set of arguments:

  • boot: this is invoked during system init (bootup)
  • start: parse configuration files and write to the netfilter kernel modules
  • stop: flush configuration rules from the kernel modules (they will not be unloaded)
  • restart, reload: read the netfilter rules from the kernel, replace using the configuration files, and write back to the netfilter kernel modules.
  • flush: (dangerous) delete all rules, delete non-default chains, and reset default policies to ACCEPT.

Behind the scenes, /etc/init.d/firewall then calls fw3, passing the argument to the binary. In some cases, the argument will be accompanied by additional flags to suppress log messages, or calls to internal functions as described above to verify the configuration files.

:!: When invoking stop, only the rules in the configuration files will be flushed. Those rules automatically generated by fw3 will be retained.

:!: If all the rules are flushed by invoking flush, the default policy is set to ACCEPT and the router will pass all packets to, or forward on, to the destination network, providing no security.

In cases where the router becomes inaccessible due to DROP set as the default policy, access can be restored through one of two methods:

Source Code on GitHub:

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2021/08/02 15:59
  • by vgaetera