Qubes firewall dom0->VM interface

[Marek Marczykowski-Górecki]

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

Hi all,

We want to somehow rework firewall ~~VM~~ qube interface in Qubes 4.0,
because the current implementation have some limitations. Some of us
already talked about it on 32c3, but I think it would be good to have
also input from others not present there. But first, some background
info:

Firewall purpose, goals
=======================
- prevent user mistakes, like opening links directly in mail ~~VM~~ qube
- mitigate software errors, like using http instead of https somewhere

Non-goals:
- ----------
- prevent compromised ~~VM~~ qube from leaking the data
- filter incoming traffic (technically it is also firewall task, but
not part of the interface discussed here, at least not directly)

Current features
================
- generally all that is available in VM firewall tab, so:
- default policy: accept / deny
- list of exceptions from that policy, for each entry it is possible to
specify:
- host or IP (optionally with netmask)
- protocol tcp, udp or "any"
- in case of tcp/udp - also port number
- separate option for allowing DNS traffic
- separate option for ICMP traffic
- "Allow connections to Updates Proxy"
- "Allow full acccess for X min"

Current implementation
======================
- firewall rules are converted to iptables script in dom0
- iptables scripts is saved to QubesDB of directly connected ProxyVM,
one entry for every VM (but all the rules as a single entry)
- there is /qubes-iptables-header - with some common header
- and /qubes-iptables-domainrules/<ID> - entry for rules for a given
VM
- qubes-firewall service in ProxyVM monitor QubesDB and apply the rules
when new are available
- all the special rules (ICMP/DNS/Updates Proxy) are embedded in that
iptables script, using addresses known to dom0 (for example Updates
Proxy has predefined address 10.137.255.254:8082)
- if there are any temporary rules ("Allow full access for ..."),
firewall reload is scheduled after that time, using systemd timer
(this part currently doesn't work reliable: #1173
- firewall rules in dom0 are saved in separate file firewall.xml, in VM
directory (this isn't part of the discussion here, just for
reference)

Limitations of current implementation
=====================================
- it is highly Linux/iptables specific, from VM point of view, hard to
use other implementations (*BSD, unikernels like MirageOS)
- hard to customize - if user want add non-standard rule, there is
/rw/config/qubes-firewall-user-script, but adding some rules in the
middle of FORWARD chain is hard (you can add at the beginning, but
it isn't always enough - #1183)
- finally, QubesDB has limit of 3kb for one entry - it means about 35
rules per VM (#1570)

Current proposal
================
- use a simple for rules in QubesDB
- convert the rules to iptables/whatever in ProxyVM
- integrate ICMP and DNS rules as standard rules, not a special case
- rule format proposal:
"allow/deny <target> <proto> [<port>]"
- allow/deny - should the connection to the target be allowed or
denied (somehow redundant to the default action)
- <target> - target IP address (possibly with netmask like "/22") or
name, or "*"
- <proto> - one of: tcp, udp, icmp, any
- in case of tcp/udp, there would be also <port> - a port number, or
"*"
- in QubesDB, save the rules as:
/qubes-firewall/<domain-ID>/default-action - "allow" or "deny"
/qubes-firewall/<domain-ID>/rules/XXX - actual rules, each as a
separate entry, where XXX is 3-digit rule number (so a maximum of
1000 rules)
- Linux specific: place rules for each VM into separate iptables chain,
to ease customizations (#974)
- convert updates proxy connection to qrexec service - see below

Questions
- ---------
- do we want to support port ranges?
- do we want any special treatment for DNS? The problem here is target
IP - dom0 may not know it (for example in case of custom VPN-provided
DNS - #1183). So I see two practical options:
- translate "Allow DNS" to a rule "allow * udp 53" + "allow * tcp 53"
- add a virtual protocol "DNS", which would be translated to
appropriate rule(s) by the ProxyVM (base on its /etc/resolv.conf,
or so)
* I think in the discussion on 32c3 we were for the first option
- anything else missing/wrong in the above proposal?


Details of qrexec-based updates proxy
- -------------------------------------

It would be socat/systemd.socket listening in TemplateVM on loopback
interface and package manager configured to connect to this address. As
a "backend" it would call qrexec-client-vm to initiate connection to
UpdateVM and connect to HTTP proxy there. UpdateVM still would have
tinyproxy to handle that traffic, the only changed part is underlying
connection transport - qrexec instead of TCP. But with such a small
change we get a lot of benefits:
- TemplateVM now may have no direct access to the network, which
eliminate the whole TCP/IP stack from attack vector (but still
leaving package manager - so some HTTP(S), which is admittedly more
concerning...)
- we can use any VM as a target here, using UpdateVM (the VM for dom0
updates) would be logical choice, but it may be different; this VM no
longer needs to on "network path between TemplateVM and the internet"
- no more problems with chaining proxies - like putting VPN VM, or
TorVM in between (which in the current implementation breaks the
connection in most cases)
- TemplateVM may even not know the name of target VM, thanks to ability
to redirect qrexec connection in policy (not sure if worth using it
in practice here)

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

iQEcBAEBCAAGBQJWl87xAAoJENuP0xzK19csijkH/jVjldwvPNFveWlAMULFlYgi
lBT/HESuDqBzXzm3pBDcKnwzDhhXHlVp6L6igJqEUpBe88hZp2hwvNeMntjvpqFa
c3XKUoFr66+1NYCl6+XpQmaFwmw6CX5LvhoxeEkDtcAKCRzwHaW3XytkkjZRHYus
mAAE5oI/zKPYplBeh9Si9NSnsyfIt/wOrjNjXsvUm9LhNkWRjKjuYApPLhbuECS3
ntWE3Sgs9fVvfJK9766Tm5KtiH35dR7m+vMd3X1cGV6CiXhLmOFwN46oRwMFpqgs
F/eOc/LJo+HGIjPAsnZXCb16N+doXF465Xc4L1ZDZbrTjhh0CjsOurV5Ipb+KMg=
=3QXO
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 01/14/2016 04:38 PM, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> We want to somehow rework firewall ~~VM~~ qube interface in Qubes 4.0,
> because the current implementation have some limitations. Some of us
> already talked about it on 32c3, but I think it would be good to have
> also input from others not present there. But first, some background
> info:
>
> Firewall purpose, goals
> =======================
> - prevent user mistakes, like opening links directly in mail ~~VM~~ qube
> - mitigate software errors, like using http instead of https somewhere
>
> Non-goals:

> ---------
> - do we want to support port ranges?
> - do we want any special treatment for DNS? The problem here is target
> IP - dom0 may not know it (for example in case of custom VPN-provided
> DNS - #1183). So I see two practical options:
> - translate "Allow DNS" to a rule "allow * udp 53" + "allow * tcp 53"
> - add a virtual protocol "DNS", which would be translated to
> appropriate rule(s) by the ProxyVM (base on its /etc/resolv.conf,
> or so)
> * I think in the discussion on 32c3 we were for the first option
> - anything else missing/wrong in the above proposal?
>
>
> Details of qrexec-based updates proxy

> -------------------------------------
>
> It would be socat/systemd.socket listening in TemplateVM on loopback
> interface and package manager configured to connect to this address. As
> a "backend" it would call qrexec-client-vm to initiate connection to
> UpdateVM and connect to HTTP proxy there. UpdateVM still would have
> tinyproxy to handle that traffic, the only changed part is underlying
> connection transport - qrexec instead of TCP. But with such a small
> change we get a lot of benefits:
> - TemplateVM now may have no direct access to the network, which
> eliminate the whole TCP/IP stack from attack vector (but still
> leaving package manager - so some HTTP(S), which is admittedly more
> concerning...)
> - we can use any VM as a target here, using UpdateVM (the VM for dom0
> updates) would be logical choice, but it may be different; this VM no
> longer needs to on "network path between TemplateVM and the internet"
> - no more problems with chaining proxies - like putting VPN VM, or
> TorVM in between (which in the current implementation breaks the
> connection in most cases)
> - TemplateVM may even not know the name of target VM, thanks to ability
> to redirect qrexec connection in policy (not sure if worth using it
> in practice here)
>

This sounds really good. Please contemplate some of our needs -- in
some cases we like to set rules up to allow *incoming* traffic to an
AppVM, whether by port forwarding or by giving the AppVM a proper subnet
IP. Accordingly, allow/deny may not be enough.


--
Rudd-O
http://rudd-o.com/

[Marek Marczykowski-Górecki]

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

Actually we have an idea for that, to do that similary to qrexec-based
updates proxy. But keep this thread about the outgoing filtering.

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

iQEcBAEBCAAGBQJWmFMhAAoJENuP0xzK19csKJgH/RgUCw1RlNQbJ+IY8Fp4x6pa
lFX1Z1uXnA8x+w3S2Vfvfb86iKNnQCOpIOse02A1LFBmLc9FT3MagdaHis7nyEmH
yMgU4X/fOieAaPoXOCvjm5i/6dc5PXSu+5E7cZRAXYEd8DfXsGnfn6Ut3fO2JgI5
w/O6ypiSNea9kVm+Cz+5lqSbFx9MVjEbZZwl9R+zlquuPul8IP82gXKc3QU+Yu0J
Di6wIUqsw9rdlm6oXt6zoYOUmnMXRW34dWTqyPpNuoYOojkdoHIBv6DGtvofP8Ky
3n474je6ZiMQGLtVgLVUXWslaPwE+rttUq1uIxAryl2TsczkhV2cgJ4KEu/iW+I=
=AgVv
-----END PGP SIGNATURE-----

[C.L. Martinez]

Only one question, why not to use a *BSD/PF based vm instead to use a
linux/iptables based xen image??.

PF filtering rules are more flexible (and more powerfull, IMO) than
iptables and maybe you can define more rules per vm than with actual
proxy-vm. And you can use a lot options like divert-to, rdr-to, etc...
that simplifies a lot of work ...

IMO, the best option will be OpenBSD, but there is a big problem:
OpenBSD performance under xen is horrible (and it doesn't seems that
this will be change soon). Better option will be a FreeBSD xen based image.

[Zrubi]

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

On 01/14/2016 04:38 PM, Marek Marczykowski-Górecki wrote:

> Firewall purpose, goals ======================= - prevent user
> mistakes, like opening links directly in mail ~~VM~~ qube -
> mitigate software errors, like using http instead of https
> somewhere

If this these are the only goals - then we should not bother at all.

At least this is not emphasize the REAL benefits of the qubes internal
network topology and the purpose of separate VMs:
AppVM->Firewall->Net



* "prevent user mistakes, like opening links directly in mail ~~VM~~ qub
e"

It is not just about user mistakes - instead SAVE the user from:
- - being a victim of pishing
- - loading unwanted content (such as ads, images from untrusted sources)
- - opening bad/untrusted links
- - help preventing/detecting bad programs to 'call home'
- - able to log all the outgoing traffic !!!

And the most important: these are still true even if the AppVM are
compromised/untrusted. Because the rules are defined in Dom0, and
implemented in the firewallvm insted of the AppVM itself.

So this is a way better solution than any of the local firewall
solutions out there. We should emphasize this.


* "mitigate software errors, like using http instead of https somewhere"

This 'goal' can never be achieved with a firewall. Because our
firewall is just a simple packet filter. Do not even able to
distinguish http from https.
(only by the used TCP port number - but that is really misleading)




> Questions --------- - do we want to support port ranges?

Would be really helpful.

> - do we want any special treatment for DNS? The problem here is
> target IP - dom0 may not know it (for example in case of custom
> VPN-provided DNS - #1183). So I see two practical options: -
> translate "Allow DNS" to a rule "allow * udp 53" + "allow * tcp
> 53"

That's fine.

But allow DNS (without the dst address) in general is not the best
thing. So we should at least separate the real 'allow dns traffic'
from the current default 'hijacking the DNS packets' solution...



- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIbBAEBCAAGBQJWmNeSAAoJEC3TtYFBiXSvzPYP92Qpln4v2Hc7+9SWuL6HewPI
wX9XmN+zARL4Vn8PVgL0MqlcgHquWU8o8NMyL8AOcsTpf7dwaGKxJ57J1nz+ZUMi
uuOPSYYcSlIvYfbItkHxtpIUL6dyw7fRQvKIFs32a/5duRkE2wxyfql5qGt5vrpS
YeZgMkrjF/3ReyNk0DpX71NXrmnydomT2nNknsvlYbXRTgkXG/AjBsQpaL9hqMSV
q8jLQjnfbqy9JIeaAbwY39r6mOlzS9ozq4pe19lNphxJPIFOOYCb8XnYG1KcpfoE
NvarMDtfwP5L0dop6kJntHds9R81zT7St+QrHa8RhccwEIYX5bT+ME0SiCEGzNMi
Ogp9n6xttocUju73qqFALcJEs3X80+24/DtYmFqrgqGQsY7PLj7+3s/0gRG0UMU2
3Px1bQuSQ5/aGj6zqt5CT0JdB8Gswnd84fixlN91FlhrnJO/EpkCJAmefPj7fcp5
qK8UyrrvQrcrzDJnM3Ellc0mrO/33aPTc8yYqRY6BWcJOmV5CdFOAJwBY4HAxUnn
//8rjrUKEzterEKS9vgYwWdPGWwY7CLtflOIAgDQovRWtdG2Ft1AGn8z4+/SUAhR
j+ax7SkpPu7osUKOU0H1Rm4WG/ukkGKma3zsB9ClhKoJl90o0V3/eZjskrCbe1cF
dISNcG2PijUVYlgmFKI=
=sUzG
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

This discussion is exactly to ease integration of different firewall
implementations, not be focused on Linux/iptables only.

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

iQEcBAEBCAAGBQJWmXnyAAoJENuP0xzK19csb9sH/jqANmqnmHG9Wm7gtK7afzAs
sVqoK/1mvDrICmsrvDAZULOjV8EnHTKiT9EQx/0F5q1AlIxnnPghkLiWBRaEXgkl
WjFVF3o4MN39ePKE+fL3gUP6x2U32ck0xPH1V93BxeaL7kin0TidhjlkA6UEtwL8
UNxfea7t3q5G37bI0KrecCU7NaM/2nmTyC/bpnjl6dETCeIcweDKEM3YcU/UwEOe
LyTzKXCWB5GGJP9j07jBfeRzhV52aNM9iFIO9CrBe/QgO6erFtXqLvsCgoZxy+Lv
vXXrfncSp2MKQZKKP07v/dkMODLqaIoAuxX4h3MGfxyXfAQHWSu1lJzx6+8OJ7g=
=wWy5
-----END PGP SIGNATURE-----

[Black Consult]

On 01/16/2016 12:00 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Fri, Jan 15, 2016 at 07:27:54AM +0000, C.L. Martinez wrote:
>> On 01/15/2016 02:02 AM, Marek Marczykowski-Górecki wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On Fri, Jan 15, 2016 at 12:35:11AM +0000, Manuel Amador (Rudd-O) wrote:
>>>> On 01/14/2016 04:38 PM, Marek Marczykowski-Górecki wrote:
>>>>> Hi all,
>>>>>
>>>>> We want to somehow rework firewall ~~VM~~ qube interface in Qubes 4.0,
>>>>> because the current implementation have some limitations. Some of us
>>>>> already talked about it on 32c3, but I think it would be good to have
>>>>> also input from others not present there. But first, some background
>>>>> info:
>>>>>
>>>>> Firewall purpose, goals
>>>>> =======================
>>>>> - prevent user mistakes, like opening links directly in mail ~~VM~~ qube
>>>>> - mitigate software errors, like using http instead of https somewhere
>>>>>
>>>>> Non-goals:
>>>>> ----------
>>>>> - prevent compromised ~~VM~~ qube from leaking the data
>>>>> - filter incoming traffic (technically it is also firewall task, but
>>>>> not part of the interface discussed here, at least not directly)

Okay, you are talking about the firewall interface, but i like to talk
also about some functionality. It's a open discussion right...? I have
some thoughts that could add extra layers of security. I know there a
lot of visions and tastes of different products, but eventually we want
all the same right?

I think that a firewall task is also to filter and/block incoming
traffic in a clever way. Personal i like the BSD style and have good
results, with implementations like in Pfsense/OpnSense. With some extra
functionality like a IDS/IPS implementation in the backend of the
FirewallVM, that could warn the user for malicious traffic and block
this traffic. Think about actually attacks, but also unaware malware ad
banners etc. I know snort/suricata is for 'normal' use in networks, but
why not give the user these benefits and give more insight in what's
going on the wire. This could raise the awareness of potential malicious
traffic and give more control to the end user.

Also an implementation of malware ip address block lists could add some
more security, for example like the PfBlocker or similar.

To run a own DNS server, that does the DNS queries to the rootservers
could maybe prevent DNS spoofing or other attacks and give personal a
more free feeling, than to use a ISP or logged DNS servers. There are
some other options, like DNSCrypt that uses OpenDNS, but haven't tried
that yet.

As i said, just some thoughts and what i am personal missing in Qubes. I
am aware that the core developers, maybe have other visions for good
reasons that i don't know, but it's a open discussion right...?

--
Have a nice weekend...

Rudy

[Danny Fullerton]

On Friday, 15 January 2016, C.L. Martinez <carlo...@gmail.com> wrote:

> Only one question, why not to use a *BSD/PF based vm instead to use a linux/iptables based xen image??.
>
> PF filtering rules are more flexible (and more powerfull, IMO) than iptables and maybe you can define more rules per vm than with actual proxy-vm. And you can use a lot options like divert-to, rdr-to, etc... that simplifies a lot of work ...
>
> IMO, the best option will be OpenBSD, but there is a big problem: OpenBSD performance under xen is horrible (and it doesn't seems that this will be change soon). Better option will be a FreeBSD xen based image.

This is about to change. OpenBSD current just got support for XEN. Someone said OpenBSD template? See http://undeadly.org/cgi?action=article&sid=20160114113445

What do you think about npf, the NetBSD firewall? I'm about to release a PoC of a rumprun unikernel running npf - a full fledge firewall with a familiar syntax (PF/IPFW).

More info in the blog post.

--
Danny Fullerton
Mantor Organization

[Danny Fullerton]

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

- --
Danny Fullerton
Mantor Organization

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWmpmNAAoJELaIPX0bl6J0AAEP/RL2TDMsQSPaD8zYZEAKpkT7B6KEGcCqWfMK
x1BxzaicRlCGj7bavF9Cic1RrV0+CoR/lSJzbLqjiQtiiYGJii6BMtoDEDLbuG3bFBZ+aINd7RXy
YkRJMp50rBjcZsfFOSgkT8bdYuXtBQ2oQYInt0mZPWeI/mzuLZooDSRWmVeFG6IsfD5LwPCKo9LN
TrBx/7peNslJxMJ0Zn0BgbYCJyYStTVJitYe8zFxB69yO09fSdJMf9rCMw2qjFvJznxp9p/k/v1s
zGo5SFUq3L2IwyaUXEU+KkZi8Q15SgOkM/jylZDSimVZUoxHZWxTksEYN/buEtxr/VjJ4/MNaUTM
dV2NGpHCDvD3D+TVpfoO90f2qR0d78jezVPRM7QBt3vCr4SP5Qe6UrRBe/nMhvDp8dbeEGh6KbwN
E/AeDLnJgCYR+dGWlXaaIEWCMQOq0pI+Xqu/gfp6wUtRt5M58lV0MdgkXFW+a7JBkx4dDc03boST
gcDG9s7osRL61kYdZh9Zofqtmlh5tDFn/b96NgoA11X1ev/XjGpk5/uqiyXEfB/YTF8k82kref5r
H9JtGQ+IxRgwFg1zDWgCbycvVahm5N0EzHUzXXQ+SRQ1/TyKVfV5sAWPwvgMn2ginUfKsOMU0R23
doQl/xxg6eoQksTnUOIXwYWfzWNyyvn/nkT+rfop
=5Y+N
-----END PGP SIGNATURE-----

[Derek Fawcus]

On Sat, Jan 16, 2016 at 03:04:15PM -0500, Danny Fullerton wrote:
> OpenBSD current just got support for XEN. Someone said OpenBSD template?
> See http://undeadly.org/cgi?action=article&sid=20160114113445
>
> What do you think about npf, the NetBSD firewall?

It is quite capable.

> I'm about to release a PoC of a rumprun unikernel running npf - a
> full fledge firewall with a familiar syntax (PF/IPFW).

I'd be interested in that, especially if it was compilable w/o too
many dependancies.

DF

[tal...@gmail.com]

Seems reasonable.

 

Details of qrexec-based updates proxy
- -------------------------------------

It would be socat/systemd.socket listening in TemplateVM on loopback
interface and package manager configured to connect to this address. As
a "backend" it would call qrexec-client-vm to initiate connection to
UpdateVM and connect to HTTP proxy there. UpdateVM still would have
tinyproxy to handle that traffic, the only changed part is underlying
connection transport - qrexec instead of TCP.

UpdateVM sounds like maybe it could be a unikernel too...
 

[Marek Marczykowski-Górecki]

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

On Sun, Feb 07, 2016 at 02:39:09PM -0800, tal...@gmail.com wrote:
>
>
> On Thursday, January 14, 2016 at 4:38:22 PM UTC, Marek Marczykowski-Górecki
> wrote:

(...)

> > Details of qrexec-based updates proxy
> > - -------------------------------------
> >
> > It would be socat/systemd.socket listening in TemplateVM on loopback
> > interface and package manager configured to connect to this address. As
> > a "backend" it would call qrexec-client-vm to initiate connection to
> > UpdateVM and connect to HTTP proxy there. UpdateVM still would have
> > tinyproxy to handle that traffic, the only changed part is underlying
> > connection transport - qrexec instead of TCP.
>
>
> UpdateVM sounds like maybe it could be a unikernel too...

UpdateVM (will) have two purposes:
- HTTP proxy (the case discussed here)
- downloading dom0 updates - which involve dependency resolving,
parsing yum repository metadata etc.

While the first one is probably good idea to handle using unikernel, the
second one not that easy. But it may be two separate VMs.

> > But with such a small
> > change we get a lot of benefits:
> > - TemplateVM now may have no direct access to the network, which
> > eliminate the whole TCP/IP stack from attack vector (but still
> > leaving package manager - so some HTTP(S), which is admittedly more
> > concerning...)
> > - we can use any VM as a target here, using UpdateVM (the VM for dom0
> > updates) would be logical choice, but it may be different; this VM no
> > longer needs to on "network path between TemplateVM and the internet"
> > - no more problems with chaining proxies - like putting VPN VM, or
> > TorVM in between (which in the current implementation breaks the
> > connection in most cases)
> > - TemplateVM may even not know the name of target VM, thanks to ability
> > to redirect qrexec connection in policy (not sure if worth using it
> > in practice here)


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

iQEcBAEBCAAGBQJWt9KXAAoJENuP0xzK19csZYYH/1/xMiSzaUeRia6yQINQ6t0j
NBkWP1olhuT2PQ18SSPNAJUCDTezDEnycQxj4c1tpC57bTbqhnBXVawjBc0isBh4
WmUZAzNubIAn8iiMHTH7TQusYzcIZtWme1BsqZ8D8TCq+hG/nHOHRtidcxU7bJVa
s88z13R+USDiDQmsewRZDCnhwY4FohThBIXC5ou4FfGQQdbfqFNi6Rqoe0e4UhF5
tfBbOoQE/biHUs348jYrSNx55ONxBLRATpxGgtsDDTe6KuRwi+xAyQszYR51fIS7
XF+tU43wdRlMe/XkCOXT76oUAsDeYCVEwj33/KQiljPBj41PYoUecVeavWGY0/w=
=GE3S
-----END PGP SIGNATURE-----

[Chris Laprise]

On 01/14/2016 11:38 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> We want to somehow rework firewall ~~VM~~ qube interface in Qubes 4.0,
> because the current implementation have some limitations. Some of us
> already talked about it on 32c3, but I think it would be good to have
> also input from others not present there. But first, some background
> info:
>

Hi Marek,

My suggestion for future Qubes firewall:

Qubes currently allows /piecemeal/ control of firewalls for individual
appvms. It would improve Qubes' usability if we could control certain
features of internal proxyvm firewall from the proxyvm settings dialog.
This adds an element of /generalized/ control to networking without
having to edit internal firewall scripts.

VPNs in particular suffer from leaks with the default configuration, and
the user impulse is to add (somewhat ineffective) rules to each and
every appvm that uses the proxyvm. This is a perennial, nagging issue
and design flaw in Qubes. Proxyvms should have a UI section to block
forwarding to particular virtual interfaces, for instance; This would
allow a user to stop leaks reliably with one setting.

Chris

[Mindy]

Hi folks,

By way of introduction, I'm the author of `mirage-nat`, on which some of
Thomas Leonard's MirageOS firewall work is based. I've been a Qubes
user for a couple of months, but haven't dived deeply into the internals
yet (although I've been lurking on qubes-devel for some time). Among
other things, I have previously implemented schemes for translating
firewall rules from an abstracted JSON syntax to iptables invocations,
unfortunately in closed-source land.

Responses to the request for comments are inline.

On 01/14/2016 04:38 PM, Marek Marczykowski-Górecki wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> We want to somehow rework firewall ~~VM~~ qube interface in Qubes 4.0,
> because the current implementation have some limitations. Some of us
> already talked about it on 32c3, but I think it would be good to have
> also input from others not present there. But first, some background
> info:
>
> Firewall purpose, goals
> =======================
> - prevent user mistakes, like opening links directly in mail ~~VM~~ qube
> - mitigate software errors, like using http instead of https somewhere
>
> Non-goals:
> - ----------
> - prevent compromised ~~VM~~ qube from leaking the data
> - filter incoming traffic (technically it is also firewall task, but
> not part of the interface discussed here, at least not directly)

Is filtering incoming traffic considered to be out-of-scope because it's
assumed that this functionality is provided automatically by the common
IPv4-and-NAT setup for VMs in Qubes? If so, it may be worth considering
whether an environment with directly-addressable IPv6 VMs would suddenly
be more vulnerable because of design decisions made here.

I appreciate this summary as someone new to Qubes. Thank you!

>
> Limitations of current implementation
> =====================================
> - it is highly Linux/iptables specific, from VM point of view, hard to
> use other implementations (*BSD, unikernels like MirageOS)
> - hard to customize - if user want add non-standard rule, there is
> /rw/config/qubes-firewall-user-script, but adding some rules in the
> middle of FORWARD chain is hard (you can add at the beginning, but
> it isn't always enough - #1183)
> - finally, QubesDB has limit of 3kb for one entry - it means about 35
> rules per VM (#1570)
>
> Current proposal
> ================
> - use a simple for rules in QubesDB

Just to be sure, "use a simple for rules in QubesDB" means "use a simple
specification for rules in QubesDB" or some such, right?

> - convert the rules to iptables/whatever in ProxyVM

This seems quite reasonable to me.

> - integrate ICMP and DNS rules as standard rules, not a special case

See comments about DNS below.

> - rule format proposal:
> "allow/deny <target> <proto> [<port>]"
> - allow/deny - should the connection to the target be allowed or
> denied (somehow redundant to the default action)
> - <target> - target IP address (possibly with netmask like "/22") or
> name, or "*"
> - <proto> - one of: tcp, udp, icmp, any
> - in case of tcp/udp, there would be also <port> - a port number, or
> "*"
> - in QubesDB, save the rules as:
> /qubes-firewall/<domain-ID>/default-action - "allow" or "deny"
> /qubes-firewall/<domain-ID>/rules/XXX - actual rules, each as a
> separate entry, where XXX is 3-digit rule number (so a maximum of
> 1000 rules)
> - Linux specific: place rules for each VM into separate iptables chain,
> to ease customizations (#974)
> - convert updates proxy connection to qrexec service - see below

"allow/deny <target> <proto> [<port>]" - if "target" is a name, who does
the resolution? Is the resolution done once at the time of rule
insertion, such that the rule actually targets a host which may or may
not be correct once the lookup has expired? (For some background on
this question, see
https://git.netfilter.org/iptables/tree/iptables/iptables.8.in#n281 or
try out the combination of `iptables -I INPUT -d unikernel.org -j
ACCEPT` and `iptables-save`.)

When proto is "any", does that really mean "any" or does it mean "one of
tcp, udp, icmp"? If the latter, what's the story for IPSEC? Perhaps we
expect all tunnels to be built by ProxyVMs, and therefore don't expect
to need to specify these sorts of rules to other VMs from the ProxyVM?

Although this may be out of scope for the current discussion, I wonder
whether it will be possible to specify "port forwarding" rules under
this scheme for VMs being NATted.

It's likely worth looking at nftables (
http://netfilter.org/projects/nftables ) for lessons learned from that
project, particularly the first feature listed: "the userspace utility
*nftables* interprets the rule-set provided by the user (using a new
syntax)". I've sent a request to a friend who works on languages for
specifying network filtering for more information about what might be
useful for Qubes.

Generally, I think it would be better to find an existing specification
for a good solution in this space rather than attempt to build something
new based on an abstracted version of iptables.

>
> Questions
> - ---------
> - do we want to support port ranges?

I think it's a good idea to do so; otherwise the number of rules
required to implement relatively simple logic expands quickly. This has
bad performance implications for iptables in particular, which IIRC
effectively keeps a linked list of rules which need to be traversed with
each incoming packet.

> - do we want any special treatment for DNS? The problem here is target
> IP - dom0 may not know it (for example in case of custom VPN-provided
> DNS - #1183). So I see two practical options:
> - translate "Allow DNS" to a rule "allow * udp 53" + "allow * tcp 53"
> - add a virtual protocol "DNS", which would be translated to
> appropriate rule(s) by the ProxyVM (base on its /etc/resolv.conf,
> or so)
> * I think in the discussion on 32c3 we were for the first option
> - anything else missing/wrong in the above proposal?

I'd rather have the second option, as allowing DNS queries to anywhere
by default is in conflict with the stated goal of mitigating software
errors (in my opinion) -- if an application is hardcoded to send DNS
queries to (say) 8.8.8.8 but a user doesn't wish to send traffic to this
network, a policy like `allow * udp 53` is contrary to their desires. A
setup like the second option allows the ProxyVM to enforce a consistent
policy for name resolution, rather than the user having to define such a
thing piecemeal per-VM or per-network.

Thanks,
Mindy Preston

[Marek Marczykowski-Górecki]

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

On Tue, Feb 09, 2016 at 02:18:29PM +0000, Mindy wrote:
>
> Hi folks,
>
> By way of introduction, I'm the author of `mirage-nat`, on which some of
> Thomas Leonard's MirageOS firewall work is based. I've been a Qubes user
> for a couple of months, but haven't dived deeply into the internals yet
> (although I've been lurking on qubes-devel for some time). Among other
> things, I have previously implemented schemes for translating firewall rules
> from an abstracted JSON syntax to iptables invocations, unfortunately in
> closed-source land.
>
> Responses to the request for comments are inline.

Thanks for your feedback!
Commends below.

> On 01/14/2016 04:38 PM, Marek Marczykowski-Górecki wrote:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA256
> >
> >Hi all,
> >
> >We want to somehow rework firewall ~~VM~~ qube interface in Qubes 4.0,
> >because the current implementation have some limitations. Some of us
> >already talked about it on 32c3, but I think it would be good to have
> >also input from others not present there. But first, some background
> >info:
> >
> >Firewall purpose, goals
> >=======================
> > - prevent user mistakes, like opening links directly in mail ~~VM~~ qube
> > - mitigate software errors, like using http instead of https somewhere
> >
> >Non-goals:
> >- ----------
> > - prevent compromised ~~VM~~ qube from leaking the data
> > - filter incoming traffic (technically it is also firewall task, but
> > not part of the interface discussed here, at least not directly)
>
> Is filtering incoming traffic considered to be out-of-scope because it's
> assumed that this functionality is provided automatically by the common
> IPv4-and-NAT setup for VMs in Qubes? If so, it may be worth considering
> whether an environment with directly-addressable IPv6 VMs would suddenly be
> more vulnerable because of design decisions made here.

Generally incoming traffic filtering should be setup to block by
default. Whether it will be as a side effect of NAT, or explicit deny
rule in firewall, it doesn't matter.

Then if someone want to allow/direct some external traffic to one of
VMs, it may be configured using some other interface. For example we
think of using qrexec proxy for that (similar to updates proxy access
described below), to not even expose such VM for original TCP/IP packets.

But if we'd go with IP forwarding (instead of qrexec), it can still use
a separate configuration interface, most likely handled by the same tool
on FirewallVM side. I think that way would be easier to design (and
later implement) such interface - if we can focus on very narrow use
case for it.

We're not considering having directly-addressable IPv6 VMs by default
(maybe an optional feature, but not sure if even that).
When we'll implement IPv6 support, it will also use NAT. There are many
reasons for that:
- not expose VMs to external traffic by default (even in case of some
firewall error, not allow directly address particular selected VM)
- not leak (or at least make it harder to guess) information about
source VM / number of them (or even the fact of using multiple VMs)
- not reconfigure every VM when user switch to a different network,
including plugging in VPN services etc
- the above is especially important in case of some privacy use
cases, to not leak "real" address to the VM

Yes.

I think the time of DNS resolution is up to the implementation. Default
iptables implementation would do that at load time, with all its
consequences. But there is nothing stopping someone from preparing
alternative implementation. For example Subgraph OS use quite smart
mechanism of intercepting DNS replies, building a cache of them, and
using it for firewall decision.

(I thought I've put it somewhere in that email, but apparently not).

> When proto is "any", does that really mean "any" or does it mean "one of
> tcp, udp, icmp"? If the latter, what's the story for IPSEC? Perhaps we
> expect all tunnels to be built by ProxyVMs, and therefore don't expect to
> need to specify these sorts of rules to other VMs from the ProxyVM?

I think "any" should really mean "any".

> Although this may be out of scope for the current discussion, I wonder
> whether it will be possible to specify "port forwarding" rules under this
> scheme for VMs being NATted.

As noted before - I think there should be a separate interface for this.
Probably very similar, but separate.

> It's likely worth looking at nftables (
> http://netfilter.org/projects/nftables ) for lessons learned from that
> project, particularly the first feature listed: "the userspace utility
> *nftables* interprets the rule-set provided by the user (using a new
> syntax)". I've sent a request to a friend who works on languages for
> specifying network filtering for more information about what might be useful
> for Qubes.
>
> Generally, I think it would be better to find an existing specification for
> a good solution in this space rather than attempt to build something new
> based on an abstracted version of iptables.

The point is to have something abstract enough to be able to implement
different backends (for example one in Mirage OS), not only iptables
backend. If there is existing specification for that, I'm all for it.

> >
> >Questions
> >- ---------
> > - do we want to support port ranges?
>
> I think it's a good idea to do so; otherwise the number of rules required to
> implement relatively simple logic expands quickly. This has bad performance
> implications for iptables in particular, which IIRC effectively keeps a
> linked list of rules which need to be traversed with each incoming packet.

Do you have any practical use case for port ranges, in output rules?

> > - do we want any special treatment for DNS? The problem here is target
> > IP - dom0 may not know it (for example in case of custom VPN-provided
> > DNS - #1183). So I see two practical options:
> > - translate "Allow DNS" to a rule "allow * udp 53" + "allow * tcp 53"
> > - add a virtual protocol "DNS", which would be translated to
> > appropriate rule(s) by the ProxyVM (base on its /etc/resolv.conf,
> > or so)
> > * I think in the discussion on 32c3 we were for the first option
> > - anything else missing/wrong in the above proposal?
>
> I'd rather have the second option, as allowing DNS queries to anywhere by
> default is in conflict with the stated goal of mitigating software errors
> (in my opinion) -- if an application is hardcoded to send DNS queries to
> (say) 8.8.8.8 but a user doesn't wish to send traffic to this network, a
> policy like `allow * udp 53` is contrary to their desires. A setup like the
> second option allows the ProxyVM to enforce a consistent policy for name
> resolution, rather than the user having to define such a thing piecemeal
> per-VM or per-network.

This is indeed a valid point. I think also of intercepting all traffic to
port 53 and redirecting it to the right address, but this can have
undesired side effects...

> >Details of qrexec-based updates proxy
> >- -------------------------------------
> >
> >It would be socat/systemd.socket listening in TemplateVM on loopback
> >interface and package manager configured to connect to this address. As
> >a "backend" it would call qrexec-client-vm to initiate connection to
> >UpdateVM and connect to HTTP proxy there. UpdateVM still would have
> >tinyproxy to handle that traffic, the only changed part is underlying
> >connection transport - qrexec instead of TCP. But with such a small
> >change we get a lot of benefits:
> > - TemplateVM now may have no direct access to the network, which
> > eliminate the whole TCP/IP stack from attack vector (but still
> > leaving package manager - so some HTTP(S), which is admittedly more
> > concerning...)
> > - we can use any VM as a target here, using UpdateVM (the VM for dom0
> > updates) would be logical choice, but it may be different; this VM no
> > longer needs to on "network path between TemplateVM and the internet"
> > - no more problems with chaining proxies - like putting VPN VM, or
> > TorVM in between (which in the current implementation breaks the
> > connection in most cases)
> > - TemplateVM may even not know the name of target VM, thanks to ability
> > to redirect qrexec connection in policy (not sure if worth using it
> > in practice here)
>

> Thanks,
> Mindy Preston

>

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

iQEcBAEBCAAGBQJWugB1AAoJENuP0xzK19csVjoIAJJ2RNew6L+qhN8vfkQwM4Qe
N8Z6LLmWVsfMx87xLKybpLkNbhY+CvaqlAajf6GBAxpOOuONk9sYuGTVfytRLd2a
v2Zacql8xSj2ph1ALeYcXeJmIDpy4RfopH8QFO14TK9a+88JQ7FqYDzp5XG3oyz6
0azCiVd4u9QxbnQxjSSAN4Jb0BGDp64d04OmdmOahSDohAouyOmkaWDPsSmZ3ccP
MN9aOC/vwYAW3XxA/2ZsweNkH3v5tnZpuFKw6y6GLphn6VTQDD4s46B+kQmKLnww
PF9UQ2PxwUyQJMzJZ4zP8gbdGuhkWuqUFIUn6mswW4aO/S2UNZwzRlRMQMMlPso=
=aQcQ
-----END PGP SIGNATURE-----

[Zrubi]

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

On 01/14/2016 05:38 PM, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> We want to somehow rework firewall ~~VM~~ qube interface in Qubes
> 4.0, because the current implementation have some limitations.

This thread talking mainly about the interface - but because I don't
know any better place to share my technical ideas - I will put it here:


Because the use of the firewall is taking place in a proxyVM - there
is many possibilities we can use to increase security in general:

- - packet logging.
Even if it is not save you directly - at least you can process the
logs after an incident and/or by a scheduled script to detect anomalies.

This (at least logging the dropped packages) should be standard Qubes
feature, switchable from the GUI


- - per VM forward chains.
Then the we could define an universal main iptables flow, and the
actual filtering would taking place in the custom chains.

In addition we can create leak protection more easily.


- - transparent proxy services - like one mentioned in #1536
Here we will might need to work with custom iptables rules. Those
rules should be honored by the global Qubes firewall services.



- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW0F4dAAoJEC3TtYFBiXSvcsMP/01PP9wNpDHXD0wBmgrzIINE
/soCETQfHo0UJ/gjTkS2M/jHh9TUUBWJBTIfxsM2gggQu67MqGYdfs2gNEih4Mi6
hNkODeFAAshp5Xap+86Jf6ZwodtbdmtV/mdtBOfbLid0p732uFrdHyzSRkgrJKLA
MPVOE4xGi1P08cCWPCduhalmTFoqR6D18XBcoDn0d2zb7WtJeDhxYNx3e502ReY0
zctOTyOwUl9vo1G47PqrBVJJnPnO1WzlDJiRh1j5mWZF6I/PEPozA0+OWwjSyRBr
ukaZ8wQR/uzERLLfOQwxdo2SOmsgAi4PPCiERBrjlDyz0x2etKNzy3HZ3u6S4tUM
+1xHEd9gwEHBVJyWORMhFCBqPN/pdCb/b78AnbHvQ9m4tD2HVOiRsNaH0ng9wQOp
50PGeCqcXCCcVrUxXaz4+7+2QEFnZgOsmg/3aTnkaCr+zRt2tokvPtBQfzfLs1UK
iL7lnv6SeJOQ4+s5/bUs3zYx2RpfsuKYMegNxiUj3v7ZWzhHFP3PWTvFbpvsARZk
BzLgB5u+LKjxL2FEr2OssDXh/Emq88dnjGvJaiTj8Y/yBs5kK1WmxK1bbXfPs9XV
gykCBtKooGBI4b1yJ83fQDnJUrvGkPPiHEJRMKPG+zyBsR5rdVqroTof/ahKa3Kg
G3ddjyc4gHCz3LfOk1xO
=Xh/x
-----END PGP SIGNATURE-----

[Zrubi]

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

On 01/14/2016 05:38 PM, Marek Marczykowski-Górecki wrote:

> We want to somehow rework firewall ~~VM~~ qube interface in Qubes
> 4.0, because the current implementation have some limitations.

Do we have any (semi)final solution/plan regarding this?

Asking because I already have a working IDS/IPS in a proxyVM:
http://zrubi.hu/en/2017/traffic-analysis-qubes/

And would be nice to use the Qubes firewall rules with this type of L7
firewall solution. In this case we can filter protocols not just
ports. And URLS instead (or addition) of IP address...

So basically my plan is to extend and/or replace the basic packet
filter with a L7 firewall.

Thanks.

- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJXr9AAoJEH7adOMCkunmIbEP/08HDZ6zyb+qnuKlQUCC84Ei
cOcmje91Bs7DF2IkistQ45biDRWiCocxwsh/5JrSpLSpelJ/BNJHRs2ZAnYRVXR7
fjse1gmmQSLIKS4Wc6ivXwf9FtLbcZuWiW+EOC9Wez+qGCbe4kCskObLnchVjMbE
+Ed4klcZcsSpIGaSBn5rG8RI7rHQHxccB0AmOKWMHhDvJZCXnc1E+yOj/HPQYwEP
R4WkTxaZ4sMvalsQPVStGQlL9F8LPAg/slPdECYieuN0xz5ZVyDrKl4EiTPmEZwB
lU7Ss8V6ZVBQEbTFWHVephZA7Jq5gHcD+vU68jcWVVmhPF8RukhT+9Ekp83q3LRv
a7u/yQszA9JC+I4J1yg5HZgEXWMaoTbC/+R/AKkuoAbU2i4J88Z0T+uWyIyxsUZo
9P9irlQ1xQ0qm9xdiTBlcIpdMEnBQjXqUPw65REQFBIVm5CFELedljW20kKVy689
3JPa9gFqHnSYvOx7Z7HZQVOlxHIedHFGoNX32g3dgIf9ZgRXYsTaW85ZiJxx5/TO
cgBAR/POXB8oUSB4telvAFwodceacPFv+7QBFMlvfC/0oq1udn8EChAJprB0KyR+
T2AtqAqHJTEEdN8kGlQhSYVJ56Fj63WbWpjs2q7QDxJLAO0LyKhTJJpWmbHqvz8a
bQgczSdOHqEUopk73zzq
=zsFn
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Wed, May 24, 2017 at 02:22:32PM +0200, Zrubi wrote:
> On 01/14/2016 05:38 PM, Marek Marczykowski-Górecki wrote:
>
> > We want to somehow rework firewall ~~VM~~ qube interface in Qubes
> > 4.0, because the current implementation have some limitations.
>
>
> Do we have any (semi)final solution/plan regarding this?

Take a look here:
https://www.qubes-os.org/doc/vm-interface/

There is also an implementation for iptables and nftables (the later
being preferred if available):
https://github.com/marmarek/qubes-core-agent-linux/blob/master/qubesagent/firewall.py

> Asking because I already have a working IDS/IPS in a proxyVM:
> http://zrubi.hu/en/2017/traffic-analysis-qubes/
>
> And would be nice to use the Qubes firewall rules with this type of L7
> firewall solution. In this case we can filter protocols not just
> ports. And URLS instead (or addition) of IP address...
>
> So basically my plan is to extend and/or replace the basic packet
> filter with a L7 firewall.

I'm not sure how to integrate this, or even what level of integration do
you expect. For start, using nftables makes it much easier to plug
your own rules into firewall - you can store them in own tables and
qubes-firewall service won't touch them (no need to reload custom rules
every time firewall is reloaded, using /rw/config/qubes-firewall-user-script).

Going further, you can compile rules retrieved from qubesdb into
anything you like (Suricata rules or such). But from just this, you
probably won't be able to use full potential of powerful L7 firewall
engine (for example specification only allow port specification, not
expected protocol, URL etc). New format is also easier to extend if
needed.

To be frank, I don't think putting something like this in firewall
VM (expected to enforce some policy, not only analyze and report) is a
good idea. L7 traffic parser largely extend attack surface.
For analyzing and reporting, better idea would be to only log
(selected?) traffic in ProxyVM and then copy it (possibly in real-time)
for analysis to some other VM. That other VM may have no network access
(and receive the data on uni-directional qrexec connection) to make it
harder to leak anything even when someone take over the analyzing
engine. And also that VM would be unable to modify the traffic - which
may be or may not be what you want. Some limited control could added
back with another qrexec service, in opposite direction now (analysing
VM -> firewall VM) which would cut network access for selected VM when
some fishy traffic is detected.

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

iQEcBAEBCAAGBQJZJY1wAAoJENuP0xzK19cs9JMH/1Zx9g05Ga/bla9EWxa6GRS+
cks/fGh2UtY0YFCcPhrBGU9MD5WQSB/DQNfnrjWmeIDxi2tPzDR2vrCspAHVeBcb
+ykbQz6FhLeao0zazLmss3mb2ed+6EztXjmTiG8JR4+5ii0IUV2G07TDLWekW/Qw
Ee0oCnBXngJ93qHoC8aoFmMOnka8I1si46m8QOEBkoJPTqymMYkyG4ssfToIio4b
Ga+RfaaTXpwi796Sid6NhOChoVsNW6wIUl7RymbJOXBaX8HX3FC+YwE+gRYXbaTf
qdW9CnRj20OlrNVYio3lPSsYF32gI76+PyezgAoU6WS3QcLR4Z31RIydvh07uUI=
=nfv5
-----END PGP SIGNATURE-----

[Zrubi]

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

On 05/24/2017 03:41 PM, Marek Marczykowski-Górecki wrote:

> I'm not sure how to integrate this, or even what level of
> integration do you expect.

> Going further, you can compile rules retrieved from qubesdb into
> anything you like (Suricata rules or such). But from just this,
> you probably won't be able to use full potential of powerful L7
> firewall engine (for example specification only allow port
> specification, not expected protocol, URL etc). New format is also
> easier to extend if needed.

According to the current docs I would need a new field for L7 protocol
like: http, https, imap, ftp, etc.

Then the rules are not contains L7 protocol would translate into
packet filter rule, the ones are contains that new L7 protocol would
translated to a suricata (or any other L7 engine) rule.

Not sure however that what you plan with the dstname in context of
iptables/nftables.

So I really do not want full L7 processing, just advanced firewall
rules based on the DNS hostname and L7 prototocol.

> To be frank, I don't think putting something like this in firewall
> VM (expected to enforce some policy, not only analyze and report)
> is a good idea. L7 traffic parser largely extend attack surface.

I do not see it as an attack surface - at least not more than a real
inline IDS/IPS system. And of course using such L7 processing would be
optional.



- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJZsFAAoJEH7adOMCkunmvg4P/RIAP6Y/QY0wrPeHaCDe612i
spP+/ZpyFrv8k52yS+aI1bvPCxdgtCGg3NSKVUI1swDQZ/GHx55rVekyQ8kq+seu
fT81iQldJHI28c4GonECpSRG2yhsygg/q2OmpyS8ZGl+1uttcThR2HxR1PXXfRid
gdA4HNxmiRLZ7yQgdkxZWShYaLmQJIt8oYoAWxvBL7oEY8NlkPWob1ES0UqAuxoN
gABfjIo9abhTpfAScl5yBrCC0pVn3+bJVo9lUMJF0YWAlUWnhe4GTHfGI0aD968K
61NKRgXE2PaK1hJUHJUpxlRFXDtoa/zhyK2nklE40AaZwhp4fPx5LhtXelw0+PX3
CtO5DWgOuCw1too9wiDbiO1iyBs0OmX+WUWSoqBSJ3hrTkuHRw3d9BPNUpsfDF2v
Apa+EBwg1w3ZdjQEedXcTu9kn7+lI69T2cfeN+O5OsKke9NIFKqa8Ax1Pse9axVv
wpekpKJsYfTk93/KQVfIUbWl+Ga60VzjakUuS9te5W9zUohun4R303DW07gX2r4s
iMVgmBKMrJjSqtqsV2tMyEXfkSL1AH0Lh3nOnc1IUehmqvPaMDCTL93f+tUtrZlF
EOfLHf6pLJz2NcAJycnmgpMd79IGXT7SjA3ZoAOrU098FslFsglOB1b3px6i9Eb3
ajZ6V8ymqbZz/Ylbe48e
=PeGJ
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Wed, May 24, 2017 at 04:41:14PM +0200, Zrubi wrote:
> On 05/24/2017 03:41 PM, Marek Marczykowski-Górecki wrote:
>
> > I'm not sure how to integrate this, or even what level of
> > integration do you expect.
>
> > Going further, you can compile rules retrieved from qubesdb into
> > anything you like (Suricata rules or such). But from just this,
> > you probably won't be able to use full potential of powerful L7
> > firewall engine (for example specification only allow port
> > specification, not expected protocol, URL etc). New format is also
> > easier to extend if needed.
>
> According to the current docs I would need a new field for L7 protocol
> like: http, https, imap, ftp, etc.

Ok, can you create pull request to qubes-doc with it's description? I
think we can add such thing.

> Then the rules are not contains L7 protocol would translate into
> packet filter rule, the ones are contains that new L7 protocol would
> translated to a suricata (or any other L7 engine) rule.

We'll also need some signaling whether L7 protocol is supported by a
given firewallvm. But we can think on this later, as default behavior is:

If tool applying firewall encounter any parse error (unknown option,
invalid value etc), it should drop all the traffic coming from that
SOURCE_IP, regardless of properly parsed rules.

So, using this new field will be signalled to the user when not
supported: firewall will fail to load.

> Not sure however that what you plan with the dstname in context of
> iptables/nftables.

Currently: resolve at the time of applying rules (appropriate VM startup).

> So I really do not want full L7 processing, just advanced firewall
> rules based on the DNS hostname and L7 prototocol.
>
>
> > To be frank, I don't think putting something like this in firewall
> > VM (expected to enforce some policy, not only analyze and report)
> > is a good idea. L7 traffic parser largely extend attack surface.
>
> I do not see it as an attack surface - at least not more than a real
> inline IDS/IPS system. And of course using such L7 processing would be
> optional.

Yes, it's probably comparable. Anyway, one should use appropriate
protocols for sensitive communication.

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

iQEcBAEBCAAGBQJZJdFsAAoJENuP0xzK19csR+kH/3fb8mu26nFw6AcYDY72PTPp
eIF7gklSWxeqtQAOtDsOnrlobpBEhkJSKBBi9Bn0nN8PKcXVzXBkUFHP39s2JMAJ
ZzxVirgjInvWcmu9Zk3cvVdcPiLhezRxnkfTGIwvIBjTS8wRbWIvuFybSJGnAI/j
p9fUR9s8Q7zUplUyxpf3e42NZAGE/07jxnswbD+jCvzA6PxErqUKk/NZrX5lyO4n
mPt+yRo5eH7Yf3ErFy2GX9lc/GNSQie5TnCCX13K9tRhiTI3etxYGwctykk0N4ho
7CiIAzsLUu+jvKoYaUc/yfRohEtkoUNJ3K6j3GiS7vSplF2WJwRdi7ala/qgv78=
=CfYU
-----END PGP SIGNATURE-----

[Zrubi]

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

On 05/24/2017 08:31 PM, Marek Marczykowski-Górecki wrote:
> On Wed, May 24, 2017 at 04:41:14PM +0200, Zrubi wrote:

>> According to the current docs I would need a new field for L7
>> protocol like: http, https, imap, ftp, etc.
>
> Ok, can you create pull request to qubes-doc with it's description?
> I think we can add such thing.

https://github.com/QubesOS/qubes-doc/pull/429


If this is still a proposal I really would like to see 'log' action
for packet filter rules also...

Do we know how would the GUI interface look like - just to avoid
confusions about the default action, vs. the single actions inside the
rules.

> We'll also need some signaling whether L7 protocol is supported by
> a given firewallvm. But we can think on this later, as default
> behavior is:
>
> If tool applying firewall encounter any parse error (unknown
> option, invalid value etc), it should drop all the traffic coming
> from that SOURCE_IP, regardless of properly parsed rules.
>
> So, using this new field will be signalled to the user when not
> supported: firewall will fail to load.

This would be a major change compared to the current "silently no
firewall rules are used" - but highly welcome this change :)


- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJqI6AAoJEH7adOMCkunmlIYQAJ6rHauuyiE8T4P/A7Jc0Xap
e2WmJ7PNZ+yzZsnCpooSGBOMaTgg+JKnBY1WkpEWwxZ7f5Yn8enE5byzQs5J+fHm
WhH3PMajoIUTM+IEz9smWCm0Qny8kqeCnFgcvNutlLpMoKT4aQyJjUC1ZGWQVQAM
bDeXyX27cz2PJWyfo0WiJs2PjjEN4fS8s197aJ0D3kx6Bb4T/lHE1pZ5aulgZL5k
DFV07HM6PH1yEFzp2ucN1OFvJV62ju3EAsFoB8x2xr39cYbne+kp05YhLlJnTDGK
ubuOWqjWapn5CM1uSUDFo8kTDdZunpSX176kUaePO5MHeZgM4WLPBX2liucLqf5r
8hnMLGM8DYw9QY+E1HR2eISVBiLThqzHMuI7gnnqPLw9AYeLmT/DCiPgceIt6VgJ
tVlyOUZoyDKbAIKVYlmaVhEAKItWxDdoPZa8bCzSFeEzJB7X2ytTdBAU0Kc/rXPq
JK+OnEVmsaS17jnXYqN2hlA9qpy08lYvOu49FMsIKOl/VyCuBoWVTsmr7FA0WUjV
8lWypAjE9X7OcEf1G/1r7hrSjpUkHb5DYWvwCWLhvxcbYzgP+OssOevYwLr9rUF4
/vmRbp25AhXeBP7Qv/Cd5bIdQtU8OKrt9GkLwd47d2Rg/rDF5jBPWWuyuuLk7tjU
74ffyv0zLzftJyMkmR8V
=gC22
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Thu, May 25, 2017 at 11:22:14AM +0200, Zrubi wrote:
> On 05/24/2017 08:31 PM, Marek Marczykowski-Górecki wrote:
> > On Wed, May 24, 2017 at 04:41:14PM +0200, Zrubi wrote:
>
> >> According to the current docs I would need a new field for L7
> >> protocol like: http, https, imap, ftp, etc.
> >
> > Ok, can you create pull request to qubes-doc with it's description?
> > I think we can add such thing.
>
> https://github.com/QubesOS/qubes-doc/pull/429

Thanks!

> If this is still a proposal I really would like to see 'log' action
> for packet filter rules also...

Do you mean alternative to action=accept, action=drop etc? Or some
additional option like log=true (but then it would be impossible to use
it without also specifying an action...)?

> Do we know how would the GUI interface look like - just to avoid
> confusions about the default action, vs. the single actions inside the
> rules.

Not yet, but if no one will come with a better idea, we'll probably port
the old one.

> > We'll also need some signaling whether L7 protocol is supported by
> > a given firewallvm. But we can think on this later, as default
> > behavior is:
> >
> > If tool applying firewall encounter any parse error (unknown
> > option, invalid value etc), it should drop all the traffic coming
> > from that SOURCE_IP, regardless of properly parsed rules.
> >
> > So, using this new field will be signalled to the user when not
> > supported: firewall will fail to load.
>
> This would be a major change compared to the current "silently no
> firewall rules are used" - but highly welcome this change :)

:)

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

iQEcBAEBCAAGBQJZJq8TAAoJENuP0xzK19cs1b0H/jY6z8neOUFGkuXCvEpC9sB8
FPVsMB/RDriRcJGeDvaI9Z2G6AGe83Ktr3EPK93BQJT4JH/jffCr9Ru54Dm4uMBI
jL2XErU/KyEORMF4rZWQavYJY1XIa0fV8y5/ujvGCoyQTPmxDacYZIdJ/8M/yfc2
Euhgv3LnTqSST84jvl6C5ZM4Uk+K1Cv9zAL9SZUDvROAAgmO2OR/+/E79L0a0xO4
bXnyaybFlHzJnIenpJ0Blz5aBCaLiR9qBBUqyjXypQgwLgLLOZiZEFttDMYCGQEb
XhOtjDD+Dx0H96MkRRo+80F7KTgXbHP07rRVWXPQ/RPHTfx61+BDqArHMllR6QY=
=Mf9S
-----END PGP SIGNATURE-----

[Zrubi]

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

On 05/25/2017 12:16 PM, Marek Marczykowski-Górecki wrote:
> On Thu, May 25, 2017 at 11:22:14AM +0200, Zrubi wrote:

>> If this is still a proposal I really would like to see 'log'
>> action for packet filter rules also...
>
> Do you mean alternative to action=accept, action=drop etc?

Yes, like action=log

>> Do we know how would the GUI interface look like - just to avoid
>> confusions about the default action, vs. the single actions
>> inside the rules.
>
> Not yet, but if no one will come with a better idea, we'll probably
> port the old one.

Since the old one has no action field in every rule, but assumes the
opposite of the default one, I would suggest separate action field for
every rule on the GUI - just like in the proposed backend side.

This way the log action would fit pretty nicely.

(Of course in this way the user can create useless rules where the
action is accept, while the default action is also accept)

And if my idea accepted about the optional L7 rules, we would also
need a new field for this.

The current solution however pretty much confusing:
The filed called 'service', and the values are selectable from a
drop-down menu where you can choose http, https, ftp, etc.
In reality (means in a packetfilter rule however it is means a port
number)

My suggestion would be to rename this field to port, and add the
default port numbers to the value like:
http (80)
https (443)
ssh (22)

Then the Deep Packet Inspection protocol field can be called DPI, (or
L7 Protocol) where the default should be 'No', and the selectable
values should reflect the possible Suricata/Snort supported protocol
names. (as a suggestion just like how the service field works in 3.2)

While the values are highly engine specific, we may offer some basic
one like:
HTTP, SSL, TLS, SMB, SMB2, SMTP, FTP, SSH, DNS


- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJrkaAAoJEH7adOMCkunm60sP/0GKaGoHZ19iiwwX3Y1Fg445
A7Ng0vNi4OReYKFXsOrZAMsePGYA8FjQNAXYYYKWp5d2m4/GgA/tcfVTnyz+J9w9
mg+01XE42lkMckZ/WWlM5IyV0Um0x4tiOt30+7X9Endc5uCRI9alGxf4oUAe4Zjw
cASj/i0ecMacXi8J4ReOl1Q2n8i53mxFhVZtoErmBxeDSFiIzMf+mzxfajok6Leb
heX5aQjplQ63A+KmIGo74SbS28k7on8piwUwmOfnFO3kU9owJ1ivTIQ//TpsxV/5
yxe97uuQZ0xF3/1hu2bOEnDTfl6dTSA7jYQEhnukvKFFV7e0i+5yR1WDwL/avqMJ
YRyov86Wn04po2zKljeHuubAtIwdndYKwECHosFrwGM/e3OAVmLd1D83Ha9N25Sw
zHbx2WOGzI6U7M4xBjEjqNro/701DaWP8b7oKiL7NzbWOFX0dOd3YdXPggl+PpKj
J5x4rhMk36X8q6Byw3x1Ft+C57hQiCWbDygwZYteAgxUC8KOe5kaPYwLBQhp4SzV
QzlIYQro+IvQk6Ge7uklHKFpZHyO6hv5AYNcpX8odD3FHWs8mtQ7NI32l5Q8tnFL
XeFbsXNXGDcGROayXWAq7Q3Uglj3F0PxoS9ta5E7gpKQH303k04FkhnclgbbYajD
evijIR7CTNQSGHnYE4Jp
=zk0g
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, May 24, 2017 at 8:22 AM, Zrubi <ma...@zrubi.hu> wrote:
> On 01/14/2016 05:38 PM, Marek Marczykowski-Górecki wrote:
>> We want to somehow rework firewall ~~VM~~ qube interface in Qubes
>> 4.0, because the current implementation have some limitations.
>
> Do we have any (semi)final solution/plan regarding this?
>
> Asking because I already have a working IDS/IPS in a proxyVM:
> http://zrubi.hu/en/2017/traffic-analysis-qubes/
>
> And would be nice to use the Qubes firewall rules with this type of L7
> firewall solution. In this case we can filter protocols not just
> ports. And URLS instead (or addition) of IP address...
>
> So basically my plan is to extend and/or replace the basic packet
> filter with a L7 firewall.

Zrubi,

I really like what you are trying to achive.

From a security perspective, it would be fantastic if the DPI code
were to be run in such a manner that once it's exploited (which I
consider inevitable*), the attacker would not gain a MITM position. In
practice, this means running Suricata (or whatever) in another VM not
on the NetVM -> AppVM path (by diverting a unidirectional copy of the
traffic stream to another VM).

* Protocol dissection is a complex parsing task, and one need only
look at the track record of wireshark or tcpdump or really any
protocol dissector to see that packet parsing is a proverbial
minefield. Unless the world starts caring about LangSec, this is
unlikely to change IMO.

This has additional complexity, and perhaps can only make sense for
IDSes (since IPSes want to be able to drop packets) but I think is
still a worthwhile endeavor. Thoughts? Should we just rely on
within-vm sandboxing instead? (Are existing IPSes designed with strong
privilege separation? I've never checked.)

Regards,
Jean-Philippe

[Jean-Philippe Ouellet]

On Thu, May 25, 2017 at 7:21 PM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> On Wed, May 24, 2017 at 8:22 AM, Zrubi <ma...@zrubi.hu> wrote:
>> On 01/14/2016 05:38 PM, Marek Marczykowski-Górecki wrote:
>>> We want to somehow rework firewall ~~VM~~ qube interface in Qubes
>>> 4.0, because the current implementation have some limitations.
>>
>> Do we have any (semi)final solution/plan regarding this?
>>
>> Asking because I already have a working IDS/IPS in a proxyVM:
>> http://zrubi.hu/en/2017/traffic-analysis-qubes/
>>
>> And would be nice to use the Qubes firewall rules with this type of L7
>> firewall solution. In this case we can filter protocols not just
>> ports. And URLS instead (or addition) of IP address...
>>
>> So basically my plan is to extend and/or replace the basic packet
>> filter with a L7 firewall.
>
> Zrubi,
>
> I really like what you are trying to achive.
>
> From a security perspective, it would be fantastic if the DPI code
> were to be run in such a manner that once it's exploited (which I
> consider inevitable*), the attacker would not gain a MITM position.

I mean here to prevent active MITM, able to modify the traffic stream
at will. An attacker could still gain passive MITM and could leak
whatever is interesting through side-channels.

Whether the increased risk of an adversary having both an IDS exploit
and compromised one of your other VMs to establish a covert channel
potentially gaining a passive MITM position is justified by the gains
of an IDS to begin with depends on your threat model.

This also makes an interesting case for potentially wanting to
separately run multiple IDSes for different traffic streams, to
prevent an adversary with an IDS exploit and the ability to send
traffic to only one VM from gaining passive MITM on the network path
of other VMs.

[Zrubi]

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

On 05/26/2017 01:21 AM, Jean-Philippe Ouellet wrote:

> I really like what you are trying to achive.
>
> From a security perspective, it would be fantastic if the DPI code
> were to be run in such a manner that once it's exploited (which I
> consider inevitable*), the attacker would not gain a MITM position.
> In practice, this means running Suricata (or whatever) in another
> VM not on the NetVM -> AppVM path (by diverting a unidirectional
> copy of the traffic stream to another VM).

Well - as always - it is depends on your threat model.

1. Deep Packet Inspection would be optional, so the user can decide.

2. I would not using the parsing engine on random streams but only
generated by a potentially clean AppVMs. The whole point is to protect
the AppVMs from user mistakes, identify phishing and calling home
situations, and probably identify suspicious activity* by limiting the
network access rights.

moreover there is no need for full L7 parsing. We need only host
headers, and protocol identification. No need for payload parsing for
this task.

* As I working with SIEM system in a pretty big scale, I see that most
of the policy violations, and many of the virus like activities can be
revealed by the unwanted traffic generated by the affected
workstations. I believe that the same apply for your small scale
virtual network inside you laptop if using Qubes OS


3. If the AppVM already compromised, there is no point talking about
the potential MITM


4. this is still just a plan.
However preparing the GUI is an important step as I see. If the Qubes
Firewall design limiting the possibilities - just as it is doing in
3.2 - nobody will try to work on any "firewall like" solution.




I'm fully agree that more deep packet parsing means more attack
surface, but still believe that achieving a MITM situation by
exploiting the DPI engine is a way more complicated (and more
targeted) that simply compromising an and user application like a browse
r.

So I still see it as an improvement if you are using a harder to break
thing to protect an easy to break thing like an end user application.

And again: it is optional. You can decide.
And you can also improve it once it is implemented ;)

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJ9rJAAoJEH7adOMCkunmGl0P/1TyR0rOEkli8iX5LINzVxld
/vBxlkLGTu4G4pamNkX31mG0l3DdktKoTrvHYIqcKEZgYrKUqzB2fO55ixwoMBvx
jvaHnuPZ2xMFJPtOGTyuqhGnfe9v+8mWEu/HlpP7rhX5sWC58keuRXi7rXlqNAhr
yeRWd2Vkb93JmWp0u3UV/xQnr4JnU8TH21nwSPRybcdhhpz1vS9lqEqOdhhdPkVh
4h0IsX+1gQij2bnfL7mG36bqDv1a34C4xUyiIAxfEGHnfM03ZsJcc/J/Pp/YLDLD
D8OaVkHugO2ud6nv6hOWlDkNEqD6ixJdfqzkaaiBrse1cb2zjEXS3X5dZJPE+1MP
DR/qDPeUR5a2qkLeFJbTETUhI/UJcuAKengb2i7wtBxfDKvB3c+bzg0aJG4p/GKM
y7q2Iz3OVllZyIVVk39K0DxPNkxmGG0iY+lBCcMZ1MPISt4hVeu4L7jEaB+KdJ3l
YqiuE/+i9jczkMjOUACEVmnlgyJ7nliTNmRkZh6uSzBGzx1WKN8QfYQGYqywpGCV
1F2qIMS7ob9pyGnVJF8zRDe5Lv4Ci9YrQ64T4YIUyMk4PPSH4le1rQCVt0t7nIVH
QO/OvalqW8HXpKyt6tbKPTbs5bS0oLx1dPay8V2BxdGQ+VJ9yqQbVJHNJnteG2KL
5IJQTfAf7UxdWcVRrpr2
=Bi0k
-----END PGP SIGNATURE-----