I look for option to active monitor and continuously secure my Qubes installation, with focus on sys-net qube and AppVM’s.
Same option I think about:
Have someone actual experience with run and maintain any IPS, IDS or another defense software in Qube to active protect and monitor Qubes?
Does anyone have an idea how to implement such solution without TPC/IP stack? (using build-in tools qrexec and salt in long run)
Previous discussion:
That would be so awesome!
Their last release of AI assistant sound cool, but it entire distro while I look for simple as possible integration to exist Qube installation.
But maybe we need Security onion template 
Another issue, Security onion absolute bare minimum requirements: Hardware Requirements — Security Onion Documentation 2.4 documentation - as Installation in Qube it most likely should be Standalone one that request 24GB RAM minimum.
thinking aloud
Deployment in dom0 isn’t an option.
Suricata -
Can function as IPS or IDS, and take a role of sys-firewall qube in order to save system resources.
Can be deployed in few copies as Named disposable based on one template and one disposable template can serve separated networks:
sys-net (Ethernet) → sys-suricata → sys-firewall
sys-wifi (Wifi module) → sys-suricata-wifi → sys-firewall2
and etc. and after vpn qube for example.
But such deployment is a black box, without real time monitoring.
Wazuh:
Deployment should be reachable via network stack from all qubes.
It break security module of Qubes
Wazuh salt ( GitHub - lassihi/Wazuh-salt-module: Salt module for Wazuh central components and clients. · GitHub ) compatible with qubes salt?
There was some discussion on a Qubes SOC a while ago. There’s also this SOC for Qubes I found a while ago. This one isn’t Qubes related but it’s a generic SOC home lab.
Maybe my post is a bit off topic, but since Suricata has already been mentioned, here is my setup:
Between my internet router and my Qubes OS PC I run a dedicated hardware firewall on a mini PC based on IPFire.
Suricata is already included there as an Intrusion Prevention System.
Advantages:
You have a point, but what about use case as:
sys-net ↔ sys-firewall ↔ sys-ecrypted-tunnel ↔ sys-suricata ↔ AppVM
We don’t want to open our encrypted tunnel (VPN, etc.) until he reach his destination.
This use case expects intrusion through the encrypted VPN tunnel, right?
Is this realistic for using a VPN provider?
Maybe for a private VPN. But why not do the IPS at the “exit” of the VPN to clearnet?
(Just thinking loudly)
Yea.
Even more then with selfhosted VPN, if it possible to request your data from VPN provider - what prevent APT from request disable IPS for your VPN channel?
thinking aloud
What if set collector as netvm for standard hvm’s: sys-net, sys-usb.
Does it can serve for monitoring?
By default, sys HVM’s shouldn’t have any netVM - such usage may result in any issue?
AI generated answers
- Network Topology: This usually requires a specific virtual network configuration in Xen to isolate management traffic from production traffic while allowing the necessary communication.
In case of QubesOS, we can consider console as management interface (qrexec, right?) and use only one network interface (TCP/IP). Right?
Wazuh
- Best For: Comprehensive SIEM/XDR with active response capabilities.
- Xen Integration: Runs well as a standard Linux VM (Ubuntu/RHEL).
- Interaction Protocol: Uses a custom TCP/UDP protocol (port 1514/1515) for agent-to-manager communication. It supports TLS encryption for this channel.
Security Onion
- Best For: Full Network Security Monitoring (NSM) + HIDS.
- Xen Integration: This is the trickiest option. Security Onion is a full distribution (based on Ubuntu) that includes Suricata, Zeek, Stenographer, and Wazuh.
- Constraint: To monitor network traffic effectively, Security Onion usually needs promiscuous mode access to the network interface.
- In Xen, this means the
sec-monVM must be attached to a Xen bridge withpromisc=1enabled, or you must use SR-IOV or PCI Passthrough to give it direct access to a physical NIC.- If you only want it to receive logs from other guests (HIDS), it works fine as a standard VM. If you want it to sniff traffic between guests, you need to configure the Xen networking to mirror traffic (SPAN port equivalent) to the security VM.
- Pros: All-in-one NSM solution.
- Cons: High resource usage; complex network setup in Xen for full visibility.
For Network Traffic Analysis: If you need to see packets flowing between guests, Security Onion is powerful, but you must configure Xen bridging with promiscuous mode or Port Mirroring to feed traffic to it. This adds complexity and potential performance overhead on the Xen host.
Xen-Specific Hardening
- Device Model Isolation: Ensure the security VM does not have unnecessary devices passed through.
- Dom0 Security: Since the security VM interacts with others, ensure
dom0is hardened. Ifdom0is compromised, the isolation is broken.- Resource Limits: Use Xen’s resource controls (
xl sched-creditorxl block-devices) to prevent a compromised security VM from starving other guests of CPU/Memory (Denial of Service).
End of AI generated data
While Qubes documentation leak of any information regrading such approach: Networking — Qubes OS Documentation
Can i relay fully on Xen documentation or QubesOS have unique settings for it?
I have a single out-of-line qube providing outbound intrusion (extrusion) detection using opensnitch nodes, qubes-opensnitch-pipes, and qubes.connectTCP. Unwanted connections are prevented in-line, but the management gui resides in a network isolated qube. I know opensnitch allows for 3rd party SIEM integration, but I haven’t tried any of these yet. Although a bit out of date atm, some of this is documented in a couple of community guides in the forum and does point out how one can employ qrexec with IPS. So not exactly “without TCP/IP”, but the connections are handled entirely with standard Qubes tools.
Purpose is to inspect ordinary TCP/IP traffic and activity on domU’s, I also don’t mean strick without TCP/IP implemention but not relay on it for server-client communication and management.
mTLS could be used for secure log collection, but XDR/SIEM solution as Wazuh in domU “sys-SIEM” became valuable as second dom0 and should be protected as much as possible.
One option more secure then direct full network connection, via RPC policy: