Feature #3479

Make the MAC/IP Spoofing dependency with Security Groups driver explicit

Added by Ruben S. Montero about 6 years ago. Updated almost 5 years ago.

Status:ClosedStart date:12/29/2014
Priority:NormalDue date:
Assignee:Jaime Melis% Done:

0%

Category:Drivers - Network
Target version:Release 5.0
Resolution:fixed Pull request:

Description

A Virtual Netwrok can select MAC/IP spoofing options but iptables rules will be only set for Hosts and VMs using security groups.

opennebula-4.12.1-nospoofevenwithnosgs.diff Magnifier (3.22 KB) Roy Keene, 12/21/2015 10:04 PM

opennebula-4.12.1-nospoofevenwithnosgs.diff Magnifier (777 Bytes) Roy Keene, 12/21/2015 10:23 PM

Associated revisions

Revision ff7acca6
Added by Jaime Melis almost 5 years ago

Feature #3479: Make the MAC/IP Spoofing dependency with Security Groups driver explicit

History

#1 Updated by Daniel Molina almost 6 years ago

  • Category changed from Sunstone to Drivers - Network

#2 Updated by Ruben S. Montero almost 6 years ago

  • Status changed from New to Assigned
  • Assignee set to Jaime Melis

#3 Updated by Ruben S. Montero almost 6 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

#4 Updated by Ruben S. Montero about 5 years ago

  • Status changed from Closed to New
  • Target version changed from Release 4.12 to 82

#5 Updated by Roy Keene about 5 years ago

Attached is a basic patch that fixes the issue of antispoofing rules not being added for a network if there are no security groups at all for a NIC.

It adds an additional argument to nic_pre/nic_post, this may not be ideal.

#6 Updated by Roy Keene about 5 years ago

Alternate implementation

#7 Updated by Roy Keene about 5 years ago

Alternate implementation, this time with patch.

Patch is untested.

#8 Updated by Ruben S. Montero about 5 years ago

  • Target version changed from 82 to Release 5.0

#9 Updated by Jaime Melis almost 5 years ago

  • Status changed from New to Assigned
  • Resolution deleted (fixed)

Hi Roy, we were about to implement this but after thinking it through we think that it's better to leave it as is.

When OpenNebula gets bootstrapped, the Security Group "Default" is created, which allows all outbound and inbound communication. Every VNET is automatically added to this Security Group transparently. Therefore by default the spoofing filters will work as they will apply along with the "Default" SG.

The default SG cannot be delete, but we considered the corner-case that the user may want to manually remove the default SG from the VNET. This ticket is about that corner case and it leads to the following question: why would any one want to remove the default SG from a network? We consider this to be very unlikely.

What are your thoughts? What's your use case?

#10 Updated by Roy Keene almost 5 years ago

The issue here is two fold:

1. Q. Why would any want to remove the default SG from a network ? A. The default security group includes an ACCEPT all for in/out. This is a terminal rule so when the firewall rules are assembled and the default security group iptables rules get placed above the other rules for the NIC the other rules are not applied.

2. Fundamentally the functionality should still work -- anti-spoofing doesn't indicate that it will be related to security group, it's surprising when it does not work

#11 Updated by Jaime Melis almost 5 years ago

But that is the intended behaviour. When we added the SG feature, we didn't want the users to go through the trouble of defining outbound and inbound rules for their VMs to get to work, that's why the default security group has two rules, one that allows all outbound traffic and another one that allows all inbound traffic.

In the documentation [1] we mention (right at the top) that:

By default, the default security group is applied to new VMs, which allows all OUTBOUND traffic but blocks any INBOUND traffic. Modify the default security group to allow all INBOUND connections or to define any rules you might want.

Meaning, if a user doesn't care about SG, everything will work, but if he wants SGs to make any sense, he must change the rules of the default SG to be more restrictive, as the default rules permit everything

Does this make sense?

[1] http://docs.opennebula.org/4.14/administration/networking/security_groups.html

#12 Updated by Jaime Melis almost 5 years ago

I just realised that text is wrong, no wonder it doesn't make sense. The default rules are:

TYPE PROTOCOL ICMP_TYPE NETWORK RANGE
OUTBOUND ALL Any
INBOUND ALL Any

Meaning, everything is allowed. I just added a banner to the documentation fixing that text and making it more visual and obvious.

Does it make more sense now? If you want to use Security Groups, you need to change the default rules.

#13 Updated by Roy Keene almost 5 years ago

The issue is that there can really be no good rules there for the default security group.

Since ACCEPT/DROP rules are terminal and are placed before rules in other security groups in some cases placing ANY rules in the default security group can lead to unexpected results for users. There are two options here:
1. Create no rules in the default security group (i.e., empty set)
2. Do not apply the Default security group to anything the users cannot remove it from (VNETs)

The problem with #1 is that there is a default DROP for in/out added at the end of the iptables chain if there are any security groups. So if a user doesn't select any security group and only the default security group is used then all traffic is dropped.

Users can't change the rules in the Default security group, only the administrator can -- user's only option is to not use it.

Since the user also may not be able to manage the VNET, and there can be no good rules for it (except empty), I don't apply the Default security group to any VNETs. The end result being that if the user doesn't apply any security groups to a NIC they almost always end up with no security groups. This breaks anti-spoofing.

The alternate implementation above is really short and just adds the security ID 0 to any NICs with an empty set of security groups -- this is the implementation I'm using now. If the user ends up not selecting any security groups at all they get SGID 0, if they do select any security groups (either at the VNET or NIC level) then those security groups are used and the SGID 0 is not added.

#14 Updated by Jaime Melis almost 5 years ago

OK, I think I understand what you are saying:

- A user in your cloud cannot manage the networks.
- A user should be able to have everything working without adding SGs.
- If a user wants to add a SG they can.

It makes sense, but I think that asking them to always create SGs is not unreasonable, I think it's actually a good practice.

The alternate implementation above is really short and just adds the security ID 0 to any NICs with an empty set of security groups -- this is the implementation I'm using now. If the user ends up not selecting any security groups at all they get SGID 0, if they do select any security groups (either at the VNET or NIC level) then those security groups are used and the SGID 0 is not added.

A minor problem with the patch is that if the Virtual Machine does not reference any SGs explicitely when you create it (which is the scenario we're discussing), it will not include the SECURITY_GROUP_RULEs [1] into the VM XML, and the driver will not apply any rules, therefore no networking will work (unless I'm mistaken)

Even if that worked, that would be confusing if the admin has changed the Default SG, since it would apply some filtering, completely unknown to the user and you would not be able to figure out what's going on even with onevm show -x.

In order to fix both things I hardcoded the Default SG rules into the driver, and it does work.

Let me discuss all of this with the team. I guess it's down to deciding whether it's reasonable to ask the user to create a SG always for Clouds implementing your workflow/use-case. Being flexible is great but giving many alternatives to accomplish the same things confuses the users.

[1] https://gist.github.com/jmelis/f053f938097864bd06d680f01eb46234#file-onevm-xml-L113

#15 Updated by Jaime Melis almost 5 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

Fixed

Also available in: Atom PDF