yahoo-eng-team team mailing list archive

[Arun Vinod <2075539@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

High level description:

The default iptables rules added by neutron port-security allows the
replies from rogue DHCP servers to reach the VM on provider network


steps to reproduce-
- Create provider network with DHCP enabled
- enable port-security
- if there is a rogue DHCP running on the network, or behind the router (when dhcp relay is enabled on router), the DHCP-discover from VMs will reach there and dhcp-offer and dhcp-ack from those Rogue DHCP servers can hit VMs.
- there is 50% probability that VMs get configured with IP from rogue DHCP instead of neutron assigned IP


Below are the two of the default rules added by neutron on the input chain of port.
-A neutron-linuxbri-i13f86148-e -d xx.xx.xx.xx/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
-A neutron-linuxbri-i13f86148-e -d 255.255.255.255/32 -p udp -m udp --sport 67 --dport 68 -j RETURN


The second rule in the above chain will allow a DHCP udp packet with destination address as broadcast address. 

When does VM receives DHCP replies as broadcast:

Guest VMs, especially windows VM send DHCP discovery with broadcast FLag
set, by explicitly telling DHCP server to generate replies as broadcast
instead of unicast.

Below is a dhcp-udp packet from a rogue dhcp server:

1:09:32.461689 IP (tos 0x0, ttl 255, id 25540, offset 0, flags [none], proto UDP (17), length 337)
    _gateway.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 309, hops 1, xid 0x782eed61, Flags [Broadcast] (0x8000)
          Your-IP 10.20.146.108
          Gateway-IP _gateway
          Client-Ethernet-Address fa:16:3e:8f:8c:0c (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Subnet-Mask Option 1, length 4: 255.255.248.0
            Default-Gateway Option 3, length 4: _gateway
            Domain-Name-Server Option 6, length 4: 10.20.136.61
            Hostname Option 12, length 7: "win22-1"
            Domain-Name Option 15, length 15: "xx.xx"
            Lease-Time Option 51, length 4: 1800
            Server-ID Option 54, length 4: 172.22.0.5
            Client-ID Option 61, length 7: ether fa:16:3e:8f:8c:0c
            END Option 255, length 0

Expected output:

The port security of neutron not bypassing these broadcast DCHP replies
from Rogue DHCP server

Actual output:

The VM receives these rogue dhcp-replies along with replies from neutron
dhcp-agent and sometimes gets configured with  wrong IP.


proposed fix:

When dhcp is enabled for the provider network, the DHCP offer and DHCP-
ACK from the dnsmasq process will have the dhcp-agent's IP as source IP.
But the destination can be either broadcast address or unicast address
(VM's offered IP)

So we need to allow only DHCP replies whose source address is neutron
dhcp-agent's IP, when its broadcasting replies.

something like,

-A neutron-linuxbri-i13f86148-e -s xx.xx.xx.xx -d 255.255.255.255/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
where , xx.xx.xx.xx is neutron dhcp-agent's IP


version:
 openstack: xena
 Linux distro: centos 8 

Environment:
 neutron driver: linux bridge

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2075539

Title:
  port-security iptables rules allows rogue DHCP servers to reach
  instances

Status in neutron:
  New

Bug description:
  High level description:

  The default iptables rules added by neutron port-security allows the
  replies from rogue DHCP servers to reach the VM on provider network

  
  steps to reproduce-
  - Create provider network with DHCP enabled
  - enable port-security
  - if there is a rogue DHCP running on the network, or behind the router (when dhcp relay is enabled on router), the DHCP-discover from VMs will reach there and dhcp-offer and dhcp-ack from those Rogue DHCP servers can hit VMs.
  - there is 50% probability that VMs get configured with IP from rogue DHCP instead of neutron assigned IP

  
  Below are the two of the default rules added by neutron on the input chain of port.
  -A neutron-linuxbri-i13f86148-e -d xx.xx.xx.xx/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
  -A neutron-linuxbri-i13f86148-e -d 255.255.255.255/32 -p udp -m udp --sport 67 --dport 68 -j RETURN

  
  The second rule in the above chain will allow a DHCP udp packet with destination address as broadcast address. 

  When does VM receives DHCP replies as broadcast:

  Guest VMs, especially windows VM send DHCP discovery with broadcast
  FLag set, by explicitly telling DHCP server to generate replies as
  broadcast instead of unicast.

  Below is a dhcp-udp packet from a rogue dhcp server:

  1:09:32.461689 IP (tos 0x0, ttl 255, id 25540, offset 0, flags [none], proto UDP (17), length 337)
      _gateway.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 309, hops 1, xid 0x782eed61, Flags [Broadcast] (0x8000)
            Your-IP 10.20.146.108
            Gateway-IP _gateway
            Client-Ethernet-Address fa:16:3e:8f:8c:0c (oui Unknown)
            Vendor-rfc1048 Extensions
              Magic Cookie 0x63825363
              DHCP-Message Option 53, length 1: Offer
              Subnet-Mask Option 1, length 4: 255.255.248.0
              Default-Gateway Option 3, length 4: _gateway
              Domain-Name-Server Option 6, length 4: 10.20.136.61
              Hostname Option 12, length 7: "win22-1"
              Domain-Name Option 15, length 15: "xx.xx"
              Lease-Time Option 51, length 4: 1800
              Server-ID Option 54, length 4: 172.22.0.5
              Client-ID Option 61, length 7: ether fa:16:3e:8f:8c:0c
              END Option 255, length 0

  Expected output:

  The port security of neutron not bypassing these broadcast DCHP
  replies from Rogue DHCP server

  Actual output:

  The VM receives these rogue dhcp-replies along with replies from
  neutron dhcp-agent and sometimes gets configured with  wrong IP.

  
  proposed fix:

  When dhcp is enabled for the provider network, the DHCP offer and
  DHCP-ACK from the dnsmasq process will have the dhcp-agent's IP as
  source IP. But the destination can be either broadcast address or
  unicast address (VM's offered IP)

  So we need to allow only DHCP replies whose source address is neutron
  dhcp-agent's IP, when its broadcasting replies.

  something like,

  -A neutron-linuxbri-i13f86148-e -s xx.xx.xx.xx -d 255.255.255.255/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
  where , xx.xx.xx.xx is neutron dhcp-agent's IP

  
  version:
   openstack: xena
   Linux distro: centos 8 

  Environment:
   neutron driver: linux bridge

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