Read some posts about SIEMs/IDS/IPS but nothing really that calls home if I could say.
I really haven’t found any real discussions on these things for Qubes and it something I want to do, not only for practice.
I am familiar with the different tools like, snort elastic stack, etc however how much I used them on their own is not much.
I am aware of Secuirty Onion, pretty cool but it not something you can get to work in Qubes virtually if can say as it wants to be assign to physical eth adapters.
With OPNsense I could go as far as setting it up however then begs the question of how do you access it dashboard it not on same IP range and gives its own IP, etc uncertain with Qubes as bit more complex.
Im looking for a helpful guide and suggestions to set a remotely possible and if anyone has been successfully doing so
I don’t really understand the question or what you want to achieve, sorry.
However, I can help here. You could use Qubes OS RPC call ConnectTCP which can allow a TCP port to be used by a qube to connect to another, so OPNsense web interface port could be access through its localhost over a vchan by another qube dedicated to OPNsense administration. This will not generate any network traffic other than on localhost.
Im trying to just get some or any already compiled SIEM system together like Opnsense to use for my Qubes system both for practice as well as for its main purpose.
From what Im seeing is you suggesting is to use a TCP port to allow access to the dahsboard from an admin vm(so say an appvm) to the standalone running the Opnsense locally?
Hi,
Thanks for the response. This seems only to log activity of vms, i.e creation delete, start & shutdown, etc?
If so then this isn’t what I am looking for based on topic but does look like a cool idea for other means of logging. My focus it on network traffic and the managing of it. I want a constant and effective overview.
Im looking for support and attempts of using an all in one networking solution like OSSEC, OPNsense, Onion Security, etc of easy management.
Perhaps my use of SIEM was a bit loose, however these days the use of the word naturally encumbers the expected IDS/IPS, firewall, logs ,etc. So yes OPNsense is a SIEM and or simpler term a firewall.(in my opinion)
If you have any suggestion or experience that is on topic it would be much appreciated.
Well my honest opinion is that people in the IT industry throw around bull**** terminologies like this all the time to confuse the general public, thus gaslighting their bosses into giving them a pay rise.
I mean, just look at the way Microsoft defines it:
SIEM, pronounced “sim,” combines both security information management (SIM) and security event management (SEM) into one security management system.
“So…SIM and SIEM are pronounced the same, and that doesn’t get confusing? Wow. You IT guys are lightyears ahead of us mere mortals…take my money!”
Although, to be fair, nobody would use “the cloud” if everyone called it “Gavin’s spare hard drives”
Anyway…
And you want this running inside of your Qubes OS machine, correct?
Alright. You’re looking for something that will:
Monitor the network traffic of all your qubes
Listen out for “potential threats”
This means either passively, or it’ll have something running inside each qube
Act on discovered threats
This means it’ll have to have something running inside each qube listening for commands from the master
I feel like you’ve basically just described the functions of sys-firewall, minus the command-issuing part.
I would be looking to see what you can install in there to augment the functionality of it to your needs.
Passive scanning will only get you so far, particularly if the qube is the one with the decryption key, and not sys-firewall…
The difficult thing about your solution is that so you can “set it and forget it”, most of these solutions require something to be installed in each qube (endpoint client), which may not exactly be ideal for your use case.
If you wanted to, you could definitely set up inter-qube communication via Xen’s vchans and qrexec, meaning that if one of your qubes got hijacked, mapping out your internal “network” (if you will) would be hard(er) than what most automated malware (and humans, for that matter) would be used to.
And if you wanted to go even further, you could even set yourself up some qrexec “Ask” policies that would force you, the user, to approve any proposed inter-qube changes as they happen. So if whatever you were running inside of sys-firewall wanted to do something, you had to approve it on a case-by-case basis, giving you more control.
This sounds like it’s much better-suited to run as a piece of physical network infrastructure, though. Unless your aim is that you can take it with you wherever you go, across networks…
I mean, you could if you wanted to, but wazuh is pretty much useless without the rootkits installed on the clients (they call them “Wazuh agents”). Not every rootkit is malicious, but they’re still rootkits.
It would be very different to, say, the Qubes OS implementation of SaltStack, which doesn’t require anything to be installed inside of the qubes…
Whether you choose to install those inside your qubes is a choice you’d have to make yourself, unfortunately.
My honest opinion is that these solutions seem to work very well when you have separate devices where the only avenue of communication between them is their NICs, but Qubes OS already has qrexec that is opaque to the qubes themselves, which is a more advantageous curve-ball you could throw at something that’s up to no good…
I’m also not particularly a fan of installing java and other “fancy components” inside sys-firewall, because they add more things that can break, misbehave, or be tricked into doing things they shouldn’t…
