I’m assuming that you simplified things a little, otherwise
“some sites” does not make any sense.
Unfortunately, these days, connecting to one site usually involves
multiple connections to various other sites. It may well be that this is
your problem.
The only real solution for this is to examine the actual traffic that is
generated and to make sure that you are allowing all related traffic.
You might be surprised (and worried) by what you find.
This may be difficult for you. A simple approach might be to install
NoScript in your browser and set it to blocking mode. Then identify what
other sites are being targeted by your desired sites and allow them one
by one until you have a working site.
Another problem you likely face is that the Qubes firewall resolves
sites - if your chosen target has many potential IPs you will have to
allow them all.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Another problem you likely face is that the Qubes firewall resolves
sites - if your chosen target has many potential IPs you will have to
allow them all.
Can you elaborate on this a little? Wouldn’t allowing sites (including the ones we figure out using noscript) based on domain as shown in @BEBF738VD’s post be enough? What IPs should we be authorizing?
Any domain name that you add to your qvm-firewall is resolved at once and stored as IP address. Check it out in qvm-firewall output.
When the site changes IP keeping domain - nobody will notice, but your setup will not work (because IP is outdated).
Also websites make a lot of requests to third-party domains (cloudflare and etc), you can check it in ublock origin addon in Firefox. And those third-party domains will often have a lot of IPs and change them from time to time.
Long story short: your plan is not possible to implement easily nor reliably.
It’s quite an easy task to see which hosts a domain connects to and it’s fairly reliable once properly set up. I’ve had restricted VMs for a while now without issues.
Plus, one can always re-create the rules if the website is updated to make new requests, not an issue.
Long story short: this shouldn’t discourage users to harden their setups.
Thanks @fsflover, I was hoping for an alternative solution.
@BEBF738VD How did you achieve it? How to find which hosts a domain connects to?
@unman I checked generic websites like facebook, feedly, etc., so I can test. What I got is feedly connect without problems, facebook stop loading with fbcdn.net showing in the loading bar then just show plain non stylized text, other sites directly show me “Unable to connect”, like the ones not in the firewall settings.
This is due to what you mentioned, but I will quote a clearer explanation:
I tested for few days. Will post “solution” for that case, as alternative to the tinyproxy method. One little thing is left.
Some parts of some sites (coming from different source) are changing IPs too frequently. As address is taken once, I need to reset.
Is there an easy way with a command like qvm-firewall to take new IP or basic deleting and adding it again is how it works?
I’m intending to create a small script with qvm-firewall rules, for those frequently changing ones, which will execute on each boot. (if that pose a security risk, let me know)
Aside from the responses of @unman & @balko, I disagree with most posted. I could be wrong but, IMO you’re trying to use the wrong tool for the job which, more often than not leads to a poor job. Essentially you’re planning to fail.
I “think” what you are seeking is an application-layer aka L7 (Layer-7) firewall whereas ip/nfables are network-layer aka L3 (Layer-3).
@cayce
I wanted to restrict all the traffic of a particular cube to 1 or few websites. That is all, nothing more going in or out, ideally. By taking the most minimalistic approach possible. Which is using what I have at hand, the integrated cube firewall.
The only problem is that it resolves the domain to IP the first time, and if that changes does not work, as mentioned by few users.
@BEBF738VD
What I asked next was, if there is a something like:
qvm-run “refresh” rule no3 (which consists of allowing 443 to site1.com)
or the only way is to del and then add the rule again. Practically I was looking for 1 line of code instead of 2, per rule.
Example part of site1 and site2 does not work, so I automate with script at each boot:
I will mark this post as a solution. A sum up of all the info in the thread.
What I wanted:
A way to restrict all traffic in a qube to one or more websites. Possibly without anything additional (tinyproxy approach alternative).
Solution:
Using the firewall setting of each cube, created 443 rules for domain.com and www.domain.com. Note: You can use qvm-firewall. Use @BEBF738VD post as reference.
Using Firefox Network tab deduce what you need to allow additionally for the site to work, or at least the parts you need. Some need only the main domain. Note: You can use the proposed Ublock origin or NoScript. I find it unecessary.
Some of the domains may change IP occasionally. As the domains will be resolved only once, either resubmit the rules from the firewall settings or you can create a script using qvm-firewall to reset some of them each day automatically (not sure from security perspective is there is a concern).
Some domains (like cloudflare probably) can be resolved to different IPs each time you request, even being checked at the same moment, it’s a part of load balancing. So, even updating firewall rules every minute will not solve the issues with websites that use such CDNs, which are crucial as they host static images and styles.
Exactly.
That’s why DNS pinning or HTTP proxies are way superior, if one wants to do it properly. Posts on this very forum and on qubes-issues already covered either of these options. Searching is left to the interested reader.
If yes, as I mentioned it is an alternative. Don’t claim which is superior. It is more of what you are more comfortable with. And probably a more minimalistic approach.