Hello!
I’d like to create a cube that only reaches the LAN network. Am i correct that what i need is a ProxyVM between my LAN AppVM and NetVM (sys-net)? Like the sys-firewall VM but limited by iptables only to the LAN network i’d like to reach?
Thanks any help!
Edit: I’d like to limit the Qube to just a specific subnet on my local network.
What exactly do you mean by “LAN” network? LAN as in Ethernet vs WiFi (or, as other languages would say, LAN vs WLAN, hence my question)?
Or LAN as in “just a specific subnet on my local network”?
If you want the former, I would suggest to create a dedicated NetVM only for your Ethernet controller (I could provide more details if that’s what you want).
If you want to limit your Qube to just a specific subnet there is no reason to create a specific proxy or firewallVM for each Qube. Luckily, that’s exactly what the Qubes firewall is for. In the Qube’s settings (accessible, e.g., via the “Qubes Manager” GUI application or via the Qubes launcher menu) you can specify unique firewall rules for each AppVM. These rules are enforced using the netVM for the specific Qube (so in a standard Qubes setup “sys-firewall” would make sure that the rules are applied to the traffic coming from your AppVM).
Due to this design, there is no way for the Qube itself to circumvent the rules, even if it would be compromised. Just create a rule that says "allow traffic to MY_LOCAL_SUBNET (e.g., 192.168.0.1/24) and make sure to check the option “Limit outgoing internet connections to…”.
Of you want more details, see The Qubes Firewall | Qubes OS
Related thread:
& @deeplow
Thanks for the answer! Sorry, i wasn’t clear enough! I’d just like to limit the Qube to just a specific subnet on my local network.
I tried the firewall in the settings of the Qube: i ticked “Limit outgoing internet connections to…” on the Firewall tab, and added my network: 192.168.0.0/24. Restarted the Qube, opened a Terminal and pinged gentoo.org and i was still able to ping the webpage. That’s why i thought i need a ProxyVM. But now i just checked the browser and everything is working as i wanted to. Does it mean that ping request is still enabled even the firewall is set to block everything but what i wrote in?
Quoting from the link I posted:
R4.0 note: ICMP and DNS are no longer accessible in the GUI, but can be changed via
qvm-firewalldescribed below.
So your AppVM can resolve gentoo.org because DNS is allowed and it can ping because that is done via the ICMP protocol. Both protocols could potentially allow an attacker to create a “tunnel” in order to exfiltrate traffic.
I suppose there is a good reason why the Qubes team removed these protocols from the firewall GUI but I honestly don’t know. I actually never really thought about that until now and it seems unexpected. Will need to manually adapt my firewall rules later in order to close these gaps which I think are indeed worth closing if you want to restrict a Qube to your local network.
Maybe someone with more knowledge about this detail can give feedback why that choice was made and if I overlooked something (there might even be some protection against tunnels in the firewall or netVM, I just wouldn’t know).
I will study the firewall documentation!
If you have figured out how to limit the ICMP and DNS protocols, could you please share it here or in a separate post? It is not too clear for me yet how to use the qvm-firewall command…
As for the reasoning behind keeping DNS and ICMP open via the GUI, I found this post by marmarta on GitHub. I can see that non-technical users would be caught off-guard if they would suddenly need to configure protocols they never even heard about. I still have mixed feelings about the current situation of the GUi firewall though.
Regarding the CLI approach it will take one or two days until I’m back at my Qubes system. It shouldn’t be too hard, but from the manpage for qvm-firewall I too find it a bit difficult to guess how a rule has to be specified exactly.
The key is to add your rules to the top of the FORWARD chain.
For example, add a script file to /rw/config/qubes-firewall.d directory:
#!/bin/sh
iptables -I FORWARD ! -s 192.168.0.0/24 -j DROP
iptables -I FORWARD ! -d 192.168.0.0/24 -j REJECT
Don’t forget to set ‘chmod +x’ on the file.
Using ‘REJECT’ for the second rule allows your VMs to see when they tried a forbidden address. But it could be changed to ‘DROP’ to block silently instead.
Note the above rules only limit/protect the AppVMs connected to the ProxyVM, not the ProxyVM itself. If you want to address that:
iptables -I INPUT ! -s 192.168.0.0/24 -j DROP
iptables -I OUTPUT ! -d 192.168.0.0/24 -j REJECT
Limiting by protocol:
iptables -I FORWARD -p icmp -j DROP
iptables -I FORWARD -p tcp --dport 53 -j DROP # DNS
iptables -t nat -F PR-QBS # Flush Qubes DNS DNAT table
You should also turn off IPv6 forwarding if your LAN uses only IPv4 addressing:
echo '0' > /proc/sys/net/ipv6/conf/all/forwarding
Quoting from the link I posted:
R4.0 note: ICMP and DNS are no longer accessible in the GUI, but can
be changed viaqvm-firewalldescribed below.So your AppVM can resolve gentoo.org because DNS is allowed and it can ping because that is done via the ICMP protocol. Both protocols could potentially allow an attacker to create a “tunnel” in order to exfiltrate traffic.
I suppose there is a good reason why the Qubes team removed these protocols from the firewall GUI but I honestly don’t know. I actually never really thought about that until now and it seems unexpected. Will need to
manually adapt my firewall rules later in order to close these gaps which
I think are indeed worth closing if you want to restrict a Qube to your local network.Maybe someone with more knowledge about this detail can give feedback why that choice was made and if I overlooked something (there might even be some protection against tunnels in the firewall or netVM, I just wouldn’t know).
I think it was for ease of use, but yes, it makes the firewall GUI rather
pointless for anyone doing things seriously.
qvm-firewall is fairly easy to use though.
Just always use --raw.
Show rules via
qvm-firewall --raw vm
Add rules via
qvm-firewall --raw vm add action=accept proto=tcp dsthost=abc.de dsports=123-124
etc.
Delete existing rules by
qvm-firewal --raw vm del action=accept proto=tcp dsthost=abc.de dsports=123-124
No problem. Just changed the title to reflect this.
@tasket I’ve added some markdown formatting to your post. Hope you don’t mind.
qvm-firewall is fairly easy to use though.
Just always use --raw.
One problem with this is that its specific to individual downstream VMs. Forgetting to run the qvm-firewall command again when a new VM is accessing the LAN proxy would leave it open to the Internet. It can provide something like blanket protection if its applied to the proxy VM instead, but the user will have to make sure the proxy is connecting through an upstream proxy (ex: sys-firewall). This will stop working if the upstream is changed to a network VM.
Configuring the proxy firewall internally (interestingly enough, via a facility called ‘qubes-firewall’) provides blanket protection.
Another problem with the (dom0) qubes-firewall is its limited to matching. Flushing a chain that’s enables DNS forwarding or using a filter module, for example, doesn’t appear to be supported. Also, --raw only works for the list command according to documentation.
Yeah, the manpage for qvm-firewall not too talkative unfortunately. Please share your solution if you’re ready with it!
Thanks!
So if i’d decide to go with the Proxy VM approach i should make these kind of iptables rules in the Proxy VM’s terminal? I’m not a too technical user regarding to linux (noob if i want to be clear) i’m only familiar with the UFW approach and more familiar with the pfSense firewall rules. With the “!” mark am i correct that the rules reject anything other than my local subnet? I will experiment with a Proxy Vm and trying to play with iptables and I will experiment with your recommended rules too.