Easiest way to substitute default firewall rules?

I find the default qubes’ firewall ruleset to be awkward at best and a security/privacy risk at worst*. I don’t really feel like arguing about the details and I think I do understand the decision to make the defaults what they are, but I find it really disappointing there doesn’t seem to be an easy way to change them. There are no config files from what I see, the defaults are ‘hardcoded’ (actually just some .sh files) included with qubes-core-agent-linux

So what would be the easiest (laziest?) way to provide my own default firewall rules? I was thinking about hooking some qubes functions if at all possible (on create, on apply settings etc.) and have a custom script call qvm-firewall and do sanity checks. This rubs me the wrong way because I’m playing catch up for one, and I can’t even modify all the rules I want (although this one can be worked around by using qrexec to call iptables directly instead of qvm-firewall) The other way would be having my own version of qubes-core-agent and to make sure it somehow ends up in every guest vm and survives every update etc. Definitely too much work.

So is there a better way in the middle that I’m just not seeing?

* - if you use Qubes to ensure a vm is forced through a vpn so it can’t learn your real IP address, make sure all your sys-nets and sys-firewalls and proxy-vms are configured “correctly” and then run an udp traceroute from the ‘isolated’ vm to your vpn server…

Did you have the chance to read this thread:

It might provide some insights.

1 Like

Hi and thank you for replying!

I have indeed found and read this thread yesterday, which unfortunately was few hours and couple of patches of hair too late, as I managed to figure out how it works on my own earlier that day. It took me embarrassingly long to do so I’ve go to say, mainly because I got thrown off by sys-* vms using both legacy and nft based iptables, which I thought was frowned upon - once I saw legacy iptables being in use I didn’t even think to check nft :frowning:

In any case I think I must’ve not been clear with my question: I am looking for either an officially supported way or a sane (sane-ish) kind of hack that would let me force qubes-core-agent to apply my own custom crafted firewall rules INSTEAD of the ones it comes built-in with. Ideally without having to maintain my own version of it.

I gave this thread another quick read and I can’t see anything there that would let me do that. I’d like for example:

  • to change the “-A INPUT -m conntrack --ctstate ESTABLISH,RELATED -j ACCEPT” to “–ctstate ESTABLISHED” only
  • to change “-P OUTPUT ACCEPT” to “-P OUTPUT DROP” (edit: I was very tired when I wrote this, it doesn’t really make sense to have it like this by default with how Qubes works, I’d still like to have it but you probably don’t)

If there is something in that thread that makes this possible my sleep deprived brain will be very grateful for pointing it out.

Long time ago I was suggested some modification in the firewall implementation to be able to achieve what you described: completely change/replace the default firewall rules… but it was not implemented at the end.

Still interested - but do not have the time to implement anything related to qubes-firewall :frowning:

What did you discover there?

Might be worth a bug report if there are any unexpected leaks.

Not sure what you mean by “unexpected leaks”? As far as I can tell the default firewall rules are being enforced, it’s just that I don’t really agree with the choice of those rules. I’d like either an option to change them or a workaround that’s more of a around and less of work.

Change the rules in the template, and they will apply in all qubes using
that template.
Otherise you need to build your own custom templates.
Undoubtedly the former is less work

1 Like

Do you mean by using qubes tools (gui or qvm-firewall)? In which case do you know how to do this:

No I mean edit the iptables rule in the template:
look, e.g, at /etc/qubes/iptables.rules etc

1 Like

This can work for some things, but the one I actually mentioned does not work like this. You can edit that file and remove all the “RELATED” ‘flags’ and all mentions of ICMP, and nft list ruleset still shows:

table ip qubes-firewall {
chain forward {
type filter hook forward priority 0; policy drop;
ct state established,related accept

and also adds

ip protocol icmp accept

to forwarding rules for every attached vm. Of course I can hook things to patch the rules every time they change, but it’d be so messy. I think what I asked for in OP is much more sane, just not sure if it could be done easily yet (ideally without rebuilding Qubes or sacrificing the security).

Ok, that is completely different from what you cited before and not
what you asked for.
You cited INPUT and OUTPUT, but now you refer to the qubes-firewall
table which governs forwarding on a netvm.
I’ll post further in the morning.

Been a busy day.

The nft tables are instantiated from

To change the default Qubes firewall settings, edit that file in the
template you are using for the firewall.
I strongly suggest you do not do this unless you understand python,
Linux firewalls, and the operation of Qubes networking. The potential
for mistake is large for very little gain.

Warning out of the way:
The qubes-firewall table is created with defaults at line 613.
To restrict forwarded traffic to ESTABLISHED, just edit line 621:
ct state established accept\n'

The individual firewall chains are hooked in that table, and are created
and maintained using the defaults in this file.
You can make changes here that will affect traffic to every qube
attached to a netvm that uses this template.

Remember that every qube also has its own firewall - I’ve already
covered changing the defaults there, by editing the template.
You can also used bind-dirs and /rw/config/rc.local to set new rules per
Combine this with the native Qubes tools (GUI and better qvm-firewall)
and you have great control over traffic to and from qubes.

There are tools that open ports and create arbitrary networking
connections between ports. I don’t approve those or condone their use -
like the vpn tools they just provide a fish.

1 Like

This is exactly what I was looking for, thank you for taking your time to write this.