Best practice maintenance of untrusted netvm

[InfusingPrivacy]

Hi,

I've decided to gives Qubes a try. Apologies if I sound confused; there are many options and settings in Qubes and as a first-time user, I want to make sure I set Qubes up correctly. I have the following concern about the default netvm.

If the netvm is untrusted by default, I am making the assumption that the vm is, "out-of-the-box" easier to compromise than the other vms. So I was wondering what is the best practice for long term maintenance of the default netvm, immediately after a fresh install of Qubes?

1. Attempt to harden netvm before connecting to the internet (disable remote access, setup iptable rules, etc), then make a backup?

2. Do not harden; only backup netvm before connecting to internet. If I suspect that netvm is compromised in the future, simply stop netvm & restore from backup.

3. Some other best practice I did not think of.

(If choice #1 or 2 is best, I have a followup question)

Q1. Based on a post on 'theinvisiblethings' blog, netVMs are not the same as AppVMs. Since the backup/restore instructions on the qubes site (qvm-backup/qvm-backup-restore) is for AppVMs, how can I backup netvms for the purpose of restoring if/when they are compromised?

(If choice #1 is best)

1. Is there a guide on how we can harden the netvm? How can I view what default services, files, ports/remote access are enabled on the default netvm and how make my hardening customizations to the netvm permanent? I mainly want to make sure the netvm has no remote filesystem access from the internet (i.e. ssh, ftp, etc); the only 'access' should be from dom0.

Apologies if some of the questions are based on incomplete/incorrect information; I've tried reading all the Qubes documentation that could be related to my question such as:

https://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html
https://www.qubes-os.org/doc/firewall/
https://www.qubes-os.org/doc/backup-restore/
https://www.qubes-os.org/getting-started/

Thanks,
New Qubes OS user

[Jean-Philippe Ouellet]

On Mon, Mar 13, 2017 at 2:29 AM, InfusingPrivacy
<flashedm...@gmail.com> wrote:
> Hi,
>
> I've decided to gives Qubes a try. Apologies if I sound confused; there are many options and settings in Qubes and as a first-time user, I want to make sure I set Qubes up correctly. I have the following concern about the default netvm.
>
> If the netvm is untrusted by default, I am making the assumption that the vm is, "out-of-the-box" easier to compromise than the other vms. So I was wondering what is the best practice for long term maintenance of the default netvm, immediately after a fresh install of Qubes?
>
> 1. Attempt to harden netvm before connecting to the internet (disable remote access, setup iptable rules, etc), then make a backup?

There is no remote-access stuff enabled by default (no ssh, etc.), and
the default iptables INPUT and FORWARD chains end in DROP (no incoming
traffic is allowed by default).

> 2. Do not harden; only backup netvm before connecting to internet. If I suspect that netvm is compromised in the future, simply stop netvm & restore from backup.

You may.

You can also delete the VM and re-create it (set NetVM of sys-firewall
to none, delete sys-net, re-create based on whatever template, assign
network pci devs to it, restore netvm of sys-firewall, and might need
to restore ClockVM to new sys-net in global prefs too (not sure)).

> 3. Some other best practice I did not think of.

Yes, just don't worry too much about it ;)

It is considered untrusted precisely because you do not need to trust
it very much as long as you follow good practice with the VMs behind
it (generally assuming your traffic may be actively man-in-the-middled
regardless of where you are - by your ISP, the kid in the coffee shop,
or the attacker in sys-net).

> (If choice #1 or 2 is best, I have a followup question)
>
> Q1. Based on a post on 'theinvisiblethings' blog, netVMs are not the same as AppVMs. Since the backup/restore instructions on the qubes site (qvm-backup/qvm-backup-restore) is for AppVMs, how can I backup netvms for the purpose of restoring if/when they are compromised?

A legitimate confusion. Perhaps our docs could be more clear.

Backups work the same for any type of VM (AppVM, ProxyVM, NetVM, etc.).

The differences are mostly in what settings they are allowed to have,
what services are run by default, and what directory they are stored
in on disk.

> (If choice #1 is best)
>
> 1. Is there a guide on how we can harden the netvm? How can I view what default services, files, ports/remote access are enabled on the default netvm and how make my hardening customizations to the netvm permanent? I mainly want to make sure the netvm has no remote filesystem access from the internet (i.e. ssh, ftp, etc); the only 'access' should be from dom0.

You should do your firewalling, etc. in sys-firewall rather than
sys-net. This is because sys-net has a higher chance of being
compromised via vulnerable wireless card drivers or malicious wireless
card firmware, and you would not want that compromised sys-net to be
able to turn off your firewall! ;) This is the reason sys-firewall
exists as a separate domain behind it.

> Apologies if some of the questions are based on incomplete/incorrect information; I've tried reading all the Qubes documentation that could be related to my question such as:
>
> https://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html
> https://www.qubes-os.org/doc/firewall/
> https://www.qubes-os.org/doc/backup-restore/
> https://www.qubes-os.org/getting-started/
>
> Thanks,
> New Qubes OS user

Glad to have you with us!

[Jean-Philippe Ouellet]

On Mon, Mar 13, 2017 at 5:04 AM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> On Mon, Mar 13, 2017 at 2:29 AM, InfusingPrivacy <flashedm...@gmail.com> wrote:
>> 1. Is there a guide on how we can harden the netvm? How can I view what default services, files, ports/remote access are enabled on the default netvm and how make my hardening customizations to the netvm permanent? I mainly want to make sure the netvm has no remote filesystem access from the internet (i.e. ssh, ftp, etc); the only 'access' should be from dom0.
>
> You should do your firewalling, etc. in sys-firewall rather than
> sys-net. This is because sys-net has a higher chance of being
> compromised via vulnerable wireless card drivers or malicious wireless
> card firmware, and you would not want that compromised sys-net to be
> able to turn off your firewall! ;) This is the reason sys-firewall
> exists as a separate domain behind it.

Likewise, when you are running "high-risk" (complex) protocol parsers
(like tcpdump, wireshark, etc.), it is preferable to do so in sys-net
(or a cloned sys-net based on a template with such tools installed)
rather than sys-firewall, because it is desirable to protect
sys-firewall from such attack vectors.

[InfusingPrivacy]

Ok; thanks for all of the information! It was very helpful!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-03-13 02:04, Jean-Philippe Ouellet wrote:
> On Mon, Mar 13, 2017 at 2:29 AM, InfusingPrivacy
> <flashedm...@gmail.com> wrote:
>> Q1. Based on a post on 'theinvisiblethings' blog, netVMs are not
>> the same as AppVMs. Since the backup/restore instructions on the
>> qubes site (qvm-backup/qvm-backup-restore) is for AppVMs, how can
>> I backup netvms for the purpose of restoring if/when they are
>> compromised?
>
> A legitimate confusion. Perhaps our docs could be more clear.
>

Fixed.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYx0rXAAoJENtN07w5UDAwVsMP/12aG0Z/GXXbRVnvZHLC8apK
0AHKSNes4x6buTmnGWI3E9+kOYfdiEkTyk2PSNMhy2jWAuduMkwyLgg8dkwo5eaB
q/6+EWIDLfRIj3b4u1iP76KgQAOl7X9HohXeFoDx/1A2fFjRwooep//xuZ2R+k2B
ODf5XJmRVgYlNH88GCzDJwLCSyi2kYP/9r8RG/z5oF7iRie/VVfsV5grgxrQcFov
cG15LYZq26qMqcz/XIVDPW4UxBgFBJX6dU8iamwJXoD3glG8uA9JTJSGsHDeLt3j
XQEPAxDQzIb2GHNu9k+qRKhyZzWn6n+PX2MQ1Xon50Qt1nfsQGH28j96fP8kHvkD
dPyM/0QA62deLrBmwroezpleCsw6YRntbfaBPmqCeXYwKUGKrXjMct0YGSAPyRIn
2dUljlo2EL+dZILmLGDVRIfB2w3K2yygXoWM2vk4OkCEXlIG7p1/Uo5mC+YEisv4
ov9NytFYJ/lJ1CYfQ0V8gxHDuT+ZPHVStJJ6HlyxG9Pm+vm5YczddgDNeVR8TtEi
CTujQ9PqG3H8uDXPfUDXVuv8oTJ3wDqmvDyTkDyF5EY66D2e6jrUZCb+vl0H1S+E
sjV2CgYxqgmgkL8KFDKdMsmk5J9OFq4wHmQdy87nhu+nzZFbwqMpwQIymFvASRL0
iDFdDJadPH3QloDCbayX
=Mcvq
-----END PGP SIGNATURE-----

[Chris Laprise]

For clarification, the main reason netVMs are considered untrusted is
because of the NICs themselves. When a NIC is compromised, it can freely
take control of any part of the VM using DMA attacks. So there is no
point in hardening the system configuration in a netVM.

Its possible that firmware updates could harden the NIC itself against
attacks, so of course keeping your netVM template updated can help.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett