Reviewed: https://review.opendev.org/712632 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=00298fe6e84cd7610b39af50e9517885a182f47c Submitter: Zuul Branch: master
commit 00298fe6e84cd7610b39af50e9517885a182f47c Author: LIU Yulong <i...@liuyulong.me> Date: Fri Mar 13 18:18:04 2020 +0800 [Security] fix allowed-address-pair 0.0.0.0/0 issue When add allowed-address-pair 0.0.0.0/0 to one port, it will unexpectedly open all others' protocol under same security group. IPv6 has the same problem. The root cause is the openflow rules calculation of the security group, it will unexpectedly allow all IP(4&6) traffic to get through. For openvswitch openflow firewall, this patch adds a source mac address match for the allowed-address-pair which has prefix lenght 0, that means all ethernet packets from this mac will be accepted. It exactly will meet the request of accepting any IP address from the configured VM. Test result shows that the remote security group and allowed address pair works: 1. Port has 0.0.0.0/0 allowed-address-pair clould send any IP (src) packet out. 2. Port has x.x.x.x/y allowed-address-pair could be accepted for those VMs under same security group. 3. Ports under same network can reach each other (remote security group). 4. Protocol port number could be accessed only when there has related rule. Closes-bug: #1867119 Change-Id: I2e3aa7c400d7bb17cc117b65faaa160b41013dde ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1867119 Title: [security] Add allowed-address-pair 0.0.0.0/0 to one port will open all others' protocol under same security group Status in neutron: Fix Released Bug description: [security] Add allowed-address-pair 0.0.0.0/0 to one port will open all others' protocol under same security group When add allowed-address-pair 0.0.0.0/0 to one port, it will unexpectedly open all others' protocol under same security group. First found in stable/queens, but also confirmed in master branch. IPv6 has the same problem! Devstack test config: [DEFAULT] [l2pop] [ml2] type_drivers = flat,gre,vlan,vxlan tenant_network_types = vxlan extension_drivers = port_security,qos mechanism_drivers = openvswitch,l2population [ml2_type_vxlan] vni_ranges = 10000:19999 [securitygroup] firewall_driver = openvswitch [ovs] local_ip = 10.0.5.10 [agent] tunnel_types = vxlan l2_population = True arp_responder = True enable_distributed_routing = True extensions = qos Step to reproduce: 1. Assuming you have following VMs | 24231705-ee79-4643-ae5a-9f0f7ff8f8ba | dvr-ha-vm-2 | ACTIVE | dvr-ha=192.168.30.44, 172.16.12.220 | cirros | nano | | 4865d216-9f95-40bf-a6b4-221e3af06798 | dvr-ha-vm-1 | ACTIVE | dvr-ha=192.168.30.64, 172.16.13.52 | cirros | nano | $ nova interface-list 4865d216-9f95-40bf-a6b4-221e3af06798 +------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+ | Port State | Port ID | Net ID | IP addresses | MAC Addr | Tag | +------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+ | ACTIVE | b333b1ca-bb9a-41fd-a878-b524ffbc6d7a | a9e82560-f1ac-4909-9afa-686b57df62fa | 192.168.30.64 | fa:16:3e:12:66:05 | - | +------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+ $ nova interface-list 24231705-ee79-4643-ae5a-9f0f7ff8f8ba +------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+ | Port State | Port ID | Net ID | IP addresses | MAC Addr | Tag | +------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+ | ACTIVE | 93197f48-3fe4-47f4-9d15-ba8728c00409 | a9e82560-f1ac-4909-9afa-686b57df62fa | 192.168.30.44 | fa:16:3e:14:ff:f1 | - | +------------+--------------------------------------+--------------------------------------+---------------+-------------------+-----+ 2. Security group rules $ openstack security group rule list 535018b5-7038-46f2-8f0e-2a6e193788aa --long|grep ingress | 01015261-0ca3-49ad-b033-bc2036a58e26 | tcp | IPv4 | 0.0.0.0/0 | 22:22 | ingress | None | | 36441851-7bd2-4680-be43-2f8119b65040 | icmp | IPv4 | 0.0.0.0/0 | | ingress | None | | 8326f59e-cf26-4372-9913-30c71c036a2e | None | IPv6 | ::/0 | | ingress | 535018b5-7038-46f2-8f0e-2a6e193788aa | | e47c6731-a0f7-42aa-8125-a9810e7b5a17 | None | IPv4 | 0.0.0.0/0 | | ingress | 535018b5-7038-46f2-8f0e-2a6e193788aa | 3. Start a nc test server in dvr-ha-vm-2 # nc -l -p 8000 4. Try to curl that dvr-ha-vm-2 port 8000 in the outside world $ curl http://172.16.12.220:8000/index.html curl: (7) Failed connect to 172.16.12.220:8000; Connection timed out 5. Add allowed address pair 0.0.0.0/0 to dvr-ha-vm-1 openstack port set --allowed-address ip-address=0.0.0.0/0 b333b1ca-bb9a-41fd-a878-b524ffbc6d7a 6. Try to curl that dvr-ha-vm-2 port 8000 again It is connected!!! # nc -l -p 8000 GET /index.html HTTP/1.1 User-Agent: curl/7.29.0 Host: 172.16.12.220:8000 Accept: */* asdfasdf asdfasdf To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1867119/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp