RFC: Firewalling in Qubes

[David Shleifman]

Goal

Excerpt from the original post:

"I would like to limit my 'banking domain to be able to talk only to http://mybank.com.pl and nothing more. Currently this cannot be done in most cases reliably."

Workaround

Excerpt from the original post:

"What I do instead, currently, I just limit those domains to https traffic. That kind of sucks."

Alternative workaround

Steve Coleman proposed to

"I think the key here is to have a (semi)trusted way of doing a reverse
IP lookup via the authoritative server for that domain and matching that
IP to the proper DNS domain name rule. Once the DNS host information is
found to match a symbolic firewall rule then a dynamically added rule
could permit subnet access to that domain. But *only* for given
organizations which are semi-trusted and preconfigured for that VM.
(e.g. BANKING-VM:*.BANK.COM SURFING_VM:*.google.com
SHOPPING_VM:*.amazon.com )

This trust mechanism requires several things, mainly a way to know which
domains are allowed to be dynamically processed symbolically, and which
DNS authoritative servers can be trusted for that domain. One should not
believe just any DNS answer (e.g dns-anycast), and some form of DNS
configuration checking should be used to verify that these servers
appear to be legitimate and still configured properly."

Questions

It would be nice t know:

1. Has this proposal ever considered?

2. As a user of Qubes R3.1, what steps should I undertake to put this alternative workaround into the place?

[David Shleifman]

Goal

Excerpt from the original post:

"I would like to limit my 'banking domain to be able to talk only to http://mybank.com.pl and nothing more. Currently this cannot be done in most cases reliably."

Workaround

Excerpt from the original post:

"What I do instead, currently, I just limit those domains to https traffic. That kind of sucks."

Alternative workaround

Steve Coleman proposed:

"I think the key here is to have a (semi)trusted way of doing a reverse
IP lookup via the authoritative server for that domain and matching that
IP to the proper DNS domain name rule. Once the DNS host information is
found to match a symbolic firewall rule then a dynamically added rule
could permit subnet access to that domain. But *only* for given
organizations which are semi-trusted and preconfigured for that VM.
(e.g. BANKING-VM:*.BANK.COM SURFING_VM:*.google.com
SHOPPING_VM:*.amazon.com )

This trust mechanism requires several things, mainly a way to know which
domains are allowed to be dynamically processed symbolically, and which
DNS authoritative servers can be trusted for that domain. One should not
believe just any DNS answer (e.g dns-anycast), and some form of DNS
configuration checking should be used to verify that these servers
appear to be legitimate and still configured properly."

Questions

It would be nice to know:

1. Has this proposal ever been considered?

[7v5w7go9ub0o]

On 04/24/2016 06:50 PM, 'David Shleifman' via qubes-users wrote:
> Goal
> Excerpt from the original post:
> "I would like to limit my 'banking domain to be able to talk only to http://mybank.com.pl and nothing more. Currently this cannot be done in most cases reliably."

> WorkaroundExcerpt from the original post:

> "What I do instead, currently, I just limit those domains to https traffic. That kind of sucks."
>

> Alternative workaroundSteve Coleman proposed:

>
> "I think the key here is to have a (semi)trusted way of doing a reverse
> IP lookup via the authoritative server for that domain and matching that
> IP to the proper DNS domain name rule. Once the DNS host information is
> found to match a symbolic firewall rule then a dynamically added rule
> could permit subnet access to that domain. But *only* for given
> organizations which are semi-trusted and preconfigured for that VM.
> (e.g. BANKING-VM:*.BANK.COM SURFING_VM:*.google.com

> SHOPPING_VM:*.amazon.com )This trust mechanism requires several things, mainly a way to know which

> domains are allowed to be dynamically processed symbolically, and which
> DNS authoritative servers can be trusted for that domain. One should not
> believe just any DNS answer (e.g dns-anycast), and some form of DNS
> configuration checking should be used to verify that these servers
> appear to be legitimate and still configured properly."

> QuestionsIt would be nice to know:
> 1. Has this proposal ever been considered?2. As a user of Qubes R3.1, what steps should I undertake to put this alternative workaround into the place?
>

Another approach is to eliminate routine DNS for banking/business addresses:

1. Use host or dig (or some dnssec inquiry) to find out what the octet
address(es) is.

2. Add an iptables rule that blocks (and logs) connection attempts other
than that octet.

3. Add a bookmark to FF using that octet. (or ipv6 address and ip6tables).

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Using IP in browser address bar probably will not work as expected
because of HTTP details (Host: header). But setting that mapping in
/etc/hosts should work just fine.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXHSsYAAoJENuP0xzK19csOdUH/RicfZc3qZ89bfookjTCYp0w
leS42E+3elttn8+vZTkEcmASum959fUojK6G494mxpE3TcdRblxZCrLAk3ULubSe
xAGFVTQ+ERSvhBHCnET9dQKQBCIHugcL6kuGhKlsv/NQm4p+926c2nhLD9tsqR8o
OwKgYduD6iFHMmtMdaaIA+C+aV5hL5oxO2egTtwUsj9leRyKyHxNN4HcxMQ54WQG
YsIRwAg8eV/KWsSSpNCL4T4VPiOjCj7LJO+83o5yiytyI+uqDBzIx+PqeIgpFJy4
Od97MSgBJFiKfO9hgBg1STqw1BtLbVkiAYCwhy45qKw+VRDgqPfkXSj7zwGsI+I=
=rI8S
-----END PGP SIGNATURE-----

[David Shleifman]

Marek Marczykowski-Górecki wrote

"Using IP in browser address bar probably will not work as expected
because of HTTP details (Host: header). But setting that mapping in
/etc/hosts should work just fine."

I tried this approach in [untrusted] domain

a) [untrusted] GNOME terminal:

nslookup www.jpmorgan.com

returns 159.53.85.117

sudo vi /etc/hosts

inserted as the first line

159.53.85.117    www.jpmorgan.com

b) [Dom0] Qubes VM Manager : Settings : untrusted Firewall rules :

x Deny network access except

Address            Service  Protocol

159.53.85.117      any      any

c) [untrusted] Mozilla Firefox

URL: https://www.jpmorgan.com

result: web page loaded without problems  (as expected :)

URL: https://online.citi.com

result: Server not found    (as expected :)

I repeated the above steps for a different bank.  Result: got to the first page.  

In order to jump to the second page, user is expected to click the drop-down list and select "on-line banking" entry.  For some reason, the drop-down list doesn't behave that way.  Instead, it presents one entry only.

It looks like I need to allow an access to additional IP(s).  But I don't know which one.   I tried to figure it out based on

[untrusted] tcpdump  -e eth0 -nn -Q out -l | tee bank_outgoing_traffic.log

However, the only site 'bank_outgoing_traffic.log' points out is tiles-cloudfront.cdn.mozilla.net.  After executing steps a) b), and c) for this site, I am still not able to jump to the second page.  Further help will be greatly appreciated.

[Daniel Wilcox]

In Firefox open Tools > Web Developer > Network from the menu bar.  (if you don't have a menu bar right click where the menu bar should be and check the box)

Then reload the page and you'll see things that fail to load -- you should be able to figure out domains from there.

Sometimes just whitelisting the domains found is enough, but often times there are round robins so a single DNS query won't cut it.  You can use the WHOIS tool from ARIN to try and get netblocks for organizations, so you can block out more addresses that should be permitted, but many organizations don't have or need that many IPs or rely on a 3rd party's allocated IPs.

Another way is to query domains for TXT or SPF records to get their permitted netblocks -- although this only works if they run their mail servers roughly the same way the run their web servers (like Google does basically -- everything interchangeable and runnable from any of their locations).

Basically with big sites the problem is with CDNs (especially the big ones aka Akami) and I don't have a solution for you there.  The IPs used jump around a lot and aren't originating directly with what you want to be your trusted party (the bank in this case).  White-listing all of Amazon or Akami's IPs would be insane and not really help your attempt to lock down the appVMs access.

It would be really nice is organizations a) hosted all their own content and/or b) allowed access to all their authoritative DNS records aka zone transfer -- and of course both of those are crazy thoughts.  a) expensive and b) publishing a blueprint of their network.

Sorry I don't have many positives for you on this, I've tried many things and it is time consuming to set these appVMs up (when they even can be setup).  I have some other ideas but I'll write to the mailing list about it when I have some code working.

;D

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1282702487.1456481.1461537799195.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

[David Shleifman]

I turned on the traffic monitoring in [untrusted] domain using

sudo tcpdump -i eth0 udp and dst port 53 -Q out -nn

This revealed 6 other sites that the browser attempts to access. Then, I white listed 3 IP addresses (which I guessed to be most important). After this, I was able to jump to the 2-nd page.

I am thankful to Marek Marczykowski-Górecki and Daniel Wilcox for their valuable feedback.

 -D

----------------------------------------------------------------------

Daniel Wilcox wrote:

"In Firefox open Tools > Web Developer > Network from the menu bar.  (if you don't have a menu bar right click where the menu bar should be and check the box)"

Yes, this definitely simplifies the white listing.  tcpdump seems to be suitable for the applications that don't provide "Network" information like Firefox does.

----------------------------------------------------------------------

It would be nice to add to the Qubes documentation a section explaining HOW-TO configure the appVM Firewall.   There are 2 use cases:

1) user trusts DNS server provider.  In this case, user may add names to [Dom0] Qubes VM Manager : Settings : <domain> Firewall rules.  Behind the scene, these names get resolved and added to [sys-firewall] iptables. Next time, user decides to access the bank, he/she has to open [Dom0] Qubes VM Manager : Settings : <domain> Firewall rules and press "OK" button.  This will resolve the names (again) and refresh IPs in [sys-firewall] iptables.

2) user doesn't trusts DNS server provider.  In this case, user may add IPs to [Dom0] Qubes VM Manager : : Settings : <domain> Firewall rules. User will have to validate these IPs by some method.

In the later case, it would be nice to have an "assistant". This assistant will:

a) query several DNS servers and compare results. If results do not match, then it will return fail status; otherwise it will return success status.

b) Ideally, queries should use some encryption to avoid tampering.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I have a script to automate that looking at tcpdump output. It is meant
to run in an AppVM from where you try to access some site and it logs
all denials in nice qvm-firewall command syntax - ready to copy&paste to
allow that connection.

Usage:
sudo tcpdump -vni eth0 port 53 or icmp | perl ./firewall-learn.pl
Script itself:
https://gist.github.com/marmarek/1d0a296930b7784327aaf9a801ec5585

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXHdl3AAoJENuP0xzK19csuzAH/jH1XlGl1OjCU6aMdHNLVK3m
/sWWWwUbh9hyQI8Q+dbgHHfrW+sDEEMELCPA8OAo5Kn7i9Em2ntemfCAUUKQJD6Y
mA6hmWyQ2bsZ8xiPlg6PQNZWMOhTPMZT0EgDnt/xhV6b6kwHmaaq2jycoYgX6Go0
D8WsfKAswS4t+3Jp52KHxfwfj6X5DHF2aoAQstqNjdcPeZaI0Kbp+1pn3WshBQcz
mrFbKcdzDNxGEvTJcmRvZKR8JvKmlFm7j0iTETd9gmn92gx6cEdrApUEeU316sN9
POVWQNXPsb+EjhQ77MKxItC53RLCM4cb8yUTuzsNfQWxq5WMa/lXUtbZOTwMuIQ=
=NfYJ
-----END PGP SIGNATURE-----