How to restrict traffic through firewall, on a single cube, only to few particular sites?

The rules for my sys-firewall are:
all 443 TCP
all 80 TCP
all 53 UDP

I wanted to filter that further for a cube. So I tried:
site1 443 TCP
site2 443 TCP
all 53 UDP

I’ve used the firewall settings window for those cubes.

Does not work. Although some sites load (slower, unsure if anything within is broken), some does not.

What is the simplest solution for that?

You can use the firewall tab in the qubes settings, and you can use the qvm-firewall command in dom0

$ qvm-firewall VMNAME reset
$ qvm-firewall VMNAME del --rule-no 0
$ qvm-firewall VMNAME add accept dsthost="SITE1" dstports=443 proto=tcp
$ qvm-firewall VMNAME add accept dsthost="SITE2" dstports=443 proto=tcp
$ qvm-firewall VMNAME add accept specialtarget=dns
$ qvm-firewall VMNAME add drop

Then verify everything with

$ qvm-firewall VMNAME 
1 Like

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.
1 Like

Apparently it needs to be proto=tcp instead of proto=TCP. The capital letters gave me an error.

1 Like

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.

1 Like

I disagree.

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:

1 Like

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)

Do you mean something like:

qvm-firewall VMNAME del --rule-no RULE_NO

It’s easy enough to grep the rule number corresponding to the IP you want to remove.

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).


There’s many L7 options these days but, I bet OpenSnitch will be your buddy.

2 Likes

@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:

del sub.site1.com
add sub.site1.com
del sub.site2.com
add sub.site2.com

Ideally:
refresh sub.site1.com rule
refresh sub.site2.com rule

According to man qvm-firewall the only available actions are {add,del,list,reset}.

There is however a --reload option (force reload of rules even when unchanged). Not sure if that’ll do.

Thank you all for the answers.

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:

  1. 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.

  2. 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.

  3. 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).

1 Like
  1. 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.
2 Likes

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.

@balko

I have not seen such a site yet. The “worst” is one which changes IPs each system boot.

Is tinyproxy the only solution to that?

@tripleh

Do you refer to tinyproxy from this post:

If not, can you share? I’m rather newer user.

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.