VLANs

VLANs

[Jonathan Tripathy]

Hi Everyone,

I wish to use VLANs on my Linux Xen hosts to seperate managed customer 
networks.

Can anybody please give me some pointers on how to make the network 
secure so no-one can VLAN hop?

At the minute, I plan to set up one bridge per customer, and use linux 
vconfig to add an if to the bridge (which I believe strips all tags). 
Then, all the respective customer Xen DomU (VM) interfaces will connect 
to the bridge.

Thanks

Re: VLANs

[John Haxby]

On 10 Jan 2011, at 17:42, Jonathan Tripathy wrote:

> 
> I wish to use VLANs on my Linux Xen hosts to seperate managed customer networks.
> 
> Can anybody please give me some pointers on how to make the network secure so no-one can VLAN hop?
> 
> At the minute, I plan to set up one bridge per customer, and use linux vconfig to add an if to the bridge (which I believe strips all tags). Then, all the respective customer Xen DomU (VM) interfaces will connect to the bridge.

If each bridge (for each customer) contains just one vlan-tagged physical interface then there is no way for the guests to vlan-hop.  A vlan tag added by a guest will either be replaced by the vlan tag of the external interface or the frame will be dropped.  If you have multiple vlans on a bridge (with multiple physical interfaces) then the vlan will be chosen by routing if the interfaces have their own addresses, I'm not sure what happens if the interfaces don't have addresses, but when a frame leaves on a vlan interface it acquires the corresponding vlan tag.  It doesn't matter what happens to the tag on the way back as it's only relevant to an interface that's on a vlan.

Obviously you should test this, but it's all pretty straightforward and there's nothing special or complicated to set up.

jch

Re: VLANs

[Jonathan Tripathy]

On 10/01/11 21:33, John Haxby wrote:
> On 10 Jan 2011, at 17:42, Jonathan Tripathy wrote:
>
>> I wish to use VLANs on my Linux Xen hosts to seperate managed customer networks.
>>
>> Can anybody please give me some pointers on how to make the network secure so no-one can VLAN hop?
>>
>> At the minute, I plan to set up one bridge per customer, and use linux vconfig to add an if to the bridge (which I believe strips all tags). Then, all the respective customer Xen DomU (VM) interfaces will connect to the bridge.
> If each bridge (for each customer) contains just one vlan-tagged physical interface then there is no way for the guests to vlan-hop.  A vlan tag added by a guest will either be replaced by the vlan tag of the external interface or the frame will be dropped.  If you have multiple vlans on a bridge (with multiple physical interfaces) then the vlan will be chosen by routing if the interfaces have their own addresses, I'm not sure what happens if the interfaces don't have addresses, but when a frame leaves on a vlan interface it acquires the corresponding vlan tag.  It doesn't matter what happens to the tag on the way back as it's only relevant to an interface that's on a vlan.
>
> Obviously you should test this, but it's all pretty straightforward and there's nothing special or complicated to set up.
>
> jch
Excellent! Thank you for your explanation.

If a guest maliciously added a vlan tag, wouldn’t it still remain in the 
frame, however be "double-tagged" by the outgoing physical port? Even 
still though, this probably isn't an issue, provided that all upstream 
switches are configured correctly.

In the first instance though, my Xen host will connect directly to my 
vlan-aware firewall port

Please let me know if I've got this wrong somewhere...

Re: VLANs

[Thomas Berg]

mån 2011-01-10 klockan 22:15 +0000 skrev Jonathan Tripathy:
> On 10/01/11 21:33, John Haxby wrote:
> > On 10 Jan 2011, at 17:42, Jonathan Tripathy wrote:
> >
> >> I wish to use VLANs on my Linux Xen hosts to seperate managed customer networks.
> >>
> >> Can anybody please give me some pointers on how to make the network secure so no-one can VLAN hop?
> >>
> >> At the minute, I plan to set up one bridge per customer, and use linux vconfig to add an if to the bridge (which I believe strips all tags). Then, all the respective customer Xen DomU (VM) interfaces will connect to the bridge.
> > If each bridge (for each customer) contains just one vlan-tagged physical interface then there is no way for the guests to vlan-hop.  A vlan tag added by a guest will either be replaced by the vlan tag of the external interface or the frame will be dropped.  If you have multiple vlans on a bridge (with multiple physical interfaces) then the vlan will be chosen by routing if the interfaces have their own addresses, I'm not sure what happens if the interfaces don't have addresses, but when a frame leaves on a vlan interface it acquires the corresponding vlan tag.  It doesn't matter what happens to the tag on the way back as it's only relevant to an interface that's on a vlan.
> >
> > Obviously you should test this, but it's all pretty straightforward and there's nothing special or complicated to set up.
> >
> > jch
> Excellent! Thank you for your explanation.
> 
> If a guest maliciously added a vlan tag, wouldn’t it still remain in the 
> frame, however be "double-tagged" by the outgoing physical port? Even 
> still though, this probably isn't an issue, provided that all upstream 
> switches are configured correctly.
> 
There is an sencario where your customer can make a mess. If the outer
vlan tag is the same as port vlan id aka native vlan on a dot1q enabled
port it will remove the outer tag and forward the packet only with the
inner tag wich was set by your customer.

I should suggest that you only allow ipv4 and arp passing trough to/from
your customer and drop any other frames including frames with vlan tag
set and ethertype x8100.



> In the first instance though, my Xen host will connect directly to my 
> vlan-aware firewall port
> 
> Please let me know if I've got this wrong somewhere...
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Best regards
Thomas

Re: VLANs

[Jonathan Tripathy]

On 11/01/11 08:19, Thomas Berg wrote:
> mån 2011-01-10 klockan 22:15 +0000 skrev Jonathan Tripathy:
>> On 10/01/11 21:33, John Haxby wrote:
>>> On 10 Jan 2011, at 17:42, Jonathan Tripathy wrote:
>>>
>>>> I wish to use VLANs on my Linux Xen hosts to seperate managed customer networks.
>>>>
>>>> Can anybody please give me some pointers on how to make the network secure so no-one can VLAN hop?
>>>>
>>>> At the minute, I plan to set up one bridge per customer, and use linux vconfig to add an if to the bridge (which I believe strips all tags). Then, all the respective customer Xen DomU (VM) interfaces will connect to the bridge.
>>> If each bridge (for each customer) contains just one vlan-tagged physical interface then there is no way for the guests to vlan-hop.  A vlan tag added by a guest will either be replaced by the vlan tag of the external interface or the frame will be dropped.  If you have multiple vlans on a bridge (with multiple physical interfaces) then the vlan will be chosen by routing if the interfaces have their own addresses, I'm not sure what happens if the interfaces don't have addresses, but when a frame leaves on a vlan interface it acquires the corresponding vlan tag.  It doesn't matter what happens to the tag on the way back as it's only relevant to an interface that's on a vlan.
>>>
>>> Obviously you should test this, but it's all pretty straightforward and there's nothing special or complicated to set up.
>>>
>>> jch
>> Excellent! Thank you for your explanation.
>>
>> If a guest maliciously added a vlan tag, wouldn’t it still remain in the
>> frame, however be "double-tagged" by the outgoing physical port? Even
>> still though, this probably isn't an issue, provided that all upstream
>> switches are configured correctly.
>>
> There is an sencario where your customer can make a mess. If the outer
> vlan tag is the same as port vlan id aka native vlan on a dot1q enabled
> port it will remove the outer tag and forward the packet only with the
> inner tag wich was set by your customer.
>
> I should suggest that you only allow ipv4 and arp passing trough to/from
> your customer and drop any other frames including frames with vlan tag
> set and ethertype x8100.
Hi Thomas,

While I have made sure that my trunk ports do not have a native vlan 
associated with them, I still think it's a good idea to use ebtables to 
prevent tagging from the customers. What would the command be?

Thanks

Re: VLANs

[John Haxby]

On 10/01/11 22:15, Jonathan Tripathy wrote:
> If a guest maliciously added a vlan tag, wouldn’t it still remain in 
> the frame, however be "double-tagged" by the outgoing physical port? 
> Even still though, this probably isn't an issue, provided that all 
> upstream switches are configured correctly. 

I don't believe that this is an issue.  And 802.1ad double tag won't be 
recognised so it will either be dropped by the switch or dropped by the 
outgoing NIC on the bridge.   Short of constructing frames by hand, 
though, I'm not sure how you would go about adding an 802.1ad vlan tag 
on top of an 802.1q vlan tag.

jch

Re: VLANs

[Jonathan Tripathy]

> On 10/01/11 22:15, Jonathan Tripathy wrote:
>> If a guest maliciously added a vlan tag, wouldn’t it still remain in 
>> the frame, however be "double-tagged" by the outgoing physical port? 
>> Even still though, this probably isn't an issue, provided that all 
>> upstream switches are configured correctly. 
>
> I don't believe that this is an issue.  And 802.1ad double tag won't 
> be recognised so it will either be dropped by the switch or dropped by 
> the outgoing NIC on the bridge.   Short of constructing frames by 
> hand, though, I'm not sure how you would go about adding an 802.1ad 
> vlan tag on top of an 802.1q vlan tag.
>
I wish it wasn't an issue. Many switches allow hosts to vlan hop if the 
native vlan of a trunk port is the same as the native vlan of the host. 
It's eaisly prevent t hough with proper switch configuration.

What ebtable command would I use to prevent *any* tagged frames coming 
from a host?

Re: VLANs

[Jonathan Tripathy]

> On 11/01/11 10:57, Jonathan Tripathy wrote:
>>> On 10/01/11 22:15, Jonathan Tripathy wrote:
>>>> If a guest maliciously added a vlan tag, wouldn’t it still remain 
>>>> in the frame, however be "double-tagged" by the outgoing physical 
>>>> port? Even still though, this probably isn't an issue, provided 
>>>> that all upstream switches are configured correctly. 
>>>
>>> I don't believe that this is an issue.  And 802.1ad double tag won't 
>>> be recognised so it will either be dropped by the switch or dropped 
>>> by the outgoing NIC on the bridge.   Short of constructing frames by 
>>> hand, though, I'm not sure how you would go about adding an 802.1ad 
>>> vlan tag on top of an 802.1q vlan tag.
>>>
>> I wish it wasn't an issue. Many switches allow hosts to vlan hop if 
>> the native vlan of a trunk port is the same as the native vlan of the 
>> host. It's eaisly prevent t hough with proper switch configuration.
>>
>
> One of us is missing something.  A VLAN tag is 802.1q; a double tag is 
> 802.1ad and, so far as I know, linux doesn't do 802.1ad.   If a guest 
> applies an 802.1q VLAN tag to a frame then that tag will either be 
> replaced by the outgoing 802.1q vlan-tagging interface or it will be 
> dropped.  (At least I believe this to be the case, you'd have to test 
> and/or check the code to see what happens, as I'm relying on memory 
> here.)  vconfig (on Linux) does not do 802.1ad double tagging, it's 
> only 802.1q.
I think I'm go on the assumption that the guest will double-tag the 
packet themselves
>
> I'm not sure what you mean by vlan hopping.  You have several vlans on 
> the same port so you can't use trunking (where the port is responsible 
> for tagging the frames) so you have to say which vlan tags are 
> permitted on the port and, of course, any frame with a permitted tag 
> will be passed but incoming frames will only go to the right vlan 
> interface.  (eg if the host has vlans 100, 101 and 102 then the switch 
> will have to be configured to allow those vlan tags on the port that 
> the host is connected to.  A frame destined for the host with vlan tag 
> 101 will show up on eth0.101 (or whatever) and that is connected to a 
> bridge that guests who are supposed to be using vlan 101 are using.  
> So even if a guest could send a frame with tag 100, it wouldn't get a 
> response from any other host on vlan 100.)
>
>> What ebtable command would I use to prevent *any* tagged frames 
>> coming from a host?
>>
>>
>
> I don't remember exactly off-hand, but you can check the particular 
> bytes in the frame for the vlan tag identifier and if it's present, 
> drop the frame.  (The 802.1q tag normally appears immediately after 
> the source and destination mac addresses, although it is allowed to be 
> in a different place.  The 802.1ad tag normally appears after the 
> source and destination mac addresses as well, immediately before the 
> 802.1a tag.)
>
>
> Have you actually tried this to see what happens?  Or are you 
> surmising that guests can have a double tag applied to an already 
> tagged frame?  Or that a vlan tagged frame is allowed through a vlan 
> interface with its vlan tag intact?  As I recall, the frame will be 
> re-tagged but it might be dropped, but I'd try it to see what happens 
> if I really wanted to know.  And then I'd check the code as well :-)
>
>
> jch

For seeing what I mean about VLAN hopping:

http://en.wikipedia.org/wiki/VLAN_hopping

Re: VLANs

[John Haxby]

On 11/01/11 12:24, Jonathan Tripathy wrote:
>
> For seeing what I mean about VLAN hopping:
>
> http://en.wikipedia.org/wiki/VLAN_hopping

Ahh.   That's interesting, but not nearly so interesting (or useful) as 
the Cisco document that it cites: 
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39054

Basically the hopping only works if the trunk has the same native vlan 
as the attacker.  This, the cisco article goes on to say, is considered 
to be a misconfiguration.   You can read it yourself, but there are two 
ways of avoiding this.

It's still not clear to me how you would get a reply from the attack -- 
you'd need something on the receiving end that can also do the double 
tagging (which is not 802.1ad, it's a second 802.1a tag, to be clear).

jch

Re: VLANs

[Jonathan Tripathy]

> On 11/01/11 12:24, Jonathan Tripathy wrote:
>>
>> For seeing what I mean about VLAN hopping:
>>
>> http://en.wikipedia.org/wiki/VLAN_hopping
>
> Ahh.   That's interesting, but not nearly so interesting (or useful) 
> as the Cisco document that it cites: 
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39054
>
> Basically the hopping only works if the trunk has the same native vlan 
> as the attacker.  This, the cisco article goes on to say, is 
> considered to be a misconfiguration.   You can read it yourself, but 
> there are two ways of avoiding this.
>
> It's still not clear to me how you would get a reply from the attack 
> -- you'd need something on the receiving end that can also do the 
> double tagging (which is not 802.1ad, it's a second 802.1a tag, to be 
> clear).
>
> jch
Yes I actually read that document. It's a very good document indeed, 
however I took it "with a pince of salt" as it's also got marketing 
behind it.

Indeed, I have no idea how a double tagging attack would work in regards 
to getting a reply, as Ethernet traffic is of course stateless.

I'm still trying to see what I can do to make my Xen network structure 
as secure as possible. I would indeed like to make some ebtables rules 
that just make sure that there are no taggs at all.

But maybe this is going to far?

Re: VLANs

[John Haxby]

On 11/01/11 12:52, Jonathan Tripathy wrote:
> Yes I actually read that document. It's a very good document indeed, 
> however I took it "with a pince of salt" as it's also got marketing 
> behind it. 

The Cisco technical documentation is generally very good -- this one is 
no exception.  You can spot Cisco marketing documentation a mile off: it 
has no technical content :-)

jch

Re: VLANs

[Jonathan Tripathy]

On 11/01/11 17:12, John Haxby wrote:
> On 11/01/11 12:52, Jonathan Tripathy wrote:
>> Yes I actually read that document. It's a very good document indeed, 
>> however I took it "with a pince of salt" as it's also got marketing 
>> behind it. 
>
> The Cisco technical documentation is generally very good -- this one 
> is no exception.  You can spot Cisco marketing documentation a mile 
> off: it has no technical content :-)
>
> jch

Excellent

Just one last question. Are there any measures I would need to take to 
make sure that traffic cannot escape from a Linux bridge? My bridges 
don't have IP assigned to them and the VM hosts don't do IP routing.

Thanks

Re: VLANs

[John Haxby]

On 11/01/11 17:15, Jonathan Tripathy wrote:
> Just one last question. Are there any measures I would need to take to 
> make sure that traffic cannot escape from a Linux bridge? My bridges 
> don't have IP assigned to them and the VM hosts don't do IP routing. 

The only way to get from one bridge to another is by routing so if there 
is no route then there's no way to get packets (or frames) to leap from 
one bridge to another.  (And if you're using separate vlans then you'd 
need a machine on both that is prepared to route the packets.)

Of course, testing is paramount.  No amount of hypothesising is going to 
help if you haven't tested.

jch

VLANs

[Jonathan Tripathy]

Hi Everyone,

If I plug my Xen host to a VLAN aware switch using a trunk port (I.e. 
all frames are tagged), can my Xen host, using a linux bridge, strip out 
all tagging and send frame to correct Xen VM? (And vice versa)

I wish to have isolated and secure networks that cannot communicate 
except via my VLAN aware firewall (pfsense)

Thanks

Re: VLANs

[John Haxby]

On 5 Jan 2011, at 12:12, Jonathan Tripathy wrote:

> 
> If I plug my Xen host to a VLAN aware switch using a trunk port (I.e. all frames are tagged), can my Xen host, using a linux bridge, strip out all tagging and send frame to correct Xen VM? (And vice versa)

Yes.  The outgoing interface on the bridge deals with the VLAN tag.

> 
> I wish to have isolated and secure networks that cannot communicate except via my VLAN aware firewall (pfsense)


Yup, that's what you get.

jch