* listening services available on all addresses

This is exacerbated by us not having unique credentials for all layers in the stack.

+1 for super careful about defining listening service definitions

I think we will need to do it anyway in current ha story

In the months since this was opened there's been some progress on the "be careful" front by way of https://review.openstack.org/#/c/100151/ - in which we defined a spec for having a "public" vip for the public services. This makes controlling access to the services much easier as there's a clear separation.

More recently we've also noticed cases where other services (particularly dnsmasq) listen on the public interface and can be used for things like dns-amplification attacks. This is suboptimal, but it seems as though the "be careful" strategy should be useful here too.

Fix proposed to branch: master
Review: https://review.openstack.org/139865

We have a fix for dnsmasq that should stop it listening on 0.0.0.0.

Comments on this bug have suggested that "being super careful" is our preferred approach for now. As I'm not aware of any outstanding services that still listen on all available addresses I'm inclined to close this issue (and re-open if we find more).

Reviewed: https://review.openstack.org/139865
Committed: https://git.openstack.org/cgit/openstack/tripleo-image-elements/commit/?id=b77ec5cb5b3ed400b44302bdbd76e2275d819da3
Submitter: Jenkins
Branch: master

commit b77ec5cb5b3ed400b44302bdbd76e2275d819da3
Author: James Polley <email address hidden>
Date: Sun Dec 7 17:29:54 2014 +0100

    System dnsmasq daemon should only listen on lo

    Neutron runs dnsmasq. That's all nice and good.

    But just having dnsmasq installed means that the system runs a different
    dnsmasq, which by default listens (and response) on all interfaces.

    For machines that are accessible on the public internet, this means they
    can be used in dns-amplification DOS attacks. This tends to make
    security and network people sad.

    This patch drops some config for the system dnsmasq which tell it to
    only listen on 127.0.0.1.

    If the deployer needs dnsmasq listening on other interfaces, another
    file dropped in /etc/dnsmasq.d can be used to specifiy additional
    interfaces or IP addreses.

    Change-Id: I6b390e168c2f972b0beab52815922bb6b2ccf786
    Partial-bug: 1188067

With dnsmasq being fixed, I don't see any specific actions we can take on this right now. To me this seems more like a guiding principle than a bug - perhaps it would be better converted to a spec.