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.
(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
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