Networking Questions

User Support General
,
1

Following up on some of these github discussions. restricting network access by default for disposable qube · Issue #8942 · QubesOS/qubes-issues · GitHub

I am interested in the following statement from the response

“except to save you a few minutes”

What configuration takes a few minutes to prevent anything on a local network communicating with a vm or vice versa?

As a new user I was under the impression that local network was already locked down and isolated (meaning devices on the same network can’t talk or compromise my qubes or qubes services). However, it appears to not be the case. If you could please identify what the contributor is talking about here and let users know what that solution is and how to implement it.

Assuming 4.2 and nft tables.

  1. How do you eliminate the threat of an external Lan device compromising your qubes VM’s or network qubes and vice versa. E.g., unsecure IoT devices, network printers, chromecast, smart home thing with 0 security etc.
  2. possible to do the above with firewall cli?

Example response I am hoping for:

From Dom0:

BLOCK INBOUND LAN COMMUNICATIONS TO external devices ON THE SAME LAN communicating with VM

$qvm-firewall <templatevmname> foo bar

^disabling all lan communications

THEN BLOCK OUTBOUND LAN COMMUNICATIONS TO EXTERNAL DEVICES ON THE SAME LAN. Use case: if a vm is already compromised (parrot os qube running hack the box ctf and pentesting etc).

If this involves identifying something e.g., you need to find this subnet <ip address, etc> would you also provide that information and how to correctly obtain it? I.e.,

Connect to wifi or ethernet

Run terminal command in Fedora/debian qube

[user@sys-net ~]$ ip a

Identify this number to obtain etc for firewall rule

Who this helps:

-users who donot set up vlans (on router pihole or otherwise)

-users who donot control the router they may connect to (friends house who loves “smart” things, coffee shop, hotel wifi, bed and breakfast etc)

-users who rarely ever need to use their lan for anything

-users with hacker roommates etc

The only drawbacks I can think of are you will eliminate your ability to print from that qube(s) (which you can’t do out of the box anyway https://github.com/QubesOS/qubes-core-agent-linux/pull/364 ) and you will eliminate your ability to change your routers settings(e.g., by connecting via an Ethernet cable you still wont be able to configure your router or login etc).

2

I think that the configuration would consist in blocking all access
to the local network. This could be done by a single additional rule in sys-net.

The default rules block all incoming traffic originating outwith the
Qubes system. They do not block access to the local network.

If the local network is 192.168.1.0/24, then a suitable rule would be -
ip daddr 192.168.1.0/24 drop
You could insert this rule in to the custom-forward chain in the qubes table in sys-net.
You could also add a new output chain, and use the same rule there.

Note that the scenario envisaged could apply to any server that is
accessed by different qubes, wherever it is situated.

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.
3

You need to clarify what you want to protect against…
Especially as you are mixing up basic terms like

What you mean by “locked down and isolated” in this context!?

The default Qubes settings are not allowing any incoming connections to your device. So even if your network is not trusted, you are ‘safe’ from direct attacks from such network.
And this is a reasonable default as most of the users are never needs to allow any direct connection to your workstation running Qubes OS.
But you can modify this - if you really want to:

And the “vice versa” is the key here, if we talking about network communications.

Because - obviously - outgoing packets are allowed by default. As without that you literally can’t do nothing with your Qubes OS.

And here you have the full control to decide if you want to limit outgoing connections from any of your virtual machines:

so saying ‘vica-versa’ in context of netwok comminucation is a very solid sign that you not really understand how network communications are working in practice, as outgoing vs incoming connections are a comletely different scenario, with different requirements and possibilities of control.

The github issue you have linked, however talking about one very specific use case about disposable VM’s. Moreover it is talking about if it’s should start without any network access, or not. And as we discussed this several times over the years, it is a very reasonable defult to have a network connection and allow any outgoing communications by default.

You can however very easily tune/modify this:

Also network acces of the template VM’s are another very different scenario, and it is implemented in a very secure way by default:

4

Just to clarify:

In sys-net’s template vm edit /rw/config/qubes-firewall-user-script

and add:

table inet qubes {
    chain custom-forward {
        type filter hook forward priority 0;
        ip daddr 192.168.1.0/24 drop
    }

    chain custom-output {
        type filter hook output priority 0;
        ip daddr 168.1.0/24 drop
    }
}

Result: All qubes using this sys-net will be blocked from accessing the LAN if they ultimately connect to sys-net via vm-htb > sys-firewall > sys-net but they should still be able to connect to the Internet.

5

Hi Zrubi,

I linked the wrong GitHub issue earlier (though it’s still related). I meant this one: Make it easy to block all private network access from VMs (and maybe make this default) · Issue #9796 · QubesOS/qubes-issues · GitHub

Thanks for clarifying — I now understand that inbound connections are blocked by default. I’ll run

nft list ruleset

in the service qube to see the actual default firewall rules and learn by doing.

Regarding your question:

“What do you mean by ‘locked down and isolated’ in this context?”

Now I mean that nothing from the vm-htb qube can reach devices on the same LAN (via outbound communication) that are not Qubes VMs. I see two ways to do this, one via sys-net which is an all encompassing rule and the second via individual qubes firewalls. I will try to do both of course.