Thanks for the insight about managing the tripwire function. I was slightly concerned it would make my dom0 unusable due to my lack of coding skills.
Yes, ultimately, I would like to build out a more robust working environment. But due to the political climate, it’s difficult.
About the threat and contingency modeling, I hazard to say, it was way to personal, which confirms my hypothesis. I suggest we stick to the original mission of the qubes project as opposed to digressing.
kind regards,
A post was merged into an existing topic: Help me setup AIDE and snort. IDS… Do you just unplug the VPN?
I disagree… If it’s open-source and foss and secure it will just notify the users of intruders in the OS. A warning if others hack you without your permission. An Qubes IDS system would be an exellent feature!
I strongly disagree with what you wrote.
Imagine a pop-up that says: Intruder. Or, system breach. Just an alarm or a notify.
Then you would at-least know.
If that would be possible to set up in Qubes, the OS would get way way better, and more secure then it is now by default.
A default VPN system with a killswitch already set up by default that just needs an .ovpn file would also be way better then now, where people need to set up a VPN every time they install Qubes.
That’s some constructive criticism for a better Qubes overall. Even if it’s good now as it is also, but it’s just a clean OS, without protection against hackers and other by default.
The vast majority of dom0’s attack surface is in the hypervisor and kernel. An attacker with access at that level will just kill off the IDS, so it doesn’t really help.
ok thanks. Is it easy to hack Qubes for some then? How do they do it… sending a file, or remote hacking? Got any smart hardening tips maybe to share… like changing the name of the os outwards so it does not look like qubes and so on?
10 things to do after installing Qubes…
Focus on learning how Qubes works and what protection it offers, rather than trying to ‘harden’ Qubes after you install it.
It is already a very robust platform, but you must first understand the concept of ‘security through compartmentalization’, and then understand how to use Qubes without working against it (transfer files from more trusted to less trusted qubes, how to attach USB’s, what Dom0 is and what NOT to do with it, why there is a sys-usb, sys-firewall, sys-net, how you should split your work/personal life up in to different Qubes that never speak to each other).
Start with learning about what is already there, and how to use it, rather than ways to improve it.
Intrustion Detectors in dom0: bad idea?
I think the effort by Purism to detect tampering from coreboot is worth mentioning here. It can scan the /boot partition before the OS starts.
To hack Qubes, i.e., dom0, you need to escape the hypervisor or perform a side channel attack. AFAIK, last time the former was achieved in 2006 by the Qubes founder. In other words, it’s extremely hard and unlikely. Concerning the latter, see also: Xen security advisory (XSA) tracker | Qubes OS and Qubes security bulletins (QSBs) | Qubes OS.
ok thanks. If you take let’s say pure os. That’s much easier right? Or a debian linux dist?
They have no dom0 so on there it’s hacked remotely or with a file easy then i assume. Thanks for the answer.
The last Xen vulnerability that I know to have been practically exploited was XSA-182. XSA-212 and XSA-213 were equally severe, but I am not aware of an exploit for them.
This doesn’t count, because
The vulnerability is only exposed to 64-bit PV guests. HVM guests and
32-bit PV guests can’t exploit the vulnerability.
Since then, Qubes switched to hardware virtualization which wasn’t affected.
Same as above. Those vulnerabilities are the reason Qubes switched to PVH by default AFAIK.
Also the same. Related discussion: qubes-secpack/QSBs/qsb-030-2017.txt at master · QubesOS/qubes-secpack · GitHub.
Hi, it would be interesting to have a “production” and “reference” dom0.
So if something “got hacked” or just failed utterly one can go to the reference side which is read-only in order to make the system running again or to be sure that nobody was able to install a backdoor for stealing credentials and secrets.
So a reference dom0 should be built by Qubes developers and signed, so called “factory settings” while a user should be able to produce user-reference dom0 systems which she holds trustworthy as she did not see signs of intrusion here.
Instead of installing some tools like “trip wire” that work after the fact, it is wiser to have means in order to prevent the fact!
So if something seems to be fishy, just go with the user-reference (signed by user), or the developers-reference (signed by developers) to copy it over to the production side while having successfully archived the old fishy active dom0 for later guru meditation on intrusion using all fancy intrusion detection tools.
Cheers,
luja
Hi all,
here is an interesting thesis that suggests to use an advanced IDS based on neural networks.
Such a thing could be included in a monitor VM that is connected to all the internal network traffic in cubes.
[ Deep Learning and Isolation Based Security for Intrusion Detection and Prevention in Grid Computing - CERN Document Server ||| CERN-THESIS-2018-441 Title Deep Learning and Isolation Based Security for Intrusion Detection and Prevention in Grid Computing]
Here it is suggested to detect intrusion in the big LHC computing grid [which could be used for crypto mining and massive hash table calculations.]
Here they learned normal scientific traffic and some malware traffic from known malware and were able to detect well better than 95%
As our traffic is more diverse than some experimental data gathered from esoteric sensors, I guess that the detection rates are worse in real world, but I think it is the best one can do, provided there are some computing resources left.
So as there are also light weight AI approaches for the embedded world, e.g. classification of cars, people and so on from video images, in a driver assistant system one could think about having some watchdog VM classifying the traffic in Qubes, and grabbing some metrics of /proc and /sys of the VMs so irregularities could be detected much better than if a guru sets up a snort.
The intrusion detection system of Gomez’ Thesis can be found here:
Maybe one wants to do a masters thesis using Qubes and the approach of Arhuaco…
Would it not be possible to couple any such tool with a blockchain that is run locally? A blockchain that need a hardware key to run, so any tampering will lead it to stop & hence trigger a warning.
At some point soon systems like that should be available, there are some for storing logs already but as far as I know they’re not running locally.
The problem is of course that no one would know if the providers of those IDS-es based on neural networks “get a visit” and a court order…
Intrusion and surveillance will then be included in the neural network itself!