1.5 Firewall Warning in Documentation

Hi All,

Been a while since I’ve been here. My VyOS firewall 1.4 has been running perfectly and I haven’t had time to test features lately. They say if it ain’t broken don’t fix it… but I thought I’d come have a look at newer versions and since LTS is gone for general users, I checked 1.5 RC. When reading documentation I saw a warning about initialised ports during boot are all open.

How much of a concern is this?
Is it possible to have ports placed in disabled state during initialisation? Or other ways to mitigate the risk.
Wondering if this was the case with 1.4?

Not to blame but to explain VyOS to me is mainly a router and not a firewall.

And being a router it will by default allow for all traffic where a firewall should deny all traffic by default.

Having that said I think there are mainly two ways to deal with this.

One is to initialize the interfaces (so they can be configured with IP and whatelse) but only bring them UP as last stage during boot.

The other is to boot (you can add as bootstring to change the kernel default) with kernel flags for IP-routing being disabled and similar to above just after you bring the interfaces UP you THEN enable the IP-routing for forwarding of the packets.

Example:

/proc/sys/net/ipv4/ip_forward

/proc/sys/net/ipv4/conf/all/forwarding
/proc/sys/net/ipv4/conf/default/forwarding
/proc/sys/net/ipv4/conf/ethX/forwarding
/proc/sys/net/ipv4/conf/lo/forwarding

/proc/sys/net/ipv6/conf/all/forwarding
/proc/sys/net/ipv6/conf/default/forwarding
/proc/sys/net/ipv6/conf/ethX/forwarding
/proc/sys/net/ipv6/conf/lo/forwarding

Drawback with the sysctl approach is that local services are not dependent on IP-routing (forwarding between interfaces) so having the combo of as last actions first bring UP the interfaces and then enable IP-routing between the interfaces is about what you can do.

I havent dug into how VyOS does this or if its even possible to add something like the above without breaking things along the road.

Perhaps someone from the VyOS maintainers team can fill in?

Hi Apachez,

I use it primarily for a firewall but router for my home network. I use Zone Based Firewall Rules and all my rules by default are drop. Hoping someone can share insight to this warning. Is it only in version 1.5 or also 1.4?

Thanks you.

It is almost certainly in 1.4 as well. All fixes hit rolling first. Those commits are then cherry picked to build 1.4 and 1.5. So there’d be no reason to have differing behavior from 1.4 and newer releases.

The only official mention I’ve seen from anyone at VyOS (outside of that docs message) was in this reddit thread: https://www.reddit.com/r/vyos/comments/1ilew7c/question_about_the_fw_capabilities/

They did create a task for the issue, but it doesn’t seem to have gone anywhere: ⚓ T7149 Add an explicit option to allow traffic before the system is successfully configured

Solving the issue would be fairly easy. An nftables table could just be applied with an early priority, and then destroyed when the actual firewall config was applied.

The fail-safe config could be user defined like:

set firewall fail-safe ipv4 input filter rule 10 action accept
set firewall fail-safe ipv4 input filter rule 10 description 'SSH management from LAN'
set firewall fail-safe ipv4 input filter rule 10 inbound-interface name eth1
set firewall fail-safe ipv4 input filter rule 10 protocol tcp
set firewall fail-safe ipv4 input filter rule 10 destination port 22
set firewall fail-safe ipv4 input filter rule 10 destination address 10.0.0.1

So the abbreviated workflow when booting would be:

  1. Apply fail-safe nftables config
  2. Configure interfaces
  3. Apply final nftables config

Hi L0crian,

I could not see those commands available. Is fail-safe the name of the rule?

I found this

But as mentioned this may break the block rules.

I am just looking for a simple, during boot WAN port is down… once everything is initialised bring the WAN port online?

Happy to implement the other method but is there more information? I really don’t want to be looking for another firewall solution to sit in front of VyOS.

Those commands don’t exist. I was proposing that the solution could use that syntax. The feature would have to be added.

I dont think you need to apply any large amount of “failsafe nftables”.

Setting default to drop for input, output and forward should be enough as soon as possible.

Problem is WHEN is this being applied during boot?

Intel NICs are known to live on their own and bring links up even if the OS didnt bring the link up and such.

There would never be a large failsafe config. It would always just be the minimal config needed to gain access to VyOS to remediate whatever caused the main firewall config to fail to load. Generally a single rule would be enough. But you need to account for all user’s environments. Most people will only need a single input rule, but some will need input and forward.

And of course if they only want the default actions, they’d be able to do that as well.

This would completely lock out the user if the firewall config fails to load. There’s 2 issues
that need to be addressed.

  1. The insecure decision to allow traffic before the firewall is configured.
  2. Ensuring any solution won’t lock users out of their router in the event the firewall config fails to load, which is what was behind the insecure decision.

The issue won’t really be the interfaces coming up, but the interfaces being configured via their respective conf_mode scripts. This is the current priorities of those scripts:

root@vyos:/usr/libexec/vyos# python3 priority.py | grep -E "interfaces|firewall"
       300  interfaces_dummy.py                 ['interfaces', 'dummy']
       300  interfaces_loopback.py              ['interfaces', 'loopback']
       300  interfaces_virtual-ethernet.py      ['interfaces', 'virtual-ethernet']
       310  interfaces_bridge.py                ['interfaces', 'bridge']
       310  interfaces_input.py                 ['interfaces', 'input']
       318  interfaces_ethernet.py              ['interfaces', 'ethernet']
       318  interfaces_wireless.py              ['interfaces', 'wireless']
       320  interfaces_bonding.py               ['interfaces', 'bonding']
       321  interfaces_pseudo-ethernet.py       ['interfaces', 'pseudo-ethernet']
       322  interfaces_pppoe.py                 ['interfaces', 'pppoe']
       350  interfaces_wwan.py                  ['interfaces', 'wwan']
       379  interfaces_wireguard.py             ['interfaces', 'wireguard']
       380  interfaces_tunnel.py                ['interfaces', 'tunnel']
       381  interfaces_vti.py                   ['interfaces', 'vti']
       460  interfaces_geneve.py                ['interfaces', 'geneve']
       460  interfaces_openvpn.py               ['interfaces', 'openvpn']
       460  interfaces_sstpc.py                 ['interfaces', 'sstpc']
       460  interfaces_vxlan.py                 ['interfaces', 'vxlan']
       461  interfaces_macsec.py                ['interfaces', 'macsec']
       485  interfaces_l2tpv3.py                ['interfaces', 'l2tpv3']
       489  firewall.py                         ['firewall']

The ideal place to apply any solution would be in the vyos-router script, which is the same place where the vyos-firewall-init.conf config is already applied and happens before all conf_mode scripts.

So basically when you configure the failsafe config, it’ll use the normal firewall.py conf_mode script, but won’t actually apply anything. It’ll just put the config in the config object so it can be grabbed when the system boots. This means the solution is very simple because you already have all of code needed to add it.

When the system boots and vyos-router is setting up everything before any conf_mode scripts are loaded, a separate firewall_failsafe.py would be run, that would pull the config from the config object. It would then apply a failsafe table with that simple failsafe config. When the main firewall.py script is run, it would just destroy that table.

The issue with VyOS is that there is no dedicated MGMT-interface (as with hardware models) so if you want to apply a failsafe that shall be so that if things fails then the default shall be to block all traffic.

The only “failsafe” way to access a VyOS if things fails is through the KVM or the serialconsole. You cant and should not count on be able to reach the VyOS through an IP-interface specially not if/when boot/config fails.

So I still think that the default ruleset shall be set to DROP for input, output and forward by default and only be changed upon request by the admin AFTER the ruleset have been applied.

But again this boils down to if VyOS is a router or a firewall. For a router the default should be ALLOW while for a firewall the default should be DROP.

For example this flow:

  1. nftables set to default drop and high prio rule to actually drop everything.

  2. IP-routing set to disabled.

  3. Configure interfaces.

  4. Apply nftables. Including changing defaults to whatever the config says should be used.

  5. Remove that highprio rule that blocks everything.

  6. Enable IP-forwarding.

  7. Continue with the rest like FRR etc.

This way up until step 5 if things fails your VyOS box wont be wideopen to the world.

If everything went OK including step 4 then the block will be removed at step 5 and routing between interfaces is enabled at step 6. Then the boot/apply of config proceeds.

Hi All,

Sorry been busy with work and unable to revisit this.
I use my vyos mainly as a firewall and love the CLI interface… other opensource solutions don’t really support cli and re-learning other configs, well I don’t have time :slight_smile:

Looking for a way so that I can lock it down. Even if it locks me out I don’t really mind as I do have a serial connection to my firewall hardware. Going through the post there is lots of info but is there a solution that I can configure to stop it opening ports on reboot? Or is this not possible? Maybe should be documented on “here is how, with risks”

Thanks all! Appreciate it.