It wasnt you that was wrong.
You do very well as is.
1 Like
the trip wire cli command seems very interesting. I wonder if I mess this up can I revert back to a previous version of dom0?
Recovering dom0, doesn’t seem that transparent, you have to copy all the files that are outside of the home/ folder nor are the installed configuration packages backed up. Unless, you copy them over to the home folder and reinstall those packages. (as least that’s what the documentation says.)
So, if you wanted to remove the current dom0 because (by some accident the trip wire wasn’t installed properly) how would you do it?
Subsequently, how would you install a previous version of dom0?
Do you delete first? then recover? And how would that work? Don’t you need dom0 to accomplish these functions?
I know, it’s seems odd, however, I want to make sure I don’t mess anything up without being able to reinstall dom0.
thanks,
Hi @Libertad,
installing and uninstalling software in dom0 (as long as it’s in the
official repository) can easily be done like this:
sudo qube-dom0-update tripwire
sudo dnf remove tripwire
Regarding “restoring” dom0: if you feel like you “messed up” dom0 or
it’s in any form compromised your only reliable way is to reinstall
Qubes OS from scratch.
If you have recent and verified backups of all your templates and qubes
that’s not really a big issue. But it could take many hours depending on
how much data it is.
Yes, the dom0 backup only contains your home directory. Think about it:
you feel you “messed up” so why would you want to restore that “messed
up” state? Instead you are starting with a clean, default dom0 and you
can then step by step redo the customization you want.
I safe copies of the config files I touch in dom0 within my home
directory for that purpose (e.g. the policy files I’ve touched).
My recommendation to you would be to try out and get familiar with
tripwire in a (fedora) qube. Then when you know what you are doing,
apply this knowledge to dom0. Your dom0 is not the place to do
experiments. Also an IDS is not a think you just install and then you
are “protected”. You have to monitor it and understand what it is
telling you. So there is no shortcut.
1 Like
Thanks for your suggestions. What I get from your answer is:
1st copy all config files if you are able.
2nd, place them in the home directory.
3rd backup.
4th, Revert back to a version of qubes which is verified and safe(which includes dom0).
However, what you are also saying it’s not impossible to swap out dom0s.
Obliviously, if I could, i would reinstall qubes, but In my case, It’s not an easy task…
It’s easier to delete dom0 and then reinstall a previous version and then add trip wire. But again, how would you do that? DomU perhaps?
the other question I have: is about the security updates? How are those managed with tripwire?
I’am not as experienced as you but I would really enjoy having a few extra machines and days in the week to experiment with dom0.
I can’t afford leaks or intrusions anymore, that’s why I like the concept of the trip wire.
thanks,
There was another thread talking about dealing with dom0 compromise -
there are no shortcuts here, if you really think your machine has been
attacked.
Depending on the nature of the attack, and your threat model, you may
need to start from scratch on another machine.
You should always be prepared for complete loss. (Not necessary due to
malicious intent - cat on the keyboard, bug on the motherboard, weather
event, solar flare, …)
If you can, it’s worth having a backup machine under lock and key that
you periodically sync with your live box. If you cant do this, have
everything ready (configuration, backups, data etc), so you can be up
and running as quickly as you can.
It’s worth thinking about, and prioritising, your qubes. If your main
machine becomes unavailable, what would you need immediately to be
able to get going again.
This is where sensible use of Qubes backup comes in - don’t blast
everything together. Break down your needs, and backup accordingly.
And remember, it is the data that counts - not the qubes. I would
always suggest having an encrypted backup of vital data alongside the
Qubes backup. If it comes to it, and you don’t have time/money to get a
new Qubes box up and running, you should still be able to access your
data quickly and easily.
On tripwire, Sven’s suggestion is good - you can practice in a qube, and
then transfer to dom0 when you are happy.
Tripwire monitors changes to your system, so it will record any changes
because of updates. If you scan before and after an update, you should
have a record of all changes made.
Keep in mind that many machines have a card reader that is attached to
dom0. You can store the tripwire binaries and configuration on an SD
card, as well as the tripwire database, if you will.
3 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
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.
1 Like
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
2 Likes
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…
2 Likes
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!