"getoutofmyla(w)n" template to block internal and external LAN access in qubesos

Community Guides
1

-----------------------------------------------------getoutofmyla(w)n----------------------------------------------------------

LAN is an area where qubesos lacks at security and makes zero real promises. Qubesos using sys-firewall is good for protecting your appVMs. It is not bad and helps for sure but it is virtually useless for protecting your LANs. A pre-configured (in my opinion) firewall ruleset is also needed and this is where the qubesos lacks at honestly. Most novice users connect their devices automatically to LAN without running scripts and a pre-configured ruleset is necessary. However as a manual fix in the meanwhile the template below can be used to solve this problem. Once configured the firewall rules will remain active forever if not cot changed in some other way.

Internal LAN: The LAN within the qubes os system. The qubesos networking system is a LAN within a LAN, due to the existence of sys-firewall and sys-net type of netVMs.

External LAN: The LAN outside the qubes os system, between your device where the qubesos runs and other devices on the same LAN.

GO OFFLINE PRIOR TO EXECUTING THESE COMMANDS IF POSSIBLE AND UNCOMMENT THE LINES BELOW. THEY ARE KEPT COMMENTED TO PREVENT THEIR ACCIDENTAL EXECUTION.

#qvm-firewall [VM-name] reset [DO NOT RUN THIS COMMAND IF YOU HAVE RULES THAT YOU WANT TO PRESERVE.]
#qvm-firewall [VM-name] --reload
#qvm-firewall [VM-name] del --rule-no 0
#qvm-firewall [VM-name] add accept 192.168.1.1 icmp
#qvm-firewall [VM-name] add accept 192.168.1.1 specialtarget=dns
#qvm-firewall [VM-name] add drop 192.168.1.0/24
#qvm-firewall [VM-name] add accept [sys-firewall IP] icmp
#qvm-firewall [VM-name] add accept [sys-firewall IP] specialtarget=dns
#qvm-firewall [VM-name] add accept [sys-net IP] icmp
#qvm-firewall [VM-name] add accept [sys-net IP] specialtarget=dns
#qvm-firewall [VM-name] add accept 10.139.1.1 icmp
#qvm-firewall [VM-name] add accept 10.139.1.1 specialtarget=dns
#qvm-firewall [VM-name] add accept 10.139.1.2 icmp
#qvm-firewall [VM-name] add accept 10.139.1.2 specialtarget=dns
#qvm-firewall [VM-name] add drop 10.137.0.0/16.
#qvm-firewall [VM-name] add drop 10.138.0.0/16
#qvm-firewall [VM-name] add drop 10.139.1.0/24
#qvm-firewall [VM-name] add accept [IF YOU USE A FIREWALL TO BLOCK WEBSITES, DO NOT ADD THIS COMMAND IMMEDIATELY BUT INSTEAD ADD SUCH RULES PRIOR TO ADDING “add accept” COMMAND FINALLY.]
#qvm-firewall [VM-name] --reload

If you want a script-ed version of this though, you can bulk replace the VM-names and utilize ctrl+c + ctrl +v to create a text file.

After that you would run “chmod +x” with /path/to/name-of-the-script and then run the script. The script won’t require root.

PLEASE READ THE WARNINGS BELOW:Reboot ALL virtual machines for whom the firewall rules are changed for after the last command.

If possible also reboot all the VMs along the connection pathway. This includes sys-net too.Due to the way the qubesOS handles the connections, the network rules are enforced in the netVM of a qube what this means is that you have to apply the firewall rules ideally for all VMs that connect to the network whether directly or indirectly through a proxy that the qubesos labels a “netvm”. If this cannot be done, apply the rules at the most granular level. Instead of changing the rule of sys-firewall as an example, focus on individual appVMs.

REMEMBER: you are not changing the rules for the VM that you intend to, but rather for the netVM of that VM, because it is where they are actually enforced.

kali > sys-firewall > sys-net > router > modem > ISP > website (simplified)

In the simplified setup above, if rules are applied only for the sys-firewall with the kalivm unchanged (accept all postrouting/forwarded connections) then since the rules are enforced at the sys-net, there might exist a slight risk of kali being able to communicate with another machine (suppose an ubuntu) that also happens to connect to the sys-firewall. sys-firewall forward chain is set to drop in sys-firewall, but again i did not say that risk is huge, it honestly is minimal but i believe that it exists and this script blocks not only LAN but also access to the router too.

SUPER IMPORTANT WARNING:If the LAN IPs are exposed to an appVM even for once, you have to disconnect the VMs from their netvm, reset their rules & reload them and then shutdown/re-start or reboot the appVM. Ideally do this a few times just to be sure. Only after this is done you should apply the rules above. Because otherwise the rules may not apply for unknown reasons. sys-firewall’s default nftables chains show no “ct state established,related” kind of a command that may signal this with the policy accept. Postrouting chains are clear of such a flag even if it has a policy accept option. I personnaly don’t know why this happens.

update:updated for qubesos virtual dns servers.

qvm-firewall [VM-name] reset
qvm-firewall [VM-name] --reload
qvm-firewall [VM-name] del --rule-no 0
qvm-firewall [VM-name] add drop
qvm-firewall [VM-name] --reload

you can run the script above but keep in mind that it will break all network connections. you have to allow icmp and dns to sys-fw, sys-net, to virtual dns and the 192.168.1.1 (router address) to not break it. added this part because unman (naively) believes that the icmp/dns has to be blocked too, so if your belief is similar run the commands above but don’t be surprised when network connection is broken.

2

As a guide you should make it absolutely clear how people should
select and apply IP addresses for their own case.

Also, why are you allowing traffic to both sys-firewall and sys-net, and
some other address? This looks like a mistake. You can restrict dns
traffic to the Qubes proxy addresses - 10.139.1.1 and 10.139.1.2.

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

3

they can (ABSOLUTELY) look up to the IP addresses via the qube manager and replace the relevant values for selecting and applying IPs. why am I allowing dns traffic to the sys-firewall you ask, well because in my case I remember when the DNS traffic to sys-net and sys-fw was restricted it broke the network connection for me. you can restrict it via qvm-firewall [vm-name] add drop [sys-net ip] specialtarget=dns && qvm-firewall [vm-name] add drop [sys-fw ip] specialtarget=dns or issue del --rule-no x && del --rule-no y with x and y representing the numbers where sys-fw and sys-net are allowed for DNS. but you may have problems with the connection. Whoever used the script above should use the 2nd command for deleting the relevant rule. But network connection may break just like keep that in mind. Plus I think that it won’t be dangerous to allow dns requests.

also the sys-net and sys-firewall are not static, for every qubes os user their IP is different and I cannot say just use this IP so just use qube manager to check their IPs, this should be clear enough. sys-fw and sys-net IPs are available with ease there. that is how you apply the IPs.

hmmmm. true I missed that it seems virtual dns addresses should also be blocked. I generally blocked qube and LAN subnets, IP of stuff I could easily look up into. But now l updated it. my main concern was LAN but they 10.139.1.x subnet is also ought to be banned from non-dns access, yeah true.

this template does not prevent against advanced targeted attacks though, but nothing does I suppose then. also, this template perhaps as a script should come by default in qubesos. I prefer the template variant, it can be added to desktop as a text file that can be opened with the nano. i can prepare it as a script too, given you would place it at the desktop of the qubesos, though I like manual configurations like a template more.

Also LAN is an area that qubesos lacks significantly at to be honest. the protection of LAN should never be delegated as a task to the LAN devices but instead should be delegated to the devices from where the traffic originates from.