VM is left unprotected when there is an error in the Security Group rules

[OpenNebulaSupport]

Description The network Security Groups (SG) are composed of rules to play the role fo a firewall to the VM guest they are mapped to iptables and ipset rules on the hosts. When an operator defines an SG rule incompatible with iptables, the VNN_MAD deletes all the iptable chains for the given VM NIC and logs an error that is visible as a notification for the given VM. Simultaneously, the VM is left running vulnerable without any form of firewall protection and an inexperienced operator could not pay enough attention. It is possible to even edit the SG rules and then not look at the VM's tab in Sunstone to notice the raised errors...

To Reproduce

• instantiate a VM with a SG
• edit the SG and create broken definition, the simplest is to define multiport rule with starting port bigger than the ending port, like:

  RULE=[
  PROTOCOL="TCP",
  RANGE="443:80",
  RULE_TYPE="inbound" ]

• When the SG is applied, all the VMs with the given SG will have an error and the vnn_mad driver will leave them running without protection...

Expected behavior Any solution that does not leave the VM open and vulnerable to the internet in case of buggy SG rule is better than the current behavior. The simplest that I'd think of is, when there is a SG defined, in case of an error the append all DROP rule in the iptables chain. Because it is better to have the VM blocked needing further attention to fix it than leave it open to become hacked.

Details

• Affected Component: [oned]
• Hypervisor: [KVM]
• Version: [6.8, 6.10]

Progress Status

• [ ] Code committed
• [ ] Testing - QA
• [ ] Documentation (Release notes - resolved issues, compatibility, known issues)

[rsmontero]

See comments here: https://github.com/OpenNebula/one/pull/6760#issuecomment-2488937377

[rsmontero]

Updating the issue here:

• After a discussion in the PR the patch is not accepted as it does not solve the issue and leaves the hypervisor in an inconsistent state.
• The root of this issue is that rules are not completely validated

Actions

The "bug" is actually in SecurityGroup::is_valid() . This needs to be extended when first port in range is greater than last, the range needs to be properly sorted.