In all of my time using QubesOS, I have never had reason to believe
that a qube was compromised. Has anyone here had a qube compromised?
Sincerely,
Demi
In all of my time using QubesOS, I have never had reason to believe
that a qube was compromised. Has anyone here had a qube compromised?
Sincerely,
Demi
I have had occasion to set a honeypot and use Qubes as a classic
Internet-inna-box - ideal for such use, and very instructive. But I
guess that wasn't what you were interested in.
In normal use, both myself and colleagues have seen compromised qubes.
Hi Unman
How did you know you're qube was compromised, can you give some details?
Seems like a good question, in that it goes to one of the ways I could shoot myself in the foot, and compromise all my security efforts.
I thought the point was, after each use of AppVM, close it and start another AppVM. That would make your question to be more like, if one of my AppVM Qubes was compromised, could it cause the compromise of any other Qube? Especially could the compromise effect Dom0 or a Template VM?
Or could, having an AppVM being compromised, could it effect modem-router that would be there after I powered off and back on computer?
I am not sure.
snort and tripwire.
Other IDS are available.
I run them on most of my Qubes installs, almost out of habit.
Because I salt my qubes, its relatively easy to run tripwire against
network connected qubes
But the way in which Qubes allows one to separate out activities really
does minimise risk. Example: read email in mutt in offline qube with
minimal template - any attachments are opened in offline disposableVM.
Anything I want to keep is transferred to an offline storage qube ,
again with no significant programs installed. In this sense, it doesn't
matter if attachments have malware because the infection risk is
minimised.
unman:
(Attachment 0xA664B90BD3BE59B3.asc is missing)
This warrants a much more detailed answer than I have time for now.
Tripwire - install in templates, store db in offline vault - I'm looking
for changes in /rw, as well as "normal" directory structures.
Mutt - varies according to provider. I set this up when I was first
playing with Qubes.
I use 3 qubes: one disposableVM to pick up mail - either offline imap or
rsync mail dirs. That qube is minimal, connects over Tor, and is restricted
to mail provider.
If the sync is in Mbox format, you can use mb2md to convert to Maildir
format.
The mail dirs are synced in to my mutt qube which is offline. I use
qrexec for this.
Mutt is a great MUA, and has good integration with PGP. I use split-gpg,
of course. I use notmuch integrated with mutt to keep on top of email.
For sending mails I use msmtp. Actually I queue outgoing in the Mutt
qube, and rsync the queues (over qrexec) in to a sender disposableVM,
which has outgoing traffic restricted to SMTP host. Over Tor of course.
So the fetch and send are done using disposableVMs, and the message
queues synced in and out of the offline mutt queue over qrexec. The
disposableVMs use minimal templates, have restricted network access,
and use different network routes.
The mutt qube is also based on a minimal template, and has a mailcap
that effectively loads almost all attachments in offline disposableVMs.
I have keyboard shortcuts to trigger the receive and send sides - I
suppose you could do this with cron jobs, but I prefer not to use
automatic processes.
That probably raises a few more questions. If it does, ask and I'll try to
provide some specifics.
unman:
unman:
This is interesting. Can you be more specific in regards of settings you
use? How do you set the tripwire for to run against network connected
qubes? You also mentioned using mutt in an offline qube. Can you
elaborate more on this too please? Is the mutt PGP friendly and more
safer option than Thunderbird?This warrants a much more detailed answer than I have time for now.
Tripwire - install in templates, store db in offline vault - I'm looking
for changes in /rw, as well as "normal" directory structures.Mutt - varies according to provider. I set this up when I was first
playing with Qubes.
I use 3 qubes: one disposableVM to pick up mail - either offline imap or
rsync mail dirs. That qube is minimal, connects over Tor, and is restricted
to mail provider.
If the sync is in Mbox format, you can use mb2md to convert to Maildir
format.
The mail dirs are synced in to my mutt qube which is offline. I use
qrexec for this.Mutt is a great MUA, and has good integration with PGP. I use split-gpg,
of course. I use notmuch integrated with mutt to keep on top of email.For sending mails I use msmtp. Actually I queue outgoing in the Mutt
qube, and rsync the queues (over qrexec) in to a sender disposableVM,
which has outgoing traffic restricted to SMTP host. Over Tor of course.So the fetch and send are done using disposableVMs, and the message
queues synced in and out of the offline mutt queue over qrexec. The
disposableVMs use minimal templates, have restricted network access,
and use different network routes.
The mutt qube is also based on a minimal template, and has a mailcap
that effectively loads almost all attachments in offline disposableVMs.
I have keyboard shortcuts to trigger the receive and send sides - I
suppose you could do this with cron jobs, but I prefer not to use
automatic processes.That probably raises a few more questions. If it does, ask and I'll try to
provide some specifics.
Dear Unman, thank you for your explanation. It is very interesting topic
and it could, if transformed into a guide, be a huge added value for
"Qubes hardening" section, or even Active Defense approach, in the Qubes
documentation.
I understand that every advanced user, like you, has his/her own custom
secure setup of Qubes and there is no Ring that rules them all. But for
the users that would like to move forward to a more active defense
approach, already present in the Qubes documentation, this would really
be very much enlightening. As if one opens the door to a new area and
move forward again.
Do you think it could be possible that you share with us the guide so
that we can move forward? There is so much to learn, and even if I
didn't manage to make run the vpn over tor yet, your setup seems very
interesting to try.
In all of my time using QubesOS, I have never had reason to believe
that a qube was compromised. Has anyone here had a qube compromised?
Hi!
Not quite what you are asking for, but I had this case more than once in tor browser:
Clicking on a link "Open in new Tab", the newly loaded page managed to close the _original_ tab (where I had clicked). I think this is absolutely hostile behavior, and I was glad that it was all in a disposable VM...
Regards,
Ulrich