Application firewall

This does not satisfy all your requirements but is quite practical:

1 Like

Thanks, it adds filtering with URL but isn’t application-specific, and also (if i understand it correctly) require a separate proxyVM for each and every Domain/AppVM.

require a separate proxyVM for each and every Domain/AppVM.

No, you can use the same proxy for several VMs - the very same way as the qubes firewall works.
(this is alos true for my PoC ofc)

When using one ProxyVM to all AppVMs, how do I set a certain rule for Firefox in one AppVM but different rule for Firefox in a different AppVM ?
Also, how do I set one rule for Firefox and a different one for Thunderbird (both regarding HTTP access)?

You can identify your client VM by it’s internal IP address.
So you can prepare the rules accordingly.
Once a VM created it’s IP kind of static, see by:
qvm-ls --network

But, you just can’t make a difference by Appalications inside a VM.
Only if they are running in a different VM.

2 posts were split to a new topic: Setting up a ProxyVM (e.g. sys-vpn) to all other AppVMs

There should be an open source logging solution for qubes! An IDS (intrusion detection system) by default. That would make Qubes even better! Why would people not want to have an overview of the traffic in the same way as CPU or memory? They do want that.

1 Like

Yes, that would be nice. However, current app firewalls (if we are not speaking about reverse proxies aka WAF) are designed to protect Windows workstations, mostly. We do not even know what is “bad” for a Linux client. Also, there are no opensource implementations worth speaking of.

If we ever care about Windows guests, that would be nice, though.

I just did a quick search, didn’t even check quality or features, but I did get few different, seemingly relevant, Linux Application Firewall (see links blow)

1 Like

both are very outdated

There was a thread on application firewalls in the Forum predating this
one:

I was asked to evaluate application firewalls in Qubes.
If you want to try opensnitch, there are signed packages available from
the repositories at Index of /4.0 for Debian qubes, and
Index of /fedora.
Install the opensnitch packages in a Template, and you can try out a host
based application firewall. It will trigger on outgoing connections,
identify the application, and prompt for action.
You can also have the alerts aggregated on an upstream netvm, and have
that as the GUI. It’s a simple configuration: the documentation is good,
but I could help out if you are having problems.

It isn’t perfect - sometimes the GUI will trigger after the first
packet - but it’s the best ready made solution I found.
Another huge caveat is that (as with all host based solutions), you have
to remove passwordless root from the qube, otherwise an attacker could
easily kill the service.

Worth trying it out.

I know. looks like it died, was picked up by a single person, and as far as I can tell nothing has changed for more than a year. All in all, the project doesn’t look very much alive.

You are looking in the wrong place -

Indeed I was. My humble thanks for pointing to the right one.
So how would something like this work in our beloved Qubes-environment (multiple AppVMs reporting to a single GUI installed in a separate AppVM or maybe NetVM)?
I’m currently on 4.1 were Net-VM set to be disposable, so I’m guessing a static IP is somehow required?

Not sure if you’re asking but if you create a named disposable (using a disposable VM template), the IP address of the VM is stable. My VPN proxyVM is fully volatile and contains a firewall script that references the static IP.

Opensnitch would be good…Would that one be installed in sys-firewall?

it need to installed on every qubes (every template, hvm and standalone for more accurate)

1 Like

Ok, thanks.

And that is the reason they not really exists in practice.
Because you must believe that a ‘blessed code’ will going to detect the ‘evil’s code’, while booth running on the same permission levels :wink:

not totally imo, it exist, but not very effective

and if the firewall missed a “evil’s code”, it could disable the firewall itself, then calling even more “evil’s code”