I’m guessing that sys-net can sometimes connect in somewhere, and this can identify, if not using qubes, then using fedora, on which sys-net runs. There are various similar topics on the forum, but they do not reflect my need at all.
I can block traffic inside the sys-firewall with qvm-firewall and it works, at least in simple tests it has been confirmed. But qvm-firewall does not work for sys-net, I also tried to configure via NFT using Ai and of course nothing came of it.
Blocking traffic outside of sys-net, I think, doesn’t make sense because I don’t trust sys-net.
I don’t know how the fedora template is set up, and I have no desire to learn about it. I’m sure that most distributions connect to various services from time to time, and it’s easy to identify the distribution by such connections. There are other things that can be used to identify the use of linux, but it requires a lot of work, and the typical IP addresses that are typical of distributions do not require any analysis.
I also wonder why such simple things as Mac randomization are provided with sys-net out of the box, but there is no simple functionality to limit traffic in the main gateway. Logically, a compromise of sys-net will not provide anything to access VMs, but if sys-net is infected, the malware will be able to show not only my real ip, but also the model of the network adapter and send this data to any server. I think this is a huge flaw in Qubes.
If this is your threat model, you should use a middleware device between the physical network and qubes os, and this thing should force traffic over a VPN. You can’t rely on a software solution if you absolutely want to avoid leak.
I rely on a software solution, but whoever created this solution is not as paranoid as I am. The developers realized that dom0 should not be given direct access to the network, so why is sys-net not limited by some rules?
Compromise of one component can help compromise the next components of the system.
By default, sys-net has the same rules as any other running qube. All incoming packets are denied unless they were sent from there first.
sys-net forwards the traffic back to the originating qube that originally sent the request. If sys-net gets infected, it means it was a targeted attack and the IP leak would mean nothing since they already know where to go in the first place.
What exactly makes you stand out with your current setup?
What do you want to limit? Anything coming out of sys-net is something you have explicitly instanced (open application, background tasks…) or qubes related services like update check (can be disabled by adding qubes-update-check and unchecking it as a qube service) or clock updates (can be changed in Global Config). As I said in my previous comment, nothing can go into sys-net unless it’s a response to a request already made.
I want to restrict incoming/outgoing traffic and only allow to one IP. I don’t care what can get into sys-net, I care what can come out of it and where. sys-net itself can initiate a packet to some IP and this must be limited
yes, the update is done through tor, but the update check is still done from qubes and their netvm, so sys-firewall and sys-net will always do it over clearnet even if you put all other qubes behind sys-whonix or a VPN.
Terrible news for me. Is downloading updates less voluminous than checking for updates? What is the point of updating through the tor if the fact of connecting to qubes servers occurs regardless of the corresponding configuratio? I did not expect a greater stupidity from the developer, I am very disappointed.
Thanks for the link. Is it still impossible to limit traffic in sys-net?
I can’t give you a ruleset, it would require a lot of testing to guarantee it does the job.
It’s possible if you prevent sys-net from connecting to anything and only allow to relay the NAT connection, I think it’s doable. The same should be done in each netvm qube until you reach your vpn qube.
Checking for updates requires ~80 MB of traffic each time on fedora IIRC, the repository metadata are huge. The updates can be a lot smaller. The update check is just to tell you there is something to update.
Different threat models, it’s not possible to have a configuration that matches everyone’s needs. There is no piece of documentation mentioning that Qubes OS tries to hide you are using it.
I can understand this can be misleading if someone comes with expectations that does not match implementation reality.
It’s a pity that everything is uncertain, are there really no clear rules that would limit traffic.
80MB is not a problem, now the tor can give 100MBit, but still, when installing programs and surfing through the tor, gigabytes of traffic can pass through the whole day, I see no reason to rush.
Should I disable updates for templates or for each appvm?
If I disable updates for all VMs and disable update checking in Global Settings:
When manually checking for updates, will a connection via the clearnet be initiated?
When manually updating the via “apt update && apt upgrade” template, will a connection via the clearnet be initiated?
Welcome to networking Well, if you know exactly what you want to allow, it’s possible to write rules.
yes, and configure the updater, through the GUI, to try to update after n days (take something shorter or equal to weekly at least), in this case if a template was not updated since n days, Qubes OS will offer you to try to update the template directly, without checking if there is something to update first. This is the best approach.
I just want to specify one ip (or several) to which it is allowed to connect.
I also want to keep the ability to connect to other devices in the local network or allow access to qubes from the local network. By default, this works.
If point 2 is more complicated and can lead to errors, then it is better to completely block access except for one ip. But I also have a question about this.
3.1 If I create a sys-net clone or create any other appvm and connect a network adapter to it, will it rush to the network to check for updates?
3.2 Does the sys-net position in qubes play a role in checking for updates? The initiator of the check is dom0, but how does it determine which cube to check for updates through?
You did not answer the questions, or your “Yes” can be interpreted as both answers confirming that even with update checking disabled, a manual upgrade will lead to a traffic leak to the clearnet. Please specify
Well, if you know exactly what you want to allow, it’s possible to write rules.