Page MenuHomeVyOS Platform
Feed Advanced Search

Feb 27 2022

sempervictus created T4274: Extend OpenConnect RADIUS Timeout to Permit 2FA Entry.
Feb 27 2022, 1:41 PM

Sep 16 2021

sempervictus added a comment to T3833: Cloud-init not finding data source in OpenStack.

Curl checks come back with:

[email protected]:/tmp# curl 169.254.169.254/latest/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
Sep 16 2021, 4:01 PM · VyOS 1.4 Sagitta
sempervictus renamed T3833: Cloud-init not finding data source in OpenStack from Cloud-init not inding data source in OpenStack to Cloud-init not finding data source in OpenStack.
Sep 16 2021, 3:59 PM · VyOS 1.4 Sagitta
sempervictus created T3833: Cloud-init not finding data source in OpenStack.
Sep 16 2021, 3:53 PM · VyOS 1.4 Sagitta

Aug 30 2021

sempervictus added a comment to T3784: can't build iso with custom built iptables .

How are the MD5 sums matching but the sha512 sums not matching?

Aug 30 2021, 10:02 PM · VyOS 1.4 Sagitta

Aug 29 2021

sempervictus added a comment to T2191: Using tallow to block sshd probes.

This can be done via the tc kernel module AFAIK. Something like fireqos would be great to have in here, but they're pretty opinionated in how they do things in their tools so probably not a viable drop-in solution.
This can also be done with OSSEC using active response, either by building an OSSEC agent into the image (client key management is kind of a PITA) or by way of remote feed for FW log events showing attempts to connect with an active-response script to temporarily block the offenders with progressively longer blocks on repeat offenses.

Aug 29 2021, 4:06 PM · VyOS 1.3 Equuleus (1.3.0)
sempervictus added a comment to T1942: hardware info collector .

lshw does this already

Aug 29 2021, 4:00 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T1890: Metatask: rewrite flow-accounting to XML and Python.

I added the kernel netflow module to my pull request a while back - collects and forwards flows to a destination defined in the module parameter set at load-time.
If we want to actually process flows on-system, there's a bunch of modern tooling for that; but in terms of just aggregation and export in canonical format, the kernel module is the best way to go IMO due to the fact that it works at the same tier as the network code itself (ring0).

Aug 29 2021, 3:56 PM · VyOS 1.3 Equuleus (1.3.0)
sempervictus added a comment to T1683: Difficulty monitoring VyOS through SNMP.

Not seeing this issue when setting "description" field - we've run it in production for years bridging our OpenStack and datacenter environments, and the names show up correctly (blanked sensitive details):

Aug 29 2021, 3:52 PM · VyOS 1.3 Equuleus (1.3.0), VyOS 1.4 Sagitta, VyOS 1.2 Crux
sempervictus added a comment to T1619: Migrate user home directories on image update.

From a post-exploitation perspective, this would permit attackers who've compromised an older vulnerable version to persist their payloads in the shell elements (~/.bashrc and friends) across upgrades.

Aug 29 2021, 3:46 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T1437: First boot configuration support.

This seems similar to the "configuration drive" option for OpenStack, which is already handled by cloud-init. Might be handy to implement as a cloud-init local data source and just include CI on all builds since thats becoming an industry standard even on bare metal.

Aug 29 2021, 3:44 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T2888: Cloud-init images refuse to work with network-based datasource such as Ec2 or OpenStack (but do work with OpenStack's config drive).

I've managed to get this working in our own builds by restoring the openstack target and making some changes there - runs fine in AWS, even with a grsec kernel and hardened userspace (Xen is often the worst visor for ring0 memory defenses).

Aug 29 2021, 2:16 PM · VyOS 1.3 Equuleus

Aug 27 2021

sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

Once i dropped that repo everything started to work again... and while it may be a temporary thing, i think that this sort of illustrates the problem with reliance on external repos. Its probably safer to mirror their content into something that can be relied upon to stay live as companies are bought and sold all the time, resources vanish, and licenses change from real FOSS to semi-permissive .

Aug 27 2021, 2:39 PM · VyOS 1.4 Sagitta

Aug 6 2021

sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

Seems like the repo's not needed anymore as my iso just built without it, twice, after a clean, and with a bunch of added stuff (tor, docker, systemd-nspawn, xtables-addons, hardened-malloc, a grsec kernel, etc) for which dependencies are also available without it.
Either way, probably a good idea to keep deps for anything third-party in the vyos repo itself since third parties can become hostile through buyouts or license changes any time and anywhere in these post-FOSS times.

Aug 6 2021, 10:12 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

What packages are we actually pulling from there? Any reason they're not in the VyOS repo itself?
I removed their repo entirely from the JSON config and my image built fine (apparently i now have to add a /debian suffix for all packages in our repo, but that's weirdness in the repo management stack):

Reading package lists...
Building dependency tree...
Reading state information...
[2021-08-06 21:39:40] lb source 
P: Source stage disabled, skipping
P: Build completed successfully
Aug 6 2021, 9:40 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

Trying to use their instructions from https://repo.saltproject.io/#debian i'm back to the certificate issue - repo is set to https://repo.saltproject.io/py3/debian/10/amd64/latest buster main and the custom GPG key has been added, but certificate checks still fail hard:

Reading package lists...
W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/InRelease: No system certificates available. Try installing ca-certificates.
W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/Release: No system certificates available. Try installing ca-certificates.
E: The repository 'https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release' does not have a Release file.
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Del nftables 0.9.6-1 [66.8 kB]
Aug 6 2021, 9:31 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

After cleaning the chroot and retrying, it now fails utterly with the '#' in there:

Aug 6 2021, 9:19 PM · VyOS 1.4 Sagitta
sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

Thank you for pointing that out - updated defaults.json and it seems to have made that issue go away.
For some reason its now breaking on using our internal repo (no TLS there, inside the datacenter), but i suspect its got something to do with the repo itself or some change in Debian since we started using it.

Aug 6 2021, 8:54 PM · VyOS 1.4 Sagitta

Aug 2 2021

sempervictus added a comment to T3692: VyOS build failing due to repo.saltstack.com.

I've cleaned the build space and rebuilt the Docker container - no dice locally or in the CI stack, still fails the same way.
It looks like they're using an AWS CA in the cert chain:

Certificate chain
 0 s:CN = repo.saltstack.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority

i do recall the starfield certs being a problem back in the day as well, but guessing its quite unlikely for the base build environment to have an AWS root CA in its trusted list.

Aug 2 2021, 1:51 AM · VyOS 1.4 Sagitta

Jul 22 2021

sempervictus triaged T3692: VyOS build failing due to repo.saltstack.com as High priority.
Jul 22 2021, 1:14 AM · VyOS 1.4 Sagitta

Feb 3 2021

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

To round out the effort, i've added an optional patch to the series which provides granular AAA/RBAC from ring0 and can also deliver the W^X functionality for userspace along with those functions.

Feb 3 2021, 12:37 AM · VyOS 1.3 Equuleus (1.3.0)

Feb 2 2021

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

Since 5.10 appears to be holding solid, and grsecurity is using 5.10 for their beta branch, i've completed the forward port of these core functions to the same kernel revision being used in the current branch (at the time of commit).
Whats the intent with Intel drivers there? If we want to pull in from Intel, i think we ought to do the same in-tree patch process to build and sign the modules at build-time (and enforce module signing validation to load at runtime).

Feb 2 2021, 10:52 PM · VyOS 1.3 Equuleus (1.3.0)

Jan 23 2021

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

I've been refreshing the stack against current branch to keep testers building, and have added the FSGSBASE backport to 5.4 as a technical argument for keeping to a properly mature LTS even when users have a good case for needing newer functionality.
What is the plan of action for this effort, and is there a written policy on which kernels are selected and how they're selected for the OS? I can keep doing the rebase & push dance once a week or so, but is anyone on the VyOS team actually testing this stuff and has anyone upstream discussed the functional security benefits to users of GeoIP firewall filters or TARPIT/DELUDE/etc response actions separately from the system hardening functions inhere?

Jan 23 2021, 3:41 PM · VyOS 1.3 Equuleus (1.3.0)

Jan 11 2021

sempervictus added a comment to T3151: Decide on the final list of packages for 1.3.

systemd-container - easiest way to get containers rapidly into VyOS because all of the infrastructure (systemd) is already there.
We build our images with it, works fine.

Jan 11 2021, 4:01 PM · VyOS 1.3 Equuleus
sempervictus added a comment to T3167: Recurring bugs in Intel NIC drivers.

You might want to take a look at the patches in T228 - its a 5.4 build with a bunch of C fixup, but using the Intel proprietary drivers for an in-tree build (permits signing of all modules at kernel build time).
We have this running on a host with a dual-port 740 (not doing all that much, some routing, NAT, ACL, and a couple of OpenVPN and IPSEC tunnels), and it seems to be fairly happy in that low intensity environment.
I can try to beat up on it and see how it fares, but probably worth a try.

Jan 11 2021, 3:53 PM · VyOS 1.3 Equuleus

Dec 30 2020

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

I've added the two binary defense components oustanding:

Dec 30 2020, 5:51 PM · VyOS 1.3 Equuleus (1.3.0)

Dec 17 2020

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

So how are userspace packages for this sort of stuff handled? I assume we need to itemize out individual phabricator tickets?
Off the top of my head, relevant things to add to uspace would be:

  1. eoip binary
  2. eoip CLI wrapper
  3. Xtables userspace with GeoIP table data and updater script (we would need to figure out how to deal with rule placement for persistence)
  4. Xtables-related CLI for firewall matching on GeoIP, DNS, etc
  5. Xtables-related CLI for firewall actions to TARPIT or DELUDE
  6. UKSM userspace (or just wrappers for the sysfs interface in CLI)
  7. Hardened Malloc with system-wide LD_PRELOAD or maintain a vyos-specific libc package with it built-in
Dec 17 2020, 7:04 PM · VyOS 1.3 Equuleus (1.3.0)

Dec 14 2020

sempervictus updated the task description for T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.
Dec 14 2020, 6:51 PM · VyOS 1.3 Equuleus (1.3.0)

Dec 7 2020

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

Important note on this PR - in order to build the GCC plugins which perform most of the self-protection work, the Docker container needs gcc-8-plugin-dev installed. Otherwise it builds, but silently downgrades the configs dropping RANDSTRUCT/STACKLEAK silently.
Pulled RSBAC out for now (issues with building the rest while its in there but disabled), validated builds with and without the plugins package for GCC8.

Dec 7 2020, 6:37 AM · VyOS 1.3 Equuleus (1.3.0)
sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

Added an inert patch (disabled in Kconfig) for https://www.rsbac.org/ on 5.4. This can be used to significantly harden the restrictions intended by the CLI to limit users to specifically defined roles, same goes for applications/containers.
If adding container support to VyOS is still on the roadmap, we're going to want to take extra care to enforce the boundaries between them and the host since real world use cases are pretty much guaranteed to leave old vulnerable containers running on long-running network appliances making for a variable and worsening attack surface over time.
This isn't quite as integrated and doesnt provide nearly the coverage as what you get with grsec+pax, but a rough approximation of "role-based FS restrictions and runtime hardening" is now in the pull request along with the other stuff which seemed pertinent for upstream.

Dec 7 2020, 3:00 AM · VyOS 1.3 Equuleus (1.3.0)
sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

Thank you sir. Worked through a clean build, updated patches, rebased, and pushed.

Dec 7 2020, 2:44 AM · VyOS 1.3 Equuleus (1.3.0)

Nov 24 2020

sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

Created a GitHub PR against 5.4.78 with the core functions listed above, ixbe and QAT in-tree as well as wireguard (avoids the convoluted module builds and permits LTO/CFI passes)

Nov 24 2020, 4:40 PM · VyOS 1.3 Equuleus (1.3.0)

Sep 16 2020

sempervictus created T2888: Cloud-init images refuse to work with network-based datasource such as Ec2 or OpenStack (but do work with OpenStack's config drive).
Sep 16 2020, 2:34 PM · VyOS 1.3 Equuleus

Sep 15 2020

sempervictus claimed T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.
Sep 15 2020, 4:09 PM · VyOS 1.3 Equuleus (1.3.0)
sempervictus changed Difficulty level from unknown to hard on T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.
Sep 15 2020, 4:08 PM · VyOS 1.3 Equuleus (1.3.0)
sempervictus updated the task description for T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.
Sep 15 2020, 4:08 PM · VyOS 1.3 Equuleus (1.3.0)
sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.

While i appreciate that you have an opinion of what's "best," i'm not re-summarizing 10+y of Linux out-of-tree history to spoon feed someone data they can, and should (like good engineers do), acquire on their own. Several of those patches are simply in-tree integrations for things currently built and packaged as kmods by VyOS on an LTS tree, the rest are well documented long running projects of their own which one must research and review the source code for anyway to properly understand their function and benefit.

Sep 15 2020, 3:29 PM · VyOS 1.3 Equuleus (1.3.0)
sempervictus created T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.
Sep 15 2020, 1:39 PM · VyOS 1.3 Equuleus (1.3.0)