Re: [qubes-users] another question/wishlist item: VLAN tags

[Joanna Rutkowska]

On 05/01/13 12:48, Robert William Fuller wrote:
> We need to be able to create net VMs that are tagged into various VLANs.
> Alright, you don't have to say it.... I am needy. But seriously, this
> is an important feature for security work and every day corporate work.
>

Can you explain it a bit more, giving an example, etc?

BTW, moving this to qubes-devel.

joanna.

[Olivier Médoc]

Using a single tag should be easy as it is now supported by NetworkManager.

Using multiple tags at the same time would require some kind of
bridging, while tagging in AppVMs.

[Robert William Fuller]

As an example, we have a SAN at my workplace. In order to isolate the
SAN from other networks, we have placed it in its own layer 2 VLAN. To
further isolate the SAN, we have NOT given the SAN's VLAN a layer 3
routing interface. In other words, the core switches cannot route to
our SAN. In order for our virtualization hosts--our server farm--to
talk to the SAN, they must be connected to network switch ports that are
tagged into the SAN's VLAN, since none of the switches will route to
that VLAN. Now, if I want to manage that SAN, in order to communicate
with it, I have to tag my desktop network switch port into the SAN's
layer 2 VLAN.

As a secondary example, we might have an open/public Wi-Fi network.
Because we do NOT want that network to be able to talk to the rest of
our network, we isolate it into a layer 2 VLAN and do NOT give it a
layer 3 routing interface. This keeps people on our open/public Wi-Fi
network from exploring the rest of our network.

So, in a corporate setting, it is useful for me to be able to tag my
desktop computer's network switch port into multiple VLANs. This
provides me access to isolated layer 2 VLANs that I might need to manage
or use for some other purpose. On Linux, this VLAN tagging is typically
presented as multiple logical ethernet interfaces--eth1, eth2, eth3,
etc--one interface for each VLAN--although they are layered on top of a
single physical interface, possibly eth0. It's this "multiple tags"
scenario that Olivier was saying would require more work.

Rob

[Joanna Rutkowska]

On 05/02/13 04:42, Robert William Fuller wrote:
> On 05/01/2013 10:35 AM, Joanna Rutkowska wrote:
>> On 05/01/13 12:48, Robert William Fuller wrote:
>>> We need to be able to create net VMs that are tagged into various VLANs.
>>> Alright, you don't have to say it.... I am needy. But seriously,
>>> this
>>> is an important feature for security work and every day corporate work.
>>>
>>
>> Can you explain it a bit more, giving an example, etc?
>>
>> BTW, moving this to qubes-devel.
>
> As an example, we have a SAN at my workplace. In order to isolate the
> SAN from other networks, we have placed it in its own layer 2 VLAN. To
> further isolate the SAN, we have NOT given the SAN's VLAN a layer 3
> routing interface. In other words, the core switches cannot route to
> our SAN. In order for our virtualization hosts--our server farm--to
> talk to the SAN, they must be connected to network switch ports that are
> tagged into the SAN's VLAN, since none of the switches will route to
> that VLAN. Now, if I want to manage that SAN, in order to communicate
> with it, I have to tag my desktop network switch port into the SAN's
> layer 2 VLAN.
>

Ok, I'm really not a network security person (technically, I'm a
all-network-is-insecure-period person), and I have zero experience with
VLANs, but a question that comes to my mind after reading the above
paragraph is: what does the action of assigning some tag *on your
switch* has to do with the client computer that is connected to that
port...?

> As a secondary example, we might have an open/public Wi-Fi network.
> Because we do NOT want that network to be able to talk to the rest of
> our network, we isolate it into a layer 2 VLAN and do NOT give it a
> layer 3 routing interface. This keeps people on our open/public Wi-Fi
> network from exploring the rest of our network.
>
> So, in a corporate setting, it is useful for me to be able to tag my
> desktop computer's network switch port into multiple VLANs. This
> provides me access to isolated layer 2 VLANs that I might need to manage
> or use for some other purpose. On Linux, this VLAN tagging is typically
> presented as multiple logical ethernet interfaces--eth1, eth2, eth3,
> etc--one interface for each VLAN--although they are layered on top of a
> single physical interface, possibly eth0. It's this "multiple tags"
> scenario that Olivier was saying would require more work.
>

So what does the _tagging_ really mean? What does it do? Because now it
sounds to me like you can tag your client-end interface via software
means (of the client-end system) and... apparently your network switch
will just honor that? So, why others cannot do the same?

joanna.

[Marek Marczykowski]

This depends on switch configuration - each port have list of tags allowed
there (and default tag to assume for not tagged packages). Some wikipedia links:
http://en.wikipedia.org/wiki/Vlan
http://en.wikipedia.org/wiki/IEEE_802.1Q

Said that, back to your problem - what do you need from Qubes on this subject?
Having multiple vlans available in your system (as a whole)? Or having each
AppVMs attached to some particular vlan?

None of above is currently supported, but the first one IIUC can be rather
easy to achieve (assuming each vlan network have distinct IP addresses).
Simply create vlan interfaces (vconfig add ...) and connect to each of them in
network-manager (hope it will allow such action). Then you should have access
to each your networks from AppVM. You can limit such access using standard
qubes firewall. You can save setup commands in /rw/config/rc.local (in netvm)
to have them started at each system boot.

You can also create multiple firewall vms and try to direct traffic from each
of them to different vlan, but it sounds somehow tricky (policy routing etc).

If you need direct access to vlans (L2 traffic etc), probably you need to do
it directly in netvm...

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Robert William Fuller]

On 05/03/2013 01:05 PM, Joanna Rutkowska wrote:
> Ok, I'm really not a network security person (technically, I'm a
> all-network-is-insecure-period person), and I have zero experience with
> VLANs, but a question that comes to my mind after reading the above
> paragraph is: what does the action of assigning some tag *on your
> switch* has to do with the client computer that is connected to that
> port...?
>

> So what does the _tagging_ really mean? What does it do? Because now it
> sounds to me like you can tag your client-end interface via software
> means (of the client-end system) and... apparently your network switch
> will just honor that? So, why others cannot do the same?

Sorry. I assumed you knew what VLANs were. My response was NOT a good
introduction to VLANs. I will try to give you a high level conceptual view.

Simply, VLANs are sort of like separate layer 2 networks, even though
they are plugged in to the same core switches. Suppose I configure my
managed switch so that ports 2, 4, 6, and 8 are in VLAN 1. I also
configure ports 7, 14, and 20 to be in VLAN 2. Now the managed switch
will treat VLAN 1 ports and VLAN 2 ports as belonging to two separate
networks. It will allow traffic to flow among the VLAN 1 ports--2, 4,
6, and 8 or among the VLAN 2 ports--7, 14, and 20. However, it will not
allow traffic to flow between VLAN 1 and VLAN 2 ports. They are treated
as two separate networks.

I started with a simple example. In reality, configurations are more
complicated. Many of the managed switches can be configured to have
virtual ethernet interfaces that route from one VLAN to another. For
example, my desktop computer might have an IP address of 192.168.1.30
and a default gateway of 192.168.1.250, That default gateway lives on a
managed switch. It's a virtual ethernet interface that can route
traffic from the 192.168.1.0/24 network to other VLANs, based on rules
configured on the managed switch.

That's sort of the basic introduction. In a broader sense, VLANs allow
you to isolate some network switch ports from others. For example, I
may only want my virtualization hosts--my server farm--to be able to
talk to my SAN. I would achieve this by putting them in their own VLAN
and NOT creating a virtual ethernet interface that can route to this
VLAN. This keeps my desktop users--among others--from being able to
talk to my storage backend.

I will have to stop here for now (out of time at the moment.) I have
not talked about VLAN tagging which is kind of important. How am I
doing? Is this any clearer?

Rob

[Joanna Rutkowska]

Right, but back to my question -- what do you expect from Qubes, which
is the client machine, to do?

j.

[Robert William Fuller]

Fair enough question. I would like Qubes to be able to pass network
traffic that is tagged for a specific VLAN, let's say VLAN 17, to a
specific VM, such as my Windows 7 HVM. This would allow to me to manage
our storage back end and hypervisors that reside on VLAN 17--using
management tools that only run on Windows--without having to create a
virtual ethernet interface on the managed switch to route traffic for
VLAN 17 (which would increase the attack surface for VLAN 17.)

Ultimately, it would be nice to be able to specify many to one
relationships between VLANs and VMs. For example, I would like to be
able to tell Qubes to send traffic tagged for VLAN 17 and VLAN 5 to my
Windows 7 HVM.

As I have begun to use Qubes and learned how to forward ports to
specific appVMs, I think Marek's analysis in this thread of what
can/can't be currently done was spot on. And I think I can get by for now.

But really, this is just a wishlist item. A nice wishlist item that
would be very useful to those of us working in IT and operations centers
trying to maintain (in)secure networks and dealing with VLANs on a daily
basis. Maybe something to consider going forward if/when networking is
refactored....

Rob

[Joanna Rutkowska]

Just for the sake of educating me, one thing I don't really get is this:
what good is hardware (switch-enforced) vlan separation, if some
end-user box (running Qubes or whatever) can generate traffic for
arbitrary VLANs? Because this is what you want to do, correct?

Or am I misunderstanding your setup and you in fact have more than one
physical NICs in your Qubes box?

joanna.

[Joanna Rutkowska]

Or is the physical port to which the Qubes machine is connected
specially blessed and the switch allows any VLAN tags to come over it
somehow? In other words you treat your Qubes box as a trusted router?

joanna.

[Robert William Fuller]

That is a very good question. This is controlled by the configuration
on the managed switch. The switch will discard traffic that my desktop
generates that is tagged for VLAN 17 and VLAN 5, unless I have
configured the managed switch to accept VLAN 17 and VLAN 5 traffic on
the switch port to which my desktop is connected. This is why tagging
is crucial to the discussion, which I did not get around to explaining,
and still have not explained.

And yes, you just got the right answer in the other thread :-) I have
specially blessed my desktop port to be a member of VLAN 5 and VLAN 17
and accept tagged traffic for those VLANs.

Rob

[Robert William Fuller]

Exactly. The switch is configured to pass certain VLANs to the physical
port to which my desktop is connected. In this case, I'm not using my
Qubes box to route traffic. I just want to be able to place my Qubes
box in other VLANs that are unrouted so that I can manage SAN units and
hypervisors whose management interfaces are plugged into isolated,
unrouted networks.

Rob

[Joanna Rutkowska]

... but then you essentially make the very NetVM you're using to handle
the NIC in your laptop *trusted* (as far as your VLAN separation is
considered at least). Because if an attacker from one of the VLANs
compromises the networking stack of your NetVM (that is allowed to
generated packets with different VLANs) then the attacker would be able
to route her packets between the VLANs, right?

j.

[Robert William Fuller]

Yes, you are correct. One would hope that there is NOT an attacker from
one of these VLANs because they are physically secure VLANs, which is
where you want to put your SAN, for example. However, one could
theoretically exploit my laptop/desktop or the managed switch to gain
access to these VLANs. Unfortunately, we do have to trust some things
in IT.

Rob

[Joanna Rutkowska]

Sure, we need to trust something, but here it somehow strikes me that,
on the one hand you want to use some hardware-level mechanism (your
switch) to achieve a near-air-gap network separation, but then, on the
other hand, you make a Linux OS (your NetVM) the single point of
failure. Because when you say "your laptop could be exploited", in this
context, it really means: "your NetVM could be exploited".

But perhaps the security of Linux NetVM (specifically the Linux kernel
stack plus DHCP client) is comparable to that of the VLAN switch,
because perhaps it's effectively also some Linux box? In which case I
would not relay on VLAN separation for security anyway...

And this again brings us (well, me at least :) back to the conclusion
that security cannot (should not) be enforced by the networking
infrastructure, but instead only by the end systems and apps (via
cryptography). I guess DoS-resistance might be an exception here.

joanna.

[Robert William Fuller]

All of the major managed switch brands seem to run Linux. If you load
their firmware updates in something like Emacs, then you see a U-boot
loader and a Linux kernel version. That is why I have been thinking
about exploits against managed switches.

As for the NetVM security, it would seem that the way to access VLANs
securely with Qubes would be to have multiple physical ports in the
desktop computer and send each VLAN from the managed switch to a
separate port. That way, each VLAN would run in its own NetVM.
Unfortunately, I only have two network ports in my desktop computer at
the moment, although I can probably get by with that. A multi-port
board is probably out of the question because it would most likely
appear as a single PCI device which means that it could be passed to
only one NetVM.

I think that security needs to be enforced at as many levels as possible
or reasonable. I do not think that anything is truly secure.

Rob

[Joanna Rutkowska]

Yes, exactly. And for that, AFAIU, you already have all you need in
Qubes, right? You only need that multiple ports...

> Unfortunately, I only have two network ports in my desktop computer at
> the moment, although I can probably get by with that. A multi-port
> board is probably out of the question because it would most likely
> appear as a single PCI device which means that it could be passed to
> only one NetVM.
>

I have no idea.

> I think that security needs to be enforced at as many levels as possible
> or reasonable. I do not think that anything is truly secure.
>

Provided those lower levels of security do not diminish your sense of
paranoia and won't stop you from implementing also additional levels.

joanna.

[Robert William Fuller]

I looked at a virtualization host at work. Some of the multi-port
boards present themselves as bus bridges, so there is a PCI device for
each port, which means that each port could be given to a separate
NetVM. Of course that is a server-grade multi-port board. I am not
sure what the situation is with desktop multi-port boards, or even if
anybody makes multi-port boards for desktops, such as my small form
factor PC (short card slots.)

Rob

[Alfonso De Gregorio]

On Wed, May 8, 2013 at 12:13 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> And this again brings us (well, me at least :) back to the conclusion
> that security cannot (should not) be enforced by the networking
> infrastructure, but instead only by the end systems and apps (via
> cryptography). I guess DoS-resistance might be an exception here.
>
> joanna.
>

Indeed. There's nothing like the warm, fuzzy feeling given by a
(supposedly) secure endpoint.

On the other hand, the tragedy of the commons suggests us that when
both risks and benefits are socialized between elements of the
population, individuals lack the incentive to unilaterally invest in
security. And this explains why we are vulnerable to DoS attacks.

Cheers,
Alfonso

[Zrubecz Laszlo]

On 8 May 2013 01:16, Robert William Fuller <hydrolo...@gmail.com> wrote:

> And yes, you just got the right answer in the other thread :-) I have
> specially blessed my desktop port to be a member of VLAN 5 and VLAN 17 and
> accept tagged traffic for those VLANs.

You should avoid tagging in the AppVMs. Just do the tagging in the
NetVM... then the AppVMs can work as usual and no need any tweaking in
the Qubes networking code...


--
Zrubi

[Alex Dubois]

Hi,

Jumping in late, Laszo is right netVM may manage that. However the purpose of netVM is to "absorb" network drivers vulnerabilities. If such an attack is conducted, as tags are not encrypted, you will loose separation.

It may be beneficial to have, as some are working on with ArchLinux twmplate to have the netVM bridging traffic and VLan tagging being managed in the firewall VM. I have not enough knowledge on NIC drivers architecture to advice on how much of the attack surface you are moving into the firewall VM which you should aim to be as light as possible so you can trust it.

Alex

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-devel?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Olivier Médoc]

On 05/10/13 20:22, Alex Dubois wrote:
> Hi,
>
> Jumping in late, Laszo is right netVM may manage that. However the purpose of netVM is to "absorb" network drivers vulnerabilities. If such an attack is conducted, as tags are not encrypted, you will loose separation.
>
> It may be beneficial to have, as some are working on with ArchLinux twmplate to have the netVM bridging traffic and VLan tagging being managed in the firewall VM. I have not enough knowledge on NIC drivers architecture to advice on how much of the attack surface you are moving into the firewall VM which you should aim to be as light as possible so you can trust it.

Still this may not be so straightforward. I usually use the bridges
directly inside my final AppVM (in fact this is like working directly in
a firewall VM, which is not recommended). The problem is that the
firewall VM purpose is to filter traffic, not to route it. So maybe we
could get something using one firewall VM per tagged network in this
situation.

Are there any open Qubes architecture drawings that can help us to
illustrate this discussion (I mean the source of the drawings) ?

[Joanna Rutkowska]

On 05/13/13 09:18, Olivier Médoc wrote:
> On 05/10/13 20:22, Alex Dubois wrote:
>> Hi,
>>
>> Jumping in late, Laszo is right netVM may manage that. However the
>> purpose of netVM is to "absorb" network drivers vulnerabilities. If
>> such an attack is conducted, as tags are not encrypted, you will loose
>> separation.
>>
>> It may be beneficial to have, as some are working on with ArchLinux
>> twmplate to have the netVM bridging traffic and VLan tagging being
>> managed in the firewall VM. I have not enough knowledge on NIC drivers
>> architecture to advice on how much of the attack surface you are
>> moving into the firewall VM which you should aim to be as light as
>> possible so you can trust it.
> Still this may not be so straightforward. I usually use the bridges
> directly inside my final AppVM (in fact this is like working directly in
> a firewall VM, which is not recommended). The problem is that the
> firewall VM purpose is to filter traffic, not to route it. So maybe we
> could get something using one firewall VM per tagged network in this
> situation.
>
> Are there any open Qubes architecture drawings that can help us to
> illustrate this discussion (I mean the source of the drawings) ?

I'm afraid not -- some early arch drawing were made in iWork on my old
Mac (that was before Qubes Alpha 1 and so when I used to use Mac as my
primary machine), and then some later ones in Open Office.

joanna.

[Alex Dubois]

Alex

On 13 May 2013, at 08:18, Olivier Médoc <o_m...@yahoo.fr> wrote:

> On 05/10/13 20:22, Alex Dubois wrote:
>> Hi,
>>
>> Jumping in late, Laszo is right netVM may manage that. However the purpose of netVM is to "absorb" network drivers vulnerabilities. If such an attack is conducted, as tags are not encrypted, you will loose separation.
>>
>> It may be beneficial to have, as some are working on with ArchLinux twmplate to have the netVM bridging traffic and VLan tagging being managed in the firewall VM. I have not enough knowledge on NIC drivers architecture to advice on how much of the attack surface you are moving into the firewall VM which you should aim to be as light as possible so you can trust it.
> Still this may not be so straightforward. I usually use the bridges directly inside my final AppVM (in fact this is like working directly in a firewall VM, which is not recommended). The problem is that the firewall VM purpose is to filter traffic, not to route it. So maybe we could get something using one firewall VM per tagged network in this situation.

The problem that I was highlighting is that if the netVM (which could be bridging instead of routing) could be compromised.

The idea to use a VLAN tag to connect a sensitive environment would break, as the secure client would not be as the tags are not encrypted.

However, having 2 NIC, 2 netVM, the sensitive NIC not being exposed to a trunk would be safer (if you want to take NIC driver as part of you attack surface). You would need to connect to sensitive service via encrypted traffic strongly authenticated (client cert) (maybe using a jump off admin workstation if the SAN only support minimal protocols).

As for the support for trunked NIC in netVM, I feel it would be preferable to bridge the trunk to FirewallVM which would detag and route and filter to appVM.
This is if NIC drivers attack surface is small on the Ethernet packet parsing, de tagging... Which I don't know.
Otherwise, detagging in NetVM and routing to firewallVM(s) with one or many virtual interface between the 2.

>
> Are there any open Qubes architecture drawings that can help us to illustrate this discussion (I mean the source of the drawings) ?
>

It would be much easier to explain with a drawing but I only I minutes per week to contribute to at the moment :-(

[Zrubecz Laszlo]

On 15 May 2013 20:50, Alex Dubois <bow...@gmail.com> wrote:

> The problem that I was highlighting is that if the netVM (which could be bridging instead of routing) could be compromised.

I thing the main idea is wrong.

If you want a safe connection, use VPN (or SSL) for encryption and
authenticate it with a certificate.

bridging/routing or VLAN tags gives NO real security at all. All this
things are happens in an untrusted layer(s)

> The idea to use a VLAN tag to connect a sensitive environment would break, as the secure client would not be as the tags are not encrypted.

Not because the tags are not encrypted. Instead because the tags are
L2 things which is still not secure.

If you forget about the marketing bullshit, you can see that VLAN is
not for real security. It is for cheap network solutions.

> However, having 2 NIC, 2 netVM, the sensitive NIC not being exposed to a trunk would be safer (if you want to take NIC driver as part of you attack surface). You would need to connect to sensitive service via encrypted traffic strongly authenticated (client cert) (maybe using a jump off admin workstation if the SAN only support minimal protocols).

Yeah this is the way... But in this case you can forget about the
tagging and routing. I Because no matter if it's compromised or not
because only the connections are authenticated and encrypted. So there
is no real difference if a firewall vm tags the packets or the netvm.



--
Zrubi

[Zrubecz Laszlo]

On 16 May 2013 09:02, Zrubecz Laszlo <ma...@zrubi.hu> wrote:
> Because no matter if it's compromised or not
> because only the connections are authenticated and encrypted.

s/only/all :)



--
Zrubi

[Alex Dubois]

Alex

We agree on all points. I would still reduce the number of hosts who can communicate to one another via VLAN but leaving tagging de tagging to the switches and air gap between security zones (Internet, pres DMZ, app/data DMZ, intranet pres, intranet app, intranet data/iSCSI, intranet clients). VLAN to separate technologies (IIS VLAN, Apache VLAN, etc).