Is it dangerous to turn Qubes firewall off?

[libvirt22283]

I installed a Debian template and installed penetration-testing tools such as Nikto, Acunetix, Nessus, SQLmap, etc.
I created an AppVM that uses this pentesting template.

Problems…

When using it to scan websites:

Without changing the firewall settings of this AppVM.

Do not use qvm-firewall; I am referring to the firewall rules inside the AppVM, which can be viewed with:

nft list ruleset

The rules are always the same for all AppVMs based on the Debian template; they are fixed for every AppVM generated from it.

Many scanners encountered problems during testing…

When I remove all the rules from the nftables firewall, the scanners work properly.

My diagnosis is that the firewall prevents the scanners from working and performing everything they need to do.
I tested this many times and reached this conclusion.

I need to know whether using an AppVM for pentesting while disabling all the firewall rules, as I did, is dangerous for the other Qubes in my Qubes OS?

Is it dangerous for sys-net, sys-firewall, sys-whonix and others qubes?

Do I lose security by disabling all the firewall rules for just one appvm?

The connection works normally, and the VM remains isolated, or does it become exposed and put at risk? Since it is a virtual machine, it should be isolated, right?

Unfortunately, to use certain vulnerability scanners and perhaps other pentesting tools, it may be necessary to disable some firewall rules or all of them.

[WhiteShadow]

Base on: Firewall — Qubes OS 4.3.1 documentation

In the following configuration:
pt-appvm <--> sys-firewall <---> sys-net

Firewall rules from sys-firewall affect pt-appvm, you can completely remove local firewall rules within pt-appvm itself.

@libvirt22283

I need to know whether using an AppVM for pentesting while disabling all the firewall rules, as I did, is dangerous for the other Qubes in my Qubes OS?

Is it dangerous for sys-net, sys-firewall, sys-whonix and others qubes?

Do I lose security by disabling all the firewall rules for just one appvm?

The connection works normally, and the VM remains isolated, or does it become exposed and put at risk? Since it is a virtual machine, it should be isolated, right?

• Use separated sys-firewall before your pt-appvm. another ideas: How to organize your qubes — Qubes OS 4.3.1 documentation
• Firewall policies configured locally in appvm have no impact on sys-* qubes.
• No. Read about networking in qubes
• If you have two appVMs connected to the same sys-firewall and you change firewall rules within sys-firewall, you risk compromising the second appVM.

@libvirt22283

Unfortunately, to use certain vulnerability scanners and perhaps other pentesting tools, it may be necessary to disable some firewall rules or all of them.

You can leverage QubesOS isolation here. Create separate logical connections based on dedicated qubes: sys-usb, sys-wifi, and sys-net.

sys-usb - hotspot via usb adapter/cable.

sys-wifi - any wifi connection.

sys-net - ethernet.

mail-appvm <--> sys-firewall <--> sys-net

pt-mobile-appvm <--> sys-firewall2 <--> sys-usb

pt-appvm <--> sys-firewall3 <--> sys-wifi

[qubist]

Many scanners encountered problems during testing…

As you may have noticed, the firewall is permissive in the output chain, so it should not hinder any traffic directed at an external host. You can add logging to examine what actually happens.

I need to know whether using an AppVM for pentesting while disabling all the firewall rules, as I did, is dangerous for the other Qubes in my Qubes OS?

It may be dangerous for the testing AppVM itself.

The connection works normally, and the VM remains isolated, or does it become exposed and put at risk?

If you flush all rules, you remove the input chain that has a default drop policy, thus allowing input traffic to the AppVM. If there is no service listening to a particular port, that may have no dangerous effect.

Since it is a virtual machine, it should be isolated, right?

The isolation has a different meaning, e.g. that the hypervisor does not allow qube A to meddle in the memory of qube B. If you connect one VM to another in a network, the two are obviously connected.

Unfortunately, to use certain vulnerability scanners and perhaps other pentesting tools, it may be necessary to disable some firewall rules or all of them.

You can create your own rules (or override existing ones) e.g. in a separate firewall qube as @WhiteShadow suggested.

[unman]

Many scanners encountered problems during testing…
When I remove all the rules from the nftables firewall, the scanners work properly.
My diagnosis is that the firewall prevents the scanners from working and performing everything they need to do.
I tested this many times and reached this conclusion.

Without knowing what tools you were trying to use, and what targets, and
how your pen-test qube is connected to the network, it’s hard to
comment. I would say that your “diagnosis” does not match my experience
in using a range of tools.

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