Open Stack

Thanks Sam, I don't expect the Nova security reviewers to object as
they're unable to reproduce this and consider the bug apparently fixed
in the Queens release anyway. Setting the security advisory task to
won't fix state, but can be revisited if any new information comes to
light.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

** Description changed:

- This issue is being treated as a potential security risk under embargo.
- Please do not make any public mention of embargoed (private) security
- vulnerabilities before their coordinated publication by the OpenStack
- Vulnerability Management Team in the form of an official OpenStack
- Security Advisory. This includes discussion of the bug or associated
- fixes in public forums such as mailing lists, code review systems and
- bug trackers. Please also avoid private disclosure to other individuals
- not already approved for access to this information, and provide this
- same reminder to those who are made aware of the issue prior to
- publication. All discussion should remain confined to this private bug
- report, and any proposed fixes should be added to the bug as
- attachments.
- 
- --
- 
  Have been debugging some instance hacks on our cloud and we have tracked
  it down to nova setting some iptables to open access to all instances.
  
  Environment:
  We are using neutron and have reproduced this on Newton and Ocata, it looks like Mitaka is not affected
  
  nova.conf options:
  use_neutron=True
  linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver
  firewall_driver = nova.virt.firewall.NoopFirewallDriver
  
  neutron is using ML2/linuxbridge
  
  Steps to reproduce:
  # Clear out all iptables rules
  iptables -F; iptables -X; iptables -t nat -F; iptables -t nat -X; iptables -t mangle -F; iptables -t mangle -X; iptables -t raw -F; iptables -t raw -X
  # restart neutron linuxbridge
  systemctl restart neutron-linuxbridge-agent
  # Wait a couple of seconds for rules to be added
  sleep 5
  # Restart nova-compute
  systemctl restart nova-compute
  
  If you look in iptables you will see in the FORWARD chain:
  
  -A FORWARD -j nova-filter-top
  -A FORWARD -j nova-compute-FORWARD
  -A FORWARD -j neutron-filter-top
  -A FORWARD -j neutron-linuxbri-FORWARD
  
  The nova-compute-FORWARD chain will have
  -A nova-compute-FORWARD -i brq34bf77e6-d8 -j ACCEPT
  -A nova-compute-FORWARD -o brq34bf77e6-d8 -j ACCEPT
  -A nova-compute-FORWARD -o brq34bf77e6-d8 -j DROP
  
  It seems that once neutron agent does something on this host, eg. a new
  instance gets booted/deleted etc. then the rules change to:
  
  -A FORWARD -j neutron-filter-top
  -A FORWARD -j neutron-linuxbri-FORWARD
  -A FORWARD -j nova-filter-top
  -A FORWARD -j nova-compute-FORWARD
  
  So we don't see this much, just on quiet compute nodes it would seem.
  
  I feel like nova shouldn't be doing any iptables stuff so I'm scared
  I've got some config wrong but I haven't found anything so far and it
  looks the same as our Mitaka hosts which don't see this issue.

-- 
You received this bug notification because you are a member of OpenStack
Security SIG, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1752792

Title:
  Iptables can allow open access to instances in certain situations

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Have been debugging some instance hacks on our cloud and we have
  tracked it down to nova setting some iptables to open access to all
  instances.

  Environment:
  We are using neutron and have reproduced this on Newton and Ocata, it looks like Mitaka is not affected

  nova.conf options:
  use_neutron=True
  linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver
  firewall_driver = nova.virt.firewall.NoopFirewallDriver

  neutron is using ML2/linuxbridge

  Steps to reproduce:
  # Clear out all iptables rules
  iptables -F; iptables -X; iptables -t nat -F; iptables -t nat -X; iptables -t mangle -F; iptables -t mangle -X; iptables -t raw -F; iptables -t raw -X
  # restart neutron linuxbridge
  systemctl restart neutron-linuxbridge-agent
  # Wait a couple of seconds for rules to be added
  sleep 5
  # Restart nova-compute
  systemctl restart nova-compute

  If you look in iptables you will see in the FORWARD chain:

  -A FORWARD -j nova-filter-top
  -A FORWARD -j nova-compute-FORWARD
  -A FORWARD -j neutron-filter-top
  -A FORWARD -j neutron-linuxbri-FORWARD

  The nova-compute-FORWARD chain will have
  -A nova-compute-FORWARD -i brq34bf77e6-d8 -j ACCEPT
  -A nova-compute-FORWARD -o brq34bf77e6-d8 -j ACCEPT
  -A nova-compute-FORWARD -o brq34bf77e6-d8 -j DROP

  It seems that once neutron agent does something on this host, eg. a
  new instance gets booted/deleted etc. then the rules change to:

  -A FORWARD -j neutron-filter-top
  -A FORWARD -j neutron-linuxbri-FORWARD
  -A FORWARD -j nova-filter-top
  -A FORWARD -j nova-compute-FORWARD

  So we don't see this much, just on quiet compute nodes it would seem.

  I feel like nova shouldn't be doing any iptables stuff so I'm scared
  I've got some config wrong but I haven't found anything so far and it
  looks the same as our Mitaka hosts which don't see this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1752792/+subscriptions