Go back to topic: "getoutofmyla(w)n" template to block internal and external LAN access in qubesos
| update:updated for qubesos virtual dns servers. | 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. |
| > #qvm-firewall add accept 10.139.1.1 icmp
> #qvm-firewall add accept 10.139.1.1 specialtarget=dns
> #qvm-firewall add accept 10.139.1.2 icmp
> #qvm-firewall add accept 10.139.1.2 specialtarget=dns
> #qvm-firewall | > #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.139.1.0/24 |
| > #qvm-firewall add accept 10.139.1.1 icmp > #qvm-firewall add accept 10.139.1.1 specialtarget=dns > #qvm-firewall add accept 10.139.1.2 icmp > #qvm-firewall add accept 10.139.1.2 specialtarget=dns > #qvm-firewall add drop 10.139.0.0/8. | |
| 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. | 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. |
| 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 | 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. |
| > #qvm-firewall [VM-name] --reload> #qvm-firewall [VM-name] del --rule-no 0 | > #qvm-firewall [VM-name] --reload > #qvm-firewall [VM-name] del --rule-no 0 |
| SUPER IMPORTANT WARNING:If the LAN IPs are exposed to | 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. |
| 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. | 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. |
| > #qvm-firewall [VM-name] add drop 10.138.0.0/16> #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] add drop 10.138.0.0/16 > #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> #qvm-firewall [VM-name] del --rule-no 0> #qvm-firewall [VM-name] add accept 192.168.1.1 icmp | > #qvm-firewall [VM-name] --reload> #qvm-firewall [VM-name] del --rule-no 0 > #qvm-firewall [VM-name] add accept 192.168.1.1 icmp |
| ----------------------------------------------------- | -----------------------------------------------------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. The template below can be used to fix this. |