VyOS Networks Blog

Hello, Community! It's spring in the northern hemisphere, and here's the March update. A lot of our effort is currently going into the development of the accelerated dataplane based on VPP: We added a prototype of IPsec, and we are actively working on support for NAT. But there are many other updates, including a fix for a vulnerability in service console-server, support for loading firewall groups from a URL, an option to set a custom container registry, and more. Read on for details!

Configuration syntax changes

The obsolete, non-standard BGP community value internet is now automatically replaced with 0:0 by a migration script on config load (T7116).

That alias for 0:0 was never in any RFC or a standard or any kind, and was included only to mimic some proprietary vendors.

Security

Private SSH key reuse in service console-server (T7217)

Morgan Jones from Viasat reported an issue that made SSH sessions associated with the console server vulnerable to active man-in-the-middle attacks (but not to passive eavesdropping in the general case). That issue did not affect system SSH connections (to the server started by set service ssh) — only SSH connections to console server ports.

A vulnerable configuration looks like this:

vyos@vyos# show service 
 console-server {
     device ttyS1 {
         speed 115200
         ssh {
             port 3000
         }
     }
 }
}

The console server in VyOS uses Dropbear SSH server, rather than OpenSSH. The issue was that the private key for Dropbear was generated at the image build time and was not regenerated on first boot or deployment, so every system deployed from the same image used the same private key.

That would allow an attacker capable of intercepting and modifying the traffic between the server and the client to impersonate the server during the key exchange phase, if the attacker knew what VyOS image was running on the server and had access to that image.

The cause was that Debian's packaging for Dropbear is made to generate those keys in the post-install script (frankly, a questionable idea in a world where deploying systems from images is now a common practice). OpenSSH packaging has the same feature, but there's a mitigating factor: live-build (the image build tool) has a safeguard against that behavior in OpenSSH — a hook to remove OpenSSH private keys from the generated system before packing it into a SquashFS image. However, it has no equivalent safeguard for Dropbear.

We now added that safeguard ourselves and made the configuration script generate keys if they don't exist. We plan to contribute the hook upstream so that other systems that use Dropbear and live-build.

Upgrading to the latest rolling release image will solve the issue for you, but you can also regenerate private keys by hand: run sudo dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system.

New features and improvements

Loading firewall groups from remote files (T5493)

A way to load a list of addresses into the firewall ruleset from a file or a URL has always been a frequently-requested feature, but it's a tricky feature to get right. There were a few unsuccessful attempts from maintainers and community members alike. This month, we merged a pull request from Alex W that implements download and periodic refresh of firewall groups from files on remote servers, and we invite everyone to test it.

Here's a little demo:

# Sample file
vyos@vyos# cat list.txt 
192.0.2.0/24
203.0.113.0-203.0.113.255

[edit]

# Start a local web server for testing
vyos@vyos# python3 -m http.server --directory . &

# Create a remote group
vyos@vyos# set firewall ipv4 forward filter rule 10 source group remote-group TEST

# Check if the group was loaded
vyos@vyos# sudo nft list  table ip vyos_filter
table ip vyos_filter {
    set R_TEST {
        type ipv4_addr
        flags interval
        auto-merge
        elements = { 192.0.2.0/24, 203.0.113.0/24 }
    }

The list file can contain any objects valid for NFTables rulesets: single addressed, subnets, or ranges — one per line.

This is the first prototype and there's certainly potential for improvements. For example, at the moment there is no way to force a refresh of a group. Also, malformed entries in lists are simply ignored right now — what proper error reporting may look like is debatable.

But it's a probably a good start. If you notice any bugs or see how we can improve that feature, let us know!

Other features

• install image and set system login user <name> authentication plaintext-password now warn the user if the password is too simple (T6353). The check is against insufficient entropy and vulnerability to dictionary attacks, in line with latest NIST guielines — no "must have a capital letter and a special character" nonsense.
• It's now possible to configure custom container registry addresses and options: set container registry ... (T7092).
• show bgp commands now allow filtering by route distinguisher: run show bgp <ipv4|ipv6> vpn rd <all|ASN:NN|IP:NN> (T7227).
• It's now possible to tell the syslog daemon not to send unnecessary mark messages: set system syslog marker disable (T6989).
• Routes learnt from NHRP can now be redistributed into other protocols, for example: set protocols bgp address-family ipv4-unicast redistribute nhrp [route-map <name>] (T7118). This was made possible by the fact that we use FRR's nhrpd instead of the far less actively maintained OpenNHRP.
• Support for mknod capability in containers: set container name <name> capability mknod (T7204).

Bug fixes

• Fixed a WireGuard key validation error that mistakenly rejected keys that start with // (T7246).
• Operational mode command for QoS correctly work with VRFs now (T7138).
• Fixed an unhandled exception in generate ipsec profile ios-remote-access operational mode command (T7225).
• Fixed an issue with synchronization of DHCP hostname records with the system state (T6948).
• VXLAN interfaces set up over WireGuard tunnels no longer disappear when the parent interface changes (T7166).