Bug 1601054 - Securing metadata service with isolated metadata enabled
Summary: Securing metadata service with isolated metadata enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: Upstream M3
: 15.0 (Stein)
Assignee: Bernard Cafarelli
QA Contact: Candido Campos
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-13 18:15 UTC by Marc Methot
Modified: 2019-09-26 10:45 UTC (History)
14 users (show)

Fixed In Version: openstack-neutron-14.0.0-0.20190301161222.7fbba81.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-21 11:16:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1745618 0 None None None 2018-08-02 07:14:09 UTC
OpenStack gerrit 600421 0 None None None 2018-09-07 13:39:14 UTC
Red Hat Product Errata RHEA-2019:2811 0 None None None 2019-09-21 11:18:42 UTC

Description Marc Methot 2018-07-13 18:15:12 UTC
Request from user:

Metadata service listens on "all" interfaces and iptables isn't restricting access to this service.   Anything outside of this subnet is able to access this service and could cause a DoS attack.  I'd like to see a mechanism to configure iptables to restrict traffic to this service to the link local subnet as well as the neutron subnet.
In this example, IP1 is accessible outside our OpenStack/ip subnet and "anyone" can access this service.  Fortunately, the metadata service responds with a HTTP 404, however the fact it responded opens the door to a denial of service attack.

[root@edtnabtfye31 neutron]# ip netns exec qdhcp-c2349c17-c64d-44b1-824c-153745494fec netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 IP1:53        0.0.0.0:*               LISTEN
tcp        0      0 169.254.169.254:53      0.0.0.0:*               LISTEN
udp        0      0 IP1:53        0.0.0.0:*
udp        0      0 169.254.169.254:53      0.0.0.0:*
udp        0      0 0.0.0.0:67              0.0.0.0:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  2      [ ]         DGRAM                    618188779

***Legitimate requests from the VM***
2017-12-15 03:33:14.315 37212 INFO neutron.wsgi [-] IP1 - - [15/Dec/2017 03:33:14] "GET /latest HTTP/1.1" 200 127 3.037322
2017-12-15 03:33:19.583 37212 INFO neutron.wsgi [-] IP1 - - [15/Dec/2017 03:33:19] "GET / HTTP/1.1" 200 215 0.081745

*** Illegitimate requests generated from “outside”***
2017-12-15 03:43:14.799 37212 INFO neutron.wsgi [-] IP2 - - [15/Dec/2017 03:43:14] "GET /latest HTTP/1.1" 404 176 0.050890
2017-12-15 03:43:18.354 37212 INFO neutron.wsgi [-] IP2 - - [15/Dec/2017 03:43:18] "GET / HTTP/1.1" 404 176 0.049309

This is of particular concern for IP subnets that are on the Internet.  Yes, I do agree an upstream firewall/ACL can block this, but I feel this can also be achieved on the neutron node as well, and this is what I'm requesting.

Comment 3 Assaf Muller 2018-07-16 13:59:43 UTC
1) Are you using metadata exclusively from the DHCP agent? (Isolated metadata)
2) Is this with provider flat or VLAN networks, or are you using VXLAN?

Comment 4 Cory Bannister 2018-07-16 14:02:59 UTC
(In reply to Assaf Muller from comment #3)
> 1) Are you using metadata exclusively from the DHCP agent? (Isolated
> metadata)

yes

> 2) Is this with provider flat or VLAN networks, or are you using VXLAN?

provider networks

Comment 7 Slawek Kaplonski 2018-08-02 07:13:37 UTC
I think that this bug is related: https://bugs.launchpad.net/neutron/+bug/1745618

Comment 11 Bernard Cafarelli 2019-02-12 10:33:05 UTC
https://review.openstack.org/#/c/600421/ merged and cherry-picked to Rocky/Queens, moving to POST

Comment 17 errata-xmlrpc 2019-09-21 11:16:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2811


Note You need to log in before you can comment on or make changes to this bug.