Has anybody tried creating a template or a Qube with a security distro like Security Onion and setting it up as a logging tool? Would this be a security risk?
I am also looking for this solution. Did you ever find a way to set it up?
If not, I’m thinking about attempting to build it myself using the instructions linked below.
I think it makes more sense to have it implemented as a mirageOS unikernel. For example, if you took the mirage-firewall as described in this tutorial → A Unikernel Firewall for QubesOS - Thomas Leonard's blog
and used Ocaml packages installed from the OPAM package manager, it could potentially be expanded into and entire IPS/IDS LibraryOS.
But you would need to port packages from C/C++/Python to OCaml.
Or you could maybe install a functional package manager like NixOS onto the mirageOS unikernel and
install firewall and network monitoring packages.
Interesting article, thanks for sharing.
I am aware of mirageOS and NixOS. They both seem promising and I am intrigued by the ideas you have mentioned for integrating with Qubes. Perhaps what you suggest will be a great option (particularly with respect to resource efficiency, smaller attack surface, etc.), but I think I still want a security-onion template for Qubes.
Do you agree with the author about this “likely” lateral movement between linux VMs (such as sys-net and sys-firewall)?
In the summary section he states :
"QubesOS provides a desktop environment made from multiple virtual machines, isolated using Xen. It runs the network drivers (which it doesn’t trust) in a Linux “NetVM”, which it assumes may be compromised, and places a “FirewallVM” between that and the VMs running user applications. This design is intended to protect users from malicious or buggy network drivers.
However, the Linux kernel code running in FirewallVM is written with the assumption that NetVM is trustworthy. It is fairly likely that a compromised NetVM could successfully attack FirewallVM. Since both FirewallVM and the client VMs all run Linux, it is likely that the same exploit would then allow the client VMs to be compromised too."
If lateral movement between VMs is “fairly likely”, wouldn’t this undermine most or all of the security features offered by Qubes?
I guess if its possible to compromise the sys-net VM and then use the vulnerable interVM protocol to
escalate privilege into another VM like the firewall-VM, and then use the same protocol to escalate privilege again, then there is a major fundamental security flaw in the concept. NetVM should be considered
as trusted VM like dom0 is. NetVM is susceptible to compromise and should also probably be replaced
by a MirageOS unikernel.
shouldn’t* be considered as trusted.
Building a template based on a MirageOS unikernel might be the best way.
Thanks for your input.
I was hoping to try out various firewalls and security tools as standalones before attempting to templatize one of them or convert to a mirageOS unikernel. I had an idea to try mixing hardware and virtual network adapters in an experimental security-VM, but I am having trouble testing it. It seems like passing through an ethernet adapter to a standalone qube is somehow making the VM unbootable. Installing works fine with no issues as long as no hardware is passed through. But once I pass any ethernet device through to the qube it will not boot. I get the following prompt:
"Boot failed: not a bootable disk
Booting from floppy…
Boot failed: could not read the boot disk
No bootable device."
This occurs whether I install the operating systems before or after passing the ethernet adapter through. So far I haven’t seen any obvious reason why this might be happening, and haven’t seen any posts on this topic in the forum. Perhaps a hardware compatibility issue?
Wondering if there are any significant advantages of any of the following configurations: hardware interfaces alone, virtual alone, or mixed?
A more in-depth guide on adding virtual interfaces to a VM would be useful…
You can use libvirt to change the hardware, the files you need are in /usr/share/qubes/templates/libvirt
https://dev.qubes-os.org/projects/core-admin/en/latest/libvirt.html
https://libvirt.org/formatdomain.html
I never figured out how to make a qube that provides networking and can bridge two networks using virtual interfaces, it requires more than just adding an extra interface to the qube, you need to understand how networking works in Qubes OS.
1 Like
you can attempt to create your own customized mirageOS unikernel by following this article:
you can deploy it by following this README:
1 Like
I’m surprised that using a network security qube to bridge two networks using virtual interfaces is not a common practice. One would think this should be the default option used by any Linux security professionals. How are people doing network security effectively on Qubes if not this way? It seems like the current mindset over-relies on compartmentalization where each compartment has almost no security whatsoever, virtually guaranteeing that any given compartment will be breached. Tediously separating activities into numerous unsecure qubes just to have them all breached separately seems like a foolish “Titanic” strategy. Waste of time and effort to build each compartment, false sense of security (“we don’t need as many life boats, because the ship is unsinkable”), and then the ship still sinks and everyone dies.
I was not aware that the netback/netfront being implemented as Linux kernel modules. This is a definite fundamental security issue in all of Qubes.
I would like to know what other kernel modules could be present in sys-net sys-firewall which allow for communication between VMs