Well those who dont know Qubes os uses firewall to manage traffic from, to and through it. That firewall is called ‘nftables’ which governs the rules based on which the connection over the internet are made and accepted or rejected. Now to make those rules is a difficult part for the noobs like me. You need to have understanding of networking and all. So for the non tech users to be able to utilize their firewall. users with knowledge can share predefined nftable templates and in few words describe what it does. Or say if someone is willing to help and if someody post a request for a particular firewal rules in this thread, may help with a custom ruleset. Another thing that could be done is to paste your own ruleset with a brief discription for others to use it. What yall say?
what do you want to do? There are few reasons to manipulate nftables in Qubes OS.
Can you please elaborate what are those reasons. If those reasons help with security or ease of use with security then why not.
Be able to use firewall as it is intended to be and not only rely on the generic default firewall rulesets that comes by default with qubes OS
Qubes OS blocks all incoming traffic, so it is already secure.
Filtering outgoing traffic from a qube should be done using qvm-firewall in dom0 or the Firewall tab in the qube settings. These rules are done on the qube’s netvm, so they can’t be altered by the qube itself.
Reasons I can think of that requires fiddling with the firewall:
- killswitch for a VPN (but it is better to handle it with qvm-firewall as it does not depend on the qube itself)
- fixing MTU problems with VPNs
- doing NAT to redirect traffic from a qube to another
- open ports to allow two qubes to communicate directly to each other
@solene Sorry for jumping into this discussion after a long time. But I think few lines in this forum made to to start with this:: “Qubes OS blocks all incoming traffic, so it is already secure.”
I started using Qubes OS just few months back. initially I started using cloning “personal” and “work” app vm and keep logged into emails/ other online accounts permanently to avoid repeating entering user name and password again and again. One AppVM for one email account. So feels secure. Open all new website for any only search etc in untrusted clone vm.
But after few months I start feeling something is wrong.
So I reinstalled complete Qubes OS 4.3 recently and also used an external Openbsd router( with suricata and vpn). This time I only used dispVM only to login to any onine email account and enter username and password again and again.
After few days I saw “GPL ATTACK RESPONSE” in suricata fast.log on openbsd router. I also found that there were outgoing traffic to port 465 from my Qubes OS PC. Looks like the website/ or server I connected to was hacked and the hacker installed his command and control malware/ rootkit in to any dispVM and than sending stolen data packet through port 465.
So on my Openbsd router I blocked all IN/OUT ports except remote ports 53,80 and 443.
On further observation I found I saw such “GPL ATTACK RESPONSE” packets when I visit a specific well known privacy focused email service. Now I searched online about bad-ips and found that servers randomly can be hacked. So I downloaded bad-ips / malware ips list from github repos and added in Openbsd Router firewall. Now whenever I open that well known privacy focused email service I see log of an ip addresses being blocked in Openbsd firewall router. Now no “GPL ATTACK RESPONSE” alerts in suricata logs.
I wants to add three points:
(1) just blocking all incoming traffic, so it is already secure is not universally true.
(2) I struggle to implement similar structured blocking in Qubes firewallVM. I wants to have at least all unnecessary port outgoing traffic block so that same rule apply to all Appvm’s except whonix.
(3) if any hacker hacked into any persistent AppVM he can send outgoing packets to firewallVM and NetVM and the world is his own.
I think you are mistaken or unclear on many points, and so your post is
somewhat misleading.
I’m not clear which part you think is not universally true. By default
all qubes prohibit incoming traffic except for ICMP: this means NEW incoming
traffic. Responses to outgoing traffic are of course enabled.
It would help if you explained exactly what you want to do. If you want
to block everything outgoing except traffic to ports 80, 443, it’s trivial to do
this in the settings GUI on the firewall tab.
However, the GUI will continue to allow DNS and ICMP traffic. If you
want to block that:
qvm-firewall QUBE del --rule-no 0
qvm-firewall QUBE add proto=tcp dstports=80 accept
qvm-firewall QUBE add proto=tcp dstports=443 accept
qvm-firewall QUBE add drop
Once you have a firewall set for one qube, you can export the settings
to file:
qvm-firewall ---raw QUBE > firewall_settings
And then use those settings for other qubes:
cat firewall_settings | qubesd-query --fail -- dom0 admin.vm.firewall.Set
You can make the firewall as restrictive as you wish.
This is not true. By default qubes prohibit incoming traffic, so
although the attacker can send packets, they will not be accepted. The
attacker might be able to probe for weaknesses in the firewall or
networking stacks, or have an exploit using ICMP, or an attack that took
advantage in weaknesses in the allowed forwarding of traffic, but that
is a level above what you are suggesting.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I omitted the target. It should be
cat firewall_settings | qubesd-query --fail -- dom0 admin.vm.firewall.Set QUBE2
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I means to say the same default nftable rules were implemented and both netvm and firewallvm were disposable still when I accessed any website in any appvm and the website server is hacked the were able to hack my appVM/ web browser. So making connections to unwanted ports(illegal ports) should be dropped likeon dekstop and not using whonix I just need ports 53, 80 and 443. Because in my case I saw hacker was sending packets to port 465.
I will make a clone of fedora-42-xfce-template and use that for every other Appvm other then whonix(means appvm not using tor or required for whonix firewalling).
Now I wants to implement following nftable rules in fedora-42-xfce-template and those rules should implement in all Appvm based on fedora-42-xfce-template.
(1) Keep default nftable rules being minimum necessary required.
(2) block IN and OUT traffic from remote port NOT 53 or 80 or 443, any_other_port_if_needed.
(3) block IN and OUT traffic Where both side ports are 1025 to 65535.
(4) block IN and OUT traffic Where both side ports are 1 to 1024.
(5) block inbound traffic from ip_addreses in list /home/user/Downloads/inbound.txt (I used /home/user/Download because templateVM do not have direct access to internet and only /home/user/ is persistent in Appvm)
(6) block outbound traffic to ip_addreses in list /home/user/Downloads/outbound.txt
(7) a script in /rw/ that download and save inboun.txt and outbound.txt in /home/user/Downloads/
Once hacker installed his malware/ payload he can now by pass kernel or disable firewall temporarily without noticing or he can send. So I only use DisposableVM to connect to internet and FirewallVM and NetVM both are Disposable too.
This has nothing to do with your firewall. It means you are using
a vulnerable browser. A competent hacker would send packets to a well
known port and not draw attention to strange packets. Your proposed rules
would not affect this.
No they cant. They may affect the kernel used by the qube, but this will
be reloaded when the qubes is restarted. They may alter the qube’s own
nftables, but the Qubes firewall is implemented in dom0 and processed on
the upstream qube. To alter that they would have to make a jump from
the qube to the upstream qube or dom0 - not impossible, but a different
level of threat, and none of your “protections” would counter that.
I am not saying that hardening the Qubes firewall is a bad idea, it
isn’t, and I do it. But you should do so understanding how it is
implemented and what threats it can guard against.
Small mistake it’s – not — if we copy and paste your command we got this error
usage: qvm-firewall [--verbose] [--quiet] [--help] [--version] [--reload]
[--raw]
VMNAME {add,del,list,reset} ...
qvm-firewall: error: unrecognized arguments: ---raw
Anyway can someone explain me why
qvm-firewall sys-whonix del --rule-no 0
qvm-firewall sys-whonix add dsthost=127.0.0.1 accept
qvm-firewall sys-whonix add proto=tcp dstports=9051 accept
qvm-firewall sys-whonix add proto=tcp dstports=80 accept
qvm-firewall sys-whonix add proto=tcp dstports=443 accept
qvm-firewall sys-whonix add proto=tcp dstports=9050 accept
qvm-firewall sys-whonix add proto=tcp dstports=9051 accept
qvm-firewall sys-whonix add drop
is not working ? My goal is to route all traffic through tor i want to add a extra security
Misspoke. Thanks for correction.
Do not do this - Whonix is configured as it is for a reason. Messing
like this will break it and your security.
In this case you are allowing traffic from sys-whonix to ports
9050-9051 - 9051 twice. What’s the point in that?
You asked about configurations for “all Appvm based on
fedora-42-xfce-template”. If you had said you wanted to mess with
Whonix I would have tried to dissuade you and pointed you to the Whonix
Forums. Go there and explain what you want to do and listen to their
advice.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I thought it could provide extra safety
Ask in the Whonix forums.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.