Using fwbuilder as main firewall generator for LEDE (study)

Installing and Using OpenWrt Network and Wireless Configuration
1

Dear all,

I would like to study usage of fwbuilder to generate firewalling rules for LEDE as an alternative firewall.
This is now my #1 issue on my radar.

Here is a background why I would like to move to fwbuilder:

This is linked to this post about logging:
https://forum.openwrt.org/t/call-for-review-how-to-log-rejected-packets
https://lede-project.org/docs/howto/log-rejected-packets#logging_limitation_in_openwrt_and_lede

Today, there are official recommendation for firewalling rules, especially targeted at companies and institutions .
Those rules do not abide by the law ... but could abide sooner or later.

Take the example of French National Security Agency (ANSSI), which produces recommendations:

In particular, each firewall rule should be numbered, labeled and when logging is enabled, it should include the rule number. This is clearly impossible (or really difficult) using LEDE embedded firewall,

ANSSI rules allow you to quickly analyze a situation using the logs. This is currently not possible with LEDE firewall, which does not label rules, does not number them and does not log them. Luci firewall does not provide a customizable reject rules on bottom of a zone. Personally, I think that the current LEDE firewalling rules put us at risk and are the weakest point of LEDE.

A possible solution would be to delegate writing iptables rules to fwbuilder Free Software, which seems (IMHO) to comply with ANSSI rules. Fwbuilder includes an OpenWRT firewalling template and has full support for detailed logging (even to databases) and much more. It includes an OpenWRT template, which is only IPv4, but with some work it could target current LEDE ipv6 implementation.

OpenWRT (LEDE) if officially supported by fwBuilder:
http://www.fwbuilder.org/4.0/supported_firewalls.shtml

Are some of you already using fwbuilder as a firewall generator for LEDE and documenting it? Would you like to collaborate with me around a short study of fwbuilder with documentation back on LEDE.

Any thoughts, comments and replies are welcome.

Kind regards,
French Fries

2

Not quite sure why you seem to be so enthusiastic about fwbuilder, which seems to be ancient.

Based on its own docs, it supports iptables for kernel 2.4 and 2.6 and likely the promised support for Openwrt is from the same time (maybe for Backfire 10.03 or so...).

And fwbuilder's own development seems to have stopped in 2011-2012 (blogs & copyrights end then, and the last git commit in Sourceforge is from 2012)

You might have also realised by now that Openwrt and LEDE use the same firewall core (fw3) and LEDE just uses a slightly newer version. LuCI does not provide core firewall functionality, but is just a GUI enabling easier adjustment of the most usual firewall functions. however, it still manages the same /etc/config/firewall file that the actual firewall uses as the config base.

3

Yes, I agree that the firewall typically used in LEDE/OpenWRT does not allow for easy monitoring of packets.

I also don't believe that any turn-key generation of firewall rules can meet the requirements of anyone truly interested in security. If you don't understand each and every one of the rules in your firewall then you can't test and convince yourself that it truly is going to perform as expected.

Finally, although LEDE/OpenWRT is certainly worlds better than most firmware running on consumer-grade embedded routers, it's far from secure to start with and very far from anything that would be considered enterprise grade. I can't imagine anyone subject to security audits relying on it as their primary firewall.

The firewall in LEDE/OpenWRT can be successful at providing a moderate level of protection for home use, balanced with ease of use by non-experts.

I, personally, would prefer any efforts on the LEDE/OpenWRT firewall to go toward being able to better log and divert rejected packets. I'm used to a system that allows the following:

  • Log rejected/dropped packets (as well as any packets at any point in the processing)
  • With the primary packet identifiers
  • With a tag identifying the rule
  • Optionally with a limit of number of packets
  • Reset logging when limit is exceeded
  • Divert rejected/dripped/interesting packets to bpf-enabled device for use with tcpdump or wireshark

Those benefits, at least for me, far outweigh some black-box firewall-rule generator

Black-box firewall-rule generators are also, in my experience, pretty useless when you start talking about multiple protection zones and the cross-one traffic that needs to be managed.

4

Nice to see this raises your interest!

You are right, did not catch my eye. A reboot is available here:

An interesting issue is that fwbuilder could need modifications to handle ipv6 traffic.
I used it for years and it is rock-solid, but this was ipv4.

Fwbuilder is a very solid solution, test it to make your own opinion. Once you have the correct definitions, you can even migrate your firewall from LEDE to FreeBSD or the converse.

Yes, this would suit me as well.

But "With a tag identifying the rule" means that each rule probably needs to be compiled within its own custom chain. Example:
iptables -N SSLv3
iptables -A SSLv3 -j LOG --log-prefix "Firewall A: Rule 3: SSLv3 Client Hello detected: "
iptables -A SSLv3 -j DROP

In the end, this makes longer rules, and they are sometimes hard to read.

By the way, fwbuilder is not a "black-box" as it is completely free software. Its firewall generator relies on an XML definition. It outcomes all other solutions that I tested before and is WAY ahead.

I even think that its XML rule generator could be integrated in GNU/Linux as an independent abstraction layers to iptables but never was.

5

Jeff, the features that you are looking for are handled by nflog extension:
http://ipset.netfilter.org/iptables-extensions.man.html

NFLOG
This target provides logging of matching packets. When this target is set for a rule, the Linux kernel will pass the packet to the loaded logging backend to log the packet. This is usually used in combination with nfnetlink_log as logging backend, which will multicast the packet through a netlink socket to the specified multicast group. One or more userspace processes may subscribe to the group to receive the packets. Like LOG, this is a non-terminating target, i.e. rule traversal continues at the next rule.

--nflog-group nlgroup
The netlink group (0 - 2^16-1) to which packets are (only applicable for nfnetlink_log). The default value is 0.
--nflog-prefix prefix
A prefix string to include in the log message, up to 64 characters long, useful for distinguishing messages in the logs.
--nflog-range size
The number of bytes to be copied to userspace (only applicable for nfnetlink_log). nfnetlink_log instances may specify their own range, this option overrides it.
--nflog-threshold size
Number of packets to queue inside the kernel before sending them to userspace (only applicable for nfnetlink_log). Higher values result in less overhead per packet, but increase delay until the packets reach userspace. The default value is 1.

6

fwbuilder was rebooted by https://github.com/BrendanThompson sysadmin of Github. Well-spotted.

7

nftables successor of iptables allows logging in one rule without jump:
http://linuxfr.org/news/nftables-successeur-diptables
https://wiki.archlinux.org/index.php/nftables

So a solution would be to handle nftables ... Interesting.

8

nftables is a huge improvement over iptables, but still "isn't there" even with Linux kernel 4.9

Notably missing at first glance include:

  • ip verify unicast reverse-path equivalent (v0.7 provides fib, which will require kernel 4.10)
  • ip verify unicast source reachable-via any (v0.7)
  • anti-spoof -- directly connected networks only
  • Assembly of fragmented IPv4 prior to firewall evaluation
  • Ability to atomically swap rule sets

Not to mention that, as far as I know, the Linux kernel doesn't provide the ability to lock down the firewall rules after they are loaded at boot (which means even for privileged users/processes)

9

I came across this post, because the LEDE documentation specifically references fwbuilder here; but it's clearly not up-to-date information.
I am curious to learn what you would consider above moderate level of protection (maybe enterprise). Products I've looked at that are open source are IPFire and OPNsense.
Do you have a personal favorite?

10

For personal use, I run FreeBSD ipfw back-to-back with netfilter (not iptables as it is close to gibberish when it comes to understanding what the rules do and how they interact)

11

I believe IPFire is based on FreeBSD. Excerpt from their WiKi:

The IPFire firewall is based on the Linux netfilter Packet Filtering framework which is famous for its command line tool that is called iptables. It is paired with a P2P filter that enriches the feature set by allowing to filter certain P2P protocols.

I want to learn more about how to set up a better firewall. I thought a GUI based solution like IPFire or OPNsense (based on pfsense) might be a good starting point. I know it's a complex subject matter and a steep learning curve.

12

To revisit this one more time. Do you know of any tutorials / instructions that would show how a first time user how to harden the LEDE built-in firewall to be secure? I hoped to find something like that in the docs, but didn't get lucky.